apm-agent-java uses shading for some of the dependencies it uses, but it doesn't change package names for them.
This caused dependencies to clash with different versions I had in my project, which defeats the purpose of shading.
Is there a plan to change this approach, so that shaded dependencies within apm-agent can work with other versions on classpath?
Welcome to our forum and thanks for the question!
We used to prevent class loading clashes through shadings, but since 1.27.0 we changed this model and now we load all of these dependencies from a dedicated agent class loader that has no access to other parts of the application classpath and is not accessible to anything that is not agent code.
This caused dependencies to clash with different versions I had in my project, which defeats the purpose of shading.
If you mean there are clashes within your IDE, then this was never the purpose of shading and the way to deal with such is through your IDE. Shading was used to prevent runtime clashes related to class loading only. If you experience such, most likely you have the wrong setup, for example - if you declared a dependency on the agent itself. If you describe your setup with greater details and the exact issue you get, maybe we can assist.
So I'm trying to bump our version of apm-agent-java to 1.28.4, for which I also needed to include apm-agent to get access to some classes that were in apm-agent-api in our older version.
This code uses asm version shaded within it, but when I have another incompatible version on my classpath (through local dependency), my tests fail because of the version mismatch (message "Found interface but class was expected"), which means my local asm version is getting mixed up with what's been shaded in apm-agent.
So currently I find no way of using both new apm-agent version and our current asm version.
Is this expected/wanted behaviour or not?
I would expect this if I didn't see shaded dependencies in your .jar, but now it seems like it should not behave like that?
The agent is not designed to be included as a dependency, which is why you get these errors.
I don't get that - the API is a separate artifact that is designed to be added as a dependency. Which classes are you depending on, for which you need to depend on the agent?
In our code we use TraceContext and CoreConfiguration to get access to certain constants they hold.
Those were available in 1.19.0 in elastic-apm-agent, but now they are moved to apm-agent module (also I found no mention of this in "Breaking Changes" section of release notes).
Those are not considered breaking changes because they are part of internal APIs. If we would list any change in internal APIs- everything would be a breaking change.
I suggest you either simply include the required Strings as your own constants, or add the agent dependency as provided.
As all modules are available to be pulled in using maven, how can we know what is considered internal API?
There was no annotation to suggest that and package/class names also didn't seem like something internal.
Sorry for not being clear enough about that 
.
I hope you find an easy way to work around this issue
This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.