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.

 

Regards,

  Eric

________________________________

From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] 
Sent: Sunday, March 15, 2009 9:43 PM
To: dev@synapse.apache.org
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).

Thanks,
Ruwan

On Mon, Mar 16, 2009 at 1:31 AM, Andreas Veithen <andreas.veit...@gmail.com> 
wrote:

On Sun, Mar 15, 2009 at 20:36, Hubert, Eric <eric.hub...@foxmobile.com> 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
JMS?


>> 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: dev-unsubscr...@synapse.apache.org
> For additional commands, e-mail: dev-h...@synapse.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org
For additional commands, e-mail: dev-h...@synapse.apache.org




-- 
Ruwan Linton
Senior Software Engineer & Product Manager; WSO2 ESB; http://wso2.org/esb
WSO2 Inc.; http://wso2.org
email: ru...@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com 

Reply via email to