Announcement Announcement Module
No announcement yet.
XSD Validation Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • XSD Validation


    STS is flagging my 'spring-webflow-config.xml' with the following :

    Multiple annotations found at this line:
    - schema_reference.4: Failed to read schema document '
    spring-webflow-config.xsd', because 1) could not find the document; 2) the document could not be read; 3) the root element of
    the document is not <xsd:schema>.
    - cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'webflow:flow-

    The snippet is :
    <beans xmlns=""
    	<!-- Executes flows: the central entry point into the Spring Web Flow system -->
    	<webflow:flow-executor id="flowExecutor">
    		<webflow:flow-execution-listeners> <!-- ERROR LINE -->
    			<webflow:listener ref="facesContextListener"/>
    			<webflow:listener ref="securityFlowExecutionListener" />
    I know this is not serious problem, but just for completeness ...?


  • #2
    Also happens to me a lot, extremely frustrating, and doesn't happen to everyone on the project. Cripples your ability to work with schema's you don't know well, because the IDE can't resolve the available grammar.


    • #3

      So lets try to find out what is going wrong here. What version of STS are you using? Do you also have an example project for me to reproduce this? Or is it just producing the error with the config file mentioned above?



      • #4

        STS 2.5.2.SR1.

        This was a completely clean install. I am a novice at Spring, and I wanted to check out the MVC/Webflow/Faces stuff (I'm coming from JBoss/Seam).
        The project is the (unmodified) booking-faces - I can zip and send it, but I haven't made any mods at all.

        Both : & are appearing as an 'Oops' in firefox.

        My understanding is that these schemata need to be available. Intelli/J used to allow me to make local copies of external schemata, so network problems (or local-only) development could continue with validation. 'Fraid I don't know Eclipse/STS well enough to do the same ... but I still can't download the actual schemata.
        Is a real problem as the project won't deploy either - get the dreaded 'must have a space between local and system ids' error ... signifying a 500 return from the (attempted) schema download.

        As I say, may be SpringSource,STS,Eclipse - would just appreciate a workaround or a pointer.

        I've had no other i/net problems (e.g. http://google-web-toolkit.googlecode...gwt-module.dtd) is fine - get the DTD) - switching to GWT ... for which I'll open another topic :-)

        Many Thanks


        • #5
          In my case it happened with both 2.5.2, and 2.6.0M2. I'm working with Spring integration, but I've found that the public XSDs require being very careful in your context file.

          For instance.

          will cause errors, the default (non-numbered) xsd doesn't have all of the spring integration 2.0 entries. Maybe this is normal?


          will work.


          • #6
            Hi Brad,

            Both of those links bring up schema data for me - the xsd is loaded 'correctly' (just from a firefox retrieval - not within code/validation as I haven't tried that).
            My assumption is (especially if your project problems are intermittent) that the server/content is flaky.
            XSD versioning was always going to be a pain (shades of CORBA :-).

            I'd be interested in solving this ... my 'project' is just a starter, and I was _so_ hoping STS would just work 'out of the box'.

            Sounds like you're further/deeper than I am.

            Good luck.


            • #7
              Correct, both links work fine. However they are not the same XSD.

              There is a 1.0, and a 2.0 XSD for spring integration. I would normally expect the default (non-numbered) to point to the latest. In this case though, the default XSD is the 1.0. Thats why I see validation errors.

              Lesson is always specify the version number when dealing with spring xsds.


              • #8
                I came from SGML when XSD was just a twinkle in the eye :-) Major mind-bender for a couple of years was how to deal with versions of schemata (and the docs that were validated against them). WSDL stuff has fudged it well - still should be forward compatible tho'.

                Intelli/J used to have a 'symbolic' mechanism where the external XSD reference could be assigned to an arbitrary internal or external link - and could be changed on a per-project basis. Not sure if Eclipse/STS has the same ... but you may find that 'project-specific settings' for other peeps are referring to older/newer versions.

                I would guess that your problem is more complex than mine (I just want to use the example) but it's certainly intriguing.


                • #9
                  Cracked it - workaround!

                  The non-versioned name doesn't exist in my 2 cases. When I set the xsi resolution to the actual (versioned, latest) file it validates correctly.

                  Thanks to Brad for the pointer.

                  Could I ask that Springsource please add the symbolic links for the non-versioned versions to the versioned versions (hmmm :-)

                  As I say, I understand the difficulties of versioning in XSD - has to be backward compatible to work for previous schema references - but the given examples (and, presumably documentation) aren't working due to the lack of these links.



                  • #10
                    I also added a JIRA issue to track these things:



                    • #11
                      I looked at this in more detail and I don't think we should do too much magic here from the tooling side. If the schema that is referenced in the config file doesn't exist (which is the case for the webflow example mentioned above where the non-versioned xsd is not available anywhere), there is not much that we could do. We could use the versioned one that exists, but what if there are multiple versions? So I tend to not do any magic in the tooling just to hide the fact that the non-versioned schema is missing or that the config file isn't correct (with respect to the missing schema).