<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Gavin King wrote:
<blockquote
cite="mid:db199550910191558t11d36ec7v3c4a0d84982686a7@mail.gmail.com"
type="cite">
<pre wrap="">On Mon, Oct 19, 2009 at 5:37 PM, Roberto Chinnici
<a class="moz-txt-link-rfc2396E" href="mailto:Roberto.Chinnici@sun.com"><Roberto.Chinnici@sun.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Gavin King wrote:
On Mon, Oct 19, 2009 at 1:58 PM, Roberto Chinnici
<a class="moz-txt-link-rfc2396E" href="mailto:Roberto.Chinnici@sun.com"><Roberto.Chinnici@sun.com></a> 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.
</pre>
</blockquote>
<pre wrap=""><!---->
On the contrary, this "clarification" to the behavior of @New
certainly does apply to both these cases.
</pre>
</blockquote>
<br>
The case being discussed was DriversSeat and SpareTire from the 330 TCK,<br>
i.e. the latest version of the Producers class you circulated.<br>
<br>
<blockquote
cite="mid:db199550910191558t11d36ec7v3c4a0d84982686a7@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">While I understand that the SPI is powerful enough to create a bean out of a
plain class -- after all, that's what it was created for -- I'd rather not
have an existing annotation with other legitimate applications, like @New,
be re-purposed to do that job.
@New has not been re-purposed even one little bit. This is precisely
what @New is supposed to be used for: getting a "new", "clean"
instance of a class inside a producer method, so that the producer
method can define its scope and qualifiers.
I'm not arguing with the formulation "getting a new instance of a class".
It's when you
say "bean" instead of "class" that I start seeing some
issues/inconsistencies.
</pre>
</blockquote>
<pre wrap=""><!---->
There are no inconsistencies. Chapter 3 defines what classes are
beans. Chapter 12 defines which beans get detected by classpath
scanning. There are beans which are not detected by scanning. We are
saying that you can use @Inject @New for those beans, even if you
can't inject them in any other way.
</pre>
</blockquote>
<br>
The "inconsistencies" are between the various specs that together
define requirements<br>
for an EE container.<br>
<br>
<blockquote
cite="mid:db199550910191558t11d36ec7v3c4a0d84982686a7@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
Then this clause in the platform spec is making it impossible to take
an archive that worked with Guice, and have it continue working
without change in 299.
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.</pre>
</blockquote>
<br>
What is a "plain war"?<br>
<br>
"Support for JSR-330 annotations" means "support for JSR-330
annotations by the container"<br>
of course.<br>
<br>
<blockquote
cite="mid:db199550910191558t11d36ec7v3c4a0d84982686a7@mail.gmail.com"
type="cite">
<pre wrap="">This was *never* what was
envisaged by the 299 spec, and we went out of our way to make sure
that things that weren't injectable by 299 could still inject using
299.
You should immediately remove that language. That's an enormous glaring error.
</pre>
</blockquote>
<br>
Maybe you should read that spec section, just to make sure it says what
you think it says.<br>
<br>
<blockquote
cite="mid:db199550910191558t11d36ec7v3c4a0d84982686a7@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
* The EJB spec certainly assumes that I can use @Resource in something
that is not in a bean deployment archive.
* The JSF spec certainly allows managed beans to use @Resource when
they are deployed in something that is not a bean deployment archive.
* The 299 spec was certainly written to assume that there are things
using 330 annotations and common annotations that are deployed in
archives that are not bean deployment archives.
I'm not sure what other specs are relevant here.
i.e. I basically think you're off your rocker here :-) The specs do
collectively require this.
</pre>
</blockquote>
<br>
You are missing my point. Component classes that support injection are
listed<br>
in the EE spec (Table EE.5-1). They are, and must be, discoverable by
the<br>
container at deployment time. Moreover, the container doesn't have to
go out of<br>
its way to discover anything else. This is why it's important to decide
what classes<br>
are managed beans.<br>
<br>
With that premise, "beans" that are not discovered are not managed
beans.<br>
<br>
<blockquote
cite="mid:db199550910191558t11d36ec7v3c4a0d84982686a7@mail.gmail.com"
type="cite">
<blockquote type="cite">
<pre wrap="">And even if they were
managed beans thanks to the @ManagedBean annotation, since they lie outside
a bean deployment archive, they should not be directly accessible using 299
means. So you could create an instance using JNDI (if the bean had a name),
but not with the 299 API or SPI.
</pre>
</blockquote>
<pre wrap=""><!---->
You have provided no argumentation in support of "should not".
Whereas I have provided a Very Good Reason why they *should* be
injectable, with limited semantics, using the special @New annotation.
</pre>
</blockquote>
<br>
OK, let me ask you a simpler question: if I have a web module, say,
without a beans.xml<br>
descriptor, can I lookup a BeanManager in JNDI under
java:comp/BeanManager? Currently<br>
the platform spec says you can't.<br>
<br>
</body>
</html>