tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Remy Maucherat" <>
Subject Re: AJP Todo
Date Sun, 02 Dec 2001 05:17:25 GMT
> On Sat, 1 Dec 2001, Bill Barker wrote:
> > I have no objection to help porting ${Server}Config to 4.x, but I'm
still a
> > Catalina novice.  The 3.3 API is more command and control, so it is
> > to get to the information.  It will take me a little time to find out
how to
> > get the servlet-mappings in Catalina.
> I'm a bit unhappy with the config generator in 3.3 - I think we can do
> better.
> If you want to work on this, it would be great to make it a bit more
> independent of the container. Right now it is very tightly coupled,
> in order for it to work you need to start tomcat, it doesn't work very
> well with context reloads, etc.

I'd leave it being tied to the container, and getting the lifecycle /
container events. It's (at least it should be) a simple piece of code, and
although most of the code could be static utility methods, I'd implement the
wrapper as a listener, instead of a webapp.

> Of course, we don't have any way to change the mappings without restarting
> apache, but that can be fixed as we add more ajp14 features ( jk_uriMap
> can be changed at run time, we just need the protocol support to send
> update requests ).
> One idea was to generate a .properties file for each webapp, following the
> same style with webapps/ directory. If a webapp is reloaded we can
> regenerate the app's mappings and get jk to reload only that file.
> We could also use a bit of XSLT or a xmlmapper to do that from web.xml,
> without starting the server. This would allow the configuration to be done
> 'off line'.

> > Tomcat 4. I did bootstrap the porting of the docs already, and I've also
> > fixed the problems with compiling against the CVS HEAD, so I think I've
> Great, many thanks !
> > my part :) If you want to see full support for AJP in TC 4.0.2, it's up
> > you guys :)
> Well, if you can also port the 'trusted app' - it would be really great.

I said I would, but it will require adding a few method to the Context
interface (so please, no screaming over API breakage ;-)).


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

View raw message