TC 4 / mod_jk

[Dan Milstein <da...@shore.net>]

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: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org
-- 

Dan Milstein // danmil@shore.net

Re: TC 4 / mod_jk

["Craig R. McClanahan" <Cr...@eng.sun.com>]

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: tomcat-dev-unsubscribe@jakarta.apache.org
> > For additional commands, email: tomcat-dev-help@jakarta.apache.org
> --
>
> Dan Milstein // danmil@shore.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, email: tomcat-dev-help@jakarta.apache.org