[cdi-dev] JSF 2.3 and specifying alternatives for build-in producers

[Jozef Hartinger]

On 11/06/2014 02:24 PM, arjan tijms wrote:
> Hi,
>
> 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.
> https://github.com/svn2github/mojarra/blob/master/trunk/jsf-api/src/main/java/javax/faces/application/ApplicationProducer.java
> It's registered in an extension here:
> https://github.com/svn2github/mojarra/blob/master/trunk/jsf-ri/src/main/java/com/sun/faces/FacesCDIExtension.java
>
> 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
> situations.
>
> 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
> beautifully.
>
> 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
> (http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#declaring_selected_alternatives)
> gave me the impression that @Priority should cause the alternative to
> be selected for the entire application, but that's not the case?
Yes, the @Alternative is globally enabled and will be injected 
everywhere from where the defining class is visible. That should cover 
your case. You may be observing an integration bug? What is the container?

>
> Kind regards,
> Arjan