Unfortunatelly this is not that easy - the assumption that "the same
bundle is going to be resolved in the same way in another OSGI
container" is false.
Not only the containers must share common provisioning infrastructure
(single view of the names) but - most importantly - the particular
wiring of a bundle is TIME dependent. It can depend on what other
bundles were loaded earlier and how the container resolved them. The
container is free to choose any wiring that meets the requirements.
Thanks,
Michal
Peter wrote:
So lets say for argument sake, that we've got River "bundles" that are annotated with package imports (dependencies) and exports.
Using Bharath's proposed 3 bundle nomenclature for services...
Lets say that a third party services defines a service api in a bundle.
Service api must only change in a backward compatible manner.
A client imports the service api packages.
A service proxy imports the service api packages.
The service api classes are already loaded in the client jvm because the client
imported them.
The service proxy is deserialised in the client jvm. Before the proxy can be
deserialized the RMIClassLoader must first determine whether the proxy's bundle
(exact version) exists, if not it needs to request OSGi to provision& load
that bundle.
When the proxy bundle is loaded, it imports the same service api packages
visible to the client.
But how do we ensure we have a compatible service api in the client jvm?
Because the lookup service finds matching interfaces. When those service api
interfaces were marshalled as arguments to the lookup service by the client,
they were matched on serial form, so the client will only ever receive
compatible results.
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: dev@river.apache.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
