Forum Discussion

KPost's avatar
KPost
New Contributor
17 years ago

Mock Response problem handling WSDL with multi levels of xsd:includes

When a test case Mock Response step is emulating an operation defined in a WSDL file that xsd:includes's an XSD file which in turn xsd:includes another XSD file, the WSDL published by the Mock Response step will not be valid.

I know the above description sounds confusing so let me give an example.

Suppose the WSDL is structured as follows:

 
   
       
        ….
   

 

  ….


And AppSpecificTypes.xsd is structured as follows:

   
    ….


The contents of CommonTypes.xsd are not important to describing the bug.

Given the above structure for WSDL and XSD’s causes soapUI to generate WSDL of the following form from its mock response service:

 
   
       
        ….
   

 

  ….


So far, so good. 
The problem comes in when you fetch the XSD included from the WSDL.   Fetching the XSD from the URL provided by soapUI in the WSDL returns XSD of the following format:

   
    ….


The bug is that the schemaLocation generated by soapUI in the above XSD is incorrect.  Instead of including a different URL for the CommonTypes.xsd file, the URL generated by soapUI points back to the same XSD file.  The result is an XSD file that just re-includes itself.

Thanks for looking into this problem,

Kurt

8 Replies

  • omatzura's avatar
    omatzura
    Super Contributor
    Hi Kurt,

    Thanks for reporting! hm.. I can't reproduce this straight from your description. What soapUI version are you using? Are there any other includes/imports in your wsdl/xsds that you didn't mention that might be "confusing" soapUI?

    If possible, please mail me the wsdls/xsds (ole@eviware.com) so I can test locally..

    regards!

    /Ole
    eviware.com
  • KPost's avatar
    KPost
    New Contributor
    Thanks for the quick reply Ole.

    I am using soapUI Pro 2.0 (Build soapuipro-dist-278, Build Date 2007/12/12 19:45).

    I took a look at the sample wsdl and xsd's you posted and the only difference in structure I see is that your wsdl is using xs:import instead of xs:include.

    Another possible difference is that my WSDL is being pulled from WSDL generated by a web service as oposed to using files in the file system. 
    So my WSDL source is something like
    http://localhost:8080/idmsws/enrollment ... point?wsdl

    I'll try loading WSDL from the file system instead and see if that makes a difference.

    Thanks,

    Kurt
  • omatzura's avatar
    omatzura
    Super Contributor
    Thanks,

    I've found one bug now which occurs if the the included/imported urls are the same resource but with different query-strings, but that wasn't your case, right?

    (ie if there are two includes for schema.xsd?id=0 and schema.xsd?id=1, the generated WSDL will treat these as the same URL.. )

    regards,

    /Ole
    eviware.com
  • omatzura's avatar
    omatzura
    Super Contributor
    Great!

    Then we found the same bug.. a relief :-) I'll fix this over the weekend and will publish a patched jar after that.. thanks for reporting!

    regards,

    /Ole
    eviware.com
  • KPost's avatar
    KPost
    New Contributor
    Thanks for the quick fix Ole.

    Would I find the patched jar in the maven repository on your site or do you publish patches elsewhewre?

    Thanks,

    Kurt
  • omatzura's avatar
    omatzura
    Super Contributor
    Hi Kurt,

    this will be part of the upcoming 2.0.3 release, there have been some other changes that make publishing of a patched 2.0.2 jar not possible..

    sorry for the inconvenience..

    and again thanks for reporting!

    regards,

    /Ole
    eviware.com