Atomikos Forum

Hi,

first of all thanks for actually making the effort to provide OSGi bundles out of the box. I tried to use transactions-osgi 3.7.0 in equinox 3.7 with java 6 and had the following problems:
- you might be aware that javax.transaction is crippled in rt.jar and only contains exceptions. If you install th atomikos bundle as is you will get a NoClassDefFound since atomikos is wired to the system class loader (bundle 0). To fix this the Import-Package: statement in manifest.mf should read javax.transaction;version="1.1.0" . This way you can for example add javax.transaction from spring EBR and the atomikos bundle will start up.
- transaction-osgi exports virtually no packages. This makes it impossible to instantiate a AtomikosDataSourceBean from another Bundle.
- As another suggestion: Consider setting a osgi jndi name for the exported services. This makes it possible to look up the services in enterprise osgi via jndi. This is documented in the osgi enterprise specification which also describes jta in osgi enterprise.

Hi,

Thanks very much for the input! Will relay to our OSGi expert...

Best

Hi,

I faced the same issue with javax.transaction package with equinox.

Atomikos implements version 1.0 of the spec, that's why I'm reluctant to javax.transaction;version="1.1.0"  although I admit It's a nice workaround.
The integration tests (based on Pax Exam) work fine with knoperfish and felix.

I admit too few package are exported in version 3.7.0. The only way to configure a datasourceBean is to create a fragment of transactions-osgi bundle, but obviously this is not very nice and the Java Beans contained in this package will certainly keep backward compatibility for a long time.

In the current dev branch some more package were added :
Export-Package: com.atomikos.jdbc.*,com.atomikos.jms.*,com.atomikos.datasource.xa,com.atomikos.icatch.jta

Thus, you'll be able to configure AtomikosDataSourceBean from other bundles.

For the "osgi jndi name" thing  I was simply not aware. So far, I didn't find any related content in the "OSGi Service Platform Enterprise Specification - Release 4, Version 4.2" . Can you provide any pointer on this subject ?

Best regards

Hi,

Magus, thanks for your feedback.

We already faced issues with javax.transaction package issue (under equinox only) for the next release we'll put javax.transaction;version="1.0.1" coz Atomikos works also with version 1.0.1.

Our Integration tests are made with the jar coming from EBR so I can say I works with JTA API version 1.1.

In the next release we'll export package "com.atomikos.jdbc.*,com.atomikos.jms.*" so user can instatiate easily AtomikosDataSourceBean and AtomikosConnectionFactoryBean from infrastructure bundle.

For the JNDI suggestion, I think "osgi:service/javax.transaction.TransactionManager" and "osgi:service/javax.transaction.UserTransactionManager" should already work.

We may add "osgi.jndi.service.name" for all the exported services  as additionnal property to avoid conflicts in case of multiple transaction manager on the same platform.

We mainly have to find an agreement on what the value of these property can be...

Regards

Hi,


- Concerning the import: I would recommend to use a version range like
javax.transaction;version="[1.0,1.2)" because afaik version 1.1 only added a new interface but is otherwise backwards compatible with JTA 1.0.
- Concerning the JNDI registration: Thinking about it again it is probably not as useful as I originally thought. You are almost providing a OSGi 4.2 Enterprise conformant OSGi-JTA implementation anyways. So just leave it out...


Having now used Atomikos in OSGi a bit, there are (of course) some classloading issues:
- If you have a Bundle which implements OSGi's DataSourceFactory to create your Atomikos DataSources you have to assign the BundleClassLoader as CCL to create a Non-XA DataSource. This could be avoided if the Drivers Class could be set directly.
- The Atomikos OSGi bundle effectively needs a DynamicImport-Package: * entry in MANIFEST.MF because otherwise creating of Connection proxies will fail: It tries to load Atomikos + Driver classes from _one_ classloader which is not in the list of ClassLoaders to try.
Making it possible to set an optional ClassLoader for the Atomikos DataSource beans would solve this problem (This should be the classloader of the bundle which instantiates the DataSource).

Cheers,
Magnus

Hi Magnus,


I think your expectation will be fully satisfied with version 3.8.

I don't know yet the release date but we're getting very close.

We implement several integration tests based on Pax Exam that prove It's going to work as expected.