[JBoss JIRA] Updated: (CDI-33) fire ProcessAnnotatedType for AnnotatedTypes added via BBD.addAnnotatedType()
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-33?page=com.atlassian.jira.plugin.sys... ]
Pete Muir updated CDI-33:
-------------------------
Fix Version/s: TBD
> fire ProcessAnnotatedType for AnnotatedTypes added via BBD.addAnnotatedType()
> -----------------------------------------------------------------------------
>
> Key: CDI-33
> URL: https://issues.jboss.org/browse/CDI-33
> Project: CDI Specification Issues
> Issue Type: Task
> Components: Portable Extensions
> Affects Versions: 1.0
> Reporter: Jozef Hartinger
> Fix For: TBD
>
>
> Currently, the ProcessAnnotatedType event is fired for AnnotatedTypes discovered in a BDA only. However, portable extensions are allowed to register other AnnotatedTypes using addAnnotatedType() during the BeforeBeanDiscovery phase. For these AnnotatedTypes, the ProcessAnnotatedType event is not fired.
> However, an extension A may register an AnnotatedType X via addAnnotatedType() and an extension B might want to react on the presence of AnnotatedType X. Therefore, it would be great to have the ProcessAnnotatedType fired also for AnnotatedTypes registered programatically in the BeforeBeanDiscovery phase.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] Updated: (CDI-49) The availability of the BeanManager should follow the normal EE visibility rules
by Pete Muir (JIRA)
[ https://issues.jboss.org/browse/CDI-49?page=com.atlassian.jira.plugin.sys... ]
Pete Muir updated CDI-49:
-------------------------
Fix Version/s: TBD
> The availability of the BeanManager should follow the normal EE visibility rules
> --------------------------------------------------------------------------------
>
> Key: CDI-49
> URL: https://issues.jboss.org/browse/CDI-49
> Project: CDI Specification Issues
> Issue Type: Feature Request
> Components: Java EE integration, Packaging and Deployment, Resolution
> Affects Versions: 1.0
> Environment: JSR-000316 Java Platform, Enterprise Edition 6 Specification
> Reporter: Aslak Knutsen
> Fix For: TBD
>
>
> EE 6 spec
> EE.5.19
> A bean manager is only available in modules in which CDI has been enabled.
> In e.g. a EAR deployment, a WAR module can see a EJB module. With CDI enabled in the EJB, the WAR can only see the BeanManager if the WAR itself is also CDI enabled. In cases where you want to do dynamic introspection of available beans etc, this is a bit cumbersome, especially since the introspecting code can be in a packaged jar inside a unknown WAR..
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] Updated: (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 updated CDI-44:
-------------------------
Fix Version/s: TBD
> 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: Feature Request
> Components: Interceptors
> Affects Versions: 1.0
> Reporter: Stuart Douglas
> Fix For: TBD
>
>
> 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.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months