5:58 p.m.
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.
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.
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.
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.
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. 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.
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.
* 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.
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.
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.
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org