When I inject classes into the JAR package specified by -Dotel.javaagent.extensions, the application JAR can load the bytecode of these classes, but the instantiation triggers an infinite recursive call

[fcabbage]

Detail information: I extend Dubbo's probe in the otel-agent-ext JAR package.
This is my InstrumentationModule and the extended probe:

@AutoService(InstrumentationModule.class)
public class DubboProbeInstrumentationModule extends InstrumentationModule implements ExperimentalInstrumentationModule {

    public DubboProbeInstrumentationModule() {
        super("apache-dubbo-probe", "apache-dubbo-probe-3.3.0");
        System.out.println("DubboProbeInstrumentationModule");
    }

    @Override
    public void registerHelperResources(HelperResourceBuilder helperResourceBuilder) {
        System.out.println("registerHelperResources");
        helperResourceBuilder.register(
                "META-INF/org.apache.dubbo.qos.probe.StartupProbe");
        if (!isIndyModule()) {
            // For indy module the proxy-bytecode will be injected as resource by injectClasses()
            helperResourceBuilder.registerForAllClassLoaders(
                    "com/cabbage/demo/otel/agent/ext/mvn/dubbo/probe/OtelAgentExtStartupProbe.class");
        }
    }

    @Override
    public ElementMatcher.Junction<ClassLoader> classLoaderMatcher() {
        System.out.println("classLoaderMatcher");
        return hasClassesNamed("org.apache.dubbo.qos.probe.StartupProbe");
    }

    @Override
    public void injectClasses(ClassInjector injector) {
        System.out.println("injectClasses");
        injector
                .proxyBuilder(
                        "com.cabbage.demo.otel.agent.ext.mvn.dubbo.probe.OtelAgentExtStartupProbe")
                .inject(InjectionMode.CLASS_ONLY);
    }

    @Override
    public List<TypeInstrumentation> typeInstrumentations() {
        System.out.println("typeInstrumentations");
        return singletonList(new ResourceInjectingTypeInstrumentation());
    }

    // A type instrumentation is needed to trigger resource injection.
    public static class ResourceInjectingTypeInstrumentation implements TypeInstrumentation {
        @Override
        public ElementMatcher<TypeDescription> typeMatcher() {
            System.out.println("typeMatcher");
            return named("org.apache.dubbo.common.extension.ExtensionLoader");
        }

        @Override
        public void transform(TypeTransformer transformer) {
            System.out.println("transform");
            // Nothing to transform, this type instrumentation is only used for injecting resources.
        }
    }

    @Override
    public boolean isIndyModule() {
        System.out.println("isIndyModule");
        return true;
    }
}

@Activate
@AutoService(StartupProbe.class)
public final class OtelAgentExtStartupProbe implements StartupProbe {

    @Override
    public boolean check() {
        System.out.println(this.getClass().getName());
        return true;
    }

}

This is the error message of the application JAR package when executing the probe command:

Caused by: java.lang.StackOverflowError: null
	at java.base/java.lang.invoke.DirectMethodHandle.allocateInstance(DirectMethodHandle.java:482) ~[na:na]
	at com.cabbage.demo.otel.agent.ext.mvn.dubbo.probe.OtelAgentExtStartupProbe.<init>(Unknown Source) ~[opentelemetry-javaagent.jar:na]
	at com.cabbage.demo.otel.agent.ext.mvn.dubbo.probe.OtelAgentExtStartupProbe.<init>(Unknown Source) ~[opentelemetry-javaagent.jar:na]
	at com.cabbage.demo.otel.agent.ext.mvn.dubbo.probe.OtelAgentExtStartupProbe.<init>(Unknown Source) ~[opentelemetry-javaagent.jar:na]

And this is the probe class modified at runtime:

ClassLoader:
+-jdk.internal.loader.ClassLoaders$AppClassLoader@2626b418
  +-jdk.internal.loader.ClassLoaders$PlatformClassLoader@4f5b08d

Location:
/D:/WorkPlace/Code/Java/OpenTelemetry/agent/opentelemetry-javaagent.jar

/*
 * Decompiled with CFR.
 *
 * Could not load the following classes:
 *  io.opentelemetry.javaagent.bootstrap.IndyBootstrapDispatcher
 *  io.opentelemetry.javaagent.bootstrap.InstrumentationProxy
 */
package com.cabbage.demo.otel.agent.ext.mvn.dubbo.probe;

import io.opentelemetry.javaagent.bootstrap.IndyBootstrapDispatcher;
import io.opentelemetry.javaagent.bootstrap.InstrumentationProxy;
import org.apache.dubbo.common.extension.Activate;
import org.apache.dubbo.qos.probe.StartupProbe;

@Activate(group={}, value={}, before={}, after={}, order=0, onClass={})
public class OtelAgentExtStartupProbe
implements StartupProbe,
InstrumentationProxy {
    private final Object delegate = IndyBootstrapDispatcher.bootstrap("ctor", new Object[]{"proxy", "com.cabbage.demo.otel.agent.ext.mvn.dubbo.probe.DubboProbeInstrumentationModule", "com.cabbage.demo.otel.agent.ext.mvn.dubbo.probe.OtelAgentExtStartupProbe", "constructor"});

    @Override
    public boolean check() {
        return (boolean)IndyBootstrapDispatcher.bootstrap("check", new Object[]{"proxy", "com.cabbage.demo.otel.agent.ext.mvn.dubbo.probe.DubboProbeInstrumentationModule", "com.cabbage.demo.otel.agent.ext.mvn.dubbo.probe.OtelAgentExtStartupProbe", "virtual"}, this.delegate);
    }

    public /* synthetic */ Object __getIndyProxyDelegate() {
        return this.delegate;
    }
}

[steverao]

Could you introduce something about your purpose?

[fcabbage]

I plan to extend Dubbo using its SPI mechanism (such as Dubbo Filter). In the source code of otel-agent, I found that classes can be injected into application JAR files through the injectClasses method, and these injected classes can be discovered by Dubbo's SPI mechanism (io.opentelemetry.javaagent.instrumentation.apachedubbo.v2_7). Therefore, I referenced a similar implementation method to build my own extension (Dubbo Probe). The difference is that I do this by the opentelemetry-javaagent-extension JAR, not in otel-agent JAR.

[steverao]

I am not very clear about your purpose why you need to achieve your Dubbo Probe like that. The current otel java agent does't meet your requirement? maybe there is more common approach to achieve your final target, can you explain more?

[jockercheng91]

I want to expand more agent capabilities while keeping the official opentelemetry agent 1.33.6 unchanged, but I also don't want to have strong coupling with business code. Can I specify my custom extension package to achieve my goal (similar to the skywalking agent's plugin mechanism) through - Dotel.javaagent.exe. I couldn't find any guidance document for this development method.

[jockercheng91]

I want to expand more agent capabilities while keeping the official opentelemetry agent 1.33.6 unchanged, but I also don't want to have strong coupling with business code. Can I specify my custom extension package to achieve my goal (similar to the skywalking agent's plugin mechanism) through - Dotel.javaagent.exe. I couldn't find any guidance document for this development method.

[laurit]

@jockercheng91 it is best to create a new discussion for your questions instead of hijacking some else's question. See https://github.com/open-telemetry/opentelemetry-java-instrumentation/tree/main/examples/extension for the sample extension.

[laurit]

@fcabbage Firstly you could try removing isIndyModule method, by default it returns false. If you wish to help us debug whey the instrumentation fails in indy mode then a sample application that reproduces the issue along with any necessary instructions would be nice. From the stack trace it looks like the proxy is invoking itself instead of delegating to the original class.