This has always been an issue. I guess we just didn't come across the right
combination to produce it.
Anyway. I think we can work around it for now and provide backward compatibility for
anyone using JBR as a Http client in production (nuts, but I suppose it is possible :) ).
The HttpMarshaller executes on the same thread as the InvocationHandler (in our case the
JBossRemotingGateway). If we attach the InvocationRequest object to the thread from
inside the JBossRemotingGateway, we can then access it from inside the HttpMarshaller. In
the HttpMarshaller, we can check:
1. Are we talking to a Remoting Client (set in the request metadata).
2. Is the response payload a Binary Payload type (set in the response metadata).
3. Is the response object an InvocationResponse (passed to the HttpMarshaller).
If all of the above are "true", we unwrap the InvocationResponse and write the
wrapped payload. We do this because under these conditions the JBR client will assume
(incorrectly) that the payload is not an InvocationResponse and will attempt to read it as
a raw stream of bytes.
This is not fool proof because we have no guaranteed way of serializing the underlying
payload to bytes, but we didn't before this either, so we're no worse off :)
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236628#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...