Bug 1094248

Summary: [QE] (6.4.z) Default servlet can't be overridden without web.xml
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Emil Cervenan <ecervena>
Component: WebAssignee: John Allen <joallen>
Status: CLOSED CURRENTRELEASE QA Contact: Radim Hatlapatka <rhatlapa>
Severity: medium Docs Contact: Russell Dickenson <rdickens>
Priority: unspecified    
Version: 6.3.0CC: bbaranow, cdewolf, iweiss, jawilson, joallen, maschmid, ollesoderstrom84, pjelinek, pslavice, rmaucher, sjadhav
Target Milestone: CR2   
Target Release: EAP 6.4.1   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Known Issue
Doc Text:
Cause: Mapping Spring dispatcher servlet to url pattern "/" does not work programmatically. In other words, overriding default servlet is not possible with Java code. Consequence: Many users map Spring's DispatcherServlet to '/', and this works fine when done in web.xml. However when this configuration is done programmatically, default servlet is bind to "/" first. This prevents to bind DispatcherServlet later. Spring controllers are not mapped and 404 is retrieved. Workaround (if any): Use web.xml configuration or map dispatcher servlet programmaticaly to some specific URL pattern. e.g. "/dispatcher/*" Result: Spring dispatcher servlet works.
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-01-17 09:59:01 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1188828, 1196427, 1196513    
Bug Blocks: 1207953    
Attachments:
Description Flags
example project
none
Servlet3DemoA.war none

Description Emil Cervenan 2014-05-05 10:53:44 UTC
Created attachment 892492 [details]
example project

Description of problem:
Mapping servlet to url pattern "/" does not work programmatically. I have encountered this issue when I was trying to bootstrap Spring WebMVC without XML configuration files. According to JSR-315 Servlet 3.0 specification (http://download.oracle.com/otndocs/jcp/servlet-3.0-fr-eval-oth-JSpec/) section 12.2, url pattern "/" should override default servlet mapping. However, an application configured this way returns 404. Same issue was fixed in Tomcat 7.0.15 (https://issues.apache.org/bugzilla/show_bug.cgi?id=51278).


Version-Release number of selected component (if applicable):
EAP 6.3.0.ER3


How reproducible:
Allways

Steps to Reproduce:
1. Build & deploy attached example project


Actual results:
404

Expected results:
"Hello world!"

Additional info:
Default servlet is overridden when using web.xml. You can exclude SpringBootstrap class from project classpath, uncomment content of dispatcher-servlet.xml and web.xml and test expected behaviour.

Comment 1 Martin Velas 2014-07-29 12:27:37 UTC
Problem still occurs for EAP 6.3.0.ER10.

Comment 2 Jay SenSharma 2014-09-07 04:33:34 UTC
This issue can be reproduced in EAP 6.3 as well as 6.2.x.
In order to reproduce this issue without even involving a simple web application can be used which tries to register a servlet to "/" dynamically using ServletContext API (inside ServletContextListener) something as following:

+++++++++++++
        @Override
        public void contextInitialized(ServletContextEvent event) {
                ServletContext context = event.getServletContext();
                System.out.println("\n\t Registering ServletA from inside the MyContextListener contextInitialized method.");
                Dynamic dynamic = context.addServlet("ServletA", ServletA.class);
                dynamic.addMapping("/");
                System.out.println("\t ServletA is Registered with url-pattern /*");
        }
+++++++++++++

Comment 3 Jay SenSharma 2014-09-07 04:38:16 UTC
The attached simple servlet3 demo can be used to reproduce this issue:

Deploy the attached WAR "Servlet3DemoA.war" then access the URL:
http://localhost:8080/Servlet3DemoA/

Above should cause 404 Page not found error.

In order to workaround this change the servlet mapping to something else (like /*) other than "/"

++++++++++
        @Override
        public void contextInitialized(ServletContextEvent event) {
                ServletContext context = event.getServletContext();
                System.out.println("\n\t Registering ServletA from inside the MyContextListener contextInitialized method.");
                Dynamic dynamic = context.addServlet("ServletA", ServletA.class);
                dynamic.addMapping("/*");
                System.out.println("\t ServletA is Registered with url-pattern /*");
        }
++++++++++

Comment 4 Jay SenSharma 2014-09-07 04:39:01 UTC
Created attachment 935119 [details]
Servlet3DemoA.war

Comment 12 Rémy Maucherat 2015-01-19 15:30:09 UTC
I have no information to provide. I never felt it was important to fix this and the updates needed were a bit too extensive for the benefit, which is the reason it didn't get fixed.

Comment 20 JBoss JIRA Server 2015-02-27 14:20:29 UTC
Bartosz Baranowski <bbaranow> updated the status of jira JBMETA-385 to Coding In Progress

Comment 22 Rostislav Svoboda 2015-04-23 11:44:49 UTC
Re-acking after "qa_ack flag reset for and jboss-eap-6.4.0 and jboss-eap-6.4.z items" cleanup.

Comment 23 JBoss JIRA Server 2015-05-04 08:55:38 UTC
Jean-Frederic Clere <jfclere> updated the status of jira JBMETA-385 to Closed

Comment 24 Pavel Jelinek 2015-05-15 19:55:55 UTC
Verified for EAP 6.4.1.CP.CR2.

Comment 25 Olof Söderström 2015-11-19 08:01:25 UTC
I got it to work by adding a "*" to the servlet mapping -> "/*".

Full example: 

public class AppInitializer extends AbstractAnnotationConfigDispatcherServletInitializer {

    @Override
    protected Class<?>[] getRootConfigClasses() {
        return null;

    protected Class<?>[] getServletConfigClasses() {
        return new Class[] { AppWebConfig.class };
    }

    @Override
    protected String[] getServletMappings() {
        return new String[] { "/*" };
    }
}

My requests are then handlet by the DispatcherServlet.

Comment 26 James Livingston 2015-11-19 22:05:05 UTC
Depending on your application that may or may not be a work around. The different is that all requests that do not match other mappings will be sent to the DispatcherServlet rather than returning a 404 directly.  They will probably end up with a 404 anyway, but may not.

Comment 28 Petr Penicka 2017-01-17 09:59:01 UTC
Retroactively bulk-closing issues from released EAP 6.4 cummulative patches.

Comment 29 Petr Penicka 2017-01-17 10:00:08 UTC
Retroactively bulk-closing issues from released EAP 6.4 cummulative patches.