For this blog post we follow up the Jaxer introduction video, with a video about how we are continuing to simplify the Jaxer installation process.

In this video we’re after the low hanging fruit of trying to clean out the post install directory to try and remove folders that aren’t needed. For context, here’s a screenshot of the folders that are included by default.

To quickly explain each of the folders we have :

• Apache22 which contains a local installation of Apache with the Jaxer config files for mod-jaxer
• data where Jaxer stores local MySqlite databases
• Jaxer, which contains the binary for the Jaxer application server
• local_jaxer is a folder for non-standard installation config files to be set
• public used for hosting web facing html, css and js files
• scripts which are used to start and stop the Apache and Jaxer servers
• tmp folder that contains temporary data such as cookies and uploads

The four folders that we’re trying to get rid of are data, local_jaxer, logs and tmp. As luck would have it all four of these folders are created in the same scripts/post_install.sh shell script. So we can remove these lines from that script to stop the folders from being created, but next we will need to move the functionality.

The easiest two of these four to handle were tmp, and logs, which are passed in parameters in the scripts/startJaxer.sh script. So our log directory is now /var/log/jaxer and tmp directory has simply been moved to /tmp. Because the process id was set to be placed in the tmp folder, we can move the pid to /var/run/jaxer.pid. Having these parameters set in a configuration file is preferable to passing the arguments on the command line, but we can comeback to that at a later time.

For local_jaxer there were two minor complications. The first is that on server start up, Jaxer will try to read the local_jaxer folder and throw an error when it can’t find the folder. The fix ended up being pretty simple as the ServerStart.js script responsible for the error checks to see if the value for the local_jaxer folder is a string. So as long as the value isn’t a string, it doesn’t check, and we don’t get an error.

The other issue that we had with the local_jaxer folder is that it contains the JaxerManager.cfg config file. But we move it to another folder, change the parameter in the startJaxer.sh script, and problem solved. So it’s down to the last and surprisingly elusive folder, data.

The funny part about the data folder is that it will be auto created after the server starts with no error and an Sqlite database file will be placed inside of it. So the reason behind this is that Jaxer creates namespaces called “apps”. Since apps now generally refer to mobile applications, in the context of Jaxer an app represents a self contained web service.

So for instance if you have an application with a client area with a given url and an admin area with a different url, you can define an App for each on of these with different default database connection settings. When no app is defined, Jaxer provides a default application. And it’s this default app configuration is creating the directory where it wants to store an Sqlite database even though we haven’t attempted to open a database yet. I guess it wants to make sure the path exists before it’s needed to run.

So the solution for this was that we changed the configApps.js config file located in jaxer/framework to use a path in /usr/share/jaxer to stash the Sqlite file Jaxer wants to create, and then change the options to not auto-create folders for application paths. And that seems to have stopped Jaxer from creating another unnecessary folder in the install path.

So we’re now down to only a few folders in the installation directory. We have Apache22, jaxer, public and scripts. And right now Apache22 seems like the most obvious target for having more flexibility over how Jaxer is handled. So in the next blog posts we will be covering how Apache interacts with Jaxer.