Re: Selective auto-deploy of web-apps?

2005-12-09 Thread Michael Hackett
 From: Caldarale, Charles R [EMAIL PROTECTED]

  From: Michael Hackett [mailto:[EMAIL PROTECTED] 
  
  We want to prompt the user for the database password and 
  boot the database before launching the real application.
 
 What user?

The user of the web app. In this case, there will only be one user, the
user of the machine where the server is running. (The same app will also
be used in a typical remote client-server environment, but in that case,
we'll be hosting the database and encryption won't be necessary.)

  I guess we will have to look at controlling the database 
  startup and shutdown within the main app
 
 Is there some reason an ServletContextListener won't work?  (See section
 10.2.2 of the Servlet spec - it seems to describe a situation very close
 to yours.)

That appears to allow the app to receive notification of start up and
shut down, but not to control it, correct? Plus, I can't quite see how
this is much different than the init/destroy methods of the servlet
(except maybe in the case of an app with several servlets, where it
sounds like the listener events would be sent after all servlets are
initialized; but I could be wrong there).

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. Maybe having the webapps in two different Hosts, with
only one set to deploy on startup? There's probably some other problem
with that set up, though, that I haven't thought of.

-- Michael


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Selective auto-deploy of web-apps?

2005-12-09 Thread Michael Hackett
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]



Re: Selective auto-deploy of web-apps?

2005-12-09 Thread David Smith
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]



RE: Selective auto-deploy of web-apps?

2005-12-08 Thread Caldarale, Charles R
 From: Michael Hackett [mailto:[EMAIL PROTECTED] 
 Subject: Selective auto-deploy of web-apps?
 
 We want to prompt the user for the database password and 
 boot the database before launching the real application.

What user?

 I guess we will have to look at controlling the database 
 startup and shutdown within the main app

Is there some reason an ServletContextListener won't work?  (See section
10.2.2 of the Servlet spec - it seems to describe a situation very close
to yours.)

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Selective auto-deploy of web-apps?

2005-12-08 Thread Martin Gainty

Bonjour Michael
Have you looked into using Spring Framework lazy-init=true property e.g
objects default-lazy-init=true 
?

Martin-
- Original Message - 
From: Michael Hackett [EMAIL PROTECTED]

To: users@tomcat.apache.org
Sent: Thursday, December 08, 2005 5:08 PM
Subject: Selective auto-deploy of web-apps?



I'm trying to come up with a solution for the following situation: We
have a webapp that we need to deploy with an encrypted Derby database.
We want to prompt the user for the database password and boot the
database before launching the real application. I was thinking of having
either:

(1) a separate small web app that gets auto-deployed and starts the main
web app after unlocking the database, and stops it before shutting down
the database; or

(2) a second servlet within the web app to do the same thing (the main
code is contained inside a single Struts-based servlet)

However, in the first case, I can't see a way to have the one web app
auto-deploy but not the other (seems to be host-specific, not
context-specific); and in the second case, even without a
load-on-startup element in the web.xml file for the main servlet,
Tomcat still seems to initialize it at startup. (And even if it did, the
docs say it would be auto-loaded as soon as its context URL was hit. No
way to protect against that.) Am I missing something?

I was hoping to do something outside of the main app, to keep it
isolated from the database deployment details (there are at least two
different configurations, only one of which needs the encryption), but
if neither option is possible, I guess we will have to look at
controlling the database startup and shutdown within the main app (which
looks like it could be messy, what with all the stuff Hibernate, Spring,
and Tomcat are doing behind the scenes for us). If anyone here has
attempted something like this, I'd love to hear from you.

Cheers,
-- Michael


-
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]