I have created a servlet which creats a pool of database connections. At the moment it starts up when the first person logs on. I would like to start this servlet when I start my apache server, is there any documentation on how to do this. Cheers Tony
The Startup Servlet will work, however if you are using Servlet Spec 2.3 or later, I suggest using the LifeCycleEvents. As a Startup Servlet will probably never be used as a servlet once loaded, it is not as 'clean' as it could be. The LifeCycleEvents exists for this purpose and this purpose only. Read more about it here
The load-on-startup element indicates that this servlet should be loaded (instantiated and have its init() called) on the startup of the web application.
Which means NOT when the container starts up, but rather, when the application starts. When is that? For most containers.. a web app is only loaded (started) when it is first requested.
As for LifeCycle events, this is fine for specific servlets. And I know it would be poorly architected if so, but imagine a case where your web-app has up to 10 servlets that could be called as "the first servlet to be called". Each of these 10 would need lifecycle listeners, wouldn't they? After the first one, the other 9 become redundant and a waste of memory and cycles.
Third point is: Is there a problem with using existing pooling mechanisms, which are designed to be loaded by the container on startup. For example.. there is a project in jakarta that I'm successfully using in Tomcat 4.1.12 called DBCP
Originally posted by Mike Curwen: Thought I'd butt in with a few thoughts.
The DTD states (and the spec re-iterates) that: Which means NOT when the container starts up, but rather, when the application starts. When is that? For most containers.. a web app is only loaded (started) when it is first requested.
Actually, I am not sure this is correct. I use IBM WebSphere 3.5, 4.0 and Allaire JRUN 3.0, 4.0. In both cases, the web applications start when the server starts. So if you set the 'load on startup' attribute of a servlet, it will start before the first page is requested. In WebSphere, the administrator can stop a web application, and when the server is rebooted, the web application will still be stopped. But in this state, the servlets won't load even if a request for the first page is made. I think the web application can start before the first page is sent. Even a long time before the first page is sent. But it can also be that the web application will not start when the application server container starts (That's what happens in WebSphere when the administrator has 'stopped' the application).
What you've run across then, are containers that go 'beyond' the spec. But the spec in no way requires the container to load applications (or servlets with 'load-on-startup' attributes) when the container is started. One could argue that 'most' containers these days will provide this type of service, but in a strict sense, this behaviour is not guaranteed, and should not be relied upon.
Regarding listeners... when I actually read the spec for investigating the above... I found this.
So whoops, it appears that on app startup, no matter what servlet is hit, the listener will be registered (and run). My bad.
The last sentence seems to imply the web application is at least *looked at*, if not outright *started* when it is deployed. Combine this sentence with the one previously quoted ("The web container creates an instance of each listener class and registers it for event notifications **prior to the processing of the first request by the application**"). I read this as: "sometime after container startup.. .lazy instantiation". In my view, if you are registering application listeners this implies the application is 'started'. What would you listen to on a quiescent app?
My start on servlets was TC 3x, before the servlet 2.3 spec, so I'm biased towards container start and web-app start being distinct and at different times. Perhaps it makes sense in a post 2.3 world for every web-app to be 'loaded' at container startup. But if this was true, why do people still complain about the need for 'startup class' support in their particular app server?
Maybe Will Brogden can weigh in. Can anyone see anything definitive in the spec that I've missed?
This whether or not the app "starts" at server startup, deployment time, or on first request may indeed be server-implementation dependent, but it seems easy enough to test. Just use the java.util.logging.Logger class to write a message out from the servlet's init() method. Then examine time stamps in the server log and the app log. I love to read specs as much as the next academician (not!), but I usually look for the easy test to get a definitive answer -- especially when there may be implementation dependencies. PCS
Philip Shanks, SCJP - Castro Valley, CA
My boss never outsources or has lay-offs, and He's always hiring. I work for Jesus! Prepare your resume!
I agree.. it would be far simpler just to get an answer by testing it. But in my (limited) experience, I've found that 'simple' tests frequently introduce side effects that either change what is being tested, or don't test what you think they are testing.
In this case you are right, init() seems pretty safe to test. But I've been bitten twice by "oh let's just find out with this simple test". Perhaps that's only related to the fact my experience is "limited", rather than simple tests having a certain quantum mechanical aspect to them. There... just firmly entrenching my academician sheen.