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

Update documentation for upgrading to KCL v2.7.x #1446

Merged
merged 10 commits into from
Mar 12, 2025

Conversation

vincentvilo-aws
Copy link
Contributor

@vincentvilo-aws vincentvilo-aws commented Mar 11, 2025

Issue #, if available:

Description of changes: Update documentation for upgrading to KCL v2.7.x and change KclSTSAssumeRoleSessionCredentialsProvider to KclStsAssumeRoleCredentialsProvider

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@vincentvilo-aws vincentvilo-aws changed the title Fix typo in documentation Update documentation for upgrading to KCL v2.7.x Mar 11, 2025
README.md Outdated
@@ -48,6 +48,9 @@ To make it easier for developers to write record processors in other languages,
## Using the KCL
The recommended way to use the KCL for Java is to consume it from Maven.

## Must read if you are migrating to a version using KCL 2.7 or later
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggesting:

🚨Important: Migration to KCL 2.7 or later with MultiLangDaemon - Credential Provider Changes Required

README.md Outdated
@@ -48,6 +48,9 @@ To make it easier for developers to write record processors in other languages,
## Using the KCL
The recommended way to use the KCL for Java is to consume it from Maven.

## Must read if you are migrating to a version using KCL 2.7 or later
KCL version 2.7.0 and beyond does not use the AWS SDK v1. Because of this, all multilang users upgrading from a prior version must update their multilang `.properties` AwsCredentialsProvider property to an AWS SDK v2 credential provider name. Please see the credentials provider name mapping [here](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/migration-client-credentials.html#credentials-changes-mapping), and reference our Configuring Credential Providers documentation [here](https://github.com/vincentvilo-aws/amazon-kinesis-client/blob/remove-sdk-v1/docs/multilang/configuring-credential-providers.md). If this is not done, your multilang KCL will fail to construct an AwsCredentialsProvider on startup.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

KCL version 2.7.0 and later uses AWS SDK for Java 2.x instead of AWS SDK for Java 1.x. All MultiLangDaemon users upgrading from earlier versions must update their credential provider configuration in the .properties file to use credentials provider name for AWS SDK for Java 2.x. Failure to do this will cause your multilang KCL application to fail during startup with credential provider construction errors. Please check the following link for the credentials provider mapping and MultiLangDaemon credentials provider configuration guide.

@@ -6,6 +6,10 @@ KCL multilang does not, and is not intended to, proxy the full breadth of the AW
However, KCL now provides better extensibility to handle, and be enhanced to handle, additional configurations.
This document should help multilang customers configure a suitable `CredentialProvider` (or contribute changes to support a new use case!).

In KCL versions prior to 2.7, the AWSCredentialsProvider property expected AWS SDK v1 provider names. If you are using
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In KCL versions prior to 2.7, the AWSCredentialsProvider property used AWS SDK for Java 1.x provider names.

@@ -6,6 +6,10 @@ KCL multilang does not, and is not intended to, proxy the full breadth of the AW
However, KCL now provides better extensibility to handle, and be enhanced to handle, additional configurations.
This document should help multilang customers configure a suitable `CredentialProvider` (or contribute changes to support a new use case!).

In KCL versions prior to 2.7, the AWSCredentialsProvider property expected AWS SDK v1 provider names. If you are using
KCL version 2.7 or beyond, ensure that you are passing an AWS SDK v2 credentials provider name to your AwsCredentialsProvider
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When upgrading to KCL 2.7 or later, you must update to use AWS SDK v2 credentials provider names in your configuration.

@@ -6,6 +6,10 @@ KCL multilang does not, and is not intended to, proxy the full breadth of the AW
However, KCL now provides better extensibility to handle, and be enhanced to handle, additional configurations.
This document should help multilang customers configure a suitable `CredentialProvider` (or contribute changes to support a new use case!).

In KCL versions prior to 2.7, the AWSCredentialsProvider property expected AWS SDK v1 provider names. If you are using
KCL version 2.7 or beyond, ensure that you are passing an AWS SDK v2 credentials provider name to your AwsCredentialsProvider
property. See list of providers [here](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/migration-client-credentials.html#credentials-changes-mapping) and several examples below.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For a complete mapping of credential provider names between version 1.x and 2.x, see the AWS SDK for Java migration guide — Credentials provider changes mapped between versions 1.x and 2.x. You also can refer to the following examples.

@vincentvilo-aws vincentvilo-aws merged commit 7ff585e into awslabs:v2.x Mar 12, 2025
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.

2 participants