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. Greg. -- Greg Trasuk, President StratusCom Manufacturing Systems Inc. - We use information technology to solve business problems on your plant floor. http://stratuscom.com
