While doing my experiments with completely dynamic service creation from WSDL only, I found suspicious code in WSDLGetInterceptor regarding schema cacheing.
A following example results in incorrect behavior:
WSDLGetUtils.updateSchemaImports() uses a map for caching processed schemata.
A service built from following path layout
- Wsdl.wsld imports z/Types.xsd(NS: http://example.com/NS1) using relative path
- z/Types.xsd imports z/Types.xsd(NS: http://example.com/NS2) using relative path (i.e. imports z/z/Types.xsd)
results in incorrect serving of service definition when querying the endpoint.
The link from wsdl to import points to "?xsd=z/Types.xsd".
The link from z/Types.xsd points again to itself "?xsd=z/Types.xsd" (same content is served).
This is because the WSDLGetUtils cuts of the schemata processing on the first import because relative path is used as key identifier in the schema map.
I suspect the same applies for the WSDL imports in WSDLGetUtils.updateDefinition() due to caching the definitions in the definition map.