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

[Kevin.Conner@jboss.com]

"tfennelly" wrote : 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 :) ).
Nuts perhaps, but safer than breaking code which is already working :)

At least it will give us some breathing space until the underlying issue is fixed.

"tfennelly" wrote : 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 :)
It does sound scary but, if it leaves the clients unchanged we should at least try it.  As you say, we are no worse off than previously and, hopefully, it will be stable enough until the underlying cause is addressed.

Thanks Tom, this looks like a good compromise.

Kev

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

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