On Nov 22, 2012, at 3:26 PM, Eirik Bjørsnøs <eir...@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 dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
