feat: automatically derive the the dependent resource type if not specified #2772
Conversation
|
I think we had something similar to this at some point but decided to make it explicit because there were too many cases where the automatic resolution of the type was causing issues (iirc). Having a no-arg constructor might induce people to initialize their dependent resources with it and then get weird exceptions when the automatic resolution fails. |
xstefank
force-pushed
the
default-ctor
branch
3 times, most recently
from
7b69822 to
e03d15f
Compare
|
I changed the logic so it now finds the first generic type in the hierarchy and takes the first parameter. We can take it even further and check that we hit some class for JOSDK but I believe this is enough and it allows us to create a test - see https://github.com/operator-framework/java-operator-sdk/pull/2772/files#diff-f5452835ea6fba16e03d5593e7efdcb2497f78368e84b1aeebf3682a6e5953bc. I agree that this will not cover all use cases but we are not removing the constructor that takes the type so if any user runs into issue with the default derivation of the resource type, they can still override it with anything they want. BTW Chris, this todo inspired me to take a look at this :) https://github.com/quarkiverse/quarkus-operator-sdk/blob/main/samples/exposedapp/src/main/java/io/halkyon/DeploymentDependent.java#L20 |
| @@ -116,4 +126,14 @@ protected void onUpdated(P primary, R updated, R actual, Context<P> context) { | |||
| private RecentOperationCacheFiller<R> recentOperationCacheFiller() { | |||
| return (RecentOperationCacheFiller<R>) eventSource; | |||
| } | |||
|
|
|||
| @SuppressWarnings("unchecked") | |||
| private Class<R> findFirstGenericSuperclass( | |||
There was a problem hiding this comment.
We should throw a meaningful exception when we cannot find the class, could pls add that, also show it works in a unit test?
There was a problem hiding this comment.
@csviri, this is impossible because this class is Abstract, so it must be subclassed, and it takes parameters. So we can never run into a subclass without parameters.
But you made me realize another potential issue, so I updated the PR.
Yeah, the TODO was about to try to generate these constructors automatically in the Quarkus extension because we can know the type for sure in all situations in that case. |
|
Note that we have a whole bunch of methods that already (imperfectly) do this kind of work: https://github.com/operator-framework/java-operator-sdk/blob/main/operator-framework-core/src/main/java/io/javaoperatorsdk/operator/api/config/Utils.java#L119-L233 |
…cified Signed-off-by: xstefank <xstefank122@gmail.com>
Just changing the samples for now. Let me know what you think and I can change all resources or even deprecate some other ctors.