Good Morning Bill (at least in my TZ that is),
many thanks for clarifying what Http10Connector stands for.
Of course I should have known that it refers to version 1.0 of
the HTTP.
I admid that I should be reading more of the docs of the Tomcat
project,
and probably have an occassional glance at the sources where I
suspect further commentary.
I think to recall that there even was such a thing as javadoc
that would provide
a documentation of the class'es interfaces
(but this should more be dedicated to the application developer,
I suppose).
As I said, I am merely a simpleton sysadmin who unfortunately
lacks the time to delve deeper into the Java/Tomcat guts.
You're right, I do have a modules.xml file in this server's conf
dir.
These are the modules listed within the module tag:
(I hope you don't mind the Perl line noise, but can you parse a
Tomcat conf file with a Java oneliner? ;-)
perl -MXML::Simple -le 'print join("\n",sort keys
%{XML::Simple->new->XMLin("/opt/hpapache2/tomcat/conf/modules.xml
")->{module}})'
AccessInterceptor
AccessLogInterceptor
AccountingInterceptor
Ajp12Connector
Ajp13Connector
ApacheConfig
AutoDeploy
AutoWebApp
ContextXmlReader
CredentialsInterceptor
DecodeInterceptor
ErrorHandler
Http10Connector
Http10Interceptor
IISConfig
InvokerInterceptor
JDBCRealm
JNIConnectionHandler
Jdk12Interceptor
JniConnector
JservConfig
JspInterceptor
LoadOnStartupInterceptor
LoaderInterceptor11
LogEvents
LogSetter
NSConfig
PathSetter
PolicyLoader
ProfileLoader
ReloadInterceptor
ServerXmlReader
Servlet22Interceptor
SessionExpirer
SessionId
SessionIdGenerator
SimpleMapper1
SimpleRealm
SimpleSessionStore
StaticInterceptor
TagPoolManagerInterceptor
TrustedLoader
WebXmlReader
WorkDirSetup
Would you mind telling me, which of these modules could be of any
use for my Tomcat monitoring purposes.
I'd simply like to cut down the masses of documentation I would
peruse in vain to only find out that a module was totally
irrelevant to my objective.
Apropos, another stupid question, what does TC stand for (is it
Tomcat)?
Regards
Ralph
> -----Original Message-----
> From: news [mailto:[EMAIL PROTECTED] Behalf Of Bill Barker
> Sent: Thursday, February 02, 2006 4:26 AM
> To: users@tomcat.apache.org
> Subject: Re: How to identify version of a running Tomcat and
similar
> trivia
>
>
> 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]
> walt-berlin.de...
> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
