John, Right, but when you use application/xml it's NOT triggered, and there's the root element <foo>, so it doesn't have a specific TYPE to unmarshall it to. This ends up meaning that it *might* pick FooType or VersionedFooType. I'm currently testing the concept of accepting application/xml in my MessageBodyReader and pivoting in the "isReadable" method on the media type and the *type*. -Tom
----- Original Message ----- From: "John D. Ament" <john.d.am...@gmail.com> To: "Tom Butt" <tb...@redhat.com> Cc: resteasy-users@lists.sourceforge.net Sent: Tuesday, July 15, 2014 10:37:47 AM Subject: Re: [Resteasy-users] media type and versioning 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