On Nov 12, 2009, at 4:10 AM, Tatu Saloranta wrote:
> On Wed, Nov 11, 2009 at 1:26 AM, Tom Schindl
> <tom.schindl_at_bestsolution.at> wrote:
>> Hi Jakub and Tatu,
> ...
>>> Unless you wanted to use the low-level JSON approach and JSONArray/
>>> JSONObject
>>> classes, you would indeed need to leverage the JacksonJsonProvider
>>> as suggested by Tatu.
>>
>> Thanks. Just included the JacksonJsonProvider into my application
>> and it
>> looks good so far. Would it be possible at all to bring in such a
>> support to jersey itself?
>>
>> If yes I'd try provide you a patch for it but before I start
>> searching
>> through the code I'd like to know if this is even possible at or a
>> limitation of underlying infrastructure.
>
> Concern so far has been with compatibility, that is, try to keep it
> possible to use alternative backends.
> JacksonJsonProvider actually could define META-INF/services definition
> so that it would auto-register.
> But the challenge is that then it would be difficult to change json
> implementation to use one of built-in styles. That is why
> jackson-jaxrs jar does not include service definition, and instead
> it's necessary to register provider (which is just one-liner but
> still).
>
> Since provider itself is a rather small thing (just a single class,
> mostly doing plumbing), it would seem possible to add something
> similar as an optional jersey package. And ideally make it
> configurable using something similar to existing mechanisms.
>
That could be useful. Also i think a simple jackson-json sample would
be really helpful. Happy to accept such contributions :-)
Paul.