Repository navigation
Spring beans are not loaded in managed dependent resource #2166
Description
Bug Report
What did you do?
I'm using josdk-spring-boot-starter to build an operator with a managed dependent resource, something similar to this example. When I inject a spring bean inside the dependent resource, on application startup I noticed that the spring beans were not instantiated and were always null. For example, in this demo application the operator fails due to NPE here
In a nutshell, the whole spring proxied dependent resource was ignored by the operator framework and instead created another instance of the dependent resource.
What did you expect to see?
The expectation from the framework is not to ignore spring proxied beans.
What did you see instead? Under which circumstances?
Spring beans are not instantiated.
Environment
Kubernetes cluster type: vanilla
$ Mention java-operator-sdk version from pom.xml file
Build file is here
implementation 'io.javaoperatorsdk:operator-framework-spring-boot-starter:5.0.0'
annotationProcessor 'io.javaoperatorsdk:operator-framework:4.3.1'
annotationProcessor 'io.fabric8:crd-generator-apt:6.5.1'
$ java -version 17
$ kubectl version
Possible Solution
Additional context
I have a demo application with the similar setup. The tests were failing because of the above mentioned issue.
Activity
csviri commentedon Dec 18, 2023
Hi @rameshmalla ,
The managed dependent resources are not interconnected with spring bean container, basically you cannot do this.
(Also calling an external service during desired is probably not a good idea, this might slow down the reconciliation even if nothing changed)
csviri commentedon Dec 18, 2023
Note that this work in Quarkus extension, if you want to give that a try.
kosmoz commentedon Dec 18, 2023
This is a valid use-case IMO. It is very common to receive configuration properties via Spring DI, for example.
The only way I found to work around this limitation was to create a custom
DependentResourceFactorythat creates the DR instance via the SpringAppicationContext, thus registering it as aBean. It still has to callDependentResourceConfigurationResolver.configurewith the DR instance.The last time I checked, this was not possible when using
josdk-spring-boot-starter, but this was already some time ago so things might have changed in the meantime.csviri commentedon Dec 18, 2023
I mean in general it is a valid use cases to have these beans injected, and have some config params in their.
Was referring to this part:
https://github.com/rameshmalla/demo-operator/blob/be32d49ac2804f23338b74d2ac254cdfda1e41b6/src/main/java/com/example/demo/ConfigMapDependentResource.java#L27
calling an external service while computing a desired. At least would cache the result (with some timeout) for some time on client side so it is not called every time desired is computed (what can be very frequent in some cases ).
csviri commentedon Dec 18, 2023
Only problem is that we don't have the bandwidth for such improvements, if anybody would volunteer to implement it in the SB starter, would be a big help.
rameshmalla commentedon Dec 19, 2023
Thanks, @csviri and @kosmoz for your inputs and suggestions, Indeed quarkus looks like a promising option I will explore the possibilities of migrating from spring-boot to quarkus. Meanwhile I will try to replicate @kosmoz suggestion on having a custom
DependentResourceFactorythat respects spring context.github-actions commentedon Feb 18, 2024
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.
exijn commentedon Aug 3, 2026
Hi, I’d be interested in working on this issue.
I have experience with Spring Boot dependency injection and have previously contributed to Java Operator SDK. Before starting, I’d like to verify whether this is still desired with the current Spring Boot starter architecture.
My initial approach would be to investigate creating managed dependent resources through the Spring ApplicationContext, while preserving the existing behavior for non-Spring usage, and add a focused integration test for bean injection.
Would this still be an acceptable direction for a contribution?
csviri commentedon Aug 3, 2026
Sure, make sense, thank you @hej090224 !
csviri commentedon Aug 3, 2026
@hej090224 any improvement and contribution to SB Starter welcome! Feel free to create issues and PRs. thank you!
exijn commentedon Aug 3, 2026
Thanks for confirming and assigning the issue to me.
I’ll start by adding a focused failing integration test for dependency injection into a managed dependent resource, then investigate the smallest Spring Boot starter change that creates the resource through the Spring ApplicationContext while preserving the existing non-Spring behavior.
I’ll target the
nextbranch based on the current development flow. Please let me know if a different base branch is preferred.feat: create managed dependent resources through Spring (#320)