aspose file tools*
The moose likes Servlets and the fly likes is web.xml compulsory Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Servlets
Bookmark "is web.xml compulsory" Watch "is web.xml compulsory" New topic
Author

is web.xml compulsory

amit taneja
Ranch Hand

Joined: Mar 14, 2003
Posts: 806
hi..
pls answer my silly question..

is writing a web.xml file (DD) is compulsary for viewing servlet..
can't we type direrct url to serlvet ?
i think we can..

just need acknolwedgement

actullay i tried but not successfull and not able to find the reason..

just give me acknolwedgement without commenting coz i know its a silly question but still answer staright forwardly..

i will appreciate your reply
regards
[ July 18, 2005: Message edited by: amit taneja ]

Thanks and Regards, Amit Taneja
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60059
    
  65

You need a web.xml.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Sharad Agarwal
Ranch Hand

Joined: Sep 11, 2002
Posts: 167
The servlet needs to be defined in the deployment descriptor for it to be reachable directly.


Alco-Haul: We move spirits.
Demented Deliberations of a Dilettante
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12682
    
    5
can't we type direrct url to serlvet ?
i think we can..

You are probably thinking of examples that use the "invoker" servlet. The invoker was a shortcut used in early work with servlets. IMHO it caused much more trouble than it was worth. See this FAQ here at the ranch.
You might as well just go ahead and learn how to use web.xml - you will be glad you did.
Bill


Java Resources at www.wbrogden.com
Harinath Kuntamukkala
Ranch Hand

Joined: May 17, 2005
Posts: 37
Without web.xml u can't;its deployment descriptor for running servlets in web container
vijaya bharath
Ranch Hand

Joined: Jun 10, 2005
Posts: 66
Hi,

Your question is not silly, we can think in different dimensions.OK.Come to u r question u asked like cant we directly use the url name and thing here is if u and me are writing the servlet and we both gave the same url name , how can it differs the 2 servlets with the url. There ambiguity occurs. So to avoid this we specify url in the web.xml and corresponding mapping to that url in the web.xml only. In the real time applications different people develops different modules. So there is no guarantee that they may give same url name, there the mapping in that corresponding module's web.xml helps. I think u got my point.


Regards,<br />Vijaya Bharath.<br />SCJP1.4 <br />SCWCD5.0
Sirish Kumar Gongal Reddy
Ranch Hand

Joined: Oct 25, 2004
Posts: 109
Hi!
very wise question you asked not silly one.the main purpose of WEB.XML
1)Is to customize your application with out touching your actual code.
2)Container can lookup your class from deployment descriptor ther is one tag called servlet-class,other wise your container won't lookup your class.
3)you are using you web.xml for alias names means while your application in developement mode you can put your own name for your class and your application in reday to deploy mode your application assembler(is a person) can put a another name i.e a public url.
These are some instances plz go thru HF S$J you find a lot info.
Thanking you,
Regards,
G Sirish Reddy.,
Mukesh Sehgal
Greenhorn

Joined: Oct 10, 2003
Posts: 11
I guess you might have got your answer by now and after going through all the replies, I doubt I could say anything different but still....
You do need a DD file in order to make your application work as web.xml is the place where container comes at first to see which corresponding class file is to be invoked with some particular URL name. Though what you said regarding this is not a wise thing to do (stated in one of the replies....)

Anyways try it out again and see where the problem lies..... do tell me if you come to know something interesting.
D Rog
Ranch Hand

Joined: Feb 07, 2004
Posts: 472

It depends on servlet container. Usually you need to type servlet class name in URL. web.xml is a new J2EE stuff and I do not see much benefits of it. Check my footer if you need a real good servlet container.


Retire your iPod and start with HD Android music player Kamerton | Minimal J2EE container is here | Light weight full J2EE stack | and build tool | Co-author of "Windows programming in Turbo Pascal"
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60059
    
  65

Usually you need to type servlet class name in URL.


Bad, bad, bad idea. Read this.
Ben Souther
Sheriff

Joined: Dec 11, 2004
Posts: 13410

Originally posted by Bear Bibeault:


Bad, bad, bad idea. Read this.


I second that.
Tomcat's own creators have called the invoker evil.
There is no reason why the concept isn't as evil in any other container.

<side note>
If this thread is to continue (which seems likely) would someone who can, please fix the spelling of 'compulsory'?
</side note>


Java API J2EE API Servlet Spec JSP Spec How to ask a question... Simple Servlet Examples jsonf
D Rog
Ranch Hand

