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
interfaces.
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.
Cheers,
Peter.
