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.

For approach we’ll look through the EmraJs install folder-by-folder and look for any possible files, make a note of where they are and count them up. First is the chrome directory. The chrome directory only seems to include some manifest files. I’m not sure what these are for, but after having tried to remove these files before it leads to weird errors if they are deleted. So it’s not clear what chrome does, but we don’t need to address it right now.

Next is the components folder. This is a similar story to chrome with a little more description on the file contents. We have aptCmdLineHandler.js, aptEventHandler.js, FeedProcessor.js and a few more files like libjxMySQL50.so. These look like files that are likely used to define characteristics of how the Jaxer executable runs, but not necessarily a config file. So we can leave these alone too.

Next we have the promising confs folder, which includes emrajs.service, jaxer.httpd.conf, and JaxerManager.cfg. All three of which are files that we’ve defined and are pretty straightforward. The emrajs.service file is the systemd file which defines the Emrajs service. And in that service definition we start Jaxer Manager which uses the JaxerManager.cfg file to define arguments. And jaxer.httpd.conf is our Apache module file.

We have two quick and easy folders, connectors which contains that Mod-Jaxer module for Apache. And then we have content which includes two files: fatalError.html , responseError.html. It’s tempting to get rid of the content folder, but I think it is referenced somewhere for what files to return to the client when certain errors are required. Though having Jaxer return an Error and having Apache return the error page would be a cleaner approach. This will depend on how much we can clean out.

Moving on we have default_local_jaxer/conf which surprisingly contains copies of all of the original config files: aptana.configApps.js, configApps.js, config.js, configLog.js, InternalWebServer.cfg, JaxerManager.cfg, services.configApps.js. Since we’ve removed the Aptana examples, the internal web server and services, and redefined all of the other config files, we should probably look into removing this folder from the installation entirely to avoid confusion.

Now we’ve hit a config file and the reason for this blog post. Inside of defaults/pref there is the file Jaxer_prefs.js. Which is stupid for a lot of reasons, namely why is a file in the defaults folder being implemented as an active config file?

// If the Jaxer framework fails to load and execute properly, should Jaxer be bypassed
// and the original document sent to the browser? This is false by default
// to prevent server-side code to be sent to the client in such a case
pref("Jaxer.dev.BypassJaxerIfFrameworkFailToLoad", false);

// If the framework fails to load and execute properly, and Jaxer is not bypassed (see above),
// Jaxer can display an error document instead of the default
// pref("Jaxer.dev.FailedLoadFrameworkErrorDoc", "resource:///framework/ErrorDocFrameworkFailsLoad.html");

// This option enables whether communications between Jaxer and
// its manager is dumped.  This generates a lot of log messages!
pref("Jaxer.dev.DumpProtocol", false);

// Note: the logging levels used by the Jaxer framework are configured
// via configLog.js and not by the following which are used only by Jaxer core.

// This option sets the log level for Jaxer core.  Valid levels are:
// TRACE, DEBUG, INFO, WARN, ERROR, FATAL.
pref("Jaxer.Core.LogLevel", "INFO");

// This option list enables/disables whether Jaxer will
// fire NewHTMLEvent's for the specified element tag name.
// If the element is not listed here, the element will
// _NOT_ have an event fired.
pref("Jaxer.HTML.Tag.Monitor.1", "html");
pref("Jaxer.HTML.Tag.Monitor.2", "head");
pref("Jaxer.HTML.Tag.Monitor.3", "script");
pref("Jaxer.HTML.Tag.Monitor.4", "aptana:include");

// Setting from firefox.js
pref("general.useragent.locale", "en-US");

pref("layout.css.report_errors", false);
pref("svg.enabled", true);

pref("general.useragent.extra.jaxer", "Jaxer/1.0.3.4549 (Aptana, Inc.)");
pref("intl.accept_languages", "en-us, en");
pref("intl.charset.detector", "");
pref("intl.charset.default", "ISO-8859-1");
// Use the unicode ellipsis char, \u2026
pref("intl.ellipsis", "…");

pref("dom.max_script_run_time", 10);
pref("Jaxer.JS.memory_limit", 24);

pref("Jaxer.dom.pixel_depth", 16);
pref("Jaxer.dom.screen_width", 800);
pref("Jaxer.dom.screen_height", 600);

Though there doesn’t seem to be anything useful in this file. Which means there is a different config file that I was thinking was still lurking around somewhere. I’m not sure what this file is used for, it looks like the http settings for when Jaxer makes an http web request. Which means I should probably leave this in here for now, and then maybe check if the user-agent being used matched this file, and if that user agent can be updated with this file to see if this can be removed.

The folder is framework, but I’ll save that for last. So skipping over that we have greprefs which includes all.js, security-prefs.js. Not exactly descriptive but not real hurry to remove or edit these files for the time being. Which means we have two more folders, modules which seems to include some .jsm files that look like they’re used for something. And then we have the res folder, which probably standard for “resources“. Which seems to include some html and svg files for something. So if this folder isn’t needed for anything that probably means we should remove it.

Which means as quick summary we have three folders on the chopping block: default_local_jaxer, defaults and res. That should probably be removed if they’re not being used for anything. I’ll go ahead and split the framework folder into it’s own blog post. But the reason I was looking through the folders is because I though there should be a config file that tells Jaxer to look at framework/config.js in the first place and that file turned out to be components/aptEventHandler.js. Which that the folders on the chopping block can likely be safely removed.