On 02/01/2015 10:56 AM, Alan Bateman wrote:
On 31/01/2015 23:47, Peter Levart wrote:
I agree. Putting the order on the SPI API is not the right solution.
The order should be configured in one place. But there needs to be
some kind of handle each service exposes for order configuration to
reference. So one idea how to extend the ServiceLoader mechanism is this:
I think this is a much bigger topic and one that the URL usage isn't
one of the better examples to explore it (the reason being that
providers of URLStreamHandlerFactory are proposed to only be located
via the system class loader, no proposal to allow for bundling with an
application which is where the real scope issues come to the fore).
I see. But if URLStreamHandlerFactories are only supposed to be located
via the system class loader, is that different from what we have now
when URLStreamHandlers are being located directly via class name
construction (prefix + protocol + .Handler) and loaded via the system
class loader? They have to be public classes with public default
constructors, yes. But so have to be URLStreamHandlerFactories too, to
be loadable by ServiceLoader.
Are we just trying to get rid of old mechanism or is there something I'm
missing?
I see. But isn't URL.setURLStreamHandlerFactory() enough for that
purpose? It can only be set once, but there can only be *one*
container that wants it's jar protocol handler configured system-wide.
This a good question as it brings up the scenario that Chris is trying
to address by introducing addURLStreamHandlerFactory. The concern is
where the container starts an application that also uses the legacy
setURLStreamHandlerFactory. The container is trying not to cause the
application to fail with an error. Looking at it again then I think
addURLStreamHandlerFactory is going to be more an attractive nuisance
that expected, despite the @apiNote and we need to drop this part of
the solution. There are compatibility and migration concerns but I
don't think they are significant in the overall context of a major
release.
If that's the reason for addURLStreamHandlerFactory (to support apps
deployed to containers and which use setURLStreamHandlerFactory) then
there should probably be some mechanism to allow those apps to call
setURLStreamHandlerFactory but don't allow them to override handlers for
protocols that container is trying to enforce (like jar). So factory set
by setURLStreamHandlerFactory should not be evaluated 1st. What about
the following order of evaluation:
1. default system factory if protocols are "file" or "jrt"
2. factories registered via ServiceLoader or addURLStreamHandlerFactory
or equivalent
3. factory set by setURLStreamHandlerFactory if any
4. default system factory
Peter
-Alan
