refactor: resolve the informer target client without a downcast by csviri · Pull Request #3548 · operator-framework/java-operator-sdk

csviri · 2026-08-07T11:55:00Z

InformerManager is generic over C extends Informable, but getTargetClient
type-tested for InformerEventSourceConfiguration to find out whether a specific
(e.g. remote cluster) client was configured. Informable has two implementors
and only one could answer the question, so a third configuration type wanting
its own client would be ignored silently rather than failing to compile.

Move the default getKubernetesClient() up from InformerEventSourceConfiguration
to Informable and let InformerManager ask the configuration directly. The
default still returns Optional.empty(), so existing implementations are
unaffected. As a side effect the ConfigurationService client is now only
created when no specific client is configured, instead of being created and
then discarded.

Quality-only change: no intended behavior difference. Cut from next and
touches a disjoint set of files from the sibling cleanup PRs, so it can be merged
independently and in any order.

Verified on this branch alone: mvn -o -pl operator-framework-core,operator-framework-junit -am test
(693 core + 6 junit tests, no failures) and mvn spotless:check.

InformerManager is generic over C extends Informable, but getTargetClient type-tested for InformerEventSourceConfiguration to find out whether a specific (e.g. remote cluster) client was configured. Informable has two implementors and only one could answer the question, so a third configuration type wanting its own client would be ignored silently rather than failing to compile. Move the default getKubernetesClient() up from InformerEventSourceConfiguration to Informable and let InformerManager ask the configuration directly. The default still returns Optional.empty(), so existing implementations are unaffected. As a side effect the ConfigurationService client is now only created when no specific client is configured, instead of being created and then discarded.

coderabbitai · 2026-08-07T11:55:08Z

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 8bd2ac12-c22a-4858-9b13-755916ce07e2

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

Copilot

Pull request overview

This PR refactors informer target-client resolution so InformerManager can ask the configuration for an optional per-informer KubernetesClient without downcasting to InformerEventSourceConfiguration, improving type-safety and avoiding unnecessary default-client creation.

Changes:

Move the default getKubernetesClient(): Optional<KubernetesClient> method from InformerEventSourceConfiguration to the common Informable interface.
Update InformerManager#getTargetClient() to resolve the client via configuration.getKubernetesClient().orElseGet(...), avoiding eager ConfigurationService client creation.
Remove the now-redundant default method from InformerEventSourceConfiguration while keeping its concrete implementation override.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
operator-framework-core/src/main/java/io/javaoperatorsdk/operator/processing/event/source/informer/InformerManager.java	Removes configuration downcast and lazily resolves the target client via `Informable#getKubernetesClient()`.
operator-framework-core/src/main/java/io/javaoperatorsdk/operator/api/config/informer/InformerEventSourceConfiguration.java	Drops the default `getKubernetesClient()` method (now inherited from `Informable`) while keeping the concrete override.
operator-framework-core/src/main/java/io/javaoperatorsdk/operator/api/config/Informable.java	Introduces the default optional `getKubernetesClient()` hook for all informable configurations.

+ /**
+ * Optional, specific kubernetes client, typically to connect to a different cluster than the rest
+ * of the operator. Note that this is solely for multi cluster support.
+ */


csviri

LGTM

InformerManager is generic over C extends Informable, but getTargetClient type-tested for InformerEventSourceConfiguration to find out whether a specific (e.g. remote cluster) client was configured. Informable has two implementors and only one could answer the question, so a third configuration type wanting its own client would be ignored silently rather than failing to compile. Move the default getKubernetesClient() up from InformerEventSourceConfiguration to Informable and let InformerManager ask the configuration directly. The default still returns Optional.empty(), so existing implementations are unaffected. As a side effect the ConfigurationService client is now only created when no specific client is configured, instead of being created and then discarded.

csviri · 2026-08-07T11:55:00Z

InformerManager is generic over C extends Informable, but getTargetClient
type-tested for InformerEventSourceConfiguration to find out whether a specific
(e.g. remote cluster) client was configured. Informable has two implementors
and only one could answer the question, so a third configuration type wanting
its own client would be ignored silently rather than failing to compile.

