One danger of adding cglib to your classpath is that lazy objects created by iBATIS will be harder to serialize. An example of serialization of "lazy" objects given by Paul here. http://opensource.atlassian.com/confluence/oss/display/IBATIS/Lazy+loadi ng+issues Beside this problem, I don't see anything else that could cause a problem. Christian
________________________________ From: Meindert [mailto:[EMAIL PROTECTED] Sent: Monday, 16 April 2007 04:32 To: [email protected] Subject: RE: converting iBATIS framework DAOs to the Spring Framework Hi Chris, I did see that in the error message :-). Do you have any additional information about why would I need to add CGLIB to enable transactions? It does give that kind io info on the Project Information; It is used by AOP, testing, data access frameworks to generate dynamic proxy objects and intercept field access. Was just wondering if there any dangers or problems if I include this library? Should I maybe rather instead of 'generate dynamic proxy objects' rather add the proxy interface. That said I don't have a clue what it that means.. I assume I've got to add something to the spring config file? Sorry about all the questions, but would like to do this simple and right. Kind Regards Meindert ________________________________ From: Poitras Christian [mailto:[EMAIL PROTECTED] Sent: 13 April 2007 06:08 PM To: [email protected] Subject: RE: converting iBATIS framework DAOs to the Spring Framework Download CGLIB (at least version 2.1.3) http://sourceforge.net/project/showfiles.php?group_id=56933 Christian ________________________________ From: Meindert [mailto:[EMAIL PROTECTED] Sent: Friday, 13 April 2007 12:03 To: [email protected]; [EMAIL PROTECTED] Subject: RE: converting iBATIS framework DAOs to the Spring Framework Hi All, I had a look at spring transactions and can get the annotation working for the dao layer but not for the service layer? This is the xml I added in the spring config file to enable spring annotations (Java1.5+ required), <!-- TRANSACTIONS --> <bean id="txManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager" > <property name="dataSource"> <ref bean="dataSource"/> </property> </bean> <bean class="org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoPro xyCreator"/> <bean class="org.springframework.transaction.interceptor.TransactionAttributeS ourceAdvisor"> <property name="transactionInterceptor" ref="txInterceptor"/> </bean> <bean id="txInterceptor" class="org.springframework.transaction.interceptor.TransactionIntercepto r"> <property name="transactionManager" ref="txManager"/> <property name="transactionAttributeSource"> <bean class="org.springframework.transaction.annotation.AnnotationTransactionA ttributeSource"/> </property> </bean> Step 2, Tested it on the dao layer by modifying updateAccount @Transactional public void updateAccount(Account account) { update("updateAccount", account); int i = 5/0; //division by zero, expect rollback of account changes update("updateProfile", account); } This works! But if I move the annotation to the service layer like this @Transactional public void updateAccount(Account account) { accountDao.updateAccount(account); } I get org.springframework.aop.framework.AopConfigException: Cannot proxy target class because CGLIB2 is not available. Add CGLIB to the class path or specify proxy interfaces. Kind Regards Meindert -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Larry Meadors Sent: 12 April 2007 04:14 PM To: [email protected] Subject: Re: converting iBATIS framework DAOs to the Spring Framework Thanks a TON for doing this, it's really appreciated! Here is the WIKI Page: http://tinyurl.com/ysvjw5 I just converted it to WIKI format and corrected some simple stuff. I was curious why if we are starting with jpetshop5, why not use the hsqldb stuff that is there? Also, I'd suggest that we use constructor injection instead of setter injection - that way, we only need to remove the default constructors from the service classes (eg., public AccountService() {...}, and the related imports. It also prevents people from replacing the dao instances (well, not entirely, but they have to do a bit more work). Larry
