I think there are a couple problems here:
- You are confused about the paths with spring MVC
- You are not configuring your web xml correctly
Unfortunately I can't cover every detail for you, a lot of spring is configurable, so my explanation is just going to cover the most basic scenario. If somebody finds a mistake please tell and I will fix it.
For the paths, it might help to think of things step by step.
- You request the url from your browser, The browser looks at the protocol, host, and port, and uses a DNS to find the appropriate IP address to connect with.
- A connection is established between your browser and the host. The host looks for a process running on the port you specified, and if a TCP connection is allowed by any security systems in place, the request is streamed to the process running on that port, the web server.
- The web server makes decisions based on what's after the port, specifically, it determines what the web application context is by looking at the path it was given. Once it determines the application context root, it knows which web application should handle that request. The decision is based on how you configure the web server, you could have a web application handle requests with no context root, or a specific context root. For example, if you requested
localhost:8080/CtxtRoot/jsp/
, you could have one web application on the server whose context root is "CtxtRoot", and it would handle that request. Alternatively, you could have an application that has "" for a context, and it could handle that request. It depends on how you configure the server, by default Tomcat will use the war name as a context root.
- The web application receives the request. While it knows the full URL requested, it only makes decisions based on everything after the context root. So for example, with the request to
localhost:8080/CtxtRoot/jsp/
, the web application would route things based on 'jsp' as the path.
- The web application has a filter chain that it submits the request to first. If a filter's pattern matches the request, that filter can evaluate the request. It might block the request, handle the request, or pass it on. I won't say much more because your question doesn't involve filters.
- The web app looks for a resource whose pattern matches the request, it considers servlets first, and then static resources. The url part that comes AFTER the context is what it tries to match, so if the request was for
localhost:8080/CtxtRoot/jsp/
, and the context root was 'CtxtRoot', then the web application is comparing '/jsp/' to all of the servlet mappings. Requests for static resources in WEB-INF will always be refused, but servlets and filters can and do return data from WEB-INF.
- I'm going to proceed assuming the request was sent to the spring DispatcherServlet, it receives the request, and considers everything after the servlet path. Spring's DispatcherServlet looks for a Controller whose path matches the path after the servlet path. The servlet path is basically what you put in the servlet mapping in your web xml. Let me give an example, let's say you have a web app whose context is 'app', and it has a spring MVC servlet whose servlet mapping is '/mvc', and a controller that handles the path 'sales', then you could reach that controller with
http://localhost:8080/app/mvc/sales
.
- If the DispatcherServlet cannot find a Controller, I believe it treats the incoming request as if it was returned by a controller, so if the sub-path is 'sales', then it would pass that as an argument to the view resolver. If it can't find it, then the server returns a not found error.
- Typically the Controller returns a string when it's done, which is the path to a resource. It could return 'popular' as a string. Spring then forwards this to the ViewResolver, and I will assume you're using the InternalResourceViewResolver. It will look at the prefix and suffix, and basically wrap those around what it was given. So if the prefix is '/WEB-INF/views/', the suffix is '.jsp', and the argument is 'popular', then it will look for a resource at '/WEB-INF/views/popular.jsp'. It is literally just concatenating those strings to make a path. The path is ALWAYS relative to the web application root here. If the path produced is a jsp file, it will be interpreted before being returned.
- Then it is finally returned to the user.
From your example you were requesting localhost:8080/ContextRoot/jsp/fileName, so it looks like 'CtxRoot' is the context root, your servlet's path is '/', so it should pass whatever is after that to a controller. By the time the DispatcherServlet receives the request, it is searching for a controller that handles 'jsp' as a path. Since you had none, it decided to treat that as a resource path. It used the view resolver and formed the path /WEB-INF/jsp/jsp/fileName.jsp, which obviously does not exist.
Let's assume that you had instead requested localhost:8080/ContextRoot/fileName, the request would reach the DispatcherServlet, it would find no Controller that handles 'fileName' as a path, and hence would treat it as a resource. It would form the path /WEB-INF/jsp/fileName.jsp, and that would return the result.
However, your web xml was not configured to initialize spring. So your web application was actually treating every one of your requests as if they were for a resource relative to the web application root. I believe that if you had made that request with Spring properly initialized, it might have worked.
Here is a good example of how to do it:
http://www.mkyong.com/spring3/spring-3-mvc-hello-world-example/
notice that his web xml has a ContextLoaderListener, which is commented out in yours, and it's essential for initializing spring in a web app. I also see the comment in your dispatcher with the path /src/main/resources, but all paths in web xml are supposed to be relative to the web application root. At runtime, the web server has no knowledge of your project, and 'src' is not a directory in your web app's root. Also note that you can have a different application context for your MVC stuff than your main spring context, and this is common.
I think if you do these things it will work:
- Move your jsp to /WEB-INF/jsp/fileName.jsp
- Update your app context so '/WEB-INF/jsp/' is the prefix, and '.jsp' is the suffix.
- Add the context loader listener to your web xml, and set the contextConfigLocation path relative to the app context root. For example, it could be /WEB-INF/appContext.xml
make a request to
localhost:8080/CtxtRoot/fileName
Also, you kept talking about the welcome-file, but you were giving full paths to resources. The welcome file only comes into play if the user makes a request to the root of a directory, like this:
localhost:8080/CtxtRoot/
That request would be forwarded to the welcome-file. I think the only time you tried that, the jsp happened to be in your app's root, and was configured as the welcome file, so it worked. While it "worked", it did NOT actually use spring to return that.
Good luck to you.