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].[PROPERTY]=value 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: worker.ajp13.8009.channel=socket In this case, "channel" is the property, and worker.ajp13.8009 is the object name. It'll match the factory for 'worker.ajp13'. 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. 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 ... 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 :-) Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
