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

[Gavin King]

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.

> 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 at gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org