Scope of what bean archives an extension applies to
by John D. Ament
Hi all,
Quick question. This is mostly from playing around with Weld SE
2.1.2, so I'm not sure if my question is going to be Weld SE specific
or be generally applied.
Looking through the spec, I did not see any obvious indications of
this. What is the scope of the application of an Extension class?
Suppose I had a JAR file that had
META-INF/services/javax.enterprise.inject.spi.Extension with the
contents of some extension class. Should the application of that
extension class apply to all JARs within the same classpath? If that
extension were listed in a WAR file, would it apply to the WAR and all
JAR modules?
John
10 years, 9 months
[JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage in the spec
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-280?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand commented on CDI-280:
------------------------------------------
{quote}
I don't think this clarification will help to understand "5.5.8 Bean metadata" better (this section is just complicated).
{quote}
Yes, I agree: more example sooner in this chapter would benefit understanding.
{quote}
I wouldn't introduce Bean Metadata but rather continue with Bean. Bean Metadata might be more correct but also possible source of confusion.
{quote}
In fact Bean Metadata is already introduced : 5.5.8 use this term many times. And I really think we should have distinctive name between the bean instance and the bean metadata, it's the purpose of this ticket.
{quote}
We should definitely check whether we use Bean instance (aka contextual instance of a Bean) consistently.
{quote}
In theory it's the best term, but everybody use the *Bean* abbreviation. So, IMO, we really should reserved the term *Bean* to shorten the *Bean Instance* and for nothing else. That said I agree we should try to use *Bean Instance* in the spec.
{quote}
Proxy - I'm not sure, to my understanding client proxy and contextual reference are synonyms with some formal differences
{quote}
Yes they're synonyms. I prefer *Bean Reference* but there are so much occurrence of *Proxy* or *Client proxy* in the spec that I hesitate to switch to *Bean Reference*.
{quote}
InjectionPoint Type - NOK, the spec uses required type consistently (see 5.2 Typesafe resolution), also I don't see any confusion here
{quote}
Agree
> clarify usage of 'bean' term usage in the spec
> ----------------------------------------------
>
> Key: CDI-280
> URL: https://issues.jboss.org/browse/CDI-280
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Mark Struberg
> Labels: CDI_api_chge, CDI_spec_chge, Ready_to_fix
> Fix For: 1.2 Proposed
>
>
> We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for
> * The Bean<T> extends Contextual<T>. Should be referred as 'Bean' or 'CDI Bean'
> * The class which gets scanned. Should be referred as 'Bean Class' to
> * The instance stored in the context. Should be referred to as 'Contextual Instance'
> * The proxy for a Contextual Instance should be referred to as 'Contextual Reference'
> * The type of an injection point should be referred to as 'InjectionPoint Type'
--
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
10 years, 10 months
[JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage in the spec
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/CDI-280?page=com.atlassian.jira.plugin.sy... ]
Martin Kouba commented on CDI-280:
----------------------------------
I don't think this clarification will help to understand "5.5.8 Bean metadata" better (this section is just complicated).
I wouldn't introduce *Bean Metadata* but rather continue with *Bean*. *Bean Metadata* might be more correct but also possible source of confusion.
We should definitely check whether we use *Bean instance* (aka contextual instance of a *Bean*) consistently.
*Bean Class* - OK
*Proxy* - I'm not sure, to my understanding _client proxy_ and _contextual reference_ are synonyms with some formal differences
*InjectionPoint Type* - NOK, the spec uses _required type_ consistently (see 5.2 Typesafe resolution), also I don't see any confusion here
*Session bean* - OK
> clarify usage of 'bean' term usage in the spec
> ----------------------------------------------
>
> Key: CDI-280
> URL: https://issues.jboss.org/browse/CDI-280
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Mark Struberg
> Labels: CDI_api_chge, CDI_spec_chge, Ready_to_fix
> Fix For: 1.2 Proposed
>
>
> We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for
> * The Bean<T> extends Contextual<T>. Should be referred as 'Bean' or 'CDI Bean'
> * The class which gets scanned. Should be referred as 'Bean Class' to
> * The instance stored in the context. Should be referred to as 'Contextual Instance'
> * The proxy for a Contextual Instance should be referred to as 'Contextual Reference'
> * The type of an injection point should be referred to as 'InjectionPoint Type'
--
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
10 years, 10 months
Please review proposed names in CDI-280
by Antoine Sabot-Durand
Hi Al,
CDI-280 - clarify usage of 'bean' term usage in the spec [1] is one of the longest ticket to treat as it involves re-reading all the spec and check the name fro all « bean » occurrences in the text. I counted 1904 occurrences in the spec, didn’t check the Javadoc but there should be a bunch too here.
All this to say that this ticket should be started very soon. I made a final proposal for the name and put the ticket in Ready_to_fix mode. That means that if you have concern with my proposed names you should raise your hand before friday 4:00pm GMT.
Thanks for your input including conter proposal if you don’t like mine.
Antoine
[1] https://issues.jboss.org/browse/CDI-280
10 years, 10 months
[JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage in the spec
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-280?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-280:
-------------------------------------
Comment: was deleted
(was: While we implicitly included CDI-406 in this ticket we missed CDI-404. We should analyse the impact of adding {{@Interceptor}} and {{@Decorator}} in the list of bean defining annotations.)
> clarify usage of 'bean' term usage in the spec
> ----------------------------------------------
>
> Key: CDI-280
> URL: https://issues.jboss.org/browse/CDI-280
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Mark Struberg
> Labels: CDI_api_chge, CDI_spec_chge, Ready_to_fix
> Fix For: 1.2 Proposed
>
>
> We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for
> * The Bean<T> extends Contextual<T>. Should be referred as 'Bean' or 'CDI Bean'
> * The class which gets scanned. Should be referred as 'Bean Class' to
> * The instance stored in the context. Should be referred to as 'Contextual Instance'
> * The proxy for a Contextual Instance should be referred to as 'Contextual Reference'
> * The type of an injection point should be referred to as 'InjectionPoint Type'
--
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
10 years, 10 months
[JBoss JIRA] (CDI-280) clarify usage of 'bean' term usage in the spec
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-280?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-280:
-------------------------------------
Labels: CDI_api_chge CDI_spec_chge Ready_to_fix (was: CDI_spec_chge)
> clarify usage of 'bean' term usage in the spec
> ----------------------------------------------
>
> Key: CDI-280
> URL: https://issues.jboss.org/browse/CDI-280
> Project: CDI Specification Issues
> Issue Type: Clarification
> Reporter: Mark Struberg
> Labels: CDI_api_chge, CDI_spec_chge, Ready_to_fix
> Fix For: 1.2 Proposed
>
>
> We should go to the spec and look up all 'bean' words as they are 5 different meaning the word 'bean' is used for
> * The Bean<T> extends Contextual<T>. Should be referred as 'Bean' or 'CDI Bean'
> * The class which gets scanned. Should be referred as 'Bean Class' to
> * The instance stored in the context. Should be referred to as 'Contextual Instance'
> * The proxy for a Contextual Instance should be referred to as 'Contextual Reference'
> * The type of an injection point should be referred to as 'InjectionPoint Type'
--
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
10 years, 10 months
[JBoss JIRA] (CDI-408) bean-discovery-mode="annotated" and Producers/Observers in @Dependent beans
by Antoine Sabot-Durand (JIRA)
[ 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
10 years, 10 months
[JBoss JIRA] (CDI-377) automatic JSR-330 annotation processing problematic
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-377?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-377:
-------------------------------------
Labels: CDI_spec_chge CDI_tck_chge Ready_to_fix (was: CDI_spec_chge CDI_tck_chge)
> automatic JSR-330 annotation processing problematic
> ---------------------------------------------------
>
> Key: CDI-377
> URL: https://issues.jboss.org/browse/CDI-377
> Project: CDI Specification Issues
> Issue Type: Bug
> Components: Java EE integration
> Affects Versions: 1.1.PFD
> Environment: glassfish-4
> Reporter: Reuben Pasquini
> Assignee: Antoine Sabot-Durand
> Labels: CDI_spec_chge, CDI_tck_chge, Ready_to_fix
> Fix For: 1.2 Proposed
>
>
> The jsr-330 dependency injection annotations (javax.inject.*) find use in javase environments using IOC packages like guice.
> Adding a dependency on a jar that uses guice or whatever in a javase environment
> to a war deployed to a jee7 container
> results in CDI processing annotated classes intended for
> app-managed injection. See this ticket filed with guava for a concrete example:
> https://code.google.com/p/guava-libraries/issues/detail?id=1433
--
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
10 years, 10 months
[JBoss JIRA] (CDI-404) adding bean-defining annotations for Interceptor while setting bean-discovery-mode="annotated"
by Antoine Sabot-Durand (JIRA)
[ https://issues.jboss.org/browse/CDI-404?page=com.atlassian.jira.plugin.sy... ]
Antoine Sabot-Durand updated CDI-404:
-------------------------------------
Labels: CDI_spec_chge CDI_tck_chge Ready_to_fix (was: CDI_spec_chge CDI_tck_chge)
> adding bean-defining annotations for Interceptor while setting bean-discovery-mode="annotated"
> -----------------------------------------------------------------------------------------------
>
> Key: CDI-404
> URL: https://issues.jboss.org/browse/CDI-404
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans
> Affects Versions: 1.1.PFD
> Reporter: Tang Yong
> Assignee: Antoine Sabot-Durand
> Labels: CDI_spec_chge, CDI_tck_chge, Ready_to_fix
> Fix For: 1.2 Proposed
>
>
> [1] and [2] has reported an issue about
> bean-discovery-mode="annotated". Although there are some workarounds for
> the issue, I think that in the future, we should support interceptor
> implict scanning while an user uses bean-discovery-mode="annotated".
> Apparently, just as bean-discovery-mode="annotated", CDI Spec and
> Interceptor Spec are disconnected.
> [1]:https://java.net/jira/browse/GLASSFISH-20667
> [2]:http://stackoverflow.com/questions/17258639/interceptor-issue-with-jav...
> About detailed discussion, please seeing the following,
> https://java.net/projects/javaee-spec/lists/users/archive/2013-09/message/7
--
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
10 years, 10 months
