>
>Should it become default? I hope the answer is yes:)
>
>It also has another value: "inet" is not a well-known
>parameter. Having it in default server.xml along with a little
>comment about
>what it does may compensate for the lack of proper documentation:)
+1 for the addition in server.xml (Marc, Larry ?)
>> I understand your valid requirement, but why not just developp a
>> servlet in admin which use ajp12 to send (to localhost), the ajp12
>> shutdown command.
>>
>> >Hope this helps :)
>>
>> Yes, and I hope you'll take a look at the ajp14 proposal.......
>I did.
>I don't really understand why Ajp protocol should handle
>shutdown command
>at all. I agree that there may be a need for some kind of servlet that
>handles this operation but WHY THROUGH Ajp protocol???
Adding shutdown in ajp14 will help a web admin to build a control
deck to shutdown from ONE POINT some or all of its Tomcat.
>It almost sounds like merging two things that serve totally
>different purpose
>together. What if you want to add more commands in the future?
The AJP14 is not closed, it's just a starting point for discussion.
>Would you
>really want to add these commands into ALL versions of
>protocol? And how do
>you handle these commands if you don't?
The AJP15 must handle all commands from AJP14 and will
have its owns one. Also you must have notice about the
negociation at startup. Some asked to add at start of
negociation a string indicating which protocol are supported
by web-server. The servlet engine will then use the higher
common protocol :
ie: web-servlet knows about AJ14/AJP15 but servlet engine only
AJP14. The protocol used will be AJP14.
web-servlet knows AJ14/AJP15 and servlet engine AJP14/AJP15/AJP16.
The discussion will use AJP15.
>IMHO there are few related but different things one wants to
>do with TC:
>1)Serve requests - handled by Ajp protocol.
>2)Configure&administrate - this one is a bit more complex.
>
> Some people (including myself) like doing configuration
>manually in
> command line interface. Hence there needs to be well
>defined set of config
> files and scripts one needs to care about. One of my
>personal challenges
> while setting up TC for the first time was to find out
>what config files
> are actually necessary. There is whole bunch of files
>in config directory
> for ALL the possible platforms/servers, etc.
I'm like you and do by hand all my configuration, and
set my JkMount in VirtualHost. But many starting users
will like the autoconf features.
Note that JkMount could still be used and JkAutoMount
is then mandatory...
> Some people would prefer to use some UI tool to
>configure the server and
> issue commands - here is your idea of extending
>functionality of "admin"
> application, add shutdown/restart commands to it as
>well as may be some
> other options like configuring "connectors", including
>configuration of
> ports, interfaces, etc. There may even be some applet
>for monitoring
> the log files (like in Sun's JavaWebServer).
> I think good example is configuration as it is done in
>"Enhydra".
> This kind of tool doesn't need any "middle man" in the
>form of Ajp or any
> other protocol. It can have hooks directly into server
>API. The advantage
> of this is that Ajp protocols remain "plugguble" unlike
>Ajp12 that you
> "need to have" to issue simple "shutdown" command and
>configuration
> may evolve without any weird dependencies on any
>particular protocol.
Some Admin Servlet could do the job....
> Some people MIGHT want to set up distributed
>environment (read load
> balancing here) where the same application is
>physically distributed
> across multiple machines but configuration MUST be
>changed synchronously.
> This may be handled just by some *NIX scripts, etc but
>in this case
> having some "administration" protocol might be usable
>to build "centralized"
> configuration where all the changes are made in one
>place and communicated
> to all the balanced servers using some protocol. There
>are lots of
> complicated issues here but this is the place where
>IMHO some protocol
> might be NECESSERY. And even than I wouldn't add this
>features into
> any Ajp?? protocols. I'd much rather define another one
>that again may
> evolve differently from Ajp protocols but might use Ajp
>protocol as a
> transport layer.
AJP13 is still present and supported, but lack some features
needed for Servlet API 2.3. My english is bad but AJP14 WILL
USE AJP13 as transport layer, there will be new commands added
and new cinematic, but AJP14 = AJP13++
>Here is the list of modifications that I've done to TC so far:
>1) changed defaults to bind to 127.0.0.1 interface in server.xml.
Will be changed in server.xml for 3.2/3.3 (Marc/larry are you agree)
>2) changed shutdown code to make it work correctly if "inet"
>parameter is used.
Thanks to (re)send the code to list.
>3) modified mod_jk logger function to print timestamps in
>Apache Web server style.
Allready exist in mod_jk in TC 3.3 CVS (another reason to have
web-connector)
>4) modified tomcat.sh file in "bin" to redirect stdout&stderr
>to a log file (people complained about not seeing System.out.println()
stuff)
Done by the official Tomcat RPM which modify tomcat.sh to
feed /var/log/tomcat.log
>5) modified default load balancing behavior to make use of
>wireless device's
> "global id" (I'm not giving details on this one because
>it's specific to
> what we are doing and probably useless for others. But I'm
>not hiding it:)
> I can describe it if anyone is interested).
Please. I realize I must'nt be too stupid since we have done
many common things :)
>Sorry for the long E-Mail:) Hope you've read it:)
I read all of it. Hope to read you soon.
