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.
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.
Now that we’ve managed to remove the need to compile Apache along with Jaxer, changed the configuration to use more Linux-like paths, and created a systemd script for starting and stopping the service, it means that we can now focus on getting Jaxer to install with a single script.
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.
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.
Okay, that was quick. Managed to get Apache registered to systemd as well. So now we have both of the processes Jaxer and Apache registered of services and that means that we can safely remove the entire scripts folder (yay!). For Apache, the /etc/systemd/system/apache-server.service file is written below.
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.
So in the previous post we rounded out our Apache emulator for Aptana Jaxer, which uses Express and Nodejs to act as a front-end file server and then uses Jaxer to handle calls to the server. While not complete it looks like we have a decent amount of functionality implemented with the basics being passing html files and callbacks to Jaxer to be handled.
So we’re reaching a point in the Apache emulation aspect of the simplification that I didn’t expect to reach this quickly, but either way I’ll take it. Now that we can take html files and pass them into mod-jaxer the next step is to actually be able to handle requests sent to the server.
So in the previous post we were able to proxy and http request to mod-jaxer by mimicking the format that Apache uses to pass to modules. And we were able to get the point to where we get a response from Jaxer. And Jaxer uses the same format to return a response that we use to pass in.