[jboss-dev-forums] [Design of JBoss ESB] - Re: JBoss Remoting Gateway using bogus HttpMarshaller?

[tfennelly]

Yeah... that comment would explain that class's handling of the byte[], which was what the class was originally created for.

I found out why I added the "special" handling of the InvocationResponse.  There's a comment on one of the linked JIRAs on the second commit re the webserive-producer quickstart not working.  I tested it out after removing the "special" handling of the InvocationResponse and sure enough, it breaks.  The reason is as follows.... 

The JBoss Remoting HttpClientInvoker uses the HTTPUnMarshaller class to read and decode the response stream (which will be an InvocationResponse when a Remoting Client calls a Remoting Server).  Problem is that the HTTPUnMarshaller only uses the Content-Type header to decide whether or not to delegate to the SerializableUnMarshaller (it handles InvocationResponses) to decode the stream.  When something on the server side sets the content type to a non-Binary type (e.g. text/xml as with the SOAPProcessor), the HTTPUnMarshaller decides to just read the stream as a raw stream of bytes.

This explains why I added the Special handling of the InvocationResponse in the HttpUnmarshaler.  It was an invalid fix however IMO.  The real issue is with JBR and it's handling of http and InvocationResponse.  If JBR Server is going to wrap responses for JBR Clients, then it is effectively changing the content type, in which case it should reset the content type to octetstream (or whatever) in the response and store the original content type somewhere on the InvocationResponse and use it after unwrapping on the client side.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236394#4236394

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236394