synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hubert, Eric" <>
Subject RE: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Date Sun, 15 Mar 2009 21:30:55 GMT
Yes, I think the overhead in the FaultMediator is rather low. It already handles a lot of other
application protocol specific stuff. The only thing which is not nice is that the way to detect
the Hessian message is making assumptions on the transport used (content-type of http transport
header as a decision criteria). But there are obviously other alternatives to implement the
isHessianMessage() method (e.g. letting the builder write an info about the application protocol
used in a defined place within the message context or even something smarter?).

Yes, there are limitations regarding message transformations changing the application protocol,
this is true. On the other side this would be a relatively hard job. Either reimplementing
the whole protocol or integrating a Hessian library (many library versions are incompatible
amongst each other). Once we really do this, the effort to change a few lines in the FaultMediator
can be neglected.





From: Ruwan Linton [] 
Sent: Sunday, March 15, 2009 9:43 PM
Subject: Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter


Hi all,

Using the formatter to do this is impossible because at the time formatter is getting called
the HTTP status code has already been written to the transport.

I don't think we need an axis2 module to do this, it is just setting a property on the axis2
message context and we should not be adding another handler into the axis2 handler chain to
do this. I would improve the Fault mediator to be aware about hessian than going for a new
module, but there might be a few cases, which will fail by doing that for example if you want
to do a protocol transformation from hessian any other. (though this is not possible for the
moment because the hessian message builder keeps the binary message as it is and is not going
to build the message).


On Mon, Mar 16, 2009 at 1:31 AM, Andreas Veithen <> wrote:

On Sun, Mar 15, 2009 at 20:36, Hubert, Eric <> wrote:
>> For two reasons:
>> 1. Message formatters should be protocol independent (even if they
>> have access to the full MessageContext).
> This is currently not the case. Whereas the rest of Synapse is totally
> unaware of any Hessian specifics, the Hessian Builder/Formatter pair is
> actually the protocol dependent implementation. It is only used for
> Hessian Messages and has to be configured (activated) in axis2.xml for
> the specific content type.

My statement was not precise enough. What I wanted to say is that
message formatters should be _transport_ protocol independent. On the
other hand, as you point out, they implement a specific _application_
protocol. BTW, is Hessian used on other transport protocols, such as

>> 2. Probably when the message formatter is invoked, it is already too
>> late to set the HTTP status code.
> Excactly! Thats the definite reason. The whole http headers are already
> written when it comes to the formatter.
> See HttpCoreNIOSender.sendAsyncResponse():
> worker.getServiceHandler().commitResponse(worker.getConn(), response);
> // ...
> OutputStream out = worker.getOutputStream();
> //..
> messageFormatter.writeTo(msgContext, format, out, false);
> Regards,
>  Eric
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

Ruwan Linton
Senior Software Engineer & Product Manager; WSO2 ESB;
WSO2 Inc.;
email:; cell: +94 77 341 3097

View raw message