Menu
▾
▴
Re: [Resteasy-users] media type and versioning
|
From: Scot F. <sf...@re...> - 2014-07-18 16:29:58
|
All,
I found a super easy solution to Tom's question...
In the client, depending on how (and if) you use ProxyFactory (this assumes its being used), all one needs do is define their own messsage reader and viola, you can manage the unmarshalling. As a simple example, let's say you have a resource Foo:
public class MyReader implements MessageBodyReader<Object> {
@Override
public boolean isReadable(Class<?> type, Type genericType, Annotation[] annotations, MediaType mediaType) {
return // Determine if you can read this type...maybe something like "return type == SomeClassIknow.class";
}
@Override
public Object readFrom(Class<Object> type, Type genericType, Annotation[] annotations, MediaType mediaType, MultivaluedMap<String, String> httpHeaders, InputStream entityStream) throws IOException, WebApplicationException {
try {
return // Do your unmarshalling... Something like:
// Create your unmarshaller named "u"
// return u.unmarshal(entityStream, type);
} catch (JAXBException ex) {
ex.printStackTrace(System.err);
throw new RuntimeException(ex);
}
}
}
public class FooFactory {
static {
// This is the magic...
ResteasyProviderFactory.getInstance().addMessageBodyReader(MyReader.class);
}
public Foo getFoo(final String uri) {
return ProxyFactory.create(Foo.class, uri, ...);
}
}
Above, the assumption is one isn't presenting a RestEasyProviderFactory to ProxyFactory.create(...) but instead using the default one as that in ProxyFactory - namely ResteasyProviderFactory.getInstance()...
Now when one makes calls to the Foo resource, the custom message reader will be used and will unmarshall appropriately for you :)
Flossy
----- Original Message -----
> From: "Tom Butt" <tb...@re...>
> To: "John D. Ament" <joh...@gm...>
> Cc: res...@li...
> Sent: Tuesday, July 15, 2014 12:56:05 PM
> Subject: Re: [Resteasy-users] media type and versioning
>
> 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" <joh...@gm...>
> To: "Tom Butt" <tb...@re...>
> Cc: res...@li...
> 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...@re...> 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
> > Res...@li...
> > 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
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-users
>
--
Make It So Number One
|
