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 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.
-Alan
