Daniel,
> So is it expected that modules (e.g. java.corba) will register
> their own service provider for the InitialContextFactory
> (I mean - using META-INF/services/)?
Alan's already answered this point. TCCL is the way to go. You are right.
> The difference however is that in this two case we're looking for
> a service implementing a specific feature, we're not looking for a
> service whose concrete class matches a specific class name.
Agreed.
> In the case of InitialContextFactory - as a client of the API, I
> would be a bit surprised if - asking for a LDAP InitialContext,
> I received a CORBA exception. This would look strange to me.
Once again, agreed.
> A possibilty might be to use InitialContextFactoryBuilder as the
> service interface instead, and loop over the implementations until
> you find one that does not throw NamingException - but then it
> would be difficult to make the distinction between
> 'This builder does not support the Context.INITIAL_CONTEXT_FACTORY
> that you ask for' and 'The InitialContextFactory could not be
> instantiated for various reasons'...
The closest thing to what you described here would be
java.sql.DriverManager:664, I think. I don't think this is an acceptable for
JNDI though. This would require to modify all the providers out there to
provide a new entry point -- their own implementation of
InitialContextFactoryBuilder.
> Maybe it's because I haven't used JNDI very often, but when
> I read the spec I didn't realize that the value of
> Context.INITIAL_CONTEXT_FACTORY would have any effect if
> ServiceLoader was used - because it's not usual to use
> ServiceLoader in this way (even though the usage of
> ServiceLoader is nested below 'the class specified in
> the Context.INITIAL_CONTEXT_FACTORY</tt> environment property
> is used').
> I'm not sure it would be overspecifying to say that the ServiceLoader
> is used to locate and load an implementation of the service whose
> concrete class matches the named class - since that's what it's
> doing anyway - but I understand your concern.
It's definitely worth thinking about. Thanks.
> So a broken InitialContextFactory for technology XXX can
> prevent getting the InitialContext for technology YYY even if both
> have nothing in common, and even if XXX is never actually
> used in the application.
+1 It indeed seems very strange at first sight. But I believe this thing is a
subjective tradeoff between the effects caused by unexpected "CORBA exception"
and the effects caused by some strange behaviour after an "unrelated" exception
was silently swallowed by the runtime.
It's more like a fail-fast behaviour, when even "unrelated" things are reported
about:
I dropped by your house to deliver the letter. Btw, it seems you've
left you kettle on...
Some time ago I asked myself the same question. And looked through the codebase
to see how the ServiceLoader is used. I found some "fault-tolerant"
implementations:
com.sun.media.sound.JSSecurityManager:189
java.sql.DriverManager:605
sun.tools.jconsole.JConsole:1004
com.sun.tools.attach.spi.AttachProvider:261
com.sun.tools.jdi.VirtualMachineManagerImpl:95
com.sun.tools.jdi.VirtualMachineManagerImpl:124
javax.script.ScriptEngineManager:124
As you can see there's no right answer here. It certainly depends on the
behaviour you want to achieve. Suppose your service provider are plugins (as it
is the case for JConsole example above) then it doesn't make any sense to
shutdown if any single plugin failed. Leave this decision to a client. Report
the warning. On the language level there's no such thing is warning. Only
exceptions and return values. We could emulate warning with logging but... I'm
sure there are many reasons why that might not fly.
-Pavel
