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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
