myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leonardo Uribe (JIRA)" <...@myfaces.apache.org>
Subject [jira] [Resolved] (MYFACES-3660) Component resource added using @ResourceDependency annotation from a facelet component should have an id defined by facelets
Date Wed, 27 Mar 2013 23:07:15 GMT

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

Leonardo Uribe resolved MYFACES-3660.
-------------------------------------

       Resolution: Fixed
    Fix Version/s: 2.1.11
                   2.0.17

I checked this one and with the fixes done in MYFACES-3663, MYFACES-3665 and MYFACES-3668
we can close this one as fixed
                
> Component resource added using @ResourceDependency annotation from a facelet component
should have an id defined by facelets
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: MYFACES-3660
>                 URL: https://issues.apache.org/jira/browse/MYFACES-3660
>             Project: MyFaces Core
>          Issue Type: Bug
>          Components: JSR-314
>            Reporter: Leonardo Uribe
>            Assignee: Leonardo Uribe
>             Fix For: 2.0.17, 2.1.11
>
>
> A problem related to @ResourceDependency has been mentioned on:
> http://stackoverflow.com/questions/13526624/duplicate-id-error-with-partial-state-saving-and-myfaces-codi
> CODI add a component called WindowContextIdHolderComponent in ResponseWriter.startDocument(),
and later a UIViewRoot.createUniqueId() call is done when getClientId() is called from the
code that checks for duplicate ids. 
> The problem is the code that process @ResourceDependency annotations in ApplicationImpl
object let UIViewRoot.addComponentResource() internals to call createUniqueId(). In the example
proposed, there is a dynamic block that changes the resources added at an specific moment
of time, and since by PSS saving algorithm, restore view phase calls buildView() before restore
the initial state, the count of uniqueIdCounter in UIViewRoot is never restored, and there
is a chance that the same id of the one assigned to WindowContextIdHolderComponent can be
set to a component resource added by @ResourceDependency effect.
> The problem of how generate ids is well known and has been studied for a long time. A
general solution for facelets was committed in MYFACES-3329, and has worked well so far.
> In few words, we need to generate predictable component ids to make PSS algorithm reliable,
otherwise it will be problems related to state saving that are very difficult to track down
and solve. In the other hand, PSS algorithm impose some restrictions over the view that conflicts
with dynamic manipulations of the component tree.
> I think the solution for this one is ensure all components created inside facelets vdl.buildView
has unique ids, doing some changes over UIViewRoot.createUniqueId and changing @ResourceDependency
processing in ApplicationImpl, so if facelets is processing the current view use FaceletCompositionContext.generateUniqueComponentId()
to set an Id. Since @ResourceDependency depends on the component tree structure, the ids will
now contains the information related to the tree structure itself (in the generated id), preventing
duplicates.
> In theory, if we can ensure that all components generated by facelets has a component
id defined by facelets algorithm, createUniqueId will be let to components added programatically,
so we can do some hack to restore the uniqueIdCounter for UIViewRoot on restore view phase
before call vdl.buildView, and simulate the same behavior we had in JSF 1.2, without the side
effects over the state and performance.
> I think solutions using a HashMap using duplicates or random generators are out of discussion,
because they will not ensure the predictability we need to get correct operation of PSS algorithm.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message