Move the default getKubernetesClient() up from InformerEventSourceConfiguration
to Informable and let InformerManager ask the configuration directly. The
default still returns Optional.empty(), so existing implementations are
unaffected. As a side effect the ConfigurationService client is now only
created when no specific client is configured, instead of being created and
then discarded.

Quality-only change: no intended behavior difference. Cut from next and
touches a disjoint set of files from the sibling cleanup PRs, so it can be merged
independently and in any order.

Verified on this branch alone: mvn -o -pl operator-framework-core,operator-framework-junit -am test
(693 core + 6 junit tests, no failures) and mvn spotless:check.

InformerManager is generic over C extends Informable, but getTargetClient type-tested for InformerEventSourceConfiguration to find out whether a specific (e.g. remote cluster) client was configured. Informable has two implementors and only one could answer the question, so a third configuration type wanting its own client would be ignored silently rather than failing to compile. Move the default getKubernetesClient() up from InformerEventSourceConfiguration to Informable and let InformerManager ask the configuration directly. The default still returns Optional.empty(), so existing implementations are unaffected. As a side effect the ConfigurationService client is now only created when no specific client is configured, instead of being created and then discarded.

coderabbitai · 2026-08-07T11:55:08Z

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 8bd2ac12-c22a-4858-9b13-755916ce07e2

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

Copilot

Pull request overview

This PR refactors informer target-client resolution so InformerManager can ask the configuration for an optional per-informer KubernetesClient without downcasting to InformerEventSourceConfiguration, improving type-safety and avoiding unnecessary default-client creation.

Changes:

Move the default getKubernetesClient(): Optional<KubernetesClient> method from InformerEventSourceConfiguration to the common Informable interface.
Update InformerManager#getTargetClient() to resolve the client via configuration.getKubernetesClient().orElseGet(...), avoiding eager ConfigurationService client creation.
Remove the now-redundant default method from InformerEventSourceConfiguration while keeping its concrete implementation override.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
operator-framework-core/src/main/java/io/javaoperatorsdk/operator/processing/event/source/informer/InformerManager.java	Removes configuration downcast and lazily resolves the target client via `Informable#getKubernetesClient()`.
operator-framework-core/src/main/java/io/javaoperatorsdk/operator/api/config/informer/InformerEventSourceConfiguration.java	Drops the default `getKubernetesClient()` method (now inherited from `Informable`) while keeping the concrete override.
operator-framework-core/src/main/java/io/javaoperatorsdk/operator/api/config/Informable.java	Introduces the default optional `getKubernetesClient()` hook for all informable configurations.

+ /**
+ * Optional, specific kubernetes client, typically to connect to a different cluster than the rest
+ * of the operator. Note that this is solely for multi cluster support.
+ */


csviri

LGTM

InformerManager is generic over C extends Informable, but getTargetClient type-tested for InformerEventSourceConfiguration to find out whether a specific (e.g. remote cluster) client was configured. Informable has two implementors and only one could answer the question, so a third configuration type wanting its own client would be ignored silently rather than failing to compile. Move the default getKubernetesClient() up from InformerEventSourceConfiguration to Informable and let InformerManager ask the configuration directly. The default still returns Optional.empty(), so existing implementations are unaffected. As a side effect the ConfigurationService client is now only created when no specific client is configured, instead of being created and then discarded.

csviri · 2026-08-07T11:55:00Z

InformerManager is generic over C extends Informable, but getTargetClient
type-tested for InformerEventSourceConfiguration to find out whether a specific
(e.g. remote cluster) client was configured. Informable has two implementors
and only one could answer the question, so a third configuration type wanting
its own client would be ignored silently rather than failing to compile.

Move the default getKubernetesClient() up from InformerEventSourceConfiguration
to Informable and let InformerManager ask the configuration directly. The
default still returns Optional.empty(), so existing implementations are
unaffected. As a side effect the ConfigurationService client is now only
created when no specific client is configured, instead of being created and
then discarded.

Quality-only change: no intended behavior difference. Cut from next and
touches a disjoint set of files from the sibling cleanup PRs, so it can be merged
independently and in any order.

Verified on this branch alone: mvn -o -pl operator-framework-core,operator-framework-junit -am test
(693 core + 6 junit tests, no failures) and mvn spotless:check.

