Servlet 3.0, fragments and web.xml to rule them all

Servlet 3.0 has some very nice ease-of-development features in the form of new annotations (such as @WebServlet) and some useful extensibility features with web-fragments (details here) and ServletContainerInitializer which all contribute to make web.xml optional. While this is a great step towards more modular applications and an overall development simplification, you may want to have more control over what’s being deployed in your production system. This is what metadata-complete helps you achieve.

web.xml contains a metadata-complete attribute in the web-app element whose binary value defines whether other sources of metadata should be considered when deploying this web application, this includes annotations on class files (@WebServlet, but also @WebListener, @WebFilter, …), web-fragment.xml as well as classes located in WEB-INF/classes. If set to true all of these will be ignored and web.xml is the only metadata considered. Setting it to false falls back to the default behavior. Note you can also use this attribute inside fragments to have them consider annotation or not. Check the Servlet 3.0 specification (section 15.5) for details on that part.

Better than a long blog entry, here’s a short screencast (available in HD) illustrating the basics of this feature :

You can try this all today in the most recent version of GlassFish.

Here are other Java EE 6-related “lesser-known features” :
Module initialization order in Java EE 6
Just say no to Scarlett Johansson … (but say yes to Bean Validation)!
EJB 3.1 asynchrony and transactions

Author: alexismp

Google Developer Relations in Paris.

4 thoughts on “Servlet 3.0, fragments and web.xml to rule them all”

  1. Hi Alexis,
    nice feature. When keeping the default behaviour for the metadata attribute, is there also a way to specify the packages you wan to scan? (so it does not inspect all Java files in the classpath).

  2. Salut Michael,
    The spec doesn’t have any such feature and GlassFish try to relieve the developer/admin by being smart about resource utilization.

  3. Although I don’t see the use of this attribute in the web-app but it might be there for backward compatibility.
    who will put the annotations and then decide to not use them in the deployment descriptor?

Comments are closed.