Pluggable WSDLLocators / Resolving WSDLs/XSDs from classpath

[Eirik Bjørsnøs <ei...@gmail.com>]

Hi,

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
reasons.

Questions
=======

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
WSDLLocators?

Thanks,
Eirik.

Re: Pluggable WSDLLocators / Resolving WSDLs/XSDs from classpath

[Daniel Kulp <dk...@apache.org>]

On Nov 22, 2012, at 3:26 PM, Eirik Bjørsnøs <ei...@gmail.com> wrote:
> 
> 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
> reasons.
> 
> Questions
> =======
> 
> 1) Does CXF have other options for extending WSDL/XSD resolution that I'm
> not aware of?

Not that I'm aware of either.   :-)

> 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
> WSDLLocators?

Patches are definitely welcome.  Might be slightly complex since you would have to deal with locators for both WSDL4J as well as XmlSchema.  Also possibly for JAXB/XMLBeans/JIBX, although they may already be pulling the doms from the current caches.   Not really sure.

-- 
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com