jmx-dev [PATCH] JDK-6705499: Bad JMXConnectorProvider class name prevents all connections - even with standard RMI connector

[Jaroslav Bachorik]

On 10/24/2012 04:28 PM, Alan Bateman wrote:
> On 24/10/2012 15:15, Jaroslav Bachorik wrote:
>> I am looking for review and a sponsor.
>>
>> Webrev is available at
>> http://cr.openjdk.java.net/~jbachorik/JDK-6705499/webrev.00/
>>
>> The issue is caused by the way the java.util.ServiceLoader treats the
>> service registration with incorrect class names. Such a service
>> registration causes java.util.ServiceConfigurationError to be thrown and
>> the JMXConnector(Server)Factory is not ready for this. Thanks to the
>> exception all the other, potentially valid, service registrations are
>> ignored.
>>
>> The patch makes JMXConnector(Server)Factory class ready for
>> java.util.ServiceConfigurationError and when such an exception is caught
>> the factory just proceeds to the next registration. If the only
>> available registration causes the exception it will be rethrown at the
>> end.
>>
>> Thanks,
>>
>> -JB-
> I'm not so sure this is the right thing to do. When SCE is thrown then
> there is no guarantee that you can continue and there isn't enough
> information in the error to know whether it makes sense to attempt to
> continue or not. We have this same issue in many areas of the platform

Shouldn't this be indicated by the "hasNext()" method of the iterator
returned by ServiceLoader? I mean - whether you can continue enumerating
the providers or not.

I agree that the fact that SCE is an Error subclass alone makes catching
and handling it rather dubious but it seems a bit harsh to throw a
(supposedly) unrecoverable exception only because one entry in the
service configuration file is invalid.

> and I think it requires future work in ServiceLoader to help users of
> the API decide whether to continue or not. Once we move to modules then

Yes, a proper fix would be in the ServiceLoader but it will most
probably involve API changes. Eg. instead of generating an Error a
checked exception should be thrown indicating a problem with the
particular service configuration line.

> many of the reasons for SCE will go away because the list of service
> provider is precomputed so there is no scanning of class paths or
> parsing of configuration files at runtime. So if this one is not urgent
> they it may be something to come back to again in the future.

Unfortunately, it will take some time till we have modules :( Until then
you can completely disable JMX subsystem simply by placing a poison jar
on classpath (probably other ServiceLoder based services as well but
this issue is about JMX).

Even though the issue is P3 it has been there sitting unresolved for 4
years and keeping it for another 3 (till JDK9) would look quite strange,
IMO.

What about filing an issue for ServiceLoader (if there is none yet) and
then pushing this workaround with comment that it should be revisited
once the modules are in place?

-JB-

> 
> -Alan.
>