I'm not sure how to start on this, but I currently have a simple application that has a home page url of
localhost:8080/projectName/homePage.jsp
However, I'd like it so that
localhost:8080/projectName/
OR
localhost:8080/projectName
sends me to the homePage.jsp.
I've read about an index.jsp that was created by eclipse in other projects, but it seems like that hasn't been done for me - do I need to create this? I'm not using a web.xml, and am instead relying on #WebServlet to do wiring.
2 ways to do this.
1. Add an entry in web.xml as follows
<welcome-file-list>
<welcome-file>homepage.jsp</welcome-file>
</welcome-file-list>
2. create an index.jsp file in your WebContent folder and forward the request to homePage.jsp
According to the following post there is no such way possible with annotation:
Servlet 3.0 annotations <welcome-file>
I have a web application deployed as war file in weblogic 10.3.3. Now I want to make this application clusterable. For this I'm using the HttpClusterServlet from Weblogic as a load balancer. According to the documentation I can put this servlet configuration into the web.xml
<servlet>
<servlet-name>HttpClusterServlet</servlet-name>
<servlet-class>weblogic.servlet.proxy.HttpClusterServlet</servlet-class>
<init-param>
<param-name>WebLogicCluster</param-name>
<param-value>server-1:7122|server-1:7123</param-value>
</init-param>
</servlet>
The problem is that this configuration is hard wired at build time and can't be reconfigured at runtime. For instance I would like to be able to add 5 more servers dynamically. I had several ideas to solve that problem:
Extend the weblogic.servlet.proxy.HttpClusterServlet with an own servlet implentation. This is not possible, the class is final.
Use a servlet filter to reconfigure the servlet. The servlet is not accessible anymore through ServletContext().getServlet(String) since Java Servlet API 2.1, with no direct replacement.
Reflection might be an option, but I couldn't figure out a reliable way to access the configuration
All of my attempts to reconfigure this init-param externally failed so far. I'm open to any solutions.
This might help How to externalize web.xml servlet init-param? Spring DelegatingFilterProxy for Servlets? Even if your not using Spring it wouldn't be too hard to port that servlet to another IoC container.
Following an issue reported on this question, a solution was found:
req.setAttribute("org.apache.catalina.ASYNC_SUPPORTED", true);
This seems a bit strange and is not really 'portable' code (it won't hurt, but...). It seems specific to Tomcat 7. I am using Tomcat 7.0.14 as delivered by NetBeans 7.0.1.
I could not find documentation indicating it is necessary to enable async request processing in servlet 3.0 with a catalina attribute. I could not find documentation indicating something special was necessary at the Tomcat configuration level too.
Is there a way to avoid having to set ASYNC_SUPPORTED=true in each request to enable async servlet 3.0 processing in Tomcat 7?
A couple of things to check first:
Make sure any filters that operate on the request also support async (as addressed in one of the answers to the question you referenced).
Make sure you're using a Servlet 3.0 web.xml - for example:
<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">
Try upgrading.
Bug 53623 fixed in 7.0.30.
"Enable remaining valves for Servlet 3 asynchronous processing support." (fixed in 7.0.16)
Check the Tomcat 7 ChangeLog for complete details.
Also, if you want to use async, then you'll need to make sure that all of the filters and valves in the chain (as well as the servlet, of course) all support async. This is likely the problem in the original question, as well as with your case, here.
I found that org.apache.catalina.ASYNC_SUPPORTED=true is only needed when you from one normal-servlet/jsp (internally) forward to an async-servlet!
Example: In my index.jsp, I embed <jsp:forward page="/path/AsyncServlet" />
I promise the AsyncServlet works fine on both Tomcat7 and Glassfish3, when I directly trigger it from browser!
However when I trigger it by index.jsp:
Tomcat7 reports 500 for "Not supported"
Glassfish3 reports 500 for "Request is within the scope of a filter or servlet that does not support asynchronous operations"
If I embed <% request.setAttribute("org.apache.catalina.ASYNC_SUPPORTED", true); %> before <jsp:forward> in index.jsp, Tomcat7 goes OK, but Glassfish3 still is BAD!
So I found a solution for both Tomcat7 and Glassfish3 (without SYNC_SUPPORTED!):
Just EXACTLY attach followings in web.xml:
<servlet>
<servlet-name>indexPage</servlet-name>
<jsp-file>/index.jsp</jsp-file>
<async-supported>true</async-supported>
</servlet>
<servlet-mapping>
<servlet-name>indexPage</servlet-name>
<url-pattern>/index.jsp</url-pattern>
</servlet-mapping>
Conclusion (for me):
You can NOT forward from a normal-servlet/jsp/filter to an async-one! Since the async-request feature MUST be preset!
So the common solution for a servlet/jsp/filter which needs to forward to an async-servlet is:
Use <servlet>/<async-supported>true or #WebServlet(asyncSupported = true) for a pre-processed servlet;
Use <servlet>/<async-supported>true for a pre-processed jsp
Use <filter>/<async-supported>true or #WebFilter(asyncSupported = true) for a pre-processed filter;
Hope this may help a little bit!
I have always wondered why so many Java developers use ".do" as the extension for their web controller (MVC) resources. Example: http://example.com/register.do
It doesn't even seem to be framework specific as I have seen it in Spring MVC and Struts projects.
Where did this ".do" extension practice come from. Why was this done instead of no extension?
I feel like I missed the Java world memo on this.
Personally I prefer no extension.
To my knowledge, this convention has been spread by Struts1. The user guide puts it like this:
5.4.2 Configure the ActionServlet Mapping
Note: The material in this section is not specific to Struts. The
configuration of servlet mappings is
defined in the Java Servlet
Specification. This section describes
the most common means of configuring a
application.
There are two common approaches to
defining the URLs that will be
processed by the controller servlet --
prefix matching and extension
matching. An appropriate mapping entry
for each approach will be described
below.
Prefix matching means that you want
all URLs that start (after the context
path part) with a particular value to
be passed to this servlet. Such an
entry might look like this:
<servlet-mapping>
<servlet-name>action</servlet-name>
<url-pattern>/do/*</url-pattern>
</servlet-mapping>
which means that a request URI to
match the /logon path described
earlier might look like this:
http://www.mycompany.com/myapplication/do/logon
where /myapplication is the context
path under which your application is
deployed.
Extension mapping, on the other hand,
matches request URIs to the action
servlet based on the fact that the URI
ends with a period followed by a
defined set of characters. For
example, the JSP processing servlet is
mapped to the *.jsp pattern so that
it is called to process every JSP page
that is requested. To use the *.do
extension (which implies "do
something"), the mapping entry would
look like this:
<servlet-mapping>
<servlet-name>action</servlet-name>
<url-pattern>*.do</url-pattern>
</servlet-mapping>
and a request URI to match the
/logon path described earlier might
look like this:
http://www.mycompany.com/myapplication/logon.do
WARNING - The framework will not operate correctly if you define more
than one <servlet-mapping> element
for the controller servlet.
WARNING - If you are using the new module support since version 1.1, you
should be aware that only extension
mapping is supported.
And I think this convention has been kept (sometimes to not change URLs even after replacing Struts1, sometimes just because people were happy with it).
It was common practice to map your struts servlet to *.do in web.xml to pass URLs to the struts servlet. For example:
<!-- Standard Action Servlet Mapping -->
<servlet-mapping>
<servlet-name>action</servlet-name>
<url-pattern>*.do</url-pattern>
</servlet-mapping>
There is really no reason except convention for this. If you use no extension you need to do some magic to handle images and other static content in a way that doesn't send them to your sevlet. Often this gets done at a load balancer of a fronting web server.
I've mapped the Spring MVC dispatcher as a global front controller servlet on /*.
<servlet>
<servlet-name>home</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>home</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
However, this mapping stops the access to static files like CSS, JS, images etc which are all in the /res/ folder.
How can I access them anyway?
Map the controller servlet on a more specific url-pattern like /pages/*, put the static content in a specific folder like /static and create a Filter listening on /* which transparently continues the chain for any static content and dispatches requests to the controller servlet for other content.
In a nutshell:
<filter>
<filter-name>filter</filter-name>
<filter-class>com.example.Filter</filter-class>
</filter>
<filter-mapping>
<filter-name>filter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<servlet>
<servlet-name>controller</servlet-name>
<servlet-class>com.example.Controller</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>controller</servlet-name>
<url-pattern>/pages/*</url-pattern>
</servlet-mapping>
with the following in filter's doFilter():
HttpServletRequest req = (HttpServletRequest) request;
String path = req.getRequestURI().substring(req.getContextPath().length());
if (path.startsWith("/static")) {
chain.doFilter(request, response); // Goes to default servlet.
} else {
request.getRequestDispatcher("/pages" + path).forward(request, response);
}
No, this does not end up with /pages in browser address bar. It's fully transparent. You can if necessary make "/static" and/or "/pages" an init-param of the filter.
With Spring 3.0.4.RELEASE and higher you can use
<mvc:resources mapping="/resources/**" location="/public-resources/"/>
As seen in Spring Reference.
What you do is add a welcome file in your web.xml
<welcome-file-list>
<welcome-file>index.html</welcome-file>
</welcome-file-list>
And then add this to your servlet mappings so that when someone goes to the root of your application, they get sent to index.html internally and then the mapping will internally send them to the servlet you map it to
<servlet-mapping>
<servlet-name>MainActions</servlet-name>
<url-pattern>/main</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>MainActions</servlet-name>
<url-pattern>/index.html</url-pattern>
</servlet-mapping>
End result: You visit /Application, but you are presented with /Application/MainActions servlet without disrupting any other root requests.
Get it? So your app still sits at a sub url, but automatically gets presented when the user goes to the root of your site. This allows you to have the /images/bob.img still go to the regular place, but '/' is your app.
If you use Tomcat, you can map resources to the default servlet:
<servlet-mapping>
<servlet-name>default</servlet-name>
<url-pattern>/static/*</url-pattern>
</servlet-mapping>
and access your resources with url http://{context path}/static/res/...
Also works with Jetty, not sure about other servlet containers.
Serving static content with appropriate suffix in multiple servlet-mapping definitions solved the security issue which is mentioned in one of the comments in one of the answers posted. Quoted below:
This was a security hole in Tomcat (WEB-INF and META-INF contents are accessible this way) and it has been fixed in 7.0.4 (and will be ported to 5.x and 6.x as well). – BalusC Nov 2 '10 at 22:44
which helped me a lot.
And here is how I solved it:
<servlet-mapping>
<servlet-name>default</servlet-name>
<url-pattern>*.js</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>default</servlet-name>
<url-pattern>*.css</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>default</servlet-name>
<url-pattern>*.jpg</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>default</servlet-name>
<url-pattern>*.htm</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>default</servlet-name>
<url-pattern>*.html</url-pattern>
</servlet-mapping>
I've run into this also and never found a great solution. I ended up mapping my servlet one level higher in the URL hierarchy:
<servlet-mapping>
<servlet-name>home</servlet-name>
<url-pattern>/app/*</url-pattern>
</servlet-mapping>
And now everything at the base context (and in your /res directory) can be served up by your container.
As of 3.0.4 you should be able to use mvc:resources in combination with mvc:default-servlet-handler as described in the spring documentation to achieve this.
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/mvc.html#mvc-static-resources
The reason for the collision seems to be because, by default, the context root, "/", is to be handled by org.apache.catalina.servlets.DefaultServlet. This servlet is intended to handle requests for static resources.
If you decide to bump it out of the way with your own servlet, with the intent of handling dynamic requests, that top-level servlet must also carry out any tasks accomplished by catalina's original "DefaultServlet" handler.
If you read through the tomcat docs, they make mention that True Apache (httpd) is better than Apache Tomcat for handling static content, since it is purpose built to do just that. My guess is because Tomcat by default uses org.apache.catalina.servlets.DefaultServlet to handle static requests. Since it's all wrapped up in a JVM, and Tomcat is intended to as a Servlet/JSP container, they probably didn't write that class as a super-optimized static content handler. It's there. It gets the job done. Good enough.
But that's the thing that handles static content and it lives at "/". So if you put anything else there, and that thing doesn't handle static requests, WHOOPS, there goes your static resources.
I've been searching high and low for the same answer and the answer I'm getting everywhere is "if you don't want it to do that, don't do that".
So long story short, your configuration is displacing the default static resource handler with something that isn't a static resource handler at all. You'll need to try a different configuration to get the results you're looking for (as will I).
'Static' files in App Engine aren't directly accessible by your app. You either need to upload them twice, or serve the static files yourself, rather than using a static handler.
The best way to handle this is using some kind of URL re-writing. In this way, you can have clean restful URLs, and NOT with any extensions i.e abc.com/welcom/register as opposed to abc.com/welcome/resister.html
I use Tuckey URL which is pretty cool.
It's got instructions on how to set up your web app.I have set it up with my Spring MVC web app. Of course, everything was fine until I wanted to use annotations for Spring 3 validations like #Email or #Null for domain objects.
When I add the Spring mvc directives:
< mvc:annotation-driven />
< mvc:default-servlet-handler />
.. it breaks the good ol Tuckey code. Apparently, < mvc:default-servlet-handler /> replaces Tuckey, which I'm still trying to solve.
I'd recommend trying to use a Filter instead of a default servlet whenever possible.
Other two possibilities:
Write a FileServlet yourself. You'll find plenty examples, it should just open the file by URL and write its contents into output stream. Then, use it to serve static file request.
Instantiate a FileServlet class used by Google App Engine and call service(request, response) on that FileServlet when you need to serve the static file at a given URL.
You can map /res/* to YourFileServlet or whatever to exclude it from DispatcherServlets' handling, or call it directly from DispatcherServlet.
And, I have to ask, what does Spring documentation say about this collision? I've never used it.
Add the folders which you don't want to trigger servlet processing to the <static-files> section of your appengine-web.xml file.
I just did this and looks like things are starting to work ok. Here's my structure:
/
/pages/<.jsp files>
/css
I added "/pages/**" and "/css/**" to the <static-files> section and I can now forward to a .jsp file from inside a servlet doGet without causing an infinite loop.
After trying the filter approach without success (it did for some reason not enter the doFilter() function) I changed my setup a bit and found a very simple solution for the root serving problem:
Instead of serving " / * "
in my main Servlet, I now only listen to dedicated language prefixes
"EN", "EN/ *", "DE", "DE/ *"
Static content gets served by the default Servlet and the empty root requests go to the index.jsp which calls up my main Servlet with the default language:
< jsp:include page="/EN/" />
(no other content on the index page.)
I found that using
<mvc:default-servlet-handler />
in the spring MVC servlet bean definition file works for me. It passes any request that isn't handled by a registered MVC controller on to the container's original default handler, which should serve it as static content. Just make sure you have no controller registered that handles everything, and it should work just fine. Not sure why #logixplayer suggests URL rewriting; you can achieve the effect he's looking for just adequately using Spring MVC alone.
I found a simpler solution with a dummy index file.
Create a Servlet (or use the one you wanted to respond to "/") which maps to "/index.html"
(Solutions mentioned here use the mapping via XML, I used the 3.0 version with annotation #WebServlet)
Then create a static (empty) file at the root of the static content named "index.html"
I was using Jetty, and what happened was that the server recognized the file instead of listing the directory but when asked for the resource, my Servlet took control instead. All other static content remained unaffected.
In Embedded Jetty I managed to achieve something similar by adding a mapping for the "css" directory in web.xml. Explicitly telling it to use DefaultServlet:
<servlet>
<servlet-name>DefaultServlet</servlet-name>
<servlet-class>org.eclipse.jetty.servlet.DefaultServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>DefaultServlet</servlet-name>
<url-pattern>/css/*</url-pattern>
</servlet-mapping>
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:mvc="http://www.springframework.org/schema/mvc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
http://www.springframework.org/schema/mvc
http://www.springframework.org/schema/mvc/spring-mvc-3.0.xsd">
<mvc:default-servlet-handler/>
</beans>
and if you want to use annotation based configuration use below code
#Override
public void configureDefaultServletHandling(DefaultServletHandlerConfigurer configurer) {
configurer.enable();
}
With regard to Tomcat, a lot depends on the particular version. There was a bug fix
https://bz.apache.org/bugzilla/show_bug.cgi?id=50026
which means the servlet-mapping (other than for '/') for the default servlet behaves differently in Tomcat 6.0.29 (and earlier) compared with later versions.
In section "12.2 Specification of Mappings" of the Servlet Specification, it says:
A string containing only the ’/’ character indicates the "default" servlet of the
application.
So in theory, you could make your Servlet mapped to /* do:
getServletContext().getNamedDispatcher("/").forward(req,res);
... if you didn't want to handle it yourself.
However, in practice, it doesn't work.
In both Tomcat and Jetty, the call to getServletContext().getNamedDispatcher('/') returns null if there is a servlet mapped to '/*'