Hi everyone, I've been having a closer look at how to implement a MessageBodyReader for the GWT RPC protocol, and while I'm aware of a JSON-related project (http://hiramchirino.com/blog/tag/json/), it's not a solution for GWT-RPC.
I'm a relative GWT noob but I think you gain much greater type-safety from using the GWT-RPC mechanism over JSON as your application receives the strongly-typed response object from your remote service, possibly replete with methods to afford encapsulation, rather than just some opaque data-only JavaScriptObject. Perhaps someone can set me straight here? The problem so far as implementing a MessageBodyReader is, as I see it, that the GWT RPC protocol describes its payload types and values in a non-sequential way. This is summarised in a very helpful article here (search for the string "This is where the Payload gets a little more interesting" to get to the payload section): http://www.gdssecurity.com/l/b/2009/10/08/gwt-rpc-in-a-nutshell/ I anticipate that the initial part of the payload can be disregarded as it contains routing information for the RemoteServiceServlet, contrary to the routing for JAX-RS where it is derived from the path itself - /path/to/my/service. The data-portion of the payload is the bit that's important, but I don't see that it is amenable to sequential processing as per the normal operation of the JAXRS call stack: JAXRSInInterceptor.processRequest(Message): 78 JAXRSUtils.processParameters(OperationResourceInfo,MultivaluedMap<String, String>,Message): 502 JAXRSUtils.processParameter(Class<?>,Type,Annotation[],Parameter,MultivaluedMap<String, String>,Message,OperationResourceInfo): 538 JAXRSUtils.readFromMessageBody(Class<T>,Type,Annotation[],InputStream,MediaType,List<MediaType>,Message): 933 MessageBodyReader.readFrom(Class<Object>,Type,Annotation[],MediaType,MultivaluedMap<String, String>,InputStream) It's even unfortunate that a parameter index is not passed to the MessageBodyReader, so you could suffer the cost of parsing the payload on each invocation. As almost all of these methods are static there's no chance of introducing a custom processor - unless I've missed something? Is there a way of hooking into the request processing system such that you can return a parameter Object[] from the request body rather than being invoked as if the payload were a nicely sequential stream? Can anyone suggest an approach to this problem? Cheers Mike On 19 January 2010 00:09, Michael Guyver <michael.guy...@gmail.com> wrote: > Hi there, > > This is a borderline hypothetical question - but say I had a GWT application > that existed within a custom static HTML/Velocity/Trimpath/Spring MVC > application and I wanted to have GWT's AJAX requests handled by the CXF > JAXRS implementation, how would I go about parsing and writing GWT-JSON > (IIRC it's worlds apart from "normal" JSON). Would you create some sort of > MessageBodyReader and MessageBodyWriter implementation analogous to the > AbstractJAXBProvider? > > Cheers > > Mike >
