Skip to content
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

Better control for class metadata ser/de and JsonP extension #133

Merged
merged 1 commit into from
Jun 6, 2018

Conversation

EugenCepoi
Copy link
Contributor

  • Ability to disable class metadata only for ser or deser via @HandleClassMetadata(serialization=true/false, deserialization=true/false)
  • By default prevent the ClassMetadataConverter to kick in when we ser/de statically typed JsonValues
  • Allow to use JsonValueConverter as default when the type is unknwon and let it leverage ClassMetadataConverter when there is class info.

@aseovic
Copy link
Contributor

aseovic commented Jun 3, 2018

I see what you are trying to do... I like the idea overall, although I do think it needs to be merged with the (new and improved) fix for #130 I'm working on.

That should be easy enough to do, so go ahead and merge this in so I can pick it up, and I'll make sure everything works together the way it should.

That said, I'm not sure it will help much with #123. Sure, it would allow me to eliminate direct reference to JsonValueConverter, but the runtime dependency would still be there and the evolvability would not work unless the user adds properly configured JSR353Bundle, which is, in my opinion, worse than what I have now -- it shifts responsibility to the user, and potentially creates the same issue I have with #132, by creating a requirement that things need to be configured the certain way.

@EugenCepoi
Copy link
Contributor Author

I thought this would be useful in general even outside of the PRs you are working on.
Although it does address some of the issues you found in your PRs.

In #127 it should allow you to avoid having the class metadata kick in when you deserialize to a JsonValue. It also fixes the problem with double class metadata that you were fixing by using a map.

This also enables you to deserialize unknown types to JsonValue (and subclasses) instead of Map and others, which is what you describe in one of your comments here #131.

In regards to

the runtime dependency would still be there and the evolvability would not work unless the user adds properly configured JSR353Bundle

I was thinking that the evolvable component would be a simple impl of the unknown property handler that would come with the jsr 353 bundle or better with this new java-ee module.

@EugenCepoi EugenCepoi merged commit f1ed7ec into master Jun 6, 2018
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