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

[Gavin King]

On Mon, Oct 19, 2009 at 7:40 PM, Roberto Chinnici
<Roberto.Chinnici at sun.com> wrote:
> Gavin King wrote:
>
> On Mon, Oct 19, 2009 at 5:37 PM, Roberto Chinnici
> <Roberto.Chinnici at sun.com> wrote:
>
>
> Gavin King wrote:
>
> On Mon, Oct 19, 2009 at 1:58 PM, Roberto Chinnici
> <Roberto.Chinnici at sun.com> wrote:
>
>
>
> OK, but the issue is that the class was not already a bean, because it was
> placed (deliberately, I assume) in an archive that is not a bean deployment
> archive.
>
>
> It is certainly NOT true that beans placed in archives that are not
> "bean deployment archives" are not beans. A class annotated
> @ManagedBean or @Stateless is a bean whether or not its archive has a
> beans.xml file.
>
>
> Of course. But neither applied to the case being discussed.
>
>
> On the contrary, this "clarification" to the behavior of @New
> certainly does apply to both these cases.
>
>
> The case being discussed was DriversSeat and SpareTire from the 330 TCK,
> i.e. the latest version of the Producers class you circulated.

OK, so now stick @Stateful on those classes. Would you still argue
that they are not beans? I don't think you would :-)

>
> The "inconsistencies" are between the various specs that together define
> requirements
> for an EE container.

>From what you've told me, there is one new sentence in the EE spec
that is inconsistent with all the other specs :-)

i.e. The sentence that says you can't use 330 annotations on a class
that is not in a 299 bean deployment archive.

> Note that that language also means that I can't have a plain war with
> servlets that use JSR-330 annotations, or a plain EJB jar with EJB
> beans that use JSR-330 annotations.
>
> What is a "plain war"?

A war that is not a bean deployment archive. A war with no beans.xml file.

Do you really, really want to say that you can't use JSR-330
annotations in the servlets deployed in such a war? That was *never*
what 299 envisaged.

> Maybe you should read that spec section, just to make sure it says what you
> think it says.

I will take a look, but the sentence you just quoted to me looks
completely wrong.

Any servlet, EJB or managed bean should be allowed to use @Inject and
@Resource. This functionality should not depend upon the presence of
beans.xml.

> You are missing my point. Component classes that support injection are
> listed
> in the EE spec (Table EE.5-1). They are, and must be, discoverable by the
> container at deployment time. Moreover, the container doesn't have to go out
> of
> its way to discover anything else. This is why it's important to decide what
> classes
> are managed beans.
>
> With that premise, "beans" that are not discovered are not managed beans.

OK, well that's a different use of the word bean than in 299. In 299
beans are beans, whether they are discovered or not. I propose that
you use the phrase "discovered beans" for your concept.

So, 299 provides 2 mechanisms for discovery of a bean:

* scanning of classes in archives with beans.xml
* scanning of injection points with @New


> OK, let me ask you a simpler question: if I have a web module, say, without
> a beans.xml
> descriptor, can I lookup a BeanManager in JNDI under java:comp/BeanManager?
> Currently
> the platform spec says you can't.

That's a very good question, and one that the 299 spec does not address.

And my answer is *definitely yes*, since you should be able to inject
into "EE components supporting injection" that are deployed in that
web module, using @Inject. So there's no reason why you should not
also be  able to get them via the BeanManager API.



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