Hola, >- ServletContextListener cannot flag that an error has occurred (other >than some type of logging)
You could throw a runtime exception, making the context unavailable in tomcat. >- Servlets have their own init parameters specified in the web.xml file. >If you use a listener, you have to share the global ones. If your filter >and something else happen to have the same name for the configuration >parameter, you have no resource but to modify the source. (The solution >to this, of course, is to use names that are highly likely to be unique, >like pre-pending your package name onto the parameter) Filters have their own parameters, like servlets. But if you mean that you could have context parameters with the same names but different value: yeah, you could, and that'd be confusing at best. >> - The footprint of a servlet in memory is bigger > >True, but it's memory footprint isn't that big of a deal. Could be a huge deal, depending on the servlet instance variables. The same is true for a listener. >> - Another servlet adds to request mapping overhead, reducing performance > >Most often, init servlets aren't mapped to anything, so there's no >performance hit. The performance hit would be marginal anyhow, given the >matching alrogithm. You'd incur maybe one String.equals comparison per >request. Comparing strings that don't have the same length is pretty quick. For some containers, it doesn't matter whether the servlet is mapped or not, or servlets are mapped automatically. Even if the performance hit is tiny, it's still there, and there for every request. At many concurrent requests, it could become an issue. >However, you must be running a servlet container which supports the 2.3 >API in order to use ServletContextListener (unless you implement >something like it yourself for older containers). True. Whether one considers that a drawback is a personal consideration, along the lines of those poor souls who still have to run JDK 1.1 ;) >I've only seen one brain-dead servlet container ever create more than >one instance of a servlet: that was JRun 2.x.something. That wasn't it's >worst problem :) Why would it be brain-dead to create more than one instance of a servlet? >Oh, I just meant more heterogeneity. Most people have servlets. One more >servlet isn't a big deal. Adding something completely different >(although much more suited for the job) creates (a small amount of) >confusion within the project. Hmm... I guess that depends on the project, the people, other variables. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
