----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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].[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'. 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 > > 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 http://xml.apache.org/xerces-c/ And, no, I'm not volunteering either. > > 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]>
