I am looking at this now. Just for the record, there has been some previous discussion on this issue:

http://www.jboss.com/index.html?module=bb&op=viewtopic&t=117224

For security the situation is a bit better, if I remember correctly. In the security stuff I don't think there is a hardcoded dependency on a class. The security dependency is already an interface, which could simply be moved to an integration project.

For transactions, the interface needs to be created. I did this already -- it's a very simple interface, with a single method that returns a Transaction instance associated with the incoming request.

I am not quite familar with maven yet, so setting up the maven build for the integration project is what will take me more time. Which makes me think if I am on the right track or not... Do we really want an integration project and a jboss-corba-ots-spi jar containing just a single class file for an interface with a single method?

interface InboundTransactionCurrent {
 javax.transaction.Transaction getCurrentTransaction();
}

Never mind, now I see there is no need for a separate jar, as the new interface is placed within jboss-integration.jar.

Maven works... :-)

The hardcoded references to TxServerInterceptor have been removed from the CORBA servants in svn trunk. Now all three servants (the EJB3 one included) use the InboundTransactionCurrent SPI, which has been added to the integration project.

TxServerInterceptor still has dependencies on DTM classes, though. I will remove those dependencies soon. After the removal of the DTM/OTS code from JBossAS, TxServerInterceptor will remain as the default OTS interceptor, used by the default implementation of InboundTransactionCurrent.

Is the 4.2/EAP using this integration.jar already or is it going to? The new API will need backporting at some point or we won't be able to do JTS in the EAP.