I haven't done any commit in the last few weeks, that's because I'm strugling with the config/autoconfig refactoring ( and I had a lot of non-tomcat work to do ).
I think the java side is in a pretty good shape. I decided to give up refactoring the config stuff for the first release, so I'll check in the config interceptors from 3.3 ( and update the 4.0 valves ), and hopefully in few weeks be ready for a beta that can be used as a direct replacement for Ajp13Interceptor and the ajp connector in 4.0. It'll just be faster, cleaner and maybe a bit easier to set up - no new features should be expected ( even if the code is there, the goal is to be able to replace the old java code with something as stable ). We can mark the new stuff as 'experimental' for brave users, or just wait for the jk2.1 release. We need to reach agreement on the jk config stuff - do we want to keep the old setting style in server.xml and interceptors.xml ? Are we comfortable with using web.xml ( with the gain of possibly using admin tools, a well documented and familiar dtd, etc ) ? Would it be better to use workers.properties style, and be consistent with the C side ? All 3 ? For autoconf, the old code will be used, but in future I would like to move it to a separate package. I strongly believe that the autoconfig should be integrated in an admin tool - we can't require people to start tomcat before apache ( especially in Jni mode :-), and it's tricky to make it work in an lb env. Ajp14-style has similar problems ( tomcat must be running ), and it's pretty hard to do it right for complex deployments. So I would change this into a set of config utils, independent of jk, maybe even use ant as a driver ( and combine it with the deploy tool, etc). I would also reorganize the generator in 2 parts - one would generate Apache/IIS/NES 'generic' config ( LoadModule, Ports, options ). And one would generate a config fragment out of web.xml ( for each app ). When a new app is deployed or a change happens, the deploy tool would call the config module and maybe a server-speciic module to do soft restart or on-the-fly reloading of mappings. This keeps jk simple and adds much more flexibility. But it depends on your aproval and commits - as we know, config is the biggest problem for users, and we'll need a lot of work here. Costin P.S. It's a long mail, today the train to SF is slower than usual :-) -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>