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] [Commented] (MYFACES-3554) REGRESSION: 2.0.12/2.1.6 (and above) fail on state saving
Date Tue, 29 May 2012 10:58:23 GMT

    [ 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

        

Mime
View raw message