[cdi-dev] JSF 2.3 and specifying alternatives for build-in producers
arjan.tijms at gmail.com
Thu Nov 6 08:24:48 EST 2014
On Thu, Nov 6, 2014 at 9:08 AM, Jozef Hartinger <jharting at redhat.com> wrote:
>> Now we're currently putting these producers in an API package, to give
>> the user a chance to override them, but I noticed CDI is not doing
>> this. All producers are in implementation packages.
> Not sure what you mean here. How is a producer in an API package supposed to
> be overriden? A CDI producer is an implementation detail and should not be
> part of the API
Okay. Well, in Mojarra 2.3 it is now indeed in the API, see e.g.
It's registered in an extension here:
We indeed put it there since we thought that otherwise you could not
override it with your own alternative.
But this now seems to be the wrong approach indeed. I guess we're
still somewhat novices when it comes to CDI.
> This should work. Sounds like an issue with your setup. Can you paste your
> code? It should be something like this: http://pastebin.com/TkzDtaAE
My code was identical, except for the @Dependent annotation. Putting
that annotation there and it starts to work, but still not for all
In a web application without any beans.xml and with this @Alternative
producer in WEB-INF/classes and a bean that also lives in
WEB-INF/classes injected with an HttpServletRequest this works
However, in my test a jar file in WEB-INF/lib containing a bean that's
also injected with an HttpServletRequest does not get injected with
the one from the alternative producer, but gets an instance from the
original CDI provided producer.
Reading 5.1.1 in the CDI spec
gave me the impression that @Priority should cause the alternative to
be selected for the entire application, but that's not the case?
More information about the cdi-dev