The previous Java was a different (older) build of openjdk and yes was working properly for months.
I am not entirely sure when you say full path to WAR what you are looking for so I am going to list all the information. Before deploying my last test project the war was in two places (I tried both). On my local system and uploaded through the manager and on the target machine in my home directory. So I deployed using the upload and I also tried to deploy by specifying the path to the WAR locally. Both of these deployments worked. At that point I have the following /usr/share/tomcat5 Contains the below work -> /var/cache/tomcat5/work webapps -> /var/lib/tomcat5/webapps temp -> /var/cache/tomcat5/work shared -> /var/lib/tomcat5/shared server -> /var/lib/tomcat5/server logs -> /var/log/tomcat5 conf -> /etc/tomcat5 common -> /var/lib/tomcat5/webapps bin In webapps for the war in question I have the following A war file called maxtest.war and a directory called maxtest. So the path would be /var/lib/tomcat5/webapps/maxtest.war or /usr/share/tomcat5/webapps/maxtest.war Both of these have rwxrwxr-x for permissions and the owner and group is tomcat. And again this directory layout was unchanged since it worked and it was working since at least sometime last fall (I wasn't here before then so I can't speak to that) If I try and undeploy I get the error message previously described, in the log I can see the stack trace and in the webapps directory I will see that the WAR file has been deleted but the directory and all its contents are intact. In this case after the undeploy the maxtest directory contains META-INF/context.xml META-INF/MANIFEST.MF WEB-INF/web.xml WEB-INF/classes (empty directory) WEB-INF/lib (empty directory) Index.jsp In the case of any of the existing projects that actually have classes and libs they will still all be in these directories rather than empty. If this is not the information that you are looking for can you please try and restate and I will get it for you. -----Original Message----- From: Christopher Schultz [mailto:ch...@christopherschultz.net] Sent: Wednesday, September 01, 2010 10:29 AM To: Tomcat Users List Subject: Re: undeploy failure - stack overflow tomcat 5 on RHEL 5 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Maximilian, On 9/1/2010 10:08 AM, Maximilian Stocker wrote: > The version that was being used (using java -version) was an OpenJDK > > java version "1.6.0_0" > OpenJDK Runtime Environment (IcedTea6 1.6) (rhel-1.13.b16.el5-x86_64) > OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode) And that was working properly? Many folks have encountered problems using OpenJDK with Tomcat and their webapps. > However as a test yesterday the most recent Sun/Oracle version was installed > > java version "1.6.0_21" > Java(TM) SE Runtime Environment (build 1.6.0_21-b06) > Java HotSpot(TM) 64-Bit Server VM (build 17.0-b16, mixed mode) > > But using this version has not proved to fix the problem either. Ok. > I also created a very simple test, a WAR with one index.jsp and its > own context configured with both lock jars and lock resources off. > Deployed fine. Still failed on undeploy with the same relatively > nondescript error message and lengthy stack trace. > > If anyone has any more suggestions of things to look at I'd be glad > to hear them. As a next step I am going to attempt to run a > standalone program that will try and delete a copy of a tomcat > unpacked war using the ExpandWar class source from 5 and see if I can > recreate the problem outside tomcat. I do have an idea: tell us what the full path to your WAR file is. You said it doesn't matter but it might help to know what it actually was. Also, giving us more details about the symlink layout might help. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkx+YxIACgkQ9CaO5/Lv0PC7cgCdF0IAorUrc31g09D2coK2rlzT i7wAni+RjLEIPnqFmJVsOR6vTk3NDzC3 =ZSjX -----END PGP SIGNATURE----- --------------------------------------------------------------------- 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
