ServiceLoader.load* take 2

[Paul Sandoz]

On Jun 12, 2012, at 11:42 PM, Jesse Glick wrote:

> On 06/12/2012 05:34 PM, David M. Lloyd wrote:
>> Is there an expectation that a configuration will exist per-application
> 
> Yes, I think that is the intent.
> 

Yes, one app == one config 

I don't know how familiar people are with the code, but if one is I suspect it is reasonably easy to grok the change in scope to service instance creation.


>> so that applications do not tend to have overlapping modules?
> 
> They could certainly overlap in contained modules, but a given JVM (or isolate??) would be running one configuration with a particular set of modules in it, according to the application's needs.
> 

There is definitely a connection between an app/config and a container "hosting" the app that is isolated from other containers within the same JVM e.g. an analogy would be an app server running multiple web apps, where there are platform modules supplied by the app server and modules that are specific to the app.


>> Does this mean that [...] service implementations should generally be global per installation?
> 
> No, I think just global per _application_. In other words, given a service
> 
> package api;
> public interface ImageFileReader {
>  boolean supports(Path image);
>  Image read(Path image) throws IOException;
> }
> 
> you would expect that any module in a given application calling
> 
> for (ImageFileReader r : ServiceLoader.load(ImageFileReader.class)) {...}
> 
> would get the same list of services. This would be true in classpath mode simply because the TCCL is always going to be ClassLoader.getSystemClassLoader(), i.e. JARs dumped in the -classpath.

+1

Paul.