tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Johnny Kewl" <>
Subject Re: Tomcat Application Read/Write properties (mk2)
Date Sun, 15 Jul 2007 07:45:28 GMT

----- Original Message ----- 
From: "Jacob Rhoden" <>
To: "Tomcat Users List" <>
Sent: Sunday, July 15, 2007 7:38 AM
Subject: Tomcat Application Read/Write properties (mk2)

>I am going to re-word the question from the last thread to ask not how to 
>do what I think I should do, but what I should do (:
> Where I work, ease of configuration and management is an important part of 
> the software selection process. I have seen many tomcat applications 
> provide an install.jsp or setup.jsp that allows you to configure various 
> information including the name of the database. So here is my question. 
> What is the correct/standard/java way of doing this? The database 
> username/password are usually stored in web.xml, should the configuration 
> page write the the web.xml file?  I know what technically can be done, but 
> what should be done?

Jacob... Changing passwords, and choosing the dB, and thus in effect setting 
up the dB pool, will never be an easy thing, if possible at all, to do from 
a JNDI resource, thru a JSP page.
Fortunately Tomcat is a lite weight container and thus easy to understand 
and it lends itself readily to POJO (plain old java object) solutions.

.... I'm going to "try" explain one way of doing it.
There are other very popular db Pools... the one that I use is called 
DbConnectionBroker  (google for it).
Of course if you like, you could use DBCP... which is the same one TC uses 
in JNDI.

What I think these guys are doing is setting up the dB pool themselves in 
the INIT section of the servlet.
This is called once at server start up, so it allows one to setup global 
initialized classes, like db Pools.

Now say you wanted to provide the facility to use a different dB from a JSP 
page.... the form will submit to the servlet, the servlet will then make a 
new dB pool, and thereafter new requests will use that one.
Conceptually you start to see the problems, because the old connection pool 
has to be allowed to finish up any work it is doing, before it can be 
Naturally one doenst have to use a dB pool, and could just use a single 
connection for a single session, if thats what the program required.... but 
if its an admin facility, and you setting up for all future requests.... it 
will be something like the above.

A side issue is that for something like this to work, they using the MVC 
model, ie the requests are all coming in thru the servlet and being 
dispatched to JSP pages, thus the correct dB pool can be passed across in a 
session object.

If you new to tomcat, all this will sound frightening, but its actaully very 
easy once you get the concept.
If you only want to work with JSP pages, then you cant channel through a 
servlet, and cant pick up the required dB pool, ie you pretty much have to 
use JNDI, and because that is setup when your webapp starts, you cant really 
change it.
If it doesnt have to be thru a JSP page, and TC can be stopped, and you 
really just looking for a convenient admin facility, then have a look at JMX 
in TC.

Answering questions like this is always difficult, because there are dozens 
of frameworks that work on TC, so someone else may say, hey use Spring....
I like Tomcat because it lends itself to POJO development.... I'm a POJO 
junky ;)
So if you want to know how to do it in POJO, thats me.... for example I take 
the above concept and add persistence to it as well, if you a POJO man.... 
then have a look at this  (Pojo Persist)... it 
does all of the above, and easy persistence, if only to get a feel for using 
your own dB pool.

Maybe a framework person can tell us both whether there is a framework that 
lets you change the dB pool at runtime.... I cant think of one. 

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message