ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Yu <jeff.yuch...@gmail.com>
Subject JPA DAO refactoring.
Date Thu, 04 Mar 2010 06:02:12 GMT
Quote from Aaron's comments of JIRA. (

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
public class JDBCContext {

   DataSource getDataSource(){}
   TransactionManager getTransactionManager(){}


What are your thoughts on this approach?



Jeff Yu

blog: http://jeff.familyyu.net

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