Why are Producers not inherited in CDI
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
add a comment |
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
add a comment |
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
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
java inversion-of-control cdi weld
edited Nov 8 at 19:47
asked Oct 31 at 11:18
aschoerk
1,3211521
1,3211521
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
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;
...
A simple and reasonable explanation.
– aschoerk
Nov 11 at 10:20
add a comment |
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 :-)
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
add a comment |
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
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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;
...
A simple and reasonable explanation.
– aschoerk
Nov 11 at 10:20
add a comment |
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;
...
A simple and reasonable explanation.
– aschoerk
Nov 11 at 10:20
add a comment |
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;
...
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;
...
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
add a comment |
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
add a comment |
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 :-)
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
add a comment |
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 :-)
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
add a comment |
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 :-)
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 :-)
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
add a comment |
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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