1:09 a.m.
Can anyone take a quick look at
org.jboss.weld.tests.decorators.generic.PartialDecoratorTest in
weld-core-tests and tell whether this use case is valid or invalid? I
can't seem to find anything prohibiting @Decorators to be themselves
generic (and be applied on @Dependent generic beans).
Thanks,
Marius
7:18 a.m.
This looks like an out of date check...
On 8 Dec 2009, at 07:09, Marius Bogoevici wrote:
Can anyone take a quick look at
org.jboss.weld.tests.decorators.generic.PartialDecoratorTest in
weld-core-tests and tell whether this use case is valid or invalid? I
can't seem to find anything prohibiting @Decorators to be themselves
generic (and be applied on @Dependent generic beans).
Thanks,
Marius
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
11:57 a.m.
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
12:03 p.m.
Yes, this is an ambiguous dependency.
On Fri, Dec 11, 2009 at 12:57 PM, Marius Bogoevici <mariusb(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
12:28 p.m.
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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>
>
12:30 p.m.
On Fri, Dec 11, 2009 at 1:28 PM, Marius Bogoevici <mariusb(a)redhat.com> wrote:
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.
Well, you already have so many options:
* "abstract"
* @Alternative
* an @Alternative stereotype
* a qualifier
* @Any
* deploy in an archive without a beans.xml
* veto() the class from a portable extension
* don't give it a default constructor
--
Gavin King
gavin.king(a)gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org
5260
days inactive
5263
days old
5 comments
3 participants
participants (3)
-
Gavin King -
Marius Bogoevici -
Pete Muir