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

David Allen drallendc at gmail.com
Wed Jul 22 07:18:25 EDT 2009


On Wed, 2009-07-22 at 12:13 +0100, Pete Muir wrote:
> 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.

This works now with the bindings, but we do not yet have the
@Alternative binding in the RI.  We do also have tests already,
including the exact examples cited above.  They are mostly under
producer method or field tests.

> _______________________________________________
> webbeans-dev mailing list
> webbeans-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/webbeans-dev




More information about the weld-dev mailing list