JDK-6234398 : JMX connection provider API exception handling unclear
  • Type: Enhancement
  • Component: core-svc
  • Sub-Component: javax.management
  • Affected Version: 5.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2005-03-01
  • Updated: 2017-05-16
  • Resolved: 2005-06-25
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 b43Fixed
Description
The expected behavior of a JMXConnectorProvider does not appear to be the same depending upon how the JMXConnectorProvider is invoked. The JMXConnectorProvider cannot know how it has been invoked.

In more detail - the newJMXConnector call is expected to throw an exception
if the provider cannot provide the requested protocol from the URL.

If the provider is located through the classpath (as a service), the provider must throw a JMXProviderException to indicate that it is not the correct provider, I think, in any case, this usually means that a provider exists for the protocol but cannot be used. And also, a message gets logged when this happens.

If the provider class is supplied in the connection environment, the provider must *NOT* throw a JMXProviderException and should throw another exception such as MalformedURLException.

More javadoc and/or examples would be helpful here, and if the behavior really is inconsistent some kind of means for the provider knowing how it's being called (maybe for compatibility we could introduce something into the map to indicate usage).

###@###.### 2005-03-01 17:06:42 GMT

Comments
EVALUATION I think the right thing to do is to throw a MalformedURLException always. But we should confirm that, and we definitely should document it better. ###@###.### 2005-03-02 17:13:41 GMT
02-03-2005