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 01:45:32 UTC
[jira] [Created] (MYFACES-3554) REGRESSION: 2.0.12/2.1.6 (and
above) fail on state saving
Kennard Consulting created MYFACES-3554:
-------------------------------------------
Summary: 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.1.7, 2.1.6, 2.0.13, 2.0.12
Environment: Tomcat 7.0.25
Reporter: Kennard Consulting
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
[jira] [Commented] (MYFACES-3554) REGRESSION: 2.0.12/2.1.6 (and
above) fail on state saving
Posted by "Leonardo Uribe (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/MYFACES-3554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13284714#comment-13284714 ]
Leonardo Uribe commented on MYFACES-3554:
-----------------------------------------
I checked it again and the problem was not in UIStub, instead it was caused because one facelet component was removed from the component tree, but note by facelets algorithm, instead by some other logic in RenderResponse time. The fix is just add that rule to the condition inside PostAddPreRemoveFromViewListener. Manipulation of the components created by facelets algorithm should be avoided, but still the trick is valid.
> 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
[jira] [Commented] (MYFACES-3554) REGRESSION: 2.0.12/2.1.6 (and
above) fail on state saving
Posted by "Kennard Consulting (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/MYFACES-3554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13284722#comment-13284722 ]
Kennard Consulting commented on MYFACES-3554:
---------------------------------------------
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
[jira] [Commented] (MYFACES-3554) REGRESSION: 2.0.12/2.1.6 (and
above) fail on state saving
Posted by "Kennard Consulting (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/MYFACES-3554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13285390#comment-13285390 ]
Kennard Consulting commented on MYFACES-3554:
---------------------------------------------
Your mention of the (MyFaces-specific) PostAddPreRemoveFromViewListener event is very interesting. The Mojarra/MyFaces team had previously settled on the following approach to dynamic component tree manipulation:
http://blog.kennardconsulting.com/2010/10/safely-manipulating-component-tree-with.html
However there has recently been discussion that this may need to be clarified in the spec, possibly with a new event (such as PostAddPreRemoveFromViewListener). Would you care to weigh in on http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1007
> 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
[jira] [Comment Edited] (MYFACES-3554) REGRESSION: 2.0.12/2.1.6
(and above) fail on state saving
Posted by "Kennard Consulting (JIRA)" <de...@myfaces.apache.org>.
[ 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, 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.
> 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
[jira] [Comment Edited] (MYFACES-3554) REGRESSION: 2.0.12/2.1.6
(and above) fail on state saving
Posted by "Kennard Consulting (JIRA)" <de...@myfaces.apache.org>.
[ 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/30/12 5:08 AM:
----------------------------------------------------------------------
Thanks Leonardo for your fast response. It's fantastic you're so readily able to understand the problem and resolve it.
I can confirm your fix now works with myfaces-*-2.0.14-20120529.110535-88 and myfaces-*-2.1.8-20120529.113957-91.jar.
Look forward to the next release!
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, 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.
> 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
[jira] [Comment Edited] (MYFACES-3554) REGRESSION: 2.0.12/2.1.6
(and above) fail on state saving
Posted by "Kennard Consulting (JIRA)" <de...@myfaces.apache.org>.
[ 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
[jira] [Commented] (MYFACES-3554) REGRESSION: 2.0.12/2.1.6 (and
above) fail on state saving
Posted by "Leonardo Uribe (JIRA)" <de...@myfaces.apache.org>.
[ 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
[jira] [Resolved] (MYFACES-3554) REGRESSION: 2.0.12/2.1.6 (and
above) fail on state saving
Posted by "Leonardo Uribe (JIRA)" <de...@myfaces.apache.org>.
[ https://issues.apache.org/jira/browse/MYFACES-3554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leonardo Uribe resolved MYFACES-3554.
-------------------------------------
Resolution: Fixed
Fix Version/s: 2.1.8
2.0.14
Assignee: Leonardo Uribe
Thanks Richard for the example. Unfortunately, the examples you already provided some time ago, converted to junit tests inside myfaces core were not able to catch that tricky scenario.
> 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