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

Mandate usage of JSON-B instance provided by user's ContextResolver<Jsonb> #742

Closed
andymc12 opened this issue Feb 11, 2019 · 9 comments · Fixed by #973
Closed

Mandate usage of JSON-B instance provided by user's ContextResolver<Jsonb> #742

andymc12 opened this issue Feb 11, 2019 · 9 comments · Fixed by #973
Assignees
Milestone

Comments

@andymc12
Copy link
Contributor

Glassfish/Jersey contains a nifty feature that allows a user to specify a ContextResolver<Jsonb> provider. The returned instance of Jsonb is then used by Glassfish to serialize and deserialize JSON objects. That way a customer could, for instance, serialize private fields.

While this feature exists in the RI, it is not mandated by the spec, and so other JAX-RS implementations (CXF, RestEasy - and the app servers that consume them including Liberty, Thorntail/Wildfly, TomEE, etc.) do not implement this feature.

Adam Bien wrote a popular blog post on the topic here:
http://www.adam-bien.com/roller/abien/entry/private_fields_serialization_with_json

And that has caused some confusion when users discover that this feature is not portable, such as:
OpenLiberty/open-liberty#5903

As @WhiteCat22 mentioned in his comments, there is a requirement in the spec to support a JAXBContext returned from a ContextResolver, but no such requirement for a Jsonb instance.

Adding this requirement will enhance portability.

@andymc12 andymc12 added the spec label Feb 11, 2019
@chkal
Copy link
Contributor

chkal commented Feb 12, 2019

+1

Unfortunately we would need to add this to the spec document, which isn't available yet.

@spericas spericas self-assigned this Feb 12, 2019
@spericas spericas added this to the 2.3 milestone Feb 12, 2019
@arjantijms
Copy link
Contributor

+1

Very much in favour of this and indeed should be targeted for 2.3.

@mkarg
Copy link
Contributor

mkarg commented Aug 8, 2019

+1

This would also allow to use default type adapters for generic type (so you cannot register them at the class itself as neither the class nor the generic class is yours), e. g. when dealing with List<UUID>.

@mkarg
Copy link
Contributor

mkarg commented Aug 8, 2019

Added to Discussion 2.3 in the WIKI: https://github.com/eclipse-ee4j/jaxrs-api/wiki/JAX-RS-2.3-Discussion.

@spericas spericas modified the milestones: 3.2, 3.1 Apr 12, 2021
@mkarg
Copy link
Contributor

mkarg commented Jun 4, 2021

Anybody working on this one already or shall I set up a proposal?

@andymc12
Copy link
Contributor Author

andymc12 commented Jun 6, 2021

Hi @mkarg, thanks for the reminder about this. I haven't started writing anything up yet, but I can. My original plan (before forgetting about this issue... :-) ) was to basically duplicate the text from the JAXBContext. If you want to take it, please feel free. Otherwise, I can write up a proposal on Monday or Tuesday.

@mkarg
Copy link
Contributor

mkarg commented Jun 7, 2021

@spericas You self-assigned this to you and have it marked as worked in progress, so shall @andymc12 and me keep our hands off?

@spericas
Copy link
Contributor

spericas commented Jun 7, 2021

@mkarg Wanted to start but did not, if somebody wants to take it from me, feel free. Thx.

@mkarg mkarg self-assigned this Jun 7, 2021
@mkarg
Copy link
Contributor

mkarg commented Jun 7, 2021

Ok will post a draft so we can discuss it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants