[prev in list] [next in list] [prev in thread] [next in thread] 

List:       myfaces-dev
Subject:    [jira] [Comment Edited] (MYFACES-3554) REGRESSION: 2.0.12/2.1.6 (and above) fail on state saving
From:       "Kennard Consulting (JIRA)" <dev () myfaces ! apache ! org>
Date:       2012-05-30 5:08:24
Message-ID: 1957893557.14668.1338354504558.JavaMail.jiratomcat () issues-vm
[Download RAW message or body]


    [ https://issues.apache.org/jira/browse/MYFACES-3554?page=com.atlassian.jira.plugi \
n.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

        


[prev in list] [next in list] [prev in thread] [next in thread]