myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kennard Consulting (JIRA)" <...@myfaces.apache.org>
Subject [jira] [Comment Edited] (MYFACES-3554) REGRESSION: 2.0.12/2.1.6 (and above) fail on state saving
Date Wed, 30 May 2012 05:08:24 GMT

    [ 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

        

Mime
View raw message