default context
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 folder, correct?
RE: puzzling stacktrace
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 them accurately. Please follow instructions in RUNNING.txt closely. I believe that I have. But it's not exactly clear to me on what I need in CATALINA_BASE. I have, at this point, only populated it with things that I have overridden. For instance, CATALINA_BASE/conf only has server.xml, because that's the only file I customized. Are copies of all the other ones supposed to be there too? Similarly, I don't even have a 'server', 'common', or 'shared' folder in my CATALINA_BASE because I'm utilizing those classloaders. Perhaps this is wrong. Personally, I can't tell from the RUNNING.txt doc. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: puzzling stacktrace
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 copy the entire conf folder from the distribution into each of my CATALINA_BASE's and remove it entirely from the CATALINA_HOME? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
puzzling stacktrace
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 some insight into this: 2012-06-07 15:28:47,616 ERROR [main]-digester.Digester: Begin event threw exception java.lang.ClassNotFoundException: org.apache.catalina.deploy.FilterDef at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1438) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1284) at org.apache.tomcat.util.digester.ObjectCreateRule.begin(ObjectCreateRule.java:205) at org.apache.tomcat.util.digester.Rule.begin(Rule.java:153) at org.apache.tomcat.util.digester.Digester.startElement(Digester.java:1276) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(Unknown Source) at com.sun.org.apache.xerces.internal.impl.dtd.XMLDTDValidator.startElement(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(Unknown Source) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(Unknown Source) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(Unknown Source) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(Unknown Source) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.tomcat.util.digester.Digester.parse(Digester.java:1562) at org.apache.catalina.startup.ContextConfig.applicationWebConfig(ContextConfig.java:348) at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:1053) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:261) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4184) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014) at org.apache.catalina.core.StandardHost.start(StandardHost.java:736) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1014) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:448) at org.apache.catalina.core.StandardServer.start(StandardServer.java:700) at org.apache.catalina.startup.Catalina.start(Catalina.java:552) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295)
RE: daemon thread causing tomcat process to live on
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, sometimes for a couple of minutes, sometimes much longer. The timertask blows up with classnotfounds because the webapp classloader is gone. Shouldn't it be killed when the webapp is killed? Tomcat won't stop threads created by your webapp: that's up to you. Even a daemon thread? I thought a daemon thread wouldn't stop a jvm from exiting . . .
stopping with force option
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 code are my own concern, but what are the tomcat specific consequences?
daemon thread causing tomcat process to live on
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. The timertask blows up with classnotfounds because the webapp classloader is gone. Shouldn't it be killed when the webapp is killed? How do I troubleshoot this?
using CATALINA_BASE
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 would be useful. 1) This parameters is a pass through to the JVM correct? In other words, it means nothing in the startup.sh and catalina.sh scripts. 2) If the answer to number 1 is true, it seems that catalina.sh's execution of my $CATALINA_BASE/bin/setenv.sh will never get executed . . . Any ideas? Thanks! Chad
RE: using CATALINA_BASE
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 latest 6.0 or 7.0 version. I did specify my tomcat version actually ;) AND here's the full paragraph: pIn many circumstances, it is desirable to have a single copy of a Tomcat binary distribution shared among multiple users on the same server. To make this possible, you can pass a -Dcatalina.base=$CATALINA_BASE argument when executing the startup command (see (2)). In this -Dcatalina.base=$CATALINA_BASE argument, replace $CATALINA_BASE with the directory that contains the files for your 'personal' Tomcat inAny stance./p So, yes, I did adulter the argument because it has double quotes in the original. However, the misleading bit is where it makes it sound as if the catalina base reference is just a placeholder, i.e. replace $CATALINA_BASE with . . . When I launch multiple Tomcats, I use a shell script similar to the following: #!/bin/bash CATALINA_HOME=/some/path/to/my/home/tomcat # the below is all on one line - sorry for the line wrap ( export CATALINA_BASE=/some/path/to/first/catalina_base; $CATALINA_HOME/bin/startup.sh ) That's about what I came up with. It just seemed to be fighting against the tide a little bit. But, this all makes it seem like you would never actually use the -D method because the startup scripts simply read the env variable and pass the value in as a java sys property anway. Makes me wonder what the paragraph means by startup command. The reference see(2) doesn't resolve in the RUNNING.txt text . . . Thanks for your help. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
CATALINA_BASE and CATALINA_HOME deployment
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 that matters. I have one question. I understand that the separation of the core tomcat stuff from my instance stuff is good. But the book says to copy the entire conf folder over to my instance folder ( CATALINA_BASE/myapp/conf ). Isn't this copying a bunch of tomcat version specific stuff that I'll have to sift through when it's time to migrate? Will I be able to just upgrade CATALINA_HOME and not upgrade all of that copied conf stuff as well? Thanks, Chad
servlet session method with https
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, it uses the cookie method.
jsessionid cookie across webapps
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
RE: jsessionid cookie across webapps
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-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Error starting Tomcat
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 ./startup.sh and I do not use Eclipse. The message that I get is *** Oct 20, 2011 3:04:03 PM org.apache.catalina.core.ContainerBase addChildInternal SEVERE: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: Failed to start component Sounds like there may have been some configuration changes to the various xml files that pertain to your app, between versions 5 and 7 I mean. Did you change any of the server.xml, and friends, when migrating? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: TOMCAT_BASE and TOMCAT_HOME
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 want that addition to affect all of the tomcat instances running off of the same CATALINA_HOME, then you were obliged to copy the entire set of lib directories to your CATALINA_HOME. Then, the instance would use, and only use, the CATALINA_HOME lib directories. This all or nothing approach requires wholesale copying. In fact, then, I was misreading the section of the book. And after the later 6.0.x revisions, you can override at a finer granularity and, thus, avoid having to copy the entire things over. Thanks so much! - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
TOMCAT_BASE and TOMCAT_HOME
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 they recommend pulling out into instance specific directories make sense, such as conf and webapps -- those folders contain the obvious application specific data. However, the also recommend pulling out all of the folders that contain the jars that hold runtime classes. To quote directly from their book: Also, some jar files and class files may need to be loaded from the shared, server, and common directory trees. 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. 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? Note: this is about tomcat 5.5 and 6.0
RE: TOMCAT_BASE and TOMCAT_HOME
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 installation among many. Yes, but is there a technical, i.e. JVM, reason that two running instances of tomcat can't concurrently use the same shared libraries?
RE: TOMCAT_BASE and TOMCAT_HOME
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 default and override on a per instance basis if you need to. Is the override on a wholesale basis, or on a per jar basis?
RE: TOMCAT_BASE and TOMCAT_HOME
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 can certainly be shared across JVM instances (that's how the JRE works), but doing so will create versioning and updating issues. Maybe I'm misreading, but it seems pretty clear . THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
modified legacy catalina.sh forces kill on every stop
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 Killing: `cat $CATALINA_PID` kill -9 `cat $CATALINA_PID` rm $CATALINA_PID else echo Kill failed: \$CATALINA_PID not set fi # fi I'm hoping to remove this completely during the modification. But I'd like to make a best effort attempt to understand why someone would have done this. Does anyone know of any common reasons, or, shall we say, valid reasons for making this modification?
