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

[David Ward (JIRA)]

     [ https://jira.jboss.org/browse/JBESB-3276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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.

> soapui client fails to load multiple interfaces if authentication required
> --------------------------------------------------------------------------
>
>                 Key: JBESB-3276
>                 URL: https://jira.jboss.org/browse/JBESB-3276
>             Project: JBoss ESB
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web Services
>    Affects Versions: 4.7
>            Reporter: Kevin Conner
>            Assignee: David Ward
>             Fix For: 4.9
>
>
> The reason for this is that only the last interface contains the wsdl context loaded using our httpclient, forcing prior interfaces to reload using the UrlWsdlLoader.  This does not have knowledge of the authentication as we place it on the httpclient and it instantiates its own httpclient.

-- 
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