I added OmniFaces to use the CombinedResourceHandler.
But now the PrimeFaces Extensions <pe:ckEditor> doesn´t work anymore.
Is there any workaround for this issue?
Unfortunately, this is a known issue caused by the way how PrimeFaces Extensions loads and manages its JS resources. This was already ever reported as an issue on old Google Code host and is mentioned in the current OmniFaces known issues wiki as follows:
PrimeFaces Extensions <=0.7.1-4.0.0 (and probably future versions)
PrimeFaces Extensions JS resource primefaces-extensions.js is incompatible with CombinedResourceHandler. During load, it attempts to figure the version from its own <script> element in order to dynamically load additional CSS/JS resources. This is however absent and the attempt fails with a JS error which in turn causes the dynamic loading of additional CSS/JS resources for e.g. CKEditor to fail.
Your best bet is to exclude primefaces-extensions.js from combining by adding the following entry to web.xml telling the CombinedResourceHandler to not combine the PrimeFaces Extensions main script file:
<context-param>
<param-name>org.omnifaces.COMBINED_RESOURCE_HANDLER_EXCLUDED_RESOURCES</param-name>
<param-value>primefaces-extensions:primefaces-extensions.js</param-value>
</context-param>
If you're using OmniFaces 2.2 or newer, then you can use a wildcard * as name:
<context-param>
<param-name>org.omnifaces.COMBINED_RESOURCE_HANDLER_EXCLUDED_RESOURCES</param-name>
<param-value>primefaces-extensions:*</param-value>
</context-param>
If you're using PrimeFaces Extensions before version 3.0.0, then you also need to make sure that the PrimeFaces Extensions own resource handler is explicitly declared after CombinedResourceHandler in faces-config.xml:
<application>
<resource-handler>org.omnifaces.resourcehandler.CombinedResourceHandler</resource-handler>
<resource-handler>org.primefaces.extensions.application.PrimeFacesExtensionsResourceHandler</resource-handler>
</application>
This issue is fixed in PrimeFaces Extensions 6.2.8 or higher.
https://github.com/primefaces-extensions/primefaces-extensions.github.com/issues/601
Related
I'm reviewing a current JSF project where the web.xml configuration contains:
the FacesServlet (configured on *.xhtml)
the com.sun.faces.config.ConfigureListener
I'm using JSF 2.2 and Mojarra implementation.
I'm confused about the ConfigureListener. Is this class needed in the configuration? What is the goal of this class? I couldn't find any information and the class has almost no javadoc.
If I remove this configuration, everything seem to work the same way. Thus I guess that the ConfigureListener could or should be removed but I am not sure.
The ConfigureListener is normally automatically registered via /META-INF/jsf_core.tld file of Mojarra implementation JAR file. Additionally, the ConfigureListener is explicitly registered via a Servlet 3.0 ServletContainerInitializer in order to workaround an old GlassFish v3 bug (note: v3, not 3.0.x, thus really that one first GF3 version ever).
There exist situations wherein the auto-registration via .tld file is insufficient. The well known one is when the webapp is deployed to Jetty. This is explained in detail in this Q&A: could not find Factory: javax.faces.context.FacesContextFactory.
Also, as mentioned before and in that detailed answer, GlassFish v3 has a bug wherein the TLD file is scanned too late and thus JSF couldn't do its necessary initialization thing at the right moment. You'd then need to explicitly register the ConfigureListener in webapp's web.xml.
But if it works for you when it's not explicitly registered in web.xml, then just keep it out. Less noise in web.xml is better. But if you happen to possibly deploy to a container sensitive to the mentioned problem (so when your webapp is actually a publicly distributed one and you have no control over choice of target container), then you'd better keep it in "for the case that".
Update: It appears that Tomcat 8.x shows buggy behavior when this entry is enabled in web.xml: this listener will actually be executed twice instead of only once. The consequence is disastrous: among others, all JSF event listeners will be registered twice and component libraries will be loaded twice. This leads only to conflicts during runtime. In other words, when deploying to Tomcat, make sure that this entry is removed from web.xml.
When I create a web application from scratch and add jsf-api-2.2.11.jar and jsf-impl-2.2.11.jar to pom.xml (add them to apps classpath) and deploy it to Tomcat 7, JSf is initializing automatically:
INFO [j.e.r.w.j.config] - Mojarra 2.2.11 ( 20150505-0732 https://svn.java.net/svn/mojarra~svn/tags/2.2.11#14688) ..... initialized.
In older versions I used to start it declarativly by defining it in web.xml (listener+servlet). So I already commented them out and set "metadata-complete" to "true" (does that even stop classpath scanning?), but it is still loading.
In this case I dont want it to load, while leaving the Jars in classpath and i.e. the faces-config.xml in web-inf.
What is still triggering the initialization?
It's loaded via a Servlet 3.0 ServletContainerInitializer implementation in the JSF implementation JAR file (in case of Mojarra, it's the com.sun.faces.config.FacesInitializer). It will auto-register the FacesServlet on the URL patterns *.jsf, *.faces and /faces/* (JSF 2.3 will add *.xhtml to the list of URL patterns). Latest JSF 2.1 implementations and all JSF 2.2 implementations will do it when deployed to a Servlet 3.0 compatible container. For detail about this new Servlet 3.0 ServletContainerInitializer thing, head to this answer: ServletContainerInitializer vs ServletContextListener.
The right way to stop it is removing the JSF implementation from the dependencies (note that you do not need to remove the JSF API as well). You seem to not be making use of it in any way. After all, a properly designed web application should not have any JSF implementation specific dependencies. I only wonder, why exactly would you leave the JSF API in? Using a 3rd party JSF based library for non-JSF purposes? This might indicate and end up in other (architectural) problems.
Another way of stopping it is downgrading your web application to be Servlet 2.5 targeted by editing the <web-app> root declaration in web.xml accordingly to comply that version. But this has many other side effects which may not be desireable when the intent is to develop a Servlet 3.0 compatible web application.
The "listener" you're referring to is actually not necessary, it's only to workaround buggy containers with timing errors in parsing TLD files, such as early GlassFish v3 and Jetty versions. See also a.o. Configuration of com.sun.faces.config.ConfigureListener.
As it's described in the documentation that in order to pass custom HTML5 attributes we have to declare the context-parameter org.omnifaces.HTML5_RENDER_KIT_PASSTHROUGH_ATTRIBUTES, passing the fully qualified name of a class as a key and the value as commaseparated string of names of passthrough attributes.
What I've done is this:
<context-param>
<param-name>org.omnifaces.HTML5_RENDER_KIT_PASSTHROUGH_ATTRIBUTES</param-name>
<param-value>
javax.faces.component.html.HtmlForm=data-parsley-validate; <!-- test also javax.faces.component.UIForm -->
javax.faces.component.html.HtmlInputText=data-parsley-type;
</param-value>
</context-param>
Also I've registered the render-kit-factory
<factory>
<render-kit-factory>org.omnifaces.renderkit.Html5RenderKitFactory</render-kit-factory>
</factory>
And of course all this goes into the faces-config.xml.
Unfortunately I have no luck in getting it to work, I'm not sure what is missing.
I have created a very basic project on github containing only one page, and inside it one form and an inputText.
I have tested this in three environments:
First one
GlassFish Edition 4.0 (build 89) - I'm having some warnings also
Mojarra 2.2.0
Omnifaces 1.8.1
Second one
JBoss Application Server 7.1.1
Mojarra 2.1.11
Omnifaces 1.8.1
Third one
jetty 9.1.1
Mojarra 2.2.0
Omnifaces 1.8.1
My first assumption was the version of Mojarra which 2.2 but I also tested on 2.1 the same result, it seems I'm missing something here since I have a very clean example/project.
I've already managed to pass those custom attributes by implementing different renderers, but it's less headache for me to use the Omnifaces one, also tested to pass autocomplete to the form which is initially supported attribute by this renderer and it works fine.
Note: I know that in JSF 2.2 we can pass HTML5 easily, in my case the app should be eligible to work on 2.2 or 2.1 .
The <context-param> belongs in web.xml, not faces-config.xml.
I just clarified the javadocs on this.
I just moved my application from glassfish to TomEE, that includes moving from mojarra to myfaces. So far I had a few problems that I could fix, but I don't know how to tackle this one.
If I use CDNResourceHandler and the PROJECT_STAGE is Production I get a NullPointerException (it does work fine in Development mode)
java.lang.NullPointerException
javax.faces.application.ResourceWrapper.getLibraryName(ResourceWrapper.java:94)
org.apache.myfaces.renderkit.html.HtmlScriptRenderer.encodeEnd(HtmlScriptRenderer.java:259)
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:674)
javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:554)
org.primefaces.renderkit.HeadRenderer.encodeBegin(HeadRenderer.java:84)
javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:596)
javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:526)
The Resource is (org.omnifaces.resourcehandler.CDNResourceHandler$1) https://cdnjs.cloudflare.com/ajax/libs/meyer-reset/2.0/reset.min.css
The relevant parts of the code
faces-config.xml
<application>
<resource-handler>org.omnifaces.resourcehandler.UnmappedResourceHandler</resource-handler>
<resource-handler>org.omnifaces.resourcehandler.CDNResourceHandler</resource-handler>
</application>
web.xml
<context-param>
<param-name>org.omnifaces.CDN_RESOURCE_HANDLER_URLS</param-name>
<param-value>bootstrap-cdn:bootstrap/3.2.0/js/bootstrap.min.js=//netdna.bootstrapcdn.com/bootstrap/3.2.0/js/bootstrap.min.js,
bootstrap-cdn:font-awesome/4.1.0/css/font-awesome.css=//netdna.bootstrapcdn.com/font-awesome/4.1.0/css/font-awesome.css,
bootstrap-cdn:bootstrap/3.2.0/css/bootstrap.min.css=//netdna.bootstrapcdn.com/bootstrap/3.2.0/css/bootstrap.min.css,
cloudflare-cdn:meyer-reset/2.0/reset.min.css=https://cdnjs.cloudflare.com/ajax/libs/meyer-reset/2.0/reset.min.css.....
Omnifaces 1.8.1 (also tried with 2.0-SNAPSHOT)
Myfaces 2.2.3
MyFaces needed the library and resource name of the original resource so that it could mark the resource as "already rendered" (to prevent duplicate rendering). However, the CDNResourceHandler didn't pass the original resource back via getWrapped().
This has been fixed and is available as per current snapshot. In the future, when you encounter an exception when using OmniFaces, you'd better report an issue.
I added OmniFaces to use the CombinedResourceHandler.
But now the PrimeFaces Extensions <pe:ckEditor> doesn´t work anymore.
Is there any workaround for this issue?
Unfortunately, this is a known issue caused by the way how PrimeFaces Extensions loads and manages its JS resources. This was already ever reported as an issue on old Google Code host and is mentioned in the current OmniFaces known issues wiki as follows:
PrimeFaces Extensions <=0.7.1-4.0.0 (and probably future versions)
PrimeFaces Extensions JS resource primefaces-extensions.js is incompatible with CombinedResourceHandler. During load, it attempts to figure the version from its own <script> element in order to dynamically load additional CSS/JS resources. This is however absent and the attempt fails with a JS error which in turn causes the dynamic loading of additional CSS/JS resources for e.g. CKEditor to fail.
Your best bet is to exclude primefaces-extensions.js from combining by adding the following entry to web.xml telling the CombinedResourceHandler to not combine the PrimeFaces Extensions main script file:
<context-param>
<param-name>org.omnifaces.COMBINED_RESOURCE_HANDLER_EXCLUDED_RESOURCES</param-name>
<param-value>primefaces-extensions:primefaces-extensions.js</param-value>
</context-param>
If you're using OmniFaces 2.2 or newer, then you can use a wildcard * as name:
<context-param>
<param-name>org.omnifaces.COMBINED_RESOURCE_HANDLER_EXCLUDED_RESOURCES</param-name>
<param-value>primefaces-extensions:*</param-value>
</context-param>
If you're using PrimeFaces Extensions before version 3.0.0, then you also need to make sure that the PrimeFaces Extensions own resource handler is explicitly declared after CombinedResourceHandler in faces-config.xml:
<application>
<resource-handler>org.omnifaces.resourcehandler.CombinedResourceHandler</resource-handler>
<resource-handler>org.primefaces.extensions.application.PrimeFacesExtensionsResourceHandler</resource-handler>
</application>
This issue is fixed in PrimeFaces Extensions 6.2.8 or higher.
https://github.com/primefaces-extensions/primefaces-extensions.github.com/issues/601