Hi Aaron, I've just committed your changes into my repository, it is at: http://github.com/jeffyu/ode/commit/a5ba9bbb0c6f49db60c29109845beacbef3a17de I've resolved the conflicts files, all of them are pom files, could you have a look at it to see if I am missing some changes or not.
Also, I've updated the JPADaoOperator.java to JPADAOOperator.java, otherwise the filename and the classname is inconsistent. Regards Jeff On Mon, Mar 8, 2010 at 11:36 PM, Jeff Yu <jeff.yuch...@gmail.com> wrote: > 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 > > -- Cheers, Jeff Yu ---------------- blog: http://jeff.familyyu.net
