As I read the context docs (
http://tomcat.apache.org/tomcat-7.0-doc/config/context.html ), the only way to
define a default web application is via a context element in the server.xml
file. Is this true? So, this means that it is IMPOSSIBLE to drop a default
web app WAR into the webapps
What did you put and where?
CATALINA_HOME has everything from the distribution, untouched ( unless my build
has changed something, but it doesn't appear to be so ). I've verified, in
particular, that the server and common libs are there, and that the values in
catalina.properties point to
All directories belong to their distinct place, which is either CATALINA_HOME
or CATALINA_BASE. In the default configuration they are in the same place
only because those variables have the same value.
Are you saying that, for instance, 'conf' can ONLY be in CATALINA_BASE?
So, I should
I have just reorganized my tomcat deployment to use catalina base and home.
I'm getting an obscure, to me at least, error on startup. During the
processing of my webapps I think. I'm on tomcat 5.5.35, and, yes, I'm going to
upgrade after I get the base and home thing working.
Anybody have
On 6/4/12 5:29 PM, chad.da...@emc.com wrote:
I've got a daemon thread that seems to run after the tomcat has
received the shutdown signal. It's a TimerTask and it appears to fire
again after the webapp itself has been shutdown. This then seems to
cause the whole jvm to live on,
I'm having trouble getting my tomcat to shutdown. Obviously, we have some
issues with our code, which I'm in the processing of addressing.
In the meantime, I'd like to shut down tomcat with the -force option. What are
the consequences to doing this? I understand the consequences to my own
I've got a daemon thread that seems to run after the tomcat has received the
shutdown signal. It's a TimerTask and it appears to fire again after the
webapp itself has been shutdown. This then seems to cause the whole jvm to
live on, sometimes for a couple of minutes, sometimes much longer.
I'm following the directions found in the RUNNING.txt file of the distribution,
version 5.5.35.
It says:
you can pass a '-Dcatalina.base=$CATALINA_BASE' argument when
executing the startup command
This doesn't work for me. I think I kind of know why but a couple of points of
clarification
I'm following the directions found in the RUNNING.txt file of the
distribution, version 5.5.35.
First of all, I'm going to assume that you're running a 5.5 version of Tomcat,
since the line you quote is only present in RUNNING.txt from those versions.
At least it's not present in the
I'm trying to convert my app to use the preferred catalina base and home
deployment. I understand that this allows for easier migration between tomcat
versions, etc. As a point of reference, I'm reading about how to do this in
Tomcat: The Definitive Guide. Also, I'm dealing with 5.5.35, if
The specification ( servlet 2.4 ) says that the servlet session may be
implemented via session cookie or, in the case of https, via the ssl mechanism.
My server is only accessible via https. Does tomcat use the ssl mechanism in
this case? I do see the JSESSINID cookie, so as far as I can
As I understand it, sessions are unique to each webapp. However, I see the
same jsessionid cookie being used for requests to two different webapps in the
same container. Is this correct? Tomcat 5.5.34
Read up on the emptySessionPath connector setting in the Tomcat
configuration guide. This will explain it.
Which, for the record, is here:
http://tomcat.apache.org/tomcat-5.5-doc/config/http.html
-
To unsubscribe,
I have Tomcat7 running. My application which was running just fine under
Tomcat5 does not run under Tomcat7. I have created setupclasspath.sh with
all the necessary JARs. My Tomcat starts fine and I see the opening page.
Even my Axis comes up ok but not my application.
I start Tomcat with
There was a change in 6.0.21 (6.0.24 - released 2010-01-21) that now a
Tomcat instance looks both into $CATALINA_BASE\lib and
$CATALINA_HOME\lib for libraries.
Ahh! This makes it clear. So, for 5.5 and early 6.0, if you wanted to add
anything to these lib directories, and you didn't
I'm reading Tomcat: The Definitive Guide to learn how to separate your instance
specific files from your core installation, i.e. CATALINE_HOME; this separation
is for providing a clean upgrade path as well as running multiple instances of
tomcat off of the same installation.
A lot of the stuff
Why would separate instances require their own jar files? Is it not possible
to point two concurrently executing jvm's at the same set of jar files?
It is entirely possible, of course. But you'll have some maintenance work to do
if ever you wish to change the jars for _one_ Tomcat
Yes, but is there a technical, i.e. JVM, reason that two running
instances of tomcat can't concurrently use the same shared libraries?
None at all.
Further, you can have both a $CATALINA_HOME/lib and a $CATALINA_BASE/lib with
BASE always taking priority over HOME. Therefore, use HOME by
This means that for multiple instances to work, each Tomcat instance
has to have its own set of these directories; they cannot be shared by
two differently configured Tomcat JVM instances.
The book is somewhat suspect, unless it explains the reasoning behind such a
statement. JAR files
I'm migrating a 5.5 version of tomcat. Whoever set this up in the first place,
modified catalina.sh to make every stop a force. Here's the modified stop
section of catalina.sh.
# Force a shutdown every time.
# if [ $FORCE -eq 1 ]; then
if [ ! -z $CATALINA_PID ]; then
echo
20 matches
Mail list logo
