tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Armstrong <a...@tagish.com>
Subject Re: #define JK_VERSION in j-t-c (doesn't exist)
Date Fri, 15 Jun 2001 13:54:52 GMT
GOMEZ Henri wrote:
[snip]
> As I said Domino need to be compiled. It could be marked as experimental
> and only Domino users will have this warning.
> 
> Why did we start j-t-c ?
> 
> - a connector is mainly native code, how to build apxs or use autoconf
>   has nothing to do in tomcat dev/users list. I hope we could have a
>   separate dev/users lists later.
> 
> - mod_jk is in TC 3.2 and 3.3. Thegeneral rules for TC 3.2 is to freeze
>   features and only correct bugs.
>   I add some features (AP2.0 support, TimeStamp in log, more robust handling
> 
>   of Tomcat failure or reboot) in the mod_jk for TC 3.3 and now the version
>   have diverged :!
>   Frankly having 2 code branchs to support is too just much job.
>   And then Kevin proposed the ajp13 port to TC 4.0, and so the need for
>   an independant repository
> 
> - a connector could/should be independant from the core container
>   and we could have a different release rate.
> 
> - j-t-c make possible reflexion on how to build connections
>   common to TC 3.2/3.3/4.0. See the excellent Coyote Proposal which live
>   now in jtc.

I understand all that, but I'm not quite clear how that negates the
possible advantage of making it possible to know at compile time which
version of the jk code is being used, and in general if there is a
version number at all defining a way of mapping it to a numeric constant
also seems to be a good idea. Is your concern that, if we were to do
that, the code would end up polluted with many conditionally compiled
sections making testing and maintenance harder?

If nothing else such a constant could be used to throw a compile time
error if people attempt to build a connector using incompatible shared
jk code.

-- 
Andy Armstrong, Tagish

Mime
View raw message