Skip to main content
Cloud Adapter preserves the AWS service model at the application boundary. Your Java code keeps using AWS request and response types; the client factory selects the adapter endpoint. This example uses AWS SDK for Java 2.x and S3. Check S3 service coverage for the target environment and operations your application uses.

Start a local adapter

This guide’s bounded example uses S3 backed by Google Cloud Storage:
1

Install or update the Tensor9 CLI

Install the customer CLI with Homebrew, then confirm the binary is available:
If tensor9 is already installed, run brew upgrade tensor9 instead of the install command.
2

Authenticate with Tensor9

A Tensor9 API key is required. Use the key issued during onboarding, or email [email protected] to request one for your organization. Do not share your account or key with another customer or organization.If your secret manager has already supplied T9_API_KEY, skip the prompt. Otherwise, enter your key at a hidden prompt in the terminal where you will run tensor9:
Check that the variable is set without printing it, then verify your Tensor9 identity:
Confirm that the reported identity belongs to the intended customer account. Do not continue if authentication fails or the account is wrong. Keep shell tracing disabled while using the key. Do not paste the key into commands, shell profiles, source files, screenshots or support messages.See Install and Authenticate for the planned license lifecycle, entitlements and credential boundaries.
3

Inspect the S3 to Google Cloud Storage mapping

Ask Tensor9 to describe the exact directed service mapping used by this guide:
Read the supported S3 operations and Google Cloud Storage limitations before starting the process. The mapping is directional: this command describes S3 requests adapted to Google Cloud Storage, not the reverse direction.
4

Prepare Google Cloud access

Authenticate with Google Cloud using its standard Application Default Credentials chain. The adapter uses that identity when it calls Google Cloud Storage.Use a dedicated test project and narrowly scoped credentials. Do not put credentials in the command line, source code, or screenshots.
5

Start the S3 service adapter

Run the S3 to Google Cloud Storage adapter as a foreground process:
Leave this terminal open. This is the current foreground launcher, not the pending Docker launcher for local development mode. It calls your actual target-cloud services; it is separate from the in-memory emulator. Acquisition and license renewal require Tensor9 authentication. Keep the endpoint local to your test.
6

Copy the listening endpoint

When the command reports its listening endpoint, copy that exact value into a second terminal:
Keep the endpoint local to the test unless you have deliberately configured network access and authentication for another machine.
7

Run one bounded S3 request

Continue with this page’s client or tool instructions. Point only S3 at T9_CLOUD_ADAPTER_ENDPOINT, then perform one operation whose Google Cloud Storage effect you can verify independently.Check both sides: read the S3-shaped response and inspect the native object or bucket in Google Cloud Storage. A successful client response alone does not prove that the target state is correct.
8

Stop the local adapter

Return to the first terminal and press Control-C. Confirm the process exits before deleting the test object or bucket with Google Cloud’s native client.If the request failed, preserve the request ID, adapter endpoint, S3 operation name, Google Cloud request ID, and any x-t9-explain-* receipt headers before stopping the process.

Choose how to set the endpoint

Set it for the process

The AWS-standard S3 environment variable applies to every S3 client created by a supported SDK in this process:
Build the client normally and omit endpointOverride:

Set it on one client

Keep endpoint selection in one factory rather than scattering it through business logic.
endpointOverride changes where the AWS request is sent. It does not change the service model, add unsupported operations, or provide credentials to the target service. Backend credentials stay in the service adapter configuration. An explicit client override takes precedence over AWS_ENDPOINT_URL_S3. Choose one approach for a client factory so configuration remains easy to audit. For SDK 1.x, use AmazonS3ClientBuilder with an endpoint configuration and path-style access. Do not mix 1.x and 2.x configuration examples in the same client factory.

Verify a lifecycle

Use a unique key and a small payload:
Verify the object in the target service after putObject, not only through the adapter. That catches name, region, metadata, and identity mistakes that an origin-shaped response alone may hide.

Preserve failure evidence

Catch service and transport failures separately:
Do not automatically retry a timed-out mutation until you have checked target state and the operation’s idempotency. Retain the SDK request ID and Cloud Adapter diagnostic headers in structured logs, while excluding credentials and payload bodies.

Explain one SDK request

For a difficult request, add a signed per-request x-t9-explain control and retain the returned report ID. ExecuteAndExplain performs the operation and preserves the ordinary SDK response; explicit Explain does not perform it and returns a diagnostic document that needs explanation-aware handling. The complete Explaining SDK Requests guide shows:
  • the Java 2.x request override, applied before SigV4 signing;
  • the exact mode and format values;
  • success, service-error and no-response handling;
  • report retrieval without replaying the original operation;
  • report-owner acknowledgment and out-of-band evidence sharing.
Do not use x-t9-explain: true for a dry run: that shorthand selects ExecuteAndExplain in Human format.

Production client checklist

  • Make endpoint, origin region, and credential provider explicit.
  • Bound connection, request, and retry timeouts for the target path.
  • Reuse the client; do not create one per request.
  • Test the exact paginator, waiter, conditional request, and multipart features the application uses.
  • Keep AWS-origin credentials separate from the adapter’s target-cloud identity.
  • Run an expected not-found or validation error to verify error translation.
For a deeper failure, preserve the SDK request ID and follow Debugging Your Adapters.