incubator-river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Kleczek <>
Subject Re: Jini and OSGI revisited
Date Sat, 09 Oct 2010 15:52:59 GMT
On Saturday 09 of October 2010 15:54:49 Sim IJskes - QCG wrote:
> On 10/09/2010 11:09 AM, Michal Kleczek wrote:
> > Folks,
> > 
> > The discussion about trust and solving deserialization DoS issues brought
> > me to the idea of annotating classes with Modules.
> > 
> > On the other hand Peter is working on ClassLoader / class identity
> > issues. I tried to think about it and came up with an idea that a Module
> > can express that it depends on other Modules so that if there is a
> > dependency that is shared between two modules classes loaded from this
> > dependency preserve their ClassLoader:
> > 
> > interface Module {
> > 
> >    Module[] getDependencies();
> >    //... class loading methods
> > 
> > }
> And downloading a jar? A jar has everything already. Dependencies,
> codesigning. Extendable manifest, etc.

There are two things:
1. I really like the Jini way of verifying trust - ask an object for a trusted 
third party that will provide a verifier and verify a not yet trusted object. 
We can always have a built in Module implementation and a verifier that would 
just make sure code is signed.
OTOH I think it would be useful to make it more dynamic.

There is also another benefit of having annotation as an object - we do not 
have to have a URLStreamHandler installed locally to download code (although 
this is not really needed in OSGI container since URLStreamHandlers can be 
installed dynamically).

2. Dependencies - that is something I am not really sure is needed in OSGI - 
the service can provide everything that it needs in its bundle and express its 
public packages (a service interface) as exports.
But it seems useful if we don't want to depend on OSGI container - service 
interface would be provided by a dependency. If the client depends on the same 
dependency Module (the problem of Module identity is something to be solved 
anyway - I would go for Java object identity here) there would be no 
In OSGI they don't do any harm - it is just that a service can provide some of 
its code in it's own bundle and some - as dependencies.


View raw message