tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Kerber <>
Subject Re: Getting tomcat instance information into webapp
Date Mon, 03 Oct 2005 00:39:51 GMT
Kyle wrote:

> I may be misunderstanding the question, but it seems to me that this 
> shouldn't really be an issue.

It's more likely that I don't know enought about tomcat to ask an 
intelligent question!

> You have multiple instances of tamcat running. This means you will 
> have multiple server.xml's (meaning multiple "Engine"s in which you 
> can set up your multiple realms and direct each different realm to 
> whichever db you want to direct it to. As server.xml is unique (in 
> std. format config.) to a tomcat instance, you have complete control 
> over which port-instance looks at which db.

Then how do I isolate the instances of tomcat (and their respective 
server.xml's?  Do I need multiple installations of tomcat on my disk?

> Again, because you have multiple instances, you will (should) have 
> multiple contexts/context.xml's (dependent upon your tomcat version) 
> in which you can set up your jdbc resources and the various connect 
> criteria for the different db's.

Ok, I didn't know that.  Right now, my jdbc connection criteria is 
hard-coded in the application (I didn't write it; just inherited it).  
It is set up to look for a specific ODBC DSN.  I can easily change the 
app to look for a configurable DSN, but don't know how to get that 
config info into the application.

> I may be mistaken, but if the app. is written correctly _and_  the 
> different resources in the different contexts are all set up with the 
> same names, you could even then get away with just having the one 
> context root/appbase with the one jdbcURL context-param in web.xml. In 
> this way, the same code would hit and serve up the different data 
> dependent upon which port-instance of tomcat it was hitting.

I'll have to do some more careful reading about my context and 
server.xml entries.

> DISCLAIMER: I haven't tried this and I'm no tomcat expert, but I 
> personally, at my lvl of expertise, am unaware of any reason why this 
> wouldn't work.
> Hopefully, someone more knowledgeable will jump in and correct me if 
> I'm way off base.
> K.

Thanks for the response!


> David Kerber wrote:
>> This question is part tomcat and part java; I'm running on a Windows 
>> 2000 server.
>> I have a situation where I am going to need to run multiple instances 
>> of tomcat on a single machine, listening on different ports, but 
>> running the same application and hitting a different instance of an 
>> identical database (same schema, but on a different server).  So what 
>> I will need to do is be able to tell each instance of the application 
>> on its respective instance of tomcat which database to hit.
>> Can I pass a parameter into tomcat from a conf file based on what 
>> port that instance of tomcat is listening on, and then get that 
>> parameter into my application?  If so, how?
>> Another option is for my application to grab the machine name and 
>> port that it is handling, and hit a "common" database to get the 
>> information on what copy of the production to use.  But again, I need 
>> my app to be able to find port information from tomcat, and I don't 
>> know how to do that.
>> It seems like a 3rd option might be to run each instance of tomcat as 
>> a service, logged on with different accounts, and use a user DSN 
>> instead of a system DSN, with the same DSN name, but different 
>> connection info.  Is that possible?
>> If necessary, I could install multiple instances of my app at 
>> different context paths, but I still don't know how to tell them to 
>> pick up the correct database connection info.  I guess I could make a 
>> code change in the first page they hit, the logon.jsp, for each 
>> instance, but I'd rather not have to do that unless there really is 
>> no other way, because that would be easy to screw up when making 
>> changes later on...
>> Any suggestions as to which of the above approaches would be the 
>> best, or another one I haven't thought of?
>> Thanks!
>> DAve
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message