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 folde
> 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
> 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
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 so
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 cod
>
> 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
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.
T
> >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 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 w
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 th
> 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, e-
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
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 tell
> 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
> 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 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 "Killi
> 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
>
> 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
> 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 install
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
20 matches
Mail list logo
