Edward Furlong/IE/TLS/PwC is out of the office.

[edward . furlong]

I will be out of the office starting  21/04/2005 and will not return until
23/05/2005.

Please contact my secretary Loreen White on 00 353 1 662 6318 for urgent
assistance.
_
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material.  Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited.   If you received
this in error, please contact the sender and delete the material from any
computer.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Why is ACL judged UNKNOWN_METHOD since jk_ajp_common.c Revision 1.68 ?

[Mladen Turk]

[EMAIL PROTECTED] wrote:
(B> 
(B> You changed implementation of jk_ajp_common.c from Revision 1.67 to Revision  
(B> 1.68.
(B> ACL have been judged UNKNOWN_METHOD since its modification.
(B> Why ?
(B> 
(B
(BBecause I forgot?
(B
(BAnyhow, committed a fix, so it should be in the 1.2.11.
(BThanks for spotting that :).
(B
(BRegards,
(BMladen.
(B
(B-
(BTo unsubscribe, e-mail: [EMAIL PROTECTED]
(BFor additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp_common.c

[mturk]

mturk   2005/04/26 23:38:59

  Modified:jk/native/common jk_ajp_common.c
  Log:
  Added missing ACL method.
  
  Revision  ChangesPath
  1.103 +5 -1  
jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c
  
  Index: jk_ajp_common.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_ajp_common.c,v
  retrieving revision 1.102
  retrieving revision 1.103
  diff -u -r1.102 -r1.103
  --- jk_ajp_common.c   24 Apr 2005 09:54:47 -  1.102
  +++ jk_ajp_common.c   27 Apr 2005 06:38:59 -  1.103
  @@ -100,6 +100,10 @@
   case 3:
   switch (method[0])
   {
  +case 'A':
  +return (method[1] == 'C'
  +&& method[2] == 'L'
  +? SC_M_ACL : UNKNOWN_METHOD);
   case 'P':
   return (method[1] == 'U'
   && method[2] == 'T'
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Can't compile jk nativ connector under Suse 9.3

[Mladen Turk]

William A. Rowe, Jr. wrote:

here the configure output
... Thank you; but the other half of my question...
It was my fault. SD_SEND is defined only on winsock.
On other platforms it is 1. Already committed a fix.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Can't compile jk nativ connector under Suse 9.3

[William A. Rowe, Jr.]

At 11:02 PM 4/26/2005, Peter Rossbach wrote:

>here the configure output

... Thank you; but the other half of my question...

>make[1]: Entering directory 
>`/home/peter/develop/tomcat/jakarta-tomcat-connectors/jk/native/common'
>/bin/sh /home/peter/server/apache2/build/libtool --silent --mode=compile gcc 
>-I/home/peter/server/apache2/include -g -O2 -g -O2 -pthread -DHAVE_APR  
>-I/home/peter/server/httpd-2.0.54/srclib/apr/include -g -O2 -DLINUX=2 
>-D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I 
>/usr/java/jdk1.5.0_02/include -I /usr/java/jdk1.5.0_02/include/ -c jk_connect.c
>jk_connect.c: In function `jk_shutdown_socket':
>jk_connect.c:485: error: `SD_SEND' undeclared (first use in this function)
>jk_connect.c:485: error: (Each undeclared identifier is reported only once
>jk_connect.c:485: error: for each function it appears in.)



>William A. Rowe, Jr. schrieb:
>
>>grep -r SD_SEND /usr/include/*
>>grep -r SD_SEND /usr/local/include/*
>>
>>?
>>
>>Tell us where it's hidden and it's more likely we can come up with
>>an appropriate patch.

You seem to presume I run your version of suse here.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-connectors/jk/native/common jk_connect.c

[mturk]

mturk   2005/04/26 23:18:11

  Modified:jk/native/common jk_connect.c
  Log:
  No need to set the send timeout for read-only operation.
  
  Revision  ChangesPath
  1.57  +2 -6  jakarta-tomcat-connectors/jk/native/common/jk_connect.c
  
  Index: jk_connect.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_connect.c,v
  retrieving revision 1.56
  retrieving revision 1.57
  diff -u -r1.56 -r1.57
  --- jk_connect.c  27 Apr 2005 06:16:07 -  1.56
  +++ jk_connect.c  27 Apr 2005 06:18:11 -  1.57
  @@ -491,15 +491,11 @@
   #if defined(WIN32)
   setsockopt(s, SOL_SOCKET, SO_RCVTIMEO,
  (const char *) &tmout, sizeof(int));
  -setsockopt(s, SOL_SOCKET, SO_SNDTIMEO,
  -   (const char *) &tmout, sizeof(int));
  -#elif defined(SO_RCVTIMEO) && defined(USE_SO_RCVTIMEO) && 
defined(SO_SNDTIMEO) && defined(USE_SO_SNDTIMEO)
  +#elif defined(SO_RCVTIMEO) && defined(USE_SO_RCVTIMEO)
   tv.tv_sec  = SECONDS_TO_LINGER;
   tv.tv_usec = 0;
   setsockopt(s, SOL_SOCKET, SO_RCVTIMEO,
  (const void *) &tv, sizeof(tv));
  -setsockopt(s, SOL_SOCKET, SO_SNDTIMEO,
  -   (const void *) &tv, sizeof(tv));
   #endif
   /* Read all data from the peer until we reach "end-of-file" (FIN
* from peer) or we've exceeded our overall timeout. If the client does
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-connectors/jk/native/common jk_connect.c

[mturk]

mturk   2005/04/26 23:16:07

  Modified:jk/native/common jk_connect.c
  Log:
  Fix typo.
  
  Revision  ChangesPath
  1.56  +2 -2  jakarta-tomcat-connectors/jk/native/common/jk_connect.c
  
  Index: jk_connect.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_connect.c,v
  retrieving revision 1.55
  retrieving revision 1.56
  diff -u -r1.55 -r1.56
  --- jk_connect.c  27 Apr 2005 06:14:59 -  1.55
  +++ jk_connect.c  27 Apr 2005 06:16:07 -  1.56
  @@ -465,7 +465,7 @@
   #endif
   #define SECONDS_TO_LINGER  1
   #ifndef SD_SEND
  -#define DS_SEND 0x01
  +#define SD_SEND 0x01
   #endif
   
   int jk_shutdown_socket(int s)
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-connectors/jk/native/common jk_connect.c

[mturk]

mturk   2005/04/26 23:15:00

  Modified:jk/native/common jk_connect.c
  Log:
  Add SD_SEND for platforms that has no such define. Also lower the
  lingering timeout for graceful shutdown to 1 second and maximum of
  16x512 packets to consume, giving the AJP max packet size.
  
  Revision  ChangesPath
  1.55  +7 -5  jakarta-tomcat-connectors/jk/native/common/jk_connect.c
  
  Index: jk_connect.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_connect.c,v
  retrieving revision 1.54
  retrieving revision 1.55
  diff -u -r1.54 -r1.55
  --- jk_connect.c  24 Apr 2005 09:52:57 -  1.54
  +++ jk_connect.c  27 Apr 2005 06:14:59 -  1.55
  @@ -461,9 +461,12 @@
   }
   
   #ifndef MAX_SECS_TO_LINGER
  -#define MAX_SECS_TO_LINGER 30
  +#define MAX_SECS_TO_LINGER 16
  +#endif
  +#define SECONDS_TO_LINGER  1
  +#ifndef SD_SEND
  +#define DS_SEND 0x01
   #endif
  -#define SECONDS_TO_LINGER  2
   
   int jk_shutdown_socket(int s)
   {
  @@ -500,8 +503,7 @@
   #endif
   /* Read all data from the peer until we reach "end-of-file" (FIN
* from peer) or we've exceeded our overall timeout. If the client does
  - * not send us bytes within 2 seconds (a value pulled from Apache 1.3
  - * which seems to work well), close the connection.
  + * not send us bytes within12 second, close the connection.
*/
   while (1) {
   nbytes = jk_tcp_socket_recvfull(s, dummy, sizeof(dummy));
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

HELLO

[remm]

Mail transaction failed. Partial message is available.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Can't compile jk nativ connector under Suse 9.3

[Peter Rossbach]

Hey,
here the configure output
[EMAIL PROTECTED]:~/develop/tomcat/jakarta-tomcat-connectors/jk/native> 
./configure --with-apxs=/home/peter/server/apache2/bin/apxs
checking build system type... i686-suse-linux
checking host system type... i686-suse-linux
checking target system type... i686-suse-linux
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... none
checking for a sed that does not truncate output... /usr/bin/sed
checking for egrep... grep -E
checking for ld used by gcc... /usr/i586-suse-linux/bin/ld
checking if the linker (/usr/i586-suse-linux/bin/ld) is GNU ld... yes
checking for /usr/i586-suse-linux/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking whether ln -s works... yes
checking how to recognise dependent libraries... pass_all
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... yes
checking dlfcn.h presence... yes
checking for dlfcn.h... yes
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... none
checking how to run the C++ preprocessor... g++ -E
checking for g77... no
checking for f77... no
checking for xlf... no
checking for frt... no
checking for pgf77... no
checking for fort77... no
checking for fl32... no
checking for af77... no
checking for f90... no
checking for xlf90... no
checking for pgf90... no
checking for epcf90... no
checking for f95... no
checking for fort... no
checking for xlf95... no
checking for ifc... no
checking for efc... no
checking for pgf95... no
checking for lf95... no
checking for gfortran... no
checking whether we are using the GNU Fortran 77 compiler... no
checking whether  accepts -g... no
checking the maximum length of command line arguments... 32768
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for objdir... .libs
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
checking if gcc static flag  works... yes
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (/usr/i586-suse-linux/bin/ld) supports 
shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... cat: 
/etc/ld.so.conf.d/*.conf: No such file or directory
GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking for shl_load... no
checking for shl_load in -ldld... no
checking for dlopen... no
checking for dlopen in -ldl... yes
checking whether a program can dlopen itself... yes
checking whether a statically linked program can dlopen itself... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
configure: creating libtool
appending configuration tag "CXX" to libtool
checking for ld used by g++... /usr/i586-suse-linux/bin/ld
checking if the linker (/usr/i586-suse-linux/bin/ld) is GNU ld... yes
checking whether the g++ linker (/usr/i586-suse-linux/bin/ld) supports 
shared libraries... yes
checking for g++ option to produce PIC... -fPIC
checking if g++ PIC flag -fPIC works... yes
checking if g++ supports -c -o file.o... yes
checking whether the g++ linker (/usr/i586-suse-linux/bin/ld) supports 
shared libraries... yes
checking dynamic linker characteristics... cat: 
/etc/ld.so.conf.d/*.conf: No such file or directory
GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking for shl_load... (cached) no
checking for shl_load in -ldld... (cached) no
checking for dlopen... (cached) no
checking for dlopen in -ldl... (cached) yes
checking whether a program can dlopen itself... (cached) yes
checking whether a statically linked program can dlopen itself...

Why is ACL judged UNKNOWN_METHOD since jk_ajp_common.c Revision 1.68 ?

[takahiro_kikumoto]

Hello, mturk.
(B
(BYou changed implementation of jk_ajp_common.c from Revision 1.67 to Revision  
(B1.68.
(BACL have been judged UNKNOWN_METHOD since its modification.
(BWhy ?
(B
(Bregards
(BTakahiro
(B
(B-
(BTo unsubscribe, e-mail: [EMAIL PROTECTED]
(BFor additional commands, e-mail: [EMAIL PROTECTED]

Re: ant installer target

[Gary Orser]

Mark,

Thanks for replying.

First an update.
Couldn't get this to work with cygwin.
  It would build, but the .exe created would fail on Service Install.

Did get it to work with cmd.exe (this is with the original
build.properties.default.  The nsis installer gets downloaded into
\usr\share\java\nsis2.0.  You have to move the makensis.exe somewhere,
then install nsis into \usr\share\java\nsis2.0) 

ant release (is the proper target and gets all the dependencies right).

ant build dist
ant build installer
looks like it works, but it's misleading, it doesn't really build the 
.exe.  The property execute-installer isn't set, so the installer target 
doesn't really run.  (It says "Build Successful", but the target hasn't 
really run.)  There is nothing in the release\...\bin directory

The modification that should be made to the 
jakarta-tomcat-5\build.xml is:

- http://jakarta.apache.org/tomcat/tomcat-5.5-doc/building.html

should be modified to state that the "ant release" target is what people
want to get everything built.

Cheers, Gary
--
Gary Orser  
Montana State University
Department of Cell Biology and Neuroscience
Center for Computational Biology
1 Lewis Hall, Bozeman MT, 59717

On Tue, 26 Apr 2005, Mark Thomas wrote:

> This works for me from a clean build with the following process:
> 
> 1. Build using build.xml as per
> http://jakarta.apache.org/tomcat/tomcat-5.5-doc/building.html
> 
> 2. Then cd jakarta-tomcat-5
> 
> 3. build dist
> 
> 4. build installer
> 
> You will need to configure build.properties in both ${tomcat-source} and
> jakarta-tomcat-5
> 
> Mark
> 
> Gary Orser wrote:
> > Not finding any clues in the archives or web...
> > 
> > I've been struggling with trying to get the ant "installer" target to
> > work.  (tried both 5.5.9 tarball and build.xml cvs checkout).  I've tried
> > this both with cygwin, and cmd.exe (ugh!).  Both produce similar results.
> > 
> > In debugging this I've discovered that the installer target should have a
> > depends="prepare-release".  Additionally, the target doesn't copy many files
> > that it needs from ./build and other places to ./dist.
> > 
> > Is this target supposed to work?
> > 
> > How is the .exe distribution being created that is on the tomcat website?
> > Has nsis been deprecated?
> > 
> > Is there some reference/howto that describes this process better?
> > 
> > Am I missing something fundamental here?...
> > 
> > PS.  I had originally thought that this would be a cool way to have a
> > point and click installer for our webapp that needs to be installed as a
> > service.  Just include our app in webapps, change filenames,
> > descriptions,banners, and away we go...  I guess nothing is ever that
> > simple.
> > 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34549] - isUserInRole() on non-secure pages

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34549





--- Additional Comments From [EMAIL PROTECTED]  2005-04-26 23:46 ---
Looking back at it, I think the explanation is easy: no session for first
request when using BASIC (auth principals are cached in the session).

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34399] - Undeploying fails when context defined in server.xml & server fails to stop

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34399


[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Can't compile jk nativ connector under Suse 9.3

[William A. Rowe, Jr.]

grep -r SD_SEND /usr/include/*
grep -r SD_SEND /usr/local/include/*

?

Tell us where it's hidden and it's more likely we can come up with
an appropriate patch.  Any ./configure output would also be helpful.

At 01:01 PM 4/26/2005, Peter Rossbach wrote:
>I have a jk native compilation problem at suse 9.3 with the current CVS HEAD.
>
>Can't compile jk_connect.c
>
>jk_connect.c: In function 'jk_shutdown_socket' :
>jk_connect.c:485: error 'SD_SEND' undeclared (first use in this function)
>jk_connect.c:485: error (Each unde ...
>
>How can I find the missing SD_SEND declaration?
>
>Peter
>
>
>
>-
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34637] - Servlet Mapping validation doesn't comply to Servlet 2.4 spec

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34637


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2005-04-26 23:00 ---
You need to go back and read section 11.1 again.  Any exact pattern that 
doesn't start with '/' can't possibly ever be matched, so including it would 
be useless.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34637] New: - Servlet Mapping validation doesn't comply to Servlet 2.4 spec

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34637

   Summary: Servlet Mapping validation doesn't comply to Servlet 2.4
spec
   Product: Tomcat 5
   Version: 5.5.9
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


The Servlet spec v2.4 states that following with regard to mappings:

SRV.11.2 Specification of Mappings

In theWeb application deployment descriptor, the following syntax is used to
define mappings:

· A string beginning with a ‘/’ character and ending with a ‘/*’ suffix is used
for path mapping.
· A string beginning with a ‘*.’ prefix is used as an extension mapping.
· A string containing only the ’/’ character indicates the "default" servlet of
the application. In this case the servlet path is the request URI minus the
context path and the path info is null.
· All other strings are used for exact matches only.

The class org.apache.catalina.core.StandardContext validates the URL in
addServletMapping().  It calls the method validateURLPattern() and always throws
an exception if validateURLPattern() returns false.  Unfortunately, the
validateURLPattern() only returns true if the pattern starts with "/" or "*.". 
This satisfies the first 3 requirements from the spec, but not the 4th. Any
string that doesn't begin with "/" or "*." should be matched exactly.

Because of this Tomcat5 does not comply to the Servlet 2.4 spec.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ant installer target

[Mark Thomas]

This works for me from a clean build with the following process:
1. Build using build.xml as per 
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/building.html

2. Then cd jakarta-tomcat-5
3. build dist
4. build installer
You will need to configure build.properties in both ${tomcat-source} and 
jakarta-tomcat-5

Mark
Gary Orser wrote:
Not finding any clues in the archives or web...
I've been struggling with trying to get the ant "installer" target to
work.  (tried both 5.5.9 tarball and build.xml cvs checkout).  I've tried
this both with cygwin, and cmd.exe (ugh!).  Both produce similar results.
In debugging this I've discovered that the installer target should have a 
depends="prepare-release".  Additionally, the target doesn't copy many 
files that it needs from ./build and other places to ./dist.

Is this target supposed to work?
How is the .exe distribution being created that is on the tomcat website?  

Has nsis been deprecated?
Is there some reference/howto that describes this process better?
Am I missing something fundamental here?...
PS.  I had originally thought that this would be a cool way to have a
point and click installer for our webapp that needs to be installed as a
service.  Just include our app in webapps, change filenames,
descriptions,banners, and away we go...  I guess nothing is ever that
simple.
Cheers, Gary
--
Gary Orser 
Montana State University
Department of Cell Biology and Neuroscience
Center for Computational Biology
1 Lewis Hall, Bozeman MT, 59717

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Can't compile jk nativ connector under Suse 9.3

[Mladen Turk]

Peter Rossbach wrote:
I have a jk native compilation problem at suse 9.3 with the current CVS 
HEAD.

According to posix:
If  how is 0, further receives will be disallowed.  If how
is 1, further sends will be disallowed.  If how is 2, further
sends and receives will be disallowed.
So ...
#ifnedf SD_SEND
#define SD_SEND 1
#endif
Should do the trick.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Can't compile jk nativ connector under Suse 9.3

[Peter Rossbach]

I have a jk native compilation problem at suse 9.3 with the current CVS 
HEAD.

Can't compile jk_connect.c
jk_connect.c: In function 'jk_shutdown_socket' :
jk_connect.c:485: error 'SD_SEND' undeclared (first use in this function)
jk_connect.c:485: error (Each unde ...
How can I find the missing SD_SEND declaration?
Peter

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant JKStatusUpdateTask.java

[pero]

pero2005/04/26 10:42:16

  Modified:catalina/src/share/org/apache/catalina/ant
JKStatusUpdateTask.java
  Log:
  Update for new stopped flag at jk 1.2.11
  
  Revision  ChangesPath
  1.3   +39 -9 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/JKStatusUpdateTask.java
  
  Index: JKStatusUpdateTask.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/JKStatusUpdateTask.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- JKStatusUpdateTask.java   14 Mar 2005 20:42:22 -  1.2
  +++ JKStatusUpdateTask.java   26 Apr 2005 17:42:16 -  1.3
  @@ -53,6 +53,8 @@
   
   private Boolean workerDisabled = Boolean.FALSE;
   
  +private Boolean workerStopped = Boolean.FALSE;
  +
   private boolean isLBMode = true;
   
   private String workerLb;
  @@ -216,6 +218,20 @@
   }
   
   /**
  + * @return Returns the workerStopped.
  + */
  +public Boolean getWorkerStopped() {
  +return workerStopped;
  +}
  +
  +/**
  + * @param workerStopped The workerStopped to set.
  + */
  +public void setWorkerStopped(Boolean workerStopped) {
  +this.workerStopped = workerStopped;
  +}
  +
  +/**
* @return Returns the workerLoadFactor.
*/
   public Integer getWorkerLoadFactor() {
  @@ -266,7 +282,7 @@
* load balance example:
* 
http://localhost/status?cmd=update&mime=txt&w=lb&lf=false&ls=true
* worker example:
  - * 
http://localhost/status?cmd=update&mime=txt&w=node1&l=lb&wf=1&wd=false
  + * 
http://localhost/status?cmd=update&mime=txt&w=node1&l=lb&wf=1&wd=false&ws=false
* 
* 
* 
  @@ -299,7 +315,7 @@
   sb.append(lbForceSession);
   }
   } else {
  -
//http://localhost/status?cmd=update&mime=txt&w=node1&l=lb&wf=1&wd=false
  +
//http://localhost/status?cmd=update&mime=txt&w=node1&l=lb&wf=1&wd=false&ws=false
   if ((workerLb != null)) { // must be configured
   sb.append("&l=");
   sb.append(URLEncoder.encode(workerLb, getCharset()));
  @@ -312,6 +328,10 @@
   sb.append("&wd=");
   sb.append(workerDisabled);
   }
  +if ((workerStopped != null)) {
  +sb.append("&ws=");
  +sb.append(workerStopped);
  +}
   if ((workerRedirect != null)) { // other worker conrecte lb's
   sb.append("&wr=");
   }
  @@ -363,18 +383,28 @@
   throw new BuildException(
   "Must specify at a node worker 'workerDisabled' 
attribute");
   }
  -if (workerLoadFactor == null && workerClusterDomain == null
  -&& workerRedirect == null) {
  +if (workerStopped == null) {
  +throw new BuildException(
  +"Must specify at a node worker 'workerStopped' 
attribute");
  +}
  +if (workerLoadFactor == null ) {
  +throw new BuildException(
  +"Must specify at a node worker 'workerLoadFactor' 
attribute");
  +}
  +if (workerClusterDomain == null) {
  +throw new BuildException(
  +"Must specify at a node worker 'workerClusterDomain' 
attribute");
  +}
  +if (workerRedirect == null) {
   throw new BuildException(
  -"Must specify at a node worker either 
'workerClusterDomain',"
  -+ "'workerRedirect' or 'workerLoadFactor'  
attribute");
  +"Must specify at a node worker 'workerRedirect' 
attribute");
   }
   if (workerLb == null) {
   throw new BuildException("Must specify 'workerLb' 
attribute");
   }
  -if (null != workerLoadFactor && 1 < workerLoadFactor.intValue()) 
{
  +if (workerLoadFactor.intValue() < 1) {
   throw new BuildException(
  -"The 'workerLoadFactor' must be greater than 1");
  +"The 'workerLoadFactor' must be greater or equal 1");
   }
   isLBMode = false;
   } else {
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JK Releasing 1.2.11/1.2.12

[Henri Gomez]

Ok, what's the plan for the new connector ?

2005/4/26, Mladen Turk <[EMAIL PROTECTED]>:
> Henri Gomez wrote:
> > AJP14 remove in JK 1.2.x and also in JTC ?
> >
> > So where will you put new AJP stuff ?
> >
> 
> Inside the new connector :).
> 
> Really if we wish to have a full dynamic config,
> discovery, encryption and compression we should
> stick to APR, Apache2/IIS.
> IMO for that kind of things we need a modern server
> and modern OS abstraction framework without any compromises.
> Only in that case we would be able to achieve something.
> 
> Regards,
> Mladen.
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-connectors/jk/xdocs/config workers.xml

[pero]

pero2005/04/26 08:30:59

  Modified:jk/xdocs changelog.xml
   jk/xdocs/config workers.xml
  Log:
  Add stopped flag for better cluster support to worker.
  Many thanks to Mladen :->
  
  Revision  ChangesPath
  1.24  +5 -0  jakarta-tomcat-connectors/jk/xdocs/changelog.xml
  
  Index: changelog.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/changelog.xml,v
  retrieving revision 1.23
  retrieving revision 1.24
  diff -u -r1.23 -r1.24
  --- changelog.xml 24 Apr 2005 10:15:02 -  1.23
  +++ changelog.xml 26 Apr 2005 15:30:59 -  1.24
  @@ -25,6 +25,11 @@
 
 
   
  +  
  +  Add a stopped flag to worker configuration. Set flag True and 
  +  complete traffic to worker is stopped. 
  +  Only usefull in a replicated session cluster.(pero)
  +  
 Added worker maintain function that will maintain all
 the workers instead just the current one. This enables to recycle
 the connections on all workers. (mturk)
  
  
  
  1.14  +10 -0 jakarta-tomcat-connectors/jk/xdocs/config/workers.xml
  
  Index: workers.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/config/workers.xml,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- workers.xml   25 Apr 2005 06:53:25 -  1.13
  +++ workers.xml   26 Apr 2005 15:30:59 -  1.14
  @@ -368,6 +368,16 @@
   
   
   
  +
  +If set to True or 1 the worker will be stopped if member
  +of load balancer. The flag is needed for stop complete traffic of a sticky 
session
  +worker. It is only usefull, when you have a cluster that replicated the 
sessions.
  +This flag can be changed at runtime using status worker.
  +
  +This feature has been added in jk 1.2.11.
  +
  +
  +
   
   
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-connectors/jk/native/common jk_lb_worker.c jk_shm.h jk_status.c jk_uri_worker_map.h jk_util.c jk_util.h

[pero]

pero2005/04/26 08:28:18

  Modified:jk/native/common jk_lb_worker.c jk_shm.h jk_status.c
jk_uri_worker_map.h jk_util.c jk_util.h
  Log:
  Add stopped flag for better cluster support to worker.
  Many thanks to Mladen :->
  
  Revision  ChangesPath
  1.79  +11 -9 jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c
  
  Index: jk_lb_worker.c
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_lb_worker.c,v
  retrieving revision 1.78
  retrieving revision 1.79
  diff -u -r1.78 -r1.79
  --- jk_lb_worker.c24 Apr 2005 09:54:47 -  1.78
  +++ jk_lb_worker.c26 Apr 2005 15:28:18 -  1.79
  @@ -40,8 +40,8 @@
   /*
* Time to wait before retry...
*/
  -#define JK_WORKER_IN_ERROR(w) ((w)->in_error_state && !(w)->is_disabled && 
!(w)->is_busy)
  -#define JK_WORKER_USABLE(w)   (!(w)->in_error_state && !(w)->is_disabled && 
!(w)->is_busy)
  +#define JK_WORKER_IN_ERROR(w) ((w)->in_error_state  && !(w)->is_disabled && 
!(w)->is_busy)
  +#define JK_WORKER_USABLE(w)   (!(w)->in_error_state && !(w)->is_stopped && 
!(w)->is_disabled && !(w)->is_busy)
   
   struct lb_endpoint
   {
  @@ -235,7 +235,7 @@
   strcmp(p->lb_workers[i].s->domain, domain))
   continue;
   /* Take into calculation only the workers that are
  - * not in error state or not disabled.
  + * not in error state, stopped or not disabled.
*/
   if (JK_WORKER_USABLE(p->lb_workers[i].s)) {
   if (p->lbmethod == JK_LB_BYREQUESTS) {
  @@ -252,7 +252,7 @@
   curmin = mytraffic;
   }
   }
  -}
  +}
   }
   
   if (candidate) {
  @@ -284,7 +284,7 @@
   retry_worker(&p->lb_workers[i], p->s->recover_wait_time, l);
   }
   /* Take into calculation only the workers that are
  - * not in error state or not disabled.
  + * not in error state, stopped or not disabled.
*/
   if (JK_WORKER_USABLE(p->lb_workers[i].s)) {
   p->lb_workers[i].s->lb_value += p->lb_workers[i].s->lb_factor;
  @@ -319,7 +319,7 @@
   retry_worker(&p->lb_workers[i], p->s->recover_wait_time, l);
   }
   /* Take into calculation only the workers that are
  - * not in error state or not disabled.
  + * not in error state, stopped or not disabled.
*/
   if (JK_WORKER_USABLE(p->lb_workers[i].s)) {
   mytraffic = 
(p->lb_workers[i].s->transferred/p->lb_workers[i].s->lb_factor) +
  @@ -351,8 +351,8 @@
   if (JK_WORKER_IN_ERROR(candidate->s)) {
   retry_worker(candidate, p->s->recover_wait_time, l);
   }
  -if (candidate->s->in_error_state) {
  -/* We have a worker that is error state.
  +if (candidate->s->in_error_state || candidate->s->is_stopped ) {
  +/* We have a worker that is error state or stopped.
* If it has a redirection set use that redirection worker.
* This enables to safely remove the member from the
* balancer. Of course you will need a some kind of
  @@ -780,6 +780,8 @@
   p->lb_workers[i].s->error_time = 0;
   /* Worker can be initaly disabled as hot standby */
   p->lb_workers[i].s->is_disabled = 
jk_get_is_worker_disabled(props, worker_names[i]);
  +/* Worker can be initaly deactive as cold standby */
  +p->lb_workers[i].s->is_stopped = 
jk_get_is_worker_stopped(props, worker_names[i]);
   if (!wc_create_worker(p->lb_workers[i].s->name,
 props,
 &(p->lb_workers[i].w),
  
  
  
  1.19  +2 -1  jakarta-tomcat-connectors/jk/native/common/jk_shm.h
  
  Index: jk_shm.h
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_shm.h,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- jk_shm.h  11 Apr 2005 06:36:02 -  1.18
  +++ jk_shm.h  26 Apr 2005 15:28:18 -  1.19
  @@ -64,6 +64,7 @@
   charredirect[JK_SHM_STR_SIZ+1];
   /* current status of the worker */
   volatile int is_disabled;
  +volatile int is_stopped;
   volatile int is_busy;
   /* Current lb factor */
   volatile int lb_factor;
  
  
  
  1.38  +17 -6 jakarta-tomcat-connectors/jk/native/common/jk_status.c
  
  Index: jk_status.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/common/jk_status.c,v
  retrieving revision 1.37
  retrieving revision 1.38
  diff -u -r1.37 -r1.38
  --- jk_status.c   13 Apr 2005 11:03:37 -

Re: JK Releasing 1.2.11/1.2.12

[Mladen Turk]

Henri Gomez wrote:
AJP14 remove in JK 1.2.x and also in JTC ?
So where will you put new AJP stuff ?
Inside the new connector :).
Really if we wish to have a full dynamic config,
discovery, encryption and compression we should
stick to APR, Apache2/IIS.
IMO for that kind of things we need a modern server
and modern OS abstraction framework without any compromises.
Only in that case we would be able to achieve something.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

hello

[craigmcc]

The message contains Unicode characters and has been sent as a binary 
attachment.



Norton AntiVirus Deleted1.txt
Description: plain/text
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JK Releasing 1.2.11/1.2.12

[William A. Rowe, Jr.]

At 09:48 AM 4/26/2005, Mladen Turk wrote:
>William A. Rowe, Jr. wrote
>
>>The effort might better be spent after conversion to svn, since
>>you attain the ability to have versioned rmdir, without hacking
>>up the raw CVS tree and breaking historical checkouts.
>
>Hmm, I would like to leave the CVS until the Tomcat switches to
>the SVN. But of course it's up to the community to decide.
>CVS supports branches too IIRC?

I agree it would be better to see all of Tomcat make the switch
at once; and I'm not suggesting this is that moment.

But no, CVS doesn't support versioned directory trees.  You do
have -p(rune) on checkout and export, but svn supports actually
removing a directory entity as of an explicit revision.

Bill  


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34549] - isUserInRole() on non-secure pages

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34549





--- Additional Comments From [EMAIL PROTECTED]  2005-04-26 17:13 ---
One tiny, but important note:
this only happens with BASIC authorization. When I use FORM-based authorization,
everything works perfectly.

I hope this clarification is usefull.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JK Releasing 1.2.11/1.2.12

[Henri Gomez]

AJP14 remove in JK 1.2.x and also in JTC ?

So where will you put new AJP stuff ?

2005/4/26, Mladen Turk <[EMAIL PROTECTED]>:
> Glenn Nielsen wrote:
> >
> > We may want to consider use of a 1.3 development branch for new
> > features. I have noticed that there have been significant new features
> > added between releases of mod_jk 1.2.
> >
> 
> Well, I agree with you that we create a new branch.
> I wish to deprecate ajp12, jni and ajp14 connectors,
> as well as isapi, domino and ntservice servers.
> 
> Reasons:
> ajp12: Old connector. We have 1.2 branch for it
> jni: unusable
> ajp14: Unsupported and IMO impossible without rewriting the connector
> isapi, domino, ntservice: unmaintained for years.
> 
> Regards,
> Mladen.
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JK Releasing 1.2.11/1.2.12

[Mladen Turk]

William A. Rowe, Jr. wrote:
Reasons:
... ntservice: unmaintained for years.

I've used ntservice for years, never had an issue, happy to
maintain it.  Can you point to a specific issue?
Well, excellent. No reason to omit from the 1.2 branch then :)
The effort might better be spent after conversion to svn, since
you attain the ability to have versioned rmdir, without hacking
up the raw CVS tree and breaking historical checkouts.
Hmm, I would like to leave the CVS until the Tomcat switches to
the SVN. But of course it's up to the community to decide.
CVS supports branches too IIRC?
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JK Releasing 1.2.11/1.2.12

[William A. Rowe, Jr.]

At 09:35 AM 4/26/2005, Mladen Turk wrote:

>Well, I agree with you that we create a new branch.
>I wish to deprecate ajp12, jni and ajp14 connectors,
>as well as isapi, domino and ntservice servers.
>
>Reasons:
>... ntservice: unmaintained for years.

I've used ntservice for years, never had an issue, happy to
maintain it.  Can you point to a specific issue?

The effort might better be spent after conversion to svn, since
you attain the ability to have versioned rmdir, without hacking
up the raw CVS tree and breaking historical checkouts.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JK Releasing 1.2.11/1.2.12

[Mladen Turk]

Glenn Nielsen wrote:
We may want to consider use of a 1.3 development branch for new
features. I have noticed that there have been significant new features
added between releases of mod_jk 1.2.
Well, I agree with you that we create a new branch.
I wish to deprecate ajp12, jni and ajp14 connectors,
as well as isapi, domino and ntservice servers.
Reasons:
ajp12: Old connector. We have 1.2 branch for it
jni: unusable
ajp14: Unsupported and IMO impossible without rewriting the connector
isapi, domino, ntservice: unmaintained for years.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JK Releasing 1.2.11/1.2.12

[Henri Gomez]

Well 1.2.11 will be the latest stable release, until we discover bugs
in it and release a 1.2.12.

:-)

2005/4/26, Mladen Turk <[EMAIL PROTECTED]>:
> William A. Rowe, Jr. wrote:
> >>I wish to make the 1.2.11 as a bugfix release, so where's the
> >>churn in that?
> > Nothing, 1.2.11 is wonderful.
> >
> > You proposed releasing 1.2.12/stable a few days afterwards.
> >
> > I don't know if calling 1.2.12/stable in a few days is really such
> > a hot idea.
> 
> Me neither. I see that my idea about odd/even numbering was
> not so smart at all.
> 
> Regards,
> Mladen.
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JK Releasing 1.2.11/1.2.12

[Glenn Nielsen]

On Tue, Apr 26, 2005 at 12:57:12AM -0500, William A. Rowe, Jr. wrote:
> At 06:38 AM 4/25/2005, Mladen Turk wrote:
> >Peter Rossbach wrote:
> >>that is a very shot time period for testing.
> >
> >Well, some of the things are really critical, so that's the reason.
> 
> I think that 1.2.8/1.2.9 proved that haste creates this churn.
> 
> Once 1.2.11 is ready, isn't it sufficient to point users at that
> test version for 2 - 4 weeks, until it truly settles out?  Nothing
> but critical/proven bug fixes between .11 and .12?
> 
> If they couldn't get the code I'd agree with the fast turnaround,
> but once 1.2.11 exists, the point is, they can.

We may want to consider use of a 1.3 development branch for new
features. I have noticed that there have been significant new features
added between releases of mod_jk 1.2.

Then users can depend on the 1.2 production branch for a feature
stable backward compatible connector.

Then we can play around in the 1.3 branch with new features rather
than have feature creep in the production branch.

Regards,

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JK Releasing 1.2.11/1.2.12

[Mladen Turk]

William A. Rowe, Jr. wrote:
I wish to make the 1.2.11 as a bugfix release, so where's the
churn in that?
Nothing, 1.2.11 is wonderful.  

You proposed releasing 1.2.12/stable a few days afterwards.
I don't know if calling 1.2.12/stable in a few days is really such
a hot idea.
Me neither. I see that my idea about odd/even numbering was
not so smart at all.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JK Releasing 1.2.11/1.2.12

[William A. Rowe, Jr.]

At 06:01 AM 4/26/2005, Mladen Turk wrote:

>I wish to make the 1.2.11 as a bugfix release, so where's the
>churn in that?

Nothing, 1.2.11 is wonderful.  

You proposed releasing 1.2.12/stable a few days afterwards.

I don't know if calling 1.2.12/stable in a few days is really such
a hot idea.  1.2.4, 1.2.6 worked for most users for a very long time,
and with all the new features/development on 1.2, it would be good
to see all this effort solidify before being blessed 'stable'.

Certainly give the testing community time to stress this.  In the
case of httpd, the 3-day rule came from www.apache.org itself, it's
possible to shove a huge volume of real world traffic at our own
web server over three days.  

In the case of jk, our testers seem to be asking for more time to
do a thorough job of testing.  1.2.10 release had a few latent
hiccups, so my question is, why the rush from 1.2.11 to 1.2.12?

Bill  


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_jk problem with domain clustering and restart node or application

[Peter Rossbach]

Thanks,
"stopped" is a very good name!
Peter
Georg v. Zezschwitz schrieb:
On Tue, Apr 26, 2005 at 01:10:13PM +0200, Peter Rossbach wrote:
 

I name the flag deactived.
   

Sorry for a lurkers comment from the background (and I am neither
a native speaker).
But I guess it should be named:
 "deactivated" not "deactived"
Also, based on Mladens points, what about a more strict name,
like: "stopped"?
Kind regards,
Georg v.Zezschwitz
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_jk problem with domain clustering and restart node or application

[Peter Rossbach]

Hey Malden,
Mladen Turk schrieb:
Peter Rossbach wrote:

I name the flag deactived.
Look, can we prolong that to the next release?
I would really appreciate that, because the 1.2.11
should be a bug-fix release.
Changing that would break the current configurations,
and IMO we could think of something smarter in the future.
The change not break the configuration, it extend the configuration.
I also see that this flag make the configruation much more compilcate 
and that was really bad.

But I can send you my changes before commit and you can have the 
descision it
include inside 1.2.11 or not.

Adding an extra checkbox to the status worker for putting the
worker in error and disabled state at once, should do a trick
I think.
Any other directives should be carefully selected thought.
Yes, I have also made the flag configurable, but I find it a little bit
strange to set the error flag. But this was my first idea. Please review 
my changes.

Better ideas welcome :-)
Currently I have test all worker modes at windows,
but now I have a compilation problem at suse 9.3
the compile can't jk_connect.c
jk_connect.c: In function 'jk_shutdown_socket' :
jk_connect.c:485: error 'SD_SEND' undeclared (first use in this function)
jk_connect.c:484: error (Each unde ...
How can I find the missing declaration of SD_SEND?
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_jk problem with domain clustering and restart node or application

[Mladen Turk]

Peter Rossbach wrote:

I name the flag deactived.
Look, can we prolong that to the next release?
I would really appreciate that, because the 1.2.11
should be a bug-fix release.
Changing that would break the current configurations,
and IMO we could think of something smarter in the future.
Adding an extra checkbox to the status worker for putting the
worker in error and disabled state at once, should do a trick
I think.
Any other directives should be carefully selected thought.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_jk problem with domain clustering and restart node or application

[Georg v. Zezschwitz]

On Tue, Apr 26, 2005 at 01:10:13PM +0200, Peter Rossbach wrote:
> I name the flag deactived.

Sorry for a lurkers comment from the background (and I am neither
a native speaker).

But I guess it should be named:

  "deactivated" not "deactived"

Also, based on Mladens points, what about a more strict name,
like: "stopped"?

Kind regards,


Georg v.Zezschwitz

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_jk problem with domain clustering and restart node or application

[Peter Rossbach]

Mladen Turk schrieb:
Peter Rossbach wrote:
Are you sure this is absolute necessity?
But at cluster the session are replicated, and we must not wait. 
Please, can we
add a flag active=false/true to test my idea. What do you thing I can 
start
a quick experiment and send you the diffs for reviewing?

Well I'm -0 on the subject, because I think it's useless.
You can of course commit what you think is appropriate,
of course if that will not break the existing functionality.
Yes, I am on testing this. I hope you can help
two test it also. Many thanks!
I think that the desired functionality can be achieved with status
worker that will put the worker in error and disabled state at once,
but of course you can add a new flag for that.
OK, I have add a deactived flag.
IMO adding that 'active' flag to the workers.properties will only
rise the fuzziness regarding to the 'disabled' flag.
Once more, all the features you are searching for, can be achieved
using the current configuration. Simply use the JMX and pause your
node.
Hmm, but curently the connection are keepalive. I see that only new 
connection
drop, but the active connection are still alive. At my test the request 
don't stop.

But if you think that is realy needed then rename the 'disable' to
be the function of your proposed 'active' and add a new flag 'standby'
or 'pause' that will act as current negation of the disabled flag.
I name the flag deactived.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JK Releasing 1.2.11/1.2.12

[Mladen Turk]

William A. Rowe, Jr. wrote:
We've burned the users with deprecating mod_jk2.  Generating churn 
in mod_jk (as opposed to solid, stable releases) will only continue
to lessen users' faith in jk as a production solution.

Well, I don't quite understand your question.
JK2 is past tense, so that's out. The first thing that crosses my
mind is Parrot/Perl compared with JK2/JK.
If you think that the frequency of the releases reflects the
instability of the software, well,
IMO it should be apache 2.0.503 not apache 2.0.53 ;)
I wish to make the 1.2.11 as a bugfix release, so where's the
churn in that?
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_jk problem with domain clustering and restart node or application

[Mladen Turk]

Peter Rossbach wrote:
Are you sure this is absolute necessity?
But at cluster the session are replicated, and we must not wait. Please, 
can we
add a flag active=false/true to test my idea. What do you thing I can start
a quick experiment and send you the diffs for reviewing?

Well I'm -0 on the subject, because I think it's useless.
You can of course commit what you think is appropriate,
of course if that will not break the existing functionality.
I think that the desired functionality can be achieved with status
worker that will put the worker in error and disabled state at once,
but of course you can add a new flag for that.
IMO adding that 'active' flag to the workers.properties will only
rise the fuzziness regarding to the 'disabled' flag.
Once more, all the features you are searching for, can be achieved
using the current configuration. Simply use the JMX and pause your
node.
But if you think that is realy needed then rename the 'disable' to
be the function of your proposed 'active' and add a new flag 'standby'
or 'pause' that will act as current negation of the disabled flag.
Regards,
Mladen.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_jk problem with domain clustering and restart node or application

[Peter Rossbach]

Hey Mladen,
I have made successfull a test implementation to deactived a worker. I 
works very fine for me at windows.
Now made a second test under apache 2.0.54 and Linux 9.3 with worker and 
prefork MPM.

I think in two hour I am ready to checkin the change. :-)
Peter
Peter Rossbach schrieb:
Hey Mladen,
Mladen Turk schrieb:
Peter Rossbach wrote:
Hey Mladen,
I used the tomcat at cluster mode, but your answer is a little bit 
to easy.
 Sticky session is the only way for the most applications to be 
consistens.
 Session replication is only a secondary feature when failure occured.


Why we can't add a flag that deactive a worker or change the 
semantic of disable?
Then all request goes to the other replication members in a cluster 
domain and restarting
is easy without risk and waiting time.

Are you sure this is absolute necessity?

YES! We monitor the cluster and when one member is not accessiable or
throw Out of memory Exception, the node was automaticly restart. Also
this mode is fine for minor node or application configuration update.
It is not usefull for complete new deployment, when serialized classes 
changed :-)

I agree something like that might be usable on a development server,
but on a production server? I'm not sure if your users will be happy
with loosing sessions in a middle of a transaction or order.
Hmm, but the fallback server (same cluster domain) has the sessions at 
this moment and the user see nothing from the switch.
This suggestion is the result of my last two week pre production tests 
and customer discussions.

Again, disable works as expected. It will preserve exiting sessions
until session times out. When all existing sessions are gone, then you
can do with that node what ever you wish.
If you do not wish to wait, then simply disable and kill that instance.
The existing sessions will be failovered to another node with loosing
session data.

But at cluster the session are replicated, and we must not wait. 
Please, can we
add a flag active=false/true to test my idea. What do you thing I can 
start
a quick experiment and send you the diffs for reviewing?

I see no reason whatsoever for introducing another 'immediate disable'
flag to the worker.

I hope my description help do understand my suggestion better.
Regards,
Mladeb.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34616] - Cookie authorization in Tomcat.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34616


[EMAIL PROTECTED] changed:

   What|Removed |Added

Version|4.0 Final   |4.1.31




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34616] New: - Cookie authorization in Tomcat.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34616

   Summary: Cookie authorization in Tomcat.
   Product: Tomcat 4
   Version: 4.0 Final
  Platform: All
OS/Version: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


It would be nice to have a cookie authorization in tomcat (as it done, for 
instance, in Resin application server).

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34615] - Unecessary cluster replication of DeltaRequest AttributeInfo objects

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34615





--- Additional Comments From [EMAIL PROTECTED]  2005-04-26 10:55 ---
Created an attachment (id=14842)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=14842&action=view)
Minimum servlet that causes the unecessary AttributeInfo replication


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34615] New: - Unecessary cluster replication of DeltaRequest AttributeInfo objects

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34615

   Summary: Unecessary cluster replication of DeltaRequest
AttributeInfo objects
   Product: Tomcat 5
   Version: 5.0.30
  Platform: PC
OS/Version: Windows 2000
Status: NEW
  Severity: normal
  Priority: P3
 Component: Catalina:Cluster
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


Setup:
Two Tomcat 5.0.30 servers arranged in a cluster with synchronous replication
using multicast.
Apache server using mod_jk2 to load balance between the two servers in a
round-robin manner (no sticky sessions)

Application:
Initially discovered the problem while testing clustering of the wicket
framework. However, problem can be replicated with small servlet (see bottom of
description). This servlet handles two requests:

1) Request arrives to servlet (on serverA), which sets a session attribute and
then outputs an HTML page. The HTML page contains a style sheet link with an
href back to the same servlet.
2) Request for dynamically generated stylesheet arrives (on serverB). The
session is not accessed and the css content is output.

I added debug to org.apache.catalina.cluster.session.DeltaRequest and what I see
happening is as follows:

1) Request to servlet arrives on serverA. Servlet sets a session attribute and
returns the HTML content.
2) ServerA sends the delta request containing one AttributeInfo object to
serverB and then resets its actions list.
3) ServerB receives the delta request containing the one AttributeInfo object
4) DeltaRequest.execute(DeltaSession) sets the attribute on the session.
However, it DOESN'T remove the AttributeInfo object from the actions list.

5) Request to servlet arrives on serverB (to retrieve the css content). Servlet
returns the css content but does not update the session.
6) DeltaManager.requestCompleted(String) is called on serverB. This checks if
the actions list of the delta request is non-empty.
7) The actions list is non-empty because it contains the AttributeInfo object
from the previous synchronization (4). Thus, the AttributeInfo object is sent
back to serverA (which starts again at 3). 

The net result is that the same AttributeInfo object bounces back and forth
between the two servers for each request that come in (regardless of whether the
request alters the session or not). When the original page contains many
dynamically generated images (retrieved concurrently by the browser) the
externalization code finally falls in a heap with EOF and NPE problems due to
the two machines trying to synchronize different copies of the same
AttributeInfo object.

The solution to the problem is to change the DeltaRequest.execute(DeltaSession)
method to remove the AttributeInfo objects from the actions list after it has
finished processing them:

public synchronized void execute(DeltaSession session) {
 
}//switch
}//for
>>  reset();  
session.endAccess();
}

This appears to solve the problem.

Example servlet (if anyone wants to test this out):
public class MyAppServlet extends HttpServlet {

protected void doGet(final HttpServletRequest request, final
HttpServletResponse response)
throws ServletException, IOException {
final String action = request.getParameter("action");
if ( "css".equals(action) ) {
response.setContentType("text/css");
PrintWriter out = response.getWriter();
out.println(".someStyle {\npadding: 5px;\n}");
}
else {
request.getSession().setAttribute("test", "value");
response.setContentType("text/html");
PrintWriter out = response.getWriter();
out.println("\n\nTest Page");
out.println("");
out.println("\n\nTest
Page\n\n");
}
}

protected void doPost(final HttpServletRequest request, final
HttpServletResponse response)
throws ServletException, IOException {
doGet(request, response);
}

}

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: mod_jk problem with domain clustering and restart node or application

[Peter Rossbach]

Hey Mladen,
Mladen Turk schrieb:
Peter Rossbach wrote:
Hey Mladen,
I used the tomcat at cluster mode, but your answer is a little bit to 
easy.
 Sticky session is the only way for the most applications to be 
consistens.
 Session replication is only a secondary feature when failure occured.


Why we can't add a flag that deactive a worker or change the semantic 
of disable?
Then all request goes to the other replication members in a cluster 
domain and restarting
is easy without risk and waiting time.

Are you sure this is absolute necessity?
YES! We monitor the cluster and when one member is not accessiable or
throw Out of memory Exception, the node was automaticly restart. Also
this mode is fine for minor node or application configuration update.
It is not usefull for complete new deployment, when serialized classes 
changed :-)

I agree something like that might be usable on a development server,
but on a production server? I'm not sure if your users will be happy
with loosing sessions in a middle of a transaction or order.
Hmm, but the fallback server (same cluster domain) has the sessions at 
this moment and the user see nothing from the switch.
This suggestion is the result of my last two week pre production tests 
and customer discussions.

Again, disable works as expected. It will preserve exiting sessions
until session times out. When all existing sessions are gone, then you
can do with that node what ever you wish.
If you do not wish to wait, then simply disable and kill that instance.
The existing sessions will be failovered to another node with loosing
session data.
But at cluster the session are replicated, and we must not wait. Please, 
can we
add a flag active=false/true to test my idea. What do you thing I can start
a quick experiment and send you the diffs for reviewing?

I see no reason whatsoever for introducing another 'immediate disable'
flag to the worker.

I hope my description help do understand my suggestion better.
Regards,
Mladeb.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34610] - the present is :ERROR ManagerBase:434 - IOException while loading persisted sessions when i started tomcat in jbuilder2005

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34610


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID
Summary|the present is :ERROR   |the present is :ERROR
   |ManagerBase:434 -   |ManagerBase:434 -
   |IOException while loading   |IOException while loading
   |persisted sessions when i   |persisted sessions when i
   |started tomcat in   |started tomcat in
   |jbuilder2005|jbuilder2005




--- Additional Comments From [EMAIL PROTECTED]  2005-04-26 10:14 ---
BZ is not a support forum, try discussing such a problem tomcat-users mailing
list first. Making this class implement Serializable interface should help.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 34609] - the present is :ERROR ManagerBase:434 - IOException while loading persisted sessions when i started tomcat in jbuilder2005

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34609


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID
Summary|the present is :ERROR   |the present is :ERROR
   |ManagerBase:434 -   |ManagerBase:434 -
   |IOException while loading   |IOException while loading
   |persisted sessions when i   |persisted sessions when i
   |started tomcat in   |started tomcat in
   |jbuilder2005|jbuilder2005




--- Additional Comments From [EMAIL PROTECTED]  2005-04-26 10:13 ---
BZ is not a support forum, try discussing such a problem on tomcat-users mailing
list first. Making this class implement Serializable interface should help.


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[EMAIL PROTECTED]: Project jakarta-tomcat-jk-native (in module jakarta-tomcat-connectors) failed

[Bill Barker]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project jakarta-tomcat-jk-native has an issue affecting its community 
integration.
This issue affects 1 projects,
 and has been outstanding for 117 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- jakarta-tomcat-jk-native :  Connectors to various web servers


Full details are available at:

http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -INFO- Failed with reason build failed



The following work was performed:
http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/gump_work/build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native.html
Work Name: build_jakarta-tomcat-connectors_jakarta-tomcat-jk-native (Type: 
Build)
Work ended in a state of : Failed
Elapsed: 
Command Line: make 
[Working Directory: 
/usr/local/gump/public/workspace/jakarta-tomcat-connectors/jk/native]
-
Making all in common
make[1]: Entering directory 
`/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common'
/bin/sh 
/usr/local/gump/public/workspace/apache-httpd/dest-26042005/build/libtool 
--silent --mode=compile gcc 
-I/usr/local/gump/public/workspace/apache-httpd/dest-26042005/include -g -O2 -g 
-O2 -pthread -DHAVE_APR  
-I/usr/local/gump/public/workspace/apr/dest-26042005/include/apr-1 -g -O2 
-DLINUX=2 -D_REENTRANT -D_GNU_SOURCE -D_LARGEFILE64_SOURCE 
-I/home/gump/workspaces2/public/workspace/apache-httpd/srclib/pcre -I 
/opt/jdk1.4/include -I /opt/jdk1.4/include/ -c jk_ajp12_worker.c 
/usr/local/gump/public/workspace/apache-httpd/dest-26042005/build/libtool: 
/usr/local/gump/public/workspace/apache-httpd/dest-26042005/build/libtool: No 
such file or directory
make[1]: *** [jk_ajp12_worker.lo] Error 127
make[1]: Leaving directory 
`/home/gump/workspaces2/public/workspace/jakarta-tomcat-connectors/jk/native/common'
make: *** [all-recursive] Error 1
-

To subscribe to this information via syndicated feeds:
- RSS: 
http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/rss.xml
- Atom: 
http://brutus.apache.org/gump/public/jakarta-tomcat-connectors/jakarta-tomcat-jk-native/atom.xml

== Gump Tracking Only ===
Produced by Gump version 2.2.
Gump Run 3026042005, brutus:brutus-public:3026042005
Gump E-mail Identifier (unique within run) #11.

--
Apache Gump
http://gump.apache.org/ [Instance: brutus]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]