Re: #define JK_VERSION in j-t-c (doesn't exist)
One small point comes to light now you've released this: version.h is quite a common thing to have on your include path; certainly under MS operating systems there tends to be a version.h already on the include path which may cause confusion. Any reason not to call it jk_version.h? jean-frederic clere wrote: Andy Armstrong wrote: jean-frederic clere wrote: Hi, I have prepared a patch for configure.in to generate JK_EXPOSED_VERSION and JK_VERSION. The result is a file named common/version.h: +++ #define JK_EXPOSED_VERSION mod_jk/1.2.0-dev #define JK_VERSION (((1) 16) + ((2) 8) + (0)) +++ Any comments? - Otherwise I will commit it tomorrow - -- Andy Armstrong, Tagish
RE: #define JK_VERSION in j-t-c (doesn't exist)
One small point comes to light now you've released this: version.h is quite a common thing to have on your include path; certainly under MS operating systems there tends to be a version.h already on the include path which may cause confusion. Any reason not to call it jk_version.h? +1 for jk_version.h Sure it will take less than 30ms to JF :)
Re: #define JK_VERSION in j-t-c (doesn't exist)
GOMEZ Henri wrote: One small point comes to light now you've released this: version.h is quite a common thing to have on your include path; certainly under MS operating systems there tends to be a version.h already on the include path which may cause confusion. Any reason not to call it jk_version.h? +1 for jk_version.h Sure it will take less than 30ms to JF :) Done, it was more 3 mn and 3 commits...
Re: #define JK_VERSION in j-t-c (doesn't exist)
Andy Armstrong wrote:
jean-frederic clere wrote:
Hi,
I have prepared a patch for configure.in to generate JK_EXPOSED_VERSION and
JK_VERSION.
The result is a file named common/version.h:
+++
#define JK_EXPOSED_VERSION mod_jk/1.2.0-dev
#define JK_VERSION (((1) 16) + ((2) 8) +
(0))
+++
Any comments? - Otherwise I will commit it tomorrow -
Decimal fields might be more appropriate to the ranges of numbers
expected, and I think Henri suggested an additional field for alpha,
beta etc.
I have VERISRELEASE to mark that it is a developement version, I am not sure we
need the beta number. I would prefer to do it like httpd.
But will this be ok?
mod_jk/1.2.0-beta-01 (for the first beta)
mod_jk/1.2.0 (for the release version).
How about
#define JK_DEV 0
#define JK_ALPHA1
#define JK_BETA 2
#define JK_RELEASE 99
#define JK_MKVER(major, minor, sequence, type) \
((major) * 100 + (minor) * 1 + (sequence) * 100 + (type))
#define JK_VERSION JK_MKVER(1, 2, 0, JK_DEV)
What about:
#ifdef RELEASE
#define JK_VERSION JK_MKVER(1, 2, 0, 99)
#else
#define JK_VERSION JK_MKVER(1, 2, 0, JK_BETA)
Hex is a copy + paste from Linux sources. Dec is more easy? - No problem - But I
like to write 0x010200 and 0x110200 it is easy to see than 10200 and 110200.
Cheers
Jean-frederic
Andy Armstrong wrote:
jean-frederic clere wrote:
[snip]
I'm categorically /not/ suggesting moving anything protocol specific
into the Domino connector, but the interface to the protocol code is
changing over time -- extra fields are being added and so on. I want the
Domino code to work with both the current jk stuff and the legacy 3.2
stuff is all.
Yep, that is because it is a developement version ;-)
Yes, I got that ;-)
Maybe a specific example will explain what I'm talking about. Here's a
bit of code that handles parsing the SSL keysize and passing it to the
jk stuff. The field ssl_key_size wasn't available until recently so the
I have to cope with that case too. Surely that isn't too evil is it?
#if FOR_TOMCAT = TOMCAT400
/* Read the variable into a dummy variable: we do this for the
side
* effect of reading it into workBuf.
*/
GETVARIABLEINT(HTTPS_KEYSIZE, dummy, 0);
if (workBuf[0] == '[')
s-ssl_key_size = atoi(workBuf+1);
#else
(void) dummy;
#endif
Ok, I will put this version information in a commun include file named
version.h. (On Monday!).
Of course we will to have to document our internal API so that for each version
of mod_jk the connectors could know the parameters and the structures used by
the version.
Thanks Jean. I don't think the documentation burden necessarily
increases that much. I expect most people writing a new connector to
start with the source of an existing one -- I certainly did -- that
pretty much documents everything you need to know. Perhaps it would be
enough to nominate one connector (mod_jk I guess) as 'state of the art'
and direct connector implementors to it.
--
Andy Armstrong, Tagish
dnl
dnl Process this file with autoconf to produce a configure script
dnl
AC_REVISION($Id: configure.in,v 1.5 2001/06/14 14:38:13 jfclere Exp $)dnl
AC_PREREQ(2.13)
AC_INIT(common/jk_ajp13.h)
AC_CONFIG_AUX_DIR(scripts/build/unix)
dnl package and version.
PACKAGE=mod_jk
VERMAJOR=1
VERMINOR=2
VERFIX=0
dnl set VERISRELEASE to 1 when release (do not forget to commit!)
VERISRELEASE=0
VERSION=${VERMAJOR}.${VERMINOR}.${VERFIX}
AM_INIT_AUTOMAKE(${PACKAGE}, ${VERSION})
dnl AM_PROG_LIBTOOL often causes problems.
dnl I have solved them once using aclocal --acdir=/usr/local/share/aclocal/
AM_PROG_LIBTOOL
AC_PROG_CC
AC_PROG_LD
AC_PATH_PROG(TEST,test,$PATH)dnl
AC_SUBST(TEST)
AC_PATH_PROG(RM,rm,$PATH)dnl
AC_SUBST(RM)
AC_PATH_PROG(GREP,grep,$PATH)dnl
AC_SUBST(GREP)
AC_PATH_PROG(ECHO,echo,echo,$PATH)dnl
AC_SUBST(ECHO)
AC_PATH_PROG(SED,sed,$PATH)dnl
AC_SUBST(SED)
AC_PATH_PROG(CP,cp,$PATH)dnl
AC_SUBST(CP)
AC_PATH_PROG(MKDIR,mkdir,$PATH)dnl
AC_SUBST(MKDIR)
dnl prepare the string and value for mod_jk version logic
JK_EXPOSED_VERSION=${PACKAGE}/${VERSION}
if ${TEST} ${VERISRELEASE} -eq 0 ; then
JK_EXPOSED_VERSION=${JK_EXPOSED_VERSION}-dev
fi
AC_SUBST(JK_EXPOSED_VERSION)
AC_SUBST(PACKAGE)
AC_SUBST(VERSION)
AC_SUBST(VERMAJOR)
AC_SUBST(VERMINOR)
AC_SUBST(VERFIX)
WEBSERVER=
apache_dir=
apache_include=
APXS=apxs
AC_ARG_WITH(apxs,
[ --with-apxs[=FILE] Build shared Apache module. FILE is the optional
pathname to the apxs tool; defaults to finding
apxs in
Re: #define JK_VERSION in j-t-c (doesn't exist)
jean-frederic clere wrote: Decimal fields might be more appropriate to the ranges of numbers expected, and I think Henri suggested an additional field for alpha, beta etc. I have VERISRELEASE to mark that it is a developement version, I am not sure we need the beta number. I would prefer to do it like httpd. But will this be ok? mod_jk/1.2.0-beta-01 (for the first beta) mod_jk/1.2.0 (for the release version). How about #define JK_DEV 0 #define JK_ALPHA1 #define JK_BETA 2 #define JK_RELEASE 99 #define JK_MKVER(major, minor, sequence, type) \ ((major) * 100 + (minor) * 1 + (sequence) * 100 + (type)) #define JK_VERSION JK_MKVER(1, 2, 0, JK_DEV) What about: #ifdef RELEASE #define JK_VERSION JK_MKVER(1, 2, 0, 99) #else #define JK_VERSION JK_MKVER(1, 2, 0, JK_BETA) Hex is a copy + paste from Linux sources. Dec is more easy? - No problem - But I like to write 0x010200 and 0x110200 it is easy to see than 10200 and 110200. Fine, +1 ;-) -- Andy Armstrong, Tagish
RE: #define JK_VERSION in j-t-c (doesn't exist)
I have prepared a patch for configure.in to generate
JK_EXPOSED_VERSION and
JK_VERSION.
The result is a file named common/version.h:
+++
#define JK_EXPOSED_VERSION mod_jk/1.2.0-dev
#define JK_VERSION (((1) 16) + ((2) 8) +
(0))
+++
Any comments? - Otherwise I will commit it tomorrow -
Decimal fields might be more appropriate to the ranges of numbers
expected, and I think Henri suggested an additional field for alpha,
beta etc.
I have VERISRELEASE to mark that it is a developement version,
I am not sure we
need the beta number. I would prefer to do it like httpd.
But will this be ok?
mod_jk/1.2.0-beta-01 (for the first beta)
mod_jk/1.2.0 (for the release version).
+1
How about
#define JK_DEV 0
#define JK_ALPHA1
#define JK_BETA 2
#define JK_RELEASE 99
#define JK_MKVER(major, minor, sequence, type) \
((major) * 100 + (minor) * 1 + (sequence) * 100 + (type))
#define JK_VERSION JK_MKVER(1, 2, 0, JK_DEV)
What about:
#ifdef RELEASE
#define JK_VERSION JK_MKVER(1, 2, 0, 99)
#else
#define JK_VERSION JK_MKVER(1, 2, 0, JK_BETA)
Hex is a copy + paste from Linux sources. Dec is more easy? -
No problem - But I
like to write 0x010200 and 0x110200 it is easy to see than
10200 and 110200.
Cheers
Jean-frederic
Andy Armstrong wrote:
jean-frederic clere wrote:
[snip]
I'm categorically /not/ suggesting moving anything
protocol specific
into the Domino connector, but the interface to the
protocol code is
changing over time -- extra fields are being added
and so on. I want the
Domino code to work with both the current jk stuff
and the legacy 3.2
stuff is all.
Yep, that is because it is a developement version ;-)
Yes, I got that ;-)
Maybe a specific example will explain what I'm
talking about. Here's a
bit of code that handles parsing the SSL keysize and
passing it to the
jk stuff. The field ssl_key_size wasn't available
until recently so the
I have to cope with that case too. Surely that isn't
too evil is it?
#if FOR_TOMCAT = TOMCAT400
/* Read the variable into a dummy variable:
we do this for the
side
* effect of reading it into workBuf.
*/
GETVARIABLEINT(HTTPS_KEYSIZE, dummy, 0);
if (workBuf[0] == '[')
s-ssl_key_size = atoi(workBuf+1);
#else
(void) dummy;
#endif
Ok, I will put this version information in a commun
include file named
version.h. (On Monday!).
Of course we will to have to document our internal API
so that for each version
of mod_jk the connectors could know the parameters and
the structures used by
the version.
Thanks Jean. I don't think the documentation burden necessarily
increases that much. I expect most people writing a new
connector to
start with the source of an existing one -- I certainly
did -- that
pretty much documents everything you need to know.
Perhaps it would be
enough to nominate one connector (mod_jk I guess) as
'state of the art'
and direct connector implementors to it.
--
Andy Armstrong, Tagish
---
-
dnl
dnl Process this file with autoconf to produce a configure script
dnl
AC_REVISION($Id: configure.in,v 1.5 2001/06/14 14:38:13
jfclere Exp $)dnl
AC_PREREQ(2.13)
AC_INIT(common/jk_ajp13.h)
AC_CONFIG_AUX_DIR(scripts/build/unix)
dnl package and version.
PACKAGE=mod_jk
VERMAJOR=1
VERMINOR=2
VERFIX=0
dnl set VERISRELEASE to 1 when release (do not forget to commit!)
VERISRELEASE=0
VERSION=${VERMAJOR}.${VERMINOR}.${VERFIX}
AM_INIT_AUTOMAKE(${PACKAGE}, ${VERSION})
dnl AM_PROG_LIBTOOL often causes problems.
dnl I have solved them once using aclocal
--acdir=/usr/local/share/aclocal/
AM_PROG_LIBTOOL
AC_PROG_CC
AC_PROG_LD
AC_PATH_PROG(TEST,test,$PATH)dnl
AC_SUBST(TEST)
AC_PATH_PROG(RM,rm,$PATH)dnl
AC_SUBST(RM)
AC_PATH_PROG(GREP,grep,$PATH)dnl
AC_SUBST(GREP)
AC_PATH_PROG(ECHO,echo,echo,$PATH)dnl
AC_SUBST(ECHO)
AC_PATH_PROG(SED,sed,$PATH)dnl
AC_SUBST(SED)
AC_PATH_PROG(CP,cp,$PATH)dnl
AC_SUBST(CP)
AC_PATH_PROG(MKDIR,mkdir,$PATH)dnl
AC_SUBST(MKDIR)
dnl prepare the string and value for mod_jk version logic
JK_EXPOSED_VERSION=${PACKAGE}/${VERSION}
if ${TEST} ${VERISRELEASE} -eq 0 ; then
JK_EXPOSED_VERSION=${JK_EXPOSED_VERSION}-dev
fi
AC_SUBST(JK_EXPOSED_VERSION)
AC_SUBST(PACKAGE)
AC_SUBST(VERSION)
AC_SUBST(VERMAJOR)
AC_SUBST(VERMINOR)
AC_SUBST(VERFIX)
WEBSERVER=
apache_dir=
apache_include=
APXS=apxs
AC_ARG_WITH(apxs,
[ --with-apxs[=FILE] Build shared Apache module.
FILE is the optional
pathname to the apxs tool;
defaults to finding
apxs in your PATH.],
[
case
Re: #define JK_VERSION in j-t-c (doesn't exist)
Hi,
I have prepared a patch for configure.in to generate JK_EXPOSED_VERSION and
JK_VERSION.
The result is a file named common/version.h:
+++
#define JK_EXPOSED_VERSION mod_jk/1.2.0-dev
#define JK_VERSION (((1) 16) + ((2) 8) +
(0))
+++
Any comments? - Otherwise I will commit it tomorrow -
Cheers
Jean-frederic
Andy Armstrong wrote:
jean-frederic clere wrote:
[snip]
I'm categorically /not/ suggesting moving anything protocol specific
into the Domino connector, but the interface to the protocol code is
changing over time -- extra fields are being added and so on. I want the
Domino code to work with both the current jk stuff and the legacy 3.2
stuff is all.
Yep, that is because it is a developement version ;-)
Yes, I got that ;-)
Maybe a specific example will explain what I'm talking about. Here's a
bit of code that handles parsing the SSL keysize and passing it to the
jk stuff. The field ssl_key_size wasn't available until recently so the
I have to cope with that case too. Surely that isn't too evil is it?
#if FOR_TOMCAT = TOMCAT400
/* Read the variable into a dummy variable: we do this for the
side
* effect of reading it into workBuf.
*/
GETVARIABLEINT(HTTPS_KEYSIZE, dummy, 0);
if (workBuf[0] == '[')
s-ssl_key_size = atoi(workBuf+1);
#else
(void) dummy;
#endif
Ok, I will put this version information in a commun include file named
version.h. (On Monday!).
Of course we will to have to document our internal API so that for each version
of mod_jk the connectors could know the parameters and the structures used by
the version.
Thanks Jean. I don't think the documentation burden necessarily
increases that much. I expect most people writing a new connector to
start with the source of an existing one -- I certainly did -- that
pretty much documents everything you need to know. Perhaps it would be
enough to nominate one connector (mod_jk I guess) as 'state of the art'
and direct connector implementors to it.
--
Andy Armstrong, Tagish
dnl
dnl Process this file with autoconf to produce a configure script
dnl
AC_REVISION($Id: configure.in,v 1.5 2001/06/14 14:38:13 jfclere Exp $)dnl
AC_PREREQ(2.13)
AC_INIT(common/jk_ajp13.h)
AC_CONFIG_AUX_DIR(scripts/build/unix)
dnl package and version.
PACKAGE=mod_jk
VERMAJOR=1
VERMINOR=2
VERFIX=0
dnl set VERISRELEASE to 1 when release (do not forget to commit!)
VERISRELEASE=0
VERSION=${VERMAJOR}.${VERMINOR}.${VERFIX}
AM_INIT_AUTOMAKE(${PACKAGE}, ${VERSION})
dnl AM_PROG_LIBTOOL often causes problems.
dnl I have solved them once using aclocal --acdir=/usr/local/share/aclocal/
AM_PROG_LIBTOOL
AC_PROG_CC
AC_PROG_LD
AC_PATH_PROG(TEST,test,$PATH)dnl
AC_SUBST(TEST)
AC_PATH_PROG(RM,rm,$PATH)dnl
AC_SUBST(RM)
AC_PATH_PROG(GREP,grep,$PATH)dnl
AC_SUBST(GREP)
AC_PATH_PROG(ECHO,echo,echo,$PATH)dnl
AC_SUBST(ECHO)
AC_PATH_PROG(SED,sed,$PATH)dnl
AC_SUBST(SED)
AC_PATH_PROG(CP,cp,$PATH)dnl
AC_SUBST(CP)
AC_PATH_PROG(MKDIR,mkdir,$PATH)dnl
AC_SUBST(MKDIR)
dnl prepare the string and value for mod_jk version logic
JK_EXPOSED_VERSION=${PACKAGE}/${VERSION}
if ${TEST} ${VERISRELEASE} -eq 0 ; then
JK_EXPOSED_VERSION=${JK_EXPOSED_VERSION}-dev
fi
AC_SUBST(JK_EXPOSED_VERSION)
AC_SUBST(PACKAGE)
AC_SUBST(VERSION)
AC_SUBST(VERMAJOR)
AC_SUBST(VERMINOR)
AC_SUBST(VERFIX)
WEBSERVER=
apache_dir=
apache_include=
APXS=apxs
AC_ARG_WITH(apxs,
[ --with-apxs[=FILE] Build shared Apache module. FILE is the optional
pathname to the apxs tool; defaults to finding
apxs in your PATH.],
[
case ${withval} in
y | yes | true) find_apxs=true ;;
n | no | false) find_apxs=false ;;
*) find_apxs=false ;;
esac
if ${TEST} ${find_apxs} ; then
AC_MSG_RESULT([need to check for Perl first, apxs depends on it...])
AC_PATH_PROG(PERL,perl,$PATH)dnl
if ${TEST} ${find_apxs} ; then
APXS=${withval}
else
AC_PATH_PROG(APXS,apxs,$PATH)dnl
fi
if ${TEST} -n ${APXS} ; then
dnl Seems that we have it, but have to check if it is OK first
if ${TEST} ! -x ${APXS} ; then
AC_MSG_ERROR(Invalid location for apxs: '${APXS}')
fi
$APXS -q PREFIX /dev/null 2/dev/null || apxs_support=false
if ${TEST} ${apxs_support} = false ; then
AC_MSG_RESULT(could not find apxs)
AC_MSG_ERROR(You must specify a valid --with-apxs path)
fi
dnl test apache version
$RM -rf test
$APXS -n test -g
APA=`grep STANDARD20 test/mod_test.c`
$RM -rf test
if ${TEST} -z $APA ; then
WEBSERVER=apache-1.3
else
Re: #define JK_VERSION in j-t-c (doesn't exist)
jean-frederic clere wrote:
Hi,
I have prepared a patch for configure.in to generate JK_EXPOSED_VERSION and
JK_VERSION.
The result is a file named common/version.h:
+++
#define JK_EXPOSED_VERSION mod_jk/1.2.0-dev
#define JK_VERSION (((1) 16) + ((2) 8) +
(0))
+++
Any comments? - Otherwise I will commit it tomorrow -
Decimal fields might be more appropriate to the ranges of numbers
expected, and I think Henri suggested an additional field for alpha,
beta etc.
How about
#define JK_DEV 0
#define JK_ALPHA1
#define JK_BETA 2
#define JK_RELEASE 99
#define JK_MKVER(major, minor, sequence, type) \
((major) * 100 + (minor) * 1 + (sequence) * 100 + (type))
#define JK_VERSION JK_MKVER(1, 2, 0, JK_DEV)
Cheers
Jean-frederic
Andy Armstrong wrote:
jean-frederic clere wrote:
[snip]
I'm categorically /not/ suggesting moving anything protocol specific
into the Domino connector, but the interface to the protocol code is
changing over time -- extra fields are being added and so on. I want the
Domino code to work with both the current jk stuff and the legacy 3.2
stuff is all.
Yep, that is because it is a developement version ;-)
Yes, I got that ;-)
Maybe a specific example will explain what I'm talking about. Here's a
bit of code that handles parsing the SSL keysize and passing it to the
jk stuff. The field ssl_key_size wasn't available until recently so the
I have to cope with that case too. Surely that isn't too evil is it?
#if FOR_TOMCAT = TOMCAT400
/* Read the variable into a dummy variable: we do this for the
side
* effect of reading it into workBuf.
*/
GETVARIABLEINT(HTTPS_KEYSIZE, dummy, 0);
if (workBuf[0] == '[')
s-ssl_key_size = atoi(workBuf+1);
#else
(void) dummy;
#endif
Ok, I will put this version information in a commun include file named
version.h. (On Monday!).
Of course we will to have to document our internal API so that for each version
of mod_jk the connectors could know the parameters and the structures used by
the version.
Thanks Jean. I don't think the documentation burden necessarily
increases that much. I expect most people writing a new connector to
start with the source of an existing one -- I certainly did -- that
pretty much documents everything you need to know. Perhaps it would be
enough to nominate one connector (mod_jk I guess) as 'state of the art'
and direct connector implementors to it.
--
Andy Armstrong, Tagish
dnl
dnl Process this file with autoconf to produce a configure script
dnl
AC_REVISION($Id: configure.in,v 1.5 2001/06/14 14:38:13 jfclere Exp $)dnl
AC_PREREQ(2.13)
AC_INIT(common/jk_ajp13.h)
AC_CONFIG_AUX_DIR(scripts/build/unix)
dnl package and version.
PACKAGE=mod_jk
VERMAJOR=1
VERMINOR=2
VERFIX=0
dnl set VERISRELEASE to 1 when release (do not forget to commit!)
VERISRELEASE=0
VERSION=${VERMAJOR}.${VERMINOR}.${VERFIX}
AM_INIT_AUTOMAKE(${PACKAGE}, ${VERSION})
dnl AM_PROG_LIBTOOL often causes problems.
dnl I have solved them once using aclocal --acdir=/usr/local/share/aclocal/
AM_PROG_LIBTOOL
AC_PROG_CC
AC_PROG_LD
AC_PATH_PROG(TEST,test,$PATH)dnl
AC_SUBST(TEST)
AC_PATH_PROG(RM,rm,$PATH)dnl
AC_SUBST(RM)
AC_PATH_PROG(GREP,grep,$PATH)dnl
AC_SUBST(GREP)
AC_PATH_PROG(ECHO,echo,echo,$PATH)dnl
AC_SUBST(ECHO)
AC_PATH_PROG(SED,sed,$PATH)dnl
AC_SUBST(SED)
AC_PATH_PROG(CP,cp,$PATH)dnl
AC_SUBST(CP)
AC_PATH_PROG(MKDIR,mkdir,$PATH)dnl
AC_SUBST(MKDIR)
dnl prepare the string and value for mod_jk version logic
JK_EXPOSED_VERSION=${PACKAGE}/${VERSION}
if ${TEST} ${VERISRELEASE} -eq 0 ; then
JK_EXPOSED_VERSION=${JK_EXPOSED_VERSION}-dev
fi
AC_SUBST(JK_EXPOSED_VERSION)
AC_SUBST(PACKAGE)
AC_SUBST(VERSION)
AC_SUBST(VERMAJOR)
AC_SUBST(VERMINOR)
AC_SUBST(VERFIX)
WEBSERVER=
apache_dir=
apache_include=
APXS=apxs
AC_ARG_WITH(apxs,
[ --with-apxs[=FILE] Build shared Apache module. FILE is the optional
pathname to the apxs tool; defaults to finding
apxs in your PATH.],
[
case ${withval} in
y | yes | true) find_apxs=true ;;
n | no | false) find_apxs=false ;;
*) find_apxs=false ;;
esac
if ${TEST} ${find_apxs} ; then
AC_MSG_RESULT([need to check for Perl first, apxs depends on it...])
AC_PATH_PROG(PERL,perl,$PATH)dnl
if ${TEST} ${find_apxs} ; then
APXS=${withval}
else
AC_PATH_PROG(APXS,apxs,$PATH)dnl
fi
if ${TEST} -n ${APXS} ; then
dnl Seems that we have it, but have to check if it is OK first
if ${TEST} ! -x ${APXS} ; then
AC_MSG_ERROR(Invalid location for
Re: #define JK_VERSION in j-t-c (doesn't exist)
Andy Armstrong wrote: jean-frederic clere wrote: [snip] But it makes only sense if someone want to use a new module with a old core code. That means a protocol developed in 1.3.x could be used in 1.2.x. Well could be nice, but difficult to handle. Backport a new protocol to an old mod_jk! It makes sense for the kind of code I'm writing for the Domino connector though. The source supports/will support the latest protocols, but should still be buildable in cases where those protocols aren't available. The protocols should be in one place, the interface to a WebServer in another place. Domino is a WebServer so you should not care about the protocols but just provide the calls the core part needs, otherwise we will have a huge quantity of code copied in several places (Hard for maintenance). These version things should be only when making a backport of something new to a old version or when adding a code that cannot work in an old version. I'm obviously missing the point here: in common with other connectors the Domino connector makes calls /to/ the common jk code -- the external interface it provides faces the other way -- towards Domino. That means that as the interface to the jk code changes the Domino connector has to change too. I want to be able to build a Domino connector for Tomcat 3.2 (for example) and a Domino connector for the current bleeding edge code from the same source base. At the moment I can do that, but it involves me having switches that are local to my source tree to select features suitable for the current jk version. What I'm proposing is that the version information should be exposed by the common jk code for /all/ connectors to use. I'm categorically /not/ suggesting moving anything protocol specific into the Domino connector, but the interface to the protocol code is changing over time -- extra fields are being added and so on. I want the Domino code to work with both the current jk stuff and the legacy 3.2 stuff is all. Yep, that is because it is a developement version ;-) Maybe a specific example will explain what I'm talking about. Here's a bit of code that handles parsing the SSL keysize and passing it to the jk stuff. The field ssl_key_size wasn't available until recently so the I have to cope with that case too. Surely that isn't too evil is it? #if FOR_TOMCAT = TOMCAT400 /* Read the variable into a dummy variable: we do this for the side * effect of reading it into workBuf. */ GETVARIABLEINT(HTTPS_KEYSIZE, dummy, 0); if (workBuf[0] == '[') s-ssl_key_size = atoi(workBuf+1); #else (void) dummy; #endif Ok, I will put this version information in a commun include file named version.h. (On Monday!). Of course we will to have to document our internal API so that for each version of mod_jk the connectors could know the parameters and the structures used by the version. -- Andy Armstrong, Tagish
Re: #define JK_VERSION in j-t-c (doesn't exist)
jean-frederic clere wrote: [snip] I'm categorically /not/ suggesting moving anything protocol specific into the Domino connector, but the interface to the protocol code is changing over time -- extra fields are being added and so on. I want the Domino code to work with both the current jk stuff and the legacy 3.2 stuff is all. Yep, that is because it is a developement version ;-) Yes, I got that ;-) Maybe a specific example will explain what I'm talking about. Here's a bit of code that handles parsing the SSL keysize and passing it to the jk stuff. The field ssl_key_size wasn't available until recently so the I have to cope with that case too. Surely that isn't too evil is it? #if FOR_TOMCAT = TOMCAT400 /* Read the variable into a dummy variable: we do this for the side * effect of reading it into workBuf. */ GETVARIABLEINT(HTTPS_KEYSIZE, dummy, 0); if (workBuf[0] == '[') s-ssl_key_size = atoi(workBuf+1); #else (void) dummy; #endif Ok, I will put this version information in a commun include file named version.h. (On Monday!). Of course we will to have to document our internal API so that for each version of mod_jk the connectors could know the parameters and the structures used by the version. Thanks Jean. I don't think the documentation burden necessarily increases that much. I expect most people writing a new connector to start with the source of an existing one -- I certainly did -- that pretty much documents everything you need to know. Perhaps it would be enough to nominate one connector (mod_jk I guess) as 'state of the art' and direct connector implementors to it. -- Andy Armstrong, Tagish
Re: #define JK_VERSION in j-t-c (doesn't exist)
GOMEZ Henri wrote: [snip explanation of versions] the jk in j-t-c, is an evolution of mod_jk found in Tomcat 3.3. We add more features and entry points but keep compatibility with actual Tomcat 3.2/3.3/4.0 (with its ajp13 connector). Ah. So it's really the jk version I need then so people can build the connector whether they have the latest j-t-c source or something like the Tomcat 3.2 source distro. It would be useful to have an API version number somewhere. How about #define JK_EXPOSED_VERSION (mod_jk/1.1a1) == exists now #define JK_VERSION 1 == proposed in jk_global.h? There should be some defined mapping between the version string and the number too I suppose. -- Andy Armstrong, Tagish
RE: #define JK_VERSION in j-t-c (doesn't exist)
Ah. So it's really the jk version I need then so people can build the connector whether they have the latest j-t-c source or something like the Tomcat 3.2 source distro. It would be useful to have an API version number somewhere. * mod_jk in TC 3.2 is +/- frozen (only major bugs fixe) : we could version it : 1.0.x * mod_jk in TC 3.3 is not frozen but there will be no major feature added : we could version it : 1.1.x * mod_jk in J-T-C will continue its evolution : we could version it : 1.2.x How about #define JK_EXPOSED_VERSION (mod_jk/1.1a1) == exists now #define JK_VERSION 1 == proposed in jk_global.h? There should be some defined mapping between the version string and the number too I suppose. May we use something like Apache 2.0 : #define JK_MODULE_BASEPRODUCT mod_jk #define JK_MODULE_BASEREVISION 1.2.0-dev #define JK_MODULE_BASEVERSION JK_MODULE_BASEPRODUCT / JK_MODULE_BASEREVISION #define JK_EXPOSED_VERSION JK_MODULE_BASEVERSION But what do you means by users building from j-t-c or 3.2/3.3 ?
Re: #define JK_VERSION in j-t-c (doesn't exist)
GOMEZ Henri wrote: Ah. So it's really the jk version I need then so people can build the connector whether they have the latest j-t-c source or something like the Tomcat 3.2 source distro. It would be useful to have an API version number somewhere. * mod_jk in TC 3.2 is +/- frozen (only major bugs fixe) : we could version it : 1.0.x * mod_jk in TC 3.3 is not frozen but there will be no major feature added : we could version it : 1.1.x * mod_jk in J-T-C will continue its evolution : we could version it : 1.2.x How about #define JK_EXPOSED_VERSION (mod_jk/1.1a1) == exists now #define JK_VERSION 1 == proposed in jk_global.h? There should be some defined mapping between the version string and the number too I suppose. May we use something like Apache 2.0 : #define JK_MODULE_BASEPRODUCT mod_jk #define JK_MODULE_BASEREVISION 1.2.0-dev #define JK_MODULE_BASEVERSION JK_MODULE_BASEPRODUCT / JK_MODULE_BASEREVISION #define JK_EXPOSED_VERSION JK_MODULE_BASEVERSION OK, but I was thinking of something numeric so it could easily be tested at compile time, for example #if defined(JK_VERSION) JK_VERSION = 1 ... newer stuff ... #endif Strings are fine for user readable versioning, but hard to test at compile time. But what do you means by users building from j-t-c or 3.2/3.3 ? I think the two groups of people who will be interested in the source for this (and other) connectors are: a) People using one of the stable releases and wanting to use it with the web server of their choice. They will have downloaded the appropriate Tomcat source and may have grabbed the connector source from either free.tagish.net or as part of the latest j-t-c release. b) People working on the cutting edge j-t-c stuff who will be using the latest versions of everything. Ideally I'd like the source for the connector to be the same in either case with conditional stuff to include functionality required by later jk versions. I assume this would be useful for other connector developers too. As to the mapping between textual versions and numeric one way to do it would be to reserve a certain number of digits for each part of the version string so you'd have something like this: 1.0.1 == 10001 12.3.6 == 120306 which has the advantage that the numerical representation increases monotonically and linearly with increases in textual version. -- Andy Armstrong, Tagish
Re: #define JK_VERSION in j-t-c (doesn't exist)
Andy Armstrong wrote: GOMEZ Henri wrote: Ah. So it's really the jk version I need then so people can build the connector whether they have the latest j-t-c source or something like the Tomcat 3.2 source distro. It would be useful to have an API version number somewhere. * mod_jk in TC 3.2 is +/- frozen (only major bugs fixe) : we could version it : 1.0.x * mod_jk in TC 3.3 is not frozen but there will be no major feature added : we could version it : 1.1.x * mod_jk in J-T-C will continue its evolution : we could version it : 1.2.x How about #define JK_EXPOSED_VERSION (mod_jk/1.1a1) == exists now #define JK_VERSION 1 == proposed in jk_global.h? There should be some defined mapping between the version string and the number too I suppose. May we use something like Apache 2.0 : #define JK_MODULE_BASEPRODUCT mod_jk #define JK_MODULE_BASEREVISION 1.2.0-dev #define JK_MODULE_BASEVERSION JK_MODULE_BASEPRODUCT / JK_MODULE_BASEREVISION #define JK_EXPOSED_VERSION JK_MODULE_BASEVERSION These things should in a version.h.in file and the version.h file should be included when needed. That some configure related thing. I have already PACKAGE and VERSION prepare for that. OK, but I was thinking of something numeric so it could easily be tested at compile time, for example #if defined(JK_VERSION) JK_VERSION = 1 ... newer stuff ... #endif Like it is in the Linux Kernel (LINUX_VERSION_CODE) ;-) Strings are fine for user readable versioning, but hard to test at compile time. But it makes only sense if someone want to use a new module with a old core code. That means a protocol developed in 1.3.x could be used in 1.2.x. Well could be nice, but difficult to handle. Backport a new protocol to an old mod_jk! But what do you means by users building from j-t-c or 3.2/3.3 ? I think the two groups of people who will be interested in the source for this (and other) connectors are: a) People using one of the stable releases and wanting to use it with the web server of their choice. They will have downloaded the appropriate Tomcat source and may have grabbed the connector source from either free.tagish.net or as part of the latest j-t-c release. b) People working on the cutting edge j-t-c stuff who will be using the latest versions of everything. ? That is CVS ? Ideally I'd like the source for the connector to be the same in either case with conditional stuff to include functionality required by later jk versions. I assume this would be useful for other connector developers too. As to the mapping between textual versions and numeric one way to do it would be to reserve a certain number of digits for each part of the version string so you'd have something like this: 1.0.1 == 10001 12.3.6 == 120306 ;-) which has the advantage that the numerical representation increases monotonically and linearly with increases in textual version. -- Andy Armstrong, Tagish
Re: #define JK_VERSION in j-t-c (doesn't exist)
jean-frederic clere wrote: [snip] #if defined(JK_VERSION) JK_VERSION = 1 ... newer stuff ... #endif Like it is in the Linux Kernel (LINUX_VERSION_CODE) ;-) Yup. But it makes only sense if someone want to use a new module with a old core code. That means a protocol developed in 1.3.x could be used in 1.2.x. Well could be nice, but difficult to handle. Backport a new protocol to an old mod_jk! It makes sense for the kind of code I'm writing for the Domino connector though. The source supports/will support the latest protocols, but should still be buildable in cases where those protocols aren't available. At the moment I'm doing that with switches in a header that's local to the Domino connector, but it would be better if it was part of the jk/common source tree. b) People working on the cutting edge j-t-c stuff who will be using the latest versions of everything. ? That is CVS ? Yes. -- Andy Armstrong, Tagish
RE: #define JK_VERSION in j-t-c (doesn't exist)
OK, but I was thinking of something numeric so it could easily be tested at compile time, for example #if defined(JK_VERSION) JK_VERSION = 1 ... newer stuff ... #endif Strings are fine for user readable versioning, but hard to test at compile time. I understand better there :=) Instead of avoid #ifdef/#endif in all the sources, we'll use the CVS and make release. People who want STABLE release, will grab a STABLE SNAPSHOT. JTC developpers will continue from CVS. b) People working on the cutting edge j-t-c stuff who will be using the latest versions of everything. Ideally I'd like the source for the connector to be the same in either case with conditional stuff to include functionality required by later jk versions. I assume this would be useful for other connector developers too. Let be carefull here since having too much #ifdef/#endif will 'pollute' the code. I'd like better have the EXPERIMENTAL switch as used As to the mapping between textual versions and numeric one way to do it would be to reserve a certain number of digits for each part of the version string so you'd have something like this: 1.0.1 == 10001 12.3.6 == 120306 Ok
Re: #define JK_VERSION in j-t-c (doesn't exist)
GOMEZ Henri wrote: OK, but I was thinking of something numeric so it could easily be tested at compile time, for example #if defined(JK_VERSION) JK_VERSION = 1 ... newer stuff ... #endif Strings are fine for user readable versioning, but hard to test at compile time. I understand better there :=) Instead of avoid #ifdef/#endif in all the sources, we'll use the CVS and make release. People who want STABLE release, will grab a STABLE SNAPSHOT. JTC developpers will continue from CVS. OK, I get that but the Domino connector (in particular) is fairly immature -- it's quite likely that bugs will be found that would affect both people using stable Tomcat releases and those on the development track -- it would nice to fix any such bugs in a single source file. I suppose my requirement is unusual in that the Domino connector is available both as a retrofit for current Tomcat releases and as part of the j-t-c development track -- most other connector code will have been frozen as part of the relevant Tomcat release. If the versioning information isn't useful to other people I'll happily sort my particular requirements some other way, but I'm still inclined to use #if/#endif with some suitable swicth to bracket code that's only usable with the latest jk code. b) People working on the cutting edge j-t-c stuff who will be using the latest versions of everything. Ideally I'd like the source for the connector to be the same in either case with conditional stuff to include functionality required by later jk versions. I assume this would be useful for other connector developers too. Let be carefull here since having too much #ifdef/#endif will 'pollute' the code. I'd like better have the EXPERIMENTAL switch as used I take the point about excessive #ifdef/#endif use -- I've seen plenty of C source code rendered practically unreadable in this way. I didn't know about the EXPERIMENTAL switch. What are the semantics of that? As to the mapping between textual versions and numeric one way to do it would be to reserve a certain number of digits for each part of the version string so you'd have something like this: 1.0.1 == 10001 12.3.6 == 120306 Ok -- Andy Armstrong, Tagish
RE: #define JK_VERSION in j-t-c (doesn't exist)
OK, I get that but the Domino connector (in particular) is fairly immature -- it's quite likely that bugs will be found that would affect both people using stable Tomcat releases and those on the development track -- it would nice to fix any such bugs in a single source file. The Domino connector will be marked experimental as long you didn't find it stable. Don't worry Apache 1.3 users won't compile use Domino connector code :) I suppose my requirement is unusual in that the Domino connector is available both as a retrofit for current Tomcat releases and as part of the j-t-c development track -- most other connector code will have been frozen as part of the relevant Tomcat release. If the versioning information isn't useful to other people I'll happily sort my particular requirements some other way, but I'm still inclined to use #if/#endif with some suitable swicth to bracket code that's only usable with the latest jk code. 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. We're far from a release, we have to finish ajp14 in mod_jk, ease installation of warp under Apache 1.3/2.0 (rpm/apr...). And Coyote as a specialised HTTP ORB, is an excellent area of reflexion about request/services in the HTTP/WWW world. So Domino could be alpha or beta quality, it should be in all j-t-c release, millenium, beta, final
Re: #define JK_VERSION in j-t-c (doesn't exist)
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
RE: #define JK_VERSION in j-t-c (doesn't exist)
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. We'll keep the idea of version number, cf JF could you add it in version.h. ? +/- how Apache http team use === /* Numeric release version identifier: MMNNFFRBB: major minor fix final beta * Always increases along the same track as the source branch. * For example, Apache 1.4.2 would be '10402100', 2.5b7 would be '2057'. */ #define APACHE_RELEASE 10320100 === #define JK_MODULE_RELEASE 1021 (1.2.0-b1 ) 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? Yep 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. Could you develop ?
Re: #define JK_VERSION in j-t-c (doesn't exist)
GOMEZ Henri wrote: [snip] 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. Could you develop ? D'you mean could I write code that throws a compile time error? If so, it's just #if !defined(JK_MODULE_RELEASE) || JK_MODULE_RELEASE REQUIRED #error You need to have a later of the jk module. See source for details #endif Is that what you meant or were you expecting something more glamorous? -- Andy Armstrong, Tagish
Re: #define JK_VERSION in j-t-c (doesn't exist)
Andy Armstrong wrote: jean-frederic clere wrote: [snip] #if defined(JK_VERSION) JK_VERSION = 1 ... newer stuff ... #endif Like it is in the Linux Kernel (LINUX_VERSION_CODE) ;-) Yup. But it makes only sense if someone want to use a new module with a old core code. That means a protocol developed in 1.3.x could be used in 1.2.x. Well could be nice, but difficult to handle. Backport a new protocol to an old mod_jk! It makes sense for the kind of code I'm writing for the Domino connector though. The source supports/will support the latest protocols, but should still be buildable in cases where those protocols aren't available. The protocols should be in one place, the interface to a WebServer in another place. Domino is a WebServer so you should not care about the protocols but just provide the calls the core part needs, otherwise we will have a huge quantity of code copied in several places (Hard for maintenance). These version things should be only when making a backport of something new to a old version or when adding a code that cannot work in an old version. At the moment I'm doing that with switches in a header that's local to the Domino connector, but it would be better if it was part of the jk/common source tree. b) People working on the cutting edge j-t-c stuff who will be using the latest versions of everything. ? That is CVS ? Yes. -- Andy Armstrong, Tagish
Re: #define JK_VERSION in j-t-c (doesn't exist)
jean-frederic clere wrote: [snip] But it makes only sense if someone want to use a new module with a old core code. That means a protocol developed in 1.3.x could be used in 1.2.x. Well could be nice, but difficult to handle. Backport a new protocol to an old mod_jk! It makes sense for the kind of code I'm writing for the Domino connector though. The source supports/will support the latest protocols, but should still be buildable in cases where those protocols aren't available. The protocols should be in one place, the interface to a WebServer in another place. Domino is a WebServer so you should not care about the protocols but just provide the calls the core part needs, otherwise we will have a huge quantity of code copied in several places (Hard for maintenance). These version things should be only when making a backport of something new to a old version or when adding a code that cannot work in an old version. I'm obviously missing the point here: in common with other connectors the Domino connector makes calls /to/ the common jk code -- the external interface it provides faces the other way -- towards Domino. That means that as the interface to the jk code changes the Domino connector has to change too. I want to be able to build a Domino connector for Tomcat 3.2 (for example) and a Domino connector for the current bleeding edge code from the same source base. At the moment I can do that, but it involves me having switches that are local to my source tree to select features suitable for the current jk version. What I'm proposing is that the version information should be exposed by the common jk code for /all/ connectors to use. I'm categorically /not/ suggesting moving anything protocol specific into the Domino connector, but the interface to the protocol code is changing over time -- extra fields are being added and so on. I want the Domino code to work with both the current jk stuff and the legacy 3.2 stuff is all. Maybe a specific example will explain what I'm talking about. Here's a bit of code that handles parsing the SSL keysize and passing it to the jk stuff. The field ssl_key_size wasn't available until recently so the I have to cope with that case too. Surely that isn't too evil is it? #if FOR_TOMCAT = TOMCAT400 /* Read the variable into a dummy variable: we do this for the side * effect of reading it into workBuf. */ GETVARIABLEINT(HTTPS_KEYSIZE, dummy, 0); if (workBuf[0] == '[') s-ssl_key_size = atoi(workBuf+1); #else (void) dummy; #endif -- Andy Armstrong, Tagish
RE: #define JK_VERSION in j-t-c (doesn't exist)
I'm doing some work on the domino tomcat connector which makes the current version unbuildable for anything T4.0. What's T4.0 ? TC 4.0 ? An important point is that the webserver didn't have to know which servlet-engine is as the remote end. From what I see in your commit : + +#if FOR_TOMCAT = TOMCAT400 +static jk_worker_env_t worker_env; +#endif The worker_env is not dependant on TC 4.0. It was added to let some protocols (currently only AJP14), have more information on the web-server (will be sent to servlet-engine at login time for information and may be action). We also need that for URI autoconf support. After the login phase, we could received a list of URI to be mapped to a worker. In ajp12/ajp13, We just don't use these informations. Consider you're allways in FOR_TOMCAT = TOMCAT400 and remove the #ifdef/#endif It occurred to me that there might be a #define somewhere in the shared jk_* stuff that would give me a version number I could test, but I can't see one. Is there anything there? Should there be? the jk in j-t-c, is an evolution of mod_jk found in Tomcat 3.3. We add more features and entry points but keep compatibility with actual Tomcat 3.2/3.3/4.0 (with its ajp13 connector).
