tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "GOMEZ Henri" <hgo...@slib.fr>
Subject RE: mod_jk2 config
Date Tue, 12 Mar 2002 00:03:38 GMT
>> >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:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message