Private configuration classes cause trouble with Java native (reflection)

[manusa]

From quarkusio/quarkus#30153

Some configuration classes (referenced issue is about ExecConfig but maybe there are more) have private access and need to be referenced by name in order to register them for reflection with GraalVM.

These classes should be exposed. In addition, it would be interesting to catalog these classes with an interface or something else, so that they can be automatically detected (Jandex) to be registered when used.

[rohanKanojia]

At the moment I see these private classes in KubernetesClient related modules:

• Config.ExecCredential
  fix (kubernetes-client-api) : Make Config's ExecCredential nested classes public (#4724) #4879
• Config.ExecCredentialSpec
  fix (kubernetes-client-api) : Make Config's ExecCredential nested classes public (#4724) #4879
• Config.ExecCredentialStatus
  fix (kubernetes-client-api) : Make Config's ExecCredential nested classes public (#4724) #4879
• HttpClientUtils.HeaderInterceptor
• RunOperations.RunConfigNestedImpl
• URLFromNodePortImpl.NodePortUrlComponents
• KubernetesClientException.RequestMetadata
• Readiness.ReadinessHolder
• BackwardsCompatibilityInterceptor.ResourceKey
• PatchUtils.SingletonHolder

Do you think it makes sense to make these public?

• Config.ExecCredential
• Config.ExecCredentialSpec
• Config.ExecCredentialStatus

[rohanKanojia]

@manusa : What else needs to be done in order to close this issue? I didn't add any interface because there were only three classes.

[manusa]

@manusa : What else needs to be done in order to close this issue? I didn't add any interface because there were only three classes.

You did list a few other classes too in your comment. Are those classes accessible by users? are they susceptible to be serialized/deserialized?

[rohanKanojia]

They are private static classes but they are not configuration classes. I don't think it makes sense to make them accessible to users.

[manusa]

are they susceptible to be serialized/deserialized? ----> Are they accessible from Config?

[rohanKanojia]

No, these classes do not seem to be accessible from io.fabric8.kubernetes.client.Config

[manusa]

I'm leaving the issue open to update the Quarkus references once 6.5.0 is released

[manusa]

Addressed in Quarkus with quarkusio/quarkus#31781. Closing issue.

[tomslot]

Still occurring with the latest lib version (6.8.0), only when run on Java 17, works well on Java 11

[rohanKanojia]

@tomslot : What error are you getting? Is it with the same classes? Is it possible to share a reproducer?

[rohanKanojia]

@tomslot : Shall we move this conversation to a new issue or reopen this one?

[tomslot]

The bug is located in io.fabric8.kubernetes.client.Config.getExecCredentialFromExecConfig():
The library is trying to parse a plain string error message output from ProcessBuilder as ExecCredential json.
The ProcessBuilder is executing the following command:
/usr/local/bin/aws --region XXX eks get-token --cluster-name YYY --output json

And the output is

"The SSO session associated with this profile has expired or is otherwise invalid. To refresh this SSO session run aws sso login with the corresponding profile."

Feel free to create a new ticket if it serves your process better.

[tomslot]

probably with Java 11 the string is parsed to null and with Java 17 it throws an exception

[rohanKanojia]

@tomslot : Sorry but from your comment, I think it's a different issue from this one. Is it possible to create a new ticket?

[tomslot]

I've just created #5361.
I got here from another ticket, which described my problem and was a supposed duplicate of this issue.