river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: Deciding the Future
Date Tue, 09 Dec 2008 14:15:19 GMT

I just want to add a comment on the dl-jar files, for people on the list
who might be new to Jini.  See comments below:

On Tue, 2008-12-09 at 00:07, Niclas Hedhman wrote:

> 3. I like modularization. Jini is quite good, and hat of to the Sun
> team who manage to keep the architectural structure as nice as it is
> even though it sits in s single codebase tree. I have started to break
> things out into separate modules. Still more to do.
> 4. I have not tackled the -dl.jar issue yet. IMHO, I would have them
> as separate Maven modules, as then the dependency for clients become
> crystal clear.

We need to be very clear here; the clients don't have a dependency on
the dl-jar.  The download jar file is the file that a service makes
available so that proxies and supporting classes can be dynamically
loaded when a service is accessed.  It is service's codebase, in other
words.  Remember that mobile code is a key part of Jini; that's how we
get the protocol-agnosticism.  The client should only know about the
interfaces to a service, and possibly data transfer objects (but only
when the DTO's are stable enough that they can be widely distributed to
clients for development-time use).  Under no circumstances should a
client have a copy of the dl-jar in its classpath.  I usually create a
third jar for the client (e.g. some-service-api.jar or
some-esrvice-client.jar) that contains only the interfaces and data
transfer objects.  This jar can go in the client's classpath.

The practice of Sun's Jini group has been to use the ClassDepAndJar tool
to create a single '-dl.jar' file for an associated set of service
instances.  My practice in Harvester has been to explicitly add the
download jars to the exported service's codebase annotation, generating
multiple jars in the codebase.  One problem is that the preferred
classloader mechanism only looks in the first jar file on the downloaded
codebase classpath so it only works with Sun's single-download-jar
approach.  I've been planning to have Harvester automatically combine
the codebase jars, but have so far avoided the need for the preferred
classloader mechanism.

So to summarize, a Jini service module will usually generate three jar
artifacts: (1) the service's actual code (some-service.jar), (2) the
codebase (some-service-dl.jar) jar, and (3) the api jar
(some-service-api.jar or some-service-client.jar).  I would expect the
codebase to be a subset of the code, and the api to be a subset of the
codebase, but I wouldn't guarantee it.  In addition, there might be a
file containing suggested configuration entries for either the service,
client, or both.



Greg Trasuk, President
StratusCom Manufacturing Systems Inc. - We use information technology to
solve business problems on your plant floor.

View raw message