Allow alternative schema location in XsdBasedSoap11Wsdl4jDefinitionBuilder [SWS-104]

[gregturn]

Aleksei Valikov opened SWS-104 and commented

I am using XsdBasedSoap11Wsdl4jDefinitionBuilder to generate WSDL for my schema.
The schema itself imports another schema via a relative path:

<xsd:import namespace="https://hyperjaxb2.dev.java.net/pows/po/schema" schemaLocation="../../po/schema/po.xsd"/>

The WSDL itself is generated quite fine. However the schema itself is simply inserted into wsdl:types while schemaLocation in xsd:import remains the same. However, this location, when resolved against the wsdl location, points to an invalid URL.

<?xml version="1.0" encoding="UTF-8"?>

<wsdl:definitions ...>
wsdl:types
<xsd:schema ...>
...
<xsd:import namespace="https://hyperjaxb2.dev.java.net/pows/po/schema" schemaLocation="../../po/schema/po.xsd"/>
...
</xsd:schema>
</wsdl:types>
...
</wsdl:definitions>

This problem can be easily resolved if instead of inserting the whole schema in wsdl:types we simply insert an xsd:schema with xsd:import pointing to the location of the actual schema. This location can be configured in the wsdl builder:

<wsdl:definitions ...>
wsdl:types
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:import
namespace="https://hyperjaxb2.dev.java.net/pows/ws/schema"
schemaLocation="resources/ws/schema/ws.xsd"/>
</xsd:schema>
</wsdl:types>
</wsdl:definitions>

I have implemented this solution based on the XsdBasedSoap11Wsdl4jDefinitionBuilder. Could you please review the code and maybe add this to the main code base.

---

Affects: 1.0 M3

Attachments:

• SchemaBasedSoap11Wsdl4jDefinitionBuilder.java (2.62 kB)

Issue Links:

• The XsdBasedSoap11Wsdl4jDefinitionBuilder does not support multiple xsds in generating a WSDL file. [SWS-162] #316 The XsdBasedSoap11Wsdl4jDefinitionBuilder does not support multiple xsds in generating a WSDL file.

Referenced from: commits fcdcf61

6 votes, 3 watchers

[gregturn]

Aleksei Valikov commented

My solution.

[gregturn]

Aleksei Valikov commented

Configuration:

<bean id="pows" class="org.springframework.ws.wsdl.wsdl11.DynamicWsdl11Definition">
<property name="builder">
<bean class="org.jvnet.hyperjaxb2.pows.ws.wsdl.wsdl11.builder.SchemaBasedSoap11Wsdl4jDefinitionBuilder">
<property name="schema" value="classpath:org/jvnet/hyperjaxb2/pows/ws/schema/ws.xsd"/>
<property name="schemaLocation" value="../resources/ws/schema/ws.xsd"/>
<property name="schemaPrefix" value="pows"/>
<property name="portTypeName" value="pows"/>
<property name="locationUri" value="http://localhost:8080/pows/"/>
</bean>
</property>
</bean>

[gregturn]

Arjen Poutsma commented

If I understand this code correctly, it requires the schema to be exposed in web application, which is not necessary for the standard XsdBasedSoap11Wsdl4jDefinitionBuilder (i.e. schemas can be in /WEB-INF, or on the classpath for instance).

Another way to solve this would be to inline all referenced schema's as well as the original schema. In your example, this means that we inline the elements found in po.xsd right into the WSDL. I think I prefer this solution, because it does not require the schema's to be exposed.

Is that acceptable?

[gregturn]

Aleksei Valikov commented

I does not requires the schema to be exposed in a web app, it simply allows this possibility. If schemaLocation is specified then wsdl will import the schema from this location. In not, the schema will be inlined like in the standard builder.

In the case of the standard builder I really have problem that imported schemas simply can't be accessed.

As for inlining imported schema - I think this is (1) technically complex and (2) not reasonable. Think of large schemas like UBL or whatever else which are up to several megabytes in size. Or something like CSW/OpenGIS schemas which are quite complex in importing structure. After all, the schema is always exposed, either inlined in WSDL or externally. I think it is important to offer both possibilities.

ps. I'm using Weblets to expose classpath resources (like schemas which are somewhere on the classpath).

[gregturn]

Arjen Poutsma commented

I'm afraid I don't have the time to put this in the 1.0 release. I will move it further in the release schedule, also because I am unsure as to how useful this is to other users.

Please let me know if you want this functionality in the main release by voting for it!

[gregturn]

Arjen Poutsma commented

Sorry it took so long, but I've added this feature. Thanks for the code!

Rather than creating a subclass, I've put the functionality in the XsdBasedSoap11Wsdl4jDefinitionBuilder itself.

[gregturn]

Aleksei Valikov commented

Nice, thank you!

[gregturn]

Arjen Poutsma commented

One issue with imports still remains. Suppose we have two schemas: A.xsd and B.xsd. A imports B. We register A.xsd with the XsdBasedSoap11Wsdl4jDefinitionBuilder , and use the schemaLocation property.

All goes well when all the request and response elements are in A. However, when B also contains request and response elements that we want to base the WSDL on, it does not work, since the imported schema (B in this case) is not investigated.

Aleksei, do you have any idea how to fix this?

[gregturn]

Aleksei Valikov commented

Well, obviously it need to be investigated then. Why not simply recurse to the imported schema?

The thing is, you follow a rather "syntactic" approach to the processing of XML Schema. Like, you grab all the xsd:elements, consider their names and build operations for those who follow certain naming conventions. It's not a deep kind of XML Schema processing: you don't process xsd:imports or xsd:includes or anything else like that.

An alternative would be using something like XSOM to build and analyze the XML Schema object model. XSOM will handle includes and imports for you, you only need to find out which elements are responsible for requests and responses.

[gregturn]

Arjen Poutsma commented

Yes, recursing into the imported schema is the option I also considered.

Using a framework like XSOM is an interesting option, which relates to #333

[gregturn]

Arjen Poutsma commented

Closing 1.0.1 issues.