Honestly - since I am fixed ( :-) ) on having mobile code treated as any
other object - I see it something like:
interface CodeBaseModule {
ClassLoader createLoader() throws AnyImportantException;
}
interface CodeRepository {
CodeBaseModule getCodeBaseModule(String name, Version version);
boolean isSameNamespace(CodeRepository other);
}
class NamedCodeBase {
String name; Version version;
CodeRepository repository;
boolean equals(Object other) { //check name, version and repo }
}
Now the question is about the implementation of "isSameNamespace". Since
the protocol(s) to access code repository might differ (and there might
be multiple available at the same time), location based equality won't
work (although is the easiest to implement). My rough idea is for the
CodeRepository to be able to authenticate as any of a set of Principals
( ie. satisfy the ServerMinPrincipal constraint ). Two CodeRepository
instances are interchangeable if intersection of their principal sets is
non-empty.
At first I thought about having a global naming scheme - then
cryptographic hash would constitute the part of the name. But that would
make names obscure and difficult to remember and write by hand.
So I came up with an idea to abstract it away - according to "all
problems in CS can be solved by introducing another level of indirection" :)
Thanks,
Michal
Peter wrote:
codebase identity
So River codebase identity is currently any number of space delimited RFC 3986
normalised URI strings.
httpmd uses a location filename and message digest.
But should location be part of identity? How can you relocate a codebase once
remote objects are deployed?
OSGi and Maven use a name and version to identify a codebase.
Might we also need codebase signers (if any) to be part of identity?
If no, why not and if yes why?
Regards,
Peter.
Sent from my Samsung device.
Include original message
---- Original message ----
From: "Michał Kłeczek (XPro Sp. z o. o.)"<michal.klec...@xpro.biz>
Sent: 26/01/2017 08:30:58 am
To: d...@riverapache.org
Subject: Re: OSGi
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
