JDK-6366543 : A valid MBean is rejected as NotCompliant when some security is in use
  • Type: Bug
  • Component: core-svc
  • Sub-Component: javax.management
  • Affected Version: 6
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2005-12-22
  • Updated: 2010-07-29
  • Resolved: 2006-01-19
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
6Resolved
Related Reports
Duplicate :  
JDK-6370080 - (ann) Method.getAnnotations() sometimes throw SecurityException: doPrivileged or javadoc missing?
Description
As of Mustang b64.
Attached code allows you to reproduce easily.
The scenario is about an MBeanServer where we register two standard MBeans.
The first MBean (UnDescribed) does not make use of the DescriptorKey annotation.
The second MBean (Described) has exactly the same management interface and makes use of the DescriptorKey annotation.

We run that code once without any security in the picture; all goes pretty well.

% java6 -classpath lib/defect.jar sqe.Defect

We register an MBean where DescriptorKey is not used at all

	OK - The MBean defaultDomain:class=UnDescribed is registered = true

We register an MBean with exactly the same management interface as above and where DescriptorKey is used.

	OK - The MBean defaultDomain:class=UnDescribed is registered = true

Now we run that code with a security manager and a policy file.
As you see below, the first MBean is still registered fine (then the security settings are fine) but the second MBean is rejected as NotCompliant.

% java6 -classpath lib/defect.jar -Dtests.codeBase=lib/defect.jar -Djava.security.manager -Djava.security.policy==java.policy.codeBase sqe.Defect

We register an MBean where DescriptorKey is not used at all

	OK - The MBean defaultDomain:class=UnDescribed is registered = true

We register an MBean with exactly the same management interface as above and where DescriptorKey is used.

	ARRGH ...
javax.management.NotCompliantMBeanException: Not compliant
	at com.sun.jmx.mbeanserver.Introspector.makeDynamicMBean(Introspector.java:194)
	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:915)
	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312)
	at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:482)
	at sqe.Defect.run(Defect.java:41)
	at sqe.Defect.main(Defect.java:23)

Extra security checking should not make an MBean NotCompliant.
Perhaps the use of DescriptorKey implies extra permissions into the policy file but then it might be documented somewhere.
Comments
SUGGESTED FIX See http://amos.france.sun.com/jmgt/master/webrev/jmx/mustang/6366543-webrev/ This fix passed the JMX tests in JavaSE SQE test suite.
11-01-2006
EVALUATION The security exception comes from Method.getAnnotations(). As this is not supposed to throw a security exception (there's nothing in the Javadoc that indicates that it could) I have logged 6370080 against classes_lang. In the mean time we could put a doPrivileged() around the call to getAnnotation(). We may need to keep this doPrivileged if 6370080 is a doc bug.
10-01-2006
EVALUATION There are several places in the code where we do a: catch (Exception e) { ... } which later results in a NotCompliantMBeanException to be thrown. This is what I suggest: 1) Correct all places that catch (Exception), making sure that SecurityExceptions are not inapropriately hidden, 2) take option 2 for makeDynamicMBean(), that is, only catch NotCompliantException there, since the catching/transforming into NotCompliantException has already been performed within the called methods.
09-01-2006
EVALUATION Looks like we are falling afoul of the following extremely clunky code in com.sun.jmx.mbeanserver.Introspector: Class c; try { c = getStandardMBeanInterface(mbeanClass); return new StandardMBeanSupport(mbean, c); } catch (Exception e) { // Ignore exception } try { c = getMXBeanInterface(mbeanClass); return new MXBeanSupport(mbean, c); } catch (Exception e) { // Ignore exception } checkCompliance(mbeanClass); throw new NotCompliantMBeanException("Not compliant"); // not reached "// Ignore exception", indeed. We're probably swallowing a SecurityException here. The exception that is the subject of this report is thrown by the supposedly "not reached" statement. We need to rewrite these methods appropriately, perhaps by returning null rather than throwing an exception from getStandardMBeanInterface, or by catching NotCompliantMBeanException rather than just Exception.
22-12-2005