cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eirik Bjørsnøs <>
Subject Pluggable WSDLLocators / Resolving WSDLs/XSDs from classpath
Date Thu, 22 Nov 2012 20:26:44 GMT

Some background:

We're currently resolving WSDL and XSD from jars from our classpath. We do
this by calling ClassLoader.getResource("path/to/helloworld.wsdl") and
returning the URL to CXF.

This works just fine given that the WSDL and any imported XSDs live in the
_same_ JAR file.

When the WSDL imports an XSD (or the XSD imports another XSD), and the
imported XSDs are packaged in a _different_ JAR, then resolving fails for
the imported XSD.

Why would we want to package XSDs in different files?

Because it would allow us to resolve XSDs just like we resolve jar files
(using Maven etc). We could stop copying and repackaging XSDs all over the
place. The WSDL artifact for a service could just depend on the XSDs and
they would be resolved transitively. Our builds would be simplified quite a
lot, there would be less copying around of XSD files.

Can this be done in CXF?

What I'd really like to to is to specify/add a custom WSDLLocator which
resolves paths using the classpath. WSDLLocators aren't really exposed as
extensions currently. However, I was able to override the
OASISCatalogManager with a custom subclass and then override its
resolveSystem, resolveURI, resolvePublic.

That's clearly an extremely ugly hack, so I'd rather like to be able to
configure CXF with an alternative / additional WSDLLocator.

It seems to me that WSDLLocator is currently hard-coded to be an instance
of ResourceManagerWSDLLocator having an instance of CatalogWSDLLocator as
its parent. (I'm looking at WSDLManagerImpl.loadDefinition method)

A alternative solution would be to use catalogs for all our WSDL/XSDs, but
doing that might be out of our control or not very desirable for other


1) Does CXF have other options for extending WSDL/XSD resolution that I'm
not aware of?
2) Is my use case reasonable or should I just stick to having all files in
the same JAR?
3) Could we makes some changes to CXF that would allow pluggable


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message