Looking into the framework folder

Last post we looked into all of the folders for config files, and we found the script that describes where the Jaxer process should look for initialization. Today we dive into the ironically described framework folder. Ironic might not be the right term as the server-side framework is indeed located in the framework folder, but the framework folder also contains the configuration files that describes on each Jaxer process is supposed to run, and then the actual framework is stashed away in the src folder.

Finding all of the Config Files

We’ve managed to get an installation of EmraJs that’s limited only Jaxer Manager, the Jaxer executable and the Mod-Jaxer Apache Module that’s able to install from a single script on a fresh install of the latest Raspbian. Which means that next we need to try and track down all of the config files, find out what they define and if possible find out what they do. Our next focus will be the Jaxer server-side framework so it should help to have a general idea of where the configuration files are and what effects they will have on starting the server-side framework.

Cutting the Repo down to size

With more testing we’ve been working on simplifying the compile and install script for Jaxer as well as the files in the repository. And we’ve able to reduce more unused lines in the setup script, which has then allowed us to remove more folders from the repository, specifically distro and tools. So we have a much more simplified base directory for the Jaxer repository.

Addressing Local File Inclusion

We have a little bit of a mystery on our hands. The development of Jaxer was pretty much discontinued after Nodejs was released. And it’s a little unclear of how much of the community continued to use the application server after Aptana was bought by Titanium Studio. And even after continually looking we generally find new mentions of the Jaxer web server other than the little amount of information we put out on the internet.

Post Install Implementation

jaxer install script

Okay, we’ve managed to get the install script to compile and install Jaxer in from a fresh Raspberry Pi install. We can get back to where I got ahead of myself and tried to over-simplify the install script too fast and too soon without testing intermediate step along the way. Lesson learned, so now it’s time to try and look and see what can be reduced, where, why and how it can be tested without compromising runtime.

Moving Run-time Location /etc/emrajs

We’ve been simplifying the post-install Jaxer environment one folder at a time. With the previous update we were able to get Jaxer working with Vanilla (apt-get) Apache. Which means that the only folder left in the post install directory is the jaxer folder which contains the binaries. Which means if we can move that folder to something like /etc/emrajs we would have something that starts to look like an actual Linux installation. But since we haven’t even looked into /usr/sbin or anything, so maybe let’s not get ahead of ourselves on that one.

Jaxer working with Vanilla Apache

Getting Jaxer to work with vanilla Apache (as in installed from apt-get or yum) is something that I haven’t been able to get working, probably because I’m an idiot. After the failure of not being able to register our compiled version of Apache to Systemd, I figured I might as well try getting vanilla Apache to work with Jaxer, and if it doesn’t work I can always go cry in a corner.

Jaxer Maintenance Blog -Systemd Jaxer

So now that we’ve managed to separate Apache from the runtime environment by using Nodejs, that means we were able to simplify the start and stops scripts directory to remove the scripts related to Apache. And now that we only need to start and stop Jaxer, that means it should be considerably easier to register Jaxer as a service to systemd. So after a little bit of trial and error we were able to get the service to work.