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

[Roberto Chinnici]

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.

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

> Really, what happened was that we discovered an unacceptable
> limitation affecting @New (well, really the limitation was not
> explicit, it was something the spec was unclear on). In fact, earlier
> versions of JSR-299 which defined @New differently did *not* have this
> limitation. It slipped through into the RI because of the lack of
> clarity in the spec.
>
>   
>> But they are not already beans.
>>     
>
> Yes they are.
>
>    @Stateless class Foo {}
>
> is a bean. Even if there is no beans.xml file.
>
>    @ManagedBean class Foo {}
>
> is a bean. Even if there is no beans.xml file.

I'm not arguing with that at all.

>  Even
>
>    class Foo {  @Inject Bar bar;  }
>
> will be treated by JSR-330 as a bean even if there is no beans.xml file.
>   

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.

>> They are classes which might reasonably have
>> been beans *if* the developer had wanted them to be.
>>     
>
> They are classes that *are* beans, but that just happen to be deployed
> in an archive that is not being scanned by the 299 implementation.
>   

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.

>> 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.
>>     
>
> That's not a limitation that JSR-330 imposes, and it therefore would
> affect the 330 -> 299 migration scenario, as pointed out by Jim.
>   

JSR-330 doesn't talk about packaging at all.

> Again, this limitation was not there by design. Recent versions of the
> spec were unclear about this issue. Earlier versions of the spec
> actually were clear, and did not have the limitation.
>
>   
>> I'm trying to recall what the code using NonContextual looked like -- wasn't
>> NonContextual similar to Provider?
>>     
>
> No. It was a workaround that called the metamodel API. Jim and I and
> others all agree that 299 should not need to use the metamodel API in
> order to pass the 330 TCK.
>   

Can you show me the code that org.jboss.weld.atinject.tck.Producers used 
in its previous version,
with @BeanTypes but without @New? For some reason I can't get at it with 
viewvc.jboss.org.

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