river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Codebase service?
Date Sun, 23 May 2010 00:34:11 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.
>   
No, this would be more appropriate:

Smart Proxy:

    Implementation jar:     service.jar (depend on service-api.jar)
    API jar:                       service-api.jar
    Download jar:             service-dl.jar (depend on service-api.jar)


Dumb Proxy:

    Implementation jar:     service.jar (depend on service-api.jar)
    API jar:                       service-api.jar

That way, your free to implement a smart proxy service later if you want 
to move processing to the client or vice versa.

Most importantly we want to promote others to standardise on popular 
service-api.jar's available on Maven's repositories.

The ClassLoader structure I have in mind will load all API (hence dumb 
proxy's too) into the Jini Platform ClassLoader, they will be protected 
by the Service-api.jar ProtectionDomain. O:-)



Mime
View raw message