Removal of JBossTM from JBossAS trunk

[dimitris]

Adrian has already specified the removal of JBossTM from JBossAS trunk here: http://jira.jboss.com/jira/browse/JBAS-4516

This is however scheduled for GA. I think it would make a lot more sense to perform those tasks at an earlier Beta or CR release.

Another question is what happens to the JBossTM project. Remove it entirely? Franscisco wanted to fork the project at sourceforge at some point.

Is there any usecase that would require a standalone/embedded JBossTM? (e.g. with JBossCache)

[bill.burke]

I think it needs some massaging, but the Arjuna stuff is pretty embeddable.

[marklittle]

Yes, you can embed JBossTS in a range of application servers or containers. As Bill said though, it may need some bespoke code to do it. Plus, it's always been designed to run stand-alone.

As for the old JBossTM project, I'm still waiting for something back from Francisco on that.

[andy.miller]

I would like to make sure that it gets removed at least for the first CR, and I really think the embedded case should also be JBoss Transactions, because the old transaction manager has lots of problems with correctness.

[marklittle]

Yes, there's no reason I'm aware of that would prevent the embedded version being JBossTS either.

[reverbel]

Ivan already copied the JBoss TM/OTS/DTM code to a Sourceforge project.

I can look into removing OTS/DTM from trunk. I am not sure I fully understand the implications of removing JBoss TM (JTA). Have all dependencies from that TM been eliminated? We want to retain some of its interfaces (e.g., the TPC importer/exporter interfaces), right?

Currently there is a hardcoded dependency from the IIOP module on the OTS code. The IIOP servant directly accesses an OTS class in order to obtain the transaction context, which is then stuffs into the Invocation object. That dependency on a class needs to be replaced by a dependency on an interface, which any deployable OTS module may implement. Besides allowing the current OTS code to continue working even after its removal from trunk, this should also be useful to JBossTS, for "transaction bridging" across OTS and XA (JTA).

[jhalliday]

> I am not sure I fully understand the implications of removing JBoss TM (JTA). Have all dependencies from that TM been eliminated? We want to retain some of its interfaces (e.g., the TPC importer/exporter interfaces), right?

Adrian (? at least I think it was him) has a project underway to separate out the interfaces that pluggable components should use to interface to the app server. I think it already has the JBoss TM interfaces. If not they should move into there before disappearing from the AS.

[adrian.brock]

The TM integration interfaces have been moved to the jboss integration project.
http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/integration/trunk/

The outstanding work is on the JIRA issue at the top of this topic.
There's the OTS issue, the XIDFactory usage and cleaning up the testsuite.

For the CORBA/OTS integration, we probably need a seperate
jboss-corba-spi in the integration project? Or should this go in the
jboss-transaction-spi?

Ideally, there should be a jboss-corba-spi anyway for the JacORB integration
to implement. Then somebody else can choose to integrate a different ORB for JBoss
by implementing that spi.

[marklittle]

For the CORBA/OTS integration, we probably need a seperate
jboss-corba-spi in the integration project? Or should this go in the
jboss-transaction-spi?

How about jboss-corba-orb-spi and jboss-corba-ots-spi? I doubt we'll be adding any further implementations based on OMG technologies in the near future, but keeping the projects hierarchical should make it easier to manage in the future.

[reverbel]

jboss-corba-ots-spi sounds good to me.

Right now I am swamped with other work, but next week will have some time to create that SPI and then remove the OTS code.