On Mon, 18 Mar 2002, Bill Barker wrote:
> I can see that this is going to make life difficult for ApacheConfig. Yes,
> hopefully we can deprecate it soon. But in the mean time, I'd personally
> prefer that the port is a property of the worker.ajp13. So your example
> would be:
> worker.ajp13.channel=socket
> worker.ajp13.port=8009
ApacheConfig is likely to change into JkConfig - we'll have almost
nothing in httpd.conf, and nothing specific to apache ( except
the experimental <Location>, which I hope to implement using the
config APIs in apache2 - the only purpose is to take advantage of the
native apache mapper and framework ).
Right now there's no 'magic' in jk2, but as soon as things are stable
I'll start adding it - setting the port on the worker is easy, and
more.
If we use a new default name ( jk2.properties ? ) and
default location ( ${ServerRoot}/conf/jk2.properties ), the only
change in httpd.conf will be including mod_jk.so ( and we can
clearly recommend puting mod_jk.so in modules/,
like all other modules )
But in the general case, I want to keep the 'channel.socket' and
'worker.ajp13' separated, and use code in the setter to simplify the
configuration without mixing up the real objects.
> I can't see that many people will do manual changes without at least doing
> "apachectl graceful". As long as that works, I can't see much of a problem
> here (at least in the real world).
There's a small problem here. If you use a management application
or ajp14 to automatically deploy apps - the config file will
change on disk. If you edit it manually at the same time - not
good :-).
You can continue to edit it manually, and it's easy to code
something in the status ( or conf ) worker to reload jk2.properties
gracefully - without even restarting the server. ( you don't
want to restart apache every time a worker is added/removed ).
> It's not that bad. If you allow in C++ (and on non-performance critical
> paths I don't see why not), then it's just http://xml.apache.org/xerces-c/
> And, no, I'm not volunteering either.
Expat is included in apache, but I don't want to increase complexity
without a good reason. Reading is not the big concern here - we'll
also have to write it, and keep code simple.
I would rather spend the time writing a jk_config_ldap - that would
much more sense given the target ( farms of workers and servers, etc ).
But that would require more work on tomcat as well to make it get
config from a directory service ( quite easy to do, if we had time ).
Propeties are good as 'common ground' because they force us to
keep things simple. As soon as we add XML, people may use entities,
includes, etc.
Costin
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
