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.
Related
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
I am getting the below exception after migrating to JSF 2.2. Specifically, I'm upgrading Mojarra 2.1.17 to Mojarra 2.2.8.
java.lang.NoSuchMethodError: javax.faces.component.UIComponent.getPassThroughAttributes(Z)Ljava/util/Map;
at org.primefaces.renderkit.RendererUtils.renderPassThroughAttributes(RendererUtils.java:79)
at org.primefaces.renderkit.CoreRenderer.renderDynamicPassThruAttributes(CoreRenderer.java:119)
at org.primefaces.renderkit.CoreRenderer.renderPassThruAttributes(CoreRenderer.java:114)
at org.primefaces.renderkit.BodyRenderer.encodeBegin(BodyRenderer.java:44)
at javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:823)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1611)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1616)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:399)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:131)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:273)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:121)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:313)
When I check the UIComponent inside jsf-api-2.2.8.jar, I can see there is a method Map<String, Object> getPassThroughAttributes(boolean create);.
How is this caused and how can I solve it?
That method was introduced in JSF 2.2. This problem will thus happen when the webapp's runtime classpath is polluted with multiple different versioned JSF API libraries. In other words, you've still a JSF 2.0 or 2.1 API somewhere in the runtime classpath.
This suggests that you're trying to upgrade JSF by manually bundling it in the webapp and deploying it to a Java EE container which already bundles JSF out the box, such as WildFly, JBoss AS, GlassFish, WebLogic, WebSphere, etc. Your stacktrace is too short in order to be able to confirm that, but your question history confirms that you're using WebLogic.
In order to properly upgrade Mojarra in WebLogic, you should actually be replacing the JSF JAR(s) in /wlserver/modules folder.
In case you're actually using a barebones servletcontainer which doesn't bundle JSF out the box, such as Tomcat, then you'd need to verify if /WEB-INF/lib (or pom file in case of Maven) is free of duplicates in JSF API. Most common starter's mistake is having a javaee-api.jar in there too. This should be removed (or be set to provided). See also a.o. How do I import the javax.servlet API in my Eclipse project?
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 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
I have a JSF 1.1 app which was working fine in WAS 6.0 and needs to be migrated to WAS 7.0, but it results in the following exception, even though I have set parent_last in deployment.xml:
Uncaught init() exception created by servlet Faces Servlet in application:
java.lang.NullPointerException
at javax.faces.webapp.FacesServlet.init(FacesServlet.java:144)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.init(ServletWrapper.java:325)**
How is this caused and how can I solve it?
You will get this exception in JSF 1.1 when the application factory cannot be found. This has in turn among others the possible cause that the ConfigureListener hasn't run for some reason. This is normally automatically invoked based on the .tld file in the JSF library. You can always try to force the webapp to run it by adding the following entry to webapp's web.xml:
<listener>
<listener-class>com.sun.faces.config.ConfigureListener</listener-class>
</listener>
However, I don't guarantee that it will fix the problem altogether. You may get a different exception now which needs to be investigated and fixed separately.
WAS 7.0 ships with JSF 1.2 bundled and (well-designed) JSF 1.1 code is technically 100% compatible with JSF 1.2, so I'd rather recommend to just get rid of the JSF 1.1 libraries in your webapp and change the faces-config.xml to a JSF 1.2 compatible one.