river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <gr...@wonderly.org>
Subject Re: Codebase service?
Date Mon, 24 May 2010 13:24:50 GMT
Greg Trasuk wrote:
> On Sun, 2010-05-23 at 17:12, Dennis Reedy wrote:
>> Since we will be formalizing the convention of creating a service.jar, service-api.jar
and service-dl jar, what I was musing about really was the creation of perhaps an extra an
unnecessary jar in the case where a service does not use a smart proxy. I agree with Greg,
in that a client should always depend on the API jar, and not the DL jar. 
>> The client will have the service-api.jar in it's classpath, and the service will
have an export codebase set to serve the service-d.jar. The service may also create some variant
of the previously discussed DLEntry, and the service-dl.jar may be provisioned to the client
as an option (whether a maven repository is used or not).
>> If the particular service does end up having 2 jars with identical content, oh well.
It preserves the approach and allows flexibility going forward.
> Could it be that we're assuming a service can only call out one jar as
> it's codebase?  If so, I don't think that's true, although if all you've
> ever used is java.rmi.server.codebase, you might think so.  It's no big
> problem for a service to mention its *-api.jar as its codebase (check
> out URLClassLoader), and add on a *-dl.jar if necessary.  I think that
> makes both Reggie and ServiceBrowser happy.  Though I'm pretty sure
> Reggie doesn't care about codebases, because it just handles marshalled
> objects.  ServiceBrowser does choke if it can't unmarshall all the
> entries, however.

I use around 5 jars in my codebase typically, and sometimes more.  The -dl.jar 
is there, but I have utility jars as well as things like JDBC drivers, SPI 
implementations for things like JMX connectors and other things that are already 
  packaged into a jar, and recombining, while trivially possible, presents some 
issues with how easy bugs get fixed.  Having a single combined jar, does help 
compartmentalize API dependencies as these other jars roll through versions, but 
in the end, it just comes down to how you package your codebase pieces for your 

Gregg Wonderly

View raw message