Java.lang.IllegalArgumentException: filter mapping must indicate either <url-pattern> or <servlet-name>

Question

I created a very simple REST application with the following web.xml:

<context-param> <param-name>resteasy.scan</param-name> <param-value>true</param-value> </context-param> <listener> <listener-class>org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap</listener-class> </listener> <servlet> <servlet-name>Resteasy</servlet-name> <servlet-class>org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher</servlet-class> </servlet> <servlet-mapping> <servlet-name>Resteasy</servlet-name> <url-pattern>/rest/*</url-pattern> </servlet-mapping> 

I am using the servlet 3.0 specification and Tomcat 7.0.23. Unfortunately, this is not the whole time:

 Caused by: java.lang.IllegalArgumentException: Filter mapping must specify either a <url-pattern> or a <servlet-name> at org.apache.catalina.core.StandardContext.validateFilterMap(StandardContext.java:2995) at org.apache.catalina.core.StandardContext.addFilterMap(StandardContext.java:2954) 

I can’t imagine where the problem is ... I do not use filters in my code, how can I fix it?

Answer 1

This is due to the RESTEasy 577 issue . To fix this, you need to add metadata-complete="true" to the root <web-app> /WEB-INF/web.xml your /WEB-INF/web.xml .

 <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" version="3.0" metadata-complete="true"> <!-- Config here. --> </web-app> 

Thus, Tomcat will assume that /WEB-INF/web.xml complete and will not check the JAR for additional metadata information in web.xml fragments, which, in the case of RESTEasy, seem to contain incorrect / incompletely declared filters.

Answer 2

Of course, adding 'metadata-complete = "true"' blocks any other jars from contributing to web.xml, including RichFaces and Seam. It is better to exclude a JAR file that violates your deployment. In my case, it was an asynchronous http-servlet-3.0-2.3.3.Final.jar that offended.

Answer 3

This is a bug in Tomcat 7 (version <7.0.28), see to answer a similar question, and linked the Tomcat 7 bugzilla ticket .