The App Engine sandbox imposes some restrictions. The most notable of these is that you cannot run background threads. Here’s how to make Wicket play ball:

• Make sure you’re running in deployment mode (this will disable the background thread that checks for modifications to your resource files, and is what you’ll want for deploying to a remote site like this anyway).
• Override newSessionStore() in your WebApplication subclass and return a new HttpSessionStore(this). (The default DiskPageStore uses a background thread and writes files, neither of which are supported in the App Engine’s sandbox.)
• Enable session support in appengine-web.xml.

App Engine for Java is in limited beta, but if you’ve been to the London Wicket Users Group at Google and would like me to wangle an account for you, please e-mail me (details on the About page).

We’re pleased to have Ari Zilka (who founded Terracotta) coming along. He will be giving a talk, as will Richard Wilkinson, who has interesting things to say about integrating Wicket with Guice and JPA. There will be a couple of other talks and some nice demos, too. If you’re wondering what it’s like to write real code in Wicket, don’t miss it.

If you’d like to come along, please wander over to the jWeekend site to sign up.

Becoming an Apache project, with all the benefits that brings, has not gone unnoticed by the wider Java development community. Particularly within the enterprise, the Apache brand (and ASF license) seems to bring with it a promise of professionalism and confidence. A bunch of banks and corporates now list it on their job advertisements, including the likes of Nokia and Time Warner. Despite the explosion in attention, the signal-to-noise ratio on the mailing lists remains impressively high. People are being really helpful both there and also with bug reports and patches, so a big thank you from all us Wicket developers to all you folk out there in the community who are making this growth in interest both workable and sustainable.

Talking of explosions, there has been a staggering level of interest in community meet-ups. When Cemal and I founded the London Wicket User Group a few months back (next meeting Dec 5th) we both hoped the concept would take off elsewhere, so we’re happy to see the vast number of other groups forming across the globe, in a quite astonishing number of places: Antwerp, Amsterdam, Copenhagen, London, Minneapolis, Rio de Janeiro, Seattle, San Francisco, Stockholm, and also somewhere TBC in Austria. I’m surprised there’s not one in New York City yet. Come on guys! ;-)

The Amsterdam meet-up on November the 30th is looking particularly awesome (80 people registered interest, which will probably equate to 50+ people). The level of Wicket expertise gathered in one room will be unprecedented – get yourself along if you possibly can.

For more information, check out the wiki page: Apache Wicket community meet-ups.

Go Wicket!

• How many tools (i.e. IDE plugins) are available for your web framework?
• How many jobs are available for your framework on Dice.com? What about Indeed.com?
• How many messages where [sic] posted to your user mailing list (or forum) in March 2007?
• How many books are available for your framework?

What on earth does he intend to do with them, I wonder? All of these numbers superficially look like they should be “more is better”. On second glance, they’re anything but:

• If you have lots of IDE tooling available, it probably means the configuration for the framework is overly complex and unmanageable without it.
• The framework with the largest number of jobs available is probably Struts 1. Enough said.
• People only post to user lists when they are stuck. If the framework is hard to use, there will be lots of e-mails. If it has a steep learning curve, and/or the documentation is poor, this will be particularly so. On the other hand, an active list might point to a large active user base. Who knows which is which from a raw figure? It might be better to find the number of posters, not the number of messages.
• If your framework is fairly stable, and someone has written a fabulous tome on it that is universally acknowledged as “the bible”, few people would bother writing another book for it. Niche books usually only get written if there is no book currently in that space or if the existing books are rubbish and the author(s) think they can do better. How many books are written is therefore a function of the number written on the subject before a good one arrives, and how stable your framework is. The first is a small random number, probably. The second number is “more is worse”, assuming you don’t like frameworks that change under you all the time.

So, I guess I’m curious what extrapolations Matt intends to make from these figures. ;-)

– UPDATE –
Bob Lee has a different way of doing this.

