On Mon, Oct 19, 2009 at 7:40 PM, Roberto Chinnici
<Roberto.Chinnici@sun.com> wrote:
  

Gavin King wrote:

On Mon, Oct 19, 2009 at 5:37 PM, Roberto Chinnici
<Roberto.Chinnici@sun.com> wrote:


Gavin King wrote:

On Mon, Oct 19, 2009 at 1:58 PM, Roberto Chinnici
<Roberto.Chinnici@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.