InformerManager is generic over C extends Informable, but getTargetClient type-tested for InformerEventSourceConfiguration to find out whether a specific (e.g. remote cluster) client was configured. Informable has two implementors and only one could answer the question, so a third configuration type wanting its own client would be ignored silently rather than failing to compile. Move the default getKubernetesClient() up from InformerEventSourceConfiguration to Informable and let InformerManager ask the configuration directly. The default still returns Optional.empty(), so existing implementations are unaffected. As a side effect the ConfigurationService client is now only created when no specific client is configured, instead of being created and then discarded.

coderabbitai · 2026-08-07T11:55:08Z

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 8bd2ac12-c22a-4858-9b13-755916ce07e2

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

Copilot

Pull request overview

This PR refactors informer target-client resolution so InformerManager can ask the configuration for an optional per-informer KubernetesClient without downcasting to InformerEventSourceConfiguration, improving type-safety and avoiding unnecessary default-client creation.

Changes:

Move the default getKubernetesClient(): Optional<KubernetesClient> method from InformerEventSourceConfiguration to the common Informable interface.
Update InformerManager#getTargetClient() to resolve the client via configuration.getKubernetesClient().orElseGet(...), avoiding eager ConfigurationService client creation.
Remove the now-redundant default method from InformerEventSourceConfiguration while keeping its concrete implementation override.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
operator-framework-core/src/main/java/io/javaoperatorsdk/operator/processing/event/source/informer/InformerManager.java	Removes configuration downcast and lazily resolves the target client via `Informable#getKubernetesClient()`.
operator-framework-core/src/main/java/io/javaoperatorsdk/operator/api/config/informer/InformerEventSourceConfiguration.java	Drops the default `getKubernetesClient()` method (now inherited from `Informable`) while keeping the concrete override.
operator-framework-core/src/main/java/io/javaoperatorsdk/operator/api/config/Informable.java	Introduces the default optional `getKubernetesClient()` hook for all informable configurations.

+ /**
+ * Optional, specific kubernetes client, typically to connect to a different cluster than the rest
+ * of the operator. Note that this is solely for multi cluster support.
+ */


csviri

LGTM

InformerManager is generic over C extends Informable, but getTargetClient type-tested for InformerEventSourceConfiguration to find out whether a specific (e.g. remote cluster) client was configured. Informable has two implementors and only one could answer the question, so a third configuration type wanting its own client would be ignored silently rather than failing to compile. Move the default getKubernetesClient() up from InformerEventSourceConfiguration to Informable and let InformerManager ask the configuration directly. The default still returns Optional.empty(), so existing implementations are unaffected. As a side effect the ConfigurationService client is now only created when no specific client is configured, instead of being created and then discarded.

csviri · 2026-08-07T11:55:00Z

InformerManager is generic over C extends Informable, but getTargetClient
type-tested for InformerEventSourceConfiguration to find out whether a specific
(e.g. remote cluster) client was configured. Informable has two implementors
and only one could answer the question, so a third configuration type wanting
its own client would be ignored silently rather than failing to compile.

Move the default getKubernetesClient() up from InformerEventSourceConfiguration
to Informable and let InformerManager ask the configuration directly. The
default still returns Optional.empty(), so existing implementations are
unaffected. As a side effect the ConfigurationService client is now only
created when no specific client is configured, instead of being created and
then discarded.

Quality-only change: no intended behavior difference. Cut from next and
touches a disjoint set of files from the sibling cleanup PRs, so it can be merged
independently and in any order.

Verified on this branch alone: mvn -o -pl operator-framework-core,operator-framework-junit -am test
(693 core + 6 junit tests, no failures) and mvn spotless:check.

InformerManager is generic over C extends Informable, but getTargetClient type-tested for InformerEventSourceConfiguration to find out whether a specific (e.g. remote cluster) client was configured. Informable has two implementors and only one could answer the question, so a third configuration type wanting its own client would be ignored silently rather than failing to compile. Move the default getKubernetesClient() up from InformerEventSourceConfiguration to Informable and let InformerManager ask the configuration directly. The default still returns Optional.empty(), so existing implementations are unaffected. As a side effect the ConfigurationService client is now only created when no specific client is configured, instead of being created and then discarded.

