A Mojasef improvement prompted by thoughts of Spring

Following on from my post a couple of days ago I’ve now added a small extra feature to Mojasef which should add a whole range of extra power. One of the things it enables is a much closer integration with Spring, but that’s only a small part of the possibilities.

The way this new feature is used is very simple. If you recall from the Mojasef documentation, the single most important Mojasef configuration is the http.application value. This may be specified as a system parameter or defined in a “spec” file, but the end result is the same :- it’s the object which provides the methods which eventually get called for each incoming HTTP request.

The new feature supports a similar (but optional) configuration http.application.context. If you define such a configuration, and the specified object implements org.stringtree.Fetcher or java.util.Map, it will be treated as an integral part of the common “context” available to all application methods.

One upshot of this is that if you define http.application.context to be an org.stringtree.spring.SpringFetcher, then all your Spring objects will be available as “first class” objects in your Mojasef applications. No more need for a “spring.” prefix in templates, or extra application code to fetch, cast, and eventually use a Spring BeanFactory.

The use of this new feature is not limited to Spring, though. You can supply any Map or Fetcher implementation, which means that you can use any static or dynamic name/value mapping. I haven’t written any implementations of such things yet, but there is no reason in principle that this technique could not be used to integrate diverse sources such as JNDI/LDAP repositories, databases queried by SQL, XML documents queried using XPath or even asking the whole web using a search engine such as Google.

And, don’t forget that you can combine any or all of these either using the built-in Stringtree FallbackFetcher mechanism, or by providing your own aggregating implementations of org.stringtree.Fetcher or java.util.Map.

As a final twist, Mojasef is smart enough to try alternatives if you don’t want to manually specify such a context. It was not an accident that http.application.context starts with http.application. If your http.application object makes available a property named context (typically by providing a getContext() accessor, or by exposing a get(String name) method which returns a non-null value for the name “context”) then Mojasef can use that too.

This code is currently in subversion, and will be included in the next stable Mojasef release. Example JUnit tests for the new feature can be read here and here