tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: Multiple applications
Date Wed, 29 Jul 2009 11:49:54 GMT
Peter Flynn wrote:
> Hassan Schroeder wrote:
>> On Tue, Jun 23, 2009 at 7:37 AM, Peter Flynn <pflynn@ucc.ie> wrote:
>>> I've been using Tomcat5 with Apache2 under RH5 to run Cocoon, but I
>>> now need to add Lucene and eXist. Is it possible to run multiple
>>> applications like this on the same machine using the same Tomcat
>>> server?
>>
Hi.
I believe that I may be about at the same level as yourself for such 
things - which is far below the level of the gurus you have been talking 
to so far - and therefore that my explanations that follow, whilst being 
maybe less accurate, may be more accessible.

And if you can read and understansd the previous paragraph, then you 
should not have trouble with the Tomcat on-line documnentation either.
So I would suggest to start by reading this page, which outlines the 
basic principles of the deployment of web applications under Tomcat :

http://tomcat.apache.org/tomcat-5.5-doc/deployer-howto.html

In order to not get an overdose, skip for now anything in that page that 
talks about the Tomcat Manager or the TCD.  We won't need them, since 
we're going to do thimgs by hand, in the good old traditional way.
So, read only up to and including the section "Deployment on Tomcat 
startup" for now.


First, two caveats :
1) One hurdle you are facing, is that these explanations relate to the 
way in which Tomcat is installed /if you were using the standard Tomcat 
as downloaded from the Tomcat website/.  This is not your situation, 
since you are using a "RHEL repackaged Tomcat".  I have to tell you that 
this is viewed with some distaste by some of the gurus on this forum, 
the - justified - reason of which is that these packages install things 
in different places than the standard Tomcat, and this makes it more 
difficult to help you.
2) Another hurdle is that you also already have <Context> elements in 
your server.xml, which also frowned upon nowadays.  It is frowned upon 
also for good reasons, as it makes moving things around dynamically more 
difficult : you have to restart the server each time you make a change 
to server.xml, which is not ideal.
About this second hurdle, the documentation page in question indicates, 
in the section "A word on Contexts", the better places for such things.

A standard Tomcat installation lays out the stuff more or less as follows :

Top install directory (also know as CATALINA_HOME)
    - bin
    - conf
    - logs
    - webapps
    .. and others less important here

Also, when you are running a single instance of Tomcat on a host, the 
symbol CATALINA_BASE is equivalent to CATALINA_HOME above.

In a pre-packaged installation, some of those subdirectories may be 
located elsewhere, and a variety of links installed, to tie it all 
together.  That's what sometimes makes it challenging.

The crucial sub-directory here is "webapps".
That is where a standard Tomcat looks for web applications.
It looks there, because in your <Host> element in your server.xml, there 
is an attribute named "appBase", which usually says "webapps". 
"webapps", unless it is an absolute path, is taken relative to 
CATALINA_BASE.

Thus, when anyone accesses your site using the URL
http://hostname/xyz
Tomcat is going to look under the "appBase" directory, for a 
sub-directory named "xyz", and try to find a web application there to 
serve the call.

A special case is the sub-directory called ROOT.
That is where Tomcat will look for the "default web application", in 
other words the one people are looking for when they enter the URL
http://hostname/

This default application could have just been located directly under the 
"webapps" sub-directory, but that would have been confusing, since then 
Tomcat would not know if ".../webapps/xyz" is a separate application 
called "xyz", or if it is a sub-directory of the default application.

Because one <Host> element has only one "appBase" attribute, and because 
this appBase attribute names one directory (in the standard case, 
CATALINA_BASE/webapps), and because under this webapps there can only be 
one ROOT sub-directory, it follows that one Tomcat Host can only have 
one "default application".
So you must choose which one that will be, and that will be the one 
users will access when they use the URL "http://yourhost/".
All other applucations - in the same Host - will have to be accessed by 
a URL such as "http://hostname/appname".

If you configure multiple <Host>'s, then each can have its own 
"appBase", under which each can have its own ROOT, and thus its own 
default application.

But let's get back to an application named "myapp", which would not be 
the default application.
Normally thus, Tomcat expects to find all the stuff related to this 
application, in the following hierarchy :

CATALINA_BASE/webapps/myapp
--- / (I mean, directly under "myapp) (files : html & jsp pages)
--- (subdir) WEB-INF
        (file : web.xml)
       --- (subdir) classes  (*.class)
       --- (subdir) lib (*.jar)
--- (subdir, optional) META-INF
         (file, optional) context.xml

The WEB-INF directory is special, in the sense that Tomcat will never 
"serve" its content to a client, even if the client were to request 
explicitly "http://hostname/myapp/WEB-INF/something".
That is thus the right place for your application's descriptor file 
(web.xml), and for your classes, libraries etc..

The META-INF directory and its content, are only necessary if you need 
to specify non-default parameters.

In general thus, you can have as many distinct applications as you want 
running under Tomcat, and each would have its own sub-directory under 
CATALINA_BASE/webapps (including one for the default ROOT app).
And Tomcat will, automatically, derive the name of the application (and 
the URL), from the name of each of these subdirectories.
(Conversely, any named subdirectory located under CATALINA_BASE/webapps/ 
is taken by Tomcat as being a separate application.  Whether these 
applications are or not delivered together with Tomcat in some packaged 
version makes no difference.  They are mere applications nevertheless, 
just at the same level as one you would add yourself.)

*Except...*
if you change the whole ballgame by putting <Context> elements in your 
server.xml.
These Context elements in effect tell Tomcat, that for the application 
named "myapp", it should look somewhere else than in 
CATALINA_BASE/webapps/myapp for all that stuff.

So now the next documentation page you need to read is :
http://tomcat.apache.org/tomcat-5.5-doc/config/context.html

and in particular, what it has to say about the "docBase" and "path" 
attributes, and the remarks therein.


Now is also the right time to read an additional section in the first 
documentation page, the one entitled "Deploying on a running Tomcat server".
This is the gist : instead of structuring the web applications according 
to the layout above, an alternative is to deploy them using a WAR file.
A WAR file is nothing more than a kind of zip file, in which you have 
put a whole application, such as you would have it under 
CATALINA_BASE/webapps/myapp.
If you take all these files and directories, and create with them a file 
called "myotherapp.war", and then just place that file under 
CATALINA_BASE/webapps/, then when Tomcat starts it will automatically 
unpack that file, and consider it as if you had a new application named 
"myotherapp" (the name of the WAR file, minus the .war extension.
That's (almost) all there is to it, just another way of installing an 
application.
The neat part about it, is that you can do this dynamically, while 
Tomcat is running : just drop the WAR file there and, presto, you have a 
new webapp (and a new URL to call it).

Of course, that is not possible if you use <Context> elements in your 
server.xml, because you have to restart Tomcat before it re-reads that file.


Hope all that helps, and was not too low-level.




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message