myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Blake Sullivan (JIRA)" <...@myfaces.apache.org>
Subject [jira] Created: (TRINIDAD-1739) ComponentReference doesn't work with bindings and should be more thread-safe
Date Thu, 25 Feb 2010 02:20:27 GMT
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.


Mime
View raw message