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 02:56:55 GMT
Dennis Reedy wrote:
> On May 22, 2010, at 646PM, Peter Firmstone wrote:
> 
>> Dennis Reedy wrote:
>>> On May 20, 2010, at 628PM, Peter Firmstone wrote:
>>>
>>>  
>>>> We could call it api, instead of spec, so as not to confuse the Jini Spec?
 (We call River an implementation of the Jini Specifications)
>>>>
>>>> Implementation jar: service.jar
>>>> API jar: service-api.jar
>>>> Download jar: service-dl.jar
>>>>
>>>>    
>>> Thinking out loud here, what id the service does not use a smart proxy? There
is no difference between the API jar and the DL jar. Is the API jar only needed when the service
uses a smart proxy?
>>>  
>> Yep that's correct.
> 
> So as far as a convention is concerned here, what would you recommend? Only create API
jar for smart proxy implementations? Or only create DL jars for smart proxy implementations.
> 
> Seems that the latter makes more sense? If so than the API jar will always be in the
client's classpath. Will have problems with the service's registration with reggie though.

ServiceRegistrar doesn't stipulate the use of MarshalledObject values.  Reggie 
uses them though, and I think this means we have to consider both ways as being 
valid.  The codebase annotation needs to include the -dl.jar reference for 
marshalled objects to be unmarshalled on the client JVM.  codebase contamination 
can occur for using unmarshalled objects on a remote ServiceRegistrar.

It seems to me that there is no short cut about using the codebase, because we 
really need to support clients that know everything as well as clients that only 
know a interface and need to download and resolve everything else.

This is the most friendly thing to do so that clients never get a 
"ClassNotFoundException" just because you left an interface or abstract type 
that you added from this rev of your service, and which most clients now have in 
their upgraded client platform.

I really think there is a lot of power in the fact that clients should only have 
to know what they must know to use the service as they knew it when they were 
deployed.

Gregg Wonderly

Mime
View raw message