Menu
I am developing a JSF custom component. This component has the purpose of encapsulating another component (namely a PrimeFaces table) and adding customized behaviour to it. For example, one of the features that it supports is creating PrimeFaces columns dynamically from the underlying data or from certain attributes. Furthermore, it supports declaring additional PrimeFaces columns in XHTML, which should be added to the encapsulated PrimeFaces table as well.
Consider this example:
<my:table id="table" fields="title,label,value,additional">
<primefaces:column id="additional">
some content
</primefaces:column>
</my:table>
My custom component dynamically creates the PrimeFaces columns from the fields attribute during rendering. It then moves all its column children to the PrimeFaces table, so after rendering the component tree looks like follows:
my:table id="table"
|---primefaces:table id="table_table"
|---primefaces:column id="title"
|---primefaces:column id="label"
|---primefaces:column id="value"
|---primefaces:column id="additional"
During first rendering, this works fine. However, when I then perform an AJAX update of my component, I get the following exception:
javax.faces.FacesException: Cannot remove the same component twice: table:additional
at com.sun.faces.context.StateContext$DynamicAddRemoveListener.handleAddRemoveWithAutoPrune(StateContext.java:761)
at com.sun.faces.context.StateContext$DynamicAddRemoveListener.handleRemove(StateContext.java:629)
at com.sun.faces.context.StateContext$AddRemoveListener.processEvent(StateContext.java:342)
at com.sun.faces.context.StateContext$DynamicAddRemoveListener.processEvent(StateContext.java:565)
at javax.faces.event.SystemEvent.processListener(SystemEvent.java:108)
at javax.faces.event.ComponentSystemEvent.processListener(ComponentSystemEvent.java:118)
at com.sun.faces.application.ApplicationImpl.processListenersAccountingForAdds(ApplicationImpl.java:2218)
at com.sun.faces.application.ApplicationImpl.invokeViewListenersFor(ApplicationImpl.java:2036)
at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:290)
at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:245)
at javax.faces.application.ApplicationWrapper.publishEvent(ApplicationWrapper.java:726)
at javax.faces.component.UIComponentBase.disconnectFromView(UIComponentBase.java:2275)
at javax.faces.component.UIComponentBase.doPreRemoveProcessing(UIComponentBase.java:1939)
at javax.faces.component.UIComponentBase.setParent(UIComponentBase.java:437)
at javax.faces.component.UIComponentBase$ChildrenList.remove(UIComponentBase.java:2757)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.adjustIndexOfDynamicChildren(ComponentTagHandlerDelegateImpl.java:283)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:223)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
at com.sun.faces.facelets.tag.ui.DefineHandler.applyDefinition(DefineHandler.java:106)
at com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:206)
at com.sun.faces.facelets.impl.DefaultFaceletContext$TemplateManager.apply(DefaultFaceletContext.java:395)
at com.sun.faces.facelets.impl.DefaultFaceletContext.includeDefinition(DefaultFaceletContext.java:366)
at com.sun.faces.facelets.tag.ui.InsertHandler.apply(InsertHandler.java:111)
at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:202)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
at com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:194)
at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:87)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:312)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:371)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:350)
at com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:199)
at com.sun.faces.facelets.tag.ui.IncludeHandler.apply(IncludeHandler.java:124)
at com.sun.faces.facelets.tag.ui.InsertHandler.apply(InsertHandler.java:116)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:202)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:202)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
at com.sun.faces.facelets.tag.ui.DefineHandler.applyDefinition(DefineHandler.java:106)
at com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:206)
at com.sun.faces.facelets.impl.DefaultFaceletContext$TemplateManager.apply(DefaultFaceletContext.java:395)
at com.sun.faces.facelets.impl.DefaultFaceletContext.includeDefinition(DefaultFaceletContext.java:366)
at com.sun.faces.facelets.tag.ui.InsertHandler.apply(InsertHandler.java:111)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:202)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:202)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
at com.sun.faces.facelets.tag.jsf.core.ViewHandler.apply(ViewHandler.java:225)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
at javax.faces.view.facelets.DelegatingMetaTagHandler.applyNextHandler(DelegatingMetaTagHandler.java:137)
at com.sun.faces.facelets.tag.jsf.ComponentTagHandlerDelegateImpl.apply(ComponentTagHandlerDelegateImpl.java:202)
at javax.faces.view.facelets.DelegatingMetaTagHandler.apply(DelegatingMetaTagHandler.java:120)
at javax.faces.view.facelets.CompositeFaceletHandler.apply(CompositeFaceletHandler.java:95)
at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:87)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:312)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:371)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:350)
at com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:199)
at com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:174)
at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:87)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:312)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:371)
at com.sun.faces.facelets.impl.DefaultFacelet.include(DefaultFacelet.java:350)
at com.sun.faces.facelets.impl.DefaultFaceletContext.includeFacelet(DefaultFaceletContext.java:199)
at com.sun.faces.facelets.tag.ui.CompositionHandler.apply(CompositionHandler.java:174)
at com.sun.faces.facelets.compiler.NamespaceHandler.apply(NamespaceHandler.java:93)
at com.sun.faces.facelets.compiler.EncodingHandler.apply(EncodingHandler.java:87)
at com.sun.faces.facelets.impl.DefaultFacelet.apply(DefaultFacelet.java:161)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.buildView(FaceletViewHandlingStrategy.java:1006)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:99)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:219)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:647)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
at de.gebit.trend.servlet.security.AuthorizationFilter.doFilter(AuthorizationFilter.java:269)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:198)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:108)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:620)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:349)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:783)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:789)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1455)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Unknown Source)
So, only the column that was moved from my table to the PrimeFaces table is creating this error. The other columns do not get recreated, because during rendering, I use an instance variable stored in the StateHelper to indicate that columns are already created.
I somehow understand where this exception is coming from and that it has something to do with JSF saving the complete component tree, and when JSF restores the view, the saved state is inconsistent with the XHTML. What I don't know is, how to solve this problem.
Could someone please explain to me how this state saving mechanism exactly works, especially in conjunction with dynamically added children and how to avoid this exception?
I've created a small sample project without additional frameworks that were in use before. It can be found on my GitHub profile. One main framework that was in use before was fiddeling with the AddRemoveListeners installed in the StateContext for replaying dynamic actions. To avoid this having an impact on my issue and to create a reproducible environment, I removed them.
The behavior I witness now is slightly different (there are no exceptions anymore) and depends on whether partial state saving is enabled/disabled and the method I use to move the primefaces:column:
The first rendering of the table in all cases works fine. I then perform a postback request by submitting a paging request. The behavior then is erronous in some cases.
With partial state saving enabled, paging does not work. I do not get an exception, but a lot of warnings similar to this:
Feb 10, 2017 4:33:11 PM com.sun.faces.application.view.FaceletPartialStateManagementStrategy saveDynamicActions
WARNUNG: Unable to save dynamic action with clientId 'form:table:table_table:additional' because the UIComponent cannot be found
This warning appears for every component that was moved dynamically created in or moved to the primefaces:table or was a child component of one of those.
With partial state saving disabled, paging does work but shows different behavior depending on when the one custom primefaces:column is moved.
When the primefaces:column is moved during render response phase, e.g. in encodeXxx, everything works fine. All the columns are in the correct order and with correct values and paging works perfectly fine.
When using this approach, as per @BalusC suggestion, the moved primefaces:column disappears on paging. The PostAddToViewEvent is called several times and the column is moved while handling this event, however on rendering, it has disappeared and only the three previously created columns are still there.
At this point, I am more than confused. Is this a bug in Mojarra or in Primefaces or am I doing something wrong? Is this kind of behavior even possible with JSF?
851
JSF state management remembers dynamic manipulations to the component tree so that it can ensure that it's after the restore view of a postback exactly the same as it was during render response of the previous request which generated the post form.
The exception which you got,
javax.faces.FacesException: Cannot remove the same component twice: table:additional
basically tells that you've added the very same component twice to the same parent.
In other words, you obtained the desired component from the component tree and then added it to the desired parent. However, as per the given exception, it was at that moment already attached to the desired parent! Effectively, you performed a no-op. But JSF remembers every single dynamic component add/remove through postbacks on the same view, even though it's effectively a no-op. That part may in turn be a bug in JSF implementation itself, but you should in first place not be moving around components when they are aready in the desired place.
A quick fix would be to check the component's parent by UIComponent#getParent() if it isn't already the desired one and if so then skip the getChildren().add() call.
if (!componentToMove.getParent().equals(targetParent)) {
targetParent.getChildren().add(componentToMove);
}
A hack would be to set UIComponent#setInView() to false so that JSF doesn't remember the dynamic action.
componentToMove.setInView(false);
targetParent.getChildren().add(componentToMove);
componentToMove.setInView(true);
// NOTE: with MyFaces, call setInView() on componentToMove.getParent() instead.
Be however cautious when using this method, see also its javadoc.
However, the most natural way to perform component tree manipulations is a postAddtoViewEvent listener instead of during encodeXxx() method.
@ListenerFor(systemEventClass=PostAddToViewEvent.class)
public class YourComponent extends SomeUIComponent {
@Override
public void processEvent(ComponentSystemEvent event) {
if (event instanceof PostAddToViewEvent) {
targetParent.getChildren().add(componentToMove);
}
}
The simple answer is: it is the other frameworks fault that is in use. This framework overwrites the state saving mechanism of JSF and replaces it with a custom mechanism. The implementation, however, was faulty and did not take care of the DynamicAddRemoveListeners responsible for saving the actions of dynamic componants correctly. They fixed the bug, now it works fine.
However, there were several things that were necessary to fix my component that I want to point out:
First, @BalusC pointed me to the correct way of moving child components in a custom JSF component: it should be done using a PostAddToView event listener.
@ListenerFor(systemEventClass=PostAddToViewEvent.class) public class YourComponent extends SomeUIComponent { @Override public void processEvent(ComponentSystemEvent event) { if (event instanceof PostAddToViewEvent) { targetParent.getChildren().add(componentToMove); } } }
This approach has the drawback, however, that the components attributes won't be set at this point. So if you need those, components can only be created/moved during render response phase.
Second, child components of a custom JSF component should not be saved in the StateHelper. They should be recreated on every request so that JSF finds these components when replaying the dynamic actions.
Third, the ID of dynamically created child components (if set) should always be set when the component is created itself. My custom component set the ID of its children components only during render response phase, so when JSF tried to replay the dynamic actions, it could not find the respective components. This was the solution to the problem mentioned above in the section Partial state saving enabled.
So with all these adaptions and the fix for the other framework, now finally my component works as desired.
3
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
