Version ids on jar file names create proper versioning of codebases. So, you can deploy a new service with a well known interface and a different jar file with a different name (version number or some other part of the URL different) and you get versioning of URLs. You’ll get a new URLClassLoader instance for that URL because it is different. The HTTPMD protocol handler includes the MD5 hash on the URL to aid in versioning content too (and yes it is not completely unique). The deployment process you undertake as a service deployer allows you to use a symlink to create a different name for a jar you want to be in the codebase for example. Then, you can upgrade new clients but not old clients while maintaining the same URI string.
Gregg > On Jan 25, 2017, at 6:45 PM, Peter <j...@zeus.net.au> 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 >>> >>> > > >
