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: Service API, class visibility, isolation and garbage collection - ClassLoaders
Date Sun, 30 May 2010 06:02:39 GMT
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".


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 

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

View raw message