river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Reedy <dennis.re...@gmail.com>
Subject Re: Service API, class visibility, isolation and garbage collection - ClassLoaders
Date Thu, 27 May 2010 18:39:22 GMT

On May 27, 2010, at 451AM, Peter Firmstone wrote:

> Hi Dennis,
> I can live with Compile time only Service API's (not dynamically loaded), as has been
identified, the API is known prior by the application.

I'm sorry for not answering your question directly, I want to make sure I understand you correctly.

By compile time, are you thinking of an environment that only deals with classes that are
loaded at JVM start time? 

Or, since a client needs to have some a-priori knowledge of what it wants to discover and
use, that means the class(es) are known by the client in advance. And those classes are included
in the classpath of the client. Is that what you mean by compile time?

> We should encourage developers to maker their Service API publicly available on Maven
repository's, for others to implement.

Well, it would be for others to 'use'. Typically artifacts are published to repositories so
you can use them. You may be able to obtain the sources, and depending on the license (or
other criteria) of the project create derivative implementation(s). But in general the issue
is not one of creating implementations, but one of use and inclusion into the systems that
you create.

> So we can implement any Service API, whether we have the source or not, confident that
it cannot obtain any Permission's, we can guarantee this by using static immutable ProtectionDomain's
for Service API, where Policy checks are excluded.  Is this the best policy?  Or should we
allow dynamic Permission grants for ServiceAPI too?  We can always relax our policy later,
to make it stricter would risk breaking code if we had to reverse the decision.
> Service Implementers produce jar archives for:
> Smart Proxy's:
> Implementation jar: service.jar (depends on service-api.jar)
> API jar:            service-api.jar (unless implemented already)
> Smart proxy jar:    service-proxy.jar (depends on service-api.jar)
>               The proxy can depend on other jar's too.
> Dumb Proxy's:
> Implementation jar: service.jar (depends on service-api.jar)
> API jar:            service-api.jar
> Client's must produce the following jar archive, if extending Parameters:
> Client Parameter extensions:   AnyNameYouLike-param.jar

Why do we need the -param.jar again? 
View raw message