OSGI has already recommended about versioning the package (semantic
versioning).
https://www.osgi.org/wp-content/uploads/SemanticVersioning.pdf
OSGI follows a specific version format (major.minor.micro.qualifier).
As the paper suggested, consumer will not be impacted if there are no
changes in major version.
For example, adding a method to a java interface will not impact consumers.
But it affects producers.
In this case, we will increment minor version.
If we remove a method from interface, it affects both consumers and
providers.
In this case, we need to increment the major version.
For the POC, I added a class "net.jini.lookup.entry.ClassVersion" ( Entry
object), which is available in org,apache,river bundle.
I have followed the below steps before registering the service and lookup a
service.
*service provider side*
Before registering the river service, package version of the exported
classes are calculated.
ClasVersion entries with major,minor,micro,qualifier are created for each
of the exported class.
These entries are added to ServiceItem's attributeSets.
Please refer the following classes in bootstrap bundle..
org.apache.river.bootstrap.service.internal.RiverServiceAdvertiser
*Service consumer side*
Before we lookup services based on ServiceTemplate object , we calculate
the package version of service interface classes (serviceTypes). We create
ClassVersion entry object with calculated major version.
Reggie can return correct compatible proxies to the client based on these
entry objects.
Please refer the below class in bootstrap bundle.
org.apache.river.bootstrap.client.internal.ServiceTemplateManager
Thanks & Regards,
Bharath
On Thu, Jan 26, 2017 at 7:34 AM, Gregg Wonderly <ge...@cox.net> wrote:
> This would be a DHCP like lease scheme.
>
> Gregg
>
> > On Jan 25, 2017, at 7:30 PM, Michał Kłeczek (XPro Sp. z o. o.) <
> michal.klec...@xpro.biz> wrote:
> >
> > I also think about adding leasing to the scheme.
> > If CodeBaseModule can be leased (and the client is capable of handling
> declines of lease renewals) - it would be quite straightforward to
> implement auto-upgrade: the lease for a module "mymodule" ver 1.1 expires
> and you have to ask the code server for a new CodeBaseModule - which in
> turn could return a newer patched version of it.
> >
> > Cheers,
> > Michal
> >
> > Michał Kłeczek (XPro Sp. z o. o.) wrote:
> >> So for a client and a service to be able to communicate they must agree
> on a common set of interchangeable CodeRepositories that would allow them
> to have a common understanding of names.
> >> In other words - to be able to work - any party first has to contact a
> CodeRepository that can authenticate itself as a particular principal. The
> issue is that to find the CodeRepository one needs to communicate with
> ServiceRegistrar. And to communicate with ServiceRegistrar you need a
> CodeRepository!!!. So there needs to be some bootstrapping in place:
> >> - either ServiceRegistrar and CodeRepository constitute as single entity
> >> - there is a bootstrap well known CodeRepository (Maven central?) - its
> implementation is based on a well known URL and its implementation code is
> shipped with the framework.
> >>
> >> Thanks,
> >> Michal
> >>
> >> Michał Kłeczek (XPro Sp. z o. o.) wrote:
> >>> 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>
> <mailto:michal.klec...@xpro.biz>
> >>>> Sent: 26/01/2017 08:30:58 am
> >>>> To: d...@riverapache.org <mailto: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> <mailto: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
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >
>
>
