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

[Roberto Chinnici]

Gavin King wrote:
> 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.
>   

The case being discussed was DriversSeat and SpareTire from the 330 TCK,
i.e. the latest version of the Producers class you circulated.

>> 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.
>   

The "inconsistencies" are between the various specs that together define 
requirements
for an EE container.

>> 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.

What is a "plain war"?

"Support for JSR-330 annotations" means "support for JSR-330 annotations 
by the container"
of course.

> 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.
>   

Maybe you should read that spec section, just to make sure it says what 
you think it says.

>> 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.
>   

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.

>> 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.
>   

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20091019/414f3b7a/attachment.html