[JBoss JIRA] (CDI-271) Provide a way to inject Event metadata into an observer method
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-271?page=com.atlassian.jira.plugin.sy... ]
Pete Muir resolved CDI-271.
---------------------------
Resolution: Done
At this point, I don't want to add new features like supporting BeanManager here. So Arne, can you create a new issue for that?
> Provide a way to inject Event metadata into an observer method
> --------------------------------------------------------------
>
> Key: CDI-271
> URL: https://issues.jboss.org/browse/CDI-271
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Events
> Reporter: Arne Limburg
> Assignee: Arne Limburg
> Fix For: 1.1.PFD
>
>
> Currently there is no way for observer methods to access the qualifiers of the fired event (i.e. to access @Nonbinding members).
> Consider the following example:
> {code}
> @Inject @MyQualifier
> Event<MyObject> event;
> public void fireEvent(MyObject object, MyTypeValue type) {
> event.select(new MyTypeAnnotationLiteral(type)).fire(object);
> }
> {code}
> Currently no observer can receive the value of MyTypeValue. I suggest to introduce an interface AnnotatedEvent that extends Annotated and contains this information. It then could be injected via the InjectionPoint like this:
> {code}
> public void observeEvent(@Observes @MyType MyObject object, InjectionPoint ip) {
> MyType annotation = ip.getAnnotated().getAnnotation(MyType.class);
> MyTypeValue value = annotation.value();
> ...
> }
> {code}
--
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
11 years, 2 months
[JBoss JIRA] (CDI-129) Clarify behaviour of @ApplicationScoped in EARs
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-129?page=com.atlassian.jira.plugin.sy... ]
Pete Muir updated CDI-129:
--------------------------
Fix Version/s: TBD
(was: 1.1.PFD)
> Clarify behaviour of @ApplicationScoped in EARs
> -----------------------------------------------
>
> Key: CDI-129
> URL: https://issues.jboss.org/browse/CDI-129
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Contexts
> Affects Versions: 1.0
> Reporter: Mark Struberg
> Assignee: Pete Muir
> Labels: application-scoped, visibility
> Fix For: TBD
>
>
> Since @ApplicationScoped currently is defined in 6.5.2 as to be 'like in the Servlet specification' this means that you will get a new instance for every WebApplication (WAR file).
> There is currently no specified CDI scope for providing a single shared instance for a whole EAR.
> We could (ab-)use @Singleton for that, but this is currently not well defined at all.
> Alternatively we could introduce an own new annotation like @EnterpriseScoped or likes.
--
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
11 years, 2 months
[JBoss JIRA] (CDI-3) Add add an event that fires after all ProcessAnnotatedType events that allows you to add new AnnotatedTypes
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-3?page=com.atlassian.jira.plugin.syst... ]
Pete Muir resolved CDI-3.
-------------------------
Assignee: Pete Muir
Resolution: Done
Merged
> Add add an event that fires after all ProcessAnnotatedType events that allows you to add new AnnotatedTypes
> ------------------------------------------------------------------------------------------------------------
>
> Key: CDI-3
> URL: https://issues.jboss.org/browse/CDI-3
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Portable Extensions
> Affects Versions: 1.0
> Reporter: Stuart Douglas
> Assignee: Pete Muir
> Priority: Critical
> Fix For: 1.1.PFD
>
>
> At the moment AnnotatedTypes can only be added in the BeforeBeanDiscovery phase. This means that if you want to install additional beans based on the beans processed in the ProcessAnnotatedType phase you must instead add implementations of the Bean interface in the AfterBeanDiscovery phase. This interface is more limited than annotated type, and does not let you exactly mimic the behaviour of beans added as AnnotatedTypes.
> Some of the things that the bean interface will not let you mimic are:
> - Interceptors
> - Disposal methods
> - Producer fields for normal scoped beans
--
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
11 years, 2 months
[JBoss JIRA] (CDI-18) Global enablement of interceptors, decorators and alternatives
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-18?page=com.atlassian.jira.plugin.sys... ]
Pete Muir resolved CDI-18.
--------------------------
Resolution: Done
Merged
> Global enablement of interceptors, decorators and alternatives
> --------------------------------------------------------------
>
> Key: CDI-18
> URL: https://issues.jboss.org/browse/CDI-18
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Beans, Decorators, Interceptors, Packaging and Deployment
> Affects Versions: 1.0
> Reporter: Mark Struberg
> Assignee: Pete Muir
> Priority: Critical
> Fix For: 1.1.PRD
>
>
> Currently the spec defines that <interceptors>, <decorators> and <alternatives> affect only the Bean Archives where they are configured in (via beans.xml).
> Thus if you e.g. enable an Alternative in a WEB-INF/beans.xml, it does NOT count for the jars in it's WEB-INF/lib folder!
> This is pretty unhandy because you would need to repackage all your jars in your WEB-INF/lib folder and add/expand the <alternatives> sections in their beans.xml.
> Needless to say that this is not only hard to do in a company build but is also impossibly to handle at deploy time in an OSGi environment!
--
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
11 years, 2 months
[JBoss JIRA] (CDI-321) Application wide CDI enablement
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-321?page=com.atlassian.jira.plugin.sy... ]
Pete Muir resolved CDI-321.
---------------------------
Resolution: Done
Merged
> Application wide CDI enablement
> -------------------------------
>
> Key: CDI-321
> URL: https://issues.jboss.org/browse/CDI-321
> Project: CDI Specification Issues
> Issue Type: Bug
> Reporter: Pete Muir
> Assignee: Pete Muir
> Fix For: 1.1.PFD
>
>
> We introduce the concept of a "bean defining annotation" and define that any class in any deployment (including those with no beans.xml) with a bean defining annotation is discovered and may be a CDI bean, and can participate fully in the application. Any archive with a beans.xml continues to work in the same way, such that all classes in the archive are discovered and may be CDI beans.
> This addresses the startup time problem. Whilst a scan of classes is still required, the impact on startup time is negligible:
> * A Java EE server must scan all classes to discover other component defining annotations such as EJBs, Servlet's, JAX-RS resources etc.
> * This scan can be done at the bytecode level, with no need to classload the class, which our research shows is the costly part of CDI startup
> Any scope (normal scope or pseudo-scope) applied to a bean at source level is a bean defining annotation (so you must add @Dependent to your class in order to get it to be picked up as a dependent bean).
> Only classes with a bean defining annotation, or with an annotation, or meta-annotation, present specified by @WithAnnotations are passed to ProcessAnnotatedType observers (the exact semantics are defined by CDI 1.1 PRD for @WithAnnotations). As mentioned above, if a ProcessAnnotatedType is observed for a type without a bean defining annotation, as a result of having an annotation present that is specified by @WithAnnotations, it may instruct the container to add discover the class as a bean.
> Every archive in a deployment would be considered a bean archive, simply with differing contents depending on the presence of beans.xml
> If a developer adds a beans.xml to their archive, behavior is as CDI 1.0. We will add an attribute to beans.xml "auto-discover=true", which the user may set to false in order to add a beans.xml and only have classes with a bean defining annotation discovered, which allows beans.xml to be used as a deployment descriptor but still limit the classes discovered.
> OPEN ISSUE: Should auto-discover be false by default for beans.xml with version 1.1. This would mean that adding a beans.xml would have no impact on discovery for 1.1 apps, however it is a significant change from 1.0.
> OPEN ISSUE: Should only scopes for which a CDI context exists be considered component defining? This could introduce some thorny edge cases, but would address the JSR-330 compatibility issue better.
> OPEN ISSUE: Should we extend auto-discover in beans.xml to allow complete disablement of scanning e.g. auto-discover="all|bean-defining-annotations-only|none" ?
> OPEN ISSUE: How should the ProcessAnnotatedType event instruct the container to discover a class as a bean? Perhaps something like event.discover(clazz)?
> OPEN ISSUE: Should we integrate this with the package level scanning control we have proposed for CDI 1.1?
--
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
11 years, 2 months
[JBoss JIRA] (CDI-44) Clarify that interceptors must be implemented using subclassing, and clarify the behaviour of self-invocation
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-44?page=com.atlassian.jira.plugin.sys... ]
Pete Muir resolved CDI-44.
--------------------------
Resolution: Done
Merged
> Clarify that interceptors must be implemented using subclassing, and clarify the behaviour of self-invocation
> -------------------------------------------------------------------------------------------------------------
>
> Key: CDI-44
> URL: https://issues.jboss.org/browse/CDI-44
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Interceptors
> Affects Versions: 1.0
> Reporter: Stuart Douglas
> Assignee: Pete Muir
> Fix For: 1.1.PFD
>
>
> When implementing interception using proxying the behaour of self invocation is quite well defined, if a method is invoked on the proxy it is intercepted, if it is invoked on the actual bean (usually through self-invocation) it is not.
> When implementing interception though sub classing this is much less well definied, and the only way to track if an invocation is intercepted or not is through a thread local flag. At the moment in weld this is reset when a call is made on a client proxy, so if we have an intercepted bean A and a SessionScoped bean B and A invokes B when invokes A the second call to A is intercepted. If however B is pseudo scoped, then the second invocation is not intercepted. The correct behaviour here should be specified by the specification.
--
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
11 years, 2 months
[JBoss JIRA] (CDI-200) ProcessBeanAttributes needs clarification
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-200?page=com.atlassian.jira.plugin.sy... ]
Pete Muir resolved CDI-200.
---------------------------
Resolution: Done
> ProcessBeanAttributes needs clarification
> -----------------------------------------
>
> Key: CDI-200
> URL: https://issues.jboss.org/browse/CDI-200
> Project: CDI Specification Issues
> Issue Type: Clarification
> Components: Portable Extensions
> Affects Versions: 1.1.EDR
> Reporter: Jozef Hartinger
> Assignee: Pete Muir
> Labels: visibility
> Fix For: 1.1.PFD
>
>
> The specification should clarify the following cases:
> (1) whether the ProcessBeanAttributes event should be fired for Beans registered using AfterBeanDiscovery.addBean() - if yes, it is necessary to clarify what would the value returned by PBA.getAnnotated() be.
> (2) whether the ProcessBeanAttributes event should be fired for built-in beans (my interpretation is that this is not required)
> (3) The attributes represented by a BeanAttributes object are not completely independent. It is necessary to clarify how the set BeanAttributes object is treated. I can see two options:
> (a) the container takes the final values of a BeanAttributes object and uses them
> (b) the container itself updates certain attributes to match CDI rules for example
> ** if an extension adds a @Named qualifier to the set of qualifiers, this change is automatically reflected within the name attribute
> ** if an extension adds a stereotype, which is (transitively) annotated with @Named, the default name is implied and reflected within the name attribute
> ** if an extension adds a stereotype, which is (transitively) annotated with @Alternative, this fact is reflected within the isAlternative attribute
> ** if an extension adds a stereotype, which is (transitively) annotated with a scope annotation, this fact is reflected within the scope attribute
> In theory, conflicts may occur where for example an extension may set different values for the @Named qualifier and for the name attribute. With the latter approach, an extension loses part of the control. On the other hand, this approach may be more convenient.
> Another area that needs clarification is specialization. Suppose having beans A and B where B specializes A. According to the specification, the result of specialization should be visible at the time the ProcessBeanAttributes event is fired for B (the qualifiers and name of B are updated with values of A). The scenarios that need clarification are:
> (4) In the ProcessBeanAttributes phase, a qualifier is added to A (making B no longer a valid substite of A). Should the container detect this as a definition error or rather apply specialization (update the set of qualifiers of B) once again? The same applies for name.
> (5) Similarly, the set of qualifiers of B may be reduced by an extension, causing the same problem.
--
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
11 years, 2 months