This week's book giveaway is in the HTML Pages with CSS and JavaScript forum.
We're giving away four copies of Testing JavaScript Applications and have Lucas da Costa on-line!
See this thread for details.
Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Deploying servlets

 
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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??

Thanks in advance,
priya.
 
Author and all-around good cowpoke
Posts: 13078
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 823
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi 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?

Thanks

Jules
 
Cowgirl and Author
Posts: 1589
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Ranch Hand
Posts: 185
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi !

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.

Thats all.
 
William Brogden
Author and all-around good cowpoke
Posts: 13078
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Its true that Sun does hide the servlet spec document I was talking about.
Specific link to a download page.
Bill
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    Bookmark Topic Watch Topic
  • New Topic