tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <>
Subject Re: config
Date Tue, 19 Mar 2002 06:56:53 GMT

----- Original Message -----
From: <>
To: <>
Sent: Monday, March 18, 2002 10:07 PM
Subject: jk2: config

> I just commited a big chunk of config changes to support
> dynamic configuration of jk2.
> I'm pretty happy with the new model - many new things
> will become possible.
> As you know, I'm usually a bit extreme regarding backward
> compatibility. Preserving it is still possible - but
> I'm now convinced it would be much better to not do so.
> The current code follows a single pattern:
> OBJECT_NAME can be either a previously defined
> object ( like 'logger', 'workerEnv', 'config' ) or
> a new object that is created when the name is first
> reached.
> The object is created using a factory that matches
> the prefix.
> Ex:
> In this case, "channel" is the property, and
> worker.ajp13.8009 is the object name. It'll match
> the factory for 'worker.ajp13'.

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:

> No need to specify 'type' or 'worker_list' or to
> use any other constructs.
> The property can be set at any time - but not all
> objects and all properties support run-time
> config ( at this moment - we'll add this in time ).
> The whole idea is that the config is intended for
> config tools or other frontends - or at least that's
> the goal. We want to allow user configuration, but
> in order to support ajp14 and dynamic config ( like
> deployment of webapps, etc ) we need to let mod_jk
> write the config file.
> Axis does the same thing with the wsdl, same for
> kde, gnome, etc. The config is editable, but when
> the program runs it will manage it and save it.
> The main problem is that the comments may be lost,
> and any manual change done while the server
> is running will probably have the same fate.

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).

> Again, this is not for the first release of jk2, but
> IMHO it should follow soon.
> One idea I'm considering is to use the ini style
> for URIs. That is:
>  [object_name]
>  propery=value
>  ...

Well, the MS syntax is well known.  I don't have a better suggestion, so
I'll hold my nose and +0.

> This will make the syntax much cleaner for URIs.
> It's a well-known format, used in many cases and programs
> - far better than inventing our own ( and better
>  than hacking the name/value ). Of course, XML
> may be a better choice - but I won't volunteer to
> do xml processing in C :-)

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
And, no, I'm not volunteering either.

> Costin
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message