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

[Gavin King]

What it's saying is that:

* suppose I have a class X that is deployed in an archive in the
classpath, or an EJB  X that is deployed in an EJB jar
* and that archive or EJB jar does not have a beans.xml file
* then, of course, the archive or EJB jar will not get automatically
scanned for beans,
* and so, as always, I can't write @Inject X or get an X by programmatic lookup.

However, what we do now let you do is write @Inject @New X or @Inject
@New Instance<X>.

We need this in order to allow us to integrate with existing library
jars or EJB jars that were not designed for use with 299, and which
therefore don't have a beans.xml file, or don't have qualifiers or
scopes defined as annotations on the bean classes.

An example usecase for this was given by Jim: a pre-existing jar
written for use with Guice or Spring, that contains 330 annotations,
but not the bean-defining annotations needed by 299. This
change/clarification allows us to integrate these bean classes by
writing producer methods, as demonstrated by Pete's code.

Now, because these archives are not being scanned, the 299
implementation needs to identify these classes by inspecting injection
points with the @New annotation. Therefore, we won't be able to
guarantee that BeanManager.getBeans() or Instance.get() will work when
@New is passed dynamically as a method parameter. Pete and I discussed
this and both agreed that it is not a real problem. We can't think of
a usecase where you would sometimes want a normal bean instance, and
other times a @New bean instance.

On Mon, Oct 19, 2009 at 12:03 PM, Roberto Chinnici
<Roberto.Chinnici at sun.com> wrote:

> I'm reading 3.12 and I have trouble understanding how a class inside an
> archive which is NOT a bean deployment archive could give rise to a managed
> bean (at least in the sense of 299). It seems then that the premise of 3.12
> is empty and no second beans will ever be created.

The 299 implementation will discover the class by looking at the
injection point with the @New annotation, and register it as a managed
bean. It's status will be just like the status of an EJB in an EJB jar
with no beans.xml file.

> And I don't think you
> meant for DriversSeat and SpareTire in your example to be annotated with
> @ManagedBean, since the 330 TCK doesn't do that.

I have no idea what the @ManagedBean annotation is doing, it is not needed.

> Also, I'm not sure why you excluded @New in 11.3.4. Doesn't that make the
> SPI less powerful than the annotations?

It's a slight limitation, but is needed, since archives which are not
bean deployment archives are not scanned at startup time.


-- 
Gavin King
gavin.king at gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org