[
https://issues.apache.org/jira/browse/TRINIDAD-1739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Sullivan resolved TRINIDAD-1739.
--------------------------------------
Resolution: Fixed
Fix Version/s: 1.2.12-core
1.2.13-core
Fixed in 1.2.12.2 revision 919496
Fixed in trunk revision 919499
> ComponentReference doesn't work with bindings and should be more thread-safe
> ----------------------------------------------------------------------------
>
> Key: TRINIDAD-1739
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1739
> Project: MyFaces Trinidad
> Issue Type: Improvement
> Components: Archetype
> Affects Versions: 1.2.13-core , 2.0.0-alpha
> Environment: All
> Reporter: Blake Sullivan
> Assignee: Blake Sullivan
> Fix For: 1.2.13-core , 1.2.12-core
>
> Attachments: JIRA-_1739_1_2_12_2.patch
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> ComponentReference has three problems:
> 1) Because it requires that the Component be in the component tree at the
> time that the ComponentReference is created, it doesn't work with component
> bindings, which at called before the component is added to the component tree
> 2) The current thread-safety guarantees (none) are insufficient for a utility
> class that is designed to be used from beans in scopes longer than request.
> These beans always have the possibility of being called from multiple threads.
> 3) Doesn't implement hashCode() and equals()
> The solution to 1) is to internally use two different implementations--one
> for the case where the component meets the current requirements, the second
> to handle the case where the component has no id or isn't in the component
> tree yet. In this case, we defer calculating the scoped id until all call
> that requires a scoped id--getComponent(), hashCode() and equals(). At this
> point, presumably the component is in the tree and if it isn't we throw an
> IllegalStateException (instead of the previous IllegalArgumentException).
> There are two more parts to this problem--there is no guarantee that the
> deferred ComponentReference will actually be called at all, but the deferred
> instance is holding onto a Component and we don't want to do so across
> requests, so we maintain a list of all of the deferred ComponentRefererences
> and call a new method--ensureInstantiation() on all of them at the end of the
> request from the GlobalConfiguratorImpl. The other trick is that we only
> want to deserialize stable component references, so we now use a
> serialization proxy instead of default serialization.
> The thread-safety solution is to make judicious use of thread-safe references
> to mutable data internally and guarantee that getComponent() can be called on
> an instantiated ComponentReference as long as the call is made from a Thread
> with a FacesContext.
> hashCode() and equals() are based on the scoped id of the
> ComponentReferences. Two ComponentReferences with the same scoped id are
> equivalent.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
