Fix all projects using GenericDao in shared
Description
Environment
Test Plan
is duplicated by
relates to
Activity
Aaron Zeckoski August 14, 2008 at 4:46 PM
We did this for evaluation:
https://source.sakaiproject.org/contrib/evaluation/trunk/api/src/java/org/sakaiproject/evaluation/dao/EvalDaoInvoker.java
Not saying it is perfect but it seemed reasonable
Jim Eng August 14, 2008 at 4:33 PMEdited
Fixed the Sakaibrary SRG project () but I'm having trouble with Textbook (). Textbook has a class ModelAccessWrapperInvoker, which implements RunnableInvoker. Is there an example of how that interacts with the changes described above to make the DAO available in the ModelAccessWrapperInvoker class (which is in the tool module) when the DAO is no longer defined in the API? I think it involves definition of an interface in the API with a method to invoke a transaction, and the impl has a DAO object injected. Then the ModelAccessWrapperInvoker can have a member variable of that type that gives access to the DAO. Any suggestions?
Aaron Zeckoski July 22, 2008 at 1:43 AM
If you need to work on a projects and want to record the changes against a JIRA, feel free to use this one or create a subtask on this issue and use that one.
Any projects being considered for use in 2.5.x or trunk need to ensure they are using generic-dao inside their project and not as a jar in shared.
Generic-DAO should be placed into the impl (component or webapp) rather than in shared for all projects that are using it. This is possible by simply moving the jar (adjusting the POM/project.xml) so that it is not deployed in shared, moving the dao interface into the service impl, and changing the spring transaction bean over to the helper bean in gendao. I am happy to handle this conversion for those who are using it or I can explain how to do it in more detail. -AZ
This should be done to reduce the dependencies in shared and to allow projects to deploy whatever version of gendao that they want. It is also required to avoid conflicts with projects that want to use different versions.
Here are the steps to switch a project from using gendao in shared to packaging it in the component/webapp impl only in detail:
1) Move the DAO api from being deployed to shared/lib to being part of the impl (component if you have one, or webapp if you don't), in eclipse this is as easy as drag and drop, eclipse will handle the refactor
2) Update the gendao dependency to look like this in your impl pom.xml:
<dependency>
<groupId>org.sakaiproject</groupId>
<artifactId>generic-dao</artifactId>
<version>[0.9.8,1.0)</version>
</dependency>
3) Remove the gendao dependency from the pom.xml for your api and the other parts which deploy to shared/lib, make sure that gendao is not mentioned in any other pom.xml files
4) Update the transactional wrapper to use one of the new classloader specific ones in gendao utils:
A) From org.springframework.transaction.interceptor.TransactionProxyFactoryBean to:
<bean id="org.sakaiproject.entitybroker.dao.EntityBrokerDao"
class="org.sakaiproject.genericdao.springutil.CurrentClassLoaderTxProxyFactoryBean">
...
OR
B) From org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator to:
<bean class="org.sakaiproject.genericdao.springutil.CurrentClassLoaderBeanNameAutoProxyCreator">
...
That should be all that is required. Note that once this conversion is done, attempting to use hibernate with gendao while still having gendao in shared will cause a failure in the tool. This is why this needs to happen relatively quickly and syncronously for all tools involved. On the other hand, leaving gendao in shared will cause any tools needing a new version or using the new correct method to also fail.