Skip to content

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

Closed
wants to merge 1 commit into from
Closed

test(mysql-schema): refactor with standalone dependent resource #267

wants to merge 1 commit into from

Conversation

scrocquesel
Copy link
Member

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.

Comment on lines +68 to +76
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];
}
}
Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Member Author

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.

@metacosm
Copy link
Member

I will take a look but note that we need to support the latest version of the dependent support first :)

@scrocquesel
Copy link
Member Author

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' ?

@metacosm
Copy link
Member

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.

@scrocquesel
Copy link
Member Author

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.
Should I push a version with the @dependent annotation even if not working due to CDI unsupported ?

@metacosm
Copy link
Member

I tried to use the annotation syntax but JOSDK DependentResourceManager is not CDI aware, so this is only using dependent resource in standalone mode.

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 implementations i.e. you shouldn't need to @Inject them because everything should be managed. Could you elaborate on what you need to do in this use case, please?

@scrocquesel
Copy link
Member Author

I tried to use the annotation syntax but JOSDK DependentResourceManager is not CDI aware, so this is only using dependent resource in standalone mode.

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 implementations i.e. you shouldn't need to @Inject them because everything should be managed. Could you elaborate on what you need to do in this use case, please?

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants