-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 André,
On 5/12/2009 7:39 AM, André Warnier wrote: > I wonder if it is not time to "make peace" on this issue and maybe > trying to find a reasonable middle ground. > > An installation of the complete official Tomcat under > /usr/local/tomcatx.y, including logfiles, webapps, etc.. is undoubtedly > the simplest case for someone here trying to offer support to some > bewildered user. > At the same time, it is not the configuration that most users have when > they come here for help. Yes, but if everyone has a different configuration, it's very difficult to answer the question "my app has been running forever without a problem, and now it 'doesnt work'". We of course ask for log messages, and the OP inevitably says "where are my log files?". If the log files are somewhere other than in the default location, we will simply have no idea where to look. I suppose we could say "just run 'find / -name catalina.out'" but that's only good for UNIX and only if stdout has been redirected to catalina.out (and not stdout.txt or catalina.log or catalina_yyyy-MM-dd.log or whatever). Wanna find your log files on Windows? That depends... are you running it as a service? Batch? EXE-from-command-line? How was it configured... it's just a giant mess. > Also, application packagers for various systems have undoubtedly a > number of reasons for doing what they do, and it is also [doubtless] > that the availability of software packaging and distribution mechanisms > greatly facilitate the life of system administrators and a whole bunch > of users. I completely agree with this. I actually like the fact that package managers move the log files to /var/log and the config files to /etc (except that Tomcat shouldn't run as root, so things get a little hairy when non-root users can write to /etc). If lots of people all use, say, Debian, then we can at least say "oh, you're on Debian, so your log files are on _____". Of course, the Debian (and other) folks clearly say "if you are having problems with our packages, contact us" but they come here anyway. The only thing I take issue with is when people come on to the list and say (to paraphrase) "my app works and it must be your software that sucks", when the reality is that their setup is not sane. > For instance, the startup of Tomcat already uses the JAVA_HOME variable > to locate the appropriate jvm, the CATALINA_HOME to find the code, > CATALINA_BASE to find the instance-specific stuff etc.. ... unless they are running it as a service under Windows. Or unless the package maintainer has used their own script in /etc/init.d to start up Tomcat (which is pretty much par for the course). The truth is that bin/startup.sh is called somewhat rarely, apparently. That means that we can't rely on the values for JAVA_HOME and CATALINA_HOME (which is usually auto-detected anyway... it's rare for anyone to set CATALINA_HOME in /etc/profile or anything like that). > And why not add a standard program/script/webapp to Tomcat, which prints > out a few lines containing the platform type, Tomcat version, location, > jvm version and location, webapps location, logfiles location, and so > on, so that we could in this forum ask that posters first and for all > execute this command or webapp and prefix their messages with the output ? > Only that, would already save a significant percentage of the bandwidth > on this list. I would love that but you could only really get the real story from the running server. Otherwise, you run the risk of running a script that's not actually being used (like reading bin/catalina.sh when it's not even being called) or looking at a configuration file that's not being used (or out of date). Again, this is a problem: where is your Tomcat running? Port 8080? How about 80? Maybe 8443? 8009? HTTP? AJP? AJP protocol on a (typically) HTTP port? What if it's not running yet? How do you start it? Well, that depends on your configuration... It's just a giant mess no matter which way you slice it. I would love it if package maintainers would maintain a script that would print out the configuration. Tomcat could provide the "default" one that would report what it /would/ use, and the package maintainers can feel free to customize it.... they just have to actually DO it :) Of course, such a script would probably just read configuration from the "standard" location for that environment, which should be published in some documentation somewhere. If most folks would just read documentation, they wouldn't have nearly so many questions... - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkoJp1MACgkQ9CaO5/Lv0PBSbgCeKU0n+2YBqedUbf0arVuCwOhx aGoAn1qrgVqJitcNfmEKna3CcV3EePVB =1/pg -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
