Getting back around to some of these, hopefully no confusion...
Peter Firmstone wrote:
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.
For me, the important thing to understand about class resolution/loading, is
that there are two distinct issues. First, do you have the correct version of
the class somewhere in the class loading system in use, and Second, if the right
version or no version is available, do you have a way to go look for a
definition that would be the right version to use?
ClassLoaders have historically been the domain of issue #1. Issue #2 has been
dealt with in a surprisingly large number of ways. Serialization annotations
that MarshalledObject et.al. provide one way to deal with #2. But we also have
later development of things like OSGi, Maven and other packaging systems which
include ways to declare or facilitate resolution of missing dependencies.
RMIClassLoaderSPI is the pluggable way to deal with the String annotations on
classes. It can facilitate a wide number of possibilities. The predominate
issues is that it doesn't include an "implementation" indication in concert with
the String value, so you don't know how to "delegate" to other mechanisms to
make use of that String value in a "varied" way.
It seems to me that if we do something with a new RMIClassLoaderSPI
implementation. My changes add no real value other than facilitating the
addition of another implementation that is offered remotely or through some
other path. What we really need is the ability to look at the annotation and
use it intelligently to ask a factory mechanism to use it to create a class loader.
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.
PreferredClassLoading allows you to fix code that is generally used across an
application "suite", by overriding the use of something in the classpath with
something you provide in your -dl.jar (or other codebase content) by making it
preferred. I find this mechanism extremely useful in my service UI client that
has the same classes as all my UIs use for Swing and AWT stuff. If I need
additional functionality or to fix something that only the UI of a service
needs, then I can make that class preferred and not have to update all of my
service UI client instances. Mobile code solutions are very convenient.
Gregg Wonderly
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
