<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Gavin King wrote:
<blockquote
cite="mid:db199550912111003i7b2f7026r235f301a9b6ccee0@mail.gmail.com"
type="cite">
<pre wrap="">Yes, this is an ambiguous dependency.
</pre>
</blockquote>
Thanks, Gavin.<br>
<br>
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.<br>
<br>
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 :).<br>
<br>
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). <br>
<blockquote
cite="mid:db199550912111003i7b2f7026r235f301a9b6ccee0@mail.gmail.com"
type="cite">
<pre wrap="">
On Fri, Dec 11, 2009 at 12:57 PM, Marius Bogoevici <a class="moz-txt-link-rfc2396E" href="mailto:mariusb@redhat.com"><mariusb@redhat.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Pete Muir wrote:
</pre>
<blockquote type="cite">
<pre wrap="">This looks like an out of date check...
</pre>
</blockquote>
<pre wrap="">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
<a class="moz-txt-link-abbreviated" href="mailto:weld-dev@lists.jboss.org">weld-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/weld-dev">https://lists.jboss.org/mailman/listinfo/weld-dev</a>
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>