SAXParseException: src-resolve: Cannot resolve the name to a(n) 'type definition'...

[benethridge]

Hi.

This one has me a bit stumped.

After getting the classes to generate ok (see other thread "Problem with Spring JAXB Version?"), I'm still getting this error:

Context initialization failed
org.springframework.beans.factory.BeanCreationExce ption: Error creating bean with name 'validatingInterceptor' defined in class path resource [org/springframework/applicationContext-ws.xml]: Initialization of bean failed; nested exception is org.springframework.xml.validation.XmlValidationEx ception: Could not create Schema: src-resolve: Cannot resolve the name 'tns:YorNTyp' to a(n) 'type definition' component.; nested exception is org.xml.sax.SAXParseException: src-resolve: Cannot resolve the name 'tns:YorNTyp' to a(n) 'type definition' component.

(At the end, I show some of the full log.)

I used the running airline sample as a template for this new web service app.

What would typically cause this error?

Ben


INFO: Undeploying context [/utdEditor_SpringWS]
Jun 29, 2006 5:48:37 PM org.apache.catalina.startup.HostConfig deployWAR
INFO: Deploying web application archive utdEditor_SpringWS.war
log4j:WARN No appenders could be found for logger (org.apache.commons.digester.D
igester.sax).
log4j:WARN Please initialize the log4j system properly.
2006-06-29 17:48:43,353 INFO [org.springframework.oxm.jaxb.Jaxb1Marshaller] - Cr
eating JAXBContext with context path [com.uptodate.utdeditor.schema]
2006-06-29 17:48:43,447 DEBUG [org.springframework.ws.soap.endpoint.PayloadRootQ
NameEndpointMapping] - Mapped key [{http://www.uptodate.com}GetCitationLstRq] on
to endpoint [com.uptodate.ws.utdeditor.GetCitationLstRqEndpoint @160c21a]
2006-06-29 17:48:43,463 INFO [org.springframework.ws.soap.SoapMessageDispatcher]
- No EndpointAdapters found: using default
2006-06-29 17:48:43,479 DEBUG [org.springframework.xml.validation.XmlValidatorFa
ctory] - Creating JAXP 1.3 XmlValidator
2006-06-29 17:48:43,494 ERROR [org.springframework.web.context.ContextLoader] -
Context initialization failed
org.springframework.beans.factory.BeanCreationExce ption: Error creating bean wit
h name 'validatingInterceptor' defined in class path resource [org/springframewo
rk/applicationContext-ws.xml]: Initialization of bean failed; nested exception i
s org.springframework.xml.validation.XmlValidationEx ception: Could not create Sc
hema: src-resolve: Cannot resolve the name 'tns:YorNTyp' to a(n) 'type definitio
n' component.; nested exception is org.xml.sax.SAXParseException: src-resolve: C
annot resolve the name 'tns:YorNTyp' to a(n) 'type definition' component.
org.springframework.xml.validation.XmlValidationEx ception: Could not create Sche
ma: src-resolve: Cannot resolve the name 'tns:YorNTyp' to a(n) 'type definition'
component.; nested exception is org.xml.sax.SAXParseException: src-resolve: Can
not resolve the name 'tns:YorNTyp' to a(n) 'type definition' component.
org.xml.sax.SAXParseException: src-resolve: Cannot resolve the name 'tns:YorNTyp
' to a(n) 'type definition' component.
at com.sun.org.apache.xerces.internal.util.ErrorHandl erWrapper.createSAX
ParseException(ErrorHandlerWrapper.java:236)
at com.sun.org.apache.xerces.internal.util.ErrorHandl erWrapper.error(Err
orHandlerWrapper.java:172)
at com.sun.org.apache.xerces.internal.impl.XMLErrorRe porter.reportError(
XMLErrorReporter.java:382)
at com.sun.org.apache.xerces.internal.impl.xs.travers ers.XSDHandler.repo
rtSchemaError(XSDHandler.java:2241)
at com.sun.org.apache.xerces.internal.impl.xs.travers ers.XSDHandler.getG
lobalDecl(XSDHandler.java:1269)
at com.sun.org.apache.xerces.internal.impl.xs.travers ers.XSDElementTrave
rser.traverseNamedElement(XSDElementTraverser.java :376)
at com.sun.org.apache.xerces.internal.impl.xs.travers ers.XSDElementTrave
rser.traverseLocal(XSDElementTraverser.java:214)
at com.sun.org.apache.xerces.internal.impl.xs.travers ers.XSDHandler.trav
erseLocalElements(XSDHandler.java:1781)
at com.sun.org.apache.xerces.internal.impl.xs.travers ers.XSDHandler.pars
eSchema(XSDHandler.java:484)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSche maLoader.loadSchema
(XMLSchemaLoader.java:556)
at com.sun.org.apache.xerces.internal.impl.xs.XMLSche maLoader.loadGramma
r(XMLSchemaLoader.java:523)
at com.sun.org.apache.xerces.internal.jaxp.validation .xs.SchemaFactoryIm
pl.newSchema(SchemaFactoryImpl.java:206)
at javax.xml.validation.SchemaFactory.newSchema(Schem aFactory.java:489)
at org.springframework.xml.validation.Jaxp13Validator Factory.createValid
ator(Jaxp13ValidatorFactory.java:47)
at org.springframework.xml.validation.XmlValidatorFac tory.createValidato
r(XmlValidatorFactory.java:68)
at org.springframework.ws.endpoint.PayloadValidatingI nterceptor.afterPro
pertiesSet(PayloadValidatingInterceptor.java:174)
at org.springframework.beans.factory.support.Abstract AutowireCapableBean
Factory.invokeInitMethods(AbstractAutowireCapableB eanFactory.java:1091)
at org.springframework.beans.factory.support.Abstract AutowireCapableBean
Factory.createBean(AbstractAutowireCapableBeanFact ory.java:396)
at org.springframework.beans.factory.support.Abstract BeanFactory.getBean
(AbstractBeanFactory.java:233)
at org.springframework.beans.factory.support.Abstract BeanFactory.getBean
(AbstractBeanFactory.java:145)
at org.springframework.beans.factory.support.DefaultL istableBeanFactory.
preInstantiateSingletons(DefaultListableBeanFactor y.java:283)
at org.springframework.context.support.AbstractApplic ationContext.refres
h(AbstractApplicationContext.java:313)
at org.springframework.web.context.support.AbstractRe freshableWebApplica
tionContext.refresh(AbstractRefreshableWebApplicat ionContext.java:139)
at org.springframework.web.context.ContextLoader.crea teWebApplicationCon
text(ContextLoader.java:252)
at org.springframework.web.context.ContextLoader.init WebApplicationConte
xt(ContextLoader.java:190)
at org.springframework.web.context.ContextLoaderListe ner.contextInitiali
zed(ContextLoaderListener.java:49)
at org.apache.catalina.core.StandardContext.listenerS tart(StandardContex
t.java:3729)
at org.apache.catalina.core.StandardContext.start(Sta ndardContext.java:4
183)
at org.apache.catalina.core.ContainerBase.addChildInt ernal(ContainerBase
.java:759)
at org.apache.catalina.core.ContainerBase.addChild(Co ntainerBase.java:73
9)
at org.apache.catalina.core.StandardHost.addChild(Sta ndardHost.java:524)

at org.apache.catalina.startup.HostConfig.deployWAR(H ostConfig.java:809)

at org.apache.catalina.startup.HostConfig.deployApps( HostConfig.java:497
)
at org.apache.catalina.startup.HostConfig.check(HostC onfig.java:1189)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Nativ e Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Native MethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(De legatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.commons.modeler.BaseModelMBean.invoke(B aseModelMBean.java:
503)
at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke (DynamicMetaDataImp
l.java:213)
at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDa taImpl.java:220)
at com.sun.jmx.interceptor.DefaultMBeanServerIntercep tor.invoke(DefaultM
BeanServerInterceptor.java:815)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxM BeanServer.java:784
)
at org.apache.catalina.manager.ManagerServlet.check(M anagerServlet.java:
1377)
at org.apache.catalina.manager.HTMLManagerServlet.doP ost(HTMLManagerServ
let.java:213)
at javax.servlet.http.HttpServlet.service(HttpServlet .java:709)
at javax.servlet.http.HttpServlet.service(HttpServlet .java:802)
at org.apache.catalina.core.ApplicationFilterChain.in ternalDoFilter(Appl
icationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.do Filter(ApplicationF
ilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invo ke(StandardWrapperV
alve.java:213)
at org.apache.catalina.core.StandardContextValve.invo ke(StandardContextV
alve.java:178)
at org.apache.catalina.authenticator.AuthenticatorBas e.invoke(Authentica
torBase.java:524)
at org.apache.catalina.core.StandardHostValve.invoke( StandardHostValve.j
ava:126)
at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.j
ava:105)
at org.apache.catalina.core.StandardEngineValve.invok e(StandardEngineVal
ve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.servic e(CoyoteAdapter.jav
a:148)
at org.apache.coyote.http11.Http11Processor.process(H ttp11Processor.java
:869)
...
SEVERE: Error listenerStart
Jun 29, 2006 5:48:43 PM org.apache.catalina.core.StandardContext start
SEVERE: Context [/utdEditor_SpringWS] startup failed due to previous errors

[Arjen Poutsma]

I've think you're suffering from this problem: http://opensource.atlassian.com/projects/spring/browse/SWS-35. Upgrading to Xerces should work, in combination to setting a system problem.

Look at PayloadValidatingInterceptorTest#testNamespacesInT ype() to see how this works.

[benethridge]

Hi, Arjen. I'm confused about this. I'm using the same user libraries (Eclipse terminology) that I'm using with the airline sample (and the Spring WS zip). Specifically, for the xerces, this is xercesImpl.jar (size 1179 KB).

So, if both Eclipse projects are pointing to the same set of jars, why would xerces version be a factor?

As for the system property, I read over the docs you mentioned and they make sense conceptually, but again, if I cloned the airline project to create my new one, and I didn't change that system property, why does the airline project not get the error but my cloned/morph'ed project does get it?

Just to test your theory though, where would be a good place to set that system property, if I wanted to? project.properties of my cloned/morphed project? or should it be a JVM setting at run- or debug-time.

Also, that colon parameter syntax is new to me. Just to make sure I get it right, what would it look like exactly:

javax.xml.validation.SchemaFactory:http\://www.w3.org/2001/XMLSchema=org.apache.xerces.jaxp.validation.XMLSch emaFactory

...i.e. with the escaped http: as per the "Tip for Trouble-shooting" in the URL you mentioned?

Ben

[Arjen Poutsma]

The system property makes you actually use the Xerces libs you deploy with the app. By default, you get the SchemaFactory contained in the JDK. You can tell, because you have com.sun.org.apache.xerces.internal.* in the stack trace. That's SUN's version of Xerces, which contains some known issues (not finding types is one of them).

Just adding Xerces to your classpath unfortunately doesn't necessarily mean you actually use it. To use the Xerces you supply instead of SUNs parser, you specify the property, like is explain in the JDK 1.5 Javadoc (http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/validation/SchemaFactory.html#newInstance(java.lang.String)). You should set that property at runtime/debugtime.

So that means (if using Tomcat): changing the startup script or by setting an environment variable JAVA_OPTS:


set JAVA_OPTS = "-Djavax.xml.validation.SchemaFactory:http://www.w3.org/2001/XMLSchema=org.apache.xerces.jaxp.validation.XMLSch emaFactory"


If you startup Tomcat from within Eclipse, you can set the property there.

Hope that solves the problem!

[benethridge]

Hi, Arjen. Did that. Same error.

I added the system property to the tomcat startup.bat. As you can see in the log below, it took effect, since the "com.sun" package prefix is now gone.

I've googled the error as best I could:

org.xml.sax.SAXParseException: src-resolve: Cannot resolve the name to a(n) 'type definition' component

... but didn't find much on it yet. One possible bug report from sun showed up in the google results, but it was a couple of years back, so it didn't look signif. Note, however, that I am using JDK1.5.x

Ben

INFO: Server startup in 4281 ms
Jun 30, 2006 11:33:58 AM org.apache.catalina.core.StandardContext stop
INFO: Container org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/
utdEditor_SpringWS] has not been started
Jun 30, 2006 11:33:58 AM org.apache.catalina.startup.HostConfig checkResources
INFO: Undeploying context [/utdEditor_SpringWS]
Jun 30, 2006 11:34:19 AM org.apache.catalina.startup.HostConfig deployWAR
INFO: Deploying web application archive utdEditor_SpringWS.war
log4j:WARN No appenders could be found for logger (org.apache.commons.digester.D
igester).
log4j:WARN Please initialize the log4j system properly.
2006-06-30 11:34:25,204 INFO [org.springframework.oxm.jaxb.Jaxb1Marshaller] - Cr
eating JAXBContext with context path [com.uptodate.utdeditor.schema]
2006-06-30 11:34:25,298 DEBUG [org.springframework.ws.soap.endpoint.PayloadRootQ
NameEndpointMapping] - Mapped key [{http://www.uptodate.com}GetCitationLstRq] on
to endpoint [com.uptodate.ws.utdeditor.GetCitationLstRqEndpoint @13a8eb1]
2006-06-30 11:34:25,298 INFO [org.springframework.ws.soap.SoapMessageDispatcher]
- No EndpointAdapters found: using default
2006-06-30 11:34:25,314 DEBUG [org.springframework.xml.validation.XmlValidatorFa
ctory] - Creating JAXP 1.3 XmlValidator
2006-06-30 11:34:25,735 ERROR [org.springframework.web.context.ContextLoader] -
Context initialization failed
org.springframework.beans.factory.BeanCreationExce ption: Error creating bean wit
h name 'validatingInterceptor' defined in class path resource [org/springframewo
rk/applicationContext-ws.xml]: Initialization of bean failed; nested exception i
s org.springframework.xml.validation.XmlValidationEx ception: Could not create Sc
hema: src-resolve: Cannot resolve the name 'tns:YorNTyp' to a(n) 'type definitio
n' component.; nested exception is org.xml.sax.SAXParseException: src-resolve: C
annot resolve the name 'tns:YorNTyp' to a(n) 'type definition' component.
org.springframework.xml.validation.XmlValidationEx ception: Could not create Sche
ma: src-resolve: Cannot resolve the name 'tns:YorNTyp' to a(n) 'type definition'
component.; nested exception is org.xml.sax.SAXParseException: src-resolve: Can
not resolve the name 'tns:YorNTyp' to a(n) 'type definition' component.
org.xml.sax.SAXParseException: src-resolve: Cannot resolve the name 'tns:YorNTyp
' to a(n) 'type definition' component.
at org.apache.xerces.util.ErrorHandlerWrapper.createS AXParseException(Un
known Source)
at org.apache.xerces.util.ErrorHandlerWrapper.error(U nknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportErro r(Unknown Source)
at org.apache.xerces.impl.xs.traversers.XSDHandler.re portSchemaError(Unk
nown Source)
at org.apache.xerces.impl.xs.traversers.XSDHandler.ge tGlobalDecl(Unknown
Source)
at org.apache.xerces.impl.xs.traversers.XSDElementTra verser.traverseName
dElement(Unknown Source)
at org.apache.xerces.impl.xs.traversers.XSDElementTra verser.traverseLoca
l(Unknown Source)
at org.apache.xerces.impl.xs.traversers.XSDHandler.tr averseLocalElements
(Unknown Source)
at org.apache.xerces.impl.xs.traversers.XSDHandler.pa rseSchema(Unknown S
ource)
at org.apache.xerces.impl.xs.XMLSchemaLoader.loadSche ma(Unknown Source)
at org.apache.xerces.impl.xs.XMLSchemaLoader.loadGram mar(Unknown Source)

at org.apache.xerces.impl.xs.XMLSchemaLoader.loadGram mar(Unknown Source)

at org.apache.xerces.jaxp.validation.XMLSchemaFactory .newSchema(Unknown
Source)
at javax.xml.validation.SchemaFactory.newSchema(Schem aFactory.java:489)
at org.springframework.xml.validation.Jaxp13Validator Factory.createValid
ator(Jaxp13ValidatorFactory.java:47)
at org.springframework.xml.validation.XmlValidatorFac tory.createValidato
r(XmlValidatorFactory.java:68)
at org.springframework.ws.endpoint.PayloadValidatingI nterceptor.afterPro
pertiesSet(PayloadValidatingInterceptor.java:174)
at org.springframework.beans.factory.support.Abstract AutowireCapableBean
Factory.invokeInitMethods(AbstractAutowireCapableB eanFactory.java:1091)
at org.springframework.beans.factory.support.Abstract AutowireCapableBean
Factory.createBean(AbstractAutowireCapableBeanFact ory.java:396)
at org.springframework.beans.factory.support.Abstract BeanFactory.getBean
(AbstractBeanFactory.java:233)
at org.springframework.beans.factory.support.Abstract BeanFactory.getBean
(AbstractBeanFactory.java:145)
at org.springframework.beans.factory.support.DefaultL istableBeanFactory.
preInstantiateSingletons(DefaultListableBeanFactor y.java:283)
at org.springframework.context.support.AbstractApplic ationContext.refres
h(AbstractApplicationContext.java:313)
at org.springframework.web.context.support.AbstractRe freshableWebApplica
tionContext.refresh(AbstractRefreshableWebApplicat ionContext.java:139)
at org.springframework.web.context.ContextLoader.crea teWebApplicationCon
text(ContextLoader.java:252)
at org.springframework.web.context.ContextLoader.init WebApplicationConte
xt(ContextLoader.java:190)
at org.springframework.web.context.ContextLoaderListe ner.contextInitiali
zed(ContextLoaderListener.java:49)
at org.apache.catalina.core.StandardContext.listenerS tart(StandardContex
t.java:3729)
at org.apache.catalina.core.StandardContext.start(Sta ndardContext.java:4
183)
at org.apache.catalina.core.ContainerBase.addChildInt ernal(ContainerBase
.java:759)
at org.apache.catalina.core.ContainerBase.addChild(Co ntainerBase.java:73
9)
at org.apache.catalina.core.StandardHost.addChild(Sta ndardHost.java:524)

at org.apache.catalina.startup.HostConfig.deployWAR(H ostConfig.java:809)

at org.apache.catalina.startup.HostConfig.deployApps( HostConfig.java:497
)
at org.apache.catalina.startup.HostConfig.check(HostC onfig.java:1189)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Nativ e Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Native MethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(De legatingMethodAcces
sorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.commons.modeler.BaseModelMBean.invoke(B aseModelMBean.java:
503)
at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke (DynamicMetaDataImp
l.java:213)
at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDa taImpl.java:220)
at com.sun.jmx.interceptor.DefaultMBeanServerIntercep tor.invoke(DefaultM
BeanServerInterceptor.java:815)
at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxM BeanServer.java:784
)
at org.apache.catalina.manager.ManagerServlet.check(M anagerServlet.java:
1377)
at org.apache.catalina.manager.HTMLManagerServlet.doP ost(HTMLManagerServ
let.java:213)
at javax.servlet.http.HttpServlet.service(HttpServlet .java:709)
at javax.servlet.http.HttpServlet.service(HttpServlet .java:802)
at org.apache.catalina.core.ApplicationFilterChain.in ternalDoFilter(Appl
icationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.do Filter(ApplicationF
ilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invo ke(StandardWrapperV
alve.java:213)
at org.apache.catalina.core.StandardContextValve.invo ke(StandardContextV
alve.java:178)
at org.apache.catalina.authenticator.AuthenticatorBas e.invoke(Authentica
torBase.java:524)
at org.apache.catalina.core.StandardHostValve.invoke( StandardHostValve.j
ava:126)
at org.apache.catalina.valves.ErrorReportValve.invoke (ErrorReportValve.j
ava:105)
at org.apache.catalina.core.StandardEngineValve.invok e(StandardEngineVal
ve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.servic e(CoyoteAdapter.jav
a:148)
at org.apache.coyote.http11.Http11Processor.process(H ttp11Processor.java
:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11 ConnectionHandler.p
rocessConnection(Http11BaseProtocol.java:664)
at org.apache.tomcat.util.net.PoolTcpEndpoint.process Socket(PoolTcpEndpo
int.java:527)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThr ead.runIt(LeaderFol
lowerWorkerThread.java:80)
at org.apache.tomcat.util.threads.ThreadPool$ControlR unnable.run(ThreadP
ool.java:684)
at java.lang.Thread.run(Thread.java:595)

[Arjen Poutsma]

Ok, I was obviously wrong about my hunch. I will have to look deeper into this.

Sorry about the unnecessary work :).

[benethridge]

No problem. Let me know how I can help.

Ben

[Luke Hamaty]

I've been considering opening a JIRA on something very similar. I have seen this when using an <xsd:import> to pull in an additional schema file relative to the main file. The main schema file ends up as a SpringContextResource, but its location is not at the top of the resources heirarchy, e.g.:

<bean id="validatingInterceptor" class="org.springframework.ws.endpoint.PayloadValidatingI nterceptor">
<property name="schema" value="/WEB-INF/wsdl/foo.xsd"/>
<property name="validateRequest" value="true"/>
<property name="validateResponse" value="true"/>
</bean>


The schema Resource property gets passed down to the validator factories. The Jaxp10Validator and Jaxp13Validator handle this resource parameter very differently, but with the same result.

Jaxp10Validator resolves it to a File when creating the parser instance for the validation:

parser.setProperty(SCHEMA_LANGUAGE, schemaLanguage);
parser.setProperty(SCHEMA_SOURCE, schemaResource.getFile());


This is sort of nasty, and probably precludes using some sorts of resources such as classpath resources loaded from a jar.

Jaxp13Validator turns it into an InputStream, which is better:

SchemaFactory schemaFactory = SchemaFactory.newInstance(schemaLanguage);
InputStream schemaInputStream = schemaResource.getInputStream();
try {
Source schemaSource = new StreamSource(schemaInputStream);
Schema schema = schemaFactory.newSchema(schemaSource);
return new Jaxp13Validator(schema);
}


The problem is that neither of these set the systemId property for the schema inputs. Without that, the parser may not be able to resolve relative imports at all, or only when the schema files are at the top of the Resource's path. (For example, it might work for foo.xsd, but not for /WEB-INF/wsdl/foo.xsd .)

I was able to reproduce this behavior in test cases outside of spring-ws. With Jaxp 1.0, this works correctly:

InputSource is = new InputSource(schemaResource.getInputStream());
is.setSystemId(schemaResource.getURL().toString()) ;
parser.setProperty(SCHEMA_LANGUAGE, schemaLanguage);
parser.setProperty(SCHEMA_SOURCE, is);

However, I have not been through the permutations of the different resource types and parser implementations. There should be a condition for getURL() throwing an IOException for Resource types that don't have URLs.

I haven't done the Jaxp 1.3 version yet, but it should be about the same. If there is a URL available from the schemaResource, use it to set the systemId of the StreamSource. Of course, the really elegant way to handle it would be to create an LSResourceResolver to use the Resource's createRelative to locate relative schema files, but that is probably more trouble than it is worth. LSResourceResolver and LSInput are pretty obnoxious.

BTW, a minor related gripe: in PayloadValidatingInterceptor, the validation error string and the validation detail element qname should be optional properties, not fixed strings. I might have an existing convention for error names, or I might not want to expose implementation details.

[Arjen Poutsma]

I've been considering opening a JIRA on something very similar. I have seen this when using an <xsd:import> to pull in an additional schema file relative to the main file. The main schema file ends up as a SpringContextResource, but its location is not at the top of the resources heirarchy, e.g.:

<bean id="validatingInterceptor" class="org.springframework.ws.endpoint.PayloadValidatingI nterceptor">
<property name="schema" value="/WEB-INF/wsdl/foo.xsd"/>
<property name="validateRequest" value="true"/>
<property name="validateResponse" value="true"/>
</bean>


The schema Resource property gets passed down to the validator factories. The Jaxp10Validator and Jaxp13Validator handle this resource parameter very differently, but with the same result.

Jaxp10Validator resolves it to a File when creating the parser instance for the validation:

parser.setProperty(SCHEMA_LANGUAGE, schemaLanguage);
parser.setProperty(SCHEMA_SOURCE, schemaResource.getFile());


This is sort of nasty, and probably precludes using some sorts of resources such as classpath resources loaded from a jar.

Jaxp13Validator turns it into an InputStream, which is better:

SchemaFactory schemaFactory = SchemaFactory.newInstance(schemaLanguage);
InputStream schemaInputStream = schemaResource.getInputStream();
try {
Source schemaSource = new StreamSource(schemaInputStream);
Schema schema = schemaFactory.newSchema(schemaSource);
return new Jaxp13Validator(schema);
}


The problem is that neither of these set the systemId property for the schema inputs. Without that, the parser may not be able to resolve relative imports at all, or only when the schema files are at the top of the Resource's path. (For example, it might work for foo.xsd, but not for /WEB-INF/wsdl/foo.xsd .)

I was able to reproduce this behavior in test cases outside of spring-ws. With Jaxp 1.0, this works correctly:

InputSource is = new InputSource(schemaResource.getInputStream());
is.setSystemId(schemaResource.getURL().toString()) ;
parser.setProperty(SCHEMA_LANGUAGE, schemaLanguage);
parser.setProperty(SCHEMA_SOURCE, is);

However, I have not been through the permutations of the different resource types and parser implementations. There should be a condition for getURL() throwing an IOException for Resource types that don't have URLs.

I haven't done the Jaxp 1.3 version yet, but it should be about the same. If there is a URL available from the schemaResource, use it to set the systemId of the StreamSource. Of course, the really elegant way to handle it would be to create an LSResourceResolver to use the Resource's createRelative to locate relative schema files, but that is probably more trouble than it is worth. LSResourceResolver and LSInput are pretty obnoxious.


It sounds like there is a JIRA issue in there. Could you create one? I would create one myself, but you obviously have done more research on this subject, and it would be a waste if I worded the issue wrong.



BTW, a minor related gripe: in PayloadValidatingInterceptor, the validation error string and the validation detail element qname should be optional properties, not fixed strings. I might have an existing convention for error names, or I might not want to expose implementation details.

Another JIRA issue, I think. I've created one here: http://opensource.atlassian.com/projects/spring/browse/SWS-43. Let me know if it's OK.

Thanks!

[benethridge]

I found the solution to my original problem. Had nothing to do with my .xsd contents. Spring could not find my .xsd file at all:

<bean id="validatingInterceptor" class="org.springframework.ws.endpoint.PayloadValidatingI nterceptor">
<description>
This interceptor validates both incoming and outgoing message contents according to the 'MySchema.xsd' XML
Schema file.
</description>
<property name="schema" value="MySchema.xsd"/>
<property name="validateRequest" value="true"/>
<property name="validateResponse" value="true"/>
</bean>



That simple.

IMHO, if Spring is going to be a long-term winner, it's going to need a little better error trapping on this kind of simple stuff, as the "symptom" (i.e. the stacktrace error) does not lead one intuitively to the "solution". I imagine others will hit this same error soon, since it's pretty easy to mis-type and/or mis-path the .xsd name.

Not blaming you, Arjen, just talking in general about Spring, as this is currently our biggest problem with it across the board. At my company, we realize that this is still new, and we are all very excited about Spring Web Services, since the essential design pattern and philosophy is far better than Axis, which we were using before.

Ben

[Arjen Poutsma]

IMHO, if Spring is going to be a long-term winner, it's going to need a little better error trapping on this kind of simple stuff, as the "symptom" (i.e. the stacktrace error) does not lead one intuitively to the "solution". I imagine others will hit this same error soon, since it's pretty easy to mis-type and/or mis-path the .xsd name.

Not blaming you, Arjen, just talking in general about Spring, as this is currently our biggest problem with it across the board. At my company, we realize that this is still new, and we are all very excited about Spring Web Services, since the essential design pattern and philosophy is far better than Axis, which we were using before.

True, the stacktrace wasn't helpful at all in this case. And to circumvent that, I've added extra checking in the PayloadValidatingInterceptor. I will try and validate these sort of things more carefully in the future.

Thanks!

[Arjen Poutsma]

I've created a second issue for the problems indicated by Luke here: http://opensource.atlassian.com/projects/spring/browse/SWS-46

[Luke Hamaty]

The SAX parser is producing the obtuse src-resolve error, so Arjen doesn't have much to work with. There is probably a reason they don't have a distinct error for when the schema validator can't load a schema, but I sure can't think of one.

[benethridge]

I found the solution to my original problem. Had nothing to do with my .xsd contents. Spring could not find my .xsd file at all

I have to take this back somewhat. Apparently coincidentally to the time I correctly pointed to the schema, I also copy/pasted the "included child" schema into the "parent" schema. THAT was what made my problem go away.

I say that because now that I've configured my two schemas so that the parent includes the child (ex: <include schemaLocation="./child.xsd"/>), I'm getting my original problem again.

Note that this is exactly the same problem farrellr is getting in his post today, titled "validating interceptor and imported xsd issue?", and I believe for exactly the same reason.

Is there a fix coming for this? We can work around it for now, but we wouldn't want to go into production with it, if we had dozens of "parent" schemas to maintain.

Ben

[Arjen Poutsma]

Is there a fix coming for this? We can work around it for now, but we wouldn't want to go into production with it, if we had dozens of "parent" schemas to maintain.

The fix is already there, as I've indicated in my reply to farrellr's post.