Dan Milstein wrote:
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?
I am OK with (as opposed to enthusiastic about -- I'd personally prefer to see people
fixing mod_webapp than doing this) someone wanting to write a Tomcat 4 connector for
MOD_JK, as long as:
* Everyone understands that it's there simply for porting
and won't be compliant with the final specs
* Enough people are willing to do support for it so that it
doesn't just collect bug reports (like MOD_JK did until
you and others started working on it again)
The quickest way to accomplish this would be to mimic the organizational structure of
org.apache.catalina.connector.http.Http{Connector,Processor}, and change the way that
request properties get sent. Everything that happens to a request after that point
(i.e. after you call invoke() on the Engine) does not care where the request came from.
NOTE: In terms of timing, I'd rather see this work in the 4.1 repository so it
doesn't destabilize anything in the 4.0 beta cycle, or delay it.
Thanks,
-Dan
Craig
"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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
