Re: JSR311: MessageBodyWriter/Reader's type should take precedence

From: Bill Burke <>
Date: Mon, 09 Feb 2009 10:07:21 -0500

Marc Hadley wrote:
> On Feb 7, 2009, at 12:21 AM, Bill Burke wrote:
>> Scenario:
>> I introduced a new YAML provider that does this:
>> @Produces({"text/yaml", "text/x-yaml", "application/x-yaml"})
>> public class YamlProvider implements MessageBodyWriter
>> {
>> boolean isWritable(...)
>> {
>> return true;
>> }
>> }
>> Basically it write any Java object out to YAML. The problem?
> I think the problem is that the isWritable is too broad. Can your
> YamlProvider really cope with *anything*. At a minimum I'd think you'd
> want to exclude stream and reader based entities ?

The YamlProvider can work with an JavaBean.

So any object with a get method might work. It can also work with
maps/lists/arrays, primitive, primitive wrappers. I just didn't want to
force the user to add additional information, like an annotation, to
their Java Beans classes.

I also ran into this problem with our DefaultPlainText provider.
Basically its the same thing in that isWritable() returns true for
anything (because all objects have a toString() method)

The thing is, StreamingOutput, InputStream, and File are all examples of
types that work with *ALL* media types. May not a user application
create more of these types of things? May not the spec create more of
these things?

>> This screws up methods using StreamingOutput for example:
>> @GET
>> @Produces("text/yaml")
>> public StreamingOutput getYAML() {...}
>> Because of provider sorting rules, the YamlProvider will *ALWAYS* get
>> picked over the StreamingOutput provider because its @Produces is more
>> specific that StreamingOutput's provider (*/*).
>> Readers/Writers that are more type specific should always take
>> precedence:
>> public class StreamingOutputProvider implements
>> MessageBodyWriter<StreamingOutput> {}
>> This provider takes precedence over the YamlProvider with the
>> getYAML() example because the returned object type matches the
>> ParameterizedType of the StreamingOutputProvider.
> Have to think about this some more, sounds like an interesting idea.

I just don't think this would hurt anything because what you are doing
is finding a MessageBodyReader/Writer that is specific to the type you
are marshalling.

For example, what if you want to override JAXB marshalling for a
specific Java type?

Also finally, we do this sort of matching for ContextResolver.


Bill Burke
JBoss, a division of Red Hat