You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
Affects: Spring Boot 2.2.11 (but most likely the current version as well, the code is the same)
The
ParentAwareNamingStrategy
bean created byJmxAutoConfiguration
changes the original order of key properties of theObjectName
unconditionally, as it decomposes the original name ingetObjectName()
and recreates it to add, if configured, "identity" and "context" fields, by using aHashtable
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 toMBeanExporter#registerManagedResource(Object)
, that modifies the name only if changes are needed.The text was updated successfully, but these errors were encountered: