[Entitlements] Fix AbstractDelegateHttpsURLConnection "this" parameter type #124304
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ldematte
added
>non-issue
auto-backport
|
Pinging @elastic/es-core-infra (Team:Core/Infra) |
ldematte
deleted the
entitlements/fix-abstractdelegateurlconnection-signature
branch
ldematte
added a commit
to ldematte/elasticsearch
that referenced
this pull request
Mar 7, 2025
…r type (elastic#124304) Our check methods injected by the instrumenter receive "this" as the second parameter. For internal classes like AbstractDelegateHttpsURLConnection we generally use a base type; in this case we were using javax.net.ssl.HttpsURLConnection, which is incorrect as AbstractDelegateHttpsURLConnection derives from java.net.HttpURLConnection. This was not failing in our tests because we don't actually use that parameter in that check function. Also, it was not failing on transform, just on retransformClasses, and only in JDK 24. Apparently, JDK 24 introduced new validation there (to be confirmed). And it was failing just on cloud as the APM agent there (which is loaded before our agent) connects to a https endpoint - our IT tests, and ./gradlew run --with-apm-server, use a http endpoint. Using https makes the JVM load AbstractDelegateHttpsURLConnection, making it one of the classes we need to retransform, triggering the VerifyError.
elasticsearchmachine
pushed a commit
that referenced
this pull request
Mar 7, 2025
…r type (#124304) (#124316) Our check methods injected by the instrumenter receive "this" as the second parameter. For internal classes like AbstractDelegateHttpsURLConnection we generally use a base type; in this case we were using javax.net.ssl.HttpsURLConnection, which is incorrect as AbstractDelegateHttpsURLConnection derives from java.net.HttpURLConnection. This was not failing in our tests because we don't actually use that parameter in that check function. Also, it was not failing on transform, just on retransformClasses, and only in JDK 24. Apparently, JDK 24 introduced new validation there (to be confirmed). And it was failing just on cloud as the APM agent there (which is loaded before our agent) connects to a https endpoint - our IT tests, and ./gradlew run --with-apm-server, use a http endpoint. Using https makes the JVM load AbstractDelegateHttpsURLConnection, making it one of the classes we need to retransform, triggering the VerifyError.
ldematte
added a commit
to ldematte/elasticsearch
that referenced
this pull request
Mar 7, 2025
…r type (elastic#124304) Our check methods injected by the instrumenter receive "this" as the second parameter. For internal classes like AbstractDelegateHttpsURLConnection we generally use a base type; in this case we were using javax.net.ssl.HttpsURLConnection, which is incorrect as AbstractDelegateHttpsURLConnection derives from java.net.HttpURLConnection. This was not failing in our tests because we don't actually use that parameter in that check function. Also, it was not failing on transform, just on retransformClasses, and only in JDK 24. Apparently, JDK 24 introduced new validation there (to be confirmed). And it was failing just on cloud as the APM agent there (which is loaded before our agent) connects to a https endpoint - our IT tests, and ./gradlew run --with-apm-server, use a http endpoint. Using https makes the JVM load AbstractDelegateHttpsURLConnection, making it one of the classes we need to retransform, triggering the VerifyError.
ldematte
added a commit
to ldematte/elasticsearch
that referenced
this pull request
Mar 7, 2025
…r type (elastic#124304) Our check methods injected by the instrumenter receive "this" as the second parameter. For internal classes like AbstractDelegateHttpsURLConnection we generally use a base type; in this case we were using javax.net.ssl.HttpsURLConnection, which is incorrect as AbstractDelegateHttpsURLConnection derives from java.net.HttpURLConnection. This was not failing in our tests because we don't actually use that parameter in that check function. Also, it was not failing on transform, just on retransformClasses, and only in JDK 24. Apparently, JDK 24 introduced new validation there (to be confirmed). And it was failing just on cloud as the APM agent there (which is loaded before our agent) connects to a https endpoint - our IT tests, and ./gradlew run --with-apm-server, use a http endpoint. Using https makes the JVM load AbstractDelegateHttpsURLConnection, making it one of the classes we need to retransform, triggering the VerifyError.
elasticsearchmachine
pushed a commit
that referenced
this pull request
Mar 7, 2025
…r type (#124304) (#124325) Our check methods injected by the instrumenter receive "this" as the second parameter. For internal classes like AbstractDelegateHttpsURLConnection we generally use a base type; in this case we were using javax.net.ssl.HttpsURLConnection, which is incorrect as AbstractDelegateHttpsURLConnection derives from java.net.HttpURLConnection. This was not failing in our tests because we don't actually use that parameter in that check function. Also, it was not failing on transform, just on retransformClasses, and only in JDK 24. Apparently, JDK 24 introduced new validation there (to be confirmed). And it was failing just on cloud as the APM agent there (which is loaded before our agent) connects to a https endpoint - our IT tests, and ./gradlew run --with-apm-server, use a http endpoint. Using https makes the JVM load AbstractDelegateHttpsURLConnection, making it one of the classes we need to retransform, triggering the VerifyError.
elasticsearchmachine
pushed a commit
that referenced
this pull request
Mar 7, 2025
…r type (#124304) (#124326) Our check methods injected by the instrumenter receive "this" as the second parameter. For internal classes like AbstractDelegateHttpsURLConnection we generally use a base type; in this case we were using javax.net.ssl.HttpsURLConnection, which is incorrect as AbstractDelegateHttpsURLConnection derives from java.net.HttpURLConnection. This was not failing in our tests because we don't actually use that parameter in that check function. Also, it was not failing on transform, just on retransformClasses, and only in JDK 24. Apparently, JDK 24 introduced new validation there (to be confirmed). And it was failing just on cloud as the APM agent there (which is loaded before our agent) connects to a https endpoint - our IT tests, and ./gradlew run --with-apm-server, use a http endpoint. Using https makes the JVM load AbstractDelegateHttpsURLConnection, making it one of the classes we need to retransform, triggering the VerifyError.
georgewallace
pushed a commit
to georgewallace/elasticsearch
that referenced
this pull request
Mar 11, 2025
…r type (elastic#124304) Our check methods injected by the instrumenter receive "this" as the second parameter. For internal classes like AbstractDelegateHttpsURLConnection we generally use a base type; in this case we were using javax.net.ssl.HttpsURLConnection, which is incorrect as AbstractDelegateHttpsURLConnection derives from java.net.HttpURLConnection. This was not failing in our tests because we don't actually use that parameter in that check function. Also, it was not failing on transform, just on retransformClasses, and only in JDK 24. Apparently, JDK 24 introduced new validation there (to be confirmed). And it was failing just on cloud as the APM agent there (which is loaded before our agent) connects to a https endpoint - our IT tests, and ./gradlew run --with-apm-server, use a http endpoint. Using https makes the JVM load AbstractDelegateHttpsURLConnection, making it one of the classes we need to retransform, triggering the VerifyError.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Our check methods injected by the instrumenter receive "this" as the second parameter.
For internal classes like
AbstractDelegateHttpsURLConnectionwe generally use a base type; in this case we were usingjavax.net.ssl.HttpsURLConnection, which is incorrect asAbstractDelegateHttpsURLConnectionderives fromjava.net.HttpURLConnection.This was not failing in our tests because we don't actually use that parameter in that check function.
Also, it was not failing on
transform, just onretransformClasses, and only in JDK 24. Apparently, JDK 24 introduced new validation there (to be confirmed).And it was failing just on cloud as the APM agent there (which is loaded before our agent) connects to a https endpoint - our IT tests, and
./gradlew run --with-apm-server, use a http endpoint. Using https makes the JVM loadAbstractDelegateHttpsURLConnection, making it one of the classes we need to retransform, triggering the VerifyError.