Re: [cdi-dev] Bean<T> that only qualifies super types?

Hi, On Fri, Aug 7, 2015 at 1:48 PM, Martin Kouba <mkouba(a)redhat.com&gt; wrote: > No, an interface may be a bean type but not a bean class of a managed bean. > For producer methods, the getBeanClass() returns the bean class of the bean > that declares the producer method. > > The bean class is defacto an implementation class. Seems fair enough, but if I look at the build-in Bean<T> implementations of Weld, then org.jboss.weld.Bean.RIBean returns the type as the bean class. See:

http://grepcode.com/file/repo1.maven.org/maven2/org.jboss.weld/weld-core-... If we look at a concrete implementation, say HttpServletRequestBean (see http://grepcode.com/file/repo1.maven.org/maven2/org.jboss.weld.se/weld-se...) Then HttpServletRequest.class is passed to the super ctor as the Type, and therefor also becomes the bean class, as per RIBean.java#56.

Same thing for UserTransaction, Principal, ServletRequest, etc. Kind regards, Arjan Tijms > >> >> There's nothing wrong with that, is it? >> >> So by extension, is this wrong then? >> >> @Produces >> public Foo produce() { >> return new FooImpl(); >> } > > > This is OK. But the bean class of this producer is not Foo as mentioned > above. > > >> >> >> >>> No, this is not possible. Qualifiers are tied to a bean definition, not >>> to a >>> bean type. >> >> >> So this would possibly be an enhancement or new feature request then. >> >> >> I did found a workaround though, which seems to work because the Type >> I'd like to hide happens to have generic parameters: >> >> private static class Dummy {} >> >> @Override >> public Set<Type> getTypes() { >> return new HashSet<Type>(asList(Foo.class, >> ParameterizedTypeImpl(Map.class, new Type[]{Dummy.class, >> Dummy.class}))); >> } >> >> With those types the proxy that's generated contains methods for both >> Foo and Map, but because the generic parameters are the private class, >> the client application can never declare an injection point for this >> (certain not accidentally). >> >> Another possible workaround I thought of is using a second Bean<T> >> that only has Foo as its type and is @Dependent scoped, which then >> asks the bean manager for an instance of a qualified Foo (qualifier is >> of a private type). If I'm not mistaken the first Bean<T> would then >> be called and an @RequestScoped proxy would be returned, which the >> second Bean<T> can then return from its create() method. >> >> What do you think, any of these methods have potential unforeseen >> side-effects or are they safe to use? >> >> Kind regards, >> Arjan >> >> >> >> >> >> >> >>> >>> >>>> >>>> Kind regards, >>>> Arjan Tijms >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> Note that for all code provided on this list, the provider licenses the >>>> code under the Apache License, Version 2 >>>> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas >>>> provided on this list, the provider waives all patent and other >>>> intellectual >>>> property rights inherent in such information. >>>> >>> >>> -- >>> Martin Kouba >>> Software Engineer >>> Red Hat, Czech Republic > > > -- > Martin Kouba > Software Engineer > Red Hat, Czech Republic