Description
A problem related to @ResourceDependency has been mentioned on:
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.
Attachments
Issue Links
- relates to
-
MYFACES-3663 UIViewRoot.createUniqueId() should generate unique ids for all the component tree.
-
- Closed
-