> On Feb 7, 2017, at 8:56 AM, Michał Kłeczek (XPro Sp. z o. o.) > <michal.klec...@xpro.biz> wrote: > > 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.
The missing notion of versioning in classloader was meant to be solved by URLs in the annotations. That would provide explicit versioning control and through the use of the TCCL, code and objects could be isolated from other versions. However, that’s not perfect, and so the preferred class loading mechanism is also a path that allows a “platform” or “hosting” environment to declare the classes that it will use to interact with a client/proxy. Practically, it’s exactly the NP-hard problem you say though. There are “pretty good” solutions, but realistically there is not a perfect solution until there is an exact dependency graph which allows perfect specification of dependencies. Gregg > > Thanks, > Michal
