glassfish
  1. glassfish
  2. GLASSFISH-7066

EJB3 bean silently not published if it inherits the Remote interface from a POJO

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 9.1peur2
    • Fix Version/s: not determined
    • Component/s: verifier
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      7,066

      Description

      Consider the following scenario:

      @Remote
      public interface TheRealRemote {

      String sayHello(String name);

      }

      public class SomeOrdinaryClassImplementingTheRealRemote implements TheRealRemote {

      public String sayHello(String name)

      { return "Hello, " + name + "!"; }

      }

      @Stateless
      public class TheRealBean extends SomeOrdinaryClassImplementingTheRealRemote {

      }

      Using plain Glassfish v2 UR2 b04, the Verifier returns 0 failures, 0 warnings
      and 0 errors for the EJB-JAR/EAR containing these classes. Deployment of the EAR
      also seems to complete fine without any error messages.

      However, the SLSB will not be properly deployed and its Remote interface not be
      published into JNDI. Any attempts to call this bean will therefore fail.

      But when we change TheRealBean to explicitly, but redundantly state that it
      implements TheRealRemote:

      @Stateless
      public class TheRealBean extends SomeOrdinaryClassImplementingTheRealRemote
      implements TheRealRemote {

      }

      the SLSB deploys fine, its remote interface will be bound to JNDI and the bean
      can successfully be called.

      The error seems to be that some statical analysis on TheRealBean class fails to
      detect that this class implements TheRealRemote indirectly, because it extends
      another POJO class that implements it.

      This issue has been found in a real-world customer application and was very hard
      to debug due to the complete lack of any error messages other than the inability
      to look up any Remote interfaces.

      The attached NetBeans project contains the full source for a test case EAR.
      Running the verifier on the EAR returns no errors, but TheRealRemote will not be
      bound into JNDI after deployment. Then add the redundant "implements
      TheRealRemote", and everything is fine.

      Many thanks in advance for fixing this!

        Activity

        Hide
        al130959 added a comment -

        Created an attachment (id=2226)
        Test case containing the scenario for issue #7066

        Show
        al130959 added a comment - Created an attachment (id=2226) Test case containing the scenario for issue #7066
        Hide
        Alexis MP added a comment -

        adding myself to CC list

        Show
        Alexis MP added a comment - adding myself to CC list
        Hide
        ksak added a comment -

        Client views are not inherited through processing of super-classes. They can only be defined directly on
        the bean class or through the deployment descriptor. This is an area that has been clarified in the 3.1
        spec. See section 4.9.2.1 – Session Bean Superclasses. At best there could be some verifier warning,
        though Changing category to verifier.

        Show
        ksak added a comment - Client views are not inherited through processing of super-classes. They can only be defined directly on the bean class or through the deployment descriptor. This is an area that has been clarified in the 3.1 spec. See section 4.9.2.1 – Session Bean Superclasses. At best there could be some verifier warning, though Changing category to verifier.
        Hide
        al130959 added a comment -

        Still my question would be:

        The EJB 3.0 spec did not make any statements regarding the need to explicitly
        include superclass-implemented interfaces in its own interface list. If
        implementing parent class interfaces this shall be explicitly handled and
        required by the EJB 3.1 spec - then fine from the EJB container point of view.

        But in this case I would at least require a mandatory message rejecting a
        bean class that has been set up like in my example - it's definitely not a
        nice-to have thing to have "at best"....

        So please change the Verifier to reject my bean and point to this section for
        the reason why - although it will be "interesting" to refuse deployment of an
        EJB 3.0 SLSB due to restrictions only being raised for the first time in the EJB
        3.1 spec...

        Many thanks!

        Andreas

        Show
        al130959 added a comment - Still my question would be: The EJB 3.0 spec did not make any statements regarding the need to explicitly include superclass-implemented interfaces in its own interface list. If implementing parent class interfaces this shall be explicitly handled and required by the EJB 3.1 spec - then fine from the EJB container point of view. But in this case I would at least require a mandatory message rejecting a bean class that has been set up like in my example - it's definitely not a nice-to have thing to have "at best".... So please change the Verifier to reject my bean and point to this section for the reason why - although it will be "interesting" to refuse deployment of an EJB 3.0 SLSB due to restrictions only being raised for the first time in the EJB 3.1 spec... Many thanks! Andreas
        Hide
        Sanjeeb Sahoo added a comment -

        As per conventions in verifier project, new assertions are classified as
        enhancements. So, marking this issue as an enhancement.

        Show
        Sanjeeb Sahoo added a comment - As per conventions in verifier project, new assertions are classified as enhancements. So, marking this issue as an enhancement.
        Hide
        Tom Mueller added a comment -

        Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

        Show
        Tom Mueller added a comment - Bulk update to change fix version to "not determined" for all issues still open but with a fix version for a released version.

          People

          • Assignee:
            Sanjeeb Sahoo
            Reporter:
            al130959
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated: