Announcement Announcement Module
Collapse
No announcement yet.
SAXParseException: src-resolve: Cannot resolve the name to a(n) 'type definition'... Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

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

    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


    Code:
    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.BeanCreationException: 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.XmlValidationException: 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.XmlValidationException: 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.ErrorHandlerWrapper.createSAX
    ParseException(ErrorHandlerWrapper.java:236)
            at com.sun.org.apache.xerces.internal.util.ErrorHandlerWrapper.error(Err
    orHandlerWrapper.java:172)
            at com.sun.org.apache.xerces.internal.impl.XMLErrorReporter.reportError(
    XMLErrorReporter.java:382)
            at com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.repo
    rtSchemaError(XSDHandler.java:2241)
            at com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.getG
    lobalDecl(XSDHandler.java:1269)
            at com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDElementTrave
    rser.traverseNamedElement(XSDElementTraverser.java:376)
            at com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDElementTrave
    rser.traverseLocal(XSDElementTraverser.java:214)
            at com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.trav
    erseLocalElements(XSDHandler.java:1781)
            at com.sun.org.apache.xerces.internal.impl.xs.traversers.XSDHandler.pars
    eSchema(XSDHandler.java:484)
            at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.loadSchema
    (XMLSchemaLoader.java:556)
            at com.sun.org.apache.xerces.internal.impl.xs.XMLSchemaLoader.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(SchemaFactory.java:489)
            at org.springframework.xml.validation.Jaxp13ValidatorFactory.createValid
    ator(Jaxp13ValidatorFactory.java:47)
            at org.springframework.xml.validation.XmlValidatorFactory.createValidato
    r(XmlValidatorFactory.java:68)
            at org.springframework.ws.endpoint.PayloadValidatingInterceptor.afterPro
    pertiesSet(PayloadValidatingInterceptor.java:174)
            at org.springframework.beans.factory.support.AbstractAutowireCapableBean
    Factory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1091)
            at org.springframework.beans.factory.support.AbstractAutowireCapableBean
    Factory.createBean(AbstractAutowireCapableBeanFactory.java:396)
            at org.springframework.beans.factory.support.AbstractBeanFactory.getBean
    (AbstractBeanFactory.java:233)
            at org.springframework.beans.factory.support.AbstractBeanFactory.getBean
    (AbstractBeanFactory.java:145)
            at org.springframework.beans.factory.support.DefaultListableBeanFactory.
    preInstantiateSingletons(DefaultListableBeanFactory.java:283)
            at org.springframework.context.support.AbstractApplicationContext.refres
    h(AbstractApplicationContext.java:313)
            at org.springframework.web.context.support.AbstractRefreshableWebApplica
    tionContext.refresh(AbstractRefreshableWebApplicationContext.java:139)
            at org.springframework.web.context.ContextLoader.createWebApplicationCon
    text(ContextLoader.java:252)
            at org.springframework.web.context.ContextLoader.initWebApplicationConte
    xt(ContextLoader.java:190)
            at org.springframework.web.context.ContextLoaderListener.contextInitiali
    zed(ContextLoaderListener.java:49)
            at org.apache.catalina.core.StandardContext.listenerStart(StandardContex
    t.java:3729)
            at org.apache.catalina.core.StandardContext.start(StandardContext.java:4
    183)
            at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase
    .java:759)
            at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:73
    9)
            at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
    
            at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:809)
    
            at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:497
    )
            at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1189)
            at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
    java:39)
            at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
    sorImpl.java:25)
            at java.lang.reflect.Method.invoke(Method.java:585)
            at org.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:
    503)
            at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImp
    l.java:213)
            at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220)
            at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultM
    BeanServerInterceptor.java:815)
            at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784
    )
            at org.apache.catalina.manager.ManagerServlet.check(ManagerServlet.java:
    1377)
            at org.apache.catalina.manager.HTMLManagerServlet.doPost(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.internalDoFilter(Appl
    icationFilterChain.java:252)
            at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
    ilterChain.java:173)
            at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
    alve.java:213)
            at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
    alve.java:178)
            at org.apache.catalina.authenticator.AuthenticatorBase.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.invoke(StandardEngineVal
    ve.java:107)
            at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
    a:148)
            at org.apache.coyote.http11.Http11Processor.process(Http11Processor.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

  • #2
    I've think you're suffering from this problem: http://opensource.atlassian.com/proj.../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.

    Comment


    • #3
      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

      Comment


      • #4
        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. 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:

        Code:
        set JAVA_OPTS = "-Djavax.xml.validation.SchemaFactory:http://www.w3.org/2001/XMLSchema=org.apache.xerces.jaxp.validation.XMLSchemaFactory"
        If you startup Tomcat from within Eclipse, you can set the property there.

        Hope that solves the problem!

        Comment


        • #5
          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

          Code:
          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.BeanCreationException: 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.XmlValidationException: 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.XmlValidationException: 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.createSAXParseException(Un
          known Source)
                  at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown Source)
                  at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
                  at org.apache.xerces.impl.xs.traversers.XSDHandler.reportSchemaError(Unk
          nown Source)
                  at org.apache.xerces.impl.xs.traversers.XSDHandler.getGlobalDecl(Unknown
           Source)
                  at org.apache.xerces.impl.xs.traversers.XSDElementTraverser.traverseName
          dElement(Unknown Source)
                  at org.apache.xerces.impl.xs.traversers.XSDElementTraverser.traverseLoca
          l(Unknown Source)
                  at org.apache.xerces.impl.xs.traversers.XSDHandler.traverseLocalElements
          (Unknown Source)
                  at org.apache.xerces.impl.xs.traversers.XSDHandler.parseSchema(Unknown S
          ource)
                  at org.apache.xerces.impl.xs.XMLSchemaLoader.loadSchema(Unknown Source)
                  at org.apache.xerces.impl.xs.XMLSchemaLoader.loadGrammar(Unknown Source)
          
                  at org.apache.xerces.impl.xs.XMLSchemaLoader.loadGrammar(Unknown Source)
          
                  at org.apache.xerces.jaxp.validation.XMLSchemaFactory.newSchema(Unknown
          Source)
                  at javax.xml.validation.SchemaFactory.newSchema(SchemaFactory.java:489)
                  at org.springframework.xml.validation.Jaxp13ValidatorFactory.createValid
          ator(Jaxp13ValidatorFactory.java:47)
                  at org.springframework.xml.validation.XmlValidatorFactory.createValidato
          r(XmlValidatorFactory.java:68)
                  at org.springframework.ws.endpoint.PayloadValidatingInterceptor.afterPro
          pertiesSet(PayloadValidatingInterceptor.java:174)
                  at org.springframework.beans.factory.support.AbstractAutowireCapableBean
          Factory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1091)
                  at org.springframework.beans.factory.support.AbstractAutowireCapableBean
          Factory.createBean(AbstractAutowireCapableBeanFactory.java:396)
                  at org.springframework.beans.factory.support.AbstractBeanFactory.getBean
          (AbstractBeanFactory.java:233)
                  at org.springframework.beans.factory.support.AbstractBeanFactory.getBean
          (AbstractBeanFactory.java:145)
                  at org.springframework.beans.factory.support.DefaultListableBeanFactory.
          preInstantiateSingletons(DefaultListableBeanFactory.java:283)
                  at org.springframework.context.support.AbstractApplicationContext.refres
          h(AbstractApplicationContext.java:313)
                  at org.springframework.web.context.support.AbstractRefreshableWebApplica
          tionContext.refresh(AbstractRefreshableWebApplicationContext.java:139)
                  at org.springframework.web.context.ContextLoader.createWebApplicationCon
          text(ContextLoader.java:252)
                  at org.springframework.web.context.ContextLoader.initWebApplicationConte
          xt(ContextLoader.java:190)
                  at org.springframework.web.context.ContextLoaderListener.contextInitiali
          zed(ContextLoaderListener.java:49)
                  at org.apache.catalina.core.StandardContext.listenerStart(StandardContex
          t.java:3729)
                  at org.apache.catalina.core.StandardContext.start(StandardContext.java:4
          183)
                  at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase
          .java:759)
                  at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:73
          9)
                  at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
          
                  at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:809)
          
                  at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:497
          )
                  at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1189)
                  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                  at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
          java:39)
                  at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
          sorImpl.java:25)
                  at java.lang.reflect.Method.invoke(Method.java:585)
                  at org.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java:
          503)
                  at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataImp
          l.java:213)
                  at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220)
                  at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultM
          BeanServerInterceptor.java:815)
                  at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:784
          )
                  at org.apache.catalina.manager.ManagerServlet.check(ManagerServlet.java:
          1377)
                  at org.apache.catalina.manager.HTMLManagerServlet.doPost(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.internalDoFilter(Appl
          icationFilterChain.java:252)
                  at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
          ilterChain.java:173)
                  at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV
          alve.java:213)
                  at org.apache.catalina.core.StandardContextValve.invoke(StandardContextV
          alve.java:178)
                  at org.apache.catalina.authenticator.AuthenticatorBase.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.invoke(StandardEngineVal
          ve.java:107)
                  at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav
          a:148)
                  at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java
          :869)
                  at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.p
          rocessConnection(Http11BaseProtocol.java:664)
                  at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpo
          int.java:527)
                  at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFol
          lowerWorkerThread.java:80)
                  at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP
          ool.java:684)
                  at java.lang.Thread.run(Thread.java:595)

          Comment


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

            Sorry about the unnecessary work .

            Comment


            • #7
              No problem. Let me know how I can help.

              Ben

              Comment


              • #8
                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.:
                Code:
                    <bean id="validatingInterceptor" class="org.springframework.ws.endpoint.PayloadValidatingInterceptor">
                        <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:
                Code:
                                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:
                Code:
                        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:
                Code:
                	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.

                Comment


                • #9
                  Originally posted by 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.:
                  Code:
                      <bean id="validatingInterceptor" class="org.springframework.ws.endpoint.PayloadValidatingInterceptor">
                          <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:
                  Code:
                                  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:
                  Code:
                          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:
                  Code:
                  	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.


                  Originally posted by Luke Hamaty
                  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/proj.../browse/SWS-43. Let me know if it's OK.

                  Thanks!

                  Comment


                  • #10
                    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.PayloadVali datingInterceptor">
                    <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

                    Comment


                    • #11
                      Originally posted by benethridge
                      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!

                      Comment


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

                        Comment


                        • #13
                          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.

                          Comment


                          • #14
                            Originally posted by 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

                            Comment


                            • #15
                              Originally posted by benethridge
                              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.

                              Comment

                              Working...
                              X