Hi Eric,

Find my comments inline;

On Mon, Mar 16, 2009 at 3:00 AM, Hubert, Eric <Eric.Hubert@foxmobile.com> wrote:

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, we can set a property in to the axis2 message context at the builder and implement a helper method to check whether the current message is a hessian message, by checking that particular property set by the builder. So we can let this helper reside on the extensions utils method so that the logic is decoupled to some extent.

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.

With the above change, I think I am +1 for letting the FaultMediator handle this scenario. :-)

Thanks,
Ruwan

 

Regards,

  Eric


From: Ruwan Linton [mailto:ruwan.linton@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.veithen@gmail.com> wrote:

On Sun, Mar 15, 2009 at 20:36, Hubert, Eric <Eric.Hubert@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-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>

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




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




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