[
https://issues.apache.org/jira/browse/ODE-704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12840702#action_12840702
]
Aaron Anderson commented on 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
> clean up the JPA module, supports botht openJPA and Hibernate
> -------------------------------------------------------------
>
> Key: ODE-704
> URL: https://issues.apache.org/jira/browse/ODE-704
> Project: ODE
> Issue Type: Improvement
> Components: BPEL Runtime
> Affects Versions: 1.3.3
> Reporter: Jeff Yu
> Assignee: Jeff Yu
> Fix For: 2.0
>
>
> see this thread for detail.
> http://mail-archives.apache.org/mod_mbox/ode-dev/200911.mbox/%[email protected]%3e
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
