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.

_______________________________________________ webbeans-dev mailing list webbeans-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/webbeans-dev

Okay, so there is an explicit step that must be taken for a producer method to win over a @Current bean (does not have additional bindings) of that type. I suspect in most cases developers will choose to use the binding type since that is the type-safe approach. The designation of the alternative class in beans.xml makes all producer methods in that class have a higher precedence than any @Current bean of that type, correct? Is it also possible to specify a single method in beans.xml? There is alluded to in the Policy section, but no examples to support it. Btw, I think this would be a lot clearer if it was explicitly stated in the spec how a producer method relates to a @Current bean of that type. I guess you could say it can be implied, but the first time someone goes to create a producer method, I can see them not realizing that they have to take an extra step to make it the preferred source. -Dan On Wed, Jul 22, 2009 at 7:13 AM, Pete Muir <pmuir(a)redhat.com&gt; 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. -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://in.relation.to/Bloggers/Dan _______________________________________________ webbeans-dev mailing list webbeans-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/webbeans-dev

Probably a good FAQ http://www.seamframework.org/Documentation/WebBeans On 22 Jul 2009, at 15:05, Dan Allen wrote: Okay, so there is an explicit step that must be taken for a producer > method to win over a @Current bean (does not have additional bindings) of > that type. I suspect in most cases developers will choose to use the binding > type since that is the type-safe approach. > > The designation of the alternative class in beans.xml makes all producer > methods in that class have a higher precedence than any @Current bean of > that type, correct? Is it also possible to specify a single method in > beans.xml? There is alluded to in the Policy section, but no examples to > support it. > > Btw, I think this would be a lot clearer if it was explicitly stated in > the spec how a producer method relates to a @Current bean of that type. I > guess you could say it can be implied, but the first time someone goes to > create a producer method, I can see them not realizing that they have to > take an extra step to make it the preferred source. > > -Dan > > On Wed, Jul 22, 2009 at 7:13 AM, Pete Muir <pmuir(a)redhat.com&gt; 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. > > > > -- > Dan Allen > Senior Software Engineer, Red Hat | Author of Seam in Action > Registered Linux User #231597 > > http://mojavelinux.com > http://mojavelinux.com/seaminaction > http://in.relation.to/Bloggers/Dan > _______________________________________________ > webbeans-dev mailing list > webbeans-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/webbeans-dev >