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.
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?
Someone else will have to confirm, but I believe it's because a
ServletContextListener is just about the first thing loaded by your app.
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.
D
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
