Bug 58577

Summary: JMX Proxy Servlet can't handle overloaded methods
Product: Tomcat 8 Reporter: Johan Compagner <jcompagner>
Component: ManagerAssignee: Tomcat Developers Mailing List <dev>
Status: RESOLVED FIXED    
Severity: enhancement    
Priority: P2    
Version: 8.0.x-trunk   
Target Milestone: ----   
Hardware: PC   
OS: Windows NT   

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 {
            info=server.getMBeanInfo(oname);
        } 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