Known Issues (general) (original) (raw)
This wiki lists known issues of OmniFaces in combination with specific JSF implementations, JSF component libraries and application servers. Note: for known issues with specific CDI features, head to Known Issues (CDI).
Mojarra 2.0.0-2.1.7
When the <o:highlight> or <o:onloadScript> is been used with javax.faces.PARTIAL_STATE_SAVING set to false (which is not the default setting), then it will fail during a postback as follows:
java.lang.ArrayIndexOutOfBoundsException: 1
at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1346)
at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1351)
at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:1370)
at javax.faces.component.UIViewRoot.processRestoreState(UIViewRoot.java:879)
at com.sun.faces.application.StateManagerImpl.restoreView(StateManagerImpl.java:208)
at com.sun.faces.application.view.ViewHandlingStrategy.restoreView(ViewHandlingStrategy.java:123)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.restoreView(FaceletViewHandlingStrategy.java:453)
at com.sun.faces.application.view.MultiViewHandler.restoreView(MultiViewHandler.java:142)
at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:303)
at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:303)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:192)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:116)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593)
This is related to Mojarra issue 2037 and is fixed since Mojarra 2.1.8.
Mojarra 2.1.11
When the CombinedResourceHandler is used, you will get the following exception during a postback when using Mojarra 2.1.11 (this and only this version, older versions work fine):
java.lang.NullPointerException
com.sun.faces.application.view.FaceletPartialStateManagementStrategy.saveDynamicActions(FaceletPartialStateManagementStrategy.java:426)
com.sun.faces.application.view.FaceletPartialStateManagementStrategy.saveView(FaceletPartialStateManagementStrategy.java:491)
com.sun.faces.application.StateManagerImpl.saveView(StateManagerImpl.java:89)
com.sun.faces.application.view.WriteBehindStateWriter.flushToWriter(WriteBehindStateWriter.java:225)
com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:441)
com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:125)
com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:121)
com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:594)
This is caused by a Mojarra bug in state saving of dynamically manipulated components. This has been reported as Mojarra issue 2471 and is fixed in Mojarra 2.1.12.
Mojarra 2.0.0-2.1.13
When the Html5RenderKit is used in combination with different <h:inputText type>, then the <f:ajax> will skip those inputs during preparing the query string. This has been reported as Mojarra issue 2532 and is fixed in Mojarra 2.1.14.
Mojarra 2.1.22-2.1.23
The <o:onloadScript> is not invoked at end of body during a synchronous postback. This is caused by an unknown bug in Mojarra and is fixed since 2.1.24. You should however upgrade to OmniFaces 1.6 if you're using 2.1.24 or newer. The <o:onloadScript> of OmniFaces 1.5 and older still works fine on 2.1.21 or older.
MyFaces 2.0.0-2.0.7 / 2.1.0-2.1.1
Deploy of a webapp with the since OmniFaces 1.1 introduced InvokeActionEventListener / PreInvokeActionEvent / PostInvokeActionEvent will fail with the following exception:
java.lang.NullPointerException: type
at org.apache.myfaces.shared_impl.util.ClassUtils.classForName(ClassUtils.java:180)
at org.apache.myfaces.config.FacesConfigurator.configureRuntimeConfig(FacesConfigurator.java:920)
at org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:468)
at org.apache.myfaces.webapp.AbstractFacesInitializer.buildConfiguration(AbstractFacesInitializer.java:313)
at org.apache.myfaces.webapp.Jsp21FacesInitializer.initContainerIntegration(Jsp21FacesInitializer.java:73)
at org.apache.myfaces.webapp.AbstractFacesInitializer.initFaces(AbstractFacesInitializer.java:136)
at org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:111)
This is caused by a MyFaces bug in registering custom JSF events which are annotated by @NamedEvent. This has been reported as MyFaces issue 3277 and is fixed in MyFaces 2.0.8/2.1.2.
MyFaces 2.0.17 / 2.1.11
Rendering of a page with <o:viewParam> / <o:enableRestorableView> (in fact, anything which needs to go into <f:metadata>) will fail with the following exception:
java.lang.IllegalStateException: component with duplicate id "someId" found
at org.apache.myfaces.view.facelets.compiler.CheckDuplicateIdFaceletUtils.checkIds(CheckDuplicateIdFaceletUtils.java:100)
at org.apache.myfaces.view.facelets.compiler.CheckDuplicateIdFaceletUtils.checkIds(CheckDuplicateIdFaceletUtils.java:116)
at org.apache.myfaces.view.facelets.compiler.CheckDuplicateIdFaceletUtils.checkIds(CheckDuplicateIdFaceletUtils.java:110)
at org.apache.myfaces.view.facelets.compiler.CheckDuplicateIdFaceletUtils.checkIds(CheckDuplicateIdFaceletUtils.java:82)
at org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.saveView(DefaultFaceletsStateManagementStrategy.java:558)
at org.apache.myfaces.application.StateManagerImpl.saveView(StateManagerImpl.java:188)
at org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:2052)
at org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:285)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:59)
at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:116)
at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:241)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:199)
This is caused by a MyFaces bug in component ID generation. This has been reported as MyFaces issue 3709 and is fixed in MyFaces 2.0.18/2.1.12.
MyFaces 2.3.0
<o:onloadScript> fails on every ajax request with:
java.lang.AbstractMethodError: org.omnifaces.component.script.OnloadScript$1.getWrapped()Ljavax/faces/context/ResponseWriter;
at org.omnifaces.component.script.OnloadScript$1.writeText(OnloadScript.java:119)
at org.apache.myfaces.view.facelets.compiler.LiteralTextInstruction.write(LiteralTextInstruction.java:38)
at org.apache.myfaces.view.facelets.compiler.UIInstructions.encodeBegin(UIInstructions.java:46)
at org.apache.myfaces.view.facelets.compiler.UILeaf.encodeAll(UILeaf.java:491)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:636)
at org.omnifaces.component.script.OnloadScript.processEvent(OnloadScript.java:124)
at javax.faces.event.SystemEvent.processListener(SystemEvent.java:49)
at javax.faces.event.ComponentSystemEvent.processListener(ComponentSystemEvent.java:57)
at org.apache.myfaces.application._ApplicationUtils._traverseListenerListWithCopy(_ApplicationUtils.java:168)
This is caused by a bug in MyFaces. This has been reported as issue 4208 and will be fixed in 2.3.1.
MyFaces 2.3.x
@ViewScoped unload will in OmniFaces 2.6.8 or older fail as below (not affecting the web application's functionality, only the memory usage):
java.lang.ClassCastException: [B cannot be cast to java.base/java.lang.Integer
at org.omnifaces.util.Hacks.removeViewState(Hacks.java:432)
at org.omnifaces.viewhandler.OmniViewHandler.unloadView(OmniViewHandler.java:134)
at org.omnifaces.viewhandler.OmniViewHandler.restoreView(OmniViewHandler.java:101)
at javax.faces.application.ViewHandlerWrapper.restoreView(ViewHandlerWrapper.java:97)
This is caused by a bug in OmniFaces and is fixed in 2.6.9.
PrimeFaces 2.0-3.1
The FullAjaxExceptionHandler will not work on PrimeFaces ajax requests, because PrimeFaces did by design not support an ajax render of @all before version 3.2. If you can't upgrade to at least PrimeFaces 3.2, then you can workaround it with the following script which should be loaded after PrimeFaces' own scripts (just referencing it by <h:outputScript> anywhere in the view ought to be sufficient):
var originalPrimeFacesAjaxResponseFunction = PrimeFaces.ajax.AjaxResponse; PrimeFaces.ajax.AjaxResponse = function(responseXML) { var newViewRoot = $(responseXML.documentElement).find("update[id='javax.faces.ViewRoot']").text();
if (newViewRoot) {
$('head').html(newViewRoot.substring(newViewRoot.indexOf("<head>") + 6, newViewRoot.indexOf("</head>")));
$('body').html(newViewRoot.substring(newViewRoot.indexOf("<body>") + 6, newViewRoot.indexOf("</body>")));
}
else {
originalPrimeFacesAjaxResponseFunction.apply(this, arguments);
}};
PrimeFaces Mobile (all versions)
PrimeFaces Mobile is incompatible with CombinedResourceHandler. It does not make use of JSF component resource facility. Instead, all CSS/JS resources are hardcoded in the PageRenderer. Also, any custom styles/scripts are been added as a facet of the page instead of to the <h:head>. The CombinedResourceHandler is only capable of combining JSF component resources, not hardcoded or faceted resources.
PrimeFaces Extensions <=0.7.1-6.2 (FIXED in 6.2.8 or higher)
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:
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:
org.omnifaces.resourcehandler.CombinedResourceHandler org.primefaces.extensions.application.PrimeFacesExtensionsResourceHandler
FIXED: This issue was fixed in PFE 6.2.8: https://github.com/primefaces-extensions/primefaces-extensions.github.com/issues/601
RichFaces 4.3.1-4.3.2 (and probably future versions)
RichFaces custom implementation of PartialViewContext is not delegating to the endDocument() call when the current PartialResponseWriter does not seem to be an instance of their own implementation, but is instead wrapped by the one from another JSF library, such as OmniFaces, PrimeFaces and more. This will result in broken ajax responses in certain environments wherein RichFaces is initialized before the other JSF library. See also issue 191.
GlassFish 3.x
In GlassFish 3.x the request scope is not available in a request listener. Attempting to instantiate a request scoped bean from within such request listener will thus result in a context not active exception.
Furthermore, instantiating session scoped beans from within a session listener will corrupt the session, causing an exception like the following when accessing the session afterwards:
java.lang.IllegalArgumentException: Should never reach here
at org.apache.catalina.connector.SessionTracker.track(SessionTracker.java:168)
at org.apache.catalina.connector.Request.doGetSession(Request.java:2939)
at org.apache.catalina.connector.Request.getSession(Request.java:2583)
at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:920)
at javax.servlet.http.HttpServletRequestWrapper.getSession(HttpServletRequestWrapper.java:259)
at com.sun.faces.context.ExternalContextImpl.getSession(ExternalContextImpl.java:155)
at javax.faces.context.ExternalContextWrapper.getSession(ExternalContextWrapper.java:396)
at javax.faces.context.ExternalContextWrapper.getSession(ExternalContextWrapper.java:396)
There is a workaround available that's documented here: http://omnifaces.org/docs/javadoc/current/org/omnifaces/cdi/Eager.html
(last tested with GlassFish 3.1.2.2)
GlassFish 3.x and 4.0.0 (anything older than 4.0.1)
Since OmniFaces 1.6, which features new CDI artifacts, the deploy of a webapp which uses EJB, but which doesn't use CDI, will cause an exception with the following root cause in GlassFish 3.x and 4.0.0 during creating the EJBs:
Caused by: java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.hash(ConcurrentHashMap.java:333)
at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:988)
at org.jboss.weld.manager.BeanManagerImpl.getBean(BeanManagerImpl.java:1076)
at org.jboss.weld.manager.BeanManagerImpl.getBean(BeanManagerImpl.java:148)
at org.glassfish.weld.services.JCDIServiceImpl._createJCDIInjectionContext(JCDIServiceImpl.java:169)
at org.glassfish.weld.services.JCDIServiceImpl.createJCDIInjectionContext(JCDIServiceImpl.java:146)
at com.sun.ejb.containers.BaseContainer.createEjbInstanceAndContext(BaseContainer.java:1639)
at com.sun.ejb.containers.StatelessSessionContainer.createStatelessEJB(StatelessSessionContainer.java:475)
... 82 more
This is caused because GlassFish by default implicitly checks for CDI artifacts in JARs but doesn't properly register them when the webapp itself is in first place not configured to use CDI. This has been reported as GlassFish issue 20566 and is fixed in 4.0.1. There are 2 workarounds if you can't upgrade:
- Enable CDI anyway in your web application by creating/generating the
/WEB-INF/beans.xmlfile. - Disable implicit CDI artifact checking by executing the following asadmin command:
$GFHOME/bin/asadmin set configs.config.server-config.cdi-service.enable-implicit-cdi=false See also issue 215.
GlassFish 4.0.0
Using #{now} and #{startup} will cause an exception with the following root cause:
Caused by: java.lang.NullPointerException
at org.glassfish.weld.DeploymentImpl.findRootBda(DeploymentImpl.java:700)
at org.glassfish.weld.DeploymentImpl.getBeanDeploymentArchive(DeploymentImpl.java:682)
at org.jboss.weld.manager.BeanManagerLookupService.lookupBeanManager(BeanManagerLookupService.java:48)
at org.jboss.weld.manager.BeanManagerLookupService.lookupBeanManager(BeanManagerLookupService.java:60)
at org.jboss.weld.manager.BeanManagerImpl.getInjectionTargetFactory(BeanManagerImpl.java:1381)
at org.jboss.weld.manager.BeanManagerImpl.createInjectionTarget(BeanManagerImpl.java:1039)
at org.glassfish.weld.services.JCDIServiceImpl.injectManagedObject(JCDIServiceImpl.java:283)
at org.glassfish.faces.integration.GlassFishInjectionProvider.inject(GlassFishInjectionProvider.java:189)
at com.sun.faces.mgbean.BeanBuilder.injectResources(BeanBuilder.java:203)
at com.sun.faces.mgbean.BeanBuilder.build(BeanBuilder.java:101)
at com.sun.faces.mgbean.BeanManager.createAndPush(BeanManager.java:409)
at com.sun.faces.mgbean.BeanManager.create(BeanManager.java:269)
at com.sun.faces.el.ManagedBeanELResolver.resolveBean(ManagedBeanELResolver.java:244)
at com.sun.faces.el.ManagedBeanELResolver.getValue(ManagedBeanELResolver.java:116)
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176)
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203)
at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:116)
at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:226)
at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:50)
at com.sun.faces.facelets.el.ELText$ELTextVariable.writeText(ELText.java:227)
at com.sun.faces.facelets.el.ELText$ELTextComposite.writeText(ELText.java:150)
at com.sun.faces.facelets.compiler.TextInstruction.write(TextInstruction.java:85)
... 39 more
The cause is unknown. This is already reported as GlassFish issue 20775, which appears to be fixed in GlassFish 4.1 as consequence of another bugfix. If you can't upgrade to GlassFish 4.1, then a workaround would be to create #{now} (and #{startup}) yourself using a servlet filter. See also this Stack Overflow question.
Liberty 1.0.x (8.5.x) / WebSphere 8.5.x
CDI injection in converters and validators does not work in Liberty 1.0.x (8.5.x) and WebSphere 8.5.x. There'll be no exception, but a null value is injected instead of the actual instance.
The problem is caused by the fact that the mentioned servers from IBM (Liberty and WebSphere thus) ship with a very old version of MyFaces, namely 2.0.4. Among its many bugs, a particular problem is with state management (related to https://issues.apache.org/jira/browse/MYFACES-3257). This was fixed in MyFaces 2.0.8 and 2.1.2.
Unfortunately it's not really feasible to upgrade MyFaces in those IBM servers.
The workaround is to have Converters and Validators implement the Serializable interface.
See https://code.google.com/p/omnifaces/issues/detail?id=183 for additional details.
(last tested with Liberty 1.0.5 (8.5.5.2))
Resin 4.0.38 (anything older than 4.0.40)
Resin 4.0.38 it doesn't support generic producer methods which causes a failed deployment. On Resin 4.0.40 this will work correctly.
Resin 4.0.40 (likely all versions)
On Resin the <o:methodParam> tag handler doesn't work for actions, but does work for action listeners. It will result in an exception like the following:
javax.el.ELException: //server/omnifaces-showcase/WEB-INF/tags/actionmethod.xhtml @8,53 action="#{method}": 'method' is an illegal method expression on com.caucho.el.ValueExpr
at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:111)
at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87)
at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:101)
at javax.faces.component.UICommand.broadcast(UICommand.java:315)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:786)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1251)
at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:593)
at com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChain.java:109)
(last tested on Resin 4.0.40)