Comments inline
Niclas Hedhman wrote:
4. For Server(osgi)+Client(osgi), number of options goes up. In this space,
Paremus has a lot of experience, and perhaps willing to share a bit,
without compromising the secret sauce? Either way, Michal's talk about
"wiring" becomes important and that wiring should possibly be
re-established on the client side. The insistence on "must be exactly the
same version" is to me a reflection of "we haven't cared about version
management before", and I think it may not be in the best interest to load
many nearly identical bundles just because they are a little off, say stuff
like guava, commons-xyz, slf4j and many more common dependencies.
This problem is generally unsolvable because there are contradicting
requirements here:
1. The need to transfer object graphs of (unknown) classes
2. The need to optimize the number of class versions (and the number of
ClassLoaders) in the JVM
It might be tempting to do the resolution on the client but it is
(AFAIR) NP-hard
- the object graph is a set of constraints on possible module (bundle)
versions. Plus there is a whole
set of constraints originating from the modules installed in the
container prior to graph deserialization.
So the only good solution for a library is to provide a client with an
interface to implement:
Module resolve(Module candidate) (or Module[] resolve(Module[] candidates))
and let it decide what to do.
Peter wrote;
This is why the bundle must be given first
attempt to resolve an objects class and rely on the bundle dependency
resolution process.
OSGi must be allowed to wire up dependencies, we must avoid attempting to
make decisions about
compatibility and use the current bundle wires instead (our stack).
Well, not totally sure about that. The 'root object classloader' doesn't
have visibility to serialized objects, and will fail if left to do it all
by itself. And as soon as you delegate to another BundleClassLoader, you
have made the resolution decision, not the framework. Michal's proposal to
transfer the BundleWiring (available in runtime) from the server to the
client, makes it somewhat possible to do the delegation. And to make
matters worse, it is quite common that packages are exported from more than
one bundle, so the question is what is included in the bundleWiring coming
across the wire.
The whole issue with proposals based on the stream itself is the fact
that to resolve properly
one have to walk the whole graph first to gather all modules and their
dependencies.
It is much better to simply provide the module graph (wiring) first (at
the beginning of the stream)
and only after resolution of all the modules - deserialize the objects.
Thanks,
Michal
