Hi Lukas, Thank you for adding this functionality to jOOQ!
I've been experimenting with it all day. Unfortunately, i haven't been able to get this to work as intended with Wicket yet. As far as i can see, the problem is not with jOOQ but with Wicket and my failure to understand the exact way Wicket handles serialization. It turns out that, although Wicket *does* serialize pages and their associated objects after each http request, it does NOT always deserialize them on the next request. In fact, it keeps an in-memory cache of the last few pages. Because i disconnect JDBC connections at the end of each HTTP request cycle to prevent them from 'leaking', this means that i end up with jOOQ objects that have references to disconnected JDBC connections. Since the jOOQ objects do not get deserialized, ConfigurationRegistry is not being called at all. Unfortunately, there's no (easy) way to force Wicket to disable the in- memory cache and to always use deserialization. I'm still trying to find a way to do this for this, but i'm affraid that even if i find a way, this will have a negative impact on the performance of the application. I was wondering if it would be possible to call the ConfigurationProvider.provideFor method just before query execution (when a jOOQ object is detached OR the associated JDBC connection is disconnected) instead of in readObject? slightly off-topic: i tried to download the jOOQ source myself (both the current trunk version and r905, which is in fact release 1.5.9 according to the subversion comments) to experiment with these kind of things, but i get this error when i try to compile it (maven in Netbeans): org/jooq/impl/InsertImpl.java:[109,20] reference to addValue is ambiguous, both method <T>addValue(org.jooq.Field<T>,T) in org.jooq.StoreQuery<R> and method <T>addValue(org.jooq.Field<T>,org.jooq.Field<T>) in org.jooq.StoreQuery<R> match Sander
