ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Anderson <aaronander...@acm.org>
Subject Re: JPA DAO refactoring.
Date Wed, 10 Mar 2010 02:23:00 GMT
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?



From: Jeff Yu <jeff.yuchang@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 <aaronanderson@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,

> 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.

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


> 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.


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?


Jeff Yu

blog: http://jeff.familyyu.net

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message