Henri,
I think Dan is right on this one - improving the configuration of mod_jk
is probably the most important thing, and merging with mod_webapp and
porting it's protocol and config mechanism would be a good way to do that.
I think the best way to do that would be a revolution ( like jasper34 ),
and when it's ready propose it as either a replacement for both mod_jk and
mod_webapp, or as a top level project ( if enough people will contribute
on it ). Combining mod_jk and mod_webapp is likely to result in something
better than both, so the vote to replace mod_jk and mod_webapp will be a
formality :-)
( making it a top level project now is not a good idea right now, neither
to do the development in the main tree - there are just few big bugs to be
fixed before a 3.3 beta. )
Costin
P.S. It's fun beeing a "revolutionar" !
On Wed, 18 Apr 2001, Dan Milstein wrote:
> In terms of integrating mod_jk/mod_webapp, I think this might be worthwhile
> -- specifically, mod_jk was built to handle a variety of protocols (ajp12,
> ajp13, etc.). So writing a protocol handler for the mod_webapp protocol
> would give a lot of benefits -- load-balancing, support for a variety of web
> servers, debugged C code. Pier had mentioned a while ago that the mod_jk
> code was completely incomprehensible. Gal Shachor basically wrote his own
> object system in C, which is very, very confusing at first. I've added a
> lot of comments in the 3.3 branch, particularly to common/jk_service.h, with
> the explicit goal of making it easier for people to write new protocol
> handlers and/or new web server plugins.
>
> One thing I can imagine being a problem right off the bat would be that the
> abstractions which allow mod_jk to deal with a variety of web servers may
> not support the fine-grained control over configuration which mod_webapp
> supports.
>
> Splitting off a connectors sub-project: I don't think I support this -- it
> was discussed on the list a few months ago, and my objections from then
> still hold.
>
> Sharing session-information around: feels way too complex -- I think there
> are better ways to get persistent sessions. Overloading the
> (already-complicated) web server/servlet container communication stream
> seems like asking for trouble we don't need.
>
> -Dan
>
> GOMEZ Henri wrote:
> >
> > Fine to see mod_webapp back to life :)
> >
> > 1) You added many features interesting in building (autoconf, apr)
> > which we could study to adapt to mod_jk (at least autoconf).
> >
> > 2) I plan to update the mod_webapp RPM and hope the code will compile
> > under GCC (it wasn't the case with tc 4.0b2/b3)
> >
> > 3) You still didn't tell us what you think into merging mod_webapp
> > and mod_jk.
> >
> > Why not use mod_webapp/mod_jk to start the
> > web-connector sub-project allowing us to remove many question
> > related to connectors from Tomcat user/dev lists ?
> >
> > The same web-connector project could be used against
> > Tomcat 3.2/3.3/4.0 but not be restricted to Tomcat.
> > Any project understanding the concept of HTTP request/reply
> > could use it.
> >
> > Much more what about using the connector to have the Apache
> > store sessions (serialized) data from Tomcat.
> >
> > Here is the idea :
> >
> > - One Apache may be connected to multiple Tomcat (TomcatA/TomcatB).
> >
> > - Each Tomcat have sessions related data which may be good to
> > see available to other Tomcats in case of failure :
> >
> > ie:
> >
> > TomcatA create a session and data in that session.
> >
> > When replying to Apache (via mod_jk or mod_webapp) it also
> > send the session datas (serialized) when they are created
> > (or updated).
> >
> > Apache store that informations for possible future use (db1/gdb)
> >
> > TomcatA fail (stopped, restarted, jvm dumped...) and Apache
> > (via at least mod_jk) decide to route the request to TomcatB.
> > TomcatB miss the session datas allready generated by TomcatA but
> >
> > Apache could route the request ALONG WITH THE previously saved
> > session
> > informations. TomcatB could then recreate the session, set the
> > session data and then serve the request in the same condition that
> > TomcatA.
> >
> > You get a real fault-tolerant system (no need to resign in some
> > case).
> >
> > What do you think about that proposal (Costin, Craig, Dan, Jon, Pier...)
> >
> > -
> > Henri Gomez ___[_]____
> > EMAIL : [EMAIL PROTECTED] (. .)
> > PGP KEY : 697ECEDD ...oOOo..(_)..oOOo...
> > PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>
>
