Affects: Spring Boot 2.2.11 (but most likely the current version as well, the code is the same)
The ParentAwareNamingStrategy bean created by JmxAutoConfiguration changes the original order of key properties of the ObjectName unconditionally, as it decomposes the original name in getObjectName() and recreates it to add, if configured, "identity" and "context" fields, by using a Hashtable to temporarily store the key properties.
An object name defined with @ManagedResource like "ABC:type=something,name1=def,name2=ghi" with more than one property except "type" could therefore change to "ABC:type=something,name2=ghi,name1=def".
While two ObjectNames with the same key properties in different order are semantically equal and the canonical name stays the same, this change may not affect regular calls through the JMX API, but it at least affects JConsole, as JConsole relies on the property order to build the MBean hierarchy in the "MBeans" tab. Other tools that for whatever reason rely on the same order as defined in the code might be affected as well.
For the case above, a hierarchy ABC > def > ghi in JConsole might change to ABC > ghi > def, which at least affects things like documentation about where to find specific operations or attributes.
It's potentially not easily possible to keep the order intact if "identity" and "context" fields would need to be added, but it might be already helpful, if ParentAwareNamingStrategy would simply use the original name as-is, if these fields don't need to be added, similar to MBeanExporter#registerManagedResource(Object), that modifies the name only if changes are needed.
Comment From: snicoll
Thanks for the report.
It's potentially not easily possible to keep the order intact if "identity" and "context" fields would need to be added
I don't see how that's possible indeed considering that ObjectName itself uses an HashTable. However, you are right that we should only change the ObjectName if that is necessary.
Comment From: wilkinsona
I think it may be possible to preserve the order with something like this:
private ObjectName appendToObjectName(ObjectName name, String key, String value) throws MalformedObjectNameException {
return ObjectNameManager.getInstance(name.getDomain() + ":" + name.getKeyPropertyListString() + "," + key + "=" + value);
}
However, I don't think we should take this approach as it would not be consistent with Framework's JmxUtils.appendIdentityToObjectName. We can, however, leave the order unchanged when neither identity nor context is being added.
@rschuetz If you would like the property ordering to be preserved when the identity or context attribute is being added, please open a Spring Framework issue proposing a change to JmxUtils.appendIdentityToObjectName and comment here with a link to it. If the Framework team agree with preserving the order we can then adapt accordingly in Spring Boot.
Comment From: rschuetz
@wilkinsona: Thanks a lot for the quick resolution. The current approach is fine for me for now.