1
votes

In a JSF 2.2 project with PrimeFaces (currently latest: 5.1) I have had problems with <p:fileUpload>. In a multi upload scenario randomly selected files were not uploaded. The problem was finally solved by enabled Partial State Saving (PSS) in web.xml:

<context-param>
    <param-name>javax.faces.PARTIAL_STATE_SAVING</param-name>
    <param-value>true</param-value>
</context-param>

Now after enabling PSS, almost all my pages throw duplicate id exception (although there is really no duplicate0. I have CRUD pages with <p:dataTable> and binding to view-scoped beans. When I switch to Mojarra duplicate id errors are gone, but for some reasons I want to work with MyFaces. Is there any workaround? Is this a bug with MyFaces.

I'm using MyFaces 2.2.5. And here is the related part of stack trace (at line 90, I have the first <p:column> inside a <p:dataTable>):

2014-11-01 11:31:51,390 ERROR <admin> Unhandled exception on component null during phase RENDER_RESPONSE(6): 
org.apache.myfaces.view.facelets.compiler.DuplicateIdException: Component with duplicate id "form:keywordDataTable:j_id_39" found. The first component is /admin/keyword.xhtml at line 90 and column 99
    at org.apache.myfaces.view.facelets.compiler.CheckDuplicateIdFaceletUtils.createAndQueueException(CheckDuplicateIdFaceletUtils.java:152) ~[myfaces-impl-2.2.5.jar:2.2.5]
    at org.apache.myfaces.view.facelets.compiler.CheckDuplicateIdFaceletUtils.checkIds(CheckDuplicateIdFaceletUtils.java:107) ~[myfaces-impl-2.2.5.jar:2.2.5]
    at org.apache.myfaces.view.facelets.compiler.CheckDuplicateIdFaceletUtils.checkIds(CheckDuplicateIdFaceletUtils.java:124) ~[myfaces-impl-2.2.5.jar:2.2.5]
    at org.apache.myfaces.view.facelets.compiler.CheckDuplicateIdFaceletUtils.checkIds(CheckDuplicateIdFaceletUtils.java:124) ~[myfaces-impl-2.2.5.jar:2.2.5]
    at org.apache.myfaces.view.facelets.compiler.CheckDuplicateIdFaceletUtils.checkIds(CheckDuplicateIdFaceletUtils.java:124) ~[myfaces-impl-2.2.5.jar:2.2.5]
    at org.apache.myfaces.view.facelets.compiler.CheckDuplicateIdFaceletUtils.checkIds(CheckDuplicateIdFaceletUtils.java:124) ~[myfaces-impl-2.2.5.jar:2.2.5]
    at org.apache.myfaces.view.facelets.compiler.CheckDuplicateIdFaceletUtils.checkIds(CheckDuplicateIdFaceletUtils.java:89) ~[myfaces-impl-2.2.5.jar:2.2.5]
    at org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.saveView(DefaultFaceletsStateManagementStrategy.java:688) ~[myfaces-impl-2.2.5.jar:2.2.5]
    at org.apache.myfaces.application.StateManagerImpl.saveView(StateManagerImpl.java:213) ~[myfaces-impl-2.2.5.jar:2.2.5]
    at javax.faces.application.StateManager.getViewState(StateManager.java:262) ~[myfaces-api-2.2.5.jar:2.2.5]
    at org.apache.myfaces.context.servlet.PartialViewContextImpl.processPartialRendering(PartialViewContextImpl.java:581) ~[myfaces-impl-2.2.5.jar:2.2.5]
    at org.apache.myfaces.context.servlet.PartialViewContextImpl.processPartial(PartialViewContextImpl.java:415) ~[myfaces-impl-2.2.5.jar:2.2.5]
    at org.primefaces.context.PrimePartialViewContext.processPartial(PrimePartialViewContext.java:60) ~[primefaces-5.1.1-UR.jar:5.1.1-UR]
    at javax.faces.context.PartialViewContextWrapper.processPartial(PartialViewContextWrapper.java:85) ~[myfaces-api-2.2.5.jar:2.2.5]
    at javax.faces.component.UIViewRoot.encodeChildren(UIViewRoot.java:516) ~[myfaces-api-2.2.5.jar:2.2.5]
    at javax.faces.component.UIComponentBase.encodeAll(UIComponentBase.java:541) ~[myfaces-api-2.2.5.jar:2.2.5]
    at org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1891) ~[myfaces-impl-2.2.5.jar:2.2.5]
    at org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:313) ~[myfaces-impl-2.2.5.jar:2.2.5]
    at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:58) ~[myfaces-api-2.2.5.jar:2.2.5]
    at org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:116) ~[myfaces-impl-2.2.5.jar:2.2.5]
    at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:267) ~[myfaces-impl-2.2.5.jar:2.2.5]
    at javax.faces.webapp.FacesServlet.service(FacesServlet.java:200) [myfaces-api-2.2.5.jar:2.2.5]
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) [catalina.jar:7.0.47]
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) [catalina.jar:7.0.47]
    at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:51) [tomcat7-websocket.jar:7.0.47]
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) [catalina.jar:7.0.47]
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) [catalina.jar:7.0.47]
1
I don't think there is a bug in MyFaces. Attach the stack trace could help. - lu4242
Here is a related post: Binding causes duplicate ID. Note that in my case I don't access session-scoped binding, but view-scoped beans. When I remove binding duplicate error is resolved, but I cannot remove them. - Mohsen
The stack trace is for Mojarra, not for MyFaces. I think your problem is related to use view scope beans to hold component bindings. My suggestions is use always request scope beans for your component bindings, and make a reference to the view scope bean from your request scope bean, otherwise the component will be serialized with the view scope bean and that could cause you problems. It is not a bug, it is something that is on JSF spec. - lu4242
OK, when component is serialized, why should duplicate ID error occur? I use binding to access filtering/sorting metadata to filter my lazy data model. BTW, Why this works with Mojarra? - Mohsen
Just for the reference, JSF spec section 3.1.5 Component Binding says: "... If application developers place managed beans that are pointed at by component binding expressions in any scope other than request scope, the system cannot behave correctly.... There are also potentially negative impacts on memory management when placing a component binding in “session” or “view” scopes. ..." - lu4242

1 Answers

2
votes

Just for the reference, JSF spec section 3.1.5 Component Binding says: "... If application developers place managed beans that are pointed at by component binding expressions in any scope other than request scope, the system cannot behave correctly.... There are also potentially negative impacts on memory management when placing a component binding in “session” or “view” scopes. ..."