6 Replies Latest reply on Apr 16, 2010 9:04 AM by dward

    Problems loading WSDL with SOAPProxy

    doudl

      I'm trying to load a WSDL using the classpath.  The wsdl file is called NotifyConsumer.wsdl, and it is a directory called "wsdl" within the ESB deployment.

       

      The wsdl property of the SOAPProxy action was configured using the following:

       

      <property name="wsdl" value="classpath://wsdl/NotifyConsumer.wsdl"/>

       

       

      When deploying the ESB file I get the following stack trace:

       

      Caused by: java.lang.IllegalArgumentException: URL cannot be null
          at org.jboss.ws.tools.wsdl.WSDLDefinitionsFactory.parse(WSDLDefinitionsFactory.java:99)
          at org.jboss.soa.esb.actions.soap.proxy.SOAPProxyWsdlLoader.loadDefinitions(SOAPProxyWsdlLoader.java:102)
          at org.jboss.soa.esb.actions.soap.proxy.SOAPProxy.<init>(SOAPProxy.java:145)
          ... 125 more

       

      I stepped through this with a debugger and found some interesting....

       

      SOAPProxyWsdlLoader uses ClassUtil.getResource (line 226) to find the "wsdl_url" and it passes SOAPProxyWsdlLoader.class as the second arg. When ClassUtil.getResource executes it changes the name of the resource from "wsdl/NotifyConsumer.wsdl" to "org/jboss/soa/esb/actions/soap/proxy/wsdl/NotifyConsumer.wsdl". As a result of this name change the wsdl file is not found.

       

      To test my understanding I made a directory structure of "org/jboss/soa/esb/actions/soap/proxy/wsdl" and put NotifyConsumer.wsdl in it, and redeployed the ESB. This time the ESB was successfully deployed.

       

      I think this is a bug unless I misunderstand the configuration options for the action. I wanted to post here first before opening an issue report.

       

      Thanks,

      Leon

        • 1. Re: Problems loading WSDL with SOAPProxy
          dward

          Leon,

           

          The "classpath://" part of the wsl property value is stripped off before classloading.  So, if you don't want the resource to be loaded relatively, you need to add an extra "slash" to make the value "absolute".  So, instead of "classpath://wsdl/NotifyConsumer.wsdl" use "classpath:///wsdl/NotifyConsumer.wsdl" (3 slashes not 2).

           

          Let me know how it goes.  Thanks,

          David

          • 2. Re: Problems loading WSDL with SOAPProxy
            doudl

            Thanks, the additional "/" fixed it. Sorry I didn't catch on to that fact when looking at the code or documentation.

             

            Just curious, is there an example when you would want to use just two slashes?

            • 3. Re: Problems loading WSDL with SOAPProxy
              dward

              Probably not.  But I just wanted to be consistent for what an "absolute" path looks like.  For example, "file:///home/dward" is what I type into my web browser when I want to open my home directory.

              • 4. Re: Problems loading WSDL with SOAPProxy
                doudl

                After restarting the server I noticed the WSDL was no longer loading. If I "touch" the jboss-esb.xml file and trigger a hot redeploy the WSDL does load and I can access it via a browser pointed at the ESB.

                 

                At first I suspected a classloading issue, so I reconfigured the path of the WSDL to use file:///path/to/file.wsdl (notice the three slashes). This did not work on server startup, but triggering a hot redploy did cause WSDL to load.

                 

                Perhaps this is a startup order problem? I didn't see any errors in the log file though.

                • 5. Re: Problems loading WSDL with SOAPProxy
                  doudl

                  Sorry about posting without checking the other new postings. I suspect my problem is related to:

                   

                  https://jira.jboss.org/jira/browse/JBESB-3255

                  • 6. Re: Problems loading WSDL with SOAPProxy
                    dward

                    No worries, Leon.  Yes, JBESB-3255 documents the most likely cause of your issue.  Please upgrade to ESB 4.8 and verify your issue has been fixed.  Thank you.