[ https://jira.jboss.org/jira/browse/EJBTHREE-1002?page=com.atlassian.jira.... ] Brian Stansberry reassigned EJBTHREE-1002: ------------------------------------------ Assignee: Paul Ferraro (was: Brian Stansberry) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/EJBTHREE-1002?page=com.atlassian.jira.... ] Brian Stansberry commented on EJBTHREE-1002: -------------------------------------------- Some notes on this as I've been thinking about it a bit. Assumption is that the basic EJB2 design of storing the cluster topology in JNDI next to the bean ref, using jndiname + fixed_suffix is followed. (That assumption is open to debate if there are better approaches.) JndiClusteredSessionRegistrarBase would override superclass bind() method to bind the cluster topology objects in JNDI. Objects would either be a FamilyWrapper, or a Reference with a bunch of StringRefAddr, one per target, and an ObjectFactory to create the FamilyWrapper on the client side. SessionClusteredProxyObjectFactory.createProxyFactoryProxy would be modified to pass the jndiname to ClusteredPojiProxy via a new property setter. Field for this would be transient to ensure serialization format is unchanged. ClusteredPojiProxy would add this name to the invocation metadata. The actual retry interceptor would be much like the current one, except than once it has created a FamilyWrapper it doesn't need to bind it to the invocation, since FamilyClusterInfo/ClusteringTargetsRepository ensure there is only one set of targets per family. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira