cvc-id.3 error in web.xml

Question

I'm getting this error message while editing web.xml file in eclipse for SpringMVC web-app:

cvc-id.3: A field of identity constraint 'web-app-servlet-name-uniqueness' matched element 'web-app', but this element does not have a simple type.

here is part of my web.xml:

<?xml version="1.0" encoding="UTF-8" ?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="http://java.sun.com/xml/ns/javaee" 
    xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
    id="WebApp_ID" version="2.5">

    <servlet>
        <servlet-name>dispatcher</servlet-name>
        <servlet-class>
            org.springframework.web.servlet.DispatcherServlet
        </servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>

Error points at the <servlet-name>dispatcher</servlet-name> declaration. What should i do to fix it? Thank you in advance.

Hideaway

The error suggests a problem with the uniqueness of the servlet-name. Can we see the whole file, not just that one bit? – Caudill

Answer 1

I accidentally found that changing Java to the upper case made the error disappear:

xmlns="http://java.sun.com/xml/ns/javaee"

Should be:

xmlns="http://JAVA.sun.com/xml/ns/javaee"

Revers

Got the same error today. You can actually just put "Java" instead of "java" it works... I chose to add an "s" in https... it solves the errors too. that's some weird stuff... – Snelling

By using a differetn casing you are technically introducing a different namespace. So, this is not really a solution. – Corncrib

Oh my god, that cannot all be true. How dead is GWT, actually?? – Jorrie

I verified that changing it to "JAVA" or "Java" fixes it. Also that switching the url to have "https..." instead of "http..." with no other change seems to do it as well. Simply doing a [Project > Clean] does not fix it. – Nowell

This is NOT an answer, people are simply hiding the underlying problem by changing the namespace to something not known and ignored by Eclipse. The suggestions have the same effect like using xmlns="foobar" liquid-technologies.com/xml-schema-tutorial/xsd-namespaces – Garrik

Strangely! worked for me too – Lymphadenitis

Answer 2

Eclipse 2021-06

I've ran into a similar issue with Eclipse 2021-06 today:

cvc-id.3: A field of identity constraint 'web-common-filter-name-uniqueness' matched element 'web-app', but this element does not have a simple type.

Wrong answers

Many of the other suggestions in the answers are simply wrong, because what they are doing is changing namespaces to something not mapped to any schema at all anymore and therefore things won't simply be checked anymore. Some comments make that clear already, so java to Java or http to https or javaee to j2ee at some places really only hides the problem.

The point is that if that message comes, there really is a validation problem which needs to be found and fixed. So while suggestions like cleaning the project, the network cache of Eclipse under Windows/Preferences/Network Connections/Cache etc. are usual Voodoo, they MIGHT(!) work! Though, that wasn't the problem in my case.

Deployment descriptor 3.1

What has worked in my case was changing the deployment descriptor to version 3.1:

<web-app    xmlns="http://java.sun.com/xml/ns/javaee"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
                                http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
            id="WebApp_ID" version="3.0">

vs.

<web-app    xmlns="http://xmlns.jcp.org/xml/ns/javaee"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
                                http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
            id="WebApp_ID" version="3.1">

Afterwards the validation errors were instantly gone. Though, the important part is that in contrast to introduce invalid/unknown/wrong/... namespaces like in many of the other answers, Eclipse DOES validate! This can easily be tested by really adding the same filter-name twice, which results in the following error:

cvc-identity-constraint.4.1: Duplicate unique value [UrlRewriteFilter] declared for identity constraint "web-common-filter-name-uniqueness" of element "web-app".

That DOES NOT happen with invalid/unknown/wrong/... namespaces, Eclipse wouldn't simply validate at all and the error would be left unrecognized until deployment or even later.

Support for version 3.1 in Tomcat+Eclipse

I need to support legacy apps myself, so checked with which version of Tomcat a corresponding web.xml has been deployed and its 8.0. That should be old enough for a lot of users. Of course Eclipse seems to bundle that version for quite some time as well, otherwise it wouldn't be able to validate right now. Just have a look into the file org.eclipse.jst.standard.schemas_1.2.400.v202101070609.jar.

Changes of 3.0 to 3.1

I've diffed both versions and it seems people mostly changed only namespaces and migrated some types from the associated web-common_*.xsd to web-app_*.xsd itself. Really only minor changes otherwise.

Conclusion

The overall interesting question is why Eclipse stopped working for the former web.xml even though it seems that it was totally correct. Only the namespaces and version number changed, but that worked for years in the past. What I'm not sure about anymore is if older Eclipse validated using language server, like the currently used version does. I wonder if whatever provides the language server might have changed and version 3.0 of the deployment descriptor might simply not be supported at all anymore.

Or something else changed regarding downloading and including the web-common_*.xsd and that's why they needed to refactor types into the parent file.

Of course, neither of this was the issue when the question was actually written in 2010. :-) Though, as the deployment descriptor looks still correct to me, only for some older version, there surely was some other root cause as well than wrong namespaces or alike.

JSP-related updates

I've ran into pretty much the problem with JSP as well and this time it was enough to change the location of the XSD only, without any namespace or version changes. The latter were applied for web.xml, but this time I only did the following:

<taglib
    xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd"
    version="2.1">

vs.

<taglib
    xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-jsptaglibrary_2_1.xsd"
    version="2.1">

http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd

vs.

http://xmlns.jcp.org/xml/ns/javaee/web-jsptaglibrary_2_1.xsd

The important thing is that I didn't simply invalidated namespaces, but validation still applies. This can easily be tested by adding invalid elements or e.g. add multiple functions with the same names.

cvc-complex-type.2.4.a: Invalid content was found starting with element '{"http://java.sun.com/xml/ns/javaee":foobar}'. One of '{"http://java.sun.com/xml/ns/javaee":description, "http://java.sun.com/xml/ns/javaee":display-name, "http://java.sun.com/xml/ns/javaee":icon, "http://java.sun.com/xml/ns/javaee":tlib-version}' is expected.

WWD in Eclipse contains some catalog file mapping the same actual XSD file under multiple different URI-names. So while in theory the older URI should still be available and used, it doesn't seem to be for some reason. OTOH, the newer URI seems to work for some reason, but in those cases it is necessary to keep the OLD namespaces! Reason simply is that the one and only available file still contains the old namespaces, regardless which URI is used to read it.

<uri name="http://java.sun.com/xml/ns/javaee/web-jsptaglibrary_2_1.xsd" uri="file:///C:/Users/tschoening/AppData/Roaming/Eclipse/Java%20Docsrv/configuration/org.eclipse.osgi/1360/0/.cp/dtdsAndSchemas/web-jsptaglibrary_2_1.xsd"/>
<uri name="http://xmlns.jcp.org/xml/ns/javaee/web-jsptaglibrary_2_1.xsd" uri="file:///C:/Users/tschoening/AppData/Roaming/Eclipse/Java%20Docsrv/configuration/org.eclipse.osgi/1360/0/.cp/dtdsAndSchemas/web-jsptaglibrary_2_1.xsd"/>

So, it might be that changing the URI only might have worked with web.xml as well, like it seems to work with my JSP taglibs. Didn't get anything newer to work as well, seems like standards have changed a bit and I would need to adopt more, which I don't want anymore. Legacy-stuff... :-)

Owl

Please Upvote the hell out of this answer :) – Sycophant

For me changing it to 3.1 did not fix the error, but changing it to 2.5 did. – Thin

So you actually used the definition of the question? Because changing the version number only hides the underlying problem again. – Garrik

The next obvious question to me is, is there an Eclipse bug filed somewhere?... This is really annoying, and I can't yet change to 3.1, because of the levels supported by our current servers. – Streaky

I opened bugs.eclipse.org/bugs/show_bug.cgi?id=577715 – Streaky

Answer 3

<?xml version="1.0" encoding="UTF-8" ?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:javaee="http://java.sun.com/xml/ns/javaee" 
    xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
    id="WebApp_ID" version="2.5">

Adding a namespace to your xmlns="http://java.sun.com/xml/ns/javaee" Line (eg) xmlns:javaee="http://java.sun.com/xml/ns/javaee" will resolve your problems probably.

There are elements in both definition files, so without a proper namespace they won't be unique

Hardfavored

Using xmlns:javaee without using <javaee:servlet> as well will hide the problem only, pretty much like with all the other answers suggesting java to JAVA or http to https. Doesn't it? – Garrik

Answer 4

please find below the tag for web.xml

<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
         http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
         version="3.1">

</web-app>

Ira

Please include detail on why this would fix the issue. Not having detail doesn't provide much assistance. – Perdomo

Answer 5

I really appreciate Thorsten Schöning's answer and his offer to fix issues, not hide them.

In my case, I was getting these validation errors due to the usage of incorrect version and descriptor schema.

Since I used Jakarta's implementation of Servlets

jakarta.servlet:jakarta.servlet-api:5.0.0

I had to use Jakarta's schema

<web-app version="5.0"
             xmlns="https://jakarta.ee/xml/ns/jakartaee"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd"
             id="webappid">

For example, Jakarta servlet Deployment Descriptor instances that must be processed with the servlet 5.0 version must indicate the version within the version attribute of the instance document, for example, “5.0”. The Deployment Descriptor processors use the version information to choose the appropriate version of the schema document(s) to process the Deployment Descriptor instances.

So, if you use javax.servlet-api:3.1 then the correct descriptor should use the appropriate version as well. Like this

<web-app version="3.1"
         xmlns="http://xmlns.jcp.org/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
         id="webappid">

Dosage

been there done that. For Spring 6 / Java 17 world I ended with <web-app xmlns:xsi="w3.org/2001/XMLSchema-instance" xmlns="jakarta.ee/xml/ns/jakartaee" xsi:schemaLocation="jakarta.ee/xml/ns/jakartaee jakarta.ee/xml/ns/jakartaee/web-app_6_0.xsd" version="6.0"> – Atthia

Answer 6

I've found the following here and here which helps me:

<web-app
  xmlns="http://java.sun.com/xml/ns/j2ee"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
  version="2.5">

The value of attribute xmlns ends with j2ee instead of javaee.

Lorient

Don't follow people using ISO-8859-1 for their XML examples. :-) j2ee in combination with a schema location of javaee doesn't make much sense. schemaLocation maps namespaces to files and javaee is nether imported/used. OTOH, j2ee is not mentioned in schemaLocation, so parsers simply won't validate at all. That's why errors go away. https://mcmap.net/q/159115/-what-is-the-use-of-xsi-schemalocation – Garrik