Announcement Announcement Module
Collapse
No announcement yet.
SimpleWsdl11Definition - xsd files Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • SimpleWsdl11Definition - xsd files

    I would like to use SimpleWsdl11Definition to expose my web service definitions

    but my wsdl file includes xsd files:
    how do I expose those xsd files also?
    (according to the docs, SimpleWsdl11Definition only exposes wsdl files, not xsd files)

    one more thing:
    it would be nice to have SimpleWsdl11Definition accept wildcards in wsdl locations: (eg. /WEB-INF/schema/*.wsdl, /WEB-INF/schema/*.xsd)

  • #2
    I agree, this is one of the major shortcomings of Spring Web Services that forced me to use Apache CXF (or Metro). There is a JIRA issue relating to this that is scheduled for the 1.5 RC release.

    Comment


    • #3
      there is an easy workaround for this, by the way:

      you can put your wsdl + xsd files outside the /WEB-INF/ folder
      so that thay are accessible without any further help from spring-ws

      in this case, you have to map your services to eg. /services/*
      (not to the root of the context)

      Comment


      • #4
        The problem with exposing XSDs is not trivial. XSDs can have imports and includes, which makes it really hard to determine where they should be exposed, in order for the links to work properly.

        I'd rather do this right, than rush a half-baked solution.

        Comment


        • #5
          I believe this is still an issue in Spring-WS 1.5.5; is there any timetable for a fix?

          Thanks

          Alan

          Comment


          • #6
            Just encountered this issue and would like to share how it is done as I couldn't find it in the reference doc or in this forum.

            This issue is supposed to be fixed in 1.5.3 as per JIRAs http://jira.springframework.org/browse/SWS-281 and http://jira.springframework.org/browse/SWS-346. Unfortunately, an example is not given or even the handler class name. Anyway, here is one approach.

            Code:
            	<bean id="MyService" class="org.springframework.ws.wsdl.wsdl11.SimpleWsdl11Definition">
                		<constructor-arg value="/wsdl/MyService.wsdl"/>
            	</bean>
            	
            	<bean id="MySchemaA" class="org.springframework.xml.xsd.SimpleXsdSchema">
            		<property name="xsd" value="/wsdl/MySchemaA.xsd" />
            	</bean>
            	<bean id="MySchemaB" class="org.springframework.xml.xsd.SimpleXsdSchema">
            		<property name="xsd" value="/wsdl/MySchemaB.xsd" />
            	</bean>
            where MyService imports MySchemaA and MySchemaA imports MySchemaB. Then all of them are exposed based on their bean names i.e. http://someUrl/someContext/MyService.wsdl, http://someUrl/someContext/MySchemaA.xsd, http://someUrl/someContext/MySchemaB.xsd.

            Yes, it is that simple but it took me sometime to figure it out. I initially thought that you still need to declare as a bean the handler like

            Code:
            	<bean lass="org.springframework.ws.transport.http.XsdSchemaHandlerAdapter"/>
            so I had to find out the handler class name and how it is supposed to work. But after checking the MessageDispatcherServlet code, it creates that handler automatically for you if none is found. In the end, it is just a matter of declaring the schemas together with SimpleWsdl11Definition.

            This is just one approach. Maybe CommonsXsdSchemaCollection can also be used but haven't tried it.

            Hope this helps.

            Arjen, if this is the correct approach to expose imported XSDs, perhaps it could be mentioned in Section 5.3 of the reference doc? It would save a lot of time to those new to this.

            Thanks.

            Comment


            • #7
              CommonsXsdSchemaCollection will work and will inline all the included xsds. Make sure you include only the xsd as the parameter. You do not need to include the other xsd since the import/include directive already has them.

              Comment


              • #8
                Originally posted by harringf View Post
                CommonsXsdSchemaCollection will work and will inline all the included xsds. Make sure you include only the xsd as the parameter. You do not need to include the other xsd since the import/include directive already has them.
                I think it's the inlining that we are trying to avoid and expose the xsd's as it is. Please read the jiras above.

                Comment


                • #9
                  Multiple xsd

                  I m facing the problem of Mutiple xsd , as mentioned earlier , I have only used the xsd which is parrent
                  Below is config file
                  <bean id="partyservice"
                  class="org.springframework.ws.wsdl.wsdl11.DefaultW sdl11Definition">
                  <property name="schemaCollection">
                  <bean class="org.springframework.xml.xsd.commons.Commons XsdSchemaCollection">
                  <description>
                  This bean wrap the messages.xsd (which imports types.xsd), and inlines them as a one.
                  </description>
                  <property name="xsds">
                  <list>
                  <value>/xsd/service/SOAmods-Party_V1.xsd</value>
                  </list>
                  </property>
                  <property name="inline" value="true"/>
                  </bean>
                  </property>
                  <property name="portTypeName" value="partyservice" />
                  <!-- <property name="followIncludeImport" value="true"/> -->
                  <!--<property name="locationUri" value="http://localhost:8081/partyService/services" /> -->
                  <property name="locationUri" value="/partyservice/services" />

                  </bean>

                  The above xsd has 4 other xsd imported and some of the imported xsd imports other xsd , the wsdl that is genrated has one tag as below
                  <xsd:schema attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="urn:oasis:names:specification:ubl :schema:xsd:CommonExtensionComponents-2">
                  <xsd:import namespace="urn:oasis:names:specification:ubl:schem a:xsd:CommonBasicComponents-2"/>
                  <xsd:include schemaLocation="UBL-ExtensionContentDatatype-2.0.xsd"/>

                  <xsd:element name="UBLExtensions" type="UBLExtensionsType">

                  to get the above schema my client creates aurl some thing like this
                  http://localhost:8084/partyservice/s...tatype-2.0.xsd

                  but cannot return this xsd hence I cannot create a client code ,
                  Please help me to solve this problem

                  Comment


                  • #10
                    If your client needs to see the schema files (.xsd) you should not inline in order to expose them as xsd files. See my previous post and use SimpleXsdSchema

                    Comment


                    • #11
                      This works but...

                      Originally posted by adrian View Post
                      Just encountered this issue and would like to share how it is done as I couldn't find it in the reference doc or in this forum.

                      This issue is supposed to be fixed in 1.5.3 as per JIRAs http://jira.springframework.org/browse/SWS-281 and http://jira.springframework.org/browse/SWS-346. Unfortunately, an example is not given or even the handler class name. Anyway, here is one approach.

                      Code:
                      	<bean id="MyService" class="org.springframework.ws.wsdl.wsdl11.SimpleWsdl11Definition">
                          		<constructor-arg value="/wsdl/MyService.wsdl"/>
                      	</bean>
                      	
                      	<bean id="MySchemaA" class="org.springframework.xml.xsd.SimpleXsdSchema">
                      		<property name="xsd" value="/wsdl/MySchemaA.xsd" />
                      	</bean>
                      	<bean id="MySchemaB" class="org.springframework.xml.xsd.SimpleXsdSchema">
                      		<property name="xsd" value="/wsdl/MySchemaB.xsd" />
                      	</bean>
                      where MyService imports MySchemaA and MySchemaA imports MySchemaB. Then all of them are exposed based on their bean names i.e. http://someUrl/someContext/MyService.wsdl, http://someUrl/someContext/MySchemaA.xsd, http://someUrl/someContext/MySchemaB.xsd.

                      Yes, it is that simple but it took me sometime to figure it out. I initially thought that you still need to declare as a bean the handler like

                      Code:
                      	<bean lass="org.springframework.ws.transport.http.XsdSchemaHandlerAdapter"/>
                      so I had to find out the handler class name and how it is supposed to work. But after checking the MessageDispatcherServlet code, it creates that handler automatically for you if none is found. In the end, it is just a matter of declaring the schemas together with SimpleWsdl11Definition.

                      This is just one approach. Maybe CommonsXsdSchemaCollection can also be used but haven't tried it.

                      Hope this helps.

                      Arjen, if this is the correct approach to expose imported XSDs, perhaps it could be mentioned in Section 5.3 of the reference doc? It would save a lot of time to those new to this.

                      Thanks.
                      I have been unable to get a "correct" schema location in my wsdl (the schema location is not re-written in the import). Were you able to to get a schema location of http://someUrl/someContext/MySchemaA.xsd in your wsdl without hard coding it? My reading of the (closed) jira issues is that this was not implemented. Arjen, is there an open issue or plans to implement some schema location re-writing in the SimplwWsdl11Definition?

                      Comment


                      • #12
                        Alternate Solution

                        An alternate solution is to use Spring's ResourceServlet to serve WSDLs/XSDS. http://forum.springsource.org/showthread.php?t=91536

                        Comment

                        Working...
                        X