RE: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Hi all, sorry for the gap in response. I was actually very busy due to some platform live issues which needed my attention. Anyway I tried to finish up the discussed work on the handling of synapse generated faults send out as a Hessian message. Looking at the possibilities I discarded the approach setting the HTTP status code in the FaultMediator. Actually if it is already indicated from the HessianMessageBuilder that 200 shall be used for faults, then this information should be directly evaluated from the nhttp transport module. Everything else would just be a useless indirection introducing another transport coupling. So how do you like the new idea to evaluate this property directly inside NhttpCoreNIOSencer. Please have a look at my patch provided at: https://issues.apache.org/jira/browse/SYNAPSE-521 Feedback welcome! Indika, this should also address your concerns, or? Thanks for the feedback, Eric
Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Is there a scenario where request is a hessian message and reply is a SOAP message? Supun. On Mon, Mar 16, 2009 at 9:56 PM, indika kumara wrote: > Hi All > > I am sorry as I just look at this only now. Just putting my concerns. > > I actually don’t like for setting http code inside fault mediator. > > 1) Both ‘fault ‘and ‘property’ mediators have well defined > abstraction. Things should be done by a ‘property’ mediator, should > not be done by a fault mediator for any reason (if not impossible by > other way). > 2) If this kind of things are needed for some other protocol or due to > any other reasons. Do we add those logics into fault mediator? > > Use of synapse language API is the most important things than adding > Java code. For synapse, synapse language API should be the first > choice. > > There are some great extensions that can be used to add additional > behaviors. Hessian specific things can not be a main concern. > 1) As Andreas suggests , Axis2 module - This should be possible even I > cannot validate > 2) Other most important thing is synapse has a great extension - Class > mediator. You can make a mediator with the logic you want (if > XMediator). And then documents, use after > fault mediator for this Hessian specific things. Then, ship these > useful mediators that can be used with Class mediator configuration. > > I just only want to add my concerns as it is the way I thinks. I just > want to say the way I think about these and I never want to prove > ideas of others are bad or mine are good. > > Thanks > Indika > > - > To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org > For additional commands, e-mail: dev-h...@synapse.apache.org > > -- Software Engineer, WSO2 Inc http://wso2.org supunk.blogspot.com
Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Hi All I am sorry as I just look at this only now. Just putting my concerns. I actually don’t like for setting http code inside fault mediator. 1) Both ‘fault ‘and ‘property’ mediators have well defined abstraction. Things should be done by a ‘property’ mediator, should not be done by a fault mediator for any reason (if not impossible by other way). 2) If this kind of things are needed for some other protocol or due to any other reasons. Do we add those logics into fault mediator? Use of synapse language API is the most important things than adding Java code. For synapse, synapse language API should be the first choice. There are some great extensions that can be used to add additional behaviors. Hessian specific things can not be a main concern. 1) As Andreas suggests , Axis2 module - This should be possible even I cannot validate 2) Other most important thing is synapse has a great extension - Class mediator. You can make a mediator with the logic you want (if XMediator). And then documents, use after fault mediator for this Hessian specific things. Then, ship these useful mediators that can be used with Class mediator configuration. I just only want to add my concerns as it is the way I thinks. I just want to say the way I think about these and I never want to prove ideas of others are bad or mine are good. Thanks Indika - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Sounds good. Andreas On Mon, Mar 16, 2009 at 07:52, Hubert, Eric wrote: > Yes, this has been exactly the direction I was looking for. I guess Asankha > made just a typo in the name of the suggested property and wanted to use > FAULTS_AS_HTTP200 as 500 would be the current default. Then the rest of the > sentence setting it to true in the HessianMessageBuilder would still apply. > ;-) > > > > If nobody objects or has better ideas, I’ll go ahead and propose a patch > following Asankha’s suggestion. > > > > Regards, > > Eric > > > > > > > > From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] > Sent: Monday, March 16, 2009 4:27 AM > To: dev@synapse.apache.org > Subject: Re: Creating HessianFaults using > FaultMediator/HessianMessageFormatter > > > > I think all last three suggestions will work nicely to solve this issue, but > I think asankha's solution seems quite handy in this case as well as in most > of the other POX cases (it is a generic solution). > > I think HessianBuilder should set the value to false in the asankha's > suggestion, because hessian messages want them to be to 200 rather than 500. > :-) > > Thanks, > Ruwan > > On Mon, Mar 16, 2009 at 6:59 AM, Asankha C. Perera > wrote: > > Hi all > > 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. > > Considering all that has been brought up in this thread and the above in > particular, what if we define a new Synapse property say 'FAULTS_AS_HTTP500' > - and the Hessian builders would set this property to True. This way the > fault mediator is not Hessian specific. > > When the fault mediator is invoked later, it would check this property and > perform the logic given in Eric's patch. I believe many POX messages would > also benefit from this - where many fault messages would actually go on the > wire as HTTP 200's.. > > cheers > asankha > > -- > > Asankha C. Perera > > AdroitLogic, http://adroitlogic.org > > > > http://esbmagic.blogspot.com > > > > > > > > > -- > 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 - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter
+1 Thanks, Rwuan On Mon, Mar 16, 2009 at 12:22 PM, Hubert, Eric wrote: > Yes, this has been exactly the direction I was looking for. I guess > Asankha made just a typo in the name of the suggested property and wanted to > use FAULTS_AS_HTTP200 as 500 would be the current default. Then the rest of > the sentence setting it to true in the HessianMessageBuilder would still > apply. ;-) > > > > If nobody objects or has better ideas, I’ll go ahead and propose a patch > following Asankha’s suggestion. > > > > Regards, > > Eric > > > > > -- > > *From:* Ruwan Linton [mailto:ruwan.lin...@gmail.com] > *Sent:* Monday, March 16, 2009 4:27 AM > *To:* dev@synapse.apache.org > *Subject:* Re: Creating HessianFaults using > FaultMediator/HessianMessageFormatter > > > > I think all last three suggestions will work nicely to solve this issue, > but I think asankha's solution seems quite handy in this case as well as in > most of the other POX cases (it is a generic solution). > > > I think HessianBuilder should set the value to false in the asankha's > suggestion, because hessian messages want them to be to 200 rather than 500. > :-) > > Thanks, > Ruwan > > On Mon, Mar 16, 2009 at 6:59 AM, Asankha C. Perera > wrote: > > Hi all > > 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. > > Considering all that has been brought up in this thread and the above in > particular, what if we define a new Synapse property say 'FAULTS_AS_HTTP500' > - and the Hessian builders would set this property to True. This way the > fault mediator is not Hessian specific. > > When the fault mediator is invoked later, it would check this property and > perform the logic given in Eric's patch. I believe many POX messages would > also benefit from this - where many fault messages would actually go on the > wire as HTTP 200's.. > > cheers > asankha > > -- > > Asankha C. Perera > > AdroitLogic, http://adroitlogic.org > > > > http://esbmagic.blogspot.com > > > > > > > > > > > -- > 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 > -- 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
RE: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Yes, this has been exactly the direction I was looking for. I guess Asankha made just a typo in the name of the suggested property and wanted to use FAULTS_AS_HTTP200 as 500 would be the current default. Then the rest of the sentence setting it to true in the HessianMessageBuilder would still apply. ;-) If nobody objects or has better ideas, I'll go ahead and propose a patch following Asankha's suggestion. Regards, Eric From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] Sent: Monday, March 16, 2009 4:27 AM To: dev@synapse.apache.org Subject: Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter I think all last three suggestions will work nicely to solve this issue, but I think asankha's solution seems quite handy in this case as well as in most of the other POX cases (it is a generic solution). I think HessianBuilder should set the value to false in the asankha's suggestion, because hessian messages want them to be to 200 rather than 500. :-) Thanks, Ruwan On Mon, Mar 16, 2009 at 6:59 AM, Asankha C. Perera wrote: Hi all 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. Considering all that has been brought up in this thread and the above in particular, what if we define a new Synapse property say 'FAULTS_AS_HTTP500' - and the Hessian builders would set this property to True. This way the fault mediator is not Hessian specific. When the fault mediator is invoked later, it would check this property and perform the logic given in Eric's patch. I believe many POX messages would also benefit from this - where many fault messages would actually go on the wire as HTTP 200's.. cheers asankha -- Asankha C. Perera AdroitLogic, http://adroitlogic.org http://esbmagic.blogspot.com -- 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
Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter
I think all last three suggestions will work nicely to solve this issue, but I think asankha's solution seems quite handy in this case as well as in most of the other POX cases (it is a generic solution). I think HessianBuilder should set the value to false in the asankha's suggestion, because hessian messages want them to be to 200 rather than 500. :-) Thanks, Ruwan On Mon, Mar 16, 2009 at 6:59 AM, Asankha C. Perera wrote: > Hi all > > 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. > > Considering all that has been brought up in this thread and the above in > particular, what if we define a new Synapse property say 'FAULTS_AS_HTTP500' > - and the Hessian builders would set this property to True. This way the > fault mediator is not Hessian specific. > > When the fault mediator is invoked later, it would check this property and > perform the logic given in Eric's patch. I believe many POX messages would > also benefit from this - where many fault messages would actually go on the > wire as HTTP 200's.. > > cheers > asankha > > -- > Asankha C. Perera > AdroitLogic, http://adroitlogic.org > http://esbmagic.blogspot.com > > > -- 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
Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Hi all 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. Considering all that has been brought up in this thread and the above in particular, what if we define a new Synapse property say 'FAULTS_AS_HTTP500' - and the Hessian builders would set this property to True. This way the fault mediator is not Hessian specific. When the fault mediator is invoked later, it would check this property and perform the logic given in Eric's patch. I believe many POX messages would also benefit from this - where many fault messages would actually go on the wire as HTTP 200's.. cheers asankha -- Asankha C. Perera AdroitLogic, http://adroitlogic.org http://esbmagic.blogspot.com
Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter
> 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?). Normally, the message formatter is selected based on the "messageType" (Constants.Configuration.MESSAGE_TYPE) property of the MessageContext. This is transport independent, so you should use this information. Andreas - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Hi Eric, Find my comments inline; On Mon, Mar 16, 2009 at 3:00 AM, Hubert, Eric 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.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 > 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 > -- 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
RE: Creating HessianFaults using FaultMediator/HessianMessageFormatter
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 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 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
RE: Creating HessianFaults using FaultMediator/HessianMessageFormatter
> >> 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? Ah, sorry that I didn't get your point at first. This makes sense. I haven't seen some other transport protocol than http for Hessian so far as it is RPC oriented, but it should be possible to use other transports. Regards, Eric
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 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 > 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
Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter
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 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
RE: Creating HessianFaults using FaultMediator/HessianMessageFormatter
> Just throwing an idea into the discussion: What about an Axis2 module? Ideas are always welcome. Unfortunately I can nothing put into this discussion as I'm currently not aware of the Axis2 design. Is there any overview of the Axis2 design and what one can do within an Axis2 module? Hmmm, seems to be the wrong list to ask this, but actually Synapse is currently very tightly coupled with Axis2. I hope someone more knowledgeable can comment on this idea. Regards, Eric > > Andreas > > On Sun, Mar 15, 2009 at 00:11, Hubert, Eric > wrote: > > I thought it might be useful for discussion to also have some sample > code to illustrate b). > > > > Please find attached a quick implementation showing the idea. > > > > Regards, > > Eric > > > > > >> Hi all, > >> > >> if someone wants to use the FaultMediator in conjunction with Hessian > >> messages he has to know that he to set the HTTP status code to 200, > after > >> using the FaultMediator and before using the SendMediator. > >> > >> Normally (for SOAP messages) the HTTP status code is 500, but Ruwan > once > >> created a possibility to override this value using a property of scope > >> Axis2. > >> > >> So declaratively this is possible in synapse.xml via adding the > following > >> configuration block: > >> > >> > >> > >> > >> > >> > >> > >> The HessianFormatter transforms the SOAPFault to a Hessian fault and > >> writes a valid Hessian fault message to the client, which deserializes > the > >> fault message to a HessianServiceException with the proper message. > >> This only works if the HTTP status code is 200. Any other messages will > >> not be deserialized by the Hessian Client libraries. > >> > >> I guess most people trying out the Hessian support would stumple over > this > >> issue. I see two possibilities and would like to here your opinion. > >> > >> a) Document this behaviour and the needed configuration online. > >> b) Extend the FaultMediator to set this property programmatically > >> depending on the content-type header. > >> > >> I see advantages and disadvantages with both approaches. Currently the > >> FaultMediator is already handling the differences between SOAP 1.1, > SOAP > >> 1.2 and POX. This would need three of four more lines as well as the > >> duplication or a move of a content-type constant for "x- > >> application/hessian" as for sure a dependency from the core to the > >> extensions module must not exist. > >> > >> Anyone having a clever option c in mind? Comments are welcome! > >> > >> 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 - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
RE: Creating HessianFaults using FaultMediator/HessianMessageFormatter
> 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. > 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
Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter
I don't know exactly. It was just an idea that came to my mind. Let's see what others on the list think about it. Andreas On Sun, Mar 15, 2009 at 16:47, Supun Kamburugamuva wrote: > If setting 200 in case of a hessian fault is not an option for the user, > using a module will be a cleaner solution. BTW did you mean another handler > for Synapse or a complete module? > > Supun > > On Sun, Mar 15, 2009 at 8:20 PM, Andreas Veithen > wrote: >> >> For two reasons: >> >> 1. Message formatters should be protocol independent (even if they >> have access to the full MessageContext). >> 2. Probably when the message formatter is invoked, it is already too >> late to set the HTTP status code. >> >> Andreas >> >> On Sun, Mar 15, 2009 at 16:17, Supun Kamburugamuva >> wrote: >> > If setting 200 in case of a Hessian fault is a must, why don't we do it >> > in >> > the HessianMessageFormatter? My be I'm missing something :) >> > >> > Thanks, >> > Supun. >> > >> > On Sun, Mar 15, 2009 at 4:05 PM, Andreas Veithen >> > >> > wrote: >> >> >> >> Just throwing an idea into the discussion: What about an Axis2 module? >> >> >> >> Andreas >> >> >> >> On Sun, Mar 15, 2009 at 00:11, Hubert, Eric >> >> wrote: >> >> > I thought it might be useful for discussion to also have some sample >> >> > code to illustrate b). >> >> > >> >> > Please find attached a quick implementation showing the idea. >> >> > >> >> > Regards, >> >> > Eric >> >> > >> >> > >> >> >> Hi all, >> >> >> >> >> >> if someone wants to use the FaultMediator in conjunction with >> >> >> Hessian >> >> >> messages he has to know that he to set the HTTP status code to 200, >> >> >> after >> >> >> using the FaultMediator and before using the SendMediator. >> >> >> >> >> >> Normally (for SOAP messages) the HTTP status code is 500, but Ruwan >> >> >> once >> >> >> created a possibility to override this value using a property of >> >> >> scope >> >> >> Axis2. >> >> >> >> >> >> So declaratively this is possible in synapse.xml via adding the >> >> >> following >> >> >> configuration block: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> The HessianFormatter transforms the SOAPFault to a Hessian fault and >> >> >> writes a valid Hessian fault message to the client, which >> >> >> deserializes >> >> >> the >> >> >> fault message to a HessianServiceException with the proper message. >> >> >> This only works if the HTTP status code is 200. Any other messages >> >> >> will >> >> >> not be deserialized by the Hessian Client libraries. >> >> >> >> >> >> I guess most people trying out the Hessian support would stumple >> >> >> over >> >> >> this >> >> >> issue. I see two possibilities and would like to here your opinion. >> >> >> >> >> >> a) Document this behaviour and the needed configuration online. >> >> >> b) Extend the FaultMediator to set this property programmatically >> >> >> depending on the content-type header. >> >> >> >> >> >> I see advantages and disadvantages with both approaches. Currently >> >> >> the >> >> >> FaultMediator is already handling the differences between SOAP 1.1, >> >> >> SOAP >> >> >> 1.2 and POX. This would need three of four more lines as well as the >> >> >> duplication or a move of a content-type constant for "x- >> >> >> application/hessian" as for sure a dependency from the core to the >> >> >> extensions module must not exist. >> >> >> >> >> >> Anyone having a clever option c in mind? Comments are welcome! >> >> >> >> >> >> 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 >> >> >> > >> > >> > >> > -- >> > Software Engineer, WSO2 Inc >> > http://wso2.org >> > supunk.blogspot.com >> > >> > >> > >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org >> For additional commands, e-mail: dev-h...@synapse.apache.org >> > > > > -- > Software Engineer, WSO2 Inc > http://wso2.org > supunk.blogspot.com > > > - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter
If setting 200 in case of a hessian fault is not an option for the user, using a module will be a cleaner solution. BTW did you mean another handler for Synapse or a complete module? Supun On Sun, Mar 15, 2009 at 8:20 PM, Andreas Veithen wrote: > For two reasons: > > 1. Message formatters should be protocol independent (even if they > have access to the full MessageContext). > 2. Probably when the message formatter is invoked, it is already too > late to set the HTTP status code. > > Andreas > > On Sun, Mar 15, 2009 at 16:17, Supun Kamburugamuva > wrote: > > If setting 200 in case of a Hessian fault is a must, why don't we do it > in > > the HessianMessageFormatter? My be I'm missing something :) > > > > Thanks, > > Supun. > > > > On Sun, Mar 15, 2009 at 4:05 PM, Andreas Veithen < > andreas.veit...@gmail.com> > > wrote: > >> > >> Just throwing an idea into the discussion: What about an Axis2 module? > >> > >> Andreas > >> > >> On Sun, Mar 15, 2009 at 00:11, Hubert, Eric > >> wrote: > >> > I thought it might be useful for discussion to also have some sample > >> > code to illustrate b). > >> > > >> > Please find attached a quick implementation showing the idea. > >> > > >> > Regards, > >> > Eric > >> > > >> > > >> >> Hi all, > >> >> > >> >> if someone wants to use the FaultMediator in conjunction with Hessian > >> >> messages he has to know that he to set the HTTP status code to 200, > >> >> after > >> >> using the FaultMediator and before using the SendMediator. > >> >> > >> >> Normally (for SOAP messages) the HTTP status code is 500, but Ruwan > >> >> once > >> >> created a possibility to override this value using a property of > scope > >> >> Axis2. > >> >> > >> >> So declaratively this is possible in synapse.xml via adding the > >> >> following > >> >> configuration block: > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> The HessianFormatter transforms the SOAPFault to a Hessian fault and > >> >> writes a valid Hessian fault message to the client, which > deserializes > >> >> the > >> >> fault message to a HessianServiceException with the proper message. > >> >> This only works if the HTTP status code is 200. Any other messages > will > >> >> not be deserialized by the Hessian Client libraries. > >> >> > >> >> I guess most people trying out the Hessian support would stumple over > >> >> this > >> >> issue. I see two possibilities and would like to here your opinion. > >> >> > >> >> a) Document this behaviour and the needed configuration online. > >> >> b) Extend the FaultMediator to set this property programmatically > >> >> depending on the content-type header. > >> >> > >> >> I see advantages and disadvantages with both approaches. Currently > the > >> >> FaultMediator is already handling the differences between SOAP 1.1, > >> >> SOAP > >> >> 1.2 and POX. This would need three of four more lines as well as the > >> >> duplication or a move of a content-type constant for "x- > >> >> application/hessian" as for sure a dependency from the core to the > >> >> extensions module must not exist. > >> >> > >> >> Anyone having a clever option c in mind? Comments are welcome! > >> >> > >> >> 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 > >> > > > > > > > > -- > > Software Engineer, WSO2 Inc > > http://wso2.org > > supunk.blogspot.com > > > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org > For additional commands, e-mail: dev-h...@synapse.apache.org > > -- Software Engineer, WSO2 Inc http://wso2.org supunk.blogspot.com
Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter
For two reasons: 1. Message formatters should be protocol independent (even if they have access to the full MessageContext). 2. Probably when the message formatter is invoked, it is already too late to set the HTTP status code. Andreas On Sun, Mar 15, 2009 at 16:17, Supun Kamburugamuva wrote: > If setting 200 in case of a Hessian fault is a must, why don't we do it in > the HessianMessageFormatter? My be I'm missing something :) > > Thanks, > Supun. > > On Sun, Mar 15, 2009 at 4:05 PM, Andreas Veithen > wrote: >> >> Just throwing an idea into the discussion: What about an Axis2 module? >> >> Andreas >> >> On Sun, Mar 15, 2009 at 00:11, Hubert, Eric >> wrote: >> > I thought it might be useful for discussion to also have some sample >> > code to illustrate b). >> > >> > Please find attached a quick implementation showing the idea. >> > >> > Regards, >> > Eric >> > >> > >> >> Hi all, >> >> >> >> if someone wants to use the FaultMediator in conjunction with Hessian >> >> messages he has to know that he to set the HTTP status code to 200, >> >> after >> >> using the FaultMediator and before using the SendMediator. >> >> >> >> Normally (for SOAP messages) the HTTP status code is 500, but Ruwan >> >> once >> >> created a possibility to override this value using a property of scope >> >> Axis2. >> >> >> >> So declaratively this is possible in synapse.xml via adding the >> >> following >> >> configuration block: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> The HessianFormatter transforms the SOAPFault to a Hessian fault and >> >> writes a valid Hessian fault message to the client, which deserializes >> >> the >> >> fault message to a HessianServiceException with the proper message. >> >> This only works if the HTTP status code is 200. Any other messages will >> >> not be deserialized by the Hessian Client libraries. >> >> >> >> I guess most people trying out the Hessian support would stumple over >> >> this >> >> issue. I see two possibilities and would like to here your opinion. >> >> >> >> a) Document this behaviour and the needed configuration online. >> >> b) Extend the FaultMediator to set this property programmatically >> >> depending on the content-type header. >> >> >> >> I see advantages and disadvantages with both approaches. Currently the >> >> FaultMediator is already handling the differences between SOAP 1.1, >> >> SOAP >> >> 1.2 and POX. This would need three of four more lines as well as the >> >> duplication or a move of a content-type constant for "x- >> >> application/hessian" as for sure a dependency from the core to the >> >> extensions module must not exist. >> >> >> >> Anyone having a clever option c in mind? Comments are welcome! >> >> >> >> 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 >> > > > > -- > Software Engineer, WSO2 Inc > http://wso2.org > supunk.blogspot.com > > > - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter
If setting 200 in case of a Hessian fault is a must, why don't we do it in the HessianMessageFormatter? My be I'm missing something :) Thanks, Supun. On Sun, Mar 15, 2009 at 4:05 PM, Andreas Veithen wrote: > Just throwing an idea into the discussion: What about an Axis2 module? > > Andreas > > On Sun, Mar 15, 2009 at 00:11, Hubert, Eric > wrote: > > I thought it might be useful for discussion to also have some sample code > to illustrate b). > > > > Please find attached a quick implementation showing the idea. > > > > Regards, > > Eric > > > > > >> Hi all, > >> > >> if someone wants to use the FaultMediator in conjunction with Hessian > >> messages he has to know that he to set the HTTP status code to 200, > after > >> using the FaultMediator and before using the SendMediator. > >> > >> Normally (for SOAP messages) the HTTP status code is 500, but Ruwan once > >> created a possibility to override this value using a property of scope > >> Axis2. > >> > >> So declaratively this is possible in synapse.xml via adding the > following > >> configuration block: > >> > >> > >> > >> > >> > >> > >> > >> The HessianFormatter transforms the SOAPFault to a Hessian fault and > >> writes a valid Hessian fault message to the client, which deserializes > the > >> fault message to a HessianServiceException with the proper message. > >> This only works if the HTTP status code is 200. Any other messages will > >> not be deserialized by the Hessian Client libraries. > >> > >> I guess most people trying out the Hessian support would stumple over > this > >> issue. I see two possibilities and would like to here your opinion. > >> > >> a) Document this behaviour and the needed configuration online. > >> b) Extend the FaultMediator to set this property programmatically > >> depending on the content-type header. > >> > >> I see advantages and disadvantages with both approaches. Currently the > >> FaultMediator is already handling the differences between SOAP 1.1, SOAP > >> 1.2 and POX. This would need three of four more lines as well as the > >> duplication or a move of a content-type constant for "x- > >> application/hessian" as for sure a dependency from the core to the > >> extensions module must not exist. > >> > >> Anyone having a clever option c in mind? Comments are welcome! > >> > >> 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 > > -- Software Engineer, WSO2 Inc http://wso2.org supunk.blogspot.com
Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Just throwing an idea into the discussion: What about an Axis2 module? Andreas On Sun, Mar 15, 2009 at 00:11, Hubert, Eric wrote: > I thought it might be useful for discussion to also have some sample code to > illustrate b). > > Please find attached a quick implementation showing the idea. > > Regards, > Eric > > >> Hi all, >> >> if someone wants to use the FaultMediator in conjunction with Hessian >> messages he has to know that he to set the HTTP status code to 200, after >> using the FaultMediator and before using the SendMediator. >> >> Normally (for SOAP messages) the HTTP status code is 500, but Ruwan once >> created a possibility to override this value using a property of scope >> Axis2. >> >> So declaratively this is possible in synapse.xml via adding the following >> configuration block: >> >> >> >> >> >> >> >> The HessianFormatter transforms the SOAPFault to a Hessian fault and >> writes a valid Hessian fault message to the client, which deserializes the >> fault message to a HessianServiceException with the proper message. >> This only works if the HTTP status code is 200. Any other messages will >> not be deserialized by the Hessian Client libraries. >> >> I guess most people trying out the Hessian support would stumple over this >> issue. I see two possibilities and would like to here your opinion. >> >> a) Document this behaviour and the needed configuration online. >> b) Extend the FaultMediator to set this property programmatically >> depending on the content-type header. >> >> I see advantages and disadvantages with both approaches. Currently the >> FaultMediator is already handling the differences between SOAP 1.1, SOAP >> 1.2 and POX. This would need three of four more lines as well as the >> duplication or a move of a content-type constant for "x- >> application/hessian" as for sure a dependency from the core to the >> extensions module must not exist. >> >> Anyone having a clever option c in mind? Comments are welcome! >> >> 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
RE: Creating HessianFaults using FaultMediator/HessianMessageFormatter
I thought it might be useful for discussion to also have some sample code to illustrate b). Please find attached a quick implementation showing the idea. Regards, Eric > Hi all, > > if someone wants to use the FaultMediator in conjunction with Hessian > messages he has to know that he to set the HTTP status code to 200, after > using the FaultMediator and before using the SendMediator. > > Normally (for SOAP messages) the HTTP status code is 500, but Ruwan once > created a possibility to override this value using a property of scope > Axis2. > > So declaratively this is possible in synapse.xml via adding the following > configuration block: > > > > > > > > The HessianFormatter transforms the SOAPFault to a Hessian fault and > writes a valid Hessian fault message to the client, which deserializes the > fault message to a HessianServiceException with the proper message. > This only works if the HTTP status code is 200. Any other messages will > not be deserialized by the Hessian Client libraries. > > I guess most people trying out the Hessian support would stumple over this > issue. I see two possibilities and would like to here your opinion. > > a) Document this behaviour and the needed configuration online. > b) Extend the FaultMediator to set this property programmatically > depending on the content-type header. > > I see advantages and disadvantages with both approaches. Currently the > FaultMediator is already handling the differences between SOAP 1.1, SOAP > 1.2 and POX. This would need three of four more lines as well as the > duplication or a move of a content-type constant for "x- > application/hessian" as for sure a dependency from the core to the > extensions module must not exist. > > Anyone having a clever option c in mind? Comments are welcome! > > Regards, > Eric FaultMediator.java.patch Description: FaultMediator.java.patch - To unsubscribe, e-mail: dev-unsubscr...@synapse.apache.org For additional commands, e-mail: dev-h...@synapse.apache.org
RE: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Hi Ruwan, yes I certainly understand this concern and am also looking for a clean approach. You are right it is basically the question whether the fault mediator is allowed to contain application protocol specific logic besides the already existing SOAP-logic (which is actually also application protocol specific logic). It is not really the core which would be aware of the hessian protocol, but a mediator being part of the current synapse core Maven module. I think subclassing the FaultMediator to create a Hessian-aware mediator in the extensions-module would be possible, but would not be worth the code overhead. I will continue to think about it... Thanks, Eric From: Ruwan Linton [mailto:ruwan.lin...@gmail.com] Sent: Saturday, March 14, 2009 7:44 PM To: dev@synapse.apache.org Subject: Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter Hi Eric, While fixing the HTTP status code issue which we found earlier, I have thought of many ways of fixing this, but all of that ended up with making the synapse core aware of hessian behaviors which is sort of not good. There fore I only see the option (a) as the possible approach that we can take, may be we could add this bit of logic to the Fault mediator because that is a mediator but not the core of synapse, so the fault mediator is aware of the hessian protocol. Thanks, Ruwan On Sat, Mar 14, 2009 at 11:43 PM, Hubert, Eric wrote: Hi all, if someone wants to use the FaultMediator in conjunction with Hessian messages he has to know that he to set the HTTP status code to 200, after using the FaultMediator and before using the SendMediator. Normally (for SOAP messages) the HTTP status code is 500, but Ruwan once created a possibility to override this value using a property of scope Axis2. So declaratively this is possible in synapse.xml via adding the following configuration block: The HessianFormatter transforms the SOAPFault to a Hessian fault and writes a valid Hessian fault message to the client, which deserializes the fault message to a HessianServiceException with the proper message. This only works if the HTTP status code is 200. Any other messages will not be deserialized by the Hessian Client libraries. I guess most people trying out the Hessian support would stumple over this issue. I see two possibilities and would like to here your opinion. a) Document this behaviour and the needed configuration online. b) Extend the FaultMediator to set this property programmatically depending on the content-type header. I see advantages and disadvantages with both approaches. Currently the FaultMediator is already handling the differences between SOAP 1.1, SOAP 1.2 and POX. This would need three of four more lines as well as the duplication or a move of a content-type constant for "x-application/hessian" as for sure a dependency from the core to the extensions module must not exist. Anyone having a clever option c in mind? Comments are welcome! Regards, Eric -- 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
Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Hi Eric, While fixing the HTTP status code issue which we found earlier, I have thought of many ways of fixing this, but all of that ended up with making the synapse core aware of hessian behaviors which is sort of not good. There fore I only see the option (a) as the possible approach that we can take, may be we could add this bit of logic to the Fault mediator because that is a mediator but not the core of synapse, so the fault mediator is aware of the hessian protocol. Thanks, Ruwan On Sat, Mar 14, 2009 at 11:43 PM, Hubert, Eric wrote: > Hi all, > > if someone wants to use the FaultMediator in conjunction with Hessian > messages he has to know that he to set the HTTP status code to 200, after > using the FaultMediator and before using the SendMediator. > > Normally (for SOAP messages) the HTTP status code is 500, but Ruwan once > created a possibility to override this value using a property of scope > Axis2. > > So declaratively this is possible in synapse.xml via adding the following > configuration block: > > > > > > > > The HessianFormatter transforms the SOAPFault to a Hessian fault and writes > a valid Hessian fault message to the client, which deserializes the fault > message to a HessianServiceException with the proper message. > This only works if the HTTP status code is 200. Any other messages will not > be deserialized by the Hessian Client libraries. > > I guess most people trying out the Hessian support would stumple over this > issue. I see two possibilities and would like to here your opinion. > > a) Document this behaviour and the needed configuration online. > b) Extend the FaultMediator to set this property programmatically depending > on the content-type header. > > I see advantages and disadvantages with both approaches. Currently the > FaultMediator is already handling the differences between SOAP 1.1, SOAP 1.2 > and POX. This would need three of four more lines as well as the duplication > or a move of a content-type constant for "x-application/hessian" as for sure > a dependency from the core to the extensions module must not exist. > > Anyone having a clever option c in mind? Comments are welcome! > > Regards, > Eric > -- 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