Joined: Feb 07, 2004
Posts: 472

Evil because:
Security risk ... see links above

It's Tomcat security problem, consider Tomcat just yet another servlet container (not only one).

Configuration hiding - There is NO way to determine which servlets are used vs which are not used. In web.xml, every servlet is declared and mapped. In that one file you instantly have a road map to how the webapp works.

It doesn't make sense, web.xml just tells me which is used, but not which not. Correct me if you think different.

Back doors. Servlets which are mapped can be alternately called via the invoker by class name. Since the URL is different, all security constraints might be ignored since the URL pattern is VERY different.

Hmm. Sound reasonable to do not mix two ways of calling servlet, but nothing more.

Back doors. Bad programmers make it easier to do bad things.

No sense. Bad programmers can generates backdoors, regardless of way of serlvet invocation. Why servlet called used web.xml more safe than called using invoker?

Back doors. It may be common to use common 3rd party jars in a shared area. If that shared jar has servlets in them and that servlet has a hole in it, bad things happen.

Servlet invoker can apply package rules to avoid calling servlet from 3rd party libraries.

Configuration hiding - it's important enough to say twice. Explicit declaration while a PITA, will be more helpful in the maintenance scheme of your webapp.

It's very questionable. How often do you change web.xml for maintenance purpose? Give a good example.
Ben Souther
Sheriff

Joined: Dec 11, 2004
Posts: 13410

Originally posted by D Rog:
Evil because:
Security risk ... see links above

It's Tomcat security problem, consider Tomcat just yet another servlet container (not only one).

Configuration hiding - There is NO way to determine which servlets are used vs which are not used. In web.xml, every servlet is declared and mapped. In that one file you instantly have a road map to how the webapp works.

It doesn't make sense, web.xml just tells me which is used, but not which not. Correct me if you think different.

I do.
Without an invoker servlet, the only servlets that are used are the ones that I've mapped in web.xml -- period.


Back doors. Servlets which are mapped can be alternately called via the invoker by class name. Since the URL is different, all security constraints might be ignored since the URL pattern is VERY different.

Hmm. Sound reasonable to do not mix two ways of calling servlet, but nothing more.

If you have an invoker running, you don't control the ways of calling servlets. Anyone who can type an address in a browser window can call the servlets via the invoker.


Back doors. Bad programmers make it easier to do bad things.

No sense. Bad programmers can generates backdoors, regardless of way of serlvet invocation. Why servlet called used web.xml more safe than called using invoker?

If I'm using a 3rd party library (jar) to perform some special function and there is a servlet in there that I don't know about, someone who does can call that servlet via the invoker. Without the invoker, they can put all the servlets they like in the library. The only ones that can be run, however, are the ones specifically declared in my web.xml file.



Back doors. It may be common to use common 3rd party jars in a shared area. If that shared jar has servlets in them and that servlet has a hole in it, bad things happen.

Servlet invoker can apply package rules to avoid calling servlet from 3rd party libraries.

And this makes more sense than a white list of allowed servlets with specific mappings?
Saravanan Thirugnanam
Greenhorn

Joined: Jan 19, 2005
Posts: 20
I haven't worked with JBoss server.But i heard that servlets can be executed without using web.xml in JBoss.Is it true? :roll:


saravanan T
Ben Souther
Sheriff

Joined: Dec 11, 2004
Posts: 13410

JBoss uses Tomcat as it's servlet/jsp engine.
D Rog
Ranch Hand

Joined: Feb 07, 2004
Posts: 472

All your arguments are based on specific of your product. If you package hundred servlets in one application library and then just specified used in web.xml, then you may be right. But I strongly disagree to overload a product with a huge amount of useless code. Why don't you just package all servlets separately? Oh, I know,probably your servlets use code from other servlets, but it seems bad design pattern. Pull all your common code in one library which doesn't contain any servlet and supply it with any one.
[ July 19, 2005: Message edited by: D Rog ]
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60059
    
  65

Sorry, but security through obscurity is no security at all.

Regardless of whether a servlet class is actively in use for a web app or not (are you seriously saying that you go through any 3rd party jars that you use and weed out any classes that are not in active use? -- be serious!), being able to invoke it by classname is madness.
[ July 19, 2005: Message edited by: Bear Bibeault ]
D Rog
Ranch Hand

Joined: Feb 07, 2004
Posts: 472

