Serving Static Content with Servlet 3.0

(aka WEB-INF/lib/{\*.jar}/META-INF/resources)

Modularity is one of the themes for Java EE 6 and servlet 3.0 fragments are often mentioned as one example of this (see details here). This blog entry is about a small yet very useful new feature of the servlet 3.0 specification to deal with static content such as images, CSS or JavaScript. Before servlet 3.0, images could be made accessible from the root of the web applications but that meant copying the files to the WAR archive and keeping them up-to-date. This certainly meant a solution tightly coupled with the web application development and packaging. The other option was to place this static content in the docroot of the application server which was in turn time probably too loosely coupled allowing for anyone to access this and encouraging every application to use the same set of static content. With Servlet 3.0, a JAR placed in WEB-INF/lib has static content from its META-INF/resource directory accessible from the web-context root. You can also parse this previous statement with WEB-INF/lib/{\*.jar}/META-INF/resources. So this means you no longer need to use the ServletContext getResource() and getResourceAsStream() methods with some rather dumb rewriting. In this simple web application WAR example : … the static resources are available from : http://host:port/webcontext/scripts.js http://host:port/webcontext/styles.css http://host:port/webcontext/welcome.png where http://host:port/webcontext/ could be replaced with the relative path “./” This makes for more modular applications. Other than images, think of how this applies to CSS and javascript. It’s probably now a good idea to package JavaScript libraries such a jquery or dojo in a dedicated JAR (effectively a resource JAR). The other use-case I can think of is configuration files. One could deploy with WEB-INF/lib/testing.jar or with WEB-INF/lib/production.jar each of which containing META-INF/resources/config.properties file with different content. The application code reading the configuration would always access it using ./config.properties (or http://host:port/webcontext/config.properties). Note this mechanism also applies to JSPs and that resource files placed in the document root take precedence. Get all the details from paragraph 10.5 of the Servlet 3.0 specification. Try this out today in GlassFish 3 and above.

Author: alexismp

Google Developer Relations in Paris.

6 thoughts on “Serving Static Content with Servlet 3.0”

  1. It’s definitely a nice feature, thanks for sharing.
    But I don’t think it’s a good idea to put configuration files in META-INF/resources because they are exposed through HTTP and an attacker could learn some things about your configuration just by browsing your webapp.

  2. You can’t list the content of the resources directory and the rest of the webapp is not available either. Am I missing something?

  3. Maybe I’m too paranoid, but I think that an attacker can guess the filenames. Some people are really good at this with Apache’s httpd to find unprotected configuration or system files that are exposed through HTTP.
    But if you name your file with something really difficult to guess, there should be no issues.

  4. Well, yes that comment would certainly apply to files you do not want to be shared outside of your application such as the config file scenario.

  5. Hello,
    Nice tutorial. Where can we find the war ?
    I will test it in a real case for us.
    Best regards, Nicolas (aka zepouet)

Comments are closed.