3 Replies Latest reply on Feb 10, 2016 4:50 AM by mkouba

    Injection of EJB's implementing an abstract class

    cfinerty

      Hi all,

       

      I have run into an odd behavior moving between jboss-as 7.1.1 and wildfly 10.0.0.0. This involved a weld update 1.1.32->2.3.2 and an ejb update 3.1->3.2 . If i have interface A, abstract class B implements A and class C extends B and B is annotated @Stateless. As below.

      scenario 1:

      public interface A{
          void foo();
      }
      
      public abstract class B implements A{
          public void foo(){}
      }
      
      @Stateless
      public class C extends B{
      }
      

       

      When i inject A

      @Inject
      A a;
      

      I expect to get a proxy of the stateless bean C. This worked previously but now causes a WELD-001408: Unsatisfied dependencies for type A with qualifiers @Default.

      Without the abstract class, with the local annotation specifying the interface or with an explicit inheritance of the interface the injection works fine (scenarios 2,3,4 respectively).

      scenario 2:

      @Stateless
      public class C implements A{
          void foo(){}
      }
      

      scenario 3:

      @Stateless
      @Local(value = A.class)
      public class C extends B{
      }
      

      scenario 4:

      @Stateless
      public class C extends B implements A{
      }
      

      The error message is interesting, I would have expected an exception mentioning incorrect local EJB interface if the defaulting of EJB local interfaces had changed but the unsatisfied dependency implies an interplay between weld and the EJB provider (scenario 1 works when C is not an EJB) that I don't know about. Perhaps an issue in the EJB interface discovery where it doesn't traverse abstract classes. Could anyone explain this behavior before i make a bug report encase this is an intended change that i can't find a record of without understanding the cause.

       

      Thank you for any help or redirection to a more appropriate forum.

        • 1. Re: Injection of EJB's implementing an abstract class
          mkouba

          Hi Christopher,

          I think the behavior of WildFly10/Weld2.3 is correct per the specs. The CDI spec: "The unrestricted set of bean types for a session bean contains all local interfaces of the bean and their superinterfaces. If the session bean has a no-interface view, the unrestricted set of bean types contains the bean class and all superclasses." (see also 3.2.2. Bean types of a session bean). In your case C has no-interface view because the client views exposed by B are not inherited by a subclass (C) - see also EJB spec "4.9.2.1 Session Bean Superclasses" and "4.9.7 Session Bean’s Business Interface". Scenarios 2, 3 and 4 look fine (A is explicitly declared).

          • 2. Re: Injection of EJB's implementing an abstract class
            cfinerty

            Thanks Martin,

            That line in the spec certainly seems to disallows our current usage. I guess something got tightened up in the implementations between the old and new versions which enforces this. Guess ill start migrating our code base as the fix is very simple and I understand the issue now.

             

            Thanks again.

            • 3. Re: Injection of EJB's implementing an abstract class
              mkouba

              Yes, it could also be a Weld bug - it seems there was no TCK test for CDI 1.0, 1.1 and 1.2 (see also CDITCK-483).