indy instrumentation - leftovers migration #13074
Conversation
…nstrumentation into indy-leftovers
.../io/opentelemetry/javaagent/instrumentation/internal/lambda/LambdaInstrumentationModule.java
Outdated
Show resolved
Hide resolved
.../main/java/io/opentelemetry/javaagent/instrumentation/internal/lambda/LambdaTransformer.java
Outdated
Show resolved
Hide resolved
| } | ||
|
|
||
| @Override | ||
| public byte[] transform( |
There was a problem hiding this comment.
[for reviewer] here we override the pre-java9 API and then resolve the class module from the class, this allows to transparently call it from code compiled with Java 8 API level.
In practice, there is only a single usage for this in the internal lambda instrumentation, which makes it equivalent to the (now removed) Java9LambdaTransformer.
| instrumentationInstalled = true; | ||
| ClassFileTransformerHolder.setClassFileTransformer(resettableClassFileTransformer); | ||
| if (JavaModule.isSupported()) { | ||
| // wrapping in a JPMS compliant implementation |
There was a problem hiding this comment.
[for reviewer] wrapping at registration time helps to make the consumer transparently use it with java 8 API.
| public class InlineIbmResourceLevelInstrumentationModule extends InstrumentationModule { | ||
| public InlineIbmResourceLevelInstrumentationModule() { | ||
| super("inline-ibm-resource-level"); | ||
| public class IbmResourceLevelInstrumentationModule extends InstrumentationModule { |
There was a problem hiding this comment.
[for reviewer] there is no need to maintain an inline and indy variants of this instrumentation, so we only need one that is compatible with both.
| * | ||
| * @return class transformer for defining lambdas | ||
| */ | ||
| public static ClassFileTransformer getLambdaClassFileTransformer() { |
There was a problem hiding this comment.
[for reviewer] this is only used for lambda, and the ClassFileTransformer instances that are used here are very specific to lambda instrumentation, so renaming helps keep it clear.
.../main/java/io/opentelemetry/javaagent/instrumentation/internal/lambda/LambdaTransformer.java
Outdated
Show resolved
Hide resolved
...umentation/kotlinxcoroutines/instrumentationannotations/AnnotationInstrumentationModule.java
Outdated
Show resolved
Hide resolved
…nstrumentation into indy-leftovers
…nstrumentation into indy-leftovers
…nstrumentation into indy-leftovers
...nt/instrumentation/kotlinxcoroutines/instrumentationannotations/WithSpanInstrumentation.java
Outdated
Show resolved
Hide resolved
| // to get a reference to the jpms module. However, a null value must be passed to the | ||
| // underlying transformer as this code is called when the lambda is defined. | ||
| byte[] result = | ||
| transformer.transform( |
There was a problem hiding this comment.
I didn't immediately get why you wanted to change this, but I guess it is to reduce the helper classes and push more logic into the agent code. I think this is good idea and getting rid for the extra module for java9 is nice. What I'd change is that I'd probably also rename ClassFileTransformerHolder as it is only for lambdas as you noted. Also I'd consider not using ClassFileTransformer here. Passing the targetClass argument to the transform method confused me a bit as transform should have the class there only when retransforming/redefining which we aren't doing here. You could have an interface in ClassFileTransformerHolder that takes the necessary arguments. What do you think?
There was a problem hiding this comment.
I agree on the ClassFileTransformerHolder rename as it's definitely only used for lambdas.
I initially tried to simplify the design/API but that requires to introduce a new interface, so I thought maybe keep reusing ClassFileTransformer could be an acceptable compromise, but I agree that it might be a bit confusing as the implementations details leak into the callers as shown by the quantity of comments to use it the way it's intended.
I'll do another attempt by introducing a new interface to see if it helps improve this.
...nt-bootstrap/src/main/java/io/opentelemetry/javaagent/bootstrap/LambdaTransformerHolder.java
Outdated
Show resolved
Hide resolved
...t-tooling-java9/src/main/java/io/opentelemetry/javaagent/tooling/Java9LambdaTransformer.java
Outdated
Show resolved
Hide resolved
javaagent-tooling/src/main/java/io/opentelemetry/javaagent/tooling/Java8LambdaTransformer.java
Outdated
Show resolved
Hide resolved
|
thanks @SylvainJuge @laurit! |
Should be the final step of #11457, hopefully completing it.
There are currently 5 overrides of
isIndyModule()and the goal here is to removeallmost of them, hence allowing to move forward with the next steps described in #13031