Uploaded image for project: 'Weld'
  1. Weld
  2. WELD-301

ProducerMethod.checkProducerMethod only checked method declarations in direct implemented interface and not super interfaces

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Critical
    • Resolution: Partially Completed
    • Affects Version/s: 1.0.0.GA
    • Fix Version/s: 1.0.1.CR1
    • Component/s: None
    • Labels:
      None
    • Environment:

      X86/Ubuntu

      Description

      I am investigating the deployment failure when running org.jboss.jsr299.tck.tests.implementation.producer.method.definition.enterprise.EnterpriseProducerMethodDefinitionTest.

      The deployment failed due to some validation failure in weld RI code. It complains that produceLightYellowPear method of LightYellowPearTree is not declared in LightYellowPearTree business interface. But LightYellowTree implements LightYellowPearTreeLocal which extends from PearTreeLocal which delares the produceLightYellowPear method.

      This seems a weld RI bug to me after stepping into the RI code:
      In ProducerMethod.checkProducerMethod, when it's a session bean, it will check for its implemented interface and super class for whether they declared this business method. But the problem is it only goes to its direct implemented interface and not the interface hierarchy. In this case it's true that the LightYellowPearTreeLocal does not declare this method, but PearTreeLocal which the LightYellowPearTreeLocal extends from does declare this method. The RI code should be modified to check for the whole interface hierarchy and not just the direct implemented interface.

        Gliffy Diagrams

          Issue Links

            Activity

            Hide
            pmuir Pete Muir added a comment -

            Gavin, thanks, I had missed that bit of the 299 spec, I will fix that in Weld (NB this is a slightly different issue than the original one reported).

            Show
            pmuir Pete Muir added a comment - Gavin, thanks, I had missed that bit of the 299 spec, I will fix that in Weld (NB this is a slightly different issue than the original one reported).
            Hide
            pmuir Pete Muir added a comment -

            I am still surprised that EJB (or at lest the GlassFish implementation) doesn't traverse the interface hierarchy looking for the @Local interface. Gavin, what do you think the local business interfaces (as defined by the EJB spec) of this should be?

            @Stateful
            public class LightYellowPearTree extends YellowPearTree implements LightYellowPearTreeLocal

            { // body ommitted}

            class YellowPearTree extends PearTree

            { // body ommitted }

            @Stateful
            public class PearTree implements PearTreeLocal { // body omitted }

            @Local
            public interface LightYellowPearTreeLocal extends PearTreeLocal {// body omitted }

            @Local
            public interface PearTreeLocal { // body ommitted }

            GlassFish currently only provides one EJB local business interface (LightYellowPearTreeLocal) whilst JBoss AS gives us both. I would expect EJB to see both PearTreeLocal and LightYellowPearTreeLocal as local business interfaces, given both are annotated @Local and both appear in the class hierarchy (though PearTreeLocal isn't directly extending/implementing)

            Show
            pmuir Pete Muir added a comment - I am still surprised that EJB (or at lest the GlassFish implementation) doesn't traverse the interface hierarchy looking for the @Local interface. Gavin, what do you think the local business interfaces (as defined by the EJB spec) of this should be? @Stateful public class LightYellowPearTree extends YellowPearTree implements LightYellowPearTreeLocal { // body ommitted} class YellowPearTree extends PearTree { // body ommitted } @Stateful public class PearTree implements PearTreeLocal { // body omitted } @Local public interface LightYellowPearTreeLocal extends PearTreeLocal {// body omitted } @Local public interface PearTreeLocal { // body ommitted } GlassFish currently only provides one EJB local business interface (LightYellowPearTreeLocal) whilst JBoss AS gives us both. I would expect EJB to see both PearTreeLocal and LightYellowPearTreeLocal as local business interfaces, given both are annotated @Local and both appear in the class hierarchy (though PearTreeLocal isn't directly extending/implementing)
            Hide
            wolfc Carlo de Wolf added a comment -

            EJB 3.1 FR 4.9.7 bullet 3:
            • The interface is allowed to have superinterfaces.

            EJB 3.1 FR 4.9.7 bullet 5.2:
            • A bean class is permitted to have more than one interface. If a bean class has more
            than one interface—excluding the interfaces listed below—any business interface of
            the bean class must be explicitly designated as a business interface of the bean by
            means of the Local or Remote annotation on the bean class or interface or in the
            deployment descriptor.

            Since both interfaces are annotated with @Local I would consider both interfaces to be valid local business interfaces.

            Show
            wolfc Carlo de Wolf added a comment - EJB 3.1 FR 4.9.7 bullet 3: • The interface is allowed to have superinterfaces. EJB 3.1 FR 4.9.7 bullet 5.2: • A bean class is permitted to have more than one interface. If a bean class has more than one interface—excluding the interfaces listed below—any business interface of the bean class must be explicitly designated as a business interface of the bean by means of the Local or Remote annotation on the bean class or interface or in the deployment descriptor. Since both interfaces are annotated with @Local I would consider both interfaces to be valid local business interfaces.
            Hide
            pmuir Pete Muir added a comment -

            I've spun the issue Gavin raised out into WELD-305, marking this as partially completed, as there is a bug in GlassFish as well, not considering super-interfaces marked @Local as local business interfaces (at least when this info is passed to Weld).

            Show
            pmuir Pete Muir added a comment - I've spun the issue Gavin raised out into WELD-305 , marking this as partially completed, as there is a bug in GlassFish as well, not considering super-interfaces marked @Local as local business interfaces (at least when this info is passed to Weld).
            Hide
            hzhang_jb Hong Zhang added a comment -

            I have filed a glassfish issue on this and assigned to ejb team to investigate.

            https://glassfish.dev.java.net/issues/show_bug.cgi?id=11140

            If ejb team agrees this is a glassfish bug, I think we should also modify the javadoc of this SPI so it's clear what the expected behavior is.

            Show
            hzhang_jb Hong Zhang added a comment - I have filed a glassfish issue on this and assigned to ejb team to investigate. https://glassfish.dev.java.net/issues/show_bug.cgi?id=11140 If ejb team agrees this is a glassfish bug, I think we should also modify the javadoc of this SPI so it's clear what the expected behavior is.

              People

              • Assignee:
                pmuir Pete Muir
                Reporter:
                hzhang_jb Hong Zhang
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Development