7:24 p.m.
Gavin King wrote:
On Mon, Oct 19, 2009 at 7:40 PM, Roberto Chinnici
<Roberto.Chinnici(a)sun.com> wrote:
> Gavin King wrote:
>
> On Mon, Oct 19, 2009 at 5:37 PM, Roberto Chinnici
> <Roberto.Chinnici(a)sun.com> wrote:
>
>
> Gavin King wrote:
>
> On Mon, Oct 19, 2009 at 1:58 PM, Roberto Chinnici
> <Roberto.Chinnici(a)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 :-)
Of course not.
> 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.
OK, so you think I should be able to use @Inject everywhere basically,
even in modules
which are not bean deployment archives. It seems OK, but it's not what
the proposal
I sent to the platform EG back in July said.
> 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.
Yep, we have a disconnect.
> 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.
I understand. Let me think about the implications.
> 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
The second one is more scanning than we had in mind.
> 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.
Yes, that is consistent with your belief we should support @Inject
everywhere.