tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jean-frederic clere <jfrederic.cl...@fujitsu-siemens.com>
Subject Re: #define JK_VERSION in j-t-c (doesn't exist)
Date Wed, 20 Jun 2001 17:26:25 GMT
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
Mime
View raw message