2014-09-26 12:31 GMT+02:00 Christian Schneider <[email protected]>:
> I would like to do some changes in the jpa.container code. > > > 1. Directly use BundleWiring > > Currently > org.apache.aries.jpa.container.annotation.impl.AnnotationScannerFactory > tests if BundleWiring is available. The code for Annotation parsing would > be a lot simpler if we could assume that it is always there. > BundleWiring is in the OSGi spec since version 4.3 which was released > 2011. Can we already assume that all platforms we support provide it? If > yes then I would like to remove the optionality. > > If we need to still support the spec < 4.3 then we might be able to embed > the package org.osgi.framework.wiring and export / import it. We then only > need to check bundle.adapt(BundleWiring.class) for exceptions. > > +1 > > 2. Directly use TransactionManager > > We have similar special code to test for the > javax.transaction.TransactionManager > class. I would like to embed and export / import the package. So we could > remove the special handling. > -1 I don't think substitutable imports should be used as a workaround for optional imports. > > > 3. Remove wrapping of XADataSource into a managed DataSource > > In JEE containers you normally do not directly use XADataSource. Instead > you rely on a managed DataSource that is published on jndi. So I wonder if > we could do the same even for DataSourceFactory. > > There are some facitlities available that do the wrapping for us like > aries.transaction.jdbc or pax-jdbc-pool. So by moving this effort outside > aries jpa our code would be a lot simpler. Apart from removing the wrapping > this would also completely eleminate the link to TransactionManager. So > change 2 would not be necessary. > > The problem here is of course that such a change is not backwards > compatible. > > As far as I know this only affects people that create the DataSource > inside aries jpa from a DataSourceFactory. All people I know seem to use a > jndi reference to a DataSource which does not seem to be affected. > If we need to keep compatibility at the moment then would such a change > make sense for the next major version of aries jpa? > No real objection on my side. > > > 4. Introduce a switch to decide if DataSource or XADataSource > should be created > > Apart from that I would like to introduce a switch that already allows to > use a managed transactional DataSource right now. So with this switch (in > persistence.xml ?) the user could choose if he wants to create the > DataSource from the DataSourceFactory using createDataSource() even in JTA > mode or use createXADataSource() and let aries jpa do the wrapping. > > I don't think it makes sense if #3 is done, right ? > > > Christian > > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > >
