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

[Roberto Chinnici]

Jason T. Greene wrote:
> Roberto Chinnici wrote:
>> Gavin King wrote:
>>> Check out sections 2.2.2, 3.12, 3.5.2 together with the new sentence
>>> regarding @New added to 5.7.1 and 11.3.4.
>>>
>>> This is everything that is needed for 299 to *elegantly* pass the 
>>> 330 TCK.
>>>   
>>
>> Can you explain again the new semantics for @New and why it is needed?
>
> It's just a loosening of a restriction, so that the semantics of @New 
> can apply to a class that is not part of a bean deployment archive. 
> The problem is the previous approach required an additional support 
> class NonContextual, which was using the BeanManager to implement the 
> behavior of @New. With this change the user has to only a provide the 
> simple class with producer methods.

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

>>
>> I'm reading 3.12 and I have trouble understanding how a class inside 
>> an archive which is NOT a bean deployment archive could give rise to 
>> a managed bean (at least in the sense of 299). It seems then that the 
>> premise of 3.12 is empty and no second beans will ever be created. 
>> And I don't think you meant for DriversSeat and SpareTire in your 
>> example to be annotated with @ManagedBean, since the 330 TCK doesn't 
>> do that.
>
> The thinking was that we will treat them as a managed bean definition, 
> since they basically are, even though they are not annotated with 
> @ManagedBean. Are you saying we can't do that without the TCK using 
> @ManagedBean on them? I was under the impression this wasn't a hard 
> restriction, just that some frameworks may require it.

But they are not already beans. They are classes which might reasonably 
have been beans *if* the developer had wanted them to be. 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. Now, as I 
said earlier, if somebody went and did the necessary SPI calls to define 
a bean for them, then yes, it would work.

>> Also, I'm not sure why you excluded @New in 11.3.4. Doesn't that make 
>> the SPI less powerful than the annotations?
>
> I don't recall the reason, I will let Gavin comment on that one.

That seems to be a hint that @New shouldn't be used for this purpose. 
Maybe if you could describe what NonContextual did and how it was used, 
we could figure out a suitable replacement. For example, I don't think I 
would object if a bunch of SPI magic was hidden behind the use of a 
standard API called NonContextual, as long as there is some 
justification for it.

I'm trying to recall what the code using NonContextual looked like -- 
wasn't NonContextual similar to Provider?