Hi all, > Am 25.07.2017 um 21:00 schrieb Christopher Schultz > <ch...@christopherschultz.net>: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Peter, > >>> On 7/25/17 11:14 AM, Peter Flynn wrote: >>> On 24/07/17 11:57, Mark Thomas wrote: >>> On 24/07/17 11:12, Flynn, Peter wrote: >> >> I must apologise first for unintentionally misleading you: the >> upgrade was from Tomcat 7.0.54-2 to 7.0.69-11, not from 6 to 7. I >> inherited this along with what was clearly bad information. > > Thanks for the clarification. > >>> Running from a package tends to limit the members of this that >>> are available to help to those that understand the packaging on >>> the platform in question. >> >> I'm afraid so. But I hope this is not about packaging, but about >> modifying the configuration. > > Probably so, especially because it was a minor version upgrade. > >>> Tomcat needs allowLinking to be correctly set if that path to a >>> web application (or the web application itself) uses symlinks. I >>> don't think that has changed between 6.0.x and 7.0.x. >> >> There seem to be two, but I have never used or touched examples. >> >> # find /var/lib/tomcat/webapps -type l -ls 536929726 0 >> lrwxrwxrwx 1 tomcat tomcat 40 Aug 11 2016 >> /var/lib/tomcat/webapps/examples/WEB-INF/lib/jstl.jar -> >> /usr/share/java/jakarta-taglibs-core.jar 536929727 0 lrwxrwxrwx >> 1 tomcat tomcat 44 Aug 11 2016 >> /var/lib/tomcat/webapps/examples/WEB-INF/lib/standard.jar -> >> /usr/share/java/jakarta-taglibs-standard.jar > > That looks like the package manager's doing, and is probably okay. If > it's not okay, then complain to the package manager that they have > broken their own package :) (And the package manager happens to be > reading this thread, so you should be good, here.) > >>>> # In new-style instances, if CATALINA_BASE isn't specified, it >>>> will # be constructed by joining TOMCATS_BASE and NAME. >>> >>> Those last two variables are package specific. >> >> What is a 'package' in this context? A Tomcat application? > > Mark was referring to the Tomcat "package" as packaged by the package > manager (e.g. yum). > > In this case, Tomcat itself doesn't do anything with environment > variables called TOMCAT_HOME or NAME. Tomcat only cares about > CATALINA_BASE (where instance-specific configuration and webapps are > kept) and CATALINA_HOME (which is where the base Tomcat files can be > found). > >>> The Tomcat logs should at least tell you what - if anything - >>> Tomcat is deploying. >> >> If I can make sense of them... >> >>> There is no one 'right' way to install Tomcat. Pick the one that >>> works best for you (and be prepared to try an alternative if you >>> hit problems). >> >> :-) I'd rather compile from scratch, but that's just the way I was >> brought up. > > Building Tomcat from source is a waste of your time: the official > packages (both from ASF and from Red Hat) have all been built for you > and are environment agnostic. I would never recommend that anyone > build Tomcat themselves unless they are trying to hack on it for their > own needs. > > Let's try this: > > 1. Stop Tomcat and remove all log files (or push them somewhere else > out of the way) > 2. Launch Tomcat (and please tell us how you do that) > 3. Make a single request that returns 404 but should not > 4. Stop Tomcat > 5. Post the contents of logs/catalina.out to the list > > Please remove any secrets that might be in that file (the only secrets > that might be in there would be coming from your application). > > I saw your log file snippets, but there might be something you missed > (since the log was incomplete). > > I've used Apache Cocoon with Tomcat 4.x and later and haven't had any > problems like you describe. I suspect this is a simple configuration > problem that we can help you get corrected. > > - -chris
All started contexts are from a default install. ROOT may be also the default homepage, so that would explain the 404s. Maybe the new installation is using a different than expected webapps dir?! Or has overwritten your ROOT? I would try to remove all webapps (besides manager), restart tomcat and see what's in the logs. (That's best practise anyways to remove samples and the default ROOT). BTW: from the logs I see a misconfigured server/context.xml as tomcat warns that xml attributes are used that have no corresponding setters!? Best regards Peter --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org