>> >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 :-)
Yes, I noticed ;) >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 ) Yes >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/ ). good >As soon as the code is stable I'll finish 1.3, I can probably do >IIS as well. What about iPlanet and Domino ? >> 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. Good -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
