[ 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.