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 <jeff.yuch...@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
