Hi Sergey > 1. We can leave current approach and mark it as deprecated. > Jooq does not know which classloader should be used to load ExecuteListener > instance and how to configure it. > We should be able to instantiate and configure ExecuteListener instance and > after that inject it into the Factory. > The same approach is used in JdbcTemplate class (Spring framework). > We can inject both DataSource and SQLExceptionTranslator instances into > JdbcTemplate. > http://static.springsource.org/spring/docs/2.0.x/api/org/springframework/jdbc/support/JdbcAccessor.html#setExceptionTranslator%28org.springframework.jdbc.support.SQLExceptionTranslator%29
Yes, I understand that Spring has the advantage of being able to use Spring for configuration. Without assuming any dependencies though, jOOQ uses JAXB for loading generic XML configuration files. Thanks to your recent changes to jOOQ's XJC code generation, JAXB artefacts and Spring configurations are compatible. However, moving ExecuteListeners out of Settings would mean that other users could no longer use their XML files / JAXB, to configure jOOQ's ExecuteListener settings. I am not happy with the fact that the current solution actually loads classes. But I would like to keep the ExecuteListener property in Settings, somehow. The currently ongoing thread with Aaron Digulla also depicts that separation of concerns between Factory and Configuration should be improved. Moving another item to the Factory would be a step back in that evolution. Another constraint that I would prefer not to be broken: The ExecuteListener object lifecycle is the same as that of a query execution. An ExecuteListener is allowed to contain state, which it may share between events. E.g. a state can be produced at the renderStart() event, and consumed at the renderEnd() event. Your solution would imply that ExecuteListeners were allowed to live longer than that, which introduces the risk of stale state between subsequent executions of queries. Anyone from the group, please participate. Do you see a solution solving Sergey's classloading problem while preserving compatibility as much as possible? > 2. I like idea to use DataSourceConnection, DataSourcePreparedCall, > DataSourcePreparedStatement etc. classes to close connection received from > DataSource. It is pretty elegant and works fine. I suppose it's safe to > remove FactoryProxy in 2.4. Thanks for the feedback. FactoryProxy will be removed in jOOQ 3.0 > The only questions was why you decided to use wrappers instead of proxies > (from java.lang.reflect package). That is a nice hint. I hadn't explored that possibility. Specifically, DataSourceConnection exposes getDataSource() to DataSourceStatement, in order for the latter to detect whether the underlying Connection needs to be closed. But I guess that could be done with proxies as well. I'll put this idea on the roadmap for future consideration: #1538 https://sourceforge.net/apps/trac/jooq/ticket/1538 Cheers Lukas 2012/7/5 Sergey Epik <[email protected]>: > Hello Lukas, > > > On Thu, Jul 5, 2012 at 8:55 PM, Lukas Eder <[email protected]> wrote: >> >> Hi Sergey, >> >> I've had a closer look to your suggested contribution. This would >> break existing API where ExecuteListeners are registered in Settings, >> with the possibility of loading ExecuteListener configuration from an >> XML configuration file. Settings is the right place for >> ExecuteListeners. >> >> Do you see any other solution that would remain compatible? > > > 1. We can leave current approach and mark it as deprecated. > Jooq does not know which classloader should be used to load ExecuteListener > instance and how to configure it. > We should be able to instantiate and configure ExecuteListener instance and > after that inject it into the Factory. > The same approach is used in JdbcTemplate class (Spring framework). > We can inject both DataSource and SQLExceptionTranslator instances into > JdbcTemplate. > http://static.springsource.org/spring/docs/2.0.x/api/org/springframework/jdbc/support/JdbcAccessor.html#setExceptionTranslator%28org.springframework.jdbc.support.SQLExceptionTranslator%29 > > 2. I like idea to use DataSourceConnection, DataSourcePreparedCall, > DataSourcePreparedStatement etc. classes to close connection received from > DataSource. It is pretty elegant and works fine. I suppose it's safe to > remove FactoryProxy in 2.4. > > The only questions was why you decided to use wrappers instead of proxies > (from java.lang.reflect package). > It's more simple to define InvocationHadler that intercepts "close" method > and does all stuff. > We should not implement JDBC interfaces in this case and are more protected > from JDBC changes. > Here is example, how Spring framework creates Connection proxy and > intercepts "close" method: > http://www.docjar.com/html/api/org/springframework/jdbc/datasource/TransactionAwareDataSourceProxy.java.html > Look at the method getTransactionAwareConnectionProxy. > > -- > Best regards, > Sergey Epik
