Hi Sergey > This solution works.
I will integrate it into jOOQ for now. In the mean time, that particular answer was deleted again on Stack Overflow. It seems that using context class loaders is a sign of bad design (yet not as bad as using Class.forName()) See the updated question here: http://stackoverflow.com/questions/11483993/is-there-an-alternative-to-loading-a-class-with-class-forname I will keep these things in mind when implementing jOOQ 3.0. So far, I like your approach best, where ExecuteListener *instances* (not *classes*) can be injected into a Configuration. With jOOQ 3.0's separation of Configuration / Factory, things will get much cleaner. I'll also consider Aaron Digulla's suggestion about having what we now call "Settings" to be the default "Configuration" if not overridden programmatically. > Please pay attention that we should not keep classes in > static field. > I mean > > private static final Map<String, Class<?>> EXECUTE_LISTENERS = new > ConcurrentHashMap<String, Class<?>>(); > > in Util. > > If we "restart" osgi bundle with listener implementation, EXECUTE_LISTENERS > will contain outdated classes. I see. I guess that this cache causes more problems than it resolves. The overhead from loading one class per listener per query should be negligible, so I can safely remove this micro-optimisation. The two issues will be resolved with #1572: https://sourceforge.net/apps/trac/jooq/ticket/1572 - Usage of the context class loader - Removal of the class cache > I missed that ExecutionLister is created for each request (in this case more > correct is to inject into "Configuration" some kind of > ExecutionListenerFactory instance). You're probably right. The current lifecycle may not be intuitive. This will be obsolete in jOOQ 3.0, though, when you can inject instances into "Configuration", rather than classes into "Settings". > We use ExecutionListener as exception translator (it maps Oracle exceptions > ORA-xxx to java application-specific exceptions). > I see no reason why it should be instantiated and configured by jOOQ (and > per request). The only reason is the fact that at some point I've decided to allow for XML configuration of "Settings" and thus, ExecuteListeners. Using JAXB to load that XML file, it wasn't possible to actually load instances. Hence, the current design. > You can remove EXECUTE_LISTENERS and instantiate using > Thread.currentThread().getContextClassLoader().loadClass, > but I can not recommend this solution. Nope. Let's live with it until jOOQ 3.0, though. > Thank you for introducing ExecutionListener and runtime exceptions. You're welcome!
