On 13/10/2016 19:40, Thomas Watson wrote:
I don't think service loader lookup is going to help us here. Each
framework instance will need its own provider but the set of providers
will be constant to what is discovered on the system class loader. As
additional frameworks come up their providers will have no chance to
be discovered. Furthermore each framework implementation can be
loaded by a non-system class loader. For the usecase I am concerned
about the framework implementation will not be loaded by the system
class loader but instead by some dynamic class loader that can be
thrown away when the framework instance is torn down. For Eclipse a
small launcher is the only jar on the system class loader. The
framework itself is loaded with a custom class loader the launcher
creates.
I should have been clearer. I was trying to point out that you can
locate URLStreamHandlerProvider implementations that aren't built-in or
deployed on the class path yourself. That should be enough to create the
URLStreamHandler and do the wrapping that I think you are doing.
:
I have not been able to determine why an SPI is needed for providing
URLStreamHandlerFactory implementations to the service loader but not
for ContentHandlerFactory implementations. The
URLStreamHandlerProvider is just an empty abstract class that
implements URLStreamHandlerFactory. Why couldn't the provider type
just be URLStreamHandlerFactory directly similar to how
ContentHandlerFactory is?
This is a security sensitive area and the permission check needed here
couldn't be reliably enforced if the interface URLStreamHandleFactory
were the service type. There is discussion on net-dev where this point
was discussed.
Speaking of net-dev, then maybe this thread should move there as this
topic is really more of a URL issue rather than module system issue.
-Alan
