Thanks Nic, If annot
You've identified the reason we need an OSGi specific RMIClassLoaderSpi implementation; so we can capture and provide Bundle specific annotation information. Rmiclassloaderspi's loadClass method expects a ClassLoader to be passed in, the context ClassLoader is used by PreferredClassProvider when the ClassLoader argument is null. Standard Java serialization's OIS walks the call stack and selects the first non system classloader (it's looking for the application class loader), it deserializes into the application ClassLoader's context. This doesn't work in OSGi because the application classes are loaded by a multitude of ClassLoaders. It also looks like we'll need an OSGi specific InvocationLayerFactory to capture ClassLoader information to pass to our MarshalInputStream then to our RMIClassLoaderSpi during deserialization at both endpoints. We also need to know the bundle (ClassLoader) of the class that calls a java.lang.reflect.Proxy on the client side, this is actually quite easy to find, walk the stack, find the Proxy class and obtain the BundleReference / ClassLoader of the caller. Currently the java.lang.reflectProxy dynamically generated subclass instance proxy's ClassLoader is used, this is acceptable when the proxy bytecode is loaded by the the Client's ClassLoader or smart proxy ClassLoader in the case where a smart proxy is utilised. If the caller changes, so does the calling context. Each bundle provides access to all classes within that bundle, including any public classes from imported packages. Sent from my Samsung device. Include original message ---- Original message ---- From: Niclas Hedhman <nic...@hedhman.org> Sent: 04/02/2017 12:43:28 pm To: dev@river.apache.org Subject: Re: OSGi <snip> Further, I think the only "sane" approach in a OSGi environment is to create a new bundle for the Remote environment, all codebases not part of the API goes into that bundle and that the API is required to be present in the OSGi environment a priori. I.e. treat the Remote objects in OSGi as it is treated in plain Java; one classloader, one chunk, sort out its own serialization woes. Likewise for the server; treat it as ordinary RMI, without any mumbo-jambo OSGi stuff to be figured out at a non-OSGi-running JVM. An important difference is that in OSGi, the BundleClassLoader is not (required to be) a URLClassLoader, so the Java serialization's auto annotation of globally reachable URLs won't work, and one need to rely on java.rmi.server.codebase property, but a bundle could watch for loaded bundles and build that up for URLs that can be resolved globally. Cheers -- Niclas Hedhman, Software Developer http://polygeneapache.org <http://zest.apache.org> - New Energy for Java
