tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "GOMEZ Henri" <>
Subject RE: mod_jk2 config
Date Mon, 11 Mar 2002 23:06:41 GMT
>> Yes, and we had all to relearn it :-)
>You already know me, as long as nobody complains ( and -1 ) 
>I move on until I'm happy enough with the design.

And that's fine :)

>Jk was already 'object oriented C', I just enhanced that
>and tried to clean up a bit. 

And it works well, better design and working implementation

>> >For refresh - again, I would prefer an explicit control, maybe
>> >using the status worker ( or a config worker ) - you can deploy a 
>> >new app on a dozen of workers, and then refresh the apache config.
>> Arg, you'll see we'll have to create a nice WEB interface for this.
>> IBM does a superb job in their AS/400 implementation with a cool
>> UI creating workers/in-process/out-process tomcats, 
>something I'd like
>> to see in jk2 and may be via a new jkconfig worker....
>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.

>Seriously - the properties file doesn't have to be visible to the 
>user, it's just a format that is easy to parse on the C side
>and easy to generate/edit from java ( by a GUI, deploy tool, etc).
>KDE, Gnome, etc are using this kind of stuff without problems.
>The win registry is much worse, but still has a similar model -
>a hierarchical-named key/value. 


>I love XML, and I could probably write expat code - but I don't
>think it's a complexity we need. A much better/simpler solution
>would be to have a XML config file and a simple xsl ( or just
>java xmlmapper/digester ) to generate the properties.


>I also think the _best_ solution to generate
>is not what we use in 3.3 ( the interceptor extracting info
>from inside tomcat), but a standalone tool ( eventually 
>ant-scriptable )
>that transforms web.xml directly ( == a deploy tool independent
>of tomcat ).

Good idea

>Ant is obviously an excelent driver for this, but needs some work.
>Let's try to wrap up the first release of jk2 with minimal 
>additional features ( i.e. don't let me change too much more :-)


>I still want to finish the setProperty() changes and allow the
>channel to be configured independently of worker ( it's cleaner,
>simpler - and similar with what we do in the java side of jk ).
>And I'll start to run end-to-end watchdog tests to make sure
>jk2/java is fine. 
>My proposal is to first release jk2/java, as a replacement for
>the current jk connector/jk interceptor ( using mod_jk1 ).


>Then we can release mod_jk2 for apache2.0/1.3, and maybe 
>finish the iis/nes updates. 

what's the status of iis/nes/domino ?

>We are pretty close, the 'core' stuff is in a decent shape,
>and all extra features can be refined and updated in future
>> >I think Apache has some time() function called ( so it can log the 
>> >total time ). We can use it, and call the system if we want to 
>> >tune our stuff ( but not in the default config, only if enabled 
>> >and maybe per uri )
>> I was thinking about a faster time() alternative, there was hacks
>I think for now it is enough to have an option on the uri to
>enable counting, and use the system time. It's not an essential
>feature or something that should be enabled in production mode
>for all pages, it's maingly for tuning.

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

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message