4 Replies Latest reply on Sep 21, 2007 12:41 PM by Jonathan Halliday

    TxServerInterceptor hardwiring

    Adrian Brock Master

      This is just to document what Jonathon discovered and communicated in a private e-mail

      The iiop servants for EJBs (both home and ejbobject) hardwire the TxServerInterceptor
      to retrieve the transaction from the request.
      There is a similar problem for the security.

      We need to come up with some integration api such that the iiiop ejb proxy
      doesn't depend upon specific transport configuration like what interceptors are used.

        • 1. Re: TxServerInterceptor hardwiring
          Francisco Reverbel Novice

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


          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();

          • 2. Re: TxServerInterceptor hardwiring
            Francisco Reverbel Novice

            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... :-)

            • 3. Re: TxServerInterceptor hardwiring
              Francisco Reverbel Novice

              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.

              • 4. Re: TxServerInterceptor hardwiring
                Jonathan Halliday Master

                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.