On May 26, 2010, at 10:31 AM, Alex Treppass wrote:
> Sure, I'll raise configuration of default registered providers as an
> improvement issue.
>
Thanks.
> > To work around the issue why don't you declare the media type you
> require in your application code?
>
> We don't want to hard-bake the return types into the server at
> compile time. Our use of Jersey revolves around hot-swapping return
> types at runtime by plugging in and offering different
> MessageBodyWriter instances, so that clients can use a particular
> method in our Web Service (i.e. search) and request results in a
> particular format (xml, json, etc), as well as develop their own
> MessageBodyWriters. This seems possible, but very fragile at the
> moment.
>
OK.
> To what extent is the ability for the JSR311 implementation to be
> runtime-configurable envisaged, moving forward?
>
I think it is gonna require some architectural changes.
Perhaps what we require is the concept of Guice-like modules that the
developer can include for specific functionality e.g. 3 modules for
JAXB support for text/xml, application/xml, and application/*+xml
media types and a parent module that includes all of them.
The idea of say including the jersey-json or jersey-multipart in the
class path and readers/writers getting automatically included was very
appealing initially, but i think it causes issues for developers
because they do not exactly know what is going on and it can cause
conflicts e.g. when Jackson is to be used.
Thus it is reasonable to have a default set of readers/writers. But a
developer can override that by composing their own set and should opt
in for say JSON and multipart etc.
Paul.