Hi Jeff, Thanks for the response!
For question #2, I errantly used the term class annotation instead of class enhancement. The challenge I encountered was trying to acheive the goal of reusing the same JPA entities across persistence providers while also somehow addressing the differences between the class enhancement behaviors of hibernate and OpenJPA. Hibernate utilizes a byte code manipulator at runtime to augment the JPA entites so I had no problems with it. OpenJPA on the other hand requires the JPA entity classes to be enhanced with OpenJPA specific class references or there must be an OpenJPA agent to augment the classes at runtime. Using the OpenJPA enhancer means that there must be two separate versions of the JPA entity compiled classes: a non-manipulated version and an OpenJPA enhanced version. I used a maven classifer to set them appart but it would be possible to include the OpenJPA enhanced classes in the OpenJPA DAO module. Maybe when I am done with shuffling around the code I can investigate to see if there is a way to enable the OpenJPA agent at runtime programatically so it behaves more like Hibernate. Regards, Aaron ________________________________ From: Jeff Yu <jeff.yuch...@gmail.com> To: dev@ode.apache.org Sent: Thu, March 4, 2010 12:22:14 AM Subject: Re: JPA DAO refactoring. Hi Aaron, Firstly, we are very glad that you made progress on this, and interested in contributing your effort in this area. ;) comments inline. On Thu, Mar 4, 2010 at 2:02 PM, Jeff Yu <jeff.yuch...@gmail.com> wrote: > Quote from Aaron's comments of JIRA. ( > https://issues.apache.org/jira/browse/ODE-704) > > Hi Jeff, > > Thanks for the pointers on helping me get started on this task. I have > setup a github project and created a fork of your JPA branch. I have made > some progress with separating the JPA and hibernate code apart based on your > initial effort and I also have started to attempt to unify the JPA DAO > patterns used in the DAO and bpel-store modules. I had a few questions and I > was hoping you could provide me some guidance on them. > > 1) Maven modules - To prevent module proliferation I was thinking that the > DAO, store, and scheduler implementations could be stored in the same module > per implementation. For example, > > ode-dao - contains new generic DAO ConnectionFactory interface(s) and the > existing core DAOConnection interfaces > dao-jpa - contains all the JPA entities, including dao, store, and soon to > be scheduler. The store and scheduler implementations would still be in > different packages and persistence units. > dao-hibernate - contains all the hibernate entities, including dao, store, > and soon to be scheduler. Includes factory implementation classes that > implement generic interfaces in ode-dao > dao-jpa-ojpa - contains factory implementation classes that implement > generic interfaces in ode-dao. The factory primes the JPA environment with > the the openjpa specific properties > dao-jpa-hibernate - same as dao-jpa-ojpa but for hibernate > bpel-store - contains factory implementation classes that implement generic > interfaces in ode-dao and the existing store connection code. > bpel-scheduler-simple - the same as bpel-store with new connection based > DAO > il-common - OdeConfigProperties updated to include new factory class > lookups for the store and scheduler implementations > > What do you think of this approach? > +1 to this. One comment, (just make sure. ;) ) for the ode-dao, we should put the store, and soon to be scheduler's DAO's Interfaces into this module. > > 2) OpenJPA class enhancements - OpenJPA requires that the classes be > annotated in order to be utilized unless a JavaEE container is used or their > runtime agent is utilized. The problem is that these class enhancements > would interfere with a different JPA implementations and duplicating the > entities per implementation module would lead to too much redundancy. To > address this I took the approach of extending the dao-jpa maven pom to > duplicate the target classes, run the enhancer on the copy, and then run the > maven-jar plugin again with a classifer of openjpa so that two versions of > the module will be stored in the maven repo. Is this a valid approach? > Sorry, I didn't see these openjpa's specific annotations in the code? With regard to the class enhancements, I was thinking that we run the enhance commands on the dao-jpa-ojpa module, so the dao-jpa module is all about standard JPA, no JPA's implementator's stuff. Does this approach make sense to you? > > 3) When examining the ode 2.0 source code I found a lot of references to > JDBC datasources and transaction managers in the DAO classes. To me the DAO > abstraction classes should be storage implementation agnostic. I would like > to refactor the connection interfaces to use the same interface and > introduce a common DAO strategy. > > //new common interface > public interface DAOConnectionFactory<C> { > > C getConnection(); > > <E> void init(OdeConfigProperties p, E envCtx); > > void shutdown(); > } > > //Module specific DAO access implementation (dao, store, scheduler, etc) > public interface BpelDAOConnectionFactory extends > DAOConnectionFactory<BpelDAOConnection> { > > BpelDAOConnection getConnection(); > > > } > > //Implementation specific factory that can be instantiated by the module > using an OdeConfigProperties lookup > public class BpelDAOConnectionFactoryJPAImpl implements > BpelDAOConnectionFactory { > > public BpelDAOConnection getConnection() { > return new BpelDAOConnectionJpaImpl(); > } > > public <JDBCContext>void init(OdeConfigProperties p, JDBCContext envCtx) > { > > } > > public void shutdown() { > > } > > } > > //This is a implementation specific environment context that the runtime > the ode is executed in can pass opaquely through the DAO layer into the > implementation. > public class JDBCContext { > > DataSource getDataSource(){} > TransactionManager getTransactionManager(){} > > } > > > What are your thoughts on this approach? > Yeah, +1, I like this idea. Regards Jeff > > Regards, > > Aaron > > -- > Cheers, > Jeff Yu > > ---------------- > blog: http://jeff.familyyu.net > > -- Cheers, Jeff Yu ---------------- blog: http://jeff.familyyu.net
