[EMAIL PROTECTED] wrote: > > 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.
We could write a converter from "old" format to "new" format if too many people complain. > > 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. A warning in the first lines of the file like: +++ # # NOTE: This file is automatically updated by the autoconfigure. # Any changes will be lost! # +++ is probably enough. > > 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 :-) If the file is handled by program it does not need to be nice: for me the property format is enough. And -0 for using xerces C to do that... I want to run mod_jk on EBCDIC machines and porting xerces C is some work. What about parsing the xml file in Java? ;-) > > Costin > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
