river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter <j...@zeus.net.au>
Subject Re: OSGi
Date Mon, 06 Feb 2017 12:01:10 GMT
Yes I agree, ProxyTrust should be deprecated, it only provides a false 
sense of security. :)

Better to authenticate prior to performing any code downloads and if 
reading in data, best to be very careful to validate it and limit 
potential for DOS by placing limits on the data being read in, not just 
blindly hoping for the best.

Cheers,

Peter.

On 6/02/2017 7:15 PM, "Michał Kłeczek (XPro Sp. z o. o.)" wrote:
> The upside is that it simplifies the overall architecture.
> For example it makes the whole part of River related to proxy trust 
> verification obsolete.
> All these ProxyTrustIterators executed in an untrusted security 
> context, Verifier implementations loaded using a proper ClassLoader 
> etc. - this is not needed anymore.
>
> Thanks,
> Michal
>
> Michał Kłeczek (XPro Sp. z o. o.) wrote:
>> Well - times changed since original Jini has been developed.
>> There is a whole lot of amazing libraries out there - so the 
>> undertaking is much easier than doing it without them.
>> I am specifically talking about Google Guava, JBoss Modules and RxJava.
>>
>> As River is concerned - once you get past the assumption that 
>> codebase annotations are Strings - it has all the necessary extension 
>> points available.
>>
>> I've already started writing the test suite for the thing and hope to 
>> present it soon.
>>
>> Thanks,
>> Michal
>>
>> Peter wrote:
>>> For the sake of simplicity it's probably best if OSGi and non interact only using
reflection proxy's and have their own djinn groups so code downloading is unnecessary between
them. 
>>>
>>> At least that's how I'd consider introducing it into an existing djinn.
>>>
>>> A jvm that doesn't have version management of some sort may have a lot of difficulty
interacting with services from a framework that can use incompatible library versions (and
that includes service api) side by side.
>>>
>>> My concern is interacting with non versioned env's will probably cause the developer
to have to continue dealing with the problems the modular framework they selected intended
solving
>>>
>>> Maven and OSGi can probably interact using mvn: codebase annotations, provided
all modules have bundle manifests.
>>>
>>> I still support what your doing and find it interesting and don't wish to discourage
you, I think you're likely to admit it will be a difficult undertaking, but that's probably
an attraction right?  Maybe River could provide some interfaces for extensibility where you
could plug in?
>>>
>>> Regards,
>>>
>>> Peter.
>>>
>>> Sent from my Samsung device.
>>>   
>>>    Include original message
>>> ---- Original message ----
>>> From: "Michał Kłeczek (XPro Sp. z o. o.)"<michal.kleczek@xpro.biz>
>>> Sent: 06/02/2017 03:34:54 pm
>>> To:dev@river.apache.org
>>> Subject: Re: OSGi
>>>
>>> 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
View raw message