fix #4590: only using a builder if there are visitors

[shawkins]

Description

Fixes #4590 - the namespace modification is no longer needed in the NamespaceVisitFromServerGetWatchDeleteRecreateWaitApplicableListImpl because the logic in resource(item) will already handle that. This removes the need to construct a builder for just simple operations.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• Feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change
• Chore (non-breaking change which doesn't affect codebase;
  test, version modification, documentation, etc.)

Checklist

• Code contributed by me aligns with current project license: Apache 2.0
• I Added CHANGELOG entry regarding this change
• I have implemented unit tests to cover my changes
• I have added/updated the javadocs and other documentation accordingly
• No new bugs, code smells, etc. in SonarCloud report
• I tested my code in Kubernetes
• I tested my code in OpenShift

[sonarcloud]

SonarCloud Quality Gate failed.   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

50.0% Coverage
0.0% Duplication

[manusa]

Maybe I'm not following it OK, but this PR seems to change the current behavior.

It now changes the namespace of the context as opposed to changing the namespace of the item in the context.

If this is the case, I'm not really sure of the possible side-effects this might have.

[shawkins]

It now changes the namespace of the context as opposed to changing the namespace of the item in the context.

The logic for changing the item namespace at the list level was redundant - it was simply preserved from the original logic. The responsibility for changing the namespace is now handled as part of the resource(item) method, which is called by the logic to perform any of the operations.

[manusa]

It now changes the namespace of the context as opposed to changing the namespace of the item in the context.

The logic for changing the item namespace at the list level was redundant - it was simply preserved from the original logic. The responsibility for changing the namespace is now handled as part of the resource(item) method, which is called by the logic to perform any of the operations.

Yes, I understand, but considering a maybe very random use-case (related to #4574) where a user might be doing:

kubernetesClient.resource($resource).inNamespace("new-namespace").get();
// or
kubernetesClient.load($resource).inNamespace("new-namespace").get();
// or the #4574 proposal
kubernetesClient.resource($resource).inNamespace("new-namespace").item();

The behavior won't be the same (AFAIU)

I'm not opposing to this change, I'm just highlighting the possible side-effects and repercussions.

[shawkins]

The behavior won't be the same (AFAIU)

No, the behavior is the same - if needed the item namespace will reflect the namespace specified in inNamespace. The only case that is different is if the item does not have a namespace, then the namespace won't be set - the resource(item) logic will leave the resource alone in that case.

[manusa]

at the list level was redundant

OK, I was missing the important part here: NamespaceVisitFromServerGetWatchDeleteRecreateWaitApplicableListImpl