Reputation: 61
Why was web.xml removed from servlet 3.0 ?, and the configuration is now done through Java.
Upvotes: 0
Views: 3330
Reputation: 718788
Support for web.xml was NOT removed in Servlet 3.0, and (IMO) it is unlikely to be removed in the foreseeable future.
Evidence? If you download the Servlet 3.0 spec and search for "web.xml", you will see lots of references to it.
The most cogent quote is in A6.6
"A web application is NOT required to contain a web.xml if it does NOT contain any Servlet, Filter, or Listener components. In other words an application containing only static files or JSP pages does not require a web.xml to be present."
What it is saying is that a webapp is permitted to leave out the "web.xml" file ... but it is also permitted to include one. In other words, it is optional.
So why did they allow you to leave out "web.xml"? I can think of a couple of reasons:
It is often more convenient to do the configuration programatically or via annotations that way!
It is a violation of DRY principles to be doing configuration in different ways / places. If you can do the configuration in the Java source code via annotations and/or explicit calls, why do it in XML as well?
But the bottom line is that it is your choice.
Upvotes: 6
Reputation: 2711
One way to look at it is that now annotations provide the same configuration which was earlier provided by the web deployment descriptor (web.xml). Annotations or xml are read and understood by the engines which implement the relevant specification - tomcat, junit, etc. So overall they provide same functionality.
Xml configurations decouple the code from the configuration. But they can become polluted, can be difficult to maintain. You might hear things like convention over configuration, etc. I am not saying that all these drawbacks are applicable to web.xml. But they are about xml configurations, in general. xmls can get messy. Most of the times they are handwritten and prone to typos. Since they are not compiled (?)/ checked at the time of writing for syntax correctness, they may fail at runtime.
Annotations give the advantage of keeping the code and its configuration together. So the configuration is closer to where it belongs. You can know immediately a lot about code and its configurations just by looking at a class or method.
Nowadays - that is post java 5 - many of the frameworks and specifications are going the annotations way. For example, hibernate, spring, REST(jax rs), etc. To the best of my knowledge they still provide a way to manage your configuration by the use of xmls. Some of my colleagues still prefer xml, for example, in case of spring framework. I am more inclined towards annotations. This is a questions of preference and team style.
As to why did java ee team decided to go ahead with annotations, I think it must have been a decision by considering factors like these.
Upvotes: 2
Reputation: 8946
Before Servlet 3 for defining any deployment properties the only way to define was using deployments descriptors(web.xml).
Starting with Java EE 6, annotations such as @WebServlet, @WebFilter, @WebListener were introduced which lets you define the deployment properties in the java class itself. You do not have to mention them in web.xml. All the properties you can mention in web.xml can now be provided using @WebSerlvet annotation.
So as you can see there is no need to have any deployment descriptor.
So now the default web.xml generated will just contain this
<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">
and this will do no harm
Upvotes: 3
Reputation:
In Servlet 3.0 still web.xml is there but You can manage your application through Annotation approach which is added from Servlet 3.0.The Reason for that is only to remove the xml file from there......
Upvotes: 0