It doesn't sound very intelligent to download an OSGi Container to a client. It surely is something wrong with that... Proxy should depend on the deployed services, locally some more... What am I missing, other than you are trying to convey an absurdity?
On Tue, Jan 31, 2017 at 4:10 PM, "Michał Kłeczek (XPro Sp. z o. o.)" < michal.klec...@xpro.biz> wrote: > My point throughout the whole thread is that to support these scenarios: > > 1. Manipulating class streams (like in Voyager) is not necessary (quite > franky - I think it is a bad idea actually since it assumes a single > namespace for classes what precludes class evolution) > 2. Dictating a particular "class conveyance mechanism" is not necessary > either > > What I am proposing is: > 1. Abstract over a "class conveyance mechanism" (by making codebases > serializable objects which classes implement a specific contract) > 2. Change ClassProvider API to support the above (accept abstract > codebases instead of only Strings) > 3. (Optionally) - provide a default class conveyance mechanism that: > a) allows resolving classes in non-hierarchical way (similar to > ClassWorlds or JBossModules or... OSGI) > b) supports coexisting of other "class conveyance mechanisms" in the same > JVM > > Point 1 and 3b) will make the whole solution really dynamic allowing a > "class conveyance mechanism" to be dynamically downloaded by the client. > So - how do you make sure a service deployed in OSGi container may send > its proxy to a non-OSGI client? Yes! You let the client download the OSGI > container dynamically! > > What's more - once you abstract over how the classes are downloaded - it > is possible to support downloading code through relays etc. > > Thanks, > Michal > > Gregg Wonderly wrote: > >> The annotation for the exported services/classes is what is at issue >> here. Here’s the perspectives I’m trying to make sure everyone sees. >> >> 1) Somehow, exported classes from one JVM need to be resolved in another >> JVM (at a minimum). The source of those classes today, is the codebase >> specified by the service. A directed graph of JVMs exchanging classes >> demands that all service like JVMs provide a codebase for client like JVMs >> to be able to resolve the classes for objects traveling to the client form >> the service. This is nothing we all don’t already know I believe. >> >> 2) If there is a 3rd party user of a class from one JVM which is handed >> objects resolved by a middle man JVM (as Michal is mentioning here), there >> is now a generally required class which all 3 JVMs need to be able to >> resolve. As we know, Jini’s current implementation and basic design is >> that a services codebase has to provide a way for clients to resolve the >> classes it exports in its service implementation. In the case Michal is >> mentioning, the demand would be for the middle man service to have the >> classes that it wants the 3rd service to resolve, in some part of its >> codebase. This is why I mentioned Objectspace Voyage earlier. I wanted to >> use it as an example of a mechanism which always packages class definitions >> into the byte stream that is used for sending objects between VMs. Voyager >> would extract the class definitions from the jars, wrap them into the >> stream, and the remote JVM would be able to then resolve the classes by >> constructing instances of the class using the byte[] data for the class >> definition. >> >> Ultimately, no matter what the source of the byte[] data for the class >> definition is, it has to be present, at some point in all VMs using that >> definition/version of the class. That’s what I am trying to say. The >> issue is simply where would the class resolve from? I think that class >> definition conveyance, between JVMs is something that we have choices on. >> But, practically, you can’t change “annotations” to make this work. If the >> middle man above is a “proxy” service which bridges two different networks, >> neither JVM on each network would have routing to get to the one on the >> other side of the proxy JVM. This is why a mechanism like Objectspace >> Voyager would be one way to send class definitions defined on one network >> to another JVM on another network via this proxy service. >> >> Of course other mechanisms for class conveyance are possible and in fact >> already exist. Maven and even OSGi provide class, version oriented >> conveyance from a distribution point, into a particular JVM instance. Once >> the class definition exists inside of one of those JVMs then we have all >> the other details about TCCL and creation of proper versions and resolution >> from proper class loaders. >> >> I don’t think we have to dictate that a particular class conveyance >> mechanism is the only one. But, to solve the problem of how to allow >> classes hop between multiple JVMs, we have to specify how that might work >> at the level that service instances are resolved and some kind of class >> loading context is attached to that service. >> >> The reason I am talking specifically about directed graphs of class >> loading is because I am first focused on the fact that there is a lot less >> flexibility in trying to resolve through a large collection of specific >> classes rather than an open set of classes resolved through a directed >> graph of the code execution path which exposes the places and moments of >> object use in a much more controlled and natural way to me. >> >> Gregg >> >> >> -- Niclas Hedhman, Software Developer http://polygene.apache.org <http://zest.apache.org> - New Energy for Java
