cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: WSDLs, Schemas in a jar separate from Web Service impl
Date Fri, 30 Oct 2009 16:43:41 GMT

Any chance you could package up a small test case with a couple dumb schemas 
and log some JIRA's.   The relative includes should be relative from the 
schema that defines that include, not the root wsdl.  Thus, that part MAY be a 

The validation thing is another issue and really surprises me.   A little 
while ago, we flipped the validation schema creation over to using the schemas 
in the XmlSchemaCollection instead of redownloading and parsing and such.  
Thus, I didn't think it should even be trying to find them again.   Strange.  
A test case would be good.


On Thu October 29 2009 3:59:05 pm Craig Tataryn wrote:
> Repeatedly running into a problem in our project where we have a
> multi-module Maven project structured such that a set of  3rd party
> schemas are held in one module (packaged as a Jar) and several web
> service module (packaged as a War) references it.
> This doesn't seem to work properly.
> If the wsdl file is contained within the War project,
> cxf-codegen-plugin  cannot reference the schema files defined within
> it's <xsd:include> elements.  Because the wsdls are owned by me (not
> the 3rd party), I was able to write a jax-ws-catalog.xml entry and
> stuff it into META-INF as per a suggestion Dan K made.  That worked
> well to get me past a certain point, that is, the wsdl now knows where
> the included schemas exist on the classpath.  However, those included
> schemas also have their own <xsd:include> statements of the form:
> <xs:include schemaLocation="../coreschemas/infrastructureRoot.xsd"/>
> That relative reference buggers everything because you cannot write
> (to my knowlege) a catalog entry which can interpolate a system id
> that is a relative reference into a fixed classpath location.
> Elements being referenced in the ../coreschemas/infrastructureRoot.xsd
> won't be resolved.
> Put the wsdl in the same project as the 3rd party schemas.
> <xsd:includes> are working directly off of filesystem locations and
> thus all the relative pathing works fine.
> Assuming you implement the workaround listed above, but you still have
> a separate module setup that houses your Web Service Implementations
> there will be issues if you turn on xsd-validation for your endpoint.
> When validation runs, it will complain that it can't find certain
> schemas, for example:
> org.apache.cxf.wsdl.EndpointReferenceUtils$SchemaLSResourceResolver
> resolveResource
> WARNING: Could not resolve Schema for COCT_MT090102CA.xsd
> COCT_MT090102CA.xsd is not referenced directly from the WSDL, it's
> actually referenced from one of the schemas the WSDL references.
> WebService Project:
> src/main/java/my/package/
> WSDLandSchemas Project:
> src/main/generated/... <-- all the JAXB generated resources from the
> Schemas/WSDL including the service interface being implemented in the
> WebService project
> src/main/resources/wsdl/WebService.wsdl
> src/main/resources/schemas/3rdParty
> src/main/resources/schemas/coreschemas
> So COCT_MT090102CA.xsd exists in the 3rdParty directory within the
> WSDLandSchemas project (which is on the classpath for the WebService
> project).  The WSDL references a schema in that same directory and
> it's that schema which has an <xsd:include
> schemaLocation="COCT_MT090102CA.xsd"/>
> Any thoughts?  Suggestions?  Is my dream of a nirvana where I only
> need to keep my schemas in one place and reference them on the
> classpath without bundling them with every project that needs them a
> pipe dream?
> Thanks,
> Craig.

Daniel Kulp

View raw message