A major goal of the Stringtree software project has always been to be as compatible as possible with all the software people are using for their Java development. Naturally that also includes whatever Java version is being used.

For a long time I interpreted this goal as implying that all Stringtree code should run on all Java versions from Java 1.2 onwards. Java 1.4, however, introduced some compelling new features including built-in regular-expression handling. For a few years I still tried to ensure that most code was still 1.2-compatible (for example by using Ant to swap in a third-party regular-expression library while building a jar file), while also providing a Java 1.4 version. Eventually, use of Java versions prior to 1.4 declined enough that I felt comfortable removing the complicated pre-1.4 version.

For the last few years I have been very careful to keep all my Stringtree code compatible with all versions of Java from 1.4 upwards. Now, however, the pressure is building again to move over to Java 5. In my day-to-day coding I develop with Java 5 and make increasing use of Java 5 features such as the enhanced for loop, the Iterable interface, enums, generics, autoboxing, varargs and so on. It would be very nice to be able to update the Stringtree codebase to use these features too.

Occasionally a Java 5-specific detail has crept in to a Stringtree library, and I have soon received comments or emails pointing this out. I haven’t noticed this for a while, which might indicate either that I have been especially careful, or that I there are no longer any/many people developing with Stringtree code who are still limited to Java 1.4.

If you are reading this and you still require Java 1.4 support, please let me know. Likewise, if you have thrown off the shackles of 1.4 within the last year or so or are desperately hoping for a Java 5 Stringtree that would be good to know too.

Is it time for Java 5 yet?

Posted by Stringtree as Friki, General, HTTPClient, Inkling, JSON, Mojasef, Projects, Templater at 7:59 PM PDT

No Comments »

Finally, I have got to a point where I reckon Mojasef is nearing a proper numbered stable release. To celebrate this I have updated the version number in the Mojasef source code to 2.0.b1 and made a downloadable release (source and jar) available at Sourceforge.

I strongly encourage anyone interested in shaping the direction, contents and/or timing of the official 2.0.1 release of Mojasef to grab this release, have a play with it, and let me know your comments and suggestions.

I know that it is light on documentation, especially as even the examples on the web site are not quite accurate any more, but that is now very high on my list of priorities.

Posted by Stringtree as Mojasef, Projects at 2:01 PM PDT

No Comments »

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

Posted by Stringtree as Mojasef, Projects at 10:06 AM PDT

2 Comments »

I don’t tend to use it myself (preferring the “spec” mechanism built-in to Stringtree), but today someone asked me if a Mojasef application could work with Spring.

After a bit of thought, some downloading, and a little playing, here is the result. My intention was to allow beans configured in a Spring application context to act as first-class citizens within a Stringtree context, so that they can be used seamlessly inside Mojasef application code and templates.

The implementation was actually pretty simple, essentially consisting of creating a class which implements org.stringtree.Fetcher and provides access to any Spring beans within a Spring context.

package org.stringtree.spring;

import org.springframework.beans.BeansException;
import org.springframework.beans.factory.BeanFactory;
import org.stringtree.Fetcher;

public class SpringFetcher implements Fetcher {

	private BeanFactory factory;

	public SpringFetcher(BeanFactory factory) {
		this.factory = factory;
	}

	public Object getObject(String name) {
		Object ret = null;
		try {
			ret = factory.getBean(name);
		} catch(BeansException e) {
			ret = null;
		}

		return ret;
	}
}

To use this class, you will need to create an instance of it, passing in a Spring BeanFactory or ApplicationContext object to the constructor. Then the SpringFetcher object can be used just as any other Fetcher.

It seems that when using Spring in a Mojasef application, what will likely be needed is a single Mojasef context which provides access to both Mojasef and Spring objects. To achieve this, simply wrap the two Fetchers in a FallbackFetcher:

	Fetcher spring = new SpringFetcher(new XmlBeanFactory(new FileSystemResource("application.xml")));
	Fetcher map = new MapFetcher();
	Fetcher ff = new FallbackFetcher(spring, map);

An example Eclipse project containing the SpringFetcher class, some unit tests, and the jar files to compile and run them is available in sourceforge subversion at https://svn.sourceforge.net/svnroot/stringtree/projects/spring_example/trunk.

Posted by Stringtree as Mojasef, Projects at 9:56 PM PDT

No Comments »