Tom,
Is your MessageBodyReader/Writer annotated with @Produces/@Consumes? If so,
then it should only be triggered for those types.
John
On Tue, Jul 15, 2014 at 12:31 PM, Tom Butt <tb...@redhat.com> wrote:
> I currently have a resource that consumes "application/xml", but I'm
> moving to custom media types for versioning. So, the issue happens in
> marshal/unmarshal as the root element is the same for both. I have a
> messagebodyreader/writer to handle the custom media types in place, and it
> works well. My concern is that I don't want my messagebodyreader/writer to
> consume/produce application/xml.
>
> So, I let's say I have an endpoint defined as http://something.com/foo
>
> it accepts application/xml and application/vnd.tom.foo+xml
> When you use application/xml, you expect a "FooType"
> When you use application/vnd.tom.foo+xml, you expect a "VersionedFooType"
>
> Both are in the same namespace and both have the same root element <foo>.
>
> IF you use application/vnd.tom.foo+xml, all is peachy. We hit the
> messagebodyreader, it unmarshalls a VersionedFooType and life is good.
>
> If, however, you use application/xml, we don't get into the
> messagebodyreader (as I really don't want EVERY call to have to hit this),
> and so what it unmarshalls is anybody's guess (quite often it's
> VersionedFooType rather than the previously used FooType.)
>
> The solutions that have come to mind are
> 1. Allow the MessageBodyReader to consume/produce application/xml, and
> then I can perform a check in the readFrom or writeTo on the *Type*. If
> it's "FooType" and "application/xml" I can handle it here. This feels a
> bit off to me as I'll have every resource going through this provider, and
> this edge case for a non-custom media type (not even sure this works, but
> it seems that it would.)
> 2. Change the root element of the VersionedFooType to be "<versionedFoo>"
> rather than "<foo>"
>
>
> The real crime here might be the mixture of custom media types with
> non-custom media types, but it seems this is a natural progression if one
> was to move from a non-versioned API to a versioned one using custom media
> types. Maybe I'm overlooking something really simple here, and I hope
> that's the case!
>
> Thanks in advance!
> -Tom
>
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Resteasy-users mailing list
> Resteasy-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Resteasy-users mailing list
Resteasy-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/resteasy-users
