]
Brian Stansberry updated WFCORE-3493:
-------------------------------------
Issue Type: Bug (was: Task)
MBeanInfoFactory stores invalid minValue/maxValue data for
jboss.as.expr domain
-------------------------------------------------------------------------------
Key: WFCORE-3493
URL:
https://issues.jboss.org/browse/WFCORE-3493
Project: WildFly Core
Issue Type: Bug
Components: JMX
Reporter: Brian Stansberry
Assignee: Brian Stansberry
MBeanInfoFactory.getParameterInfos is trying to store a minValue and maxValue in the
OpenMBeanParameterInfo it creates if the DMR description data includes a "min"
or a "max". This is fine when numeric types are what is being stored, but with
the jboss.as.expr domain what's being stored are Strings. And OpenMBeanParameterInfo
is meant to do meaningful comparisons of values against any configured min and max. It
does this via Comparable.compareTo calls on the provided objects. That doesn't work
with String, e.g. "6".compareTo("2147483647") reports that 6 is
bigger.
Constructing the OpenMBeanParameterInfo itself will fail if item has a default that
doesn't lexically compare properly with any min or max or if the min and max don't
happen to lexically compare properly. The only reason this doesn't blow up now is we
don't happen to have any attributes with default values that are lexically greater
than the string form of their max (e.g. 3 or higher would be more than
Integer.MAX_VALUE).
I expect we'd also see failures if anyone used the OpenMBeanParameterInfo we provide
and called isValue on it with something like 3.
I think the correct solution is to simply not provide this data for any non-numeric
OpenMBeanParameterInfo. There would be a loss of information provided to human readers who
happen to inspect the OpenMBeanParameterInfo but what we provide now is not correct for
software consumers. An alternative is to only turn this off is the attribute has a default
that doesn't fall lexically between the min and the max, or if we have min that is
lexically greater than the max. This would mean we continue to present human readable data
and just hope that there are no software consumers that expect it to function as per the
OpenMBeanParameterInfo javadoc.