tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: Tomcat 6 - How to make an application available at www.mydomain.com
Date Sun, 29 Jan 2012 13:07:18 GMT
John Renne wrote:
> On Jan 29, 2012, at 1:27 PM, André Warnier wrote:
>> Sorry to appear to pounce on you, but putting a <Context> element in server.xml
is discouraged, see here :
>> http://tomcat.apache.org/tomcat-6.0-doc/config/context.html#Introduction
>>
> No offense taken 
> 
>> I am not myself an expert, so treat this with caution, but to summarise so far :
> 
> Same here, we're all doing the same, trying to be helpful in some way
>> 1) the easiest and recommended way is to deploy the application as ${CATALINA_BASE}/webapps/ROOT.war.
That is the normal place for an application invoked as "/", it will not confuse anyone, and
it will work with or without a front-end.
> 
> This isn't what the original poster asked, he asked for a way without renaming

Yes, but maybe this was for some reason of his, which is not necessarily a good one (we 
don't know, he did not give a reason).  As Chuck was pointing out, this is the recommended

best practice, and it turns out to be the easiest in all respects.  So it is worth 
pointing it out anyway.

> 
>> 2) instead, in some cases (and only since Tomcat 7.x), you can use the "trick" indicated
previously by Pid
> 
> This isn't what the original poster asked, he was talking about Tomcat 6

And as Pid indicated, upgrading was a suggestion. Tomcat 7 is the current version, and it

is "better" than Tomcat 6.  So again, it is worth suggesting.
But of course, as the OP is under Ubuntu, he may want to use the Ubuntu packages (for ease

of administration), and Tomcat 7 may not yet have made it it there.

>> 3) place a Context description in $CATALINA_BASE/conf/[enginename]/[hostname]/ROOT.xml,
with an attribute : docBase="(full path to the application's .war archive)"  (whatever you
decide to name the .war archive). Put the .war archive outside of tomcat's webapps directory
then, to avoid a double deployment.
> 
> This is a nice option, however putting war's outside of the webapps directory might be
very confusing. 

It would not be more confusing than where Ubuntu's Tomcat package is already putting the 
Tomcat files. ;-)
And it may be a nice way to "insulate" his application from future Ubuntu Tomcat upgrades

(which, by the way, also militates against putting a <Context> in server.xml).

> 
>> 4) deploy the application as you wish, and use VirtualHost and/or Rewrite and/or
Proxy rules at the front-end httpd level to achieve what you want.  But this is more complex
to do right as it appears initially. (You may have to be careful about links embedded inside
your pages, for example).
>>
> This is a nice solution too, however if an application for some reason uses applets or
generates it's URL's in a non-standard way, this might not work. I do realize the downsides
of modifying the server.xml and including a context element, but it might be a working approach
and answers the question the original poster has. 
> 
To emphasise a point made above : it often happens that someone comes here with a question

such as "How do I do 'this', using 'that' ?".
It oftens turns out that 'that' is not the best way of doing 'this', but is merely a way 
which the poster heard about from some more or less reputable source.  Sometimes it is 
even so that 'that' is really unnecessarily complex, insecure, unreliable or wrong.
People here then feel obliged to point this out, and recommend what they consider a better

way of achieving 'this'.
I think that's also part of the role of a list such as this one.

To give an egregious example : many people come here asking how they can do this or that 
at the Apache httpd front-end level, before proxying a call to Tomcat.
Then upon further enquiry, it will come up that they are using a directive such as
JkMount /* worker1
Someone here then is bound to question why they are using a httpd front-end at all, and 
recommend that they perhaps get rid of it (and of the original problem at the same time).
No doubt, this also does not match the original OP's question, but may not be a bad thing

to ask, or ?

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


Mime
View raw message