ProjectRequestHandler is registered as handler for Project

[Obirah]

After updating from the client version 4.10.2 to 4.11.0 I'm experiencing the following bug:

I'm using the client to create all resources of a KubernetesList in the following way:
client.resourceList(resources).createOrReplace()

The list also contains one resource of the kind "Project" and apiGroup "project.openshift.io/v1". When it's the project's turn to be created, I get the following error with new version of the client while it worked with the old one: class io.fabric8.openshift.api.model.Project cannot be cast to class io.fabric8.openshift.api.model.ProjectRequest.

I think the culprit lies somewhere in the resuscitation of the ProjectRequestHandler and I'd like to verify that. In this line I guess return Project.class.getSimpleName(); might need to be replaced with return ProjectRequest.class.getSimpleName();.

With the way the ProjectRequestHandler is written now, a call to Handlers.get("Project", "project.openshift.io/v1") will return the ProjectRequestHandler instead of the ProjectHandler and after that the erroneous cast happens. That's exactly what happens in the "acceptVisitors" method of NamespaceVisitFromServerGetWatchDeleteRecreateWaitApplicableListImpl after the wrong handler is returned.

[rohanKanojia]

@Obirah : ah, we added it recently in #2303 , looks like we missed it during review. Would you like to create a PR to fix this?

[rohanKanojia]

Strange, Did it use to work for you earlier? I see that in older versions of client it's set to Project.class.getSimpleName() https://github.com/fabric8io/kubernetes-client/blob/v3.0.1/openshift-client/src/main/java/io/fabric8/openshift/client/handlers/ProjectRequestHandler.java#L40

[Obirah]

It worked for me in 4.10.2, yes.

Was there maybe a change that caused the registration order of the handlers to change? Maybe the registration of the ProjectHandler superseded the registration of the ProjectRequestHandler before and now the order might be the other way around. With the RESOURCE_HANDLER_MAP in the Handlers class, for me it looks like there can never be two handlers with the same ResourceHandler.Key.

[Obirah]

Hi @rohanKanojia, how do we proceed with this? Shall create a PR with my suggested change or does this need another solution?

[rohanKanojia]

You mean replacing Project.class with Project request.class? Yes, please go ahead and create PR 👍