The evolution will goes in jakarta-tomcat-connectors to avoid
disturbing mod_jk/ajp13 in the to be released TC 3.3.
Of course all bugs fixes from TC 3.3 mod_jk will be back ported to
jakarta-tomcat-connectors.
The auto-update will not be my premium priority and I think to
delay it since it will add too much complexity for a first try.
On the native part, I'll need help for autoconf stuff and the
JServ like JVM start. Jon could you help us here since you were
on it on JServ ?
I'd like to see someone take a look at APR, and how we could use it.
May be by adding some wrapper code to avoid having #ifde USE_APR sprayed
in all mod_jk.
Volunteers ?
On the C side code, all help will be welcome. I'm confident with the
code but all help is also welcome (toc toc toc Dan).
May be via review of the regular code commit.
I'm pleased to see the proposal was actively discussed and since many
users ask about integration of mod_jk and mod_webapp, I reiterate here
my invitation to Pier.
>I'll try to implement the Java side as you go with the C changes,
>unless someone else volunteers ( jasper is taking more than
>I expected, and xalan has a release planned in few weeks ).
May be Kevin could help also and could commit it's AJP13 in
jakarta-tomcat-connector.
>BTW, we'll need to discuss about the Java side - so
>optimizations on the "lower" level would work on any container.
>
>
>At minimum we need MessageBytes or equivalent, MimeHeaders or
>equivalent
>( i.e. recyclable, low overhead, etc ), and a simple Request
>object that
>can be easily adapted to TC3.3 and TC4.0.
AJP14 will be only available to TC 3.3/4.0 since the 3.2 is closed
to new features. But did the AJP12/AJP13 in jakarta-tomcat-connectors will
contains code for tomcat 3.2 tree also ?
>This is not the "easiest" solution - from my point of view the easisest
>would be to just write the Ajp14Interceptor and use the existing and
>optimized 3.3 infrastructure. ( and use a reimplementation of
>the protocol for 4.0 - using their low-level objects ).
