RE: The FIX - Shutdown not working under SLES8 and FC2
Is there any reason why it doesn't try localhost first? Using localhost before anything else would have the following benefits; a) Would ensure that only really strange network configs would be affected (i.e. those where localhost is not the local host). b) Make use of the speed advantage some OS's have in their implementation of the loopback address. c) Avoid any wacky differences in the implementation of InetAddress.getLocalHost() between JVMs/OSs/etc. Off the top off my head I can't see the advantages of using the result of InetAddress.getLocalHost() first. Al. -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED] Sent: 03 February 2005 19:11 To: Tomcat Developers List Subject: Re: The FIX - Shutdown not working under SLES8 and FC2 If no address is configured, ChannelSocket attempts the shutdown on InetAddress.getLocalHost(). Personally, I'm not inclined to change this as it points to a network configuration problem if this is unreachable. However, you might try complaining to Sun about how they have implemented getLocalHost on SLES8. - Original Message - From: [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Cc: tomcat-dev@jakarta.apache.org Sent: Thursday, February 03, 2005 2:14 AM Subject: The FIX - Shutdown not working under SLES8 and FC2 After some playing around I think I've tracked down what the fix is, and I'd like to throw an idea out as to what could be happening. First the fix. The fix is to explicitly state in the AJP13 connector that the connector should ONLY bind to the loopback address (i.e. add address=127.0.0.1). Maybe this should be made the default because; a) it's a fix to the issue. and b) it also enhances security. Those people who are using AJP13 between machines should have the knowlege to re-configure the connector to allow connections between different machines. Now the suggestion as to why this is happening. My machine is behind a firewall, and therefore has non-routable IP addresses (192.168.x.x). If you lookup the full hostname (a.b.c.d) on the machine the hosts file resolves it to the private IP, if you look it up using DNS it resolves to the public IP address of the firewall. If you lookup the machine name only (a) from on the machine or anywhere else it resolves via DNS to the public IP of the firewall. From what I can tell the AJP13 connector looks up the hostname only, (which resolves it to the public IP address), then tries to connect to the AJP13 port on the public IP address, and because the firewall blocks this traffic, does not connect, and then gives up. To back this up I have put the hostname on it's own into the hosts file (i.e. a resolves to the private IP), and everything worked again. Before everyone shouts you've got a strange config, it's your problem, I'd like to re-iterate that this issue can be avoided in many ways, and my personal beleif is that the order of preference of fixes would be; 1) Add the address=127.0.0.1 to the default server.xml (which also has the side effect of increasing security). 2) If no address is specified then make the shutdown system start by trying to connect to localhost as opposed to what seems to be the current behaviour of attempting to resolve to an external address first. 3) Require everyone to have the short hostname configured to resolve to their local IP. The reasons for this ordering is that 1 is the least effort by the fewest people, 2 is more effort but by a small group, 3 has a potential impact on all users and no matter where you document it will still be missed by those who beleive in unpack and run. Regards, Al. Al Sutton [EMAIL PROTECTED] wrote on 03.02.2005, 07:58:16: Ben, Thanks for this. I'm not using any settings in JAVA_OPTS as shown below; [EMAIL PROTECTED] al]$ env | grep -i JAVA JRE_HOME=/usr/java/jdk1.4/jre PATH=/usr/java/jdk1.4/bin:/home/al/utils/apache-ant-1.6.2/bin:/usr/kerberos/ bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin JAVA_HOME=/usr/java/jdk1.4 [EMAIL PROTECTED] al]$ I've tried this on two machines, one an Athlon XP 2400+ running FC2, and the other a Dual Xeon 2.8 GHz running SLES 8, both showed the same problem, so I'm pretty sure it's not hardware. The machines are also geographically seperated and do not operate on the network (ones on my LAN at home, the others on a LAN at work), so I'm pretty sure it's not related to the environment external to the machine. I'm going to upgrade to _07 and get the latest kernel and try again, as currently the only difference seems to be that your execting startup and shutdown from within the bin directory and I'm executing it from the top level (i.e. doing bin/startup.sh and bin/shutdown.sh). Thanks again, Al. -Original Message- From: Ben Souther [mailto:[EMAIL PROTECTED] Sent: 02 February 2005 23:32 To: Tomcat Users List Subject: RE: Shutdown not working under SLES8 and FC2 On Wed, 2005-02-02 at 17:11, Ben Souther wrote: On Wed, 2005-02
RE: The FIX - Shutdown not working under SLES8 and FC2
Costin, The answer to your question is all of the above (i.e. start with localhost, then 127.0.0.1, then try the IPv6 localhost). I'm not saying it's the only behaviour, just that trying it first may make more stable than trying a hostname first. It's als less work by fewer people to change Tomcat than to check, test, and modify (if neccessary) all the JVMs in existance. Al. -Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of Costin Manolache Sent: 04 February 2005 02:28 To: tomcat-dev@jakarta.apache.org Subject: Re: The FIX - Shutdown not working under SLES8 and FC2 Al Sutton wrote: Is there any reason why it doesn't try localhost first? Using localhost before anything else would have the following benefits; a) Would ensure that only really strange network configs would be affected (i.e. those where localhost is not the local host). b) Make use of the speed advantage some OS's have in their implementation of the loopback address. c) Avoid any wacky differences in the implementation of InetAddress.getLocalHost() between JVMs/OSs/etc. Off the top off my head I can't see the advantages of using the result of InetAddress.getLocalHost() first. What do you mean by 'try localhost first' ? The name 'localhost', or '127.0.0.1' or whatever the number is in IPV6 ? I guess the reason for InetAddress.getLocalHost() is the wacky differences between OSes :-), and if it's broken on a platform - it should be fixed ( by Sun or OS vendor ) Costin Al. -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED] Sent: 03 February 2005 19:11 To: Tomcat Developers List Subject: Re: The FIX - Shutdown not working under SLES8 and FC2 If no address is configured, ChannelSocket attempts the shutdown on InetAddress.getLocalHost(). Personally, I'm not inclined to change this as it points to a network configuration problem if this is unreachable. However, you might try complaining to Sun about how they have implemented getLocalHost on SLES8. - Original Message - From: [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Cc: tomcat-dev@jakarta.apache.org Sent: Thursday, February 03, 2005 2:14 AM Subject: The FIX - Shutdown not working under SLES8 and FC2 After some playing around I think I've tracked down what the fix is, and I'd like to throw an idea out as to what could be happening. First the fix. The fix is to explicitly state in the AJP13 connector that the connector should ONLY bind to the loopback address (i.e. add address=127.0.0.1). Maybe this should be made the default because; a) it's a fix to the issue. and b) it also enhances security. Those people who are using AJP13 between machines should have the knowlege to re-configure the connector to allow connections between different machines. Now the suggestion as to why this is happening. My machine is behind a firewall, and therefore has non-routable IP addresses (192.168.x.x). If you lookup the full hostname (a.b.c.d) on the machine the hosts file resolves it to the private IP, if you look it up using DNS it resolves to the public IP address of the firewall. If you lookup the machine name only (a) from on the machine or anywhere else it resolves via DNS to the public IP of the firewall. From what I can tell the AJP13 connector looks up the hostname only, (which resolves it to the public IP address), then tries to connect to the AJP13 port on the public IP address, and because the firewall blocks this traffic, does not connect, and then gives up. To back this up I have put the hostname on it's own into the hosts file (i.e. a resolves to the private IP), and everything worked again. Before everyone shouts you've got a strange config, it's your problem, I'd like to re-iterate that this issue can be avoided in many ways, and my personal beleif is that the order of preference of fixes would be; 1) Add the address=127.0.0.1 to the default server.xml (which also has the side effect of increasing security). 2) If no address is specified then make the shutdown system start by trying to connect to localhost as opposed to what seems to be the current behaviour of attempting to resolve to an external address first. 3) Require everyone to have the short hostname configured to resolve to their local IP. The reasons for this ordering is that 1 is the least effort by the fewest people, 2 is more effort but by a small group, 3 has a potential impact on all users and no matter where you document it will still be missed by those who beleive in unpack and run. Regards, Al. Al Sutton [EMAIL PROTECTED] wrote on 03.02.2005, 07:58:16: Ben, Thanks for this. I'm not using any settings in JAVA_OPTS as shown below; [EMAIL PROTECTED] al]$ env | grep -i JAVA JRE_HOME=/usr/java/jdk1.4/jre PATH=/usr/java/jdk1.4/bin:/home/al/utils/apache-ant-1.6.2/bin:/usr/kerberos/ bin:/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin JAVA_HOME=/usr/java/jdk1.4
RE: DO NOT REPLY [Bug 33339] - Shutdown script down not work
In answer to your points; on 3) I'm not asking for it tested on all distros, just those where issues have arisen. If no-one has FC2 installed then thats something the group should know about and should be able to say Sorry, no-one has FC2, rather than Closed bug, doesn't work on [insert name of totally different platform here]. The users mail list has a report from Drew Jorgenson if it not working on RHAS 3, and I can confirm I've also seen the behaviour on SLES8 (i.e. a non-redhat product), so I don't think it's distribution specific. on 4) It's never good to write that any other groups efforts off as crappy, I'm sure this group wouldn't be happy if the Fedora group described Tomcat as crappy. We're all doing our best (yes, I have released some open source code in the past), and it worried me that the crappy comment was made and no-one else stepped in to be a bit more helpful. on 5) Given your response I'm happy to offer help with FC2 related problems. I wasn't willing to make this offer before because it seemed the only responses I had were aimed more at getting the bug marked as closed than investigating where the problem was. I'll keep an eye on the -dev list (but unfortunatley I don't have time to look at all the bug report comments) and if I see a problem with FC2 I will attempt to dupluicate it. In case your wondering what my experience is I've been a Linux sys admin for 11 years, and have been programming system in Java for about 8 years with the last 5 spent focused on developing high performance server side applications for Teleco's and Financial institutions, which hopefully will allow me to assist in some way. on the last paragraph - I completely agree. If people know which platforms are fully supported (i.e. if bugs are reported someone can test them easilly) it will make life a lot easier. You'll probably find that in return for listing a platform as full supported the distributor may be receptive to including Tomcat in their product. Costin, I'd like to thank you for the sending the first comprehensive response which makes me feel that users bugs are taken seriously, and not treated as something that should be closed at any costs. Regards, Al. -Original Message- From: news [mailto:[EMAIL PROTECTED] Behalf Of Costin Manolache Sent: 02 February 2005 21:22 To: tomcat-dev@jakarta.apache.org Subject: Re: DO NOT REPLY [Bug 9] - Shutdown script down not work [EMAIL PROTECTED] wrote: 3) Cygwin is definatley NOT a good platform for testing Linux bugs on. However testing with all possible linux distributions is not a good choice either. And distributions based on 'latest' version of everything plus all kind of experimental/non stable/vendor specific stuff - like fedora - are not the best choice for a supported platform. Can you reproduce it on RHEL or RH9 ? If not - report the bug on fedora. 4) Do you want to tell the Fedora guys that the Tomcat developers official view of Fedora Core 2 is that its' a crappy distro? It is not 'official view' - but some developers have issues with FC :-) 5) Do you expect me to re-install my system just to get Tomcat working?, It's easier to replace Tomcat with Jetty than it would be to resintall my machine with one of the distros that you don't consider crappy I believe a lot of products ( and not only java ) officially support only few distributions. We can't ask you to re-install your system - but you can't ask us to reinstall and test your favorite distro either. There are just too many incompatible linux distributions. If jetty works on your linux distro - just use it. It's a fine open source product. Or you can use resin or any other server. Now I'd like to help resolve this, but at the moment all I'm seeing is a wall of not interesting, can't be bothered, lets' mark it as invalid because I can't reproduce on my own personal setup. Which kinda Probably the comments should be more explicit - like 'unsupported platform / not reproductible on supported platforms '. Costin - 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: DO NOT REPLY [Bug 33339] - Shutdown script down not work
Ben, Please re-read my email. It is discussing the initial response I received from the -dev list, and then addressing the issue raised about it being distribution specific. My critisism was that the bug was initially closed when the only attempt to re-produce it I was made aware of was made on a completely different platform and that it initially appeared that the -dev list did not have developers that were willing to investigate the problem. Regards, Al. -Original Message- From: Ben Souther [mailto:[EMAIL PROTECTED] Sent: 02 February 2005 22:25 To: Tomcat Developers List Subject: RE: DO NOT REPLY [Bug 9] - Shutdown script down not work On Wed, 2005-02-02 at 16:54, Al Sutton wrote: In answer to your points; on 3) I'm not asking for it tested on all distros, just those where issues have arisen. If no-one has FC2 installed then thats something the group should know about and should be able to say Sorry, no-one has FC2, rather than Closed bug, doesn't work on [insert name of totally different platform here]. The users mail list has a report from Drew Jorgenson if it not working on RHAS 3, and I can confirm I've also seen the behaviour on SLES8 (i.e. a non-redhat product), so I don't think it's distribution specific. Just for the record, I tested on FC2 and posted the shell session on the users list. You responded to my email before writing this message. I've also stated that I'm willing to upgrade both the kernel and the JDK to test under an environment that is closer to yours. Please don't omit these details when when writing to either list. At the very least, it's dishonest, at worst it's misleading and could cause people to waste time repeating things that have already been done. -Ben - 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: DO NOT REPLY [Bug 33339] - Shutdown script down not work
So let me get this right, just because you can't reproduce it on your system you're not willing to leave it open for others to check, despite the fact you haven't, as yet, told me if your using the same JDK, Linux environment, and you've not waiting for others to comment. Guess the easiest way to get round this is to move to Jetty. Al. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 01 February 2005 22:21 To: tomcat-dev@jakarta.apache.org Subject: DO NOT REPLY [Bug 9] - Shutdown script down not work DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUGĀ· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=9. 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=9 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-02-01 23:21 --- As I said originally, use the mailing list for discussion and to get suggestions from other users. This is not a discussion forum, especially not once two people (myself being the second) have confirmed that this issue is not reproducible. Please don't reopen this issue. -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Patch to Tomcat 5.0 top level build.xml
Please find attached a patch for build.xml properties supplied in the TOMCAT_5.0 branch of the jakarta-tomcat-5 project which ensures that the correct versions of supporting projects are checked out when the checkout target is executed. This patch has been made against code check on in the morning of 29th Jan from the public anonymous CVS repository. Regards, Al. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Patch to Tomcat 5.0 default build properties
Please find attached a patch for the default build properties supplied in the TOMCAT_5.0 branch of the jakarta-tomcat-5 project which corrects the URL to obtain struts from. This patch has been made against code check on in the morning of 29th Jan from the public anonymous CVS repository. Regards, Al. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Patch to Tomcat 5.0
Please find attached a patch for default build properties supplied in the TOMCAT_5.0 branch of the jakarta-tomcat-5 project which alters the location of the servlet-api to reflect where the jakarta-servletapi-5 project is placed when the update or checkou targets are used to obtain the source. This patch has been made against code checked out on the morning of 29th Jan from the public anonymous CVS repository. Regards, Al. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 27006] - libtool: install: error: cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in /usr/lib/apache2
Wow, Thanks Jean you're right :). I still don't understand why I get this error when nobody else seems to. I hope its just a superficial copying thing and that the build process wasn't compromised. Thanks! From: jean-frederic clere [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: DO NOT REPLY [Bug 27006] - libtool: install: error: cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in /usr/lib/apache2 Date: Wed, 10 Mar 2004 09:25:05 +0100 Al Banard wrote: mod_jk2.so is there but libjkjni.so isn't, which seems to be what its complaining about. You should have a libjkjni.so in the .libs directory of jk/build/jk2/apache2. When copied in modules it should work. From a previous email ... make clean build makeOutput - This produces the attached makeOutput file and the following error to the terminal: libtool: install: warning: remember to run `libtool --finish /usr/lib/apache2' libtool: install: error: cannot install `../../../build/jk2/apache2/libjkjni.la' to a directory not ending in /usr/lib/apache2 make[1]: *** [../../../build/jk2/apache2/libjkjni.so] Error 1 make: *** [jk2-build] Error 1 From: Kurt Miller [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: DO NOT REPLY [Bug 27006] - libtool: install: error: cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in /usr/lib/apache2 Date: Tue, 09 Mar 2004 15:26:00 -0500 From: Al Banard [EMAIL PROTECTED] /bin/sh /usr/lib/apache2/build/libtool --silent --mode=install /bin/cp ../../../build/jk2/apache2/mod_jk2.la `pwd`/../../../build/jk2/apache2 ... /bin/sh /usr/lib/apache2/build/libtool --silent --mode=install /bin/cp ../../../build/jk2/apache2/libjkjni.la `pwd`/../../../build/jk2/apache2 make[1]: Leaving directory `/usr/src/redhat/BUILD/jakarta-tomcat-connectors/jk/native2/server/apa che2' This appears to have finished without error. Is mod_jk2.so in ../build/jk2/apache2 now? -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Personalise your mobile chart ringtones and polyphonics. Go to http://ringtones.com.au/ninemsn/control?page=/ninemsn/main.jsp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] signature.asc _ Personalise your mobile chart ringtones and polyphonics. Go to http://ringtones.com.au/ninemsn/control?page=/ninemsn/main.jsp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 27006] - libtool: install: error: cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in /usr/lib/apache2
mod_jk2.so is there but libjkjni.so isn't, which seems to be what its complaining about. From a previous email ... make clean build makeOutput - This produces the attached makeOutput file and the following error to the terminal: libtool: install: warning: remember to run `libtool --finish /usr/lib/apache2' libtool: install: error: cannot install `../../../build/jk2/apache2/libjkjni.la' to a directory not ending in /usr/lib/apache2 make[1]: *** [../../../build/jk2/apache2/libjkjni.so] Error 1 make: *** [jk2-build] Error 1 From: Kurt Miller [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: DO NOT REPLY [Bug 27006] - libtool: install: error: cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in /usr/lib/apache2 Date: Tue, 09 Mar 2004 15:26:00 -0500 From: Al Banard [EMAIL PROTECTED] /bin/sh /usr/lib/apache2/build/libtool --silent --mode=install /bin/cp ../../../build/jk2/apache2/mod_jk2.la `pwd`/../../../build/jk2/apache2 ... /bin/sh /usr/lib/apache2/build/libtool --silent --mode=install /bin/cp ../../../build/jk2/apache2/libjkjni.la `pwd`/../../../build/jk2/apache2 make[1]: Leaving directory `/usr/src/redhat/BUILD/jakarta-tomcat-connectors/jk/native2/server/apa che2' This appears to have finished without error. Is mod_jk2.so in ../build/jk2/apache2 now? -Kurt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Personalise your mobile chart ringtones and polyphonics. Go to http://ringtones.com.au/ninemsn/control?page=/ninemsn/main.jsp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 27006] - libtool: install: error: cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in /usr/lib/apache2
Jean, sorry for the late reply to your previous message, but here is what you requested + exactly what I did. However I did not find any jkjni.la file in the CVS sources and this file wasn't produced. STEPS: tar xzvf jakarta-tomcat-connectors_20040305232049.tar.gz cd jakarta-tomcat-connectors/jk/native2 chmod 0777 buildconf.sh ./buildconf.sh - This produces the following output: rm autom4te.cache libtoolize --force --automake --copy aclocal automake --copy --add-missing automake: configure.in: installing `scripts/build/unix/install-sh' automake: configure.in: installing `scripts/build/unix/mkinstalldirs' automake: configure.in: installing `scripts/build/unix/missing' autoconf - End output ./configure --with-java-home=/opt/sun-jdk-1.4.2.03 --with-apxs2=/usr/sbin/apxs2 --with-tomcat41=/usr/local/tomcat - This produces the following output: checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu checking for a BSD-compatible install... /bin/install -c checking whether build environment is sane... yes checking whether make sets $(MAKE)... yes checking for working aclocal-1.4... found checking for working autoconf... found checking for working automake-1.4... found checking for working autoheader... found checking for working makeinfo... found 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 ld used by GCC... /usr/i686-pc-linux-gnu/bin/ld checking if the linker (/usr/i686-pc-linux-gnu/bin/ld) is GNU ld... yes checking for /usr/i686-pc-linux-gnu/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking for a sed that does not truncate output... /bin/sed checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking command to parse /usr/bin/nm -B output... ok checking how to run the C preprocessor... gcc -E checking for egrep... grep -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 ranlib... ranlib checking for strip... strip checking for objdir... .libs checking for gcc option to produce PIC... -fPIC checking if gcc PIC flag -fPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.lo... yes checking if gcc supports -fno-rtti -fno-exceptions... no checking whether the linker (/usr/i686-pc-linux-gnu/bin/ld) supports shared libraries... yes checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking dynamic linker characteristics... GNU/Linux ld.so checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking whether -lc should be explicitly linked in... no creating libtool checking for test... /usr/bin/test checking for rm... /bin/rm checking for grep... /bin/grep checking for echo... /bin/echo checking for sed... /bin/sed checking for cp... /bin/cp checking for mkdir... /bin/mkdir no apxs given need to check for Perl first, apxs depends on it... checking for perl... /usr/bin/perl building connector for apache-2.0 checking checking for apache13.. not provided checking checking for apache20.. not provided checking checking for iis.. not provided checking checking for iPlanet.. not provided checking for tomcat33 location... not provided checking for tomcat40 location... not provided checking for tomcat41 location... /usr/local/tomcat configure: creating ./config.status config.status: creating Makefile config.status: creating server/apache13/Makefile config.status: creating server/apache13/Makefile.apxs config.status: creating server/apache2/Makefile config.status: creating server/apache2/Makefile.apxs config.status: creating ../build.properties config.status: creating scripts/build/unix/dummy - End output make clean build makeOutput - This produces the attached makeOutput file and the following error to the terminal: libtool: install: warning: remember to run `libtool --finish /usr/lib/apache2' libtool: install: error: cannot install `../../../build/jk2/apache2/libjkjni.la' to a directory not ending in /usr/lib/apache2 make[1]: ***
Re: DO NOT REPLY [Bug 27006] - libtool: install: error: cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in /usr/lib/apache2
For some reason the makeOutput file did not attach so here it is in the flesh... list=' server/apache2'; \ for i in $list; do \ echo Making $target in $i; \ if test $i != .; then \ (cd $i make clean) || exit 1; \ fi; \ done; Making in server/apache2 make[1]: Entering directory `/usr/src/redhat/BUILD/jakarta-tomcat-connectors/jk/native2/server/apache2' rm -rf ../../../build/jk2/apache2/*.lo ../../../build/jk2/apache2/*.la ../../../build/jk2/apache2/*.o ../../../build/jk2/apache2/.libs ../../../build/jk2/apache2/*.so make[1]: Leaving directory `/usr/src/redhat/BUILD/jakarta-tomcat-connectors/jk/native2/server/apache2' list=' server/apache2'; \ for i in $list; do \ echo Making $target in $i; \ if test $i != .; then \ (cd $i make) || exit 1; \ fi; \ done; Making in server/apache2 make[1]: Entering directory `/usr/src/redhat/BUILD/jakarta-tomcat-connectors/jk/native2/server/apache2' mkdir -p ../../../build/jk2/apache2 /bin/sh /usr/lib/apache2/build/libtool --silent --mode=compile gcc -O3 -march=pentium4 -funroll-loops -fprefetch-loop-arrays -pipe -pthread -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I../../include -I/usr/include/apache2 -I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr-util/include -I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr/include -DCHUNK_SIZE=4096 -DUSE_APACHE_MD5 -DHAS_APR -DHAS_AP_PCRE -c ../../common/jk_channel.c -o ../../../build/jk2/apache2/jk_channel.lo /bin/sh /usr/lib/apache2/build/libtool --silent --mode=compile gcc -O3 -march=pentium4 -funroll-loops -fprefetch-loop-arrays -pipe -pthread -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I../../include -I/usr/include/apache2 -I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr-util/include -I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr/include -DCHUNK_SIZE=4096 -DUSE_APACHE_MD5 -DHAS_APR -DHAS_AP_PCRE -c ../../common/jk_channel_apr_socket.c -o ../../../build/jk2/apache2/jk_channel_apr_socket.lo /bin/sh /usr/lib/apache2/build/libtool --silent --mode=compile gcc -O3 -march=pentium4 -funroll-loops -fprefetch-loop-arrays -pipe -pthread -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I../../include -I/usr/include/apache2 -I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr-util/include -I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr/include -DCHUNK_SIZE=4096 -DUSE_APACHE_MD5 -DHAS_APR -DHAS_AP_PCRE -c ../../common/jk_channel_jni.c -o ../../../build/jk2/apache2/jk_channel_jni.lo /bin/sh /usr/lib/apache2/build/libtool --silent --mode=compile gcc -O3 -march=pentium4 -funroll-loops -fprefetch-loop-arrays -pipe -pthread -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I../../include -I/usr/include/apache2 -I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr-util/include -I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr/include -DCHUNK_SIZE=4096 -DUSE_APACHE_MD5 -DHAS_APR -DHAS_AP_PCRE -c ../../common/jk_channel_un.c -o ../../../build/jk2/apache2/jk_channel_un.lo /bin/sh /usr/lib/apache2/build/libtool --silent --mode=compile gcc -O3 -march=pentium4 -funroll-loops -fprefetch-loop-arrays -pipe -pthread -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I../../include -I/usr/include/apache2 -I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr-util/include -I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr/include -DCHUNK_SIZE=4096 -DUSE_APACHE_MD5 -DHAS_APR -DHAS_AP_PCRE -c ../../common/jk_config.c -o ../../../build/jk2/apache2/jk_config.lo /bin/sh /usr/lib/apache2/build/libtool --silent --mode=compile gcc -O3 -march=pentium4 -funroll-loops -fprefetch-loop-arrays -pipe -pthread -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I../../include -I/usr/include/apache2 -I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr-util/include -I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr/include -DCHUNK_SIZE=4096 -DUSE_APACHE_MD5 -DHAS_APR -DHAS_AP_PCRE -c ../../common/jk_config_file.c -o ../../../build/jk2/apache2/jk_config_file.lo /bin/sh /usr/lib/apache2/build/libtool --silent --mode=compile gcc -O3 -march=pentium4 -funroll-loops -fprefetch-loop-arrays -pipe -pthread -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -I../../include -I/usr/include/apache2 -I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr-util/include -I/var/tmp/portage/apache-2.0.48-r1/work/httpd-2.0.48/srclib/apr/include -DCHUNK_SIZE=4096 -DUSE_APACHE_MD5 -DHAS_APR -DHAS_AP_PCRE -c ../../common/jk_endpoint.c -o ../../../build/jk2/apache2/jk_endpoint.lo /bin/sh /usr/lib/apache2/build/libtool --silent
Re: DO NOT REPLY [Bug 27006] - libtool: install: error: cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in /usr/lib/apache2
I tried the latest CVS (using --with-apxs2) on the 25th Feb and got exactly the same error, unless things have changed with regard to this between now and then. From: Kurt Miller [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: DO NOT REPLY [Bug 27006] - libtool: install: error: cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in /usr/lib/apache2 Date: Thu, 26 Feb 2004 12:27:41 -0500 Are you using the current source from CVS or http://cvs.apache.org/snapshots/jakarta-tomcat-connectors/ yet? libtool is set correctly for you in the current version. Simply configure with --with-apxs2 with current source and it should be correctly set for you. From: Al Banard [EMAIL PROTECTED] Thanks, Unfortunately my OS is Gentoo and after installing there ebuild (basically equivalent to an RPM) directories are all over the place. The base location of apache is actually /etc/apache2 but when I try using this as a configure option I get this message: building connector for apache-2.0 configure: error: can't locate /etc/apache2/ and configure dies. Here is a list of the more relevant files that were installed with the package. Do you have any idea as to what I should put as my argumernt to the configure option? libtool is in /usr/lib/apache2/build/libtool but I've tried passing different combinations of this path without any luck. bash-2.05b# qpkg -l apache net-www/apache-2.0.48-r1 * CONTENTS: (Please view previous email on this topic for file list, I didn't want to keep posting this to keep the post size down) From: jean-frederic clere [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: DO NOT REPLY [Bug 27006] - libtool: install: error: cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in /usr/lib/apache2 Date: Tue, 24 Feb 2004 16:16:31 +0100 Al Banard wrote: Hi Henri, Thanks for giving me help. OK, I have to admit I don't know a lot about libtool. I'm using apache 2.0.48 and have also installed apr-0.9.2. How do I specify to use the libtool from Apache 2.0 / APR? That is what is done when you use --with-apache2=$HOME/httpd-2.0.48. It works for me with the actual CVS and libtool-1.5.2 and automake-1.6.1 (I build and install automake after libtool). From: Henri Gomez [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: DO NOT REPLY [Bug 27006] - libtool: install: error: cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in /usr/lib/apache2 Date: Tue, 24 Feb 2004 14:57:49 +0100 Continuing this thread on tomcat-dev. Well you should use the libtool from Apache 2.0 / APR. Which version of Apache 2.0 are you using ? [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27006. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27006 libtool: install: error: cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in /usr/lib/apache2 --- Additional Comments From [EMAIL PROTECTED] 2004-02-24 13:53 --- I just tried libtool 1.5.2-r3 and I still get the same error. Can you think of anything else (program versions / configure options / steps) I might be doing differently to you? Here is a recap of my steps: cd jakarta-tomcat-connectors-jk2-2.0.2-src/jk/native2/ chmod 0777 buildconf.sh ./buildconf.sh ./configure --with-java-home=/opt/sun-jdk-1.4.2.03 --with-apxs2=/usr/sbin/apxs2 --with-tomcat41=/usr/local/tomcat make clean build libtool --finish /usr/lib/apache2 -- _ SEEK: Now with over 50,000 dream jobs! Click here http://ninemsn.seek.com.au/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 27006] - libtool: install: error: cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in /usr/lib/apache2
Thanks, Unfortunately my OS is Gentoo and after installing there ebuild (basically equivalent to an RPM) directories are all over the place. The base location of apache is actually /etc/apache2 but when I try using this as a configure option I get this message: building connector for apache-2.0 configure: error: can't locate /etc/apache2/ and configure dies. Here is a list of the more relevant files that were installed with the package. Do you have any idea as to what I should put as my argumernt to the configure option? libtool is in /usr/lib/apache2/build/libtool but I've tried passing different combinations of this path without any luck. bash-2.05b# qpkg -l apache net-www/apache-2.0.48-r1 * CONTENTS: /usr /usr/include /usr/include/apache2 /usr/include/apache2/apr.h /usr/include/apache2/apr_allocator.h /usr/include/apache2/apr_atomic.h ... /usr/include/apache2/ssl_util_ssl.h /usr/include/apache2/ssl_util_table.h /usr/include/apache2/pcre.h /usr/include/apache2/unixd.h /usr/lib /usr/lib/libapr-0.so.0.9.5 /usr/lib/libapr-0.so.0 - libapr-0.so.0.9.5 /usr/lib/libapr-0.so - libapr-0.so.0.9.5 /usr/lib/libapr-0.la /usr/lib/libapr-0.a /usr/lib/apr.exp /usr/lib/apache2 /usr/lib/apache2/build /usr/lib/apache2/build/libtool /usr/lib/apache2/build/apr_rules.mk /usr/lib/apache2/build/config_vars.mk /usr/lib/apache2/build/library.mk /usr/lib/apache2/build/ltlib.mk /usr/lib/apache2/build/program.mk /usr/lib/apache2/build/rules.mk /usr/lib/apache2/build/special.mk /usr/lib/apache2/build/instdso.sh /usr/lib/apache2/build/config.nice /usr/lib/apache2/build/envvars /usr/lib/apache2/build/envvars-std /usr/lib/apache2/mod_access.so /usr/lib/apache2/mod_auth.so /usr/lib/apache2/mod_auth_anon.so ... /usr/lib/apache2/mod_userdir.so /usr/lib/apache2/mod_alias.so /usr/lib/apache2/mod_rewrite.so /usr/lib/apache2/httpd.exp /usr/lib/libaprutil-0.so.0.9.5 /usr/lib/libaprutil-0.so.0 - libaprutil-0.so.0.9.5 /usr/lib/libaprutil-0.so - libaprutil-0.so.0.9.5 /usr/lib/libaprutil-0.la /usr/lib/libaprutil-0.a /usr/lib/aprutil.exp /usr/lib/ssl /usr/lib/ssl/apache2-mod_ssl /usr/lib/ssl/apache2-mod_ssl/gentestcrt.sh /usr/lib/apache2-extramodules /usr/lib/apache2-extramodules/mod_ssl.so /usr/bin /usr/bin/apr-config /usr/bin/apu-config /usr/sbin /usr/sbin/ab2 /usr/sbin/logresolve2 /usr/sbin/apxs2 /usr/sbin/dbmmanage2 /usr/sbin/ab2-ssl /usr/sbin/suexec2 /usr/sbin/htdbm /usr/sbin/htdigest2 /usr/sbin/checkgid2 /usr/sbin/rotatelogs2 /usr/sbin/apache2 /usr/sbin/apache2logserverstatus /usr/sbin/apache2splitlogfile /usr/sbin/list_hooks2.pl /usr/sbin/logresolve2.pl /usr/sbin/apache2ctl /usr/sbin/htpasswd2 /usr/sbin/split-logfile2 /usr/sbin/log_server_status2 /usr/share /usr/share/man /usr/share/man/man1 ... /usr/share/man/man8/apache2.8.gz /usr/share/man/man8/apache2ctl.8.gz /usr/share/man/man8/logresolve2.8.gz /usr/share/doc /usr/share/doc/apache-2.0.48-r1 /usr/share/doc/apache-2.0.48-r1/manual ... From: jean-frederic clere [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: DO NOT REPLY [Bug 27006] - libtool: install: error: cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in /usr/lib/apache2 Date: Tue, 24 Feb 2004 16:16:31 +0100 Al Banard wrote: Hi Henri, Thanks for giving me help. OK, I have to admit I don't know a lot about libtool. I'm using apache 2.0.48 and have also installed apr-0.9.2. How do I specify to use the libtool from Apache 2.0 / APR? That is what is done when you use --with-apache2=$HOME/httpd-2.0.48. It works for me with the actual CVS and libtool-1.5.2 and automake-1.6.1 (I build and install automake after libtool). From: Henri Gomez [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: DO NOT REPLY [Bug 27006] - libtool: install: error: cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in /usr/lib/apache2 Date: Tue, 24 Feb 2004 14:57:49 +0100 Continuing this thread on tomcat-dev. Well you should use the libtool from Apache 2.0 / APR. Which version of Apache 2.0 are you using ? [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27006. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27006 libtool: install: error: cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in /usr/lib/apache2 --- Additional Comments From [EMAIL PROTECTED] 2004-02-24 13:53 --- I just tried libtool 1.5.2-r3 and I still get the same error. Can you think of anything else (program versions / configure options / steps) I might be doing differently to you? Here is a recap of my steps: cd jakarta-tomcat-connectors-jk2-2.0.2-src/jk/native2/ chmod 0777 buildconf.sh ./buildconf.sh ./configure
Re: DO NOT REPLY [Bug 27006] - libtool: install: error: cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in /usr/lib/apache2
Hi Henri, Thanks for giving me help. OK, I have to admit I don't know a lot about libtool. I'm using apache 2.0.48 and have also installed apr-0.9.2. How do I specify to use the libtool from Apache 2.0 / APR? From: Henri Gomez [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: DO NOT REPLY [Bug 27006] - libtool: install: error: cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in /usr/lib/apache2 Date: Tue, 24 Feb 2004 14:57:49 +0100 Continuing this thread on tomcat-dev. Well you should use the libtool from Apache 2.0 / APR. Which version of Apache 2.0 are you using ? [EMAIL PROTECTED] wrote: DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27006. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27006 libtool: install: error: cannot install `../../../build/jk2/apache2/jkjni.la' to a directory not ending in /usr/lib/apache2 --- Additional Comments From [EMAIL PROTECTED] 2004-02-24 13:53 --- I just tried libtool 1.5.2-r3 and I still get the same error. Can you think of anything else (program versions / configure options / steps) I might be doing differently to you? Here is a recap of my steps: cd jakarta-tomcat-connectors-jk2-2.0.2-src/jk/native2/ chmod 0777 buildconf.sh ./buildconf.sh ./configure --with-java-home=/opt/sun-jdk-1.4.2.03 --with-apxs2=/usr/sbin/apxs2 --with-tomcat41=/usr/local/tomcat make clean build libtool --finish /usr/lib/apache2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Hot chart ringtones and polyphonics. Go to http://ninemsn.com.au/mobilemania/default.asp - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Please Help, Building JK2 failed
Anonymous CVS from where? Why checkout from CVS? I am trying to build a production JK2, not checkout development code. My source came from the jakarta site as a release. -Original Message- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Costin Manolache Sent: Wednesday, March 12, 2003 10:38 AM To: [EMAIL PROTECTED] Subject: Re: Please Help, Building JK2 failed Al wrote: jkant: BUILD FAILED file:/usr/local/web/tmp/apache/JK2/jakarta-tomcat-connectors-jk2-2.0.2 -s rc/jk/build.xml:235: Warning: Could not find file /usr/local/web/tmp/apache/JK2/jakarta-tomcat-connectors-jk2-2.0.2-src/jk /jkant/ant.tasks to copy. Where did you got the sources ? Try using anonymous CVS - the file should be there. Costin - 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]
Please Help, Building JK2 failed
Hi. I am trying to build JK2 on AIX 4.3.3. I have run ant already and it has successfully built. I am getting the error when running ant native. It is looking for the file ant.tasks but that file is not on my machine. Is the build suppose to make it? Am I suppose to download it from somewhere? Could someone tell me what I am doing wrong? Thanks, Al [EMAIL PROTECTED] The error is ... ant native Buildfile: build.xml jkant: BUILD FAILED file:/usr/local/web/tmp/apache/JK2/jakarta-tomcat-connectors-jk2-2.0.2-s rc/jk/build.xml:235: Warning: Could not find file /usr/local/web/tmp/apache/JK2/jakarta-tomcat-connectors-jk2-2.0.2-src/jk /jkant/ant.tasks to copy. Total time: 39 seconds ~~~ Old Chinese proverb says, No use to run, Grasshopper, if you are on the wrong road.
Re: Cocoon 2 Dumps Tomcat 4.1 on Apache1.3.22 SSL
Resubmitting since I can not solve this issue on my own. Please find the space dump in the attached file. I am testing new installation of Apache 1.3.22 SSL, Tomcat 4.0.1 with mod_webapp on RH Linux 7.1 __ Do You Yahoo!? Great stuff seeking new owners in Yahoo! Auctions! http://auctions.yahoo.com Starting service Tomcat-Apache Apache Tomcat/4.0 Starting service MackConnector Apache Tomcat/4.0 Server 1.6 is running Press [Ctrl]+[C] to abort SIGSEGV 11* segmentation violation si_signo [11]: SIGSEGV 11* segmentation violation si_errno [0]: Success si_code [1]: SEGV_MAPERR [addr: 0x0] stackpointer=0x448dab88 Full thread dump Classic VM (1.2.2-L, green threads): Thread-15 (TID:0x40eb3fd0, sys_thread_t:0x9602250, state:R) prio=5 at java.lang.ClassLoader.findLoadedClass(Native Method) at java.lang.ClassLoader.loadClass(ClassLoader.java:275) at java.lang.ClassLoader.loadClass(ClassLoader.java:243) at org.apache.avalon.excalibur.component.ExcaliburComponentManager.lookup(Unknown Source) at org.apache.avalon.excalibur.component.ExcaliburComponentManager.lookup(Unknown Source) at org.apache.cocoon.sitemap.AbstractSitemap.compose(AbstractSitemap.java:123) at org.apache.avalon.excalibur.component.DefaultComponentFactory.newInstance(Unknown Source) at org.apache.avalon.excalibur.component.ThreadSafeComponentHandler.initialize(Unknown Source) at org.apache.cocoon.components.language.generator.GeneratorSelector.addGenerator(GeneratorSelector.java:135) at org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.addCompiledComponent(ProgramGeneratorImpl.java:345) at org.apache.cocoon.components.language.generator.ProgramGeneratorImpl.load(ProgramGeneratorImpl.java:179) at org.apache.cocoon.sitemap.Handler.run(Handler.java:208) at java.lang.Thread.run(Thread.java:475) Thread-14 (TID:0x40e57510, sys_thread_t:0x862f2b0, state:CW) prio=5 at java.net.SocketInputStream.socketRead(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:86) at java.io.BufferedInputStream.fill(BufferedInputStream.java:186) at java.io.BufferedInputStream.read(BufferedInputStream.java:204) at java.io.DataInputStream.readUnsignedShort(DataInputStream.java:288) at java.io.DataInputStream.readUTF(DataInputStream.java:517) at java.io.DataInputStream.readUTF(DataInputStream.java:494) at org.hsqldb.ServerConnection.run(ServerConnection.java:116) Thread-12 (TID:0x40e57668, sys_thread_t:0x92ec350, state:CW) prio=5 at java.net.SocketInputStream.socketRead(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:86) at java.io.BufferedInputStream.fill(BufferedInputStream.java:186) at java.io.BufferedInputStream.read(BufferedInputStream.java:204) at java.io.DataInputStream.readUnsignedShort(DataInputStream.java:288) at java.io.DataInputStream.readUTF(DataInputStream.java:517) at java.io.DataInputStream.readUTF(DataInputStream.java:494) at org.hsqldb.ServerConnection.run(ServerConnection.java:116) Thread-10 (TID:0x40e577c0, sys_thread_t:0x95bf928, state:CW) prio=5 at java.net.SocketInputStream.socketRead(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:86) at java.io.BufferedInputStream.fill(BufferedInputStream.java:186) at java.io.BufferedInputStream.read(BufferedInputStream.java:204) at java.io.DataInputStream.readUnsignedShort(DataInputStream.java:288) at java.io.DataInputStream.readUTF(DataInputStream.java:517) at java.io.DataInputStream.readUTF(DataInputStream.java:494) at org.hsqldb.ServerConnection.run(ServerConnection.java:116) Thread-8 (TID:0x40e57920, sys_thread_t:0x94e4c00, state:CW) prio=5 at java.net.SocketInputStream.socketRead(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:86) at java.io.BufferedInputStream.fill(BufferedInputStream.java:186) at java.io.BufferedInputStream.read(BufferedInputStream.java:204) at java.io.DataInputStream.readUnsignedShort(DataInputStream.java:288) at java.io.DataInputStream.readUTF(DataInputStream.java:517) at java.io.DataInputStream.readUTF(DataInputStream.java:494) at org.hsqldb.ServerConnection.run(ServerConnection.java:116) Thread-6 (TID:0x40ea5510, sys_thread_t:0x95c26c0, state:CW) prio=5 at java.lang.Thread.sleep(Native Method) at org.hsqldb.Log.run(Log.java:119) at java.lang.Thread.run(Thread.java:475) Thread-5 (TID:0x40ee9290, sys_thread_t:0x93278c8, state:CW) prio=5 at