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 ?
> 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.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.