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.
http://jyaml.sourceforge.net/
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 (*/*).
>>
>>
>> SOLUTION?
>>
>> 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
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com