[
https://issues.jboss.org/browse/CDI-408?page=com.atlassian.jira.plugin.sy...
]
Antoine Sabot-Durand commented on CDI-408:
------------------------------------------
IMHO we have 3 solution to address this issue (
# Add to the bean defining annotation list {{@Produces}} and {{@Observes}}. That will add
to the list annotations *inside* a class.
# Detect {{@Produces}} and {{@Observes}} in class that don't have bean defining
annotation and warn the user at boot time. It seems to be a work very close to previous
point in term of scanning.
# Do nothing in the container and only document in spec the fact that in {{annotated}}
mode these will be ignored silently. Not very user friendly but
{{bean-discovery-mode=all}} is not out of reach ;).
Ideally I would prefer the first solution but do we have time to implement this for the
MR? Input from implementors ([~jharting], [~struberg] or [~mkouba]) seems mandatory here.
bean-discovery-mode="annotated" and Producers/Observers in
@Dependent beans
---------------------------------------------------------------------------
Key: CDI-408
URL:
https://issues.jboss.org/browse/CDI-408
Project: CDI Specification Issues
Issue Type: Clarification
Components: Beans
Reporter: Jens Schumann
Assignee: Antoine Sabot-Durand
Labels: CDI_spec_chge
Fix For: 1.2 Proposed
Right now bean-discovery-mode="annotated" skips beans that are not annotated
with an bean-defining annotation even if they contain an observer method or producer
method/field. I would not recommend having (not annotated) @Dependent beans with @Observes
or @Produces - I just had them by accident while playing around with Wildfly.
However there are two impacts:
1. Someone might be confused by ignored @Producer's. Not a major issue here, the CDI
runtime will report it. We could optionally document the behavior in the spec, so it's
clear to everyone. However I think it's inconsistent, since @Produces may contain a
scope (and has a default scope too). Therefore I would vote for @Produces support in
bean-discovery-mode="annotated". Of course the enclosing class is not a managed
bean that may be injected somewhere.
2. Since Observer methods in "not annotated" beans fail silently this can be a
major issue for applications, especially if you migrate from CDI 1.0 (CDI 1.0 source code
and CDI 1.0 thinking model). Therefore I believe @Observer methods have to be included in
bean-discovery-mode="annotated" even if the enclosing bean does not have a
bean-defining annotation. Of course the enclosing class is not a managed bean that may be
injected somewhere.
I understand that the proposal above might have negative impacts on class scanning
performance in bean-discovery-mode="annotated". However silently failing
@Observes can be a major cause of defects that have to be treated because of technical and
political reasons. Technical - because it may cause bugs. And political - because in my
experience many people are still skeptical that CDI events are a trustworthy
achievement[1]. Possibly skipped observer methods won't make live easier.
If you believe the proposal would kill the original intent of
bean-discovery-mode="annotated" please document the impact for Producers and
Observers in the spec and even in the XSD.
--
[1] I have trained a couple hundred people in using CDI and CDI events. And every time I
have to argument against the uncertainty on event delivery: "How do I know which
observers are active?", "Who ensures that event's are delivered?"... I
personally LOVE events;)
Btw: Which JIRA version is CDI 1.1 Final?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira