Why are Producers not inherited in CDI










1














Given the following classes



 private static class ProducedInSubClass 


private static class ProducedInSuperClass


public static class SuperClass
@Produces
public ProducedInSuperClass producedInSuperClass = new ProducedInSuperClass();


public static class SubClass extends SuperClass
@Produces
ProducedInSubClass producedInSubClass = new ProducedInSubClass();


public static class BeanWithSubClass
@Inject
SubClass subClass;
@Inject
ProducedInSuperClass producedInSuperClass;
@Inject
ProducedInSubClass producedInSubClass;



The injection of ProducedInSuperClass stays unsatisfied. That is consistent with the CDI-Spec Chapter 4.2, I know.



To make this work, I need to extend SubClass by



 @Produces
ProducedInSuperClass producedInSuperClassInSubClass = producedInSuperClass;


can anybody give an explanation for that? Why are Injects, Annotations Interceptors... inherited but not Producers?










share|improve this question




























    1














    Given the following classes



     private static class ProducedInSubClass 


    private static class ProducedInSuperClass


    public static class SuperClass
    @Produces
    public ProducedInSuperClass producedInSuperClass = new ProducedInSuperClass();


    public static class SubClass extends SuperClass
    @Produces
    ProducedInSubClass producedInSubClass = new ProducedInSubClass();


    public static class BeanWithSubClass
    @Inject
    SubClass subClass;
    @Inject
    ProducedInSuperClass producedInSuperClass;
    @Inject
    ProducedInSubClass producedInSubClass;



    The injection of ProducedInSuperClass stays unsatisfied. That is consistent with the CDI-Spec Chapter 4.2, I know.



    To make this work, I need to extend SubClass by



     @Produces
    ProducedInSuperClass producedInSuperClassInSubClass = producedInSuperClass;


    can anybody give an explanation for that? Why are Injects, Annotations Interceptors... inherited but not Producers?










    share|improve this question


























      1












      1








      1







      Given the following classes



       private static class ProducedInSubClass 


      private static class ProducedInSuperClass


      public static class SuperClass
      @Produces
      public ProducedInSuperClass producedInSuperClass = new ProducedInSuperClass();


      public static class SubClass extends SuperClass
      @Produces
      ProducedInSubClass producedInSubClass = new ProducedInSubClass();


      public static class BeanWithSubClass
      @Inject
      SubClass subClass;
      @Inject
      ProducedInSuperClass producedInSuperClass;
      @Inject
      ProducedInSubClass producedInSubClass;



      The injection of ProducedInSuperClass stays unsatisfied. That is consistent with the CDI-Spec Chapter 4.2, I know.



      To make this work, I need to extend SubClass by



       @Produces
      ProducedInSuperClass producedInSuperClassInSubClass = producedInSuperClass;


      can anybody give an explanation for that? Why are Injects, Annotations Interceptors... inherited but not Producers?










      share|improve this question















      Given the following classes



       private static class ProducedInSubClass 


      private static class ProducedInSuperClass


      public static class SuperClass
      @Produces
      public ProducedInSuperClass producedInSuperClass = new ProducedInSuperClass();


      public static class SubClass extends SuperClass
      @Produces
      ProducedInSubClass producedInSubClass = new ProducedInSubClass();


      public static class BeanWithSubClass
      @Inject
      SubClass subClass;
      @Inject
      ProducedInSuperClass producedInSuperClass;
      @Inject
      ProducedInSubClass producedInSubClass;



      The injection of ProducedInSuperClass stays unsatisfied. That is consistent with the CDI-Spec Chapter 4.2, I know.



      To make this work, I need to extend SubClass by



       @Produces
      ProducedInSuperClass producedInSuperClassInSubClass = producedInSuperClass;


      can anybody give an explanation for that? Why are Injects, Annotations Interceptors... inherited but not Producers?







      java inversion-of-control cdi weld






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 8 at 19:47

























      asked Oct 31 at 11:18









      aschoerk

      1,3211521




      1,3211521






















          2 Answers
          2






          active

          oldest

          votes


















          3





          +50










          Why are ... inherited but not Producers?




          Excerpt from JavaDoc of @Produces:




          Producer methods and fields are not inherited by bean subclasses.




          If producer methods and fields would be inherited then there would exist multiple beans ... eligible for injection to the injection point which CDI treats as ambiguous dependency.



          On the other hand, CDI supports producer method specialization:



          @Mock
          public class MockShop extends Shop

          @Override @Specializes
          @Produces
          PaymentProcessor getPaymentProcessor()
          return new MockPaymentProcessor();


          @Override @Specializes
          @Produces
          List<Product> getProducts()
          return PRODUCTS;


          ...







          share|improve this answer






















          • A simple and reasonable explanation.
            – aschoerk
            Nov 11 at 10:20


















          5














          Is there any reason why you operate on static classes only? Producer needs to be placed on an actual CDI bean to be recognized. Your sample is torn from context so I cannot say if they will actually be recognized as beans.



          However, transferring your sample to a non-static test case (with some @Vetoed beans and producers for them), it will run just as you expect it - both producers would be found and produce injectable beans. So maybe you need to share a complete reproducible sample and we can go from there.



          I suspect the inheritance you are asking about is not the actual problem here.
          Anyway, it is designed like that since CDI 1.0 so finding a discussion on that would be troublesome at best (no JIRA issue at least, I did check there).
          But one reason coming to mind right away - assume inheritance was in place for producers. Then your above scenario would have a producer for ProducedInSuperClass in SuperClass but due to inheritance also in SubClass. Assuming both are legitimate for injection (none is disabled via specialization), then you are now facing an ambiguous dependency exception as you have two producers for same bean type with same bean qualifiers because SuperClass and SubClass are two different beans and both contain a producer.
          I would say that's fair reason for disabling inheritance on producers. Furthermore, still with inheritance on, you could then override the method in subclass and more questions arise - do you keep both or do you disable original one? If you keep them, what would be the limitations on the new method? What if you decide for either and then you @Vetoed one of the beans?



          From my perspective it is simply a design decision. Probably in place to prevent further confusion. While I know this isn't the answer so you are probably looking for, questioning so old designs rarely comes with more accurate answers :-)






          share|improve this answer




















          • The example can be found at: github.com/1and1/ejb-cdi-unit/blob/rework-analyzing/…. Overriding the producer: I did that to show a workaround to the restriction of not being able to inherit Produces. Concerning the general concept of overriding: That is done at other places in the spec quit well. i.e. Injected initializers, PostConstruct, PreDestroy, so the overriding-concept should not be an issue.
            – aschoerk
            Nov 5 at 19:50











          Your Answer






          StackExchange.ifUsing("editor", function ()
          StackExchange.using("externalEditor", function ()
          StackExchange.using("snippets", function ()
          StackExchange.snippets.init();
          );
          );
          , "code-snippets");

          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "1"
          ;
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function()
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled)
          StackExchange.using("snippets", function()
          createEditor();
          );

          else
          createEditor();

          );

          function createEditor()
          StackExchange.prepareEditor(
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader:
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          ,
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );













          draft saved

          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53082162%2fwhy-are-producers-not-inherited-in-cdi%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown

























          2 Answers
          2






          active

          oldest

          votes








          2 Answers
          2






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          3





          +50










          Why are ... inherited but not Producers?




          Excerpt from JavaDoc of @Produces:




          Producer methods and fields are not inherited by bean subclasses.




          If producer methods and fields would be inherited then there would exist multiple beans ... eligible for injection to the injection point which CDI treats as ambiguous dependency.



          On the other hand, CDI supports producer method specialization:



          @Mock
          public class MockShop extends Shop

          @Override @Specializes
          @Produces
          PaymentProcessor getPaymentProcessor()
          return new MockPaymentProcessor();


          @Override @Specializes
          @Produces
          List<Product> getProducts()
          return PRODUCTS;


          ...







          share|improve this answer






















          • A simple and reasonable explanation.
            – aschoerk
            Nov 11 at 10:20















          3





          +50










          Why are ... inherited but not Producers?




          Excerpt from JavaDoc of @Produces:




          Producer methods and fields are not inherited by bean subclasses.




          If producer methods and fields would be inherited then there would exist multiple beans ... eligible for injection to the injection point which CDI treats as ambiguous dependency.



          On the other hand, CDI supports producer method specialization:



          @Mock
          public class MockShop extends Shop

          @Override @Specializes
          @Produces
          PaymentProcessor getPaymentProcessor()
          return new MockPaymentProcessor();


          @Override @Specializes
          @Produces
          List<Product> getProducts()
          return PRODUCTS;


          ...







          share|improve this answer






















          • A simple and reasonable explanation.
            – aschoerk
            Nov 11 at 10:20













          3





          +50







          3





          +50



          3




          +50





          Why are ... inherited but not Producers?




          Excerpt from JavaDoc of @Produces:




          Producer methods and fields are not inherited by bean subclasses.




          If producer methods and fields would be inherited then there would exist multiple beans ... eligible for injection to the injection point which CDI treats as ambiguous dependency.



          On the other hand, CDI supports producer method specialization:



          @Mock
          public class MockShop extends Shop

          @Override @Specializes
          @Produces
          PaymentProcessor getPaymentProcessor()
          return new MockPaymentProcessor();


          @Override @Specializes
          @Produces
          List<Product> getProducts()
          return PRODUCTS;


          ...







          share|improve this answer















          Why are ... inherited but not Producers?




          Excerpt from JavaDoc of @Produces:




          Producer methods and fields are not inherited by bean subclasses.




          If producer methods and fields would be inherited then there would exist multiple beans ... eligible for injection to the injection point which CDI treats as ambiguous dependency.



          On the other hand, CDI supports producer method specialization:



          @Mock
          public class MockShop extends Shop

          @Override @Specializes
          @Produces
          PaymentProcessor getPaymentProcessor()
          return new MockPaymentProcessor();


          @Override @Specializes
          @Produces
          List<Product> getProducts()
          return PRODUCTS;


          ...








          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Nov 10 at 1:04

























          answered Nov 10 at 0:06









          Illya Kysil

          701411




          701411











          • A simple and reasonable explanation.
            – aschoerk
            Nov 11 at 10:20
















          • A simple and reasonable explanation.
            – aschoerk
            Nov 11 at 10:20















          A simple and reasonable explanation.
          – aschoerk
          Nov 11 at 10:20




          A simple and reasonable explanation.
          – aschoerk
          Nov 11 at 10:20













          5














          Is there any reason why you operate on static classes only? Producer needs to be placed on an actual CDI bean to be recognized. Your sample is torn from context so I cannot say if they will actually be recognized as beans.



          However, transferring your sample to a non-static test case (with some @Vetoed beans and producers for them), it will run just as you expect it - both producers would be found and produce injectable beans. So maybe you need to share a complete reproducible sample and we can go from there.



          I suspect the inheritance you are asking about is not the actual problem here.
          Anyway, it is designed like that since CDI 1.0 so finding a discussion on that would be troublesome at best (no JIRA issue at least, I did check there).
          But one reason coming to mind right away - assume inheritance was in place for producers. Then your above scenario would have a producer for ProducedInSuperClass in SuperClass but due to inheritance also in SubClass. Assuming both are legitimate for injection (none is disabled via specialization), then you are now facing an ambiguous dependency exception as you have two producers for same bean type with same bean qualifiers because SuperClass and SubClass are two different beans and both contain a producer.
          I would say that's fair reason for disabling inheritance on producers. Furthermore, still with inheritance on, you could then override the method in subclass and more questions arise - do you keep both or do you disable original one? If you keep them, what would be the limitations on the new method? What if you decide for either and then you @Vetoed one of the beans?



          From my perspective it is simply a design decision. Probably in place to prevent further confusion. While I know this isn't the answer so you are probably looking for, questioning so old designs rarely comes with more accurate answers :-)






          share|improve this answer




















          • The example can be found at: github.com/1and1/ejb-cdi-unit/blob/rework-analyzing/…. Overriding the producer: I did that to show a workaround to the restriction of not being able to inherit Produces. Concerning the general concept of overriding: That is done at other places in the spec quit well. i.e. Injected initializers, PostConstruct, PreDestroy, so the overriding-concept should not be an issue.
            – aschoerk
            Nov 5 at 19:50
















          5














          Is there any reason why you operate on static classes only? Producer needs to be placed on an actual CDI bean to be recognized. Your sample is torn from context so I cannot say if they will actually be recognized as beans.



          However, transferring your sample to a non-static test case (with some @Vetoed beans and producers for them), it will run just as you expect it - both producers would be found and produce injectable beans. So maybe you need to share a complete reproducible sample and we can go from there.



          I suspect the inheritance you are asking about is not the actual problem here.
          Anyway, it is designed like that since CDI 1.0 so finding a discussion on that would be troublesome at best (no JIRA issue at least, I did check there).
          But one reason coming to mind right away - assume inheritance was in place for producers. Then your above scenario would have a producer for ProducedInSuperClass in SuperClass but due to inheritance also in SubClass. Assuming both are legitimate for injection (none is disabled via specialization), then you are now facing an ambiguous dependency exception as you have two producers for same bean type with same bean qualifiers because SuperClass and SubClass are two different beans and both contain a producer.
          I would say that's fair reason for disabling inheritance on producers. Furthermore, still with inheritance on, you could then override the method in subclass and more questions arise - do you keep both or do you disable original one? If you keep them, what would be the limitations on the new method? What if you decide for either and then you @Vetoed one of the beans?



          From my perspective it is simply a design decision. Probably in place to prevent further confusion. While I know this isn't the answer so you are probably looking for, questioning so old designs rarely comes with more accurate answers :-)






          share|improve this answer




















          • The example can be found at: github.com/1and1/ejb-cdi-unit/blob/rework-analyzing/…. Overriding the producer: I did that to show a workaround to the restriction of not being able to inherit Produces. Concerning the general concept of overriding: That is done at other places in the spec quit well. i.e. Injected initializers, PostConstruct, PreDestroy, so the overriding-concept should not be an issue.
            – aschoerk
            Nov 5 at 19:50














          5












          5








          5






          Is there any reason why you operate on static classes only? Producer needs to be placed on an actual CDI bean to be recognized. Your sample is torn from context so I cannot say if they will actually be recognized as beans.



          However, transferring your sample to a non-static test case (with some @Vetoed beans and producers for them), it will run just as you expect it - both producers would be found and produce injectable beans. So maybe you need to share a complete reproducible sample and we can go from there.



          I suspect the inheritance you are asking about is not the actual problem here.
          Anyway, it is designed like that since CDI 1.0 so finding a discussion on that would be troublesome at best (no JIRA issue at least, I did check there).
          But one reason coming to mind right away - assume inheritance was in place for producers. Then your above scenario would have a producer for ProducedInSuperClass in SuperClass but due to inheritance also in SubClass. Assuming both are legitimate for injection (none is disabled via specialization), then you are now facing an ambiguous dependency exception as you have two producers for same bean type with same bean qualifiers because SuperClass and SubClass are two different beans and both contain a producer.
          I would say that's fair reason for disabling inheritance on producers. Furthermore, still with inheritance on, you could then override the method in subclass and more questions arise - do you keep both or do you disable original one? If you keep them, what would be the limitations on the new method? What if you decide for either and then you @Vetoed one of the beans?



          From my perspective it is simply a design decision. Probably in place to prevent further confusion. While I know this isn't the answer so you are probably looking for, questioning so old designs rarely comes with more accurate answers :-)






          share|improve this answer












          Is there any reason why you operate on static classes only? Producer needs to be placed on an actual CDI bean to be recognized. Your sample is torn from context so I cannot say if they will actually be recognized as beans.



          However, transferring your sample to a non-static test case (with some @Vetoed beans and producers for them), it will run just as you expect it - both producers would be found and produce injectable beans. So maybe you need to share a complete reproducible sample and we can go from there.



          I suspect the inheritance you are asking about is not the actual problem here.
          Anyway, it is designed like that since CDI 1.0 so finding a discussion on that would be troublesome at best (no JIRA issue at least, I did check there).
          But one reason coming to mind right away - assume inheritance was in place for producers. Then your above scenario would have a producer for ProducedInSuperClass in SuperClass but due to inheritance also in SubClass. Assuming both are legitimate for injection (none is disabled via specialization), then you are now facing an ambiguous dependency exception as you have two producers for same bean type with same bean qualifiers because SuperClass and SubClass are two different beans and both contain a producer.
          I would say that's fair reason for disabling inheritance on producers. Furthermore, still with inheritance on, you could then override the method in subclass and more questions arise - do you keep both or do you disable original one? If you keep them, what would be the limitations on the new method? What if you decide for either and then you @Vetoed one of the beans?



          From my perspective it is simply a design decision. Probably in place to prevent further confusion. While I know this isn't the answer so you are probably looking for, questioning so old designs rarely comes with more accurate answers :-)







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 5 at 12:47









          Siliarus

          3,6721519




          3,6721519











          • The example can be found at: github.com/1and1/ejb-cdi-unit/blob/rework-analyzing/…. Overriding the producer: I did that to show a workaround to the restriction of not being able to inherit Produces. Concerning the general concept of overriding: That is done at other places in the spec quit well. i.e. Injected initializers, PostConstruct, PreDestroy, so the overriding-concept should not be an issue.
            – aschoerk
            Nov 5 at 19:50

















          • The example can be found at: github.com/1and1/ejb-cdi-unit/blob/rework-analyzing/…. Overriding the producer: I did that to show a workaround to the restriction of not being able to inherit Produces. Concerning the general concept of overriding: That is done at other places in the spec quit well. i.e. Injected initializers, PostConstruct, PreDestroy, so the overriding-concept should not be an issue.
            – aschoerk
            Nov 5 at 19:50
















          The example can be found at: github.com/1and1/ejb-cdi-unit/blob/rework-analyzing/…. Overriding the producer: I did that to show a workaround to the restriction of not being able to inherit Produces. Concerning the general concept of overriding: That is done at other places in the spec quit well. i.e. Injected initializers, PostConstruct, PreDestroy, so the overriding-concept should not be an issue.
          – aschoerk
          Nov 5 at 19:50





          The example can be found at: github.com/1and1/ejb-cdi-unit/blob/rework-analyzing/…. Overriding the producer: I did that to show a workaround to the restriction of not being able to inherit Produces. Concerning the general concept of overriding: That is done at other places in the spec quit well. i.e. Injected initializers, PostConstruct, PreDestroy, so the overriding-concept should not be an issue.
          – aschoerk
          Nov 5 at 19:50


















          draft saved

          draft discarded
















































          Thanks for contributing an answer to Stack Overflow!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid


          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.

          To learn more, see our tips on writing great answers.





          Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


          Please pay close attention to the following guidance:


          • Please be sure to answer the question. Provide details and share your research!

          But avoid


          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.

          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53082162%2fwhy-are-producers-not-inherited-in-cdi%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          𛂒𛀶,𛀽𛀑𛂀𛃧𛂓𛀙𛃆𛃑𛃷𛂟𛁡𛀢𛀟𛁤𛂽𛁕𛁪𛂟𛂯,𛁞𛂧𛀴𛁄𛁠𛁼𛂿𛀤 𛂘,𛁺𛂾𛃭𛃭𛃵𛀺,𛂣𛃍𛂖𛃶 𛀸𛃀𛂖𛁶𛁏𛁚 𛂢𛂞 𛁰𛂆𛀔,𛁸𛀽𛁓𛃋𛂇𛃧𛀧𛃣𛂐𛃇,𛂂𛃻𛃲𛁬𛃞𛀧𛃃𛀅 𛂭𛁠𛁡𛃇𛀷𛃓𛁥,𛁙𛁘𛁞𛃸𛁸𛃣𛁜,𛂛,𛃿,𛁯𛂘𛂌𛃛𛁱𛃌𛂈𛂇 𛁊𛃲,𛀕𛃴𛀜 𛀶𛂆𛀶𛃟𛂉𛀣,𛂐𛁞𛁾 𛁷𛂑𛁳𛂯𛀬𛃅,𛃶𛁼

          Edmonton

          Crossroads (UK TV series)