coderabbitai · 2026-08-07T11:55:08Z

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 8bd2ac12-c22a-4858-9b13-755916ce07e2

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

Copilot

Pull request overview

This PR refactors informer target-client resolution so InformerManager can ask the configuration for an optional per-informer KubernetesClient without downcasting to InformerEventSourceConfiguration, improving type-safety and avoiding unnecessary default-client creation.

Changes:

Move the default getKubernetesClient(): Optional<KubernetesClient> method from InformerEventSourceConfiguration to the common Informable interface.
Update InformerManager#getTargetClient() to resolve the client via configuration.getKubernetesClient().orElseGet(...), avoiding eager ConfigurationService client creation.
Remove the now-redundant default method from InformerEventSourceConfiguration while keeping its concrete implementation override.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
operator-framework-core/src/main/java/io/javaoperatorsdk/operator/processing/event/source/informer/InformerManager.java	Removes configuration downcast and lazily resolves the target client via `Informable#getKubernetesClient()`.
operator-framework-core/src/main/java/io/javaoperatorsdk/operator/api/config/informer/InformerEventSourceConfiguration.java	Drops the default `getKubernetesClient()` method (now inherited from `Informable`) while keeping the concrete override.
operator-framework-core/src/main/java/io/javaoperatorsdk/operator/api/config/Informable.java	Introduces the default optional `getKubernetesClient()` hook for all informable configurations.

+ /**
+ * Optional, specific kubernetes client, typically to connect to a different cluster than the rest
+ * of the operator. Note that this is solely for multi cluster support.
+ */


csviri

LGTM

InformerManager is generic over C extends Informable, but getTargetClient type-tested for InformerEventSourceConfiguration to find out whether a specific (e.g. remote cluster) client was configured. Informable has two implementors and only one could answer the question, so a third configuration type wanting its own client would be ignored silently rather than failing to compile. Move the default getKubernetesClient() up from InformerEventSourceConfiguration to Informable and let InformerManager ask the configuration directly. The default still returns Optional.empty(), so existing implementations are unaffected. As a side effect the ConfigurationService client is now only created when no specific client is configured, instead of being created and then discarded.

csviri · 2026-08-07T11:55:00Z

InformerManager is generic over C extends Informable, but getTargetClient
type-tested for InformerEventSourceConfiguration to find out whether a specific
(e.g. remote cluster) client was configured. Informable has two implementors
and only one could answer the question, so a third configuration type wanting
its own client would be ignored silently rather than failing to compile.

Move the default getKubernetesClient() up from InformerEventSourceConfiguration
to Informable and let InformerManager ask the configuration directly. The
default still returns Optional.empty(), so existing implementations are
unaffected. As a side effect the ConfigurationService client is now only
created when no specific client is configured, instead of being created and
then discarded.

Quality-only change: no intended behavior difference. Cut from next and
touches a disjoint set of files from the sibling cleanup PRs, so it can be merged
independently and in any order.

Verified on this branch alone: mvn -o -pl operator-framework-core,operator-framework-junit -am test
(693 core + 6 junit tests, no failures) and mvn spotless:check.

InformerManager is generic over C extends Informable, but getTargetClient type-tested for InformerEventSourceConfiguration to find out whether a specific (e.g. remote cluster) client was configured. Informable has two implementors and only one could answer the question, so a third configuration type wanting its own client would be ignored silently rather than failing to compile. Move the default getKubernetesClient() up from InformerEventSourceConfiguration to Informable and let InformerManager ask the configuration directly. The default still returns Optional.empty(), so existing implementations are unaffected. As a side effect the ConfigurationService client is now only created when no specific client is configured, instead of being created and then discarded.

coderabbitai · 2026-08-07T11:55:08Z

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 8bd2ac12-c22a-4858-9b13-755916ce07e2

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

Copilot

Pull request overview

This PR refactors informer target-client resolution so InformerManager can ask the configuration for an optional per-informer KubernetesClient without downcasting to InformerEventSourceConfiguration, improving type-safety and avoiding unnecessary default-client creation.

Changes:

