Bug 58577 - JMX Proxy Servlet can't handle overloaded methods
Summary: JMX Proxy Servlet can't handle overloaded methods
Alias: None
Product: Tomcat 8
Classification: Unclassified
Component: Manager (show other bugs)
Version: 8.0.x-trunk
Hardware: PC Windows NT
: P2 enhancement (vote)
Target Milestone: ----
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2015-11-03 12:44 UTC by Johan Compagner
Modified: 2020-01-08 15:02 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Johan Compagner 2015-11-03 12:44:35 UTC
currently the JMXProxy when invoking an operation does this:

 ObjectName oname=new ObjectName( onameStr );
        MBeanOperationInfo methodInfo = registry.getMethodInfo(oname,operation);
        MBeanParameterInfo[] signature = methodInfo.getSignature();

so it calls the registry for a method info for a specific bean and operation

that Registry does this:

 public MBeanOperationInfo getMethodInfo( ObjectName oname, String opName )
        MBeanInfo info=null;
        try {
        } catch (Exception e) {
            log.info( "Can't find metadata " + oname );
            return null;
        MBeanOperationInfo attInfo[]=info.getOperations();
        for( int i=0; i<attInfo.length; i++ ) {
            if( opName.equals(attInfo[i].getName())) {
                return attInfo[i];
        return null;

which is wrong because that just returns the first hit by name.

I think at least the patch should be that that getMethodInfo gets a 3th argument which is the number of arguments it should have. Or better an array of Types where the parameters should map on. (but that can be in this scenario tricky because the caller site doesn't know the types)

Or it should just return all a Array of MBeanOperationInfo of all hits for that name and let the caller handle it what it can use or call.
Comment 1 Christopher Schultz 2020-01-08 15:02:04 UTC
I chose to make the simplest possible change for now, which is to check the argument count. It's not entirely possible to look for the exact right types because the parameter values come from the request as String values.

With enough code, it might be possible to find a list of candidate methods, then attempt to convert the parameter strings into the target types for each one, and see if any of them succeed (or skip the failures) and invoke that particular type of operation. On the other hand, MBean operations should probably be designed to avoid such conflicts.

This is fixed in e16472f93659c053f4af20ec5bacc08c342a0b90

Will be in 9.0.31
Will be in 8.5.51
Will be in 7.0.100