-
Notifications
You must be signed in to change notification settings - Fork 52
test(mysql-schema): refactor with standalone dependent resource #267
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
protected Class<Secret> resourceType() { | ||
java.lang.reflect.Type type = getClass().getGenericSuperclass(); | ||
if (type instanceof Class<?>) { | ||
type = ((Class<?>) type).getGenericSuperclass(); | ||
} | ||
|
||
return (Class<Secret>) ((java.lang.reflect.ParameterizedType) type).getActualTypeArguments()[0]; | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is mandatory because actual implementation of JOSDK Utils.getFirstTypeArgumentFromExtendedClass
is not aware of proxy class when using Bean.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why aren't you returning Secret.class
directly? The reflection is only used in the SDK to provide a default (though flawed) implementation. If you're providing an implementation of that method, you might as well return the actual type that we want, which in this case is Secret.class
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I was trying to find a generic solution to be included in the SDK. I don't feel very comfortable having quarkus user override the resourceType when it is already set in every generic parameter. Too bad java don't allow to return R.class
.
I will take a look but note that we need to support the latest version of the dependent support first :) |
What do you mean by 'the latest version of the dependent support first' ? |
We needed #271 to be merged so that the latest version of the SDK API was used. |
Yep, that's what I was missing. By far out of my reach. |
Actually, I'm not sure what you're trying to accomplish with the annotations and CDI. If you use the annotations, you shouldn't need to get a reference to the |
DependentResource can have injected dependencies themself, that's why declarative mode should support CDI. #281 should allow to move the injected dependent resources in the reconciler to annotations. I close this PR and create one on cdi-dependents branch. |
First step to raise issue with DepedentResource integration in Quarkus.
I tried to use the annotation syntax but JOSDK
DependentResourceManager
is not CDI aware, so this is only using dependent resource in standalone mode.