wsit
  1. wsit
  2. WSIT-397

txn attribute specified in ejb deployment descriptor is disregarded by mapping of CMT EJB web service to appropriate WS-AT policy assertions

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: current
    • Fix Version/s: 2.1
    • Component/s: transaction
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      397

      Description

      Automated mapping of CMT EJB Web Service method to wsdl:binding/wsdl:operation
      with semantically equivalent WS-AtomicTransation Policy Assertion currently
      ignores transaction attributes specified in deployment descriptors.
      Implementation only computes effective transaction attribute for a CMT EJB
      based on Java EE 5.0 EJB transaction program annotations.
      (javax.ejb.TransactionAttribute, javax.ejb.TransactionManagement)

      ******************
      Workaround: Use Java EE 5.0 program annotations on Container Managed Transaction
      (CMT) EJB Web Services.

        Activity

        Hide
        jfialli added a comment -

        For implementation assistance, here is stacktrace where access to effective
        transaction attribute of an EJB mehtod from EJBDescriptor is needed.

        TxMapUpdateProvider.java:100 // WSIT WS-TX code that maps transation
        attribute on CMT EJB method to WS-AT Policy assertion.
        PolicyWSDLGeneratorExtension.start: 123
        ...
        WsUtil.reunWsGen: 1812
        WsUtil.genWSInfo: 2110
        AppDeployerBase.loadDescriptor: 346
        AppDeployer.expodeArchive: 274
        AppDeployer.deploy: 188
        AppDeployer.doRequestFinish:132
        J2EECPhase.runPhase:174
        DeploymentPhase.executePhase: 95

        Specifically, following code needs to also get
        EjbDescriptor.effectiveTransactionAttribute

        classDefaultTxnAttr =
        TransactionAnnotationProcessor.getTransactionAttributeDefault(theClass);

        The TransactionAnnnotationProcessor calls in TxMapUpdateProvider.java only look
        at program annotations and should be replaced with
        EjbDescriptor.findTxAttr(EJBMethod).

        Show
        jfialli added a comment - For implementation assistance, here is stacktrace where access to effective transaction attribute of an EJB mehtod from EJBDescriptor is needed. TxMapUpdateProvider.java:100 // WSIT WS-TX code that maps transation attribute on CMT EJB method to WS-AT Policy assertion. PolicyWSDLGeneratorExtension.start: 123 ... WsUtil.reunWsGen: 1812 WsUtil.genWSInfo: 2110 AppDeployerBase.loadDescriptor: 346 AppDeployer.expodeArchive: 274 AppDeployer.deploy: 188 AppDeployer.doRequestFinish:132 J2EECPhase.runPhase:174 DeploymentPhase.executePhase: 95 Specifically, following code needs to also get EjbDescriptor.effectiveTransactionAttribute classDefaultTxnAttr = TransactionAnnotationProcessor.getTransactionAttributeDefault(theClass); The TransactionAnnnotationProcessor calls in TxMapUpdateProvider.java only look at program annotations and should be replaced with EjbDescriptor.findTxAttr(EJBMethod).
        Hide
        jfialli added a comment -

        Before FCS, either this defect needs to be addressed as proposed resulting in
        the replacement of TransactionAnnotationProcessor with a Glassfish SPI to
        obtain the effective transaction attribute of an ejb method OR the
        following issue has to be fixed with current usage of
        TranasctionAnnotationProcessor.

        Outstanding issue moved from wsit 214:

        Just to make sure this isn't being forgotten -
        com.sun.xml.ws.tx.common.TxMapUpdateProvider contains:

        try

        { isCMTEJB = TransactionAnnotationProcessor.isContainerManagedEJB(theClass); }

        catch (NoClassDefFoundError e) {

        Catching a NoClassDefFoundError is not portable across JVMs and must be replaced
        by JVMs.
        The only reliable way to do what you need to do is to use reflection.

        A try/catch is not going to work reliably because a JVM is allowed to raise
        these exceptions any time it links in the class, which may be long before your
        code block gets executed. For more detail see:
        http://blogs.sun.com/ritzmann/entry/is_catching_noclassdeffounderror_more_effici
        ent

        Show
        jfialli added a comment - Before FCS, either this defect needs to be addressed as proposed resulting in the replacement of TransactionAnnotationProcessor with a Glassfish SPI to obtain the effective transaction attribute of an ejb method OR the following issue has to be fixed with current usage of TranasctionAnnotationProcessor. Outstanding issue moved from wsit 214: Just to make sure this isn't being forgotten - com.sun.xml.ws.tx.common.TxMapUpdateProvider contains: try { isCMTEJB = TransactionAnnotationProcessor.isContainerManagedEJB(theClass); } catch (NoClassDefFoundError e) { Catching a NoClassDefFoundError is not portable across JVMs and must be replaced by JVMs. The only reliable way to do what you need to do is to use reflection. A try/catch is not going to work reliably because a JVM is allowed to raise these exceptions any time it links in the class, which may be long before your code block gets executed. For more detail see: http://blogs.sun.com/ritzmann/entry/is_catching_noclassdeffounderror_more_effici ent
        Hide
        jfialli added a comment -

        Workaround for this issue is to use program annotations that duplicate
        deployment descriptor for transactionmanagement of EJB class and for
        transaction attributes of EJB class and/or methods.

        Show
        jfialli added a comment - Workaround for this issue is to use program annotations that duplicate deployment descriptor for transactionmanagement of EJB class and for transaction attributes of EJB class and/or methods.
        Hide
        m_potociar added a comment -

        Reassigning to the component owner

        Show
        m_potociar added a comment - Reassigning to the component owner
        Hide
        Marek Potociar added a comment -

        The new WS-AT implementation in Metro 2.1 comes up with a new config model that is not based only on the EJB annotations

        Show
        Marek Potociar added a comment - The new WS-AT implementation in Metro 2.1 comes up with a new config model that is not based only on the EJB annotations

          People

          • Assignee:
            Marek Potociar
            Reporter:
            jfialli
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: