> SRV.14.2.12 ServletContextListener > public interface ServletContextListener extends > java.util.EventListener > All Superinterfaces: java.util.EventListener > Implementations of this interface receive notifications about changes > to the serv- > let context of the web application they are part of. To receive > notification events, > the implementation class must be configured in the deployment > descriptor for the > web application. > Since: v 2.3 > See Also: ServletContextEvent
Correct. My mistake. And my own listener classes are indeed registered in my web.xml(s) since the beginning, forgot this ;-) So my point of not having to configure it in web.xml is moot. > Last but not least, using a Servlet has the additional > advantage it can > be easily configured > if needed without ressorting to an additionnal config file in > the classpath. I don't see what you are trying to say here. What additional config file in the classpath are you talking about? (I'm not trying to offend you, i'm only asking for clarification.) My main problem with the servlet approach is that a servlet has a doGet() method and is therefore supposed to serve web requests, which is not needed in an init class. (Agreed, this is not a major problem, but i like to keep things as small and simple as possible, and a class that *can* serve web requests should also actually be used for this purpose.) Robert > Robert Graf-Waczenski a écrit : > > >Using the load-on-startup mechanism was the way to go with older > >servlet APIs. Nowadays, with servlet API 2.4, having a class > >implement the ServletContextListener interface is better in my eyes. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
