Hi, I am novice to servlets i have a simple question regarding servlets In earlier versions of webservers servlets are not deployed in web container the class files are simply copied to classes directory but in later versions servlets are deployed by editing the web.xml. What difference does it actually make? what are the advantages of deploying??
Using the deployment descriptor (web.xml) lets you define lots of important things, for instance initialization parameters. If you are going to do anything serious with servlets you need to understand web.xml. There is a downloadable PDF docuement available from this Sun site. Bill
I couldn't find anything specifically to do with the deployment descriptor (web.xml) after a quick browse around that link. I'm currently trying to fill in the gaps in my own understanding of what can be done in web.xml. Can you provide a direct link or recommend a good source?
One of the coolest things about web.xml is that you can configure things in a variety of ways so that you can make changes to an app and *sometimes* avoid changing source code.
With servlet mappings, for example, you can set up logical names for your components and then *map* URL requests that come into a logical servlet *name*, and that logical servlet *name* can in turn be mapped back to an actual class somewhere. That level of abstraction/indirection gives you a lot of flexiblity to make changes. You can do things such as set up a "virtual" kind of directory structure that doesn't have to look anything like the *real* directory structure of your web app, but instead presents something logical to clients, but is mapped into something very different back on the server. And most importantly, you're free to change what happens on the server without having any existing client code break, as long as the web.xml updates all the mappings correctly.
You can also do things in web.xml like configure filters to that without touching your existing servlets, you can suddenly *intercept* an incoming request and do some extra processing (either before or after the request, or both) that can dramatically affect the way your web app behaves, but again--WITHOUT CHANGING SOURCE CODE.
Security can be configured in web.xml so that you can decide which requests are for "constrained resources" which means the combination of a particular HTTP METHOD (POST, GET, etc.) and a specific URL pattern. For example, you could say that if a POST request comes in to anything within the /update/ directory (which if you're using mapping, might not even BE a "real" directory), you require that the client be authenticated and is a member of a particular security role (also configured in a deployment descriptor rather than hard-coded).
A few other things you can do include:
* Configuring welcome files -- imagine the user types in only a path but not a full resource, as when someone goes to www.javaranch.com *without* specifying an actual HTML or JSP, for example. You can configure things so that depending on what the user puts in as the URL, the Container knows what *default* thing to give back.
* Error files--if something goes wrong, including the always fun "404 NOT FOUND", you might want to show a custom error page for that. Or, you might want to show a custom page to your clients based on a specific Java exception type. You can figure both in the web.xml--in other words, you can configure error pages based on HTTP status code (like 404) OR on actual Java exception type.
* Servlet initialization parameters, as William mentioned. Imagine you want to have a specific value that you don't want to hard-code into servlets and JSPs, but you want all parts of your web app to have access to the value. You can customize this value at deploy-time by putting the name and value into the web.xml, then at runtime, your web resources (servlets and JSPs, etc.) can look it up.
*MIME mappings--you can tell the Container to set the content-type for all files with a particular extension.
So, that's just a tiny highlight of some of what you can do with web.xml. The cool thing is that it allows for deploy-time configuration rather than code/compile-time changes. But of course, it comes with the downside that when developers do things to the code... they must remember to update the DD (Deployment Descriptor, which in the current servlet spec must always be named "web.xml").
cheers, Kathy [ August 31, 2004: Message edited by: Kathy Sierra ]
Have u ever worked with J2ee ? . Thats it ! . Recent trend changed , hence people migrated from servlet to J2ee technology.
Now my point is : In case of J2ee technology , the application server needs to identify the type of application being used . [ like Jsp or Servlet or Ejb ? ] To specify ur application type [ like , servlet ] you create a special file in .xml format . That file is used by application server & it identifies that ur application is servlet type.
Author and all-around good cowpoke
posted 15 years ago
Its true that Sun does hide the servlet spec document I was talking about. Specific link to a download page. Bill