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:-)
