The document has moved here.

Canyon: more JSR-223 and the SimpleBindings

In order to make the widgets available as object during script execution, I have extended javax.script.SimpleBindings so that I lookup keys in the widget hierarchy before handing it down to the backing map by overriding the get() method. This was how I did it when using the Groovy implementation directly. I have discovered that javax.script requires that I override containsKey() as well as get(), otherwise it doesn’t even attempt to invoke get(). Now that is fixed in SVN and I am nearing the first public release of Canyon.


Canyon: JSR-223

Canyon is my implementation of the concepts behind various kinds of XML-based application interface tools (XAML, Flash MXML, ZK, etc).
Canyon started off as a way to describe Echo2 ( applications using XML bound together with Groovy ( scripts.
Recently I’ve been working on refactoring Canyon to support multiple widget libraries (Echo2, Cooee, Echo3, Swing, SWT, etc) and JSR-223 (aka javax.script) instead of just Groovy. Currently canyon and its bits are available on Sourceforge SVN (

I promise I will hopefully get a half-way decent site for all these projects of mine and create some sort of community going.


WARShield: progress

The WARShield stuff progresses nicely: it now implements most of the feature-set I had in mind.

I have also implemented an event/listener method so that other ContextListeners / Servlets /Filters can get notified when the configuration is readily available, changes, etc.

Currently the configuration is stored in a single properties file, but I am adding a “multi-resource” method so that applications supply a set of template files which get populated with the configuration data (similar to the maven resource filtering by using the ${} notation).

I plan on adding hooks for containers such as Spring, so that they look for their data in the appropriate place and wait until the configuration is ready before reading it.


WARShield: Java webapp setup wizard framework

Well, the title is a mouthful, but it says it all.
I am working on a small generic framework for implementing setup wizards in Java WAR applications.

My requirements/features are as follows:

  • store configuration information in a sensible, environment-dependent location (e.g. ~/.java under Unix/Linux, Application Data under Windows, ~/Library, etc
  • XML-based wizard descriptor
  • allow any kind of Java view technology (JSP, Velocity, etc)
  • validation for each step in the wizard both via a user-supplied class or via a javax.script-supported script
  • no external dependencies apart from slf4j
  • obviously available via Maven

Currently the code is embedded in another side-project of mine (a Time Tracker application), but I plan to extrapolate it and make it available under an MIT license as soon as it”s robust enough and not so rough as it is now… 🙂