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
• WEB-INF/lib/{\*.jar}/META-INF/resources
• Just say no to Scarlett Johansson … (but say yes to Bean Validation)!
• javax.annotation.ManagedBean
• EJB 3.1 asynchrony and transactions
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).
Salut Michael,
The spec doesn’t have any such feature and GlassFish try to relieve the developer/admin by being smart about resource utilization.
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?
Separation of concerns. The person writing the code may not be the person deploying.