• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

When web.xml is nessary?

 
Himai Minh
Ranch Hand
Posts: 1359
7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
According to section 10.13 of servlet 3.0 spec:

A web application is not required to container a web.xml....
In other words an application containing only static files or JSP page does not require a web.xml to be present.


So, when web.xml is necessary?
 
Paul Anilprem
Enthuware Software Support
Ranch Hand
Posts: 3817
10
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is not necessary (i.e. "required") at all. Since pretty much everything can be done by annotations, you don't really need web.xml as much. But it is still useful for things like context parameters. Also, if you want to customize (or add to) the default behavior specified in annotations, without changing the code.
 
Tim Holloway
Saloon Keeper
Posts: 18359
56
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The web.xml file is necessary when:

1. Annotations have not been provided for one or more resources that must be defined in a web.xml context to be usable.

AND/OR

2. You wish to override an annotation value for one or more resources that must be defined in a web.xml context to be usable.

Functionally "web.xml" always exists, it's just that in olden days, you had to define it all manually and explicitly. Now it's possible for a "virtual" web.xml to be produced. This virtual web.xml is constructed by scanning the classes for web.xml-context annotations and building up equivalents. Then, if a physical web.xml exists, any entries not supplied from the annotation scan will be added and any entries that overlap annotations will override the annotation values. This is in accordance with the general practice regarding annotation specifications - class annotations are used unless overridden by an explicit outside source (usually an XML file). That reduces or eliminates the need for separate out-of-line definitions, since the XML file needs only to contain exceptions to the defaults (and any missing entries).

Incidentally, every J(2)EE web application has 2 "deployment descriptors" which define how the webapp is to be deployed and wired into the server (URL routing, resource definitions, etc.) There's a server-dependent deployment descriptor which defines server-specific characteristics. For example, a Tomcat webapp's server-dependent is its Context xml definition (which can be supplied externally, as part of a WAR, or automatically constructed from defaults). Other servers have other server-dependent deployment descriptor files and formats.

For characteristics that are not specific to a particular brand of server, there's the server-independent deployment descriptor. Which is the WEB-INF/web.xml file or an automatically constructed equivalent.
 
Marcos R Oliveira
Ranch Hand
Posts: 62
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Tim Holloway wrote:The web.xml file is necessary when:

1. Annotations have not been provided for one or more resources that must be defined in a web.xml context to be usable.

AND/OR

2. You wish to override an annotation value for one or more resources that must be defined in a web.xml context to be usable.

Functionally "web.xml" always exists, it's just that in olden days, you had to define it all manually and explicitly. Now it's possible for a "virtual" web.xml to be produced. This virtual web.xml is constructed by scanning the classes for web.xml-context annotations and building up equivalents. Then, if a physical web.xml exists, any entries not supplied from the annotation scan will be added and any entries that overlap annotations will override the annotation values. This is in accordance with the general practice regarding annotation specifications - class annotations are used unless overridden by an explicit outside source (usually an XML file). That reduces or eliminates the need for separate out-of-line definitions, since the XML file needs only to contain exceptions to the defaults (and any missing entries).

Incidentally, every J(2)EE web application has 2 "deployment descriptors" which define how the webapp is to be deployed and wired into the server (URL routing, resource definitions, etc.) There's a server-dependent deployment descriptor which defines server-specific characteristics. For example, a Tomcat webapp's server-dependent is its Context xml definition (which can be supplied externally, as part of a WAR, or automatically constructed from defaults). Other servers have other server-dependent deployment descriptor files and formats.

For characteristics that are not specific to a particular brand of server, there's the server-independent deployment descriptor. Which is the WEB-INF/web.xml file or an automatically constructed equivalent.


Hi, Tim! Thank you so much for your explanation!
The minute I read your POST I went right to code to make some tests and I've noticed that when comes to the filter dispatcher configuration, if it is present in both XML and annotation their values are cumulative, e.g., if we have a web.xml



and an annotaded filter as



then we have a filter that is triggered for both dispatchers: FORWARD and INCLUDE

Do you know if this behavior is mentioned somewhere in the specification? I couldn't find it.

I'm using a maven jetty plugin 9.2.15 and servlet api 3.0.1 for my tests.

Best regards,
Marcos.
 
Tim Holloway
Saloon Keeper
Posts: 18359
56
Android Eclipse IDE Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Actually, I think that makes sense when you consider that the selection characteristics are based on URL pattern and dispatcher to map them to a servlet or filter ID.

If would be the equivalent of this if done entirely old-style in web.xml:


Although you could consolidate the 2 filter mappings into one, I don't think you have to, and it might even be preferable not to if you're interested in selecting the order in which filters are invoked.

In the Oracle docs (such as they are, and discounting the fact that they're entirely too invested in NetBeans) you'll find this statement:
The order of the filters in the chain is the same as the order in which filter mappings appear in the web application deployment descriptor.

Source: https://docs.oracle.com/javaee/6/tutorial/doc/bnagb.html

The "web application deployment descriptor" is /WEB-INF/web.xml. More accurately, it's the "server-independent web application deployment descriptor." The server-dependent web application deployment descriptor is the file or resource that provides deployment information specific to a particular branch and version of web application server. For example, in Apache Tomcat, it's the "Context" element. Every webapp has one of each, although, like web.xml, the server-dependent deployment descriptor may be internally synthesized (in Tomcat, by dumping the WAR into the TOMCAT_HOME/webapps directory without supplying an explicit Context definition).

One thing you might notice is that although the so-called web application deployment descriptor can specify the order in which filters chain, there's no equivalent in the annotations for resolving chain sequence. Actually, it would be pretty difficult, since one of the points behind annotations is to make classes self-contained and the very concept of chaining demands knowledge outside the class.
 
Marcos R Oliveira
Ranch Hand
Posts: 62
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks again! You've made excellent points! I specially liked:

"Although you could consolidate the 2 filter mappings into one, I don't think you have to, and it might even be preferable not to if you're interested in selecting the order in which filters are invoked."

and

"... Actually, it would be pretty difficult, since one of the points behind annotations is to make classes self-contained and the very concept of chaining demands knowledge outside the class."

Best regards,
Marcos.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic