jean-frederic clere wrote:
>
> 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 m
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 cal
>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_
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
>> > 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
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
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 ((
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))
> +++
> An
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))
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 cur
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
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!
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 wi
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
>> 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
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 l
>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 conne
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
> >c
>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 :
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
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
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 +/- fro
>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
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 c
>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
Hi Folks,
I'm doing some work on the domino tomcat connector which makes the
current version unbuildable for anything < T4.0. 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
26 matches
Mail list logo
