pe:ckEditor doesn't work anymore after adding CombinedResourceHandler - jsf

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

org.omnifaces.resourcehandler.CombinedResourceHandler causes a JavaScript error to be issued, when a pe:ckEditor is used [duplicate]

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

How to prevent JSF from initializing automatically?

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.

Passthrough custom HTML5 attributes using Omnifaces

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.

NullPointerException with omnifaces CDNResourceHandler and myfaces 2.2.3

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.

Apache TomEE: want to user Mojarra JSF in my project instead of built-in Apache MyFaces

I have a related question. I am migrating my project from Jboss to TomEE. I was using Mojarra JSF, and have been having problems trying to get everything working using MyFaces (view Encryption problems, UI problems, ajax problems, etc). I just want to include Mojarra jars in my project, but looks like they are clashing with the built-in MyFaces jars that comes bundled with TomEE. I keep getting UnSupported exceptions.
Is there a way to specify that the Mojarra JSF should override myfaces? Is there a web.xml parameter or something? By the way, I am not using Maven (I've seen many examples with pom.xml dependency tags that cannot help me).
I tried that for 3 days, after making many tweaks(error stack-> google ->change some exotic xml parameter-> new error stack->google->change some exotic xml parameter etc....), I could make it work, except that EJB injection was not working anymore (getting null). So I surrendered and use myfaces instead of mojarra.

Resources