tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kreuser <l...@kreuser.name>
Subject Re: Server giving 404 since upgrade to Tomcat7
Date Wed, 26 Jul 2017 10:48:50 GMT
Hi all,

> Am 25.07.2017 um 21:00 schrieb Christopher Schultz <chris@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message