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

Provide a way to customize `ObjectReader` / `ObjectWriter` used by end points #33

Closed
cowtowncoder opened this Issue Oct 11, 2013 · 10 comments

Comments

Projects
None yet
3 participants
@cowtowncoder
Member

cowtowncoder commented Oct 11, 2013

(note: inspired by #32)


It would be nice to be able to customize configuration of ObjectReader used for reading content via JAX-RS, and configuration of ObjectWriter used for writing.
This functionality should be accessible from code outside of JAX-RS provider implementation.

@cowtowncoder

This comment has been minimized.

Member

cowtowncoder commented Oct 11, 2013

The way this is implemented is as follows:

  • Two new classes -- ObjectReaderInjector and ObjectWriterInjector -- can be accessed statically (they use ThreadLocal) to "inject" ObjectReaderModifier and ObjectWriterModifier (respectively)
  • JAX-RS provider will construct reader/writer to use, based on regular configuration and annotations; and then call injectors to access modifiers. If a modifier is found, it shall be used to (re)configure reader/writer

This basically allows for specifying a modifier to do any and all customization necessary. Assignment has to be made on per-call basis for now.

cowtowncoder added a commit that referenced this issue Oct 11, 2013

@cowtowncoder

This comment has been minimized.

Member

cowtowncoder commented Oct 11, 2013

Implemented for 2.3.0.

@apemberton

This comment has been minimized.

apemberton commented Oct 22, 2013

Hi Tatu: this is awesome; thanks! Can you cut a branch / mvn release of 2.3 so I can give it a whirl?

@cowtowncoder

This comment has been minimized.

Member

cowtowncoder commented Oct 22, 2013

I can do maven deploy of the snapshot tonight.

@cowtowncoder

This comment has been minimized.

Member

cowtowncoder commented Oct 23, 2013

Ok I pushed 2.3.0-SNAPSHOT of jackson-databind (jackson-core was already done), this project. So that should work.

@apemberton

This comment has been minimized.

apemberton commented Oct 23, 2013

Thanks! Looking great on our end so far. Do you have a plan to do a 2.3 release (ie: non-snapshot)?

@cowtowncoder

This comment has been minimized.

Member

cowtowncoder commented Oct 23, 2013

Yes, hope is to get things finalized soon (within a week or two). 2.3.0 has dragged on for quite a while, but all the pieces are in now.

@cowtowncoder

This comment has been minimized.

Member

cowtowncoder commented Nov 16, 2013

2.3.0 was just released on November 14th, 2013.

@renaudcerrato

This comment has been minimized.

renaudcerrato commented Jun 10, 2016

How does that fit with the caching mechanisms? It seems the key used to cache the writer/reader is computed from annotations and type.

@cowtowncoder

This comment has been minimized.

Member

cowtowncoder commented Jun 10, 2016

@renaudcerrato It should work fine as information is passed using ThreadLocal; annotations are only used to create baseline ObjectWriter / ObjectReader, but then modifier can create new instances. Modification call is made on per-request basis. I hope test case shows how this occurs.
It all works as ObjectReader/ObjectWriter are immutable, so concurrent threads are not changing reader/writer instances but constructing new ones (with withXxx() methods), returning ones to use.

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