Here Be BeastiesAlastair Maw’s small soap box.

Ever had a java.io.NotSerializableException in your code and found it very hard to debug? The JVM stack trace is nearly useless, telling you which code triggered the serialization, but not what it is trying to serialize.

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

Continue reading java.io.NotSerializableException in your HttpSession »

The upcoming Wicket 1.3 and 2.0 versions intercept their requests using a servlet filter to provide more flexible resource mapping and nicer URLs. Your Wicket pages no longer need to live at foo.com/app/PageName and can instead be rooted properly at foo.com/PageName.

This is now working well. I did, however, come up against a small issue, which is how you serve custom error pages for your 404 or 500 responses. It’s nice to render these like any other pages, so you can use your branding and whatnot. This used to work fine with Wicket as a servlet, but switching to a filter broke things. I did some digging around before reading the servlet spec in more detail and finally realising you need a Servlet 2.4 spec container and web.xml config file, with some <dispatcher> elements in your filter mapping.
Continue reading Using a servlet filter for 404 error-page »