Charles Oliver Nutter schrieb:
Jochen Theodorou wrote:
sorry for commenting here, I know it is not my project and I don't
know the architecture enough, but ;)
Not at all, feel free to comment at will!
ok ;)
I mean given that the object you deserialize has a transient field
giving access to the JRuby runtime, then all that has to be solved is
setting this filed correctly, right? If yes, then who is
deserializing? Isn't a runtime doing this? And wouldn't that mean I
have a runtime I can attach the object to? That would be independent
of classloaders and globals. I am sure I am missing something
important here.
In some cases, yes, there will be a runtime "pulling" objects off the
wire. But generally if you've got a runtime on both sides you'd just use
Ruby's marshaling, which fits a bit better into Ruby-land.
that's no problem then, ok
The problems come up when you're not in control of serialization. One
example is Rails apps running in JRuby but storing their session data in
a Java webapp session. In order to support clustering, sessions would be
serialized to other servers without the runtimes knowing about it.. so
> there would be no way on the other side to reconstitute the objects as
> they're pulled off the wire.
you mean the new object won't be connected to the runtime, because it
was deserialized by Java? I see.. hmm... my next thought is a bit
complicated, but well... Let us assume all Runtimes register themselfs
at a global map using a unique id. Then, when deserializing the object,
the runtime is created using this id and registered at the new computer
or attached to an already existing id. java.util.UUID might help here,
but I don't know if it will work. I never worked with UUID.
bye blackdrag
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
