Hi Sergey, I've mocked up something which produces a similar output to the payload referred to in the linked page (see older post). The HTTP request, Java service interface and the relevant parts of the web.xml appear below:
POST /myservice/remote/service/path HTTP/1.1 Host: 127.0.0.1:8888 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4) Gecko/20091016 Firefox/3.5.4 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive X-GWT-Permutation: HostedMode X-GWT-Module-Base: http://127.0.0.1:8888/myservice/ Content-Type: text/x-gwt-rpc; charset=utf-8 Referer: http://127.0.0.1:8888/myservice/hosted.html?myservice Content-Length: 189 Pragma: no-cache Cache-Control: no-cache 5|0|7|http://127.0.0.1:8888/myservice/|0EBF8645C6C142BAE05961AFDE515F13|com.myservice.gwttest.client.GreetingService|greetServer|java.lang.String/2004016611|hello|world|1|2|3|4|2|5|5|6|7| ----------------------8<----------------------- package com.myservice.gwttest.client; public interface GreetingService extends RemoteService { public String greetServer(String greeting, String subject); } ----------------------8<----------------------- <web-app> <servlet> <servlet-name>greetServlet</servlet-name> <servlet-class>com.myservice.gwttest.server.GreetingServiceImpl</servlet-class> </servlet> <servlet-mapping> <servlet-name>greetServlet</servlet-name> <url-pattern>/remote/service/path</url-pattern> </servlet-mapping> </web-app> ----------------------8<----------------------- I'm sorry but I haven't really had time to think about your proposed solutions. Just extemporizing briefly, what do you think of wrapping the InputStream of the message (as per your suggestion) in some sort of parameter-aware, Iterable InputStream? The parsing would be done at construction time after which it could reset itself for reading by other components. The additional methods it could provide may then be: boolean hasNextParameter(); Object nextParameter(); You could avoid having to track the index or use a thread-local Map that way. Cheers Mike On 5 February 2010 17:08, Sergey Beryozkin <[email protected]> wrote: > > 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. > >
