On Tue, 12 Mar 2002, GOMEZ Henri wrote: > >The best UI for configuration is xemacs ( or vi ) :-) > > May be for experienced users/admins, but this kind of tools are > one of the reason IT managers choose products like websphere > because they fill it will be easier to manage.
I had a :-) at the end :-) The whole point of refactoring the jk2 configuration is to make it easier for tools to manage it. The proposed get/setProperty would even be easily implementable as a simple dynamic mbean on the java side, and the status worker will be much simpler and powerfull ( changing any jk property at runtime would be close to trivial ) My only remaining concern is updating/saving workers.properties when updates are made ( either via ajp14 or the status/ctl worker ). The main problem is that comments are going to be lost. I hope to abstract the config storage enough to make this pluggable, with one option beeing read/write properties file ( with no comments ). > what's the status of iis/nes/domino ? Apache1.3 is the next - it's mostly replacing strings and removing the duplicated code ( a lot of the server-specific initialization has moved to common/ ). As soon as the code is stable I'll finish 1.3, I can probably do IIS as well. > Exact, it will be used only on LOGREQUEST mode. Which make me > think that we could have this one in a + mode. > > JkLogLevel info + request > > instead of > > JkLogLevel request Don't forget - it's JkSet object.property value :-) I would make it a per/uri property ( instead of a global or per/worker property ). Maybe <Location ....> JkUriSet logRequest true </Location> The log level should remain INFO/DEBUG/..., similar with the java side, but we can easily add settings to log more info in individual objects. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
