You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Blake Sullivan (JIRA)" <de...@myfaces.apache.org> on 2010/02/25 03:20:27 UTC
[jira] Created: (TRINIDAD-1739) ComponentReference doesn't work
with bindings and should be more thread-safe
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.
[jira] Resolved: (TRINIDAD-1739) ComponentReference doesn't work
with bindings and should be more thread-safe
Posted by "Blake Sullivan (JIRA)" <de...@myfaces.apache.org>.
[ 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.