Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SchemaCollection issues with classpath resources and relative schema imports [SWS-413] #509

Closed
gregturn opened this issue Aug 12, 2008 · 6 comments
Assignees
Milestone

Comments

@gregturn
Copy link
Member

@gregturn gregturn commented Aug 12, 2008

Patrick Crocker opened SWS-413 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)

Affects: 1.5.3, 1.5.4

Attachments:

Referenced from: commits 7464296

2 votes, 5 watchers

@gregturn
Copy link
Member Author

@gregturn gregturn commented Aug 12, 2008

Patrick Crocker commented

This is a clone of #514 http://jira.springframework.org/browse/SWS-362.

The fix introduced in spring-ws-1.5.4 only satisfies xsd's found at the root of the classpath. The issue is not resolved with respect to xsd files located in packages.

Example:
org/example/schema/messages.xsd
org/example/schema/types.xsd

File messages.xsd uses an import with a relative URL:
<xsd:import namespace="http://www.example.org/schema/types" schemaLocation="types.xsd" />

This issue could be resolved by attempting to find the imported schema relative to the baseUri value (as shown at http://forum.springframework.org/showpost.php?p=189478&postcount=14 by blackbeltdev).

Additionally, if the CommonsXsdSchemaCollection class was open to having the URIResolver set via dependency injection, users could create their own URIResolver for special cases.

I've attached a modified version of CommonsXsdSchemaCollection that allows DI of the URIResolver (defaults to the private ClasspathUriResolver) and a new ClasspathBaseUriResolver class that merges the ClasspathUriResolver with the baseUri lookup code demonstrated by blackbeltdev on the forum.

@gregturn
Copy link
Member Author

@gregturn gregturn commented Aug 12, 2008

Patrick Crocker commented

CommonsXsdSchemaCollection - URIResolver set via dependency injection.
ClasspathBaseUriResolver - find schemaLocation relative to baseUri.

@gregturn
Copy link
Member Author

@gregturn gregturn commented Aug 28, 2008

Arjen Poutsma commented

Thanks for the code! Wouldn't it be better to use the ClasspahBaseUriResolver as default, rather than the private ClasspathUriResolver one? It seems like its logic s useful in most cases....

I will make the UriResolver settable in any case...

@gregturn
Copy link
Member Author

@gregturn gregturn commented Aug 28, 2008

Arjen Poutsma commented

Fixed. Feel free to try a snapshot as of tomorrow, and give it a go.

@gregturn
Copy link
Member Author

@gregturn gregturn commented Jan 12, 2010

Olivier Billard commented

For information, this fix only works for XSD files in the same physical classpath location (WEB-INF/classes, the same JAR file), but not in several JAR artifacts. In that last case, the base URI is different.

#711 fixes this.

@gregturn
Copy link
Member Author

@gregturn gregturn commented May 4, 2012

Arjen Poutsma commented

Closing old issues

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.