I took the time to get a sample application running on TomEE:
It was fairly trivial starting from the org.apache.openejb.maven:tomee-webapp-archetype:1.5.2 archetype, and adding RichFaces dependencies to the pom. The app deploys and runs fine.
In a branch I set the org.richfaces.resourceOptimization.enabled to true, and indeed the CDI injection started failing.
See the Readme for instructions on building the above application, and running it in an embedded TomEE container:
TomEE - could have thought of that myself. Your project "works" (as in: doesnt' function) for me too... The interesting thing is: setting the context-param to "false" makes the thing work again (as opposed to my findings in Websphere). But that is only a side-note.
Since org.richfaces.resource.ResourceLoadingOptimization (which you recommended) was a dead end for me the last time around in WebSphere, I will now try to debug into OWB. I assume RF triggers some behaviour in OWB that makes CDI got the way of the dodo...
Will get back to you as soon as I found something. If you got any more ideas - let me know...
I finally got back to this problem (took some time - I know).
This is actually not one but two bugs. One in Richfaces (regarding the multiple loading of resources) and one (probably) in OpenWebBeans.
Regarding the missing ELResolver the cause seems as follows:
- When richfaces is started the
javax.faces.event.PostConstructApplicationEventis fired and the
- During the execution of this eventlistener the
org.richfaces.resource.ResourceLoadingOptimization#isEnabled()method is called. This method will try to evaluate the
org.richfaces.resourceMapping.enabledcontext parameter. To do this it will use the FacesContext.
- Since this happens very early during the application initialization sequence the OWB ELResolver has not yet been initialized. The myfaces-ELContext will initialize itself (bypassing OWB) and "remember" the partially initialized state (
org.apache.myfaces.application.ApplicationImpl#getELResolver()for those playing along at home).
- When any other part of the CDI stack afterwards tries to access "EL-entities" registered under OWBs context it will always get a null-reference since the
org.apache.webbeans.el.WebBeansELResolveris not registered with the (my)faces EL context.
Conclusion 1: Regarding the problem with non-available CDI beans in any CDI-scope the workaround in [RF-12801] Use of Resource Optimization prevents the WebBeansELResolver from registering in OWB - JBoss Issue Tracker actually the only way to do it right now (registring the resolver through faces-config.xml forces myfaces to insert the OWB-ELResolver in the correct context even when OWB itself "forgets" to register things during the
Which brings us to bug #2:
As erdemyilmaz pointed out in the jira issue the workaround causes the "
org.apache.myfaces.shared.renderkit.html.util.ResourceUtilsand subsequently calls
markScriptAsRendered()and the like on it. Here comes the problem... :-) IBM (in it's infinite wisdom) decided it would be smart to keep myfaces1.2's packaging structure (for whatever twisted reason). The util-class Lukáš' is relying on resides in
org.apache.myfaces.shared_impl.renderkit.html.util.ResourceUtilswhen running on Websphere. I prepared a patch for
org.richfaces.resource.external.MyFacesExternalResourceTrackerthat work around this problem. Have a look at [RF-13540] Websphere incarnation of MyFaces renderes optimized resources multiple times - JBoss Issue Tracker . Would someone be willing to accept a pull-request?
Conclusion 2: IBM is smarter than the rest of us... Since it will be (mostly) impossible to get IBM to fix the myfaces packaging shipped with WAS (I assume they messed it up for backwards compatibility in the first place) it seems more helpful to fix the workaround-code in RF.
Regarding OWB: I would like to file this as a bug with the OWB guys. Do you have any contact to them? After OWB fixed the problem we might just be lucky and get IBM to fix WAS (fingers crossed).
- When richfaces is started the