The Http10Connector refers to HTTP/1.0. It also means that you've got a TC 3.x server running there. If you've got a conf/modules.xml then it's probably TC 3.3.1a (since 3.3.2 uses the CoyoteConnector by default). Otherwise, it's probably TC 3.2.4.
It also explains why there is no /manager webapp, since it's called /admin in TC 3 (and is much less full-featured than /manager in later TC versions :). <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Hi Tim, thanks for referring me to the Tomcat FAQs. That's for sure the first source of information one should read before nagging the list community with redundant questions. At least did I find therein a description how to enable CGI support. Yet, the trivial task of identifying a running Java thread's Tomcat version seems rediculously convoluted. I assume the mentioned version script isn't much more than a mere wrapper script that puts together the a hundred chars long java invocation of some class method call that most likely is called version() along with the loading of a dozen jar libs etc. (only joking ;-) Anyway, far more than anyone can remember and type without making typos. Only problem is, my Tomcat depot on this box (randomly picked one of our HP-UX boxes, but we also have Tomcats running on Linux, AIX, Solaris (and probably Win32) doesn't seem to have bundled such a wrapper script. # swlist |grep -i tomcat hpuxwsTomcat A.4.1.29.04 HP-UX Tomcat-based Servlet Engine (ok, I concede with a properly bundled hpux depot I get a revision string that happens to be the same as the bundled Tomcat version, but that's not everywhere the case) # swlist -l file hpuxwsTomcat|grep -cF version 0 So where can I get such a version script? Hm, most likely in the official Apache Tomcat tarball distribution. Ok, I got that already for my Linux install problem (where I first thought to be required to compile from sources by Ant). Let's see if I find it there $ gzip -dc apache-tomcat-5.5.15.tar.gz |tar tf -|grep -F version apache-tomcat-5.5.15/bin/version.bat apache-tomcat-5.5.15/bin/version.sh Yup, let's see what its content is $ gzip -dc apache-tomcat-5.5.15.tar.gz |tar xf - apache-tomcat-5.5.15/bin/version.sh $ grep EXE apache-tomcat-5.5.15/bin/version.sh EXECUTABLE=catalina.sh if [ ! -x "$PRGDIR"/"$EXECUTABLE" ]; then echo "Cannot find $PRGDIR/$EXECUTABLE" exec "$PRGDIR"/"$EXECUTABLE" version "$@" What the hack is catalina? Only know of an island off the coast of Los Angeles of that name, and a nice WWII water plane. But if I have the catalina.sh script anyway, and the only arg it is fed with happens to be "version" then I won't require the version script on my hpux boxes anyway. What a production... Then some of you mentioned a manager or admin webapp. Is this provided along with the basic Tomact installation, or an add-on. Well, when I run a GET on this URI on the Http10Connector according to this server's server.xml (btw, what is a Http10Connector? does it refer to the maximum bandwidth?) I only get a 404 server response. Seems there is further installation of a servlet required. # wget -O - http://localhost:8081/manager/html --16:52:07-- http://localhost:8081/manager/html => `-' Resolving localhost... done. Connecting to localhost[127.0.0.1]:8081... connected. HTTP request sent, awaiting response... 404 Not Found 16:52:07 ERROR 404: Not Found. Regards Ralph > -----Original Message----- > From: Tim Funk [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 01, 2006 12:47 PM > To: Tomcat Users List > Subject: Re: How to identify version of a running Tomcat and similar > trivia > > > See the FAQ. http://tomcat.apache.org/faq/ > > There are a few ways to get the version > 1) Use version.sh (or vertsion.bat) > 2) Look at the manager webapp (in url /manager/html/) > 3) More ways that I can't remember > > -Tim > > [EMAIL PROTECTED] wrote: > > > Hi Tomcatters, > > > > I beg your pardon for this affront to any self-respecting servlet > > coder's mind. > > I am but merely a Unix sysadmin plagued with a varying zoo of > > Tomcats on different Unices who is largely Java-ignorant and only > > has to maintain these cats (sorry, but Perl suits my mundane > > admin tasks much better). > > Nevertheless I hope you deign giving me an answer to my trivial > > questions. > > > > 1. How can I identify the version of a running Tomcat without > > reaping it or wreaking similar havoc? > > > > Back in ole Apache days things where easy. > > You only had to locate the residence of the httpd daemon's binary > > (which was just a glance at the proc table), > > and run a httpd -v on it. > > These times all I can see is a running Java master thread. > > All it discloses is the version of the Java interpreter from the > > respective JRE. > > > > 2. How to quickly introspect a Tomcat's child thread, resource > > usage? > > > > I cannot see from the OS's proc table how many child threads a > > master has spawned and keeps maintaining, > > nor which resources they share. > > If something gets cranked up, what seems to be quite often for > > some of our Tomcat implementations > > (almost never experienced a crashing Apache), all I can do is > > killing the master thread > > if it is still appearing in the proc table though. > > (I assume the rather instability is owe to too many average Java > > hackers deem themselves eligable to tinker with the Tomcat's > > memory management relying on automatic garbage collection, only > > comparing this with what I learned about mod_perl and proper > > initializations and freeing of resources) > > > > 3. How to identify a Tomcat's config? > > > > Well, I could run a find for server.xml, but this would most > > likely spit out a dozens of namesake files > > of various "test" instalations that aren't of relevance. > > > > I think, there ought to be an URI one could query. > > > > For instance when I lookup the proc table on a hpux box at best I > > can only see this mess > > > > $ UNIX95= ps -x -C java -o args= > > /opt/java1.5/bin/PA_RISC2.0/java -Xverbosegc:file=/tmp/gc.out > > -server -Xms256m -Xmx256m -Xmn128m -XX:+DisableExplicitGC > > -XdoCloseWithReadPending > > -Djava.security.policy==/opt/hpapache2/tomcat/bin/../conf/tomcat. > > policy -Dtomcat.home=/opt/hpapache2/tomcat/bin/.. > > org.apache.tomcat.startup.Main start > > > > Ok, from this I could at least guess that there might be a > > /opt/hpapache2/tomcat/conf/server.xml > > lingering. > > > > > > 4. Parsing the config > > > > Despite their ever increasing whitespread I think these XML style > > config files are a nuisance for a sysadmin > > who neither is able to nor willing to use an X application for > > config maintenance, querying > > (think of low bandwidth serial line connections and the impedence > > by ubiquitious firewalls) > > I wouldn't quite argue that a sendmail.cf file is anything more > > readable to the human, > > but I find it rather overkill to throw in an XML parser module > > (like CPAN's XML::Simple, XML::Parser or XML::SAX) > > merely to find out basic configuration settings (e.g. like > > listening ports). > > > > So is there a CLI tool or a special URI for quereing a Tomcat's > > config? > > > > 5. Tool for monitoring a Tomcat's state > > > > I know there's some Java Monitoring classes (was it JMX or so?). > > But as I told you I am not into Java, and most of all I lack the > > knowledge of the underlying class hirarchy. > > It would be nice if I could use or come up with an own Perl > > plug-in. > > Is it possible to enable "legacy" CGI support with Tomcat? > > Then I could at least provide my own monitoring scripts. > > > > > > Regards > > Ralph > > > > > > > > > ----------------------------------------------------------------- ---- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > ----------------------------------------------------------------- ---- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
