I’ve managed to get something working right now. It’s not completely tested but it should work quite well. What I’m doing is the following: I parse the charset files of MySQL (on an Ubuntu system, you can find them in /usr/share/mysql/charsets/) and do the collation based on those files myself rather than using Java’s built-in collations.

EDIT: I’ve just created a github project that’s available as a Maven artifact from Sonatype’s OSS repository.

public final Object writeReplace() throws ObjectStreamException {
  if (isTransient(this)) {
    return this;
  } else {
    return new ReplaceHolder(getClass(), getId());
  }
}

The ReplaceHolder – isn’t it a lovely name? – is responsible for replacing itself with the persistent object we didn’t want to serialize before:

public static final class ReplaceHolder implements Serializable {
 
  private static final long serialVersionUID = 1L;
 
  private final String _entityName;
  private final Serializable _id;
 
  public ReplaceHolder(final Class entity, final Serializable id) {
    _entityName = entity.getName();
    _id = id;
  }
 
  public Serializable getId() {
    return _id;
  }
 
  @SuppressWarnings("unchecked")
  public Class getEntity() throws ClassNotFoundException {
    return (Class) Class.forName(_entityName);
  }
 
  public final Object readResolve() throws ObjectStreamException {
    try {
      return loadEntity(getEntity(), getId());
    } catch (final ClassNotFoundException e) {
      throw new InvalidClassException(_entityName, e.getClass().getSimpleName() + ": " + e.getMessage());
    }
  }
}

And that’s it. Well, not completely, but see the attached .java file for details.

There is only one thing Wicket developers have to be aware of. Objects aren’t serialized between requests – don’t confuse it with model detaching. If I remember correctly, there is always one page kept detached but un-serialized. So if one would like to use the serialization, one has to make sure, that the objects are already serialized as soon as the models are detached. For this purpose, I implemented a special Model, that serializes its object on detach:

public void detach() {
  if (_object != null) {
    try {
      final ByteArrayOutputStream bs = new ByteArrayOutputStream();
      new ObjectOutputStream(bs).writeObject(_object);
      _bytes = bs.toByteArray();
      _object = null;
    } catch (final IOException e) {
      throw new WicketRuntimeException(e);
    }
  }
}

You might say that this feels like a hack – at least that’s what I think of it But it works perfectly, especially for complex forms where you add persistent objects to transient ones. Furthermore, you make sure that you’ll never serialize a huge persistent object graph into your Wicket session, which definetely is a Bad Thing ™.


org.hibernate.LazyInitializationException - could not initialize proxy - the owning Session was closed
org.hibernate.LazyInitializationException: could not initialize proxy - the owning Session was closed


the problem

Generally, detached objects in Hibernate are a bad thing when it comes to reusing objects between web-requests. Detached objects are objects that have been persistent but are not attached to a Hibernate session. They’re easily produced but can be a mess if it comes to Lazy-Loading or updating them. Just consider the following case


Foo foo = _myDAO.getFoo(); // attached object

  }
}


the solution

First be sure to use the OpenSessionInViewFilter sothat a new hibernate session is opened when the request gets attached and closed when it gets detached.

Then the solution of course is a to use a LoadableDetachableModel that gets a fresh instance from the persistence-layer on each request. Could look like that:


IModel fooModel = new LoadableDetachableModel() {

  }
}


the improvement

LoadableDetachableModels are a nice thing but it’s quite a lot of work to inject your DAO (or service) and then create a new LDM for each of your objects in each and every one of your panels. so we came up with a more generic version of the LoadableDetachableModel. First, let your model-objects implement an Interface, say IPersistentObject with the single method


  Serializable getId();


As your object are likely to have a primary key named id it’ll be no problem anyway. Then create the following class:


public class PersistentObjectModel extends LoadableDetachableModel {

}


This makes working with hibernate objects really easy. There are two options:

1. Use the object e.g.

   setModel(new PersistentObjectModel(foo));

2. Use only class and id.

   This might happen e.g. if you pass your id using PageParameters (but better encrypt it )
   setModel(new PersistentObjectModel(Foo.class, 1));

Hope that saved you some time writing boilerplate code have fun

org.hibernate.type.SerializationException: could not deserialize
at org.hibernate.util.SerializationHelper.deserialize(SerializationHelper.java:217)
at org.hibernate.util.SerializationHelper.deserialize(SerializationHelper.java:240)
at org.hibernate.type.SerializableType.fromBytes(SerializableType.java:82)
at org.hibernate.type.SerializableType.get(SerializableType.java:39)
at org.hibernate.type.NullableType.nullSafeGet(NullableType.java:163)
at org.hibernate.type.NullableType.nullSafeGet(NullableType.java:154)
…..

I even got this one as cause:

Caused by: java.io.EOFException
at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2279)
at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2748)
at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780)
at java.io.ObjectInputStream.(ObjectInputStream.java:280)
….

EOF? wtf? Don’t get too confused with that EOF, the solution was simply to add the type of the id in the mapping file.

Before:

<id name=”id”>
<generator class=”native”>
</id>

After:

<id name=”id” type=”integer”> <!– or long or string of whatever your hibernate type is –>
<generator class=”native”>
</id>


<dependency>
 <groupid>org.apache.wicket</groupid>
 <artifactid>wicket-jmx</artifactid>
 <version>1.3.0-SNAPSHOT</version>
</dependency>


But Wicket (more precisely Wicketstuff) also contains a simple JMX client called wicketstuff-jmx-panel. Using this client is as simple as adding a single component to whatever Wicket-page:

POM:

<repository>
 <id>wicket-stuff-repository</id>
 <name>Wicket-Stuff Repository</name>
 <url>http://www.wicketstuff.org/maven/repository</url>
</repository>
<!-- SNIP -->
<dependency>
 <groupid>org.wicketstuff</groupid>
 <artifactid>wicketstuff-jmx-panel</artifactid>
 <version>1.3.0-SNAPSHOT</version>
</dependency>


Java:


add(new JmxPanel("jmx"));


However, documentation on this JMX panel is sparse. It took me some time to figure out the following: This panel filters all MBeans that do not have the Wicket-application’s name in their domain. This behaviour may be changed using an annonymous inner class:


add(new JmxPanel("jmx") {
 protected IDomainFilter getDomainFilter() {
   return DOMAIN_FILTER;
}
});

 public boolean accept(String domain) {
   // your filter code
   return true;
}
};


It does make sense to filter out some MBeans as there are already some by default, e.g. for java.util.logging which you probably don’t use at all.

Now it’s time to add Hibernate’s statistics MBean. This MBean is can be used per SessionFactory. I therefore decided to do registration and unregistration together with SessionFactory creation. As I am also using Spring, I went for my own SessionFactoryBean:


public class MBeanRegisteringLocalSessionFactoryBean extends
   org.springframework.orm.hibernate3.LocalSessionFactoryBean {

 /* SNIP: getMBeanServer(), getSessionFactoryName(), setSessionFactoryName(String) */
}


I copied (sorry, there is no nicer way yet) the code for getMBeanServer() from wicket-jmx’s Initializer class (sorry, can’t find an online version – you can get the source using Maven) in order to get the exact same behaviour. Now you only need to replace LocalSessionFactoryBean with MBeanRegisteringLocalSessionFactoryBean in your beans.xml and you are set. In order to enable statistics by default, add these two lines to your hibernate properties:


hibernate.generate_statistics=true
hibernate.cache.use_structured_entries=true


That’s it! Hibernate statistics directly from your webapp: