Org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: Matching pattern is strict
org.xml.sax.SAXParseException: cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element 'drools:grid-node'.
I am getting this error when I add grid-node and ksession to my spring xml. I did a few searches and it looked like a classpath. What dependency am I not seeing here?
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:camel="http://camel.apache.org/schema/spring"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:mvc="http://www.springframework.org/schema/mvc" xmlns:jaxrs="http://cxf.apache.org/jaxrs"
xmlns:drools="http://drools.org/schema/drools-spring"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://camel.apache.org/schema/spring
http://camel.apache.org/schema/spring/camel-spring.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context-3.0.xsd
http://www.springframework.org/schema/mvc
http://www.springframework.org/schema/mvc/spring-mvc-3.0.xsd
http://cxf.apache.org/jaxrs http://cxf.apache.org/schemas
http://cxf.apache.org/jaxrs http://cxf.apache.org/schemas/jaxrs.xsd
http://drools.org/schema/drools-spring org/drools/container/spring
http://drools.org/schema/drools-spring org/drools/container/spring/drools-spring-1.2.0.xsd">
<drools:grid-node id="node1"/>
<drools:ksession id="ksession1" type="stateful" kbase="kbase1" node="node1" />
My pom.xml has the following words for Drools.
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-camel</artifactId>
<version>${drools.version}</version>
<exclusions>
<!-- This ensures that we use the latest version of Spring jars and not
the one that comes with drools.version. -->
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
</exclusion>
<exclusion>
<groupId>org.apache.camel</groupId>
<artifactId>camel-core</artifactId>
</exclusion>
<exclusion>
<groupId>org.apache.camel</groupId>
<artifactId>camel-spring</artifactId>
</exclusion>
<exclusion>
<artifactId>camel-xstream</artifactId>
<groupId>org.apache.camel</groupId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.drools</groupId>
<artifactId>knowledge-api</artifactId>
<version>${drools.version}</version>
</dependency>
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-core</artifactId>
<version>${drools.version}</version>
</dependency>
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-compiler</artifactId>
<version>${drools.version}</version>
</dependency>
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-spring</artifactId>
<version>${drools.version}</version>
</dependency>
source to share
This error is thrown because the Drools XSD could not be found. In this comment in Drools list of users stated that the XSD are not publicly available, and attribute xsi:schemaLocation
in XML XSD compares with http://drools.org/schema/drools-spring org/drools/container/spring/drools-spring-1.2.0.xsd
, which does not allow proper XSD.
Spring should automatically handle XSD resolution based on the attribute xmlns:drools="http://drools.org/schema/drools-spring"
. One of the Drools JARs must include a file META-INF/spring.handlers
that defines the XSD mapping for the namespace drools
. Something like:
http://drools.org/schema/drools-spring=some.classpath.visible.package.xsdfile.xsd
Which should automatically process the XSD file included in the Drools JAR.
Try removing the last two lines of your attribute xsi:schemaLocation
to let Spring automatically resolve the XSD.
Some related links:
- Spring schemaLocation fails when there is no internet connection . Especially David Resnick answers.
- Spring Reference Appendix D.5 Handler and Schema Registration .
Of course, you can also extract this XSD from the JAR file, put it in an accessible directory from your classpath, and use the relative url of the class in xsi:schemaLocation
.
By the way, this is probably a copy and paste error, but the element is <beans>
missing its closing tag.
EDIT . It seems that Drools did not provide as expected spring.handlers
(since at least December 2010, see Drools + Spring without Internet ). You may have to dig through the JAR to get the XSD and reference it directly in xsi:schemaLocation
.
source to share
As for the bug marker in Eclipse : I only have a workaround and I doubt there is a real solution for this. As Javi Lopez said in his accepted answer, the drools-spring jar (for me, drools-spring-5.3.0.Final.jar
) has a file spring-handlers
) under the META-INF section. This, however, does not reference the xsd file (although the xsd files are in this very jar), but contains the following:
http\://drools.org/schema/drools-spring=org.drools.container.spring.namespace.SpringDroolsHandler
http\://drools.org/schema/drools-spring-1.2.0=org.drools.container.spring.namespace.SpringDroolsHandler
http\://drools.org/schema/drools-spring-1.3.0=org.drools.container.spring.namespace.SpringDroolsHandler
http\://drools.org/schema/drools-spring-1.4.0=org.drools.container.spring.namespace.SpringDroolsHandler
http\://drools.org/schema/drools-spring-1.5.0=org.drools.container.spring.namespace.SpringDroolsHandler
As you can see, it defines the handler class for each xsd version. This works well with spring at runtime, but I've never seen it work with any version of Eclipse (as well as the spring toolkit).
I always end up disabling validation for xsd files in a project, which for your convenience is like this:
- Select the project in the Package Explorer, click "File / Properties" (or press "Alt + Enter")
- In the Project Properties dialog box, select Validate
- Check Enable project specific settings (disable check only for this project)
- Uncheck "Manual and Build for: XML Schema Validator"
- Click OK
- Right click on the project and select "Confirm" (to confirm the project with changed settings)
(I also tried to reference the xsd directly from the xml definition of the spring beans, but that didn't work. Since the handler defined in the file spring-handlers
works at runtime, this won't be the best workaround IMHO.)
source to share