Building Niggle

Niggle comes with a prebuilt niggle.jar and the <ROOT>/lib directory contains all of third-party libraries that Niggle uses. So, you may have no need to rebuild Niggle from source. Nonetheless, there are a couple of basic reasons to do so. The first is if you want to change the behavior of the template variables to being case-sensitive. The other is that you want to expose your DataSources or DataRegistry objects as remote interfaces via RMI. And naturally, if you want to change anything else, you are free too, this being open source, but then you obviously have to be able to rebuild from the source.

Note that the out-of-the-box build script is an ant build file, build.xml. If you do not have the ant build tool, you can download it from the Jakarta site.

Changing to case-sensitive behavior in templates

By default, template variables are case-insensitive. This means that no distinction is made between ${foo} or ${FOO} or ${Foo} on a page template. This is actually a significant difference between using Niggle and using raw Freemarker, where all of the variables are case-sensitive. My belief was that case-insensitive syntax meshed better with HTML, which is also case-insensitive.

However, if you want to change this behavior back to being case-sensitive, you can simply change one constant in the source code and rebuild. That constant is: CASE_INSENSITIVE in the file src/com/niggle/templates/freemarkerimpl/FreemarkerPresentationWrapper.java.

Once you change this, you can rebuild the jar with: ant compile jar

Including RMI Capabilities for Niggle Data

The Niggle DataRegistry and the Niggle DataSource objects can be set up as remote RMI interfaces. This is actually a very powerful out-of-the-box capability that Niggle has. For example, it can be extremely useful if you want to have a remote administration interface to your application. Nonetheless, by default, the relevant base classes do not extend UnicastRemoteObject and nor does the niggle.jar contain the stub and skeleton classes needed by the RMI engine. The reason for this is actually rather technical. I discovered that in my own web-hosting ISP, that I could not deploy Niggle-based web apps there because they ran into SecurityManager restrictions. This was because of the RMI stuff. By turning it off, I was able to successfully deploy Niggle-based servlets there. A side issue is that, when you are not using RMI, it is annoying to have rmic as a step in your build process, since it is so slow, so there is already a strong reason to turn this on only if you are actually going to use RMI.

To rebuild Niggle with RMI capabilities you must:

Now, you should have the RMI capabilities built into Niggle.