Bug 1094248 - [QE] (6.4.z) Default servlet can't be overridden without web.xml
Summary: [QE] (6.4.z) Default servlet can't be overridden without web.xml
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Web
Version: 6.3.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: CR2
: EAP 6.4.1
Assignee: John Allen
QA Contact: Radim Hatlapatka
Russell Dickenson
URL:
Whiteboard:
Depends On: 1188828 1196427 1196513
Blocks: eap641-payload
TreeView+ depends on / blocked
 
Reported: 2014-05-05 10:53 UTC by Emil Cervenan
Modified: 2021-08-30 13:50 UTC (History)
11 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2017-01-17 09:59:01 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
example project (27.23 KB, application/zip)
2014-05-05 10:53 UTC, Emil Cervenan
no flags Details
Servlet3DemoA.war (3.03 KB, application/octet-stream)
2014-09-07 04:39 UTC, Jay SenSharma
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Apache Bugzilla 51278 0 None None None Never
Red Hat Issue Tracker JBMETA-385 0 Major Closed Add overridable flag to servlet metadata 2018-08-31 07:04:19 UTC
Red Hat Issue Tracker JBWEB-310 0 Major Open Allow servlets to be marked overridable via Servlet registration API 2018-08-31 07:04:18 UTC
Red Hat Knowledge Base (Solution) 1211203 0 None None None Never

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.


Note You need to log in before you can comment on or make changes to this bug.