WSDL generation issue when xsds import other xsds [SWS-362]

[gregturn]

olivier opened SWS-362 and commented

This issue is linked to the following thread http://forum.springframework.org/showthread.php?p=176210

I store my schemas in a specific maven project together with the generated sources.

client-messages.xsd import client-types.xsd

In my war project, I configured the Spring-WS config file this way:

<bean id="schemaCollection" class="org.springframework.xml.xsd.commons.CommonsXsdSchemaCollection">
<property name="xsds">
<list>
<value>classpath:client-messages.xsd</value>
</list>
</property>
<property name="inline" value="true" />
</bean>

When generating the wsdl, the framework complains that the client-types.xsd is not found.

Would it be possible to enhance the XsdSchemaCollection (or to write a specific org.apache.ws.commons.schema.resolver.URIResolver) which can handle the import nicely ?

Workaround is twofolds:

• put the xsds in the war file
• merge the xsds in one single file (no more import statement)

---

Referenced from: commits 341aad6

1 votes, 2 watchers

[gregturn]

Gregory bonk commented

I got tripped up on this and I'm wondering if it's me ( probably ) or a flaw in the implementation. I'm using spring-xml-2.0.2.RELEASE.jar

I have an issue with the following line....

// let's try and find it on the classpath, see SWS-362
String classpathLocation = ResourceLoader.CLASSPATH_URL_PREFIX + "/" + schemaLocation;

Now that schema locations are beiing read in like resources on the classpath, I think they should be required to be defined as classpath resources.

I have some XSDs that are in the default package and others that are in/multi/level/packages. With the defaulted "/" being added the naming in our XSDs gets messed up.

   schemaLocation="/schema_1_3.xsd" />

   schemaLocation="revision/common/locale/schema_1_3.xsd" />

In the first case the double "//" messes things up.

[gregturn]

Arjen Poutsma commented

Closing old issues