Since the lack of Java serialization of JRuby objects stops us dead
in our tracks when trying to hook up our persistence engine, I am
interested in either getting someone on this end to work on it or
jumping in myself. In either case, I need some background on the
JRuby runtime architecture
Alan McKean wrote:
Since the lack of Java serialization of JRuby objects stops us dead in
our tracks when trying to hook up our persistence engine, I am
interested in either getting someone on this end to work on it or
jumping in myself. In either case, I need some background on the JRuby
runt
Charles Oliver Nutter wrote:
Thoughts? More ideas?
More ideas!
A different approach, less brute-force, but requires control over the
deserialization process (perhaps that's not too much to ask?)...
RubyObject.java:
public void readExternal(ObjectInput in) throws IOException,
Thanks for taking the time to think this through. Let me make sure I
understand. What you are proposing would decouple the runtime from
the objects but still make it accessible via the ClassLoader. That
seems to be a major part of the problem, but doesn't it still leave
the metaclass hierar
Thanks for taking the time to think this through. Let me make sure I
understand. What you are proposing would decouple the runtime from
the objects but still make it accessible via the ClassLoader. That
seems to be solve a major part of the problem, but doesn't it still
leave the metaclass
Alan McKean wrote:
Thanks for taking the time to think this through. Let me make sure I
understand. What you are proposing would decouple the runtime from the
objects but still make it accessible via the ClassLoader. That seems to
be solve a major part of the problem, but doesn't it still leave
Charles Oliver Nutter schrieb:
Alan McKean wrote:
Thanks for taking the time to think this through. Let me make sure I
understand. What you are proposing would decouple the runtime from the
objects but still make it accessible via the ClassLoader. That seems
to be solve a major part of the pro
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!
I mean given that the object you deserialize has a transient field
giving access to the JRuby runtime, then all that has to
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
Jochen Theodorou wrote:
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
After talking with Charlie about an approach, we decided that this is
what we would try first. It would require an additional 4-byte field
in every object. Not the optimal approach, but good enough for a
proof-of-concept.
1) Mark 'metaclass' and 'finalizer' transient. This should allow us
Alan McKean wrote:
After talking with Charlie about an approach, we decided that this is
what we would try first. It would require an additional 4-byte field in
every object. Not the optimal approach, but good enough for a
proof-of-concept.
1) Mark 'metaclass' and 'finalizer' transient. This
12 matches
Mail list logo