Or IMHO, use a request filter to check for the database and then
redirect the use to a "not available" or "out of order" page. This can
easily happen before any processing starts and the servlet need not be
any the wiser.
--David
Michael Hackett wrote:
Quoting "Caldarale, Charles R" <[EMAIL PROTECTED]>:
From: Michael Hackett [mailto:[EMAIL PROTECTED]
Subject: Re: Selective auto-deploy of web-apps?
Anyway, I appreciate the attempt, but I don't think that solves my
problem of controlling the startup of a webapp or servlet from another
webapp or servlet.
I don't understand why you think this is a good idea. The listener
class provides isolation from the main logic of the webapp. Tying two
webapps together is counter to the philosophy of the Servlet spec, which
emphasizes that webapps are independent, self-contained entities. I
don't see how going against that will do much other than introduce
unnecessary complication.
I agree with you to some extent, but it's a tradeoff. If the servlet itself
has to manage the situation where it is up and running (initialized by the
container) but the database is not there, that complicates its logic fairly
significantly. What I was proposing seemed much simpler, and keeps the main
web app completely ignorant of the different database configurations and
the extra launch stage. Only the little launcher/login web app would know
about that stuff. That seemed to me to be the =less= complicated solution.
I see now the use of the listener, but it still won't help. The best I've
come up with is to wrap the DataSource in a proxy that prevents access
until the database is booted (probably in another servlet or JSP, within
the same webapp).
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
