tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject RE: mod_jk2 config
Date Thu, 07 Mar 2002 17:01:36 GMT
On Thu, 7 Mar 2002, GOMEZ Henri wrote:

> >In future versions we can add anything - the code is now
> >much more modular and easier to extend. 
> 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.

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

> >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 ) :-) 

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 ).

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. 

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.


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

View raw message