The current code approach is not ideal. It's about handling the deserialization of service proxies, in the context of servlet container clustering.
When serialized, they store a token identifying the service id. When deserialized, they need to find a Registry and replace the token with the service proxy in the new Registry. The servlet container is responsible for the deserialization, which limits our options. At startup a Registry places an instance into the static field, since a static field is all that will be available to a de-serializing service token. Ideally, the servlet containers would post some kind of notification before deseriallizing data from another server in the cluster; we could then do something using a ThreadLocal, rather than a static. Perhaps we need to do some research to see how to get access to that kind of callback information, presuming it exists. On Thu, Mar 25, 2010 at 12:48 PM, Igor Drobiazko <[email protected]> wrote: > Hello, > > before fixing TAP5-1078 [1] I would like to ask if there is any reason why > the registry is stored in a static field of SerializationSupport. As > described in [1] this causes duelling registries inside a JVM. I suggest to > remove SerializationSupport and move the creation of ServiceProxyToken to > InternalRegistry. Any objections? Am I missing something? > > [1] https://issues.apache.org/jira/browse/TAP5-1078 > > -- > Best regards, > > Igor Drobiazko > http://tapestry5.de/blog > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
