I haven't been aware of ObjectSpace Voyager. I just briefly looked at it
and it seems like it is based on Java 1.x (ancient beast) and - as I
understand it - the issues you describe are mainly caused by having only
a single class name space (single ClassLoader).
But sending IMHO class bytes in-band is not necessary (nor good).
What is needed is:
1. Encoding dependency information in codebases (either in-band or by
providing a downloadable descriptor) so that it is possible to recreate
proper ClassLoader structure (hierarchy or rather graph - see below) on
the client.
2. Provide non-hierarchical class loading to support arbitrary object
graph deserialization (otherwise there is a problem with "diamond
shaped" object graphs).
A separate issue is with the definition of codebase identity. I guess
originally Jini designers wanted to avoid this issue and left it
undefined... but it is unavoidable :)
Thanks,
Michal
Gregg Wonderly wrote:
That’s what I was suggesting. The code works, but only if you put the required
classes into codebases or class paths. It’s not a problem with mobile code,
it’s a problem with resolution of objects in mobile code references. That’s
why I mentioned ObjectSpace Voyager. It automatically sent/sends class
definitions with object graphs to the remote VM.
Gregg
On Jan 23, 2017, at 3:03 PM, Michał Kłeczek (XPro Sp. z o.
o.)<michal.klec...@xpro.biz> wrote:
The problem is that we only support (smart) proxies that reference only objects
of classes from their own code base.
We do not support cases when a (smart) proxy wraps a (smart) proxy of another
service (annotated with different codebase).
This precludes several scenarios such as for example "dynamic exporters" -
exporters that are actually smart proxies.
Thanks,
Michal
