[esb-issues] [JBoss JIRA] Closed: (JBESB-3276) soapui client fails to load multiple interfaces if authentication required

[ https://jira.jboss.org/browse/JBESB-3276?page=com.atlassian.jira.plugin.s... ] David Ward closed JBESB-3276. ----------------------------- Resolution: Done I was able to recreate the bug by hacking up the webservice_proxy_security (1) and webservice_consumer1 (2) quickstarts. In (1) I changed the SOAPAction from "" to "sayHello" (because SOAPClient requires it) then I created a custom WSDL, where I added a second port binding (soap12) to the service. This wsdl was served up from (1)'s war file via SSL. Then, I changed (2)'s jboss-esb.xml so that it loads (1)'s modified wsdl over SSL, using a copy of httpclient-8443.properties from (2). When I ran "ant runtest" from (1), I was able to see the same exact stack trace from the help desk ticket. So far so good. The problem was not *exactly* what we first thought. It is true that soapUI's UrlWsdlLoader was being used instead of our EsbWsdlLoader. However, setting the WsdlContext loaded with our EsbWsdlLoader on the rest of the returned WsdlInterface[] array elements (or even make them use a shared DefinitionCache) is TOO LATE by that point. soapUI kicks off a SwingWorker Thread from inside private code that ends up using a UrlWsdlLoader before we get a chance to do anything about it! The options then become either change soapUI code and re-build it ourselves, or create a JBoss AOP aspect that intercepts calls to soapUI's WsdlContext$Loader.getWsdlLoader() so that our EsbWsdlLoader is always returned. The later option (using JBoss AOP) is what I did. This was accomplished by setting the correct EsbWsdlLoader into an InheritableThreadLocal<WsdlLoader> variable which the aspect checks for, and if present, will always use that as the WsdlLoader. Then, clear out the InheritableThreadLocal<WsdlLoader> in a finally block. These are done in SoapUIClientService.getWsdlInterfaces(String,Properties). The soapUI SwingWorker Thread (which is waited on inside soapUI code from behind WsdlImporter -> WsdlContext$Loader) will then have access to the InheritableThreadLocal<WsdlLoader>, and always use our EsbWsdlLoader. I validated this fix using the recreated scenario on both JBoss AS 4 + JDK 1.5.0_22 and JBoss AS 5 + JDK 1.6.0_20. I also regression tested both standard webservice_consumer1 and webservice_consumer2 quickstarts to make sure I didn't break anything. Finally I ran a clean integration build. Now, this work MIGHT become moot if we end up having time to upgrade soapUI from 1.7.x to the latest version as noted in JBESB-3274, but we needed this fix in case we don't have time or if the upgrade becomes too problematic or risky for 4.9. [trunk]$ svn commit Sending product/.classpath Sending product/services/base-project-build.xml ... Adding product/services/soapui-client/aop/java/org/jboss/soa/esb/services/soapui/WsdlLoaderAspect.java ... Adding product/services/soapui-client/aop/resources/META-INF/jboss-aop.xml Sending product/services/soapui-client/build.xml Sending product/services/soapui-client/src/main/java/org/jboss/soa/esb/services/soapui/SoapUIClientService.java Sending product/services/soapui-client/src/main/resources/META-INF/jboss-structure.xml Transmitting file data ....... Committed revision 33531. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira