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

Add support for new property of @JsonProperty to support read-only/write-only use cases #813

Closed
cowtowncoder opened this issue May 30, 2015 · 0 comments
Milestone

Comments

@cowtowncoder
Copy link
Member

Although it is possible to support read-only/write-only use cases with a combination of various settings, like visibility settings, and/or addition of setters/getters, it would be useful to just have a property that dictates intended behavior, like:

  • read-only: figure out an accessor (getter or field), regardless of visibility; ignore any mutators
  • write-only: figure out a mutator (getter, field, creator parameter), regardless of visibility, ignore any accessors
  • read-write: figure out both accessor and mutator, if any found, regardless of visibility:
  • auto: just use default visibility settings (current behavior)

and default to auto for backwards compatibility.

The benefit here is that this basically allows overriding of visibility settings for individual properties.

For example:

  • For a password field, we may want "write-only" behavior, so that password is never exposed on serialization, but may be passed in via deserialization
  • Certain settings are not to be used via POJO, but should be included in serialization: read-only setting would allow use of private accessor or field for serialization, without having to change visibility settings, or make getter public
  • Modules that want to change default behavior of certain special classes could specify one of accessor cases (like read-write) to enable convenient round-trip behavior (for example, Scala module could do this at least for case classes, maybe all typical Scala beans).
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

No branches or pull requests

1 participant