refactor: resolve the informer target client without a downcast - #3548
Conversation
Sorry, something went wrong.
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.
|
Important Review skippedAuto 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 configurationConfiguration 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:
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. ❤️ ShareComment @coderabbitai help to get the list of available commands. |
Sorry, something went wrong.
There was a problem hiding this comment.
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. |
Sorry, something went wrong.
| /** | ||
| * 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
left a comment
There was a problem hiding this comment.
LGTM
Sorry, something went wrong.
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.