Hi Bill almost missed your reply...
I'm subscribed to so many mailing lists, my incoming mail is starting to
look like a flash animation...
Briefly, yes... I am looking at it....
or more accurately I'm struggling with a cool exciting concept....
Goes something like this.... auto JK config maybe a "toy" as you say, but
besides JMX, it was one of the few things that presented a partial model of
TC to another system.... that concept I find very appealing.
I'm thinking... ok, well JMX (via the internal mbeans registering
themselves), represents the live model of Tomcat.
and.... JMX has effectively demoted XML configuration to something that now
really just represents the persisted static model of TC.
So if one wants to make helper tools... those tools need to be interfaced
with and aware of both the live and static models of TC.
As a simple auto JK tool, its, as you say, a toy.... but now add JK load
balancing to it, and mod_proxy with the ability to perhaps even configure
HTTPd, then someone will go, gee thats cool, lets make it easy to configure
SSO, and the realm, and hey lets add JNDI to that.... and then people are
going to scream for a JMX interface to this easy configurator....
.....thats how I'm thinking....but it raising all sorts of issues in my
mind....
Like maybe the whole concept of core beans registering themselves with JMX
is wrong.... or maybe there has to be JMX for the expert TC developer and a
JMX for the admin dude.
For example (I havnt tried it), but what happens to TC if you change the
connected port, or reset a Realm through JMX... its live, so just how badly
would that screw up TC.... or will TC raise an exception and just ignore
you.... just how smart are the core beans?
Now JMX through the "easy configurator" or "TC modeler".... would be
something different, if you change the JK load sharing, it would say
"configuration illegal", or "new configuration will become active on a TC
restart.... do you want to restart when user activity has ceased".
It would become the model of TC that people see.... it would become a
"modeler".... and it would become a safe layer between the live TC and what
people are trying to make it do?
Thats how confused I've managed to make myself.... I need to do more
homework on the idea... I'd like to try turn something that programmers are
now finding boring, into something very exciting.... hopefully ;)
----- Original Message -----
From: "Bill Barker" <[EMAIL PROTECTED]>
To: <users@tomcat.apache.org>
Sent: Monday, July 02, 2007 3:26 AM
Subject: Re: Using auto-configure with Tomcat 6.0
That would actually be a very valuable contribution. One idea that I
looked at awhile back is a class that does minimal parsing of server.xml
to embed Tomcat (via JMX, it's soooo much easier), insert the Listener,
and then start the contexts to get the file, and then stop.
Well, the way that I found out is people on this list compaining that
their auto-conf files generate warnings on httpd 2.2.x :). Personally, I
lurk on [EMAIL PROTECTED], but this isn't for everyone. Of course, to find out
more, you just go to http://httpd.apache.org and check the documentation
and/or changelog. To add a new attribute to the ApacheConfig class (from
server.xml), all you have to do is declare the public getter/setter
methods in standard JavaBean style. Most standard type conversions are
supported by Digester (e.g. adding setApache22(boolean) would allow
apache22="true" is server.xml).
I look forward to reviewing your patch.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
