Hello Sergey,

I have merged your suggestions for
- https://sourceforge.net/apps/trac/jooq/ticket/898 (unchecked exceptions)
- https://sourceforge.net/apps/trac/jooq/ticket/899 (OSGI bundling)

The changes are being uploaded to SVN and GitHub

And I'll be doing this one in the next days
- https://sourceforge.net/apps/trac/jooq/ticket/897 (Spring integration)

I have slightly modified your suggestions:

- The unchecked DataAccessException is now always formally declared in
method signatures, and documented in Javadocs. I think that's cleaner.
But I really do like the fact of it being unchecked.
- I moved the relevant Factory Javadoc up to FactoryOperations (not
sure about the name of that interface yet)
- Factory.fetch(ResultSet) is now also declared in FactoryOperations
(might've been forgotten)
- I removed the exception translator type for now, replacing it by a
static package-private method in JooqUtil, as this is incomplete. The
final API might differ, so I prefer not to change the API for now.
Maybe there is no need to expose that API.
- I changed all relevant methods in your Spring FactoryProxy (class
renamed) to being final. I tend to prefer that.

And I have some questions:

- How can I keep OSGI export/import instructions in synch with the
rest of the pom.xml's maven dependencies?
- What is the NativeJdbcExtractor useful for? Can you show me concrete examples?

Cheers
Lukas

2011/11/1 Lukas Eder <[email protected]>:
> Hello Sergey,
>
> I'll CC this to the user group as well, as this is probably of general 
> interest
>
>> Your code is great, very good impression.
>
> Thank you
>
>> I am trying integrate JooQ with Spring.
>> Let me explain a bit problems that I faced (very briefly, night).
>>
>> 1. JooQ Factory is not thread safe (because Connection is not thread safe)
>> - created project jOOQ-spring that contains thread safe Factory proxy.
>
> This would be a valuable extension, that might be useful to other
> users as well. I checked upon the proxy. I'm not too familiar with
> Spring for managing data sources. I imagine, that transactions are
> somehow maintained outside of this proxy? What would some sample
> service code look like?
>
> I'll add Spring integration as a feature request:
> https://sourceforge.net/apps/trac/jooq/ticket/897
>
>> - added interface FactoryOperations in jOOQ project,  that declares
>> non-static public operations in Factory class
>> - added setters to SchemaMapping class (to simplify injecting configuration
>> parameters in spring configuration)
>
> That makes sense.
>
>> 2. some JooQ Factory methods return SQLException (this is checked exception)
>> - SQLException removed from method signature, operations return runtime
>> DataAccessException instead of checked SQLException
>> This exception is the same as DataAccessException in Spring
>> http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/dao/DataAccessException.html
>> 3. no abstraction in SQLException handling (different databases have
>> different errorCodes)
>> - added SQLExceptionTranslator
>> The idea is to map vendor-specific error codes to DataAccessException
>> descendants
>> http://www.koders.com/xml/fidE70F96602F7F254B935C711E60F1D141C60CD1DB.aspx
>> Implementation is very simple (just stub) at this moment. (todo)
>
> That's a nice concept. I wasn't aware of this. This will be feature
> request #898:
> https://sourceforge.net/apps/trac/jooq/ticket/898
>
>> 4. jars can not be deployed into OSGI environment (jar's are not bundles)
>> - added configuration of maven-bundle-plugin to pom.xml
>
> Is that what org.apache.felix does? Thanks for adding this. It will be
> included with
> https://sourceforge.net/apps/trac/jooq/ticket/899
>
>> Preliminary version of these changes in attachment. I am not sure that all
>> these changes are correct.
>> Suppose that these changes are important.
>
> Release 2.0 is the right time for such changes. Thanks a lot for your help!
>
> Cheers
> Lukas
>
> 2011/11/1 Sergey Epik <[email protected]>:
>> Hi Lukas,
>>
>> Your code is great, very good impression.
>> I am trying integrate JooQ with Spring.
>> Let me explain a bit problems that I faced (very briefly, night).
>>
>> 1. JooQ Factory is not thread safe (because Connection is not thread safe)
>> - created project jOOQ-spring that contains thread safe Factory proxy.
>> - added interface FactoryOperations in jOOQ project,  that declares
>> non-static public operations in Factory class
>> - added setters to SchemaMapping class (to simplify injecting configuration
>> parameters in spring configuration)
>> Here is example of spring configuration:
>>
>>
>>     <bean id="jooQFactoryProxy" class="org.jooq.spring.JooQFactoryProxy">
>>         <property name="dataSource" ref="dataSource"/>
>>         <property name="schemaMapping">
>>             <bean class="org.jooq.SchemaMapping">
>>                 <property name="defaultSchema" value="PROJ_${app.schema}"/>
>>                 <property name="schemaMapping">
>>                     <map>
>>                         <entry key="PROJ_AA" value="PROJ_AA_${app.schema}"/>
>>                     </map>
>>                 </property>
>>             </bean>
>>         </property>
>>         <property name="dialect">
>>             <value type="org.jooq.SQLDialect">ORACLE</value>
>>         </property>
>>     </bean>
>>
>> inject it into the service:
>>
>>     <bean id="fooService" class="com.example.FooServiceImpl">
>>         <property name="jooQ" ref="jooQFactoryProxy"/>
>>     </bean>
>>
>> 2. some JooQ Factory methods return SQLException (this is checked exception)
>> - SQLException removed from method signature, operations return runtime
>> DataAccessException instead of checked SQLException
>> This exception is the same as DataAccessException in Spring
>> http://static.springsource.org/spring/docs/3.0.x/javadoc-api/org/springframework/dao/DataAccessException.html
>> 3. no abstraction in SQLException handling (different databases have
>> different errorCodes)
>> - added SQLExceptionTranslator
>> The idea is to map vendor-specific error codes to DataAccessException
>> descendants
>> http://www.koders.com/xml/fidE70F96602F7F254B935C711E60F1D141C60CD1DB.aspx
>> Implementation is very simple (just stub) at this moment. (todo)
>> 4. jars can not be deployed into OSGI environment (jar's are not bundles)
>> - added configuration of maven-bundle-plugin to pom.xml
>>
>> Preliminary version of these changes in attachment. I am not sure that all
>> these changes are correct.
>> Suppose that these changes are important.
>>
>> Best regards,
>> Sergey
>>
>

Reply via email to