Move the default getKubernetesClient(): Optional<KubernetesClient> method from InformerEventSourceConfiguration to the common Informable interface.
Update InformerManager#getTargetClient() to resolve the client via configuration.getKubernetesClient().orElseGet(...), avoiding eager ConfigurationService client creation.
Remove the now-redundant default method from InformerEventSourceConfiguration while keeping its concrete implementation override.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
operator-framework-core/src/main/java/io/javaoperatorsdk/operator/processing/event/source/informer/InformerManager.java	Removes configuration downcast and lazily resolves the target client via `Informable#getKubernetesClient()`.
operator-framework-core/src/main/java/io/javaoperatorsdk/operator/api/config/informer/InformerEventSourceConfiguration.java	Drops the default `getKubernetesClient()` method (now inherited from `Informable`) while keeping the concrete override.
operator-framework-core/src/main/java/io/javaoperatorsdk/operator/api/config/Informable.java	Introduces the default optional `getKubernetesClient()` hook for all informable configurations.

+ /**
+ * Optional, specific kubernetes client, typically to connect to a different cluster than the rest
+ * of the operator. Note that this is solely for multi cluster support.
+ */


csviri

LGTM

InformerManager is generic over C extends Informable, but getTargetClient type-tested for InformerEventSourceConfiguration to find out whether a specific (e.g. remote cluster) client was configured. Informable has two implementors and only one could answer the question, so a third configuration type wanting its own client would be ignored silently rather than failing to compile. Move the default getKubernetesClient() up from InformerEventSourceConfiguration to Informable and let InformerManager ask the configuration directly. The default still returns Optional.empty(), so existing implementations are unaffected. As a side effect the ConfigurationService client is now only created when no specific client is configured, instead of being created and then discarded.

csviri · 2026-08-07T11:55:00Z

InformerManager is generic over C extends Informable, but getTargetClient
type-tested for InformerEventSourceConfiguration to find out whether a specific
(e.g. remote cluster) client was configured. Informable has two implementors
and only one could answer the question, so a third configuration type wanting
its own client would be ignored silently rather than failing to compile.

Move the default getKubernetesClient() up from InformerEventSourceConfiguration
to Informable and let InformerManager ask the configuration directly. The
default still returns Optional.empty(), so existing implementations are
unaffected. As a side effect the ConfigurationService client is now only
created when no specific client is configured, instead of being created and
then discarded.

Quality-only change: no intended behavior difference. Cut from next and
touches a disjoint set of files from the sibling cleanup PRs, so it can be merged
independently and in any order.

Verified on this branch alone: mvn -o -pl operator-framework-core,operator-framework-junit -am test
(693 core + 6 junit tests, no failures) and mvn spotless:check.

InformerManager is generic over C extends Informable, but getTargetClient type-tested for InformerEventSourceConfiguration to find out whether a specific (e.g. remote cluster) client was configured. Informable has two implementors and only one could answer the question, so a third configuration type wanting its own client would be ignored silently rather than failing to compile. Move the default getKubernetesClient() up from InformerEventSourceConfiguration to Informable and let InformerManager ask the configuration directly. The default still returns Optional.empty(), so existing implementations are unaffected. As a side effect the ConfigurationService client is now only created when no specific client is configured, instead of being created and then discarded.

coderabbitai · 2026-08-07T11:55:08Z

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 8bd2ac12-c22a-4858-9b13-755916ce07e2

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

Copilot

Pull request overview

This PR refactors informer target-client resolution so InformerManager can ask the configuration for an optional per-informer KubernetesClient without downcasting to InformerEventSourceConfiguration, improving type-safety and avoiding unnecessary default-client creation.

Changes:

Move the default getKubernetesClient(): Optional<KubernetesClient> method from InformerEventSourceConfiguration to the common Informable interface.
Update InformerManager#getTargetClient() to resolve the client via configuration.getKubernetesClient().orElseGet(...), avoiding eager ConfigurationService client creation.
Remove the now-redundant default method from InformerEventSourceConfiguration while keeping its concrete implementation override.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
operator-framework-core/src/main/java/io/javaoperatorsdk/operator/processing/event/source/informer/InformerManager.java	Removes configuration downcast and lazily resolves the target client via `Informable#getKubernetesClient()`.
operator-framework-core/src/main/java/io/javaoperatorsdk/operator/api/config/informer/InformerEventSourceConfiguration.java	Drops the default `getKubernetesClient()` method (now inherited from `Informable`) while keeping the concrete override.
operator-framework-core/src/main/java/io/javaoperatorsdk/operator/api/config/Informable.java	Introduces the default optional `getKubernetesClient()` hook for all informable configurations.

+ /**
+ * Optional, specific kubernetes client, typically to connect to a different cluster than the rest
+ * of the operator. Note that this is solely for multi cluster support.
+ */


csviri

LGTM

InformerManager is generic over C extends Informable, but getTargetClient type-tested for InformerEventSourceConfiguration to find out whether a specific (e.g. remote cluster) client was configured. Informable has two implementors and only one could answer the question, so a third configuration type wanting its own client would be ignored silently rather than failing to compile. Move the default getKubernetesClient() up from InformerEventSourceConfiguration to Informable and let InformerManager ask the configuration directly. The default still returns Optional.empty(), so existing implementations are unaffected. As a side effect the ConfigurationService client is now only created when no specific client is configured, instead of being created and then discarded.

csviri · 2026-08-07T11:55:00Z

InformerManager is generic over C extends Informable, but getTargetClient
type-tested for InformerEventSourceConfiguration to find out whether a specific
(e.g. remote cluster) client was configured. Informable has two implementors
and only one could answer the question, so a third configuration type wanting
its own client would be ignored silently rather than failing to compile.

Move the default getKubernetesClient() up from InformerEventSourceConfiguration
to Informable and let InformerManager ask the configuration directly. The
default still returns Optional.empty(), so existing implementations are
unaffected. As a side effect the ConfigurationService client is now only
created when no specific client is configured, instead of being created and
then discarded.

Quality-only change: no intended behavior difference. Cut from next and
touches a disjoint set of files from the sibling cleanup PRs, so it can be merged
independently and in any order.

Verified on this branch alone: mvn -o -pl operator-framework-core,operator-framework-junit -am test
(693 core + 6 junit tests, no failures) and mvn spotless:check.

InformerManager is generic over C extends Informable, but getTargetClient type-tested for InformerEventSourceConfiguration to find out whether a specific (e.g. remote cluster) client was configured. Informable has two implementors and only one could answer the question, so a third configuration type wanting its own client would be ignored silently rather than failing to compile. Move the default getKubernetesClient() up from InformerEventSourceConfiguration to Informable and let InformerManager ask the configuration directly. The default still returns Optional.empty(), so existing implementations are unaffected. As a side effect the ConfigurationService client is now only created when no specific client is configured, instead of being created and then discarded.

coderabbitai · 2026-08-07T11:55:08Z

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 8bd2ac12-c22a-4858-9b13-755916ce07e2

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

Copilot

Pull request overview

This PR refactors informer target-client resolution so InformerManager can ask the configuration for an optional per-informer KubernetesClient without downcasting to InformerEventSourceConfiguration, improving type-safety and avoiding unnecessary default-client creation.

Changes:

Move the default getKubernetesClient(): Optional<KubernetesClient> method from InformerEventSourceConfiguration to the common Informable interface.
Update InformerManager#getTargetClient() to resolve the client via configuration.getKubernetesClient().orElseGet(...), avoiding eager ConfigurationService client creation.
Remove the now-redundant default method from InformerEventSourceConfiguration while keeping its concrete implementation override.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
operator-framework-core/src/main/java/io/javaoperatorsdk/operator/processing/event/source/informer/InformerManager.java	Removes configuration downcast and lazily resolves the target client via `Informable#getKubernetesClient()`.
operator-framework-core/src/main/java/io/javaoperatorsdk/operator/api/config/informer/InformerEventSourceConfiguration.java	Drops the default `getKubernetesClient()` method (now inherited from `Informable`) while keeping the concrete override.
operator-framework-core/src/main/java/io/javaoperatorsdk/operator/api/config/Informable.java	Introduces the default optional `getKubernetesClient()` hook for all informable configurations.

+ /**
+ * Optional, specific kubernetes client, typically to connect to a different cluster than the rest
+ * of the operator. Note that this is solely for multi cluster support.
+ */


csviri

LGTM

