You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Christian Schneider <ch...@die-schneider.net> on 2014/09/26 12:31:45 UTC
Proposal for changes in jpa.container
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.
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.
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?
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.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Proposal for changes in jpa.container
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Christian,
it sounds good to me.
+1 for all proposals.
Regards
JB
On 09/26/2014 12:31 PM, Christian Schneider wrote:
> 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.
>
>
> 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.
>
>
> 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?
>
>
> 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.
>
>
>
> Christian
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Proposal for changes in jpa.container
Posted by Guillaume Nodet <gn...@apache.org>.
There's no maintenance branches in aries, so if the change (when/if
accepted) requires a major version, that simply means the next release will
be a major upgrade for jpa/container.
2014-09-26 14:12 GMT+02:00 Christian Schneider <ch...@die-schneider.net>:
> On 26.09.2014 13:31, Guillaume Nodet wrote:
>
>
>>> 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 ?
>>
> If we can do 3 now then 4 makes no sense. If we do 3 on the next major
> version then we should do 4 now to provide a compatible upgrade path.
>
>
> Christian
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> http://www.talend.com
>
>
Re: Proposal for changes in jpa.container
Posted by Christian Schneider <ch...@die-schneider.net>.
On 26.09.2014 13:31, Guillaume Nodet wrote:
>>
>> 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 ?
If we can do 3 now then 4 makes no sense. If we do 3 on the next major
version then we should do 4 now to provide a compatible upgrade path.
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
Re: Proposal for changes in jpa.container
Posted by Guillaume Nodet <gn...@apache.org>.
2014-09-26 12:31 GMT+02:00 Christian Schneider <ch...@die-schneider.net>:
> 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
>
>