pinpoint-apm/pinpoint · warning

No methods are intercepted. target:{}, interceptor:{}, metho

Error message

No methods are intercepted. target:{}, interceptor:{}, methodFilter:{} 

What it means

ASMClass.addInterceptor0 logs this warning when, after applying the MethodFilter to the target class, no method matched, so no interceptor was injected and interceptorId remains -1. Instrumentation of that class is effectively a no-op: the interceptor code exists but is never wired to any method. The agent does not fail; the target methods simply remain uninstrumented.

Source

Thrown at agent-module/profiler/src/main/java/com/navercorp/pinpoint/profiler/instrument/ASMClass.java:469

        final InterceptorArgumentProvider interceptorArgumentProvider = objectBinderFactory.newInterceptorArgumentProvider();
        final AutoBindingObjectFactory filterFactory = objectBinderFactory.newAutoBindingObjectFactory(pluginContext, classNode.getClassLoader(), interceptorArgumentProvider);
        final ObjectFactory objectFactory = ObjectFactory.byConstructor(filterTypeName, (Object[]) annotation.constructorArguments());
        final MethodFilter filter = (MethodFilter) filterFactory.createInstance(objectFactory);

        boolean singleton = annotation.singleton();
        int interceptorId = -1;

        for (InstrumentMethod m : getDeclaredMethods(filter)) {
            if (singleton && interceptorId != -1) {
                m.addInterceptor(interceptorId);
            } else {
                // TODO casting fix
                interceptorId = ((ASMMethod) m).addInterceptorInternal(interceptorClass, constructorArgs, scope, executionPolicy);
            }
        }

        if (interceptorId == -1) {
            logger.warn("No methods are intercepted. target:{}, interceptor:{}, methodFilter:{} ", this.classNode.getInternalName(), interceptorClass, filterTypeName);
        }

        return interceptorId;
    }


    @Override
    public int addInterceptor(Class<? extends Interceptor> interceptorClass) throws InstrumentException {
        Objects.requireNonNull(interceptorClass, "interceptorClass");
        return addInterceptor0(interceptorClass, null, null, null);
    }

    @Override
    public int addInterceptor(Class<? extends Interceptor> interceptorClass, Object[] constructorArgs) throws InstrumentException {
        Objects.requireNonNull(interceptorClass, "interceptorClass");
        Objects.requireNonNull(constructorArgs, "constructorArgs ");
        return addInterceptor0(interceptorClass, constructorArgs, null, null);
    }

View on GitHub (pinned to 744c3d3075)

Solutions

1. Log/print the target class's declared methods and confirm the expected method exists at runtime
2. Check the methodFilter's name and parameter type matching — remember internal names (Ljava/lang/String;) and inheritance rules
3. Use executionPolicy/scope settings appropriate for inherited methods, or add the interceptor to the declaring superclass transformer instead
4. Update the plugin to the library version actually deployed (e.g. different method signature after upgrade)

Example fix

// before
filter = new MethodFilter() {
    public boolean accept(ASMMethod method) {
        return method.getName().equals("doServive"); // typo
    }
};
// after
filter = new MethodFilter() {
    public boolean accept(ASMMethod method) {
        return method.getName().equals("doService");
    }
};

// before adding the interceptor, assert the method exists on the runtime class
classOf(target).getDeclaredMethods().any { m -> filterName == m.name } // else fix the filter name/signature

function declaresMethod(clazz, name) { try { return clazz.getDeclaredMethod(name) != null; } catch (e) { return false; } }

if (interceptorId == -1) { logger.warn("No methods are intercepted. target:{}, interceptor:{}, methodFilter:{}", internalName, interceptorClass, filterTypeName); }

When it happens

Trigger: addInterceptor/addScopedInterceptor called with a methodFilter whose name/constructor/signature predicates match no method in the target class (wrong method name, wrong parameter types, method is synthetic/bridge-filtered out, or the class truly lacks the method at the instrumented version).

Common situations: Plugin targets e.g. HttpServlet.service via a filter but the app uses a subclass override; library upgrade changed method signatures; filter parameters specified with wrong descriptor.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors

• source and advice class node must not be null.
• unexpected {} invoke count {}
• No methods are intercepted. target:{}, interceptor:{}, metho
• ${name} define fail Caused by:${e.getMessage()}
• Unknown InstrumentEngine:${instrumentEngine}

AI-assisted analysis of pinpoint-apm/pinpoint@744c3d3075 (2026-09-07). Data as JSON: /api/errors/f9eec910c161e2cf. Report an issue: GitHub.