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: 2.0.0-alpha, 1.2.13-core Environment: All Reporter: Blake Sullivan Assignee: Blake Sullivan 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.