Hi Aaron, Yeah, lets try to put it into the OpenJPA DAO moudle first, and then think about the other way.
BTW, I didn't see you commit logs on your repo, was thinking that I will add you as a collaborator in the github's jpa work repository. Regards Jeff On Fri, Mar 5, 2010 at 4:37 AM, Aaron Anderson <aaronander...@acm.org>wrote: > 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 > -- Cheers, Jeff Yu ---------------- blog: http://jeff.familyyu.net
