Re: OSGi

So here's how we can put it together: Our OIS contains a stack we can use to track ClassLoader's at each branch in our serialized object graph. 1. First object being read in by the OIS, check the cache see if the URI annotation is implied. 2. If yes, use this Bundle to deserialize,

Re: OSGi

Having implemented an ObjectInputStream (OIS), I can share the following insights: * The object at the head of the graph is externally visible and encapsulates all other objects and primitives. * The objects and primitives at the tails of the graph are fields. * Circular

Re: OSGi

The URI within a Bundle is its unique identity.  Only one Bundle instance is loaded for each unique URI identity. I think we need a bundle listener that creates a bundle map, referenced by a weak Map. Then I think we need a URI.implies(URI uri) which offers a version range

Re: OSGi

The commentary in the first document indicates that there is no rhyme or reason to the use of the context class loader. For me, the reason was very obvious. Anytime that you are going to create a new class loader, you should set the parent class loader to the context class loader so that the

Re: OSGi

The ultimate issue is visibility of classes. From most perspectives, there is an execution graph that implies moments when new classes are touched/needed. Where OSGi introduces bundles, it erases the ability to depend on that graph to “expose” the correct version of classes to the correct

Re: OSGi

Thanks Gregg, Thoughts inline below. Cheers, Peter. On 27/01/2017 12:35 AM, Gregg Wonderly wrote: Is there any thought here about how a single client might use both an OSGi deployed service and a conventionally deployed service? Not yet, I'm currently considering how to support OSGi by