[teiid-designer-issues] [JBoss JIRA] Resolved: (TEIIDDES-301) Queries against web services that aren't running makes Designer inoperative (because of bug in Apache Axis)

Queries against web services that aren't running makes Designer inoperative (because of bug in Apache Axis) ----------------------------------------------------------------------------------------------------------- Key: TEIIDDES-301 URL: https://jira.jboss.org/browse/TEIIDDES-301 Project: Teiid Designer Issue Type: Bug Components: Teiid Integration, VDB & Execution Affects Versions: 7.1 Environment: 5.5SP3 GA Designer on Linux Reporter: Greg Haber Attachments: axis-error.txt, wsTest1_20081211_1.zip When putting together the new 5.5SP3 sales demo, I noticed that if I forgot to start the web service's container before I started Designer, and then tried to query against that web service, I would get an error message (as expected), but if I then started up the web service and retried my query in that same Designer instance, I would get a MetaMatrixException. I would need to shut down Designer and restart it to then be able to successfully query the web service. I've attached the model project set for those who want to reproduce. The actual web service .aar file and instructions on using it are on JBEDSP-850. For those trying to reproduce, note that I can only reproduce when the machine running the web service is up and reachable, but the container hosting the web service is not running (you need to get a java.net.ConnectException - if you get an UnknownHostException we do for some reason survive that). I dug deeper into this and found that the initial exception I was seeing pop up in Designer was not in fact getting logged to the Designer message log. And on Designer's stdout, I saw the messages that I've attached as axis-error.txt. If you look at the exception you'll see that what is happening is that when we try to call printStackTrace on the exception, all sorts of Apache Axis stuff kicks in and the message logging fails. I traced this issue back to com.metamatrix.connector.xml.soap.SOAPExecutor, where we have in the executeCall method the following: } catch (AxisFault e) { throw new ConnectorException(e); I found that if I changed this to } catch (AxisFault e) { throw new ConnectorException(e.getMessage()); to avoid passing back the AxisFault, then the error message about the java.net.ConnectException would be recorded in the Designer message log, and also that I could start up the web service and then retry my query in Designer successfully (without restarting Designer). So it looks like we need to look at not only the XML-Relational Connector, but any other connectors that use Axis and throw AxisFault, to make sure we parse out the contents of the AxisFault and return those contents safely back when we throw ConnectorException. I also thought about opening up a separate JIRA that the core MetaMatrix code should be able to handle when something went funny when we called printStackTrace on a ConnectorException. I ran this by one of the JBDS developers that sits near me, and he said that he thought that it was reasonable to assume that calling printStackTrace on any subclass of java.lang.Exception (such as AxisFault) should just work without having subclass-specific stuff available - so this isn't something we should need to protect against - that this is really poor design in Apache Axis, and since this is an exception to normal Exception behavior he recommended just protecting against this one subclass of Exception (AxisFault) like in my workaround above.