The `LocationStrategy` in `AgentBuilder`

Elastic Observability APM
1 
private static AgentBuilder getAgentBuilder(final ByteBuddy byteBuddy, final CoreConfigurationImpl coreConfiguration, final Logger logger,
                                                final AgentBuilder.DescriptionStrategy descriptionStrategy, final boolean premain,
                                                final boolean useTypePoolCache) {
        AgentBuilder.LocationStrategy locationStrategy = AgentBuilder.LocationStrategy.ForClassLoader.WEAK;
        if (agentJarFile != null) {
            try {
                locationStrategy = new AgentBuilder.LocationStrategy.Compound(
                    // it's important to first try loading from the agent jar and not the class loader of the instrumented class
                    // the latter may not have access to the agent resources:
                    // when adding the agent to the bootstrap CL (appendToBootstrapClassLoaderSearch)
                    // the bootstrap CL can load its classes but not its resources
                    // the application class loader may cache the fact that a resource like AbstractSpan.class can't be resolved
                    // and also refuse to load the class
                    new AgentBuilder.LocationStrategy.Simple(ClassFileLocator.ForJarFile.of(agentJarFile)),
                    AgentBuilder.LocationStrategy.ForClassLoader.WEAK,
                    new AgentBuilder.LocationStrategy.Simple(new RootPackageCustomLocator("java.", ClassFileLocator.ForClassLoader.ofBootLoader()))
                );
            } catch (IOException e) {
                logger.warn("Failed to add ClassFileLocator for the agent jar. Some instrumentations may not work", e);
            }
        }
...
}

The comment here indicates that it is important to resolve types from within the Agent Jar first.

However, with the commit: c5fede1f Isolated agent classloader, all Agent class files have been shadowed and have the suffix .esclass. This means that using the usual ClassLocator.ForJarFile should not be able to resolve these class files, such as co.elastic.apm.agent.bci.ElasticApmAgent and the more specific java.lang.IndyBootstrapDispatcher.

I'm working on customizing my own Javaagent based on Elastic. For the sake of correctness, I want to know if this behavior is expected. Can anyone help?

2

Hi,

Thanks for reaching out, but could you elaborate a bit on what kind of customization you are trying to achieve here ? Maybe there are simple ways that might be easier than what you are trying to.

The agent is isolated from the application classloaders on purpose to avoid side effects on the application and to avoid having to shade classes, this allows among other things to debug the agent code like regular Java code with an IDE.

If you need to add extra classes in your customized agent, then you should make sure they are also packaged as the other agent classes with the .esclass suffix.

3

Hi, @Sylvain_Juge thanks for your reply.
However, it seems to me that the functionality implemented by my agent is not directly related to this question.

In my agent, during the bytecode transformation, the main configuration for ByteBuddy is almost entirely derived from Elastic. After getting the code to compile, I revisited it and noticed that the part of the code highlighted in the issue seems outdated, as it no longer appears to serve the purpose mentioned in the comments, which caused some confusion.

I want to determine whether that part of the configuration has become outdated due to Elastic's updates, whether it still serves its original intended purpose, and whether there might be any side effects.

4

I agree that this comment might be obsolete now that most of the agent classes are loaded in an isolated classloader.

However, if I recall correctly, there are still a few classes that are injected in the bootstrap classloader, so this might still be relevant but less than it used to be previously (and the comment maybe slightly obsolete), unless there is a very good reason to change this code it will probably remain as-is. On the other hand, if there is a bug in this code it's also very likely to be reported and noticed by end-users and our integration tests.