No, it's just an example, no such restriction. But it is restricted to JERI.
RemoteEvents have been extended also in JGDMS to use MarshalledInstance and JErI instead of MarshalledObjects and JRMP. All methods that rely on MarshalledObject have been deprecated and replacements provided with the exception of Activation constructors. MarshalledInstance has also been made extensible to allow other serialization formats to be supported by the api. But we're diverging... Cheers, Peter. Sent from my Samsung device. Include original message ---- Original message ---- From: Michał Kłeczek <mic...@kleczek.org> Sent: 08/02/2017 06:07:19 am To: dev@river.apache.org Subject: Re: OSGi - deserialization remote invocation strategy Hmm.. I see. So your solution explicitly only handles cases of looking up a service in the ServiceRegistrar. How about smart RemoteEventListeners? They are not published in any lookup service. Thanks, Michal Peter wrote: > In the JGDMS fork of River, in addition to Reggie's proxy returing >unmarshalled service proxy's from the ServiceRegistrar lookup method, >SafeServiceRegistrar provides a lookup method that returns instances of >java.lang.reflect.Proxy that implement interfaces to retrieve the service, >it's attributes and it's codebase uri and signer certs. > > The client can authenticate, filter and grant permissions (for >deserialization and codebase download) before retrieving the service proxy >using a method call. > > In this case the service proxy is obtained by from the reflection proxy >instead of MarshalledIstance. > > Cheers, > > 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: 08/02/2017 05:51:07 am > To: dev@river.apache.org > Subject: Re: OSGi - deserialization remote invocation strategy > > So I must have misunderstood the part about smart proxies being obtained via >"reflection proxies" or MarshalledInstances. > > What are these "reflection proxies"? > > Thanks, > Michal > > Peter wrote: > No, no bootstrap objects. > > Cheers, > > 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: 08/02/2017 12:28:50 am > To: dev@river.apache.org > Subject: Re: OSGi - deserialization remote invocation strategy > > Are you proposing to provide a bootstrap object that will download some > meta information prior to class resolution? > > How does it differ from simply changing annotations to be those > "bootstrap objects" instead of Strings? > > Thanks, > Michal > > Peter wrote: > Proposed JERI OSGi class loading strategy during deserialization. > > Record caller context - this is the default bundle at the beginning of > the stack. It is obtained by the InvocationHandler on the > client side. The InvocationDispatcher on the server side has the > calling context of the Remote > implementation. The reflection dynamic proxy must be installed in the > client's class loader, so the > InvocationHandler knows exactly what it is, it will be passed to the > MarshalInputStream. Any > interfaces not found in the client's bundle can be safely shed. For a > smart proxy the reflection proxy will > be installed in the smart proxy loader. The smart proxy is obtained > either via a reflection proxy or a MarshalledInstance. > MarshalledInstance also passes in the callers loader to the > MarshalInputStream. > > The smart proxy classloader is not a child loader of the clients > loader, instead it's a bundle that imports > service api packages, with a version range that overlaps those already > imported by the client. > > Both Invocationhandler and InvocationDispatcher utilise > MarshalInputStream and MarshalOutputStream, for marshalling parameters > and return values. > > The codebase annotation bundle's manifest contains a list of package > imports. > > Do we need to make a list of package imports for every new bundle that > we load? > Do we need to record the wiring and packages and their imports from > the remote end? > > I don't think so, the bundles themselves contain this information, I > think we just need to keep the view of available classes relevant to > the current object being deserialized. > > Codebase Annotations are exact versions! They need to be to allow the > service to ensure the correct proxy codebase is used. Other proxy > codebases will be installed in the client, possibly different > versions, but these won't be visible through the resolved > dependencies, because the proxy codebases only import packages at the > client and OSGi restricts visibility to the current bundle's own > classes and any imported packages. > Instead of appending dependencies to the codebase annotation they'll > need be defined in the proxy's bundle manifest. Of course if an > identical version of a proxy codebase bundle is already installed at > the client, this will be used again. > > Because a bundle generally imports packages (importing entire bundles > is discouraged in OSGi), there may be classes > that aren't visible from those bundles, such as transient imports, but > also including private packages that aren't exported, private > implementations need to be deserialized, but is it possible to do so > safely, without causing package > conflicts? Private implementation classes can be used as fields > within an exported public object, but cannot and should not > escape their private scope, doing so risks them being resolved to a > bundle with the version of the remote end, instead of the locally > resolved / wired package, causing ClassClassExceptions. > > Initial (naive) first pass strategy of class resolution (for each > branch in the serialized object graph)?: > 1. Try current bundle on the stack (which will be the callers > bundle if we haven't loaded any new bundles yet). > 2. Then use the package name of a class to determine if the package > is loaded by any of the bundles > referenced by the callers bundle imports (to handle any private > implementation packages > that aren't in the current imports). Is this a good idea? Or should > we go straight to step 3 > and let the framework resolve common classes, what if we use a > different version to the > client's imported bundle? Should we first compare our bundle > annotation to the currently > imported bundles and select one of those if it's a compatible > version? Yes, this could be an > application bundle, otherwise goto 3. > 3. Load bundle from annotation (if already loaded, it will be an > exact version match). Place the > new bundle on top of the bundle stack, remove this bundle from the > stack once all fields of > this object have been deserialized, returning to the previous bundle > context. We are relying > on the current bundle to wire itself up to the same package versions > of the clients bundle > imports, for shared classes. Classes that use different bundles will > not be visible to the client, > but will need to be visible to the current object's bundle. > 4. Place a bundle reference on the stack when a new object is > deserialized from the stream and > remove it once all fields have been deserialized. (we might need to > remember stack depth) > 5. Don't place non bundle references on the stack. For example > system class loader or any > other class loader, we want resolution to occur via the OSGi > resolution process. > > What about a simpler strategy (again naive), where we don't attempt to > resolve private implementation classes? > 1. The calling class' bundle, is given priority. > 2. Load bundle from annotation (exact version), when not found in > calling class. > 3. No stack, what if an application bundle from server is loaded > that conflicts with an existing > bundle resolved by the client? > 4. What about walking back through the stack? Probably > unnecessary, as the containing object > will reference the class by a common interface, the outer object may > not need to reference > it at all. But what if the outer object passed it in during > construction? > > Revised strategy: > 1. Attempt to load from current bundle on stack (the stack begins > with the client's Bundle, each > node in the graph has its bundle added to the stack and is also > removed after that node is completely deserialized. > 2. If unsuccessful, walk back through deserialized bundle reference > stack and attempt to load class. > Why not start at the beginning of the stack? We are expecting bundles > to wire up to > currently loaded versions, but bundles can import different package > versions for > implementation, safest to start with current bundle and consult parent > if not found in the current bundle > dependency graph, ie possibly passed in during object construction or > an handback > implemented in the client, from an earlier invocation or dependency > injected. > 3. The client is responsible for determining compatibility with the > service api it's interested in > from the Import Package Entry's, prior to unmarshalling a service proxy. > 4. If a bundle previously on the stack resolves a class, then this > object's bundle reference is placed > on the top of the stack, it is removed once the current object and all > it's fields have been completely deserialized. > 5. Load bundle from annotation (exact version). > 6. No attempt will be made to directly load from wired bundles, > always rely on wires, > otherwise we may utilise an incompatible package / bundle. > > Do we need a graph of the wiring from the remote end? > During serialization (from the remote end) do we need to determine if > a bundle has dependants and send some sort of version range information? > When a class descriptor is read in from a stream, the class descriptor > contains information > about fields and it's serializable supertype class (if it exists) > are also read in from the stream, before any field objects are read > in, the declared field types > are visible from the bundle of the current object being deserialized. > The objects that will be > assigned to those field types must also resolve to those types. Hence > bundles being resolved as part > of deserialization must favour already resolved packages for imports. > What if a bundle requires a specific package version? 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). > > The BundleReference stack is designed to follow the wires (dependency > links between bundles), > to allow private classes to be resolved, as they're not visible from > other bundles. > > We can't rely on annotations to resolve private classes, because we > can't predict the way bundle > dependency's are resolved in remote JVM's. > > General recommendations for OSGi: > * The service should use as wide a version range as possible for > service api. > * It is better to create new service api in a new bundle than to > evolve in a backward compatible manner, as > an incremental change may not be compatible if additional classes and > methods are missing > from the client, that the service proxy depends on. > * Don't split packages. > * Private implementation classes are ok, provided they remain > within public exported classes and don't escape, otherwise > they may not link up properly upon deserialization. > * The proxy should minimise the package imports it uses. > * There must be only one compatible service api version installed > already in the client. > * Duplicates of incompatible versions of service api are ok. > > The catch is, it may not be possible to build the bundle stack without > some programming hooks in ObjectInputStream. > > Unfortunately we don't have any control over OIS, the necessary hooks > could however be added to AtomicMarshalInputStream. > > Cheers, > > Peter. > > > > > >