Particularly tedious are HTTP sessions that refuse to serialize. In Wicket we store detached components in the session between requests. If you run a clustered app-server with session replication and add objects to your components that don’t implement Serializable, you’re toast. To avoid you deploying something with this issue and getting fired, we have a setting in development mode that tries to serialize the session on every page request. Unfortunately, although it helps you spot this problem early, it’s lumbered with the same unhelpful java.io.NotSerializableException as everything else in the world.

How do we make these issues easier to debug? Well, I’ve just written an ObjectOutputStream subclass which produces output like this:

java.lang.RuntimeException: Unable to serialize class: com.foo.C
Field hierarchy is:
  Class com.foo.A
    public com.foo.B myFieldForB
      public com.foo.C myFieldForC <----- field that is not serializable
	at DebuggingObjectOutputStream.writeObjectOverride(DebuggingObjectOutputStream.java:105)
	at DebuggingObjectOutputStream.writeObjectOverride(DebuggingObjectOutputStream.java:96)
	at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:298)
	at DebuggingObjectOutputStream.main(DebuggingObjectOutputStream.java:28)
Caused by: java.io.NotSerializableException: com.foo.C
	... 4 more

Eelco is going to plumb this into our Wicket session serialization debug check so we have much sweeter output for these problems in future. Nice! :-)

Here's the code:

import java.io.IOException;
import java.io.NotSerializableException;
import java.io.ObjectOutputStream;
import java.io.Serializable;
import java.lang.reflect.Field;
import java.lang.reflect.Modifier;
import java.util.HashSet;
import java.util.LinkedList;
 
public class DebuggingObjectOutputStream extends ObjectOutputStream {
 
  private static final long serialVersionUID = 1L;
 
  private LinkedList stack = new LinkedList();
  private HashSet set = new HashSet();
 
  public DebuggingObjectOutputStream() throws IOException {}
 
  @Override
  protected final void writeObjectOverride(Object obj) throws IOException {
    // Check for circular reference.
    if (set.contains(obj)) {
      return;
    }
    if (stack.isEmpty()) {
      stack.add("Class " + obj.getClass().getName());
    }
    set.add(obj);
    Field[] fields = obj.getClass().getFields();
    for (int i = 0; i < fields.length; i++) {
      StringBuffer buffer = new StringBuffer();
      Field f = fields[i];
      int m = f.getModifiers();
      if (fields[i].getType().isPrimitive() || Modifier.isTransient(m) ||
          Modifier.isStatic(m)) {
        continue;
      }
 
      if (Modifier.isPrivate(m)) {
        buffer.append("private ");
      }
      if (Modifier.isProtected(m)) {
        buffer.append("protected ");
      }
      if (Modifier.isPublic(m)) {
        buffer.append("public ");
      }
      if (Modifier.isFinal(m)) {
        buffer.append("final ");
      }
      if (Modifier.isVolatile(m)) {
        buffer.append("volatile ");
      }
      buffer.append(f.getType().getName()).append("");
      buffer.append(" ").append(f.getName());
      stack.add(buffer.toString());
      if (Serializable.class.isAssignableFrom(fields[i].getType())) {
        try {
          writeObjectOverride(fields[i].get(obj));
        }
        catch (IllegalAccessException e) {
          throw new RuntimeException(
              getPrettyPrintedStack(fields[i].getType().getName()), e);
        }
      }
 
      else {
        throw new RuntimeException(
            getPrettyPrintedStack(fields[i].getType().getName()).toString(),
            new NotSerializableException(fields[i].getType().getName())
        );
      }
      stack.removeLast();
    }
    if (stack.size() == 1) {
      set.clear();
      stack.removeLast();
    }
  }
 
  private String getPrettyPrintedStack(String type) {
    set.clear();
    StringBuffer result = new StringBuffer();
    StringBuffer spaces = new StringBuffer();
    result.append("Unable to serialize class: ");
    result.append(type);
    result.append("\nField hierarchy is:");
    while (!stack.isEmpty()) {
      spaces.append("  ");
      result.append("\n").append(spaces).append(stack.removeFirst());
    }
    result.append(" <----- field that is not serializable");
    return result.toString();
  }
}

:-)