-
Clarification
-
Resolution: Obsolete
-
Minor
-
None
This may have impact, provided that alternatives, interceptors or decorators are used.
- blocks
-
CDITCK-273 CustomBeanImplementationTest does not enable an alternative stereotype in a required archive
-
- Resolved
-
[CDI-233] Specify target bean archive for bean added via AfterBeanDiscovery.addBean()
Martin Kouba
added a comment - To clarify the original problem: An extension does not have to be inside a bean archive. So if it adds an AnnotatedType or a bean, it's not clear what bean archive it belongs to (which may have impact provided the bean has for example an alternative stereotype defined). I wonder if this could be solved by the statement that any archive containing extension is an implicit bean archive?
Since CDI-18 is resolved now, I think the priority of this issue may be lowered.
Martin Kouba
added a comment - To clarify the original problem: An extension does not have to be inside a bean archive. So if it adds an AnnotatedType or a bean, it's not clear what bean archive it belongs to (which may have impact provided the bean has for example an alternative stereotype defined). I wonder if this could be solved by the statement that any archive containing extension is an implicit bean archive?
Since CDI-18 is resolved now, I think the priority of this issue may be lowered. Martin Kouba
added a comment - This applies to BeforeBeanDiscovery.addAnnotatedType() as well. 
Mark Struberg (Inactive)
added a comment - imo we can only solve this cleanly once we defined how BeanManagers and their Extensions in multi-module projects get handled. And this discussion is not yet finished.
Mark Struberg (Inactive)
added a comment - imo we can only solve this cleanly once we defined how BeanManagers and their Extensions in multi-module projects get handled. And this discussion is not yet finished. 
Pete Muir (Inactive)
added a comment - Sorry, I meant bundled library, not shared library. However it looks we're on roughly on the same level here.
Mark, do you have another proposal?
Pete Muir (Inactive)
added a comment - Sorry, I meant bundled library, not shared library. However it looks we're on roughly on the same level here.
Mark, do you have another proposal? Mark Struberg (Inactive)
added a comment - maybe we have different understanding about what 'shared library visibility' means.
I take it as 'class which is contained in a shared ejb-jar.
Of course. Adding a synthetic bean to a shared jar would make it visible to ALL other WAR files. That's not very defensive^^
Mark Struberg (Inactive)
added a comment - maybe we have different understanding about what 'shared library visibility' means.
I take it as 'class which is contained in a shared ejb-jar.
Of course. Adding a synthetic bean to a shared jar would make it visible to ALL other WAR files. That's not very defensive^^ Pete Muir (Inactive)
added a comment - Shared libraries are only visible to the EAR or War they are deployed in normally, so this shouldn't affect other applications. It would affect any web applications deployed in the application, as well as EJB modules etc. only.
Pete Muir (Inactive)
added a comment - Shared libraries are only visible to the EAR or War they are deployed in normally, so this shouldn't affect other applications. It would affect any web applications deployed in the application, as well as EJB modules etc. only. Mark Struberg (Inactive)
added a comment - I fear that would be dangerous. Think about EAR scenarios again. Adding them to a shared level would probably trash other apps.
Mark Struberg (Inactive)
added a comment - I fear that would be dangerous. Think about EAR scenarios again. Adding them to a shared level would probably trash other apps. Pete Muir (Inactive)
added a comment - We propose that for beans whose bean archive cannot be determined (i.e. aren't already in a bean archive) the bean should be given shared library visibility.
Pete Muir (Inactive)
added a comment - We propose that for beans whose bean archive cannot be determined (i.e. aren't already in a bean archive) the bean should be given shared library visibility. Martin Kouba
added a comment - Mark, the BDA concept might be broken. However I'm just pointing out another part of the spec that needs clarification.
Martin Kouba
added a comment - Mark, the BDA concept might be broken. However I'm just pointing out another part of the spec that needs clarification. 
The CDI project is part ofJakarta and uses GitHub issues as it's issue tracking system.
Therefore, all issues in CDI JIRA project are being bulk-closed as described in this GitHub issue.
If you feel like this particular issue deserves ongoing discussion, investigation or fixes in CDI/CDI TCK, please create a new issue under GitHub repository and include a link to this JIRA.
For specification related question/issues, please use - https://github.com/eclipse-ee4j/cdi/issues
For CDI TCK related questions/issues, please use - https://github.com/eclipse-ee4j/cdi-tck/issues