jk2 status

[co...@covalent.net]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>