Add some error handling in the WSDL Stock Quote example to detect if the service is down (i.e. HTML payload is received)

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Priority: Minor Minor
  • Resolution: Unresolved
  • Affects Version/s: 1.4.1
  • Fix Version/s: None
  • Component/s: Examples / Tutorials
  • Labels:
    None
  • User impact:
    Medium
  • Similar Issues:
    None

Description

We should ind a generic way of handling this since most .Net web services retrun HTML not SOAP faults. genius. See MULE-1613.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Holger Hoffstaette added a comment -

A frightening idea: could the SOAP message adapters peek for <html> and wrap that into a fault - maybe as an option so that it can be turned off?

Show
Holger Hoffstaette added a comment - A frightening idea: could the SOAP message adapters peek for <html> and wrap that into a fault - maybe as an option so that it can be turned off?
Hide
Permalink
Holger Hoffstaette added a comment -

Alternatively we could try to test for the response content-type, i.e. text/html vs. xml

Show
Holger Hoffstaette added a comment - Alternatively we could try to test for the response content-type, i.e. text/html vs. xml
Hide
Permalink
Lajos Moczar added a comment -

Somebody is reading my mind. A couple of hours ago I set up a test case for a service that is indeed down so I could figure out more intelligent error handling. So far, sadly, it is failing with the proper error being thrown but I'm trying to break it

Show
Lajos Moczar added a comment - Somebody is reading my mind. A couple of hours ago I set up a test case for a service that is indeed down so I could figure out more intelligent error handling. So far, sadly, it is failing with the proper error being thrown but I'm trying to break it
Hide
Permalink
Ross Mason added a comment -

Testing for the content-type is probably the best way to go.

Show
Ross Mason added a comment - Testing for the content-type is probably the best way to go.
Hide
Permalink
Lajos Moczar added a comment -

This is more complicated than it sounds. On external calls, the MessageAdapter isn't used; the Object[] response is wrapped in a MuleMessage. And sadly, the only webservicex.net service that is done, returns a proper SOAP fault So, after looking thru the XFire source and testing various things, I conclude that the best way to deal with this is via a connector property that specifies whether to throw an exception if response[0] mimetype does not match xml. This has to be configured by the user, no defaulting here, as there are valid services (like the Currency Converter example I posted in the wiki last week) that don't return xml.

Show
Lajos Moczar added a comment - This is more complicated than it sounds. On external calls, the MessageAdapter isn't used; the Object[] response is wrapped in a MuleMessage. And sadly, the only webservicex.net service that is done, returns a proper SOAP fault So, after looking thru the XFire source and testing various things, I conclude that the best way to deal with this is via a connector property that specifies whether to throw an exception if response[0] mimetype does not match xml. This has to be configured by the user, no defaulting here, as there are valid services (like the Currency Converter example I posted in the wiki last week) that don't return xml.
Hide
Permalink
Holger Hoffstaette added a comment -

Webservicex may return a proper fault when it's up and used incorrectly, but definitely not when it's down (otherwise there wouldn't be HTML in the response). Might be because the service itself is proxied by a webserver in front of it which returns the "error page" in HTML when the service is down.

Show
Holger Hoffstaette added a comment - Webservicex may return a proper fault when it's up and used incorrectly, but definitely not when it's down (otherwise there wouldn't be HTML in the response). Might be because the service itself is proxied by a webserver in front of it which returns the "error page" in HTML when the service is down.
Hide
Permalink
Lajos Moczar added a comment -

All that is academic, in fact. The XFire dynamic client, which we are using here, seems to only return primitives. So there is no mime type to use. Basically, we get a java.lang.String for both normal and error invocations of stockquote. We can a java.lang.Double for invocations of the currency converter. However you look at it, if you get a non-XML error, can have no good way to trap it. Unless we want to hack xfire, of course . I think I will close this as "will not fix", since any solution will be fairly complex.

Show
Lajos Moczar added a comment - All that is academic, in fact. The XFire dynamic client, which we are using here, seems to only return primitives. So there is no mime type to use. Basically, we get a java.lang.String for both normal and error invocations of stockquote. We can a java.lang.Double for invocations of the currency converter. However you look at it, if you get a non-XML error, can have no good way to trap it. Unless we want to hack xfire, of course . I think I will close this as "will not fix", since any solution will be fairly complex.
Hide
Permalink
Ross Mason added a comment -

I'd imaging we can hook in a handler of sort to get the Http Soap Response and determine the error. Not sure how we pass that back to Mule though...

Show
Ross Mason added a comment - I'd imaging we can hook in a handler of sort to get the Http Soap Response and determine the error. Not sure how we pass that back to Mule though...

People

  • Assignee:
    Unassigned
    Reporter:
    Ross Mason
Vote (0)
Watch (0)

Dates

  • Created:
    Updated: