You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by "Hubert, Eric" <Er...@foxmobile.com> on 2009/03/14 19:13:33 UTC
Creating HessianFaults using FaultMediator/HessianMessageFormatter
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:
<syn:switch source="get-property('transport', 'Content-Type')">
<syn:case regex="x-application/hessian">
<syn:property name="HTTP_SC" value="200" scope="axis2"/>
</syn:case>
</syn:switch>
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
RE: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Posted by "Hubert, Eric" <Er...@foxmobile.com>.
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.linton@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
<Er...@foxmobile.com> 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:
<syn:switch source="get-property('transport', 'Content-Type')">
<syn:case regex="x-application/hessian">
<syn:property name="HTTP_SC" value="200" scope="axis2"/>
</syn:case>
</syn:switch>
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: ruwan@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com
Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Posted by Ruwan Linton <ru...@gmail.com>.
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 <Er...@foxmobile.com>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:
>
> <syn:switch source="get-property('transport', 'Content-Type')">
> <syn:case regex="x-application/hessian">
> <syn:property name="HTTP_SC" value="200" scope="axis2"/>
> </syn:case>
> </syn:switch>
>
> 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: ruwan@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com
Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Posted by Ruwan Linton <ru...@gmail.com>.
Hi Eric,
Find my comments inline;
On Mon, Mar 16, 2009 at 3:00 AM, Hubert, Eric <Er...@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 <Er...@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
Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Posted by Supun Kamburugamuva <su...@gmail.com>.
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 <in...@gmail.com>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 <class name=”XMediator”/> 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-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>
--
Software Engineer, WSO2 Inc
http://wso2.org
supunk.blogspot.com
RE: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Posted by "Hubert, Eric" <Er...@foxmobile.com>.
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
Posted by indika kumara <in...@gmail.com>.
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 <class name=”XMediator”/> 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-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Posted by Andreas Veithen <an...@gmail.com>.
Sounds good.
Andreas
On Mon, Mar 16, 2009 at 07:52, Hubert, Eric <Er...@foxmobile.com> 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.linton@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 <as...@apache.org>
> 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: ruwan@wso2.com; cell: +94 77 341 3097
> blog: http://ruwansblog.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Posted by Ruwan Linton <ru...@gmail.com>.
+1
Thanks,
Rwuan
On Mon, Mar 16, 2009 at 12:22 PM, Hubert, Eric <Er...@foxmobile.com>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.linton@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 <as...@apache.org>
> 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: 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
RE: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Posted by "Hubert, Eric" <Er...@foxmobile.com>.
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.linton@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 <as...@apache.org>
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: ruwan@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com
Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Posted by Ruwan Linton <ru...@gmail.com>.
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 <as...@apache.org>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: ruwan@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com
Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Posted by "Asankha C. Perera" <as...@apache.org>.
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
Posted by Andreas Veithen <an...@gmail.com>.
> 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-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
RE: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Posted by "Hubert, Eric" <Er...@foxmobile.com>.
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.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 <an...@gmail.com> wrote:
On Sun, Mar 15, 2009 at 20:36, Hubert, Eric <Er...@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
Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Posted by Ruwan Linton <ru...@gmail.com>.
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
<an...@gmail.com>wrote:
> On Sun, Mar 15, 2009 at 20:36, Hubert, Eric <Er...@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
RE: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Posted by "Hubert, Eric" <Er...@foxmobile.com>.
> >> 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
Posted by Andreas Veithen <an...@gmail.com>.
On Sun, Mar 15, 2009 at 20:36, Hubert, Eric <Er...@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
RE: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Posted by "Hubert, Eric" <Er...@foxmobile.com>.
> 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-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Posted by Andreas Veithen <an...@gmail.com>.
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 <su...@gmail.com> 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 <an...@gmail.com>
> 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 <su...@gmail.com>
>> 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
>> > <an...@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 <Er...@foxmobile.com>
>> >> 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:
>> >> >>
>> >> >> <syn:switch source="get-property('transport', 'Content-Type')">
>> >> >> <syn:case regex="x-application/hessian">
>> >> >> <syn:property name="HTTP_SC" value="200" scope="axis2"/>
>> >> >> </syn:case>
>> >> >> </syn:switch>
>> >> >>
>> >> >> 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-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
>> >>
>> >
>> >
>> >
>> > --
>> > Software Engineer, WSO2 Inc
>> > http://wso2.org
>> > supunk.blogspot.com
>> >
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
>> For additional commands, e-mail: dev-help@synapse.apache.org
>>
>
>
>
> --
> Software Engineer, WSO2 Inc
> http://wso2.org
> supunk.blogspot.com
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Posted by Supun Kamburugamuva <su...@gmail.com>.
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
<an...@gmail.com>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 <su...@gmail.com>
> 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.veithen@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 <Er...@foxmobile.com>
> >> 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:
> >> >>
> >> >> <syn:switch source="get-property('transport', 'Content-Type')">
> >> >> <syn:case regex="x-application/hessian">
> >> >> <syn:property name="HTTP_SC" value="200" scope="axis2"/>
> >> >> </syn:case>
> >> >> </syn:switch>
> >> >>
> >> >> 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-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
> >>
> >
> >
> >
> > --
> > Software Engineer, WSO2 Inc
> > http://wso2.org
> > supunk.blogspot.com
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>
--
Software Engineer, WSO2 Inc
http://wso2.org
supunk.blogspot.com
Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Posted by Andreas Veithen <an...@gmail.com>.
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 <su...@gmail.com> 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 <an...@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 <Er...@foxmobile.com>
>> 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:
>> >>
>> >> <syn:switch source="get-property('transport', 'Content-Type')">
>> >> <syn:case regex="x-application/hessian">
>> >> <syn:property name="HTTP_SC" value="200" scope="axis2"/>
>> >> </syn:case>
>> >> </syn:switch>
>> >>
>> >> 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-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
>>
>
>
>
> --
> Software Engineer, WSO2 Inc
> http://wso2.org
> supunk.blogspot.com
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Posted by Supun Kamburugamuva <su...@gmail.com>.
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
<an...@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 <Er...@foxmobile.com>
> 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:
> >>
> >> <syn:switch source="get-property('transport', 'Content-Type')">
> >> <syn:case regex="x-application/hessian">
> >> <syn:property name="HTTP_SC" value="200" scope="axis2"/>
> >> </syn:case>
> >> </syn:switch>
> >>
> >> 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-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
>
>
--
Software Engineer, WSO2 Inc
http://wso2.org
supunk.blogspot.com
RE: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Posted by "Hubert, Eric" <Er...@foxmobile.com>.
> 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 <Er...@foxmobile.com>
> 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:
> >>
> >> <syn:switch source="get-property('transport', 'Content-Type')">
> >> <syn:case regex="x-application/hessian">
> >> <syn:property name="HTTP_SC" value="200" scope="axis2"/>
> >> </syn:case>
> >> </syn:switch>
> >>
> >> 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-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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
For additional commands, e-mail: dev-help@synapse.apache.org
Re: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Posted by Andreas Veithen <an...@gmail.com>.
Just throwing an idea into the discussion: What about an Axis2 module?
Andreas
On Sun, Mar 15, 2009 at 00:11, Hubert, Eric <Er...@foxmobile.com> 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:
>>
>> <syn:switch source="get-property('transport', 'Content-Type')">
>> <syn:case regex="x-application/hessian">
>> <syn:property name="HTTP_SC" value="200" scope="axis2"/>
>> </syn:case>
>> </syn:switch>
>>
>> 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-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
RE: Creating HessianFaults using FaultMediator/HessianMessageFormatter
Posted by "Hubert, Eric" <Er...@foxmobile.com>.
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:
>
> <syn:switch source="get-property('transport', 'Content-Type')">
> <syn:case regex="x-application/hessian">
> <syn:property name="HTTP_SC" value="200" scope="axis2"/>
> </syn:case>
> </syn:switch>
>
> 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