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.


Reply via email to