You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Kennard Consulting (JIRA)" <de...@myfaces.apache.org> on 2012/05/29 13:00:24 UTC
[jira] [Comment Edited] (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=13284722#comment-13284722 ]
Kennard Consulting edited comment on MYFACES-3554 at 5/29/12 10:59 AM:
-----------------------------------------------------------------------
Thanks Leonardo for your fast response. It's fantastic you're so readily able to understand the problem.
I think ideally, as your new id handling is supposed to be an optimisation, it'd be good if we could find a way for MyFaces to toggle the 'UIComponent is changed dynamically, generate unique ids from this place' flag automatically. Rather than using the MyFaces-specific PostAddPreRemoveFromViewListener.
Could it perhaps key off some behaviour in the UIComponent? For example, the Mojarra/MyFaces/Metawidget teams had all previously agreed that this was the correct way to do dynamic component manipulation:
http://blog.kennardconsulting.com/2010/10/safely-manipulating-component-tree-with.html
So could you take 'root.subscribeToViewEvent( PreRenderViewEvent.class, this )' as a hint that this UIComponent shouldn't use the new, optimized id stuff? Subscribing to PreRenderViewEvent would be pretty rare, I would think. Even if we got a false positive, the worst case scenario is that a UIComponent's id's may not be quite as optimized as they could be.
As another technique, could you detect calls to 'component.getChildren().add()' during render-time? I believe the Collection returned by 'component.getChildren()' is already more than just a standard List, so is there already a place to put a trigger in there to turn off optimized ids?
I don't really mind the mechanism, I'd just hope we could disable this new optimization automatically in cases where it might break things.
was (Author: kennardconsulting):
Thanks Leonardo for your fast response. It's fantastic you're so readily able to understand the problem.
I think ideally, as your new id handling is supposed to be an optimisation, it'd be good if we could find a way for MyFaces to toggle the 'UIComponent is changed dynamically, generate unique ids from this place' flag automatically. Rather than using the MyFaces-specific PostAddPreRemoveFromViewListener.
Could it perhaps key off some behaviour in the UIComponent? For example, we had all previously agreed that this was the correct way to do dynamic component manipulation:
http://blog.kennardconsulting.com/2010/10/safely-manipulating-component-tree-with.html
So could you take 'root.subscribeToViewEvent( PreRenderViewEvent.class, this )' as a hint that this UIComponent shouldn't use the new, optimized id stuff? Subscribing to PreRenderViewEvent would be pretty rare, I would think. Even if we got a false positive, the worst case scenario is that a UIComponent's id's may not be quite as optimized as they could be.
As another technique, could you detect calls to 'component.getChildren().add()' during render-time? I believe the Collection returned by 'component.getChildren()' is already more than just a standard List, so is there already a place to put a trigger in there to turn off optimized ids?
I don't really mind the mechanism, I'd just hope we could disable this new optimization automatically in cases where it might break things.
> 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
> Assignee: Leonardo Uribe
> Fix For: 2.0.14, 2.1.8
>
> 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