[JBoss JIRA] Created: (CDI-49) The availability of the BeanManager should follow the normal EE visibility rules
by Aslak Knutsen (JIRA)
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: Specification
Affects Versions: 1.0
Environment: JSR-000316 Java Platform, Enterprise Edition 6 Specification
Reporter: Aslak Knutsen
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
13 years, 10 months
[JBoss JIRA] Created: (CDI-44) Clarify that interceptors must be implemented using subclassing, and clarify the behaviour of self-invocation
by Stuart Douglas (JIRA)
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
Reporter: Stuart Douglas
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
13 years, 10 months
[JBoss JIRA] Created: (CDI-47) Add required attribute to <interceptor> tag in beans.xml
by Stuart Douglas (JIRA)
Add required attribute to <interceptor> tag in beans.xml
---------------------------------------------------------
Key: CDI-47
URL: https://issues.jboss.org/browse/CDI-47
Project: CDI Specification Issues
Issue Type: Feature Request
Reporter: Stuart Douglas
Currently the deployment will fail if an interceptor is not present, which means that it is not conventient to use interceptors from optional modules, as the end user will need to open up the jar file and edit the beans.xml file manually.
For example, currently Seam Security has a hard dependency on Seam Persistence because it uses the Transaction interceptor, and the deployment will fail if Seam Persistence is not present.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months
[JBoss JIRA] Created: (CDI-48) Global interceptor ordering
by Stuart Douglas (JIRA)
Global interceptor ordering
---------------------------
Key: CDI-48
URL: https://issues.jboss.org/browse/CDI-48
Project: CDI Specification Issues
Issue Type: Feature Request
Reporter: Stuart Douglas
Currently interceptor ordering is specified on a per bean archive level. In the majority of cases the correct ordering is the same for every BDA in the application, so this violates DRY and opens the door to nasty bugs due to different ordering per module if beans.xml files get out of sync.
We should look at allowing the user to define interceptor ordering once per app and have this applied to all modules in the deployment.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 10 months