river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michał Kłeczek (XPro Sp. z o. o.)" <michal.klec...@xpro.biz>
Subject Re: OSGi
Date Mon, 06 Feb 2017 05:34:54 GMT
Once you realize you need some codebase metadata different than mere 
list of URLs
the next conclusion is that annotations should be something different 
than... a String :)

The next thing to ask is: "what about mixed OSGI and non-OSGI environments"
Then you start to realize you need to abstract over the class loading 
environment itself.

Then you start to realize that to support all the scenarios you need to 
provide a class loading environment that is "pluggable"
- ie allows using it with other class loading environments and allow the 
user to decide which classes should be loaded
by which environment.

This is what I am working on right now :)

Thanks,
Michal

Peter wrote:
> My phone sent the previous email before I completed editing.
>
> ...If api classes are already loaded locally by client code, then a smart proxy codebase
bundle will resolve imports to those packages (if they're within the imported version range),
when the proxy bundle is downloaded, resolved and loaded.
>
> The strategy should be, deserialize using the callers context until a class is not found,
then switch to the object containing the current field being deserialized (which may be a
package private implementation class in the service api bundle) and if that fails use the
codebase annotation (the smart proxy).  This is similar in some ways to never preferred, where
locally visible classes will be selected first.
>
> The strategy is to let OSGi do all the dependency wiring from bundle manifests.  Classes
not visible will be visible from a common package import class, except for poorly designed
services, which is outside of scope.
>
> Only match api version compatible services.
>
> No allowances made for split packages or other complexities.
>
> If deserialization doesn't succeed, look up another service.
>
> Cheers,
>
> Peter.
>
> Sent from my Samsung device.
>   
>    Include original message
> ---- Original message ----
> From: Peter<jini@zeus.net.au>
> Sent: 06/02/2017 02:59:09 pm
> To: dev@river.apache.org<dev@river.apache.org>
> Subject: Re: OSGi
>
>   
> 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<niclas@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
>
>
>
>


Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message