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,

---------------- blog: http://jeff.familyyu.net