Re: FW: Working with the class server

Asaf Lahav wrote:
> Ok, got it… my bad.
> 
> The installverify class path is not designed to look at the lib folder 
> as its own class path.
> 
> Now it works fine.

Putting jar files in everyones classpath, is NOT what Jini was designed to do. 
That creates versioning nightmares.  Everytime you need to update something, 
everyone has to get the new version and install it.  The Java mobile code model, 
first visible in RMI, and carried forward (and greatly enhanced in Jini), allows 
clients to get the "right" version of the software they need, automatically. 
The term "codebase" is used to describe the jar file(s) needed to resolve 
classes which are downloaded (as opposed to those in your classpath, that are on 
the disk locally, always).

Things that will be in the classpath, are things like interface definitions, and 
core classes (such as abstract classes) which do not change, or do so rarely, 
and typically in Serialization Spec compatible ways.  In RMI, you had to set the 
system property, java.rmi.server.codebase on the command line.  You'd typically 
do something like

	java -Djava.rmi.server.codebase=http://mycode.server.domain/my.jar

to tell RMI what to "annotate" mobile, serialized code with so that the receiver 
could find out how to download the code.  The RMIClassLoaderSPI class's javadocs 
provide some information on how this works.

With Jini, this mechanism is plugged into using the PerferredClassLoader.  The 
service starter framework (the classes in com.sun.jini.start) provide a 
"Configuration" based mechanism for detailing the classpath, codebase, security 
policy, command line arguments and service "class" using the ServiceDescriptor 
based classes.

It is in that place, that you usually need to put the specification of your 
codebase for the code that is putting entries into a Javaspace.  As Guy said, if 
you have long lived entries, you need to manage the fact that the codebase URLs 
need to work for all clients at all times that you need them too.  As Dennis 
responded, short lived entries, will expire if the writer stops renewing leases.

The gigaspaces Javaspace implementation has an "in place class server" that is 
part of the space implementation.  When you write something, the annotation is 
used to download the specified jars into the space, and the entries are modified 
to indicate a different way to get the code to resolve the classes inside them.

This is an interesting capability, but it doesn't resolve all entries associated 
with some desired behaviors when an entries' codebase server disappears.

Gregg Wonderly

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]