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.
I'm still evaluating options regarding this issue here. Options proposed so far would have a major impact on the API strategy (meaning of Configuration / Settings), so I'd like to avoid them in a minor release. I've asked a question on Stack Overflow to see if there are alternatives: http://stackoverflow.com/questions/11483993/is-there-an-alternative-to-loading-a-class-with-class-forname 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
