On 02/04/2015 02:54 PM, Chris Hegarty wrote:
On 02/02/15 20:52, Alan Bateman wrote:
....
I'm happy with this approach. One outstanding point from the discussion
is whether the URLStreamHandlerFactory implementation will need to be
granted RuntimePermission("setFactory"), if so then this will need to go
into the javadoc.
I think that we should check "setFactory" for providers located
by service loader. The most appropriate way to do this is with
a new public abstract type who's constructor checks this,
similar to CharsetProvider ( and others ).
The updated spec revision, link below, defines the new public
provider type in a new networking service provider interface
package, java.net.spi. Future service provider interfaces for
the java.net package should be defined into this package.
http://cr.openjdk.java.net/~chegar/8064924/03/specdiff/overview-summary.html
Note:
The spec does no mention what happens when a SecurityException is
thrown ( it will be the cause of the SCE ). The prototype
implementation I have will will swallow it, and continue searching,
as is done for CharsetProviders. A SecurityException, locating
a provider, should not prevent the the app from making progress.
The provider will just not be available.
-Chris.
Hi Chris,
I agree that this is the most appropriate way with which you can force
some provider's class code (the constructor) in the call stack so that
you get correct AccessControlContext to check against. But the name
starts to sound like German words. :-)
Wouldn't URLStreamHandlerProvider be enough? Since it's a provider for
URLStreamHandlers and not URLStreamHandlerFactories.
Regards, Peter
