Hi Aaron, This is great, it all sounds great to me, but before I dig into the code, I am wondering if you could commit this change into the jpa work repo. ( http://github.com/jeffyu/ode/tree/jpa), as I've already added your account (aaronanderson) as the collaborator, you should be able to push the commit into repo.
Below are the instructions on how to do the merge. (Thanks Rafal for telling me this, I am also quite new to git. :)) In your project directory, run: git fetch g...@github.com:jeffyu/ode.git jpa:jeff_jpa then from jeff_jpa, git merge jpa (you may need to resolve some conflicts if any). then you can push merged local branch to the repo: git push g...@github.com:jeffyu/ode.git jeff_jpa:jpa Let me know if you have problems on this.. I will look into your code tomorrow and then provide more comments. Thanks for your great work. ;) Regards Jeff On Mon, Mar 8, 2010 at 3:28 PM, Aaron Anderson <aaronander...@acm.org>wrote: > Hi Jeff, > > I committed my changes to my github fork at > http://github.com/aaronanderson/ode/tree/jpa Please take a look at it and > let me know what you think. Here are some notes on what I did: > > 1) Moved the bpel-store DAO interfaces, JPA, and hibernate classes into > their respective modules > 2) Updated the DAO package names to divide the DAO interfaces in a > consistent fashion > 3) Introduced the DAOConnectionFactory interface to use a common DAO > factory instantiation pattern across implementations. > 4) Moved all the DAO test cases to a new single module, dao-test. This > artifact is extracted to each of the three DAO implementation (hibernate, > hibernate JPA, and OpenJPA) at test time. This allows for good test case > coverage for each of the implementations without unit test redundancy. > Instead of introducing a new module these test cases could be moved to > bpel-dao and a maven test classifer used to archive them instead. > 5) All the test cases pass except for a couple of DAO tests for both > hibernate and hibernate JPA. Engine passes all the tests with OpenJPA. I'll > look into the two failed test cases early this week > 6) I have not run the hibernate DAO implementations with the engine yet but > I did not need to tweak too many of the JPA classes in order for it to load > in Hibernate 3.4.0GA. > 6) I can get started on moving the simple scheduler DAO code into the > implementation modules once the JPA changes stabilize. > > Please take a look and let me know what you think. I am new to git so if > you would like to accept any of these changes I may need some pointers on > how to merge them in with your repository. > > Cheers, > > Aaron > > > > > > > ________________________________ > From: Jeff Yu <jeff.yuch...@gmail.com> > To: dev@ode.apache.org > Sent: Thu, March 4, 2010 11:26:50 PM > Subject: Re: JPA DAO refactoring. > > 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 > -- Cheers, Jeff Yu ---------------- blog: http://jeff.familyyu.net
