On 14/04/2010 15:31, David kerber wrote: > On 4/14/2010 10:20 AM, Godmar Back wrote: >> On Wed, Apr 14, 2010 at 10:12 AM, Pid<p...@pidster.com> wrote: >> >>>> For instance, if you look at >>>> >>> http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/ServletContextListener.html >>> >>>> it says: >>>> >>>> "To recieve (sic) notification events, the implementation class must be >>>> configured in the deployment descriptor for the web application." >>> >>> Web applications are largely configured by the web.xml file in >>> app/WEB-INF. Servlets, listeners etc are all configured in it. >>> >>> >> Thank you for your confirmation. I thought I was going nuts, after >> having >> waded through various *Facade classes, hoping to find an API method I >> could >> call at runtime. >> >> I have added a ServletContextListener, but it is very much a solution I >> strongly dislike. The reason is that my application is layered on top of >> another application (ZK), and I don't really want to touch web.xml. >> 'web.xml' describes how ZK is configured to run inside Tomcat or another >> J2EE server. My applications runs on top of ZK, and having to go and made >> changes to the underlying deployment descriptor violates basic >> principles of >> layering. > > You don't have to modify the ZK web.xml, AFAIK. Your app can have its > own web.xml, and the contents will both be applied.
Hmm. What does your app/code do in relation to the other app? >> It also creates a maintenance problem (unless an application can have >> multiple .xml files that are combined to form a deployment descriptor). >> Whenever ZK is updated, a new version of web.xml will be installed, and I >> would then have to merge my<listener> declaration into the new file. >> >> Just out of curiosity, what is the rationale for the (apparently >> deliberate) >> lack of an runtime API? Ask Sun. Servlet 3.0 adds multiple deployent descriptor 'fragments' and programmatic listener, servlet and filter loading. Tomcat 7 will support this spec and is nearing a first release. > Someone else will have to confirm, but I believe it's because a > ServletContextListener is just about the first thing loaded by your app. SCLs are loaded first, yes. I'm not privy to the reasoning for the way the original spec works. p > Because of that, runtime APIs are too late to help you; context > listeners can signal (among other things) when a context is first > initialized, and your code hasn't started up at that point. > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
signature.asc
Description: OpenPGP digital signature
