river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Android
Date Mon, 17 May 2010 01:11:22 GMT
Fabrizio Giudici wrote:
> Indeed, I thought that one could add them by means of the Maven shade
> plugin trick, or similar stuff. But you made me realize that we're
> sharing the same code between the peers, and thus we can't have RMI
> stuff renamed. Unless it's possible to write some sort of filter to
> the serialized data where names are again converted on the fly... but
> it sounds definitely cumbersome.
Funny you mention filters, I've got classes that extend 
ObjectInputStream and ObjectOutputStream that do just that.

See net.jini.io.* on SVN for details.

It converts the names of net.jini.io.MarshalledInstance and 
java.rmi.MarshalledObject and serialVersionUID's for Java CDC.

java.rmi.Remote is a marker interface, there might be some way to do 
without it, via some sort of replacement, I'm not confident though.

I've been thinking about a new URL scheme for annotating codebases.  
Currently the sender doesn't know the platform implementation at the 
remote end, so the appropriate codebase to utilise there should be 
determined by a combination of a package name and perhaps version and 
the local platform.  The appropriate codebase could be provided via a 
codebase service rather than an http server.

OSGi also has a need to determine the most appropriate ClassLoader for 
Serialization, at the moment there is no suitable mechanism, we might be 
able to provide it.

If you're willing to help we can give it a try, its not something I 
alone have the resources to deal with.

I'm starting to believe that Services should have a separate 
"ServiceInterface" jar, proxy's servers and clients can all share common 

If Apache River were to have a public codebase service that vetted, 
signed and distributed these ServiceInterface jar's they could be 
utilised by parties unknown to each other to cooperate.  Service 
Interfaces can be placed high up in the ClassLoader hierarchy, so 
they're visible to all proxies and clients, enabling many different and 
varied implementations of each.



View raw message