You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Leonardo Uribe (JIRA)" <de...@myfaces.apache.org> on 2012/05/29 11:20:25 UTC
[jira] [Commented] (MYFACES-3554) REGRESSION: 2.0.12/2.1.6 (and
above) fail on state saving
[ https://issues.apache.org/jira/browse/MYFACES-3554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13284686#comment-13284686 ]
Leonardo Uribe commented on MYFACES-3554:
-----------------------------------------
Hi Richard
I can see the problem. In 2.1.6, some changes were done to PSS algorithm and in myfaces in general, trying to get a better performance. All facelet ids algorithm was changed, for another one with a lot better stability.
The problem is to ensure the state can be saved and restored correctly, we need to generate the same ids, even if some part of the component tree changes dynamically, and in that "edge" part there was some documented use cases that just failed.
The issues that is causing this trouble is:
MYFACES-3451 Improve PSS algorithm when a dynamic view (use of c:if or ui:include src=#{...}) is used
MYFACES-3329 Fix PSS algorithm to ensure c:if and ui:include src="#{...}" related use cases will work without rely on org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS_PRESERVE_STATE
MYFACES-3330 Generate small generated unique ids for components without explicit ids
MYFACES-3331 Identifier stored on MARK_CREATED should be unique per component on the same
In 2.1.6, I put "the final block of the puzzle".
To go directly to the point, any facelet component or tag that changes dynamically the component tree, like <c:if ...>, <ui:include src="#{...}"/> and others like the one you used in metawidget (the first time I see an use like that one outside mf-core), should call some methods to tell facelets that this part is changed dynamically and it is necessary to generate unique ids from this place.
Take a look at these classes:
org.apache.myfaces.view.facelets.tag.jstl.core.IfHandler
org.apache.myfaces.view.facelets.tag.ui.IncludeHandler
org.apache.myfaces.view.facelets.tag.jstl.core.ChooseHandler
You'll see how diferent dynamic components uses that API, to indicate how to create the ids. Also, there is some logic with the intention of change the initial state in a dynamic part, to prevent save it fully into the state and just save a small delta. For example, in c:if, it is detected the change of some condition and if that is true, a change is done over a map stored in UIViewRoot, so the next time the view is restored, the initial value will be taken from there and the view will be restored correctly without that overhead.
I know a solution for this one could involve some changes into your implementation, because that area does not have any spec at all, and introduce a dependency to myfaces stuff, but at the end the benefits involved exceed by far the problems. If you have an idea about how to create a good API for this problem (maybe we can create an interface for this one and include it in MyFaces, to ensure stability over the time), we can discuss it and see what we can do.
Note this is something new, so maybe we need to investigate more about it.
> REGRESSION: 2.0.12/2.1.6 (and above) fail on state saving
> ---------------------------------------------------------
>
> Key: MYFACES-3554
> URL: https://issues.apache.org/jira/browse/MYFACES-3554
> Project: MyFaces Core
> Issue Type: Bug
> Affects Versions: 2.0.12, 2.0.13, 2.1.6, 2.1.7
> Environment: Tomcat 7.0.25
> Reporter: Kennard Consulting
> Attachments: addressbook-faces.2.0.11.war, addressbook-faces.2.0.12.war, addressbook-faces.2.1.5.war, addressbook-faces.2.1.6.war
>
>
> Hi guys,
> Thanks again for all the great work you do on MyFaces!
> There appears to have been an identical regression between MyFaces 2.0.11 and 2.0.12, and between MyFaces 2.1.5 and 2.1.6. My apologies for not picking this up earlier. This regression is likely related to a suite of unit tests I gave you in MYFACES-2935, though unfortunately I guess my suite didn't cover this particular bug?
> I attach 4 versions of the same sample application. You'll see it works for the 2.0.11/2.1.5 versions, but not the 2.0.12/2.1.6 versions. To reproduce:
> 1. Run the app
> 2. On the opening page click on contact 'Homer Simpson'
> 3. Click Edit
> In the regressed versions you will see:
> java.lang.IllegalStateException: component with duplicate id "form:j_id_b" found
> org.apache.myfaces.view.facelets.compiler.CheckDuplicateIdFaceletUtils.checkIdsStatefulComponents(CheckDuplicateIdFaceletUtils.java:54)
> org.apache.myfaces.view.facelets.compiler.CheckDuplicateIdFaceletUtils.checkIdsStatefulComponents(CheckDuplicateIdFaceletUtils.java:75)
> org.apache.myfaces.view.facelets.compiler.CheckDuplicateIdFaceletUtils.checkIdsStatefulComponents(CheckDuplicateIdFaceletUtils.java:75)
> org.apache.myfaces.view.facelets.compiler.CheckDuplicateIdFaceletUtils.checkIdsStatefulComponents(CheckDuplicateIdFaceletUtils.java:75)
> org.apache.myfaces.view.facelets.compiler.CheckDuplicateIdFaceletUtils.checkIdsStatefulComponents(CheckDuplicateIdFaceletUtils.java:75)
> org.apache.myfaces.view.facelets.compiler.CheckDuplicateIdFaceletUtils.checkIdsStatefulComponents(CheckDuplicateIdFaceletUtils.java:35)
> org.apache.myfaces.view.facelets.DefaultFaceletsStateManagementStrategy.saveView(DefaultFaceletsStateManagementStrategy.java:488)
> org.apache.myfaces.application.StateManagerImpl.saveView(StateManagerImpl.java:166)
> org.apache.myfaces.view.facelets.FaceletViewDeclarationLanguage.renderView(FaceletViewDeclarationLanguage.java:1619)
> org.apache.myfaces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:264)
> org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor.java:115)
> org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:239)
> javax.faces.webapp.FacesServlet.service(FacesServlet.java:191)
>
> I'm assuming this is on your end, but if it's a case of you tightening up spec compliance and exposing a bug in my code, please let know!
> Regards,
> Richard.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira