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.
