MessageBodyReader support for JAX-RS 2.0

[Stefan Bodewig]

Hi all

I've got a simple MessageBodyReader implementation that we use on the
client side during unit tests. I'd be happy to contribute it to the
jaxrs module if you are interested.

One problem here is it needs an instance of a RepresentationFactory and
I see two options basically

(a) decide for one of the factories (probably Standard) and use that

(b) make the factory something that gets @Injected

Option (a) means the jaxrs module would need a dependency on the module
holding whatever factory we add. At $work we are only using the JSON
variant and wouldn't necessarily want a dependency on the XML stuff (but
could live with it).

OTOH (b) would require users to set up DI for the RepresentationFactory.
They may have done so for the server side anyway.

Stefan

[Mark Derricutt]

On 3 Oct 2014, at 18:12, Stefan Bodewig wrote:

> One problem here is it needs an instance of a RepresentationFactory and
> I see two options basically

The constructor for the *Reader and *Writer's take a RepresentationFactory - at least the standard ones do.

If you're using your own Reader then you're already replacing what Standard is doing, which simply calls:

withRenderer(HAL_JSON, JsonRepresentationWriter.class);
withReader(HAL_JSON, JsonRepresentationReader.class);

Mark

[Stefan Bodewig]

On 2014-10-07, Mark Derricutt wrote:

> On 3 Oct 2014, at 18:12, Stefan Bodewig wrote:

>> One problem here is it needs an instance of a RepresentationFactory and
>> I see two options basically

> The constructor for the *Reader and *Writer's take a RepresentationFactory - at least the standard ones do.

Yes, I know, but I need to get hold of the factory inside the
MessageBodyReader so either I use a fixed one (which might add new
dependencies to halbuilder-jaxrs) or let Jersey inject one.

I was thinking about using RepresentationFactory#readRepresentation.

Stefan

[Mark Derricutt]

On 7 Oct 2014, at 17:23, Stefan Bodewig wrote:

Yes, I know, but I need to get hold of the factory inside the
MessageBodyReader so either I use a fixed one (which might add new
dependencies to halbuilder-jaxrs) or let Jersey inject one.

I was thinking about using RepresentationFactory#readRepresentation.

I must be missing something here - as I said, the *Reader and *Writer classes take a RepresentationFactory as it's constructor, you provide the .class to the RepresentationFactory using withReader/withWriter, and the RepresentationFactory constructs an instance of said reader/writer passing itself in the constructor.

So all Readers/Writers already have a hold of the factory....

The StandardRepresentationFactory is little more than:

new DefaultRepresentationFactory()
  ..withReader()
  ..withWriter()

adding both the XML and JSON readers/writers - you'd just be replacing your own reader.

Oh wait... I just realised MessageBodyReader is a JAX-RS thing and not the HalBuilder *Reader - now I understand the problem - we've been talking about two totally different class hierarchies :)

Since I know jack-squat about Jax-RS - I have no idea what I'm talking about here :)

Mark

[Stefan Bodewig]

On 2014-10-07, Mark Derricutt wrote:

> On 7 Oct 2014, at 17:23, Stefan Bodewig wrote:

>> Yes, I know, but I need to get hold of the factory inside the
>> MessageBodyReader so either I use a fixed one (which might add new
>> dependencies to halbuilder-jaxrs) or let Jersey inject one.

>> I was thinking about using RepresentationFactory#readRepresentation.

> I must be missing something here - as I said, the *Reader and *Writer
> classes take a `RepresentationFactory` as it's constructor,

I guess I'm not explaining things very well, I'll create a branch and
show some code and maybe then things get clearer :-)

Thanks

Stefan

[Stefan Bodewig]

https://github.com/bodewig/halbuilder-jaxrs/blob/read-support-example/src/main/java/com/theoryinpractise/halbuilder/jaxrs/JaxRsHalBuilderReadSupport.java

This is the code we currently use and it only supports reading hal+json
(and is not exactly in the shape of a pull request, yet).

It would be trivial to extend it to also support hal+xml by using the
StandardRepresentationFactory. Even with the current code the jaxrs
module now has new dependencies on halbuilder-core and halbuilder-json
and using StandardRepresentationFactory would pull in -xml and -standard
on top of that.

The alternative I debated was @Injecting the factory so halbuilder-jaxrs
didn't need any new dependencies. The cost of this is I can't use the
@Consumes annotation and don't really have a clean way of knowing which
media type the factory would support[1].

Hope this makes things clearer :-)

Stefan

[1] I'd consider trying AbstractRepresentationFactory#lookupRenderer but
that would mean catching an exception to recognize a media type is not
supported. This doesn't smell nicely.