All posts by roger

Turnkey appliances

This blog is running on a Turnkey WordPress appliance ( Virtual appliances are of course fantastic if they work – a fully configured, just-works server which you can download and provision in seconds (this blog took about 5 minutes to download, install on a VMWare Server virtual machine and get running). Until now, most appliances we tried had enough gotchas to make us return to manual installation on a generic distribution, but the Turnkey appliances seem to be perfect. Based on Ubuntu or Debian and with just enough stuff pre-installed to make them useful, while still being compact enough to compete with a manual installation. Thanks Turnkey!

Adding scripting to java applications

Many of our applications require scripting support (allowing users to create scripts to customize workflow within the application). Java provides very straightforward scripting via the javax.script script-engine library. A simple integration is shown below where a Javascript onSave method provided by the user is called, if available, passing a business-logic object “item”:

import javax.script.Invocable;
import javax.script.ScriptEngine;
import javax.script.ScriptEngineManager;
import javax.script.ScriptException;

public class Scripting extends Base {
 private ScriptEngineManager mgr;
 private ScriptEngine engine;
 private Invocable invocable;

 private boolean initialize (String script) {
  mgr = new ScriptEngineManager();
  engine = mgr.getEngineByName("js");
  try {
  } catch (ScriptException e) {
   warn("The script could not be loaded: " + e.getMessage());
   return false;
  invocable = (Invocable)engine;
  return true;

 public void onSave(Item item) {
  try {
   invocable.invokeFunction("onSave", item);
  } catch (ScriptException e) {
   warn("The onSave method of the script caused an error: " + e.getMessage());
  } catch (NoSuchMethodException e) {
   // no onSave method provided by the user - that's OK, just ignore it

Note: the javax.script library supports multiple scripting engines including javascript, python, groovy and java. Javascript was the easiest to get working because the Rhino Javascript engine is included in JDK 6.

A sessionless login page for Wicket applications

We’re big fans of Apache Wicket, but as with most frameworks, sometimes the simplest things appear to be hard to do (or at least its hard to find out how to do them). Application session handling is great in Wicket, but I immediately ran into the problem that the problem that the login page of my application would timeout like any other page of the application. If the user logged out (at which point the login page is displayed), left the browser window open and then tried to use the same browser window to login again an hour later, he’d get a “sorry, your session has timed out, please login again”.  This message obviously makes no sense on the login page.

The solution (thanks Doug Donohue for the help on this) is to use a stateless form for the login page (which causes Wicket to only create a temporary session for the page) and when the user has successfully logged in, convert the session to a regular session.

The relevant code fragments are shown below:

final StatelessForm form = new StatelessForm("loginForm", new CompoundPropertyModel(this)) {
 private static final long serialVersionUID = 1L;

 protected void onSubmit() {
  try {
   validateUser(userid_or_email, password);
   if (getSession().isTemporary()) getSession().bind();
   // this makes the temporary session used by the stateless login page permanent
  catch (Exception e) {

Note however that you have to be very careful what components you use in a stateless page – otherwise you’ll suddenly find it to be stateful again (i.e. it will bind its session automatically and you’ll be back in the same situation). Basically anything which requires remembering a specific page instance (e.g. Ajax) will cause your page to become stateful.

There is some logic built into Wicket which should warn you when a page which you expect to be stateless becomes stateful, but it seems that in the latest versions of Wicket, these warnings are disabled. We ended up creating our own StatelessPage super-class which, in onBeforeRender, calls isPageStateless() and if that returns false, it runs through the components on the page and checks isStateless() for each and reports the wicket id for each component which is not stateless. That way, during development we can show a warning like “This page should be stateless, but isn’t because the following components are stateful: component1, component2…”

public class MyStatelessPage extends BasePage {

	protected void onBeforeRender() {

		if (Settings.isOperatingModeDevelopment())

	private void checkIfPageStateless(Page p) {
		if (!p.isPageStateless()) {
			// find out why
			final List statefulComponents = new ArrayList();
			p.visitChildren(Component.class, new IVisitor() {
				public Object component(Component component) {
					if (!component.isStateless())

			String message = "Whoops! this page is no longer stateless";
			if (statefulComponents.size() > 0) {
				message += " - the reason is that it contains the following stateful components: ";
				for (Component c : statefulComponents) {
					message += Settings.getNewLine() + c.getMarkupId();