kubernetes-client icon indicating copy to clipboard operation
kubernetes-client copied to clipboard

decoupling unmatched handling from kubernetesdeserializer

Open shawkins opened this issue 3 years ago • 4 comments

Description

As either a stand alone change or part of one of the other serialization issues #3972 or #4024 I'd like to remove the coupling between the KubernetesDeserializer and the unmatched property handling. This change elevates that to the Serialization level. This will further allow us to change the handling of parsing / processing parameters - that has been embedded down in the serialization layer as raw string processing, but it doesn't need to be. Parsing with unmatched type handling on, or parsing as a map would allow for post processing of property substitution.

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
  • [x] Chore (non-breaking change which doesn't affect codebase; test, version modification, documentation, etc.)

Checklist

  • [x] 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

shawkins avatar Apr 04 '22 11:04 shawkins

@manusa marking as a WIP, since we probably won't make it far with cleaning up the static nature of KubernetesDeserializer, it isn't imperative to make this change just yet.

shawkins avatar Apr 07 '22 00:04 shawkins

Does #4171 address the issues that this PR tries to fix? (I feel really uncomfortable extending the ObjectMapper.)

manusa avatar Jun 05 '22 08:06 manusa

Does https://github.com/fabric8io/kubernetes-client/issues/4171 address the issues that this PR tries to fix?

No, this pr is more general. It would have addressed #4171 as well as the ability to do something like client.templates().list() - when you have non-string parameters (currently that will throw a parsing exception), and eventually fully decouple the template processing from parsing (that currently requires simple string substitution prior to parsing).

shawkins avatar Jun 06 '22 19:06 shawkins

Replaced by #4109

shawkins avatar Aug 29 '22 10:08 shawkins