You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ode.apache.org by Jeff Yu <je...@gmail.com> on 2010/03/04 07:02:12 UTC
JPA DAO refactoring.
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?
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?
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?
Regards,
Aaron
--
Cheers,
Jeff Yu
----------------
blog: http://jeff.familyyu.net
Re: JPA DAO refactoring.
Posted by Jeff Yu <je...@gmail.com>.
Hi Aaron,
If we move the dao-test into bpel-test module, will we also run the
bpel-test test cases multiple times with different dao implementation?
With regard to the svn trunk change, I think we are good with it, as Apache
ODE also has a git repository, we pull changes from it into our own git repo
from time to time, and do the merge between branch. So it is not a lot of
work there.
Regards
Jeff
Regards
Jeff
On Wed, Mar 10, 2010 at 10:23 AM, Aaron Anderson <aa...@acm.org>wrote:
> Hi Jeff,
>
> Thanks for merging in the code! I had some laptop problems today (I will
> need to send it back for repairs again!) so I did not get a chance to do the
> merge myself. Working from the git repository is fine with me. I will work
> on finishing the refactoring of the code and I will get the rest of the unit
> tests passing again. After that I will take a look at merging in the svn
> trunk changes as well. Perhaps I will try the git svn rebase command to see
> if that can help automate some of the merges. I was also thinking about
> moving the dao-test module into the bpel-test one and then configuring the
> surefire plugin to run multiple times per dao implementation. This way most
> of the integration tests are centrally located in one module. What do you
> think?
>
> Cheers,
>
> Aaron
>
>
>
>
>
>
--
Cheers,
Jeff Yu
----------------
blog: http://jeff.familyyu.net
Re: JPA DAO refactoring.
Posted by Aaron Anderson <aa...@acm.org>.
Hi Jeff,
Thanks for merging in the code! I had some laptop problems today (I will need to send it back for repairs again!) so I did not get a chance to do the merge myself. Working from the git repository is fine with me. I will work on finishing the refactoring of the code and I will get the rest of the unit tests passing again. After that I will take a look at merging in the svn trunk changes as well. Perhaps I will try the git svn rebase command to see if that can help automate some of the merges. I was also thinking about moving the dao-test module into the bpel-test one and then configuring the surefire plugin to run multiple times per dao implementation. This way most of the integration tests are centrally located in one module. What do you think?
Cheers,
Aaron
________________________________
From: Jeff Yu <je...@gmail.com>
To: dev@ode.apache.org
Sent: Tue, March 9, 2010 2:40:29 AM
Subject: Re: JPA DAO refactoring.
Hi Aaron,
comments inline.
On Mon, Mar 8, 2010 at 3:28 PM, Aaron Anderson <aa...@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
>
+1, Now it looks much cleaner when I look into the bpel-store module, also
look into the bpel-store's dependency, no more dependencies on the impl,
great.
> 2) Updated the DAO package names to divide the DAO interfaces in a
> consistent fashion
>
+1
> 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.
>
I also agreed that we have a new module, as you did. It is cleaner than
having it in the bpel-dao module.
> 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
>
Great.
> 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.
>
+1.
I think at this stage, It is better that we make sure all of our changes
didn't broke the build, all of tests should passed etc, before we move to
refactor the scheduler DAO, it would be easy for us to find the problem,
what do you think?
As of now, I see following issues or tasks that we need to do.
1. It seems to me that we haven't refactored the axis2-war test case code,
as it still refers to the org.apache.ode.bpel.dao.BpelDAOConnection class,
which is already been updated into a new package.
2. the dao-hibernate-db module build failed.
3. Need to deploy the distribution into Tomcat, ServiceMix to see if it
works or not.
Overall, This is a great step forward, I am thinking that can we work on one
git repo, so that we can avoid conflicts, and we also need to merge the
updates from Apache ode's repo, so it can be applied back to apache ode svn
more easily?
Regards
Jeff
--
Cheers,
Jeff Yu
----------------
blog: http://jeff.familyyu.net
Re: JPA DAO refactoring.
Posted by Jeff Yu <je...@gmail.com>.
Hi Aaron,
comments inline.
On Mon, Mar 8, 2010 at 3:28 PM, Aaron Anderson <aa...@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
>
+1, Now it looks much cleaner when I look into the bpel-store module, also
look into the bpel-store's dependency, no more dependencies on the impl,
great.
> 2) Updated the DAO package names to divide the DAO interfaces in a
> consistent fashion
>
+1
> 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.
>
I also agreed that we have a new module, as you did. It is cleaner than
having it in the bpel-dao module.
> 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
>
Great.
> 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.
>
+1.
I think at this stage, It is better that we make sure all of our changes
didn't broke the build, all of tests should passed etc, before we move to
refactor the scheduler DAO, it would be easy for us to find the problem,
what do you think?
As of now, I see following issues or tasks that we need to do.
1. It seems to me that we haven't refactored the axis2-war test case code,
as it still refers to the org.apache.ode.bpel.dao.BpelDAOConnection class,
which is already been updated into a new package.
2. the dao-hibernate-db module build failed.
3. Need to deploy the distribution into Tomcat, ServiceMix to see if it
works or not.
Overall, This is a great step forward, I am thinking that can we work on one
git repo, so that we can avoid conflicts, and we also need to merge the
updates from Apache ode's repo, so it can be applied back to apache ode svn
more easily?
Regards
Jeff
--
Cheers,
Jeff Yu
----------------
blog: http://jeff.familyyu.net
Re: JPA DAO refactoring.
Posted by Jeff Yu <je...@gmail.com>.
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 <je...@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 git@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 git@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 <aa...@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 <je...@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 <aaronanderson@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 <je...@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 <je...@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
Re: JPA DAO refactoring.
Posted by Jeff Yu <je...@gmail.com>.
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 git@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 git@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 <aa...@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 <je...@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 <aaronanderson@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 <je...@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 <je...@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
Re: JPA DAO refactoring.
Posted by Aaron Anderson <aa...@acm.org>.
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 <je...@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 <aa...@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 <je...@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 <je...@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
Re: JPA DAO refactoring.
Posted by Jeff Yu <je...@gmail.com>.
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 <aa...@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 <je...@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 <je...@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
Re: JPA DAO refactoring.
Posted by Aaron Anderson <aa...@acm.org>.
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 <je...@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 <je...@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
Re: JPA DAO refactoring.
Posted by Jeff Yu <je...@gmail.com>.
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 <je...@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