[cdi-dev] Accessiblity of beans

[Pete Muir]

On 22 Oct 2012, at 14:33, Mark Struberg wrote:

> What I DO care about are the visibility rules. Once we deal with scopes broader than 1-per-war (or more generally speaking a scope which is shared over multiple classloaders which don't see each other) and we interpret 5.1 in the way Jozef does than

I'm still not really understanding how scoping particularly affects this. I think this issue is true for any normal scoped bean.

> 
> * any bean defined in a shared lib will not be able to see beans in any webapp. And this even regardless of the scope, even @RequestScoped and @SessionScoped beans defined in an WAR would not be visible. 

For the purposes of my answer, I'm assuming by "see" mean inject.

This is absolutely correct. If we take a look 1.0 of the spec, 5.1.4 (Inter-module injection), we can see it clearly says

"A bean is available for injection in a certain module if ... the bean class is required to be accessible to classes in the module, according to the class accessibility requirements of the module architecture."

The accessibility requirements of Java EE are quite clear, there should *not* be visibility FROM a WAR TO an EAR shared library, and so therefore a bean defined in a WAR is NOT available for injection in an EAR shared library.

> 
> * no class defined in a WAR file would get *any* CDI event originating in a class which is in a shared lib. 

This is not true. The resolution rules for observers are defined in chapter 10, and do not make any reference to 5.1.4, which are anyway about injection, as the section title indicates. Note that this is intended, as it allows events to propagate throughout the application.

> 
> * if you write @Inject User user; you will end up with a different contextual instance than the same code @Inject User user; in a class which is in a shared lib jar.

Without more details of the packaging of these beans I can't make a comment here. But it's certainly the case that injecting a user in one module will not result in the same thing as injecting a user in another module. This is true under any proposed scheme that we've discussed.

What is important here is not that you get a different instance, but that the rules about what instance you get are:

* consistent
* easy to understand
* easy to apply

> * Extension Rules are ambiguous for anything > 1-per-war
> 
> * BeanManager#getBeans(String ), #getBeans(Type, Qualifiers), #resolve(), etc must get fixed

Agreed, there needs to be some increased specification here.

> 
> * Alternatives, Decorators, Interceptors and Specializes in WARs would not work for any classes defined in a shared lib.

You need to provide a little more detail of the problem you see here, as from this, I can't quite gather what you mean ;-)

> 
> 
> If people can live with that, then so be it.

I think this is being a little pejorative towards those who see this as the *best* way to do things. In general, we are going to make better progress on this issue if we try to make rational well reasoned arguments.

> Currently it's not possible to write portable applications for EAR scenarios it seems so I really like to address that in CDI-1.1.

Definitely.

> 
> 
> By using the TCCL as OWB does currently  (and even Weld/JBossAS as far as my tests showed) we could avoid those shortcoming
> at least for all @NormalScoped beans.

Weld should never use the TCCL to determine bean accessibility.