[weld-dev] [jsr-299-eg] Updated spec with @BeanTypes and clarification of @New

Roberto Chinnici Roberto.Chinnici at Sun.COM
Mon Oct 19 19:55:11 EDT 2009


Pete Muir wrote:
>
> On 19 Oct 2009, at 22:37, Roberto Chinnici wrote:
>
>> JSR-330 doesn't treat anything as a bean, because it only defines DI 
>> annotations.
>> The platform spec (EE.5.19) says that "support for JSR-330 annotations
>> is conditional to their being used by a class which is part of a bean 
>> deployment
>> archive". So there is a conflict.
>
> IMO, no. EE is simply *restricting* where 299 and 330 may be used. 
> Given that EE consumes the 299 and 330 specs, I think this is 
> perfectly valid (whether it is desirable is another matter ;-). I 
> don't see why 299 or 330 need to also restrict themselves in this way.

We need to come up with a consistent view of how it all works together.

>> Well, I can tell you there is an issue. If they were managed beans, 
>> for consistency
>> you should be able to use @Resource and friends with them, but I 
>> don't think the
>> specs (plural) today imply that.
>
> The 299 states this explicitly (not implicitly).
>
> 3.12 defines which beans are new beans
>
>> Note that this second bean exists, is enabled, and is available for 
>> injection whenever the bean class is in the application classpath, 
>> even if the first bean is disabled, as defined by Section 5.2.2, 
>> “Enabled and disabled beans” or is deployed out- side of a bean 
>> deployment archive, as defined in Section 12.1, “Bean deployment 
>> archives”, and is therefore not dis- covered during the bean 
>> discovery process defined in Chapter 12, Packaging and deployment.
>
> This clearly states that any class in the application class path is 
> represented by a new bean. As an optimisation, the implementation may 
> choose to only create new beans for injection points it detects with 
> @New specified.

But that's the issue, because it triggers scanning of all application 
classes. On top of that, it's speculative scanning. If the bean isn't 
discovered until we find a use of the "second bean" (with @New), should 
we tentatively retain as valid all the resources the bean declares, 
during scanning, only to discard them if it turns out the bean does not 
actually exist (i.e. there is no usage with @New)? I'm also starting to 
wonder where this process ends, given that the SPI lets the application 
register new beans at runtime. Does that mean that all resources 
declared anywhere are valid?

> So, we have established that these classes are new (managed) beans.
>
> Now, if you look at 5.6.4, you'll see that the 299 spec requires that 
> Java EE component environment resources are injected into all managed 
> beans.

As Jim pointed out, we were using the term "bean" differently.



More information about the weld-dev mailing list