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
