Hi Sander > 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.
Does Wicket not manage your connections via DataSources, like a J2EE container? Then you shouldn't need to worry about connections yourself... J2EE containers usually have a shared connection pool for these purposes, but I don't know Wicket. > 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? I'm sorry I forgot about that. I'll add a 1.6.0-SNAPSHOT version soon, implementing this. I prefer attaching (if possible) at deserialisation time, because some advanced data types (especially with Oracle) need an open connection to be constructed. But there shouldn't be any drawback in handling the other case, too. https://sourceforge.net/apps/trac/jooq/ticket/535 > 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 Thank you for mentioning this. I keep forgetting about Netbeans. It seems that Eclipse, Netbeans and Maven don't have exactly the same compiler behaviour when overloaded generic methods are involved, when <T> binds to Object. This is a rather complex topic. In the mean time, you could try with Eclipse...? Cheers Lukas
