Weld
  1. Weld
  2. WELD-301

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

    Details

    • Type: Bug Bug
    • Status: Closed Closed (View Workflow)
    • Priority: Critical 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
    • Similar Issues:
      Show 10 results 

      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.

        Issue Links

          Activity

          Hide
          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
          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
          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
          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
          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
          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
          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
          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
          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
          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:
              Pete Muir
              Reporter:
              Hong Zhang
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: