[webbeans-dev] producer method trumps raw dependent type?

Pete Muir pmuir at redhat.com
Wed Jul 22 07:13:18 EDT 2009


On 22 Jul 2009, at 03:18, Dan Allen wrote:

> After the recent revisions of the JSR-299 spec, I'm finding that I'm  
> a tad confused about the bean selection algorithm when a producer  
> method exists.
>
> Consider the following:
>
> class PotatoChip {
> }
>
> class SnackFactory() {
>     public @Produces PotatoChip createPotatoChip() {
>         return new PotatoChip();
>     }
> }
>
> 1) Does the produced PotatoChip take precedence over the raw  
> dependent type when being selected for injection?

No.

>
> 2) How do I get the Bean<PotatoChip> that represents the producer  
> method?
>
> BeanManager#getBeans(PotatoChip.class) returns two beans that are  
> indistinguishable from the public API.

either:

@Alternative
class SnackFactory() {
     public @Produces PotatoChip createPotatoChip() {
         return new PotatoChip();
     }
}

<beans>
    <alternatives>
       <alternative>SnackFactory</alternative>
    </alternatives>
</beans>

or

class SnackFactory() {
     public @Produces @Snack PotatoChip createPotatoChip() {
         return new PotatoChip();
     }
}

BeanManager.getBeans(PotatoChip.class, new AnnotationLiteral<Snack>()  
{});

where @Snack is a binding type

>
> 3) What if the producer method is @RequestScoped? How do I get the  
> request-scoped produce instead of the dependent bean?
>
>       Bean<PotatoChip> potatoChipBean = null;
>       for (Bean<PotatoChip> candidate : getBeans(PotatoChip.class))
>       {
>          if (candidate.getScopeType().equals(RequestScoped.class))
>          {
>             potatoChipBean = candidate;
>             break;
>          }
>       }
>
> Sorry if this sounds like a dumb question. The spec has changed a  
> lot and my memory is getting mixed in with the current set of facts.

As above.

It's possible the RI doesn't actually reflect this behavior atm - if  
you have a problem, make sure there is a test, then change the RI or  
file a WBRI.



More information about the weld-dev mailing list