Using web.xml as a way to define a way to invoke servlet doesn't make application secure. Most of security holes reside in code you call in right way using web.xml. So generally you may only imagine that direct class invocation will lose your control and increase security risk. It's a good for academic research but not for practical everyday programming.
Yes, I'd prefer finer granularity in 3rd parties class libraries, however it should be concern of a developer of libraries. As you may notice, many company prefer to sell software by modules, not everything in one. And reason of that is not only marketing. In other words we discuss CMP vs BMP, when you have control in your code or you have control in some deployment descriptor. Both approaches have certain advantages, but it's insane to be so strict to name bad what you do not like for some reasons.
Ben Souther
Sheriff

Joined: Dec 11, 2004
Posts: 13410

Originally posted by D Rog:
Using web.xml as a way to define a way to invoke servlet doesn't make application secure.

It's not that having a web.xml make it more secure.
It's the disabling of the invoker (or whatever mechanism your app server has for allow direct calls to servlets via class name) that makes it more secure. This is not specific to any one app server.


Most of security holes reside in code you call in right way using web.xml. So generally you may only imagine that direct class invocation will lose your control and increase security risk. It's a good for academic research but not for practical everyday programming.

For practical everyday programming, the simplest way to insure that no servlets get called other than than the ones that you've intended is to build a white list yourself.
This is much more practical than scouring every third party library for servlets.

Yes, I'd prefer finer granularity in 3rd parties class libraries, however it should be concern of a developer of libraries. As you may notice, many company prefer to sell software by modules, not everything in one.

This is beside the point.
In the real world, people rely on 3rd party code.
The granularity is irrelevant.
If you add a 3rd party jar, there is the possibility that there is servlet code in there. Combine that with the ability for people to call servlets directly from the URL and you have surrendered control of your app.

And reason of that is not only marketing. In other words we discuss CMP vs BMP, when you have control in your code or you have control in some deployment descriptor. Both approaches have certain advantages, but it's insane to be so strict to name bad what you do not like for some reasons.

This isn't one or two people 'naming something bad'.
The invoker concept has been around for a while and has proven, over time, to be a bad idea. Deprecating it and encouraging developers to explicitly name and map each servlet is considered by the community as a whole to be an improvement.


There is also the issue of initialization that you haven't addressed.
Calling a servlet directly bypasses an init settings from web.xml.
How do you insure that your servlet-init params are set?
How do you insure that the load-on-startup order is maintained?
Ben Souther
Sheriff

Joined: Dec 11, 2004
Posts: 13410

continued...

Filter-mappings are linked by either the servlet-name and/or the url-pattern -- both of which are set up in web.xml. If someone calles the servlet by it's class name, the filters get bypassed. How do you handle this situation?
William Brogden
Author and all-around good cowpoke
Rancher

Joined: Mar 22, 2000
Posts: 12682
    
    5
There is also the issue of initialization that you haven't addressed.
Calling a servlet directly bypasses an init settings from web.xml.
How do you insure that your servlet-init params are set?
How do you insure that the load-on-startup order is maintained?

EXACTLY!
Over the years in this forum we have seen numerous examples of odd bugs and confusing situations - such as the inability to read configuration settings - all caused by people trying to take shortcuts and avoid web.xml. This is distilled experience talking here - why not listen?
Bill
D Rog
Ranch Hand

Joined: Feb 07, 2004
Posts: 472

You are both right. Your problem that you are not flexible enough, it's sort of academic approach do it in a proven way without thinking. However I want to show people that using a proven approach in many cases create extra overhead without actual needs. Why do I need initializing if my servlet doesn't require the phase? Why should I concern about filters if my servlet really doesn't need them? Why do I need keep unsecure servlet in my distribution? I successfully use servlet invoker for may years and do not see any reason to deal with web.xml.
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60059
    
  65

Well, you've made it clear that you think you know better than the many experienced people who have come to a conclusion other than your own. And that's certainly your right. It's your foot...

But to the people coming here to learn what is best accepted practice, most experienced people have agreed that servlet invocation without web.xml is not a good practice.

Caveat progammer.
Sharad Agarwal
Ranch Hand

Joined: Sep 11, 2002
Posts: 167
D Rog,

Discussion is always healthy, do not feel discouraged to state your view. As for being flexible, no one denies that you can do without web.xml if you so wish. People are just pointing out the problems that it would cause.

It boils down to the theory behind any accepted design pattern. Of course, there are other ways to achieve the goal.

I, for one, have found this thread a nice refresher to concepts, that over time, you take as fact without re-thinking them.
marchrose rose
Greenhorn

