Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add instrumentation for jaxws metro 3.0+ #9705

Merged
merged 10 commits into from
Oct 27, 2023
Merged

Conversation

philsttr
Copy link
Contributor

@philsttr philsttr commented Oct 18, 2023

Previously, only jaxws metro 2.2 was instrumented, which only worked with Java EE (javax namespace). Now, jaxws metro 3.0+ is also instrumented, which works with Jakarta EE (jakarta namespace).

Rather than copy/pasting the metro 2.2 instrumentation implementation to a new metro 3.0 module, I made the existing module able to work with both Java EE and Jakarta EE classes.

More specifically, I

  • moved the instrumentation implementation from jaxws-2.0-metro-2.2 to jaxws-metro-2.2 since "jaxws-2.0" is specific to Java EE.
    • Renamed MetroServerSpanNaming to MetroServerSpanNameUpdater, and made it work with both Java EE and Jakarta EE based on what is available on the runtime classpath.
  • moved the Java EE specific tests from jaxws-2.0-metro-2.2 to jaxws-2.0-metro-2.2-testing
  • added new Jakarta EE specific tests in jaxws-3.0-metro-2.2-testing. This is basically a copy/paste of the tests from jaxws-2.0-metro-2.2-testing, but using Jakarta EE namespacing.
  • added the jaxws-3.0-common-testing module for reusable Jakarta EE tests for other future jaxws instrumentation implementations. This is basically a copy/paste of jaxws-2.0-common-testing, but using Jakarta EE namespacing.

The end result is the following submodules:

  • Implementation submodule (no tests. works with both Java EE and Jakarta EE)
    • jaxws-metro-2.2/javaagent
  • Testing submodules for Java EE
    • jaxws-2.0-common-testing
    • jaxws-2.0-metro-2.2-testing
  • Testing submodules for Jakarta EE
    • jaxws-3.0-common-testing
    • jaxws-3.0-metro-2.2-testing

Regarding the implementation of MetroServerSpanNameUpdater, I originally added compile time dependencies on both jakarta.servlet-api and javax.servlet-api, and referenced both of their classes directly in the code, although guarded to make sure things would still work if they weren't on the runtime classpath. Unfortunately, muzzle would disable the instrumentation if either was not found at runtime. Therefore, I had to refactor the code a bit to only use reflection to access the classes. This way muzzle won't disable the instrumentation if either is not found.

This is related to #9569, but specific to the metro runtime, rather than at the annotated @WebService level.

@philsttr philsttr requested a review from a team as a code owner October 18, 2023 12:59
@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented Oct 18, 2023

CLA Signed

The committers listed above are authorized under a signed CLA.

Previously, only jaxws metro 2.2 was instrumented, which only worked with Java EE (javax namespace).
Now, jaxws metro 3.0+ is also instrumented, which works with Jakarta EE (jakarta namespace).

Rather than copy/pasting the metro 2.2 instrumentation implementation to a new metro 3.0 module,
I made the existing module able to work with both Java EE and Jakarta EE classes.

More specifically, I
* moved the instrumentation implementation from `jaxws-2.0-metro-2.2` to `jaxws-metro-2.2` since "jaxws-2.0" is specific to Java EE.
  * Renamed `MetroServerSpanNaming` to `MetroServerSpanNameUpdater`, and made it work with both Java EE and Jakarta EE based on what is available on the runtime classpath.
* moved the Java EE specific tests from `jaxws-2.0-metro-2.2` to `jaxws-2.0-metro-2.2-testing`
* added new Jakarta EE specific tests in `jaxws-3.0-metro-2.2-testing`.
  This is basically a copy/paste of the tests from `jaxws-2.0-metro-2.2-testing`, but using Jakarta EE namespacing.
* added the `jaxws-3.0-common-testing` module for reusable Jakarta EE tests for other future jaxws instrumentation implementations.
  This is basically a copy/paste of `jaxws-2.0-common-testing`, but using Jakarta EE namespacing.

Regarding the implementation of `MetroServerSpanNameUpdater`, I originally added compile time dependencies on both `jakarta.servlet-api` and `javax.servlet-api`, and referenced both of their classes directly in the code, although guarded to make sure things would still work if they weren't on the runtime classpath.  Unfortunately, muzzle would disable the instrumentation if either was not found at runtime.  Therefore, I had to refactor the code a bit to only use reflection to access the classes.  This way muzzle won't disable the instrumentation if either is not found.

This is related to open-telemetry#9569, but specific to the metro runtime, rather than at the annotated `@WebService` level.
@philsttr
Copy link
Contributor Author

The test failure for testLatestDeps2 is unrelated to the changes in this PR..

2023-10-18T14:46:33.6071138Z 
2023-10-18T14:46:33.6071317Z * What went wrong:
2023-10-18T14:46:33.6072693Z Execution failed for task ':instrumentation:redisson:redisson-3.17:javaagent:test'.
2023-10-18T14:46:33.6075144Z > There were failing tests. See the report at: file:///home/runner/work/opentelemetry-java-instrumentation/opentelemetry-java-instrumentation/instrumentation/redisson/redisson-3.17/javaagent/build/reports/tests/test/index.html

@laurit
Copy link
Contributor

laurit commented Oct 23, 2023

@philsttr See https://scans.gradle.com/s/rne277nvrcpo6/tests/task/:instrumentation:jaxws:jaxws-2.0-metro-2.2-testing:test/details/MetroJaxWsTest?top-execution=1 for the case of the test failure with jdk8. You probably need

// early versions of streambuffer depend on latest release of org.jvnet.staxex:stax-ex
// which doesn't work with java 8
library("com.sun.xml.stream.buffer:streambuffer:1.4")

Tests were moved to other submodules, so the test config is no longer needed in jaxws-metro-2.2
@philsttr
Copy link
Contributor Author

What is the next step to get this merged?

@trask trask merged commit dc975b7 into open-telemetry:main Oct 27, 2023
47 checks passed
@philsttr philsttr deleted the metro_30 branch October 27, 2023 16:54
Abhishekkr3003 pushed a commit to Abhishekkr3003/opentelemetry-java-instrumentation that referenced this pull request Nov 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants