[
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
