Hi
Sorry, was about to reply earlier on....
That is a useful link indeed. Can you please let me know how does the the
method signature look like ?
I'd like to understand how a GWT RPC sequence is supposed to mapped to a
real method....Then we can see what is the best option is...
Perhaps one option is to replace an incoming InputStream with the
ByteArrayInputStream on the incoming message from a custom CXF JAXRS filter,
given that the sequences seem to be quite small :
ByteArrayInputStream bos =
IOUtils.loadIntoBais(message.getContent(InputStream.class))
message.setContent(bos);
Next build some sort of the map by passing this stream and set it as a
message property, say message.put("gwt.map", map);
this all can be done in a filter.
Next your message reader can have a CXF @MessageContext injected and you can
get the map out of it.
Finally, in readFrom(), you can try to retrieve the value, perhaps using
some of the readFrom parameters ?
If needed you can also have a thread local map which will be used to
increment the parameters index ?
If you could post the sample method signature then it would help
cheers, Sergey
Michael Guyver-3 wrote:
>
> 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,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 <[email protected]> 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
>>
>
>
--
View this message in context:
http://old.nabble.com/GWT-service-from-CXF--tp27218968p27470896.html
Sent from the cxf-user mailing list archive at Nabble.com.