Joined: Jul 20, 2005
Posts: 3
hi,

Yes, Web.xml is compulsory.

Basically web.xml is used to map the url to a particular servlet.

without web.xml, how will the container know for which request, which is

the actual servlet to be invoked.The container needs deployed information.

Thanks,
march
ramprasad madathil
Ranch Hand

Joined: Jan 24, 2005
Posts: 489

Iam totally in agreement with Ben and Bear here. Using web.xml is the done thing. It makes your app clean, ease the deployment process, you can directly look up which actions would be assigned to which resource, you could use filters, you could make a servlet (or a jsp for that matter) intercept requests with a certain pattern and tons of other stuff. Its standard j2ee practise and nobody (atleast those I know and interact with) would consider touching a j2ee web application with a barge pole (which's how it should be, IMO) if they are aware that the invoker is turned on or the web.xml is missing . So far, so good.

But this whole security thinggy raises some questions in my head - I was reading with interest the discussion here and it lead me thinking to this - suppose I turn the invoker on in my application and suppose somebody else knows the classpath to my servlet (Its an MVC2 app). Now this servlet, on itself does nothing, (as you all would know) it looks up an xml file for the action handlers etc (which it wouldnt find as the action path is the fully qualified name of the servlet itself) - all the user will get is a NPE (500 error)at some point in the Servlet processing, right ?

Now lets stretch this a bit further - suppose the servlet does some action. In 90% (atleast 80%) of the cases, it would require certain params to be present in the request and certain attributes to be present in the session, right ? Again wouldnt the servlet throw an NPE at some point in its processing when it doesnt find the required parameters ?

Now if its an user who is logged in, he could overcome most of the session attributes issue (he would be a valid logged in user), but how about the request params ? Assuming that he does know the params, what would happen if the servlet still processes only post requests?

Please note, as i said earlier, I wouldnt dare write an app that doesnt have a web.xml or have the invoker servlet turned on. I was just wondering about the security issue and Iam pretty sure that there would be several valid reasons why my argument above is trash and people who know better would undoubtedly point it out or treat it with the contempt it deserves

cheers,
ram.
Ben Souther
Sheriff

Joined: Dec 11, 2004
Posts: 13410

Originally posted by ramprasad madathil:

But this whole security thinggy raises some questions in my head - I was reading with interest the discussion here and it lead me thinking to this - suppose I turn the invoker on in my application and suppose somebody else knows the classpath to my servlet (Its an MVC2 app). Now this servlet, on itself does nothing, (as you all would know) it looks up an xml file for the action handlers etc (which it wouldnt find as the action path is the fully qualified name of the servlet itself) - all the user will get is a NPE (500 error)at some point in the Servlet processing, right ?

Now lets stretch this a bit further - suppose the servlet does some action. In 90% (atleast 80%) of the cases, it would require certain params to be present in the request and certain attributes to be present in the session, right ? Again wouldnt the servlet throw an NPE at some point in its processing when it doesnt find the required parameters ?

Now if its an user who is logged in, he could overcome most of the session attributes issue (he would be a valid logged in user), but how about the request params ? Assuming that he does know the params, what would happen if the servlet still processes only post requests?

Please note, as i said earlier, I wouldnt dare write an app that doesnt have a web.xml or have the invoker servlet turned on. I was just wondering about the security issue and Iam pretty sure that there would be several valid reasons why my argument above is trash and people who know better would undoubtedly point it out or treat it with the contempt it deserves

cheers,
ram.


Here is the scenario that comes to my mind:

I'm a builder of some library, upload, xml-parser, mailer,... It could be anything. Let's call it a jFragulator.
Maybe when I built it, I put in some classes that were only intended for testing and debugging. These classes might include some servlet code for calling this functionality. Maybe I also included a servlet for reading log files on the server or for tweaking config files remotely. I may have never documented these features.

This library gets released and is very sucessful and popular.
You download and install it in your app to get this jFragulator functionality and it works perfectly.

Now, if you've used the invoker, I would have the ability to view or edit any file on your system.

Again, this isn't Tomcat specific. Any container that allows servlets to be called by class name would allow me to call the servlets in that jar file.

Without the invoker, I could only call servlets that you've defined and only under the conditions (init params etc...) that you've defined.
Ben Souther
Sheriff

Joined: Dec 11, 2004
Posts: 13410

Continued.....

In short, it's not YOUR servlets that you have to worry about when you turn on the invoker. Unless you have time to scour every jar file that you've included in your app to insure that there are no servlet classes (most real apps have quite a few) you never really know if you're opening yourself up to this threat.
Sharad Agarwal
Ranch Hand

Joined: Sep 11, 2002
Posts: 167
Originally posted by ramprasad madathil:
<snip> all the user will get is a NPE (500 error)at some point in the Servlet processing, right ?

<sinp> Again wouldnt the servlet throw an NPE at some point in its processing when it doesnt find the required parameters ?


While Ben has addressed the main issue, I would like to take up the more hazy ones here. Aren't you guessing that something or the other will fail server-side? That the user will forget to set something which would result in some server-side error? Sounds suspiciously like security by obscurity. Also, 500s are not nice errors to throw, even to malicious users. A 500 tells a malicious user that (s)he has hit on a situation that the developer had not envisaged and there is an opportunity to hack in.
D Rog
Ranch Hand

Joined: Feb 07, 2004
Posts: 472

It seems the discussion goes on. Ok, let me add a bit fuel. You are mature web application developer who has a bunch of servlets in distributed batch. You have no any ideas what servlets you have. It's fine, it's a result of XP programming, under pressure of customer requirements, you just dropped development some servlets and started new. Hopefully web.xml is helping you to keep track of the latest and coolest servlet. Of course a malicious customer can discover your less successful code attempt when you use servlet invoker. Consider a situation two, you are RUP very organized developer, and you have only two servlets, one you use in production and other one for debugging. Functionality of both are equal besides that debug servlet just gives you a little more control of a system. Of course, production servlet doesn't copy debug, it just does a filtering of debug requests. How much web.xml help you inthis case? Unless your servlet container dynamically picks up web.xml changes, you have to stop your server each time and edit web.xml. You can easily forget to revert it back and ola your customer gets control of system.
Ben Souther
Sheriff

Joined: Dec 11, 2004
Posts: 13410

Originally posted by D Rog:
It seems the discussion goes on. Ok, let me add a bit fuel. You are mature web application developer who has a bunch of servlets in distributed batch. You have no any ideas what servlets you have. It's fine, it's a result of XP programming, under pressure of customer requirements, you just dropped development some servlets and started new. Hopefully web.xml is helping you to keep track of the latest and coolest servlet. Of course a malicious customer can discover your less successful code attempt when you use servlet invoker. Consider a situation two, you are RUP very organized developer, and you have only two servlets, one you use in production and other one for debugging. Functionality of both are equal besides that debug servlet just gives you a little more control of a system. Of course, production servlet doesn't copy debug, it just does a filtering of debug requests. How much web.xml help you inthis case? Unless your servlet container dynamically picks up web.xml changes, you have to stop your server each time and edit web.xml. You can easily forget to revert it back and ola your customer gets control of system.


No.
You're missing my point.
The security hole that is opened by running an app server that can call servlets by class name has nothing to do with MY servlets (some real nasty bugs can happen this way but that's another issue).

The potential problem is with any 3rd party jars that I may have shipped with my app. Even if I only have one servlet of my own, having an invoker means that any servlet in any jar that shipped with my app can be run.

Please go back and read my last few posts for the details.
Ben Souther
Sheriff

Joined: Dec 11, 2004
Posts: 13410

D Rog:
It's fine, it's a result of XP programming, under pressure of customer requirements, you just dropped development some servlets and started new. Hopefully web.xml is helping you to keep track of the latest and coolest servlet. Of course a malicious customer can discover your less successful code attempt when you use servlet invoker.


On another note:
Nobody who has posted to this thread (or contributed to the invoker page) is suggesting that web.xml is somehow a cover up for sloppy coding.
Comments like that are insulting.
You're debating with quite a few, seasoned developers who take great pride in their work. Everyone who has disagreed with your points has remained civil.
Please try to do the same.

Thank you,
[ July 21, 2005: Message edited by: Ben Souther ]
Harishanker Kannan
Greenhorn

Joined: Jul 20, 2005
Posts: 2
amit taneja!

The reason why we use web.xml is that it is mandatory by the currently available servlet containers to use them to deploy servlets. Nevertheless, one can write a servlet container that need not refer to web.xml........to map to a servlet.......write a new container.....problem solved!!!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: is web.xml compulsory
 
Similar Threads
Devaka Cooray Mock Exam Practice 1
JSTL Problem
JSP and Web.xml
Can someone explained to me the "paused" state ?
Comparable Interface