[weld-dev] Generic Decorator

[Marius Bogoevici]

Gavin King wrote:
> Yes, this is an ambiguous dependency.
>   
Thanks, Gavin.

I am wondering if the spec could consider a special 
stereotype/annotation to indicate beans which would normally be eligible 
to be managed beans, but shouldn't, because there is no intent of using 
them directly like that.

Something like @Unmanaged (bad name, perhaps), similar to how 
javax.persistent.Transient indicates that a field is not persistent and 
should not be managed by the container. Of course, I am aware that 
careful design could avoid this type of situation :).

Apart from disambiguation per se, for which perhaps a stereotype would 
be more suitable, this could also help optimizing the behaviour of the 
container at runtime (by never considering certain classes as managed 
beans, when it is clear that there is absolutely no chance of using them 
that way).
> On Fri, Dec 11, 2009 at 12:57 PM, Marius Bogoevici <mariusb at redhat.com> wrote:
>   
>> Pete Muir wrote:
>>     
>>> This looks like an out of date check...
>>>
>>>
>>>       
>> OK, thanks. Actually, I just noticed that the example in the
>> introduction of the specification is showing exactly this use case.
>>
>> I would, however, like to clarify whether the following use case is
>> acceptable (was driven to this while handling @Inject GenericBean<T>):
>>
>> class Receiver
>> {
>>    @Inject Injected<String> injected;
>> }
>>
>> @Dependent
>> class Injected<T>
>> {
>>    public void Injected() {} // making clear that this satisfies the
>> conditions for a generic managed bean
>> }
>>
>> class StringInjectedProducer
>> {
>>    @Produces Injected<String> produce() { ... }
>> }
>>
>> Looking carefully, it shouldn't, since Receiver.injected has ambiguous
>> dependencies (on one hand Injected per se, on the other hand, the
>> producer method). A qualifier can help disambiguating between the two
>> situations.
>>
>> If the statement above is correct, then ProducerFieldDefinitionTest in
>> the TCK could be adjusted, since FunnelWeaver and pals
>> (FunnelWeaverSpiderProducer and FunnelWeaverSpiderConsumer) illustrate
>> exactly this behaviour (simple qualification will solve the ambiguity).
>>
>> Marius
>>
>>
>>
>>
>> _______________________________________________
>> weld-dev mailing list
>> weld-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>
>>     
>
>
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20091211/17ec1f75/attachment.html