You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Max Starets (JIRA)" <de...@myfaces.apache.org> on 2010/03/17 16:22:27 UTC

[jira] Resolved: (TRINIDAD-1760) Map returned from UIXComponentBase.getAttributes() is missing attributes set in restoreState()

     [ https://issues.apache.org/jira/browse/TRINIDAD-1760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Max Starets resolved TRINIDAD-1760.
-----------------------------------

       Resolution: Fixed
    Fix Version/s: 2.0.0.3-core

Fixed by Blake Sullivan in revision 924123

> Map returned from UIXComponentBase.getAttributes() is missing attributes set in restoreState()
> ----------------------------------------------------------------------------------------------
>
>                 Key: TRINIDAD-1760
>                 URL: https://issues.apache.org/jira/browse/TRINIDAD-1760
>             Project: MyFaces Trinidad
>          Issue Type: Bug
>          Components: Components
>    Affects Versions: 2.0.0.3-core
>            Reporter: Max Starets
>             Fix For: 2.0.0.3-core
>
>
> org.apache.myfaces.trinidad.bean.util.ValueMap is caching the set of Map entries (_entries member variable), and is assuming that the entries may be added/removed only by calling put()/remove(). However, UIXComponentBase.restoreState() adds new entries directly on the FacesBean, so the ValueMap does not know about these new entries. Basically, the current implementation of the ValueMap will cache the entry set too soon if UIXComponentBase.getAttributes() is called before the restored state is applied. This is precisely what is happening now after we started calling pushComponentToEL in processRestoreState():
> (ValueMap.java:127)  org.apache.myfaces.trinidad.bean.util.ValueMap$MakeEntries.<init>
> 	(ValueMap.java:101)  org.apache.myfaces.trinidad.bean.util.ValueMap.entrySet
> 	(AbstractMap.java:123)  java.util.AbstractMap.containsKey
> 	(UIComponent.java:1761)  javax.faces.component.UIComponent.isCompositeComponent
> 	(UIComponent.java:1684)  javax.faces.component.UIComponent.pushComponentToEL
> 	(UIXComponentBase.java:1073)  org.apache.myfaces.trinidad.component.UIXComponentBase.processRestoreState
> 	(TreeState.java:96)  org.apache.myfaces.trinidad.component.TreeState.restoreState
> 	(UIXComponentBase.java:1080)  org.apache.myfaces.trinidad.component.UIXComponentBase.processRestoreState
> 	(AdfViewRoot.java:79)  oracle.adfinternal.view.faces.component.AdfViewRoot.processRestoreState
> The stack shows where the entry set is being cached in the ValueMap. The attributes from the restored state are set on the FacesBean later,a nd are not reflected in the cached attribute map entry set.
> Possible fix: should we route UIXComponentBase.restoreState() through the ValueMap (instead of calling FacesBean directly), so that the ValueMap has a chance to clear its entry cache?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.