Thank you for the clarification. Now I see the reason for storing the registry in a static field.
On Thu, Mar 25, 2010 at 8:56 PM, Howard Lewis Ship <[email protected]> wrote: > 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] > > -- Best regards, Igor Drobiazko http://tapestry5.de/blog