InformerManager is generic over C extends Informable, but getTargetClient type-tested for InformerEventSourceConfiguration to find out whether a specific (e.g. remote cluster) client was configured. Informable has two implementors and only one could answer the question, so a third configuration type wanting its own client would be ignored silently rather than failing to compile. Move the default getKubernetesClient() up from InformerEventSourceConfiguration to Informable and let InformerManager ask the configuration directly. The default still returns Optional.empty(), so existing implementations are unaffected. As a side effect the ConfigurationService client is now only created when no specific client is configured, instead of being created and then discarded.

csviri · 2026-08-07T11:55:00Z

InformerManager is generic over C extends Informable, but getTargetClient
type-tested for InformerEventSourceConfiguration to find out whether a specific
(e.g. remote cluster) client was configured. Informable has two implementors
and only one could answer the question, so a third configuration type wanting
its own client would be ignored silently rather than failing to compile.

Move the default getKubernetesClient() up from InformerEventSourceConfiguration
to Informable and let InformerManager ask the configuration directly. The
default still returns Optional.empty(), so existing implementations are
unaffected. As a side effect the ConfigurationService client is now only
created when no specific client is configured, instead of being created and
then discarded.

Quality-only change: no intended behavior difference. Cut from next and
touches a disjoint set of files from the sibling cleanup PRs, so it can be merged
independently and in any order.

Verified on this branch alone: mvn -o -pl operator-framework-core,operator-framework-junit -am test
(693 core + 6 junit tests, no failures) and mvn spotless:check.

InformerManager is generic over C extends Informable, but getTargetClient type-tested for InformerEventSourceConfiguration to find out whether a specific (e.g. remote cluster) client was configured. Informable has two implementors and only one could answer the question, so a third configuration type wanting its own client would be ignored silently rather than failing to compile. Move the default getKubernetesClient() up from InformerEventSourceConfiguration to Informable and let InformerManager ask the configuration directly. The default still returns Optional.empty(), so existing implementations are unaffected. As a side effect the ConfigurationService client is now only created when no specific client is configured, instead of being created and then discarded.

coderabbitai · 2026-08-07T11:55:08Z

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 8bd2ac12-c22a-4858-9b13-755916ce07e2

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

Copilot

Pull request overview

This PR refactors informer target-client resolution so InformerManager can ask the configuration for an optional per-informer KubernetesClient without downcasting to InformerEventSourceConfiguration, improving type-safety and avoiding unnecessary default-client creation.

Changes:

Move the default getKubernetesClient(): Optional<KubernetesClient> method from InformerEventSourceConfiguration to the common Informable interface.
Update InformerManager#getTargetClient() to resolve the client via configuration.getKubernetesClient().orElseGet(...), avoiding eager ConfigurationService client creation.
Remove the now-redundant default method from InformerEventSourceConfiguration while keeping its concrete implementation override.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
operator-framework-core/src/main/java/io/javaoperatorsdk/operator/processing/event/source/informer/InformerManager.java	Removes configuration downcast and lazily resolves the target client via `Informable#getKubernetesClient()`.
operator-framework-core/src/main/java/io/javaoperatorsdk/operator/api/config/informer/InformerEventSourceConfiguration.java	Drops the default `getKubernetesClient()` method (now inherited from `Informable`) while keeping the concrete override.
operator-framework-core/src/main/java/io/javaoperatorsdk/operator/api/config/Informable.java	Introduces the default optional `getKubernetesClient()` hook for all informable configurations.

+ /**
+ * Optional, specific kubernetes client, typically to connect to a different cluster than the rest
+ * of the operator. Note that this is solely for multi cluster support.
+ */


csviri

LGTM

InformerManager is generic over C extends Informable, but getTargetClient type-tested for InformerEventSourceConfiguration to find out whether a specific (e.g. remote cluster) client was configured. Informable has two implementors and only one could answer the question, so a third configuration type wanting its own client would be ignored silently rather than failing to compile. Move the default getKubernetesClient() up from InformerEventSourceConfiguration to Informable and let InformerManager ask the configuration directly. The default still returns Optional.empty(), so existing implementations are unaffected. As a side effect the ConfigurationService client is now only created when no specific client is configured, instead of being created and then discarded.

CopilotAI lite review requested due to automatic review settings August 7, 2026 11:55