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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev