Thanks Tatu,
Do you mean:
https://github.com/FasterXML/jackson-jaxrs-json-provider
?
Thanks,
Rick
On Mon, May 28, 2012 at 1:45 PM, Tatu Saloranta <tsaloranta_at_gmail.com>wrote:
> On Sun, May 27, 2012 at 8:46 AM, Casper Bang <casper.bang_at_gmail.com>
> wrote:
> > None, as fair as I am aware of. I've struggled with this problem in
> > the past as well, and came to the conclusion that JAXB ties the view
> > (resource) too rigidly with the model (POJO), making it impossible to
> > reuse POJO's elsewhere - basically it's a cute idea, but it just
> > doesn't scale in practice.
> >
> > So we ended up using raw Jackson, which also has the added benefit
> > that you can start streaming results back immediately. The downside is
> ...
>
> One possible extension point is to have a look at the provider that is
> used to integrate Jackson with JAX-RS. This is where one can add
> things like annotation- or header/query-param-based routing and
> dispatching. Or even use content/media-type for deciding how to handle
> a request, and by whom.
>
> The default implementation (JacksonJaxrsJsonProvider) is relatively
> simple, which is mostly because it is not easy to figure out a generic
> system that would allow useful toggles for things like asked here.
> But it is not all that difficult to figure out how to handle specific
> use case, in "locally generic" way. That is: logic for determining is
> based on specific domain and use case, and custom annotations are
> added to support just those cases.
>
> I think all the flexibility & power of JAX-RS -- which handles LOTS of
> use cases with very simple config and annotations -- sort of hides the
> possibility of using custom extensions, which can solve further set of
> use cases.
>
> -+ Tatu +-
>