[cdi-dev] [JBoss JIRA] Issue Comment Edited: (CDI-23) Allow BeanManager to be resolved as though you were in another bean archive

[ https://issues.jboss.org/browse/CDI-23?page=com.atlassian.jira.plugin.sys... ] Pete Muir edited comment on CDI-23 at 5/9/11 10:11 AM: ------------------------------------------------------- {quote} Nor sure if this is really a problem of the spec. Actually I think this is only caused by Weld being organized hierarchically (Not that OWB is better, but you might get other problems). This makes it more flexible for different classloader configurations, but definitely restricts the use in such cases. {quote} Weld uses a peer based organisation not hierarchical, which allows it to be used both in hierarchical classloader configurations such as JBoss AS 6 or in peer based systems such as AS7 or OSGi. Often people encounter it hierarchical situation, but it's worth noting that both are supported. {quote} Please note that it's not defined from 'where' (in which jar) you get which BeanManager instance. {quote} Yes, this is exactly why I am proposing this feature ;-) As you note implementations vary a lot on class visibility (primarily as EE makes few guarantees here), so we need to provide the ability to query this information in the spec, so that extensions do not start using non-portable assumptions. {quote} In OWB we manage the different BeanManager instances on a ContextClassLoader base by default (can be changed via SPI) So all classes accessed in the same WebApp get the same ClassLoader. {quote} Remember that CDI must address many different deployment structures, of which a War with libraries is just one. {quote} Also: Extensions must not assume a certain classloader or BeanManager hierarchy for being portable - because there is no such thing defined in the spec (neither in CDI nor in EE umbrella). {quote} Exactly. However it is often useful to be able to query what beans are installed in another bean archive, for example in the issue I linked. Let's take another example. If an extension is provided in a shared library, then it would currently see the BM which is applicable for the bean archive for that shared library, however it might wish to query the beans installed into bean archive which is applicable for the WAR. So in conclusion, it's not a "problem of the spec" but rather a problem that extensions encounter and therefore need the specification to provide some abstraction so that this information can be retrieved in a portable fashion. was (Author: petemuir): "Nor sure if this is really a problem of the spec. Actually I think this is only caused by Weld being organized hierarchically (Not that OWB is better, but you might get other problems). This makes it more flexible for different classloader configurations, but definitely restricts the use in such cases." Weld uses a peer based organisation not hierarchical, which allows it to be used both in hierarchical classloader configurations such as JBoss AS 6 or in peer based systems such as AS7 or OSGi. Often people encounter it hierarchical situation, but it's worth noting that both are supported. "Please note that it's not defined from 'where' (in which jar) you get which BeanManager instance." Yes, this is exactly why I am proposing this feature ;-) As you note implementations vary a lot on class visibility (primarily as EE makes few guarantees here), so we need to provide the ability to query this information in the spec, so that extensions do not start using non-portable assumptions. "In OWB we manage the different BeanManager instances on a ContextClassLoader base by default (can be changed via SPI) So all classes accessed in the same WebApp get the same ClassLoader." Remember that CDI must address many different deployment structures, of which a War with libraries is just one. "Also: Extensions must not assume a certain classloader or BeanManager hierarchy for being portable - because there is no such thing defined in the spec (neither in CDI nor in EE umbrella)." Exactly. However it is often useful to be able to query what beans are installed in another bean archive, for example in the issue I linked. Let's take another example. If an extension is provided in a shared library, then it would currently see the BM which is applicable for the bean archive for that shared library, however it might wish to query the beans installed into bean archive which is applicable for the WAR. So in conclusion, it's not a "problem of the spec" but rather a problem that extensions encounter and therefore need the specification to provide some abstraction so that this information can be retrieved in a portable fashion. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira