-
Notifications
You must be signed in to change notification settings - Fork 99
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
v2 libraries require AWS SDK v1.11 to run #92
Comments
Hey, Thank you very much for bringing this to our attention. As of right now, this dependency is required because the X-Ray SDK uses version 1.11 of the AWS SDK to generate a client used for our rule and target poller threads. We aim to have the dependency on v2 of the SDK by the next major version release of our Java SDK. Please stay tuned. Thanks! |
Are there any further updates on this or timelines for when it might be released? |
Hi @annedroiid, We have rewritten the core X-Ray SDK to remove any dependencies on AWS SDK v1 in #145. However, we exposed references to AWS SDK classes in some of our public APIs, and as such we must maintain the dependency until our next major version, since removing it will constitute a breaking change. We can't provide an official timeline on a 3.x release, but the dependency will be removed then. |
Hi @willarmiros, |
@humanzz I sure did! Thanks for catching that. |
Do you have any advice on how to implement generating custom subsegments using only SDK v2? I mean, by adding a bit more library code to one's project, to then use it in their code, before AWS SDK V3 is released? The functionality I mean: https://github.com/aws/aws-xray-sdk-java?tab=readme-ov-file#intercept-custom-methods. |
Given AWS have announced that v1 of the Java SDK is being end-of-lifed in the next 18 months; it would be lovely if this got some love from AWS: https://aws.amazon.com/blogs/developer/announcing-end-of-support-for-aws-sdk-for-java-v1-x-on-december-31-2025/ |
Since #43 this library has provided compatibility with v2 of the standard AWS SDK. However, there are still a large number of dependencies on the (old) v1.11 SDK which means that it's necessary to have both sets of libraries on the classpath for this to work correctly:
potential naming conflicts / code errors arise because a lot of classes are identically named (although in a different package structure)
increases the bulk of applications since we need to bundle jars for both v1.11 and v2 SDKs
additional complications such as having e.g. two sets of connection pools (one maintained by each SDK) which can lead to obscure bugs
Ideally, it would be possible to run using exclusively the v2 SDK: this is potentially quite a big undertaking since it would require rewriting large parts of the
core
package to remove any dependencies or v1.11, or else creating a newcore-v2
project largely as a copy ofcore
and rewriting the necessary parts.The text was updated successfully, but these errors were encountered: