Craig,
I assume I'm the person interested in porting mod_jk to TC 4 (if there's anyone else,
please get in touch with me ;-).
Thank you for clarifying the issue about the difference between the 2.2 and 2.3 specs
-- I hadn't realized that.
I do have a question: how would you feel about including mod_jk in TC 4 before it
became totally 2.3 compliant? In other words, if I managed to write ajp13 and/or
ajp12 connectors for TC 4, how would you feel about that being committed to cvs
immediately, so that people could start using it (and using TC with various web
servers), *before* making the extensive additions which would be necessary to bring it
into 2.3 compliance?
To my mind this would be worthwhile, and in keeping with TC 4 development in general
-- there is the doc specifying the various degrees of "doneness" of 2.3 compliance. I
see it as a very pragmatic path -- I believe that adding a functional web server
connector would give many, many more people reason to start using TC 4, which can only
be a good thing. And, I hope, that increased usage would bring more volunteer
resources to bear on the connectors -- which could be mod_webapp or mod_jk.
I ask this because I am honestly not sure how much time I can devote to the project --
I am hoping to write the ajp13 connector, but I am not sure if I will have the time to
rewrite all the C code (something I'm not as expert at) to bring mod_jk into 2.3
compliance. If I can only offer the code for the current ajp13, would that be
something you would be comfortable with merging into the TC 4 codebase?
Thanks,
-Dan
"Craig R. McClanahan" wrote:
>
> GOMEZ Henri wrote:
>
> > [finally ... a technical issue!]
> > I still didn't understand why TC 4.0 didn't select mod_jk as
> > their connector to WebServer. The code is clean and many bugs
> > are removed. A web server connector is not an easy piece of cake
> > so why reinvent the whell ?-(
> >
>
> Tomcat 4.0 did not select mod_jk for several reasons. The most important ones
> are at the top:
>
> * MOD_JK (like MOD_JSERV before it) has no clue what a web
> application is. This forces you to configure many items twice --
> once in the web.xml file and once in the Apache configuration,
> which is a pretty serious imposition on people trying to administer
> the combination.
>
> * While the 2.2 spec was silent in many areas, the 2.3 spec will
> require an Apache+Tomcat combination to obey *all* the requirements
> of the spec (same rules as for any other container). This means that
> the things in web.xml *must* be respected. For example, a security
> constraint in a web.xml file must be enforced, even on a static resource
> that is served by Apache instead of Tomcat. Substantial modifications
> to MOD_JK would be needed to make this work (primarily in adding a
> two-way exchange of configuration information).
>
> * MOD_JK had no committers interested in maintaining it, at the time
> that the decision was made. Subsequent to that time, several
> volunteers have surfaced, including at least one person interested in
> supporting MOD_JK under Tomcat 4.0. That would be fine with me,
> as long as the result obeys all the rules.
>
> Craig McClanahan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
--
Dan Milstein // [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
