Hi, For JSF 2.3 we're currently working on providing build-in producers for various JSF artefacts.We're basically using the approach that I outlined here: http://jdevelopment.nl/dynamic-cdi-producers I noticed CDI is using a similar approach for its build-in producers, e.g. the one for HttpServletRequest (in Weld: org.jboss.weld.bean.builtin.ee.HttpServletRequestBean). 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.

After some experimentation I couldn't really succeed in providing an alternative producer for the CDI produced HttpServletRequest. I tried the obvious things, like an @Produces method in a bean annotated with @Alternative but that didn't work. Registered the bean as alternative in beans.xml, tried the uhm alternative @Priority method, tried different priority ranges, etc but my own producer was never called. Am I missing something very obvious, or is it not trivial to provide an alternative for build-in producers?

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.

Hi, On Thu, Nov 6, 2014 at 9:08 AM, Jozef Hartinger <jharting(a)redhat.com&gt; 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/... It's registered in an extension here: https://github.com/svn2github/mojarra/blob/master/trunk/jsf-ri/src/main/j... 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_alter...) gave me the impression that @Priority should cause the alternative to be selected for the entire application, but that's not the case?

Kind regards, Arjan