Hi Gregg,
Sorry I missed this earlier, have a look at my latest messages, they
might provide some more background to my thoughts.
Mike Warres has a good example of when the existing mechanism causes
codebase annotation loss and type conflicts on page 23 of his paper
"Class Loading Issues in Java RMI and Jini Network Technology".
https://issues.apache.org/jira/secure/attachment/12413650/Java+Classloader+issues+relating+to+Jini+smli_tr-2006-149.pdf
Because the Service API is loaded from the local file system and isn't
dynamically downloaded, it may not have an annotation, I'm thinking
about creating a new URL scheme, that provides information about all Jar
files, whether local or downloaded dynamically, such as jar name and
version annotation. This should help people who wish to provision their
codebases.
Note I haven't had any thoughts about removing PreferredClassProvider,
but I'm thinking about another ClassLoader structure, although I'm prone
to changing my mind as I struggle to understand it all. I haven't got
any implementations, yet, still working it all out.
Gregg Wonderly wrote:
I have a Jini based application that is a content based router system
for satellite networks. There are multiple servers running with comms
cards, and the ServiceUI needs to see all of them at once, because I
use transactions to commit data changes to all servers. In this case,
one clients ServiceUI must lookup all of the services, ignoring
itself, and then get the service proxies to work with. All of the
services proxies need to share interfaces and data classes that are
commonly exchanged.
I didn't need a different kind of classloader tree, I just needed to
make sure that the parent class loader of the RMIClassLoaderSPI was
the ClassLoader of the client (The context ClassLoader which is a
PreferredClassLoader), which was already happening. All the other
service instance unmarshalling would in fact make use of the
PreferredClassLoader, so that versioning could be done by preferring
classes, for example, and each services preferred classes would be
honored.
There is only one -dl.jar involved in the commonality aspects of the
involved Classes. I could break the common classes into a separate
jar, but I have not done that, yet.
This type of application must be restarted fairly rarely, so class
compatibility is a very key issue.
Peter, can you provide a more specific example of when you think the
structure you are proposing would be valuable, i.e. the existing
mechanism would break?
Gregg Wonderly
