aspose file tools*
The moose likes Servlets and the fly likes starting a servlet when the server starts Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Servlets
Bookmark "starting a servlet when the server starts" Watch "starting a servlet when the server starts" New topic
Author

starting a servlet when the server starts

Tony Evans
Ranch Hand

Joined: Jun 29, 2002
Posts: 579
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
Jesse Beaumont
Ranch Hand

Joined: May 30, 2002
Posts: 43
In the web.xml deployment descriptor add a <load-on-startup> tag to the servlet definition. This will cause the servlet to be loaded when the container is started.


---<br />Time flies like an arrow,<br />Fruit flies like a banana
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61433
    
  67

This is of course handled by your web application container (tomcat? resin? whatever?). Has nothing to do with apache.
hth,
bear


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Ken Robinson
Ranch Hand

Joined: Jul 25, 2002
Posts: 52
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
Mike Curwen
Ranch Hand

Joined: Feb 20, 2001
Posts: 3695

Thought I'd butt in with a few thoughts.

Regarding load-on-startup:

The DTD states (and the spec re-iterates) that:
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
Michael Zalewski
Ranch Hand

Joined: Apr 23, 2002
Posts: 168
Originally posted by Mike Curwen:
Thought I'd butt in with a few thoughts.

Regarding load-on-startup:

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).
Mike Curwen
Ranch Hand

Joined: Feb 20, 2001
Posts: 3695

Michael, from the spec....



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.
Mike Curwen
Ranch Hand

Joined: Feb 20, 2001
Posts: 3695

Hmm... I'm a bit confused now... (my **'s)

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?
Philip Shanks
Ranch Hand

Joined: Oct 15, 2002
Posts: 189
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!
Mike Curwen
Ranch Hand

Joined: Feb 20, 2001
Posts: 3695

Was i just called an academician? hehe.

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.
Garrett Smith
Ranch Hand

Joined: Jun 27, 2002
Posts: 401
Ken was right.
You should implement
Interface
ServletContextListener
void contextInitialized(ServletContextEvent sce){
// initialize db
}


comp.lang.javascript FAQ: http://jibbering.com/faq/
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: starting a servlet when the server starts