[weld-dev] Generic Decorator

[Gavin King]

Yes, this is an ambiguous dependency.

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
>



-- 
Gavin King
gavin.king at gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org