WSDLs, Schemas in a jar separate from Web Service impl

[Craig Tataryn]

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.

1ST PROBLEM:
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.

WORKAROUND:
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.

2ND PROBLEM:
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.

STRUCTURE OF THE PROJECTS:

WebService Project:
src/main/java/my/package/WebServiceImpl.java

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.

--
Craig Tataryn
site: http://www.basementcoders.com/
podcast:http://feeds.feedburner.com/TheBasementCoders
irc: ThaDon on freenode #basementcoders, ##wicket, #papernapkin
twitter: craiger

[Craig Tataryn]

Anyone?

On Thu, Oct 29, 2009 at 2:59 PM, Craig Tataryn <craiger@...> 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.
>
> 1ST PROBLEM:
> 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.
>
> WORKAROUND:
> 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.
>
> 2ND PROBLEM:
> 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.
>
> STRUCTURE OF THE PROJECTS:
>
> WebService Project:
> src/main/java/my/package/WebServiceImpl.java
>
> 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.
>
> --
> Craig Tataryn
> site: http://www.basementcoders.com/
> podcast:http://feeds.feedburner.com/TheBasementCoders
> irc: ThaDon on freenode #basementcoders, ##wicket, #papernapkin
> twitter: craiger
>

--
Craig Tataryn
site: http://www.basementcoders.com/
podcast:http://feeds.feedburner.com/TheBasementCoders
irc: ThaDon on freenode #basementcoders, ##wicket, #papernapkin
twitter: craiger

[dkulp]

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

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.

Dan


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.
>
> 1ST PROBLEM:
> 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.
>
> WORKAROUND:
> 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.
>
> 2ND PROBLEM:
> 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.
>
> STRUCTURE OF THE PROJECTS:
>
> WebService Project:
> src/main/java/my/package/WebServiceImpl.java
>
> 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
dkulp@...
http://www.dankulp.com/blog

[Craig Tataryn]

Hey Dan, created a JIRA for this and attached the sample project:
https://issues.apache.org/jira/browse/CXF-2516

Craig.

On Fri, Oct 30, 2009 at 10:43 AM, Daniel Kulp <dkulp@...> wrote:

>
> 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
> bug.
>
> 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.
>
> Dan
>
>
> 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.
>>
>> 1ST PROBLEM:
>> 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.
>>
>> WORKAROUND:
>> 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.
>>
>> 2ND PROBLEM:
>> 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.
>>
>> STRUCTURE OF THE PROJECTS:
>>
>> WebService Project:
>> src/main/java/my/package/WebServiceImpl.java
>>
>> 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
> dkulp@...
> http://www.dankulp.com/blog
>

--
Craig Tataryn
site: http://www.basementcoders.com/
podcast:http://feeds.feedburner.com/TheBasementCoders
irc: ThaDon on freenode #basementcoders, ##wicket, #papernapkin
twitter: craiger