Announcement Announcement Module
Collapse
No announcement yet.
Issues with CommonsXsdSchemaCollection Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Issues with CommonsXsdSchemaCollection

    I've hit a couple issues with CommonsXsdSchemaCollection with inline=true, and I'd like to know if these are likely Spring-WS bugs or Apache XmlSchema bugs, so I can work on a test case and reporting them properly.

    The first issue involves the use of the "xml:: prefix & and the "http://www.w3.org/XML/1998/namespace" namespace. When my schemas references other schemas that use that namespace (and the http://www.w3.org/2001/03/xml.xsd schema), the WSDL can't be generated any longer, because the http://www.w3.org/XML/1998/namespace is no longer mapped to the xml: prefix. Currently I'm having to comment out the use of xml namespace in third-party schemas I reference.

    The second issue involves referring to multiple schema files. I want to have separate schema files defining each of my operations. However, only the elements from the first schema I put in the list for the xsds property of CommonsXsdSchemaCollection are found. I've worked around this by making a new schema file that includes the two separate schema files (which is ok because they are in the same namespace). Is this a bug, or is this how it should behave, or..?

    Thanks,
    Stephen

  • #2
    Here's a few more details for my problems that I've discovered while testing.

    The first problem regarding the xml namespace only applies building the WSDL. Validation seems to work fine.

    The second problem regarding only finding elements from the first schema only applies to the PayloadValidatingInterceptor. The WSDL is generated correctly.

    Comment


    • #3
      More problems/info:

      If I don't set inline=true while using the wrapper schema file (that just uses xsd:include on my two real schemas), or if I use the SimpleXsdSchema, then the *Request & *Response message aren't found, and I have a WSDL with no messages or operations. When I do use inline=true with my work-arounds, all the top-level elements from all the referenced schemas are defined as wsdl:message elements, which 1) probably won't scale as I have more third-party schemas (localName conflict), and 2) isn't necessary as far as I know; only the elements used by operations need to be defined, right? At least only the top-level elements from the schema I directly use (but including elements defined in schemas using xs:include) should be used.

      Comment


      • #4
        Originally posted by jrduncans View Post
        The first issue involves the use of the "xml:: prefix & and the "http://www.w3.org/XML/1998/namespace" namespace. When my schemas references other schemas that use that namespace (and the http://www.w3.org/2001/03/xml.xsd schema), the WSDL can't be generated any longer, because the http://www.w3.org/XML/1998/namespace is no longer mapped to the xml: prefix. Currently I'm having to comment out the use of xml namespace in third-party schemas I reference.
        This sounds like something that should be further investigated. Could you please create a JIRA issue for this?

        Originally posted by jrduncans View Post
        The second issue involves referring to multiple schema files. I want to have separate schema files defining each of my operations. However, only the elements from the first schema I put in the list for the xsds property of CommonsXsdSchemaCollection are found. I've worked around this by making a new schema file that includes the two separate schema files (which is ok because they are in the same namespace). Is this a bug, or is this how it should behave, or..?
        This is related to the way XML validation works in Java. There is AFAIK very little I can do about it. The only workaround is - as you suggested - to create a separate schema that includes both.

        Comment


        • #5
          Originally posted by jrduncans View Post
          If I don't set inline=true while using the wrapper schema file (that just uses xsd:include on my two real schemas), or if I use the SimpleXsdSchema, then the *Request & *Response message aren't found, and I have a WSDL with no messages or operations. When I do use inline=true with my work-arounds, all the top-level elements from all the referenced schemas are defined as wsdl:message elements, which 1) probably won't scale as I have more third-party schemas (localName conflict), and 2) isn't necessary as far as I know; only the elements used by operations need to be defined, right? At least only the top-level elements from the schema I directly use (but including elements defined in schemas using xs:include) should be used.
          You are correct: the DefaultWsdl11Definition creates Messages for all elements found in the schema. If you create a JIRA issue, we can create a new MessagesProviders, which only includes elements with the given suffix.

          Comment


          • #6
            Originally posted by Arjen Poutsma View Post
            This sounds like something that should be further investigated. Could you please create a JIRA issue for this?



            This is related to the way XML validation works in Java. There is AFAIK very little I can do about it. The only workaround is - as you suggested - to create a separate schema that includes both.
            Ok, created an issue for the xml namespace issue: http://jira.springframework.org/browse/SWS-339

            Yeah, I started to come to that conclusion as well. Should I make an issue, then, about finding elements for WSDL Operations in included (not imported) schemas when not using inline=true?

            Comment


            • #7
              Originally posted by Arjen Poutsma View Post
              You are correct: the DefaultWsdl11Definition creates Messages for all elements found in the schema. If you create a JIRA issue, we can create a new MessagesProviders, which only includes elements with the given suffix.
              Ok, I created http://jira.springframework.org/browse/SWS-340

              Comment

              Working...
              X