Re: [5.0] Procrun problems / New loader
Remy Maucherat wrote: Hi, I've switched (temporarily, maybe) away from JavaService to Procrun. The problem is that I couldn't get it to work. In the install script, I'm using the following command: ExecWait '$INSTDIR\bin\tomcatw.exe //IS//Tomcat5 --DisplayName Apache Tomcat @VERSION@ --Description Apache Tomcat @VERSION@ Server http://jakarta.apache.org/tomcat; --Install $INSTDIR\bin\tomcat.exe --ImagePath $INSTDIR\bin\bootstrap.jar --StartupClass org.apache.catalina.startup.Bootstrap;main;start --ShutdownClass org.apache.catalina.startup.Bootstrap;main;stop --Java auto --JavaOptions -Djava.endorsed.dirs=$INSTDIR\common\endorsed#-Dcatalina.home=$INSTDIR --StdOutputFile $INSTDIR\logs\stdout.log --StdErrorFile $INSTDIR\logs\stderr.log --WorkingPath $INSTDIR' Have you try without the @VERSION@? I believe this is correct, and using the test mode sort of works (except that the console output doesn't get redirected). Trying to run the service doesn't work at all, and looking in the registry, it doesn't seem to have the needed parameters (so I wonder how the test mode does work). Also, Procrun doesn't seem to be designed to handle Tomcat in service mode (that is, where Tomcat doesn't block and wait for a shutdown command). Mladen, I think I need some help :) Other that that, there are now too many ways to start Tomcat in standalone mode: - Bootstrap - The launcher - JMX I think the most compelling is to use the launcher + JMX (and allow JMX only also). Basically, in the Windows distribution, there are some incosistencies, as the scripts use the launcher, while the service uses direct invocation of Bootstrap. I can't do those changes alone. Comments ? Java code of daemon: jakarta-commons-sandbox/daemon/src/java/org/apache/commons/daemon Java code of launcher: jakarta-commons-sandbox/daemon/src/java/org/apache/commons/launcher C code of procrun: jakarta-commons-sandbox/daemon/src/native/nt/procrun C code of daemon: jakarta-commons-sandbox/daemon/src/native (except nt/procrun) I am using daemon to start Tomcat as normal user but listening on port 80 on Linux. I am also using daemon (with cygwin) to run Tomcat on windoze but I am thinking to change to procrun for that platfrom. For the moment I have not enough time to look to launcher nor JMX. Remy - 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: [5.0] Procrun problems / New loader
jean-frederic clere wrote: Remy Maucherat wrote: Hi, I've switched (temporarily, maybe) away from JavaService to Procrun. The problem is that I couldn't get it to work. In the install script, I'm using the following command: ExecWait '$INSTDIR\bin\tomcatw.exe //IS//Tomcat5 --DisplayName Apache Tomcat @VERSION@ --Description Apache Tomcat @VERSION@ Server http://jakarta.apache.org/tomcat; --Install $INSTDIR\bin\tomcat.exe --ImagePath $INSTDIR\bin\bootstrap.jar --StartupClass org.apache.catalina.startup.Bootstrap;main;start --ShutdownClass org.apache.catalina.startup.Bootstrap;main;stop --Java auto --JavaOptions -Djava.endorsed.dirs=$INSTDIR\common\endorsed#-Dcatalina.home=$INSTDIR --StdOutputFile $INSTDIR\logs\stdout.log --StdErrorFile $INSTDIR\logs\stderr.log --WorkingPath $INSTDIR' Have you try without the @VERSION@? It's an Ant token, so it gets replaced before invoking NSIS anyway. The service parameters now gets populated correctly (I looked at the source code to find out where they were going), but: - err and out redirection doesn't seem to work (the console stays blank, as do the logs, and all output goes into the console) - procrunw still flashes a console when it's used; I thought it was supposed not to - WorkingPath doesn't seem to do anything - JavaOptions doesn't either :-( If I call the test service mode from the right directory (the Catalina home), then it works ok. Additionally, it seems that the daemon must block until stop is called to work. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Procrun problems / New loader
[EMAIL PROTECTED] wrote: -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: 17. veljaa 2003 9:38 To: Tomcat Developers List Subject: Re: [5.0] Procrun problems / New loader jean-frederic clere wrote: Remy Maucherat wrote: I've switched (temporarily, maybe) away from JavaService to Procrun. The problem is that I couldn't get it to work. In the install script, I'm using the following command: ExecWait '$INSTDIR\bin\tomcatw.exe //IS//Tomcat5 --DisplayName Apache Tomcat @VERSION@ --Description Apache Tomcat @VERSION@ Server http://jakarta.apache.org/tomcat; --Install $INSTDIR\bin\tomcat.exe --ImagePath $INSTDIR\bin\bootstrap.jar --StartupClass org.apache.catalina.startup.Bootstrap;main;start --ShutdownClass org.apache.catalina.startup.Bootstrap;main;stop --Java auto --JavaOptions -Djava.endorsed.dirs=$INSTDIR\common\endorsed#- Dcatalina.home=$INSTDIR --StdOutputFile $INSTDIR\logs\stdout.log --StdErrorFile $INSTDIR\logs\stderr.log --WorkingPath $INSTDIR' Have you try without the @VERSION@? It's an Ant token, so it gets replaced before invoking NSIS anyway. The service parameters now gets populated correctly (I looked at the source code to find out where they were going), but: - err and out redirection doesn't seem to work (the console stays blank, as do the logs, and all output goes into the console) Those can be used only if you redirect onother process. Try with -Java java. Dunno how to redirect the console of the current process. Setting handles doesn't help. The only thing that can be used is API Hooking, but that's too much for now. I was using -Java auto. I thought it was supposed to be the same. - procrunw still flashes a console when it's used; I thought it was supposed not to It shouldn't. But the problem is that I made the wrong binaries using devcpp. Try with the lates build. - WorkingPath doesn't seem to do anything Not when using JVM. For redirected app it sets the Working Directory when calling the CreateProcess. That seems to be a plausible explanation. I had looked at the source, and it seemed to be making the CreateProcess call using the right paramter. - JavaOptions doesn't either :-( Here is how it works for me: procrunw //IS//Tomcat4 --DisplayName Tomcat 4.1.19 --Description Tomcat 4.1.19 LE JDK 1.4 http://jakarta.apache.org; --ImagePath c:\devtools\tomcat\41\bin\bootstrap.jar --StartupClass org.apache.catalina.startup.Bootstrap;main;start --ShutdownClass org.apache.catalina.startup.Bootstrap;main;stop --Java auto --JavaOptions -Dcatalina.home=c:\devtools\tomcat\41#-Xmx128M#-Dtomcat.home=c:\devtools \tomcat\41 Perhaps you exceeded the command line length. Try using the Procrunw //IS//Tomcat minimum params (ServiceName, DisplayName, ImagePath, and Install). Then Procrunw //US//Tomcat extra params (update service changing or adding params.) Well, I checked with the registry, and everything gets registered ok with one single call. Update also works good. You can call the //US as many times as you wish. Also check if some installation params that NSIS process have emedded spaces. In that case you'll need to quote that params. --JavaOptions needs the next argument as single string so it need to be quoted. --Dcatalina.home=\some location\#etc... Yes, I sort of figured that out. I tried hacking the value in the registry without much success. How and are the params set correctly, can be seen in the registry: HKLM\\SOFTWARE\\Apache Software Foundation\\Process Runner 1.0\\ServiceName\\Parameters. The JavaOptions is MULTI_SZ, and you can check the params there. Yes, I had already found out everything was there. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Request to Fix Tomcat Standalone 302 redirect Issue
Bill Barker wrote: - Original Message - From: neal [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Sunday, February 16, 2003 8:00 PM Subject: RE: Request to Fix Tomcat Standalone 302 redirect Issue So it *will* be in tomcat 5? My head is spinning...so confusing. How does one access o.a.t.u.http.mapper.Mapper? Is this something that will be configurable via web.xml? It will be in configurable in 'server.xml' (or, at least it will be when I do my next commit :). Good, the code looks like as if I had written it myself :) However, it poses the usual security problems, and breaks the admin webapp. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Request to Fix Tomcat Standalone 302 redirect Issue
What are the security problems and why doesn't Apache or other major web servers have this problem (or do they)? If this is made optional (with the default turned off) is the problem with it breaking an app ... really a problem? -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 1:58 AM To: Tomcat Developers List Subject: Re: Request to Fix Tomcat Standalone 302 redirect Issue Bill Barker wrote: - Original Message - From: neal [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Sunday, February 16, 2003 8:00 PM Subject: RE: Request to Fix Tomcat Standalone 302 redirect Issue So it *will* be in tomcat 5? My head is spinning...so confusing. How does one access o.a.t.u.http.mapper.Mapper? Is this something that will be configurable via web.xml? It will be in configurable in 'server.xml' (or, at least it will be when I do my next commit :). Good, the code looks like as if I had written it myself :) However, it poses the usual security problems, and breaks the admin webapp. Remy - 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]
[GUMP] Build Failure - jakarta-tomcat-catalina
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-02-17/jakarta-tomcat-catalina.html
Buildfile: build.xml
deploy-prepare:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build
deploy-static:
deploy-catalina:
[echo] Target: Catalina - Deploy ...
flags:
flags.display:
[echo] --- Build environment for Catalina ---
[echo] If ${property_name} is displayed, then the property is not set)
[echo] --- Build options ---
[echo] full.dist=${full.dist}
[echo] build.sysclasspath=only
[echo] compile.debug=${compile.debug}
[echo] compile.deprecation=${compile.deprecation}
[echo] compile.optimize=${compile.optimize}
[echo] --- Ant Flags ---
[echo] style task available (required)=true
[echo] --- JDK ---
[echo] jdk.1.2.present=true
[echo] jdk.1.3.present=true
[echo] jdk.1.4.present=true
[echo] --- Source Dependencies ---
[echo] jtc.home.present=true
[echo] --- Required Libraries ---
[echo] beanutils.present=true
[echo] collections.present=true
[echo] digester.present=true
[echo] jaxp.present=true
[echo] jndi.present=true
[echo] logging.present=true
[echo] regexp.present=true
[echo] --- Optional Libraries ---
[echo] dbcp.present=true
[echo] fileupload.present=true
[echo] jaas.present=true
[echo] javamail.present=true
[echo] jmx.present=true
[echo] jsse.present=true
[echo] jta.present=true
[echo] junit.present=true
[echo] lang.present=${lang.present}
[echo] launcher.present=${launcher.present}
[echo] launcher.bootstrap.present=${launcher.bootstrap.present}
[echo] ldap.present=true
[echo] modeler.present=true
[echo] pool.present=true
[echo] tyrex.present=${tyrex.present}
[echo] --- Required JARs ---
[echo] jndi.jar.present(except JDK 1.3+)=true
[echo] regexp.jar.present=true
[echo] servlet-api.jar.present=true
[echo] xerces2.jars.present(except JDK 1.4+)=true
[echo] --- Optional JARs ---
[echo] dbcp.jar.present=true
[echo] fileupload.jar.present=true
[echo] jaas.jar.present=true
[echo] javamail.jar.present=true
[echo] jdbc20ext.jar.present=true
[echo] jmx.jar.present=true
[echo] jta.jar.present=true
[echo] junit.jar.present=${junit.jar.present}
[echo] modeler.jar.present=true
[echo] pool.jar.present=true
[echo] tyrex.jar.present=${tyrex.jar.present}
[echo] --- Conditional compilation flags ---
[echo] compile.dbcp=true
[echo] compile.jaas=true
[echo] compile.javamail=true
[echo] compile.jmx=true
[echo] compile.jndi=true
[echo] compile.jsse=true
[echo] compile.jta=true
[echo] compile.junit=true
[echo] compile.ldap=true
[echo] compile.ssi=true
[echo] compile.tyrex=${compile.tyrex}
[echo] --- Distribution flags ---
[echo] copy.dbcp.jar=true
[echo] copy.jmx.jar=true
[echo] copy.launcher.jars=${copy.launcher.jars}
[echo] copy.logging.jar=true
[echo] copy.modeler.jar=true
[echo] copy.pool.jar=true
build-prepare:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/bin
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-tomcat-catalina/build/common/classes
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/common/lib
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-tomcat-catalina/build/common/endorsed
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/conf
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/logs
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-tomcat-catalina/build/server/classes
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/server/lib
[mkdir] Created dir:
/home/rubys/jakarta/jakarta-tomcat-catalina/build/shared/classes
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/shared/lib
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/work
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-catalina/build/temp
copy-dbcp.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-catalina/build/common/lib
copy-fileupload.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-catalina/build/server/lib
copy-jmx.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-catalina/build/server/lib
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-catalina/build/server/lib
copy-launcher.jars:
copy-modeler.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-catalina/build/server/lib
copy-pool.jar:
[copy] Copying 1 file to
/home/rubys/jakarta/jakarta-tomcat-catalina/build/common/lib
copy-xerces2.jars:
[GUMP] Build Failure - jakarta-tomcat-jk-native
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-02-17/jakarta-tomcat-jk-native.html
Buildfile: build.xml
init:
[echo] /home/rubys
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-connectors/jk/build/jk
apache20:
apache13:
iis:
netscape:
jni:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-connectors/jk/build/jk/jni
[so] Compiling 4 out of 4
Compiling /home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/common/jk_map.c
Compiling /home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/common/jk_pool.c
Compiling /home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/common/jk_util.c
Compiling /home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/jni/jk_jnicb.c
[so] Compile failed 1
/home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/jni/jk_jnicb.c
[so] Command:libtool --mode=compile cc -c -o
/home/rubys/jakarta/jakarta-tomcat-connectors/jk/build/jk/jni/jni/jk_jnicb.o
-I/home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/common
-I/home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/jni
-I/usr/java/j2sdk1.4.1_01/jre/../include -I${build.compiler.base}/include -g -W
/home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/jni/jk_jnicb.c
[so] Output:
[so] mkdir
/home/rubys/jakarta/jakarta-tomcat-connectors/jk/build/jk/jni/jni/.libs
[so] cc -c -I/home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/common
-I/home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/jni
-I/usr/java/j2sdk1.4.1_01/jre/../include -I\${build.compiler.base}/include -g -W
/home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/jni/jk_jnicb.c -fPIC -DPIC
-o /home/rubys/jakarta/jakarta-tomcat-connectors/jk/build/jk/jni/jni/.libs/jk_jnicb.lo
[so] StdErr:
[so] In file included from
/home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/jni/jk_jnicb.h:2,
[so] from
/home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/jni/jk_jnicb.c:64:
[so] /usr/java/j2sdk1.4.1_01/include/jni.h:27:20: jni_md.h: No such file or
directory
BUILD FAILED
file:///home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/build.xml:63: Compile
failed /home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/jni/jk_jnicb.c
Total time: 6 seconds
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.0] Procrun problems / New loader
-Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: 17. veljaa 2003 11:28 To: Tomcat Developers List Subject: Re: [5.0] Procrun problems / New loader [EMAIL PROTECTED] wrote: Those can be used only if you redirect onother process. Try with -Java java. Ok, it's the magic parameter indeed :) Rereading the readme.txt, it looks like it's supposed to be equivalent to auto. Another question: Can I use procrun on 9x ? There's a duplication of functionality between procrun and the laucher. Should procrun call the laucher, which then calls the launcher ? It seems like a waste of resources, so maybe procrun should go directly to Tomcat ;-) It could, need some API cheching. There is no CreateRemoteThread API, and Services alltogether. The simplest would be using some #ifdefs and and another build. If the nsis installer can distinguish the host OS, than we can make something like procrun9x. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Procrun problems / New loader
[EMAIL PROTECTED] wrote: It could, need some API cheching. There is no CreateRemoteThread API, and Services alltogether. The simplest would be using some #ifdefs and and another build. If the nsis installer can distinguish the host OS, than we can make something like procrun9x. That's doable. I don't know if it's really useful, though. Or we decide we should stop caring about Win 9x for the installer. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.0] Procrun problems / New loader
-Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] The simplest would be using some #ifdefs and and another build. If the nsis installer can distinguish the host OS, than we can make something like procrun9x. That's doable. I don't know if it's really useful, though. Or we decide we should stop caring about Win 9x for the installer. +1. One who is enthusiast enough to use the TC on DOS box is certainly capable of setting that up ;-). MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Procrun problems / New loader
[EMAIL PROTECTED] wrote: -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: 17. veljaa 2003 11:28 To: Tomcat Developers List Subject: Re: [5.0] Procrun problems / New loader [EMAIL PROTECTED] wrote: Those can be used only if you redirect onother process. Try with -Java java. Ok, it's the magic parameter indeed :) Rereading the readme.txt, it looks like it's supposed to be equivalent to auto. Another question: Can I use procrun on 9x ? There's a duplication of functionality between procrun and the laucher. Should procrun call the laucher, which then calls the launcher ? It seems like a waste of resources, so maybe procrun should go directly to Tomcat ;-) It could, need some API cheching. There is no CreateRemoteThread API, and Services alltogether. The simplest would be using some #ifdefs and and another build. If the nsis installer can distinguish the host OS, than we can make something like procrun9x. #ifdefs No... I remember doing this in instmain.c (jakarta-commons-sandbox/daemon/src/native/nt/service). Should I copy/adapte this code to procrun? MT. - 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]
[4.1.20] Stability rating
I would like comments on bug 17049 before deciding what to do with 4.1.20. If this turns out to be a relatively minor issue, I would be ok with releasing 4.1.20 as a beta, and would propose a vote. For 4.1.21, there are apparently some patches for better taglib handling to be integrated in JspC. Other than that, it looks good enough to me. Thanks, Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [5.0] Procrun problems / New loader
-Original Message- From: jean-frederic clere [mailto:[EMAIL PROTECTED]] Sent: 17. veljaa 2003 12:14 To: Tomcat Developers List Subject: Re: [5.0] Procrun problems / New loader #ifdefs No... I remember doing this in instmain.c (jakarta-commons-sandbox/daemon/src/native/nt/service). Should I copy/adapte this code to procrun? Well, that was just an idea (using ifdefs), you can use OS guessing inside the procrun itself. In that case you'll need to make something like procrun_install_service9x and call that instead procrun_install_service. Also you'll need the wrap the update_service and delete_service functions. I would like to see that as a new functions, not just to support the 9x inside the existing one. Everthing else should work as is, so you are wellcome to copy that from instmain. MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Procrun problems / New loader
[EMAIL PROTECTED] wrote: -Original Message- From: jean-frederic clere [mailto:[EMAIL PROTECTED]] Sent: 17. veljaa 2003 12:14 To: Tomcat Developers List Subject: Re: [5.0] Procrun problems / New loader #ifdefs No... I remember doing this in instmain.c (jakarta-commons-sandbox/daemon/src/native/nt/service). Should I copy/adapte this code to procrun? Well, that was just an idea (using ifdefs), you can use OS guessing inside the procrun itself. In that case you'll need to make something like procrun_install_service9x and call that instead procrun_install_service. Also you'll need the wrap the update_service and delete_service functions. I would like to see that as a new functions, not just to support the 9x inside the existing one. That is what instmain.c is doing. +++ if (isWindowsNT()) done = InstallSvcNT(szExePath); else done = InstallSvc(szExePath); +++ And +++ if (isWindowsNT()) done = RemoveSvcNT(); else done = RemoveSvc(); +++ I do not have update_service for 9x. Everthing else should work as is, so you are wellcome to copy that from instmain. I will do it ASAP... MT. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17124] New: - cannot compile mod_webapp.so
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=17124. 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=17124 cannot compile mod_webapp.so Summary: cannot compile mod_webapp.so Product: Tomcat 4 Version: 4.1.18 Platform: Sun OS/Version: Solaris Status: NEW Severity: Normal Priority: Other Component: Connector:Webapp AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi I'm running Tomcat 4.1 18 and am trying to compile the mod_webapp.so connector. When i run the build script as per README.txt file, only the mod_webapp.c is created . Below is the output of my log file. Thanks. This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by WebApp Module configure , which was generated by GNU Autoconf 2.57. Invocation command line was $ ./configure --enable-debug ## - ## ## Platform. ## ## - ## hostname = websrv2 uname -m = sun4u uname -r = 5.8 uname -s = SunOS uname -v = Generic_108528-13 /usr/bin/uname -p = sparc /bin/uname -X = System = SunOS Node = websrv2 Release = 5.8 KernelID = Generic_108528-13 Machine = sun4u BusType = unknown Serial = unknown Users = unknown OEM# = 0 Origin# = 1 NumCPU = 2 /bin/arch = sun4 /usr/bin/arch -k = sun4u /usr/convex/getsysinfo = unknown hostinfo = unknown /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: usrlocalbin PATH: /usr/sbin PATH: /usr/bin PATH: /usr/local/bin PATH: /usr/ccs/bin PATH: /usr/ucb PATH: /opt/sfw/bin PATH: /opt/SUNWseam/3_0/bin PATH: /usr/local/pgsql/bin PATH: /usr/local/pgsql/bin PATH: /usr/local/pgsql/lib PATH: /usr/local/lib/ PATH: . PATH: /usr/local/apache1.3.24/bin ## --- ## ## Core tests. ## ## --- ## configure:1256: result: configure:1258: result: Configuring WebApp Module configure:1272: checking build system type configure:1290: result: sparc-sun-solaris2.8 configure:1298: checking host system type configure:1312: result: sparc-sun-solaris2.8 configure:1346: checking for sources directory path configure:1354: result: /download/jakarta-tomcat-connectors/webapp configure:1372: checking for build directory path configure:1380: result: /download/jakarta-tomcat-connectors/webapp configure:1500: result: configure:1502: result: Checking Apache APXS configure:1507: checking for apxs name configure:1533: result: apxs configure:1575: checking for apxs configure:1593: found /usr/local/apache1.3.24/bin/apxs configure:1605: result: /usr/local/apache1.3.24/bin/apxs configure:1614: checking for apxs availability configure:1622: result: /usr/local/apache1.3.24/bin/apxs configure:1629: checking for apxs version configure:1645: result: /usr/local/apache1.3.24/bin/apxs (1.3) configure:1650: checking for apxs sanity configure:1673: result: ok configure:1680: result: configure:1682: result: Apache 1.3 module compilation (APR checks) configure:1692: checking for apr sources configure:1718: result: ./apr configure:1721: checking for apr sources directory path configure:1729: result: /download/jakarta-tomcat-connectors/webapp/apr configure:1810: checking for proper command execution configure:1813: result: ok (0) configure:1829: checking for apr CC variable configure:1875: result: gcc configure:1880: checking for apr CPP variable configure:1926: result: gcc -E configure:1931: checking for apr SHELL variable configure:1977: result: /bin/bash configure:1983: checking for apr CFLAGS variable configure:2029: result: configure:2034: checking for apr CPPFLAGS variable configure:2080: result: -DSOLARIS2=8 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT configure:2085: checking for apr LDFLAGS variable configure:2131: result: configure:2137: checking for apr LIBS variable configure:2183: result: -lsendfile -lrt -lm -lsocket -lnsl -lresolv -ldl configure:2188: checking for apr EXTRA_INCLUDES variable configure:2234: result: configure:2240: checking for apr APR_LIB configure:2286: result: apr-0 configure:2291: checking for apr APR_LIBNAME configure:2336: result: libapr-0.la configure:2341: checking for apr headers configure:2364: result: -I/download/jakarta-tomcat-connectors/webapp/apr/include configure:2367: checking for apr libtool configure:2370: result: /bin/bash /download/jakarta-tomcat- connectors/webapp/apr/libtool --silent configure:2374: result: configure:2376: result: Apache 1.3 module compilation (APXS checks) configure:2381: checking for apxs CC variable configure:2394: result: gcc configure:2419: checking for compiler coherency configure:2433: result: ok (gcc) configure:2482: checking for apxs INCLUDEDIR variable configure:2495:
Re: Request to Fix Tomcat Standalone 302 redirect Issue
A patch (which I didn't look at yet) could introduce the following: - Bypassing a security contraints, eg:index.jsp is protected but / isn't - Vulnerabilities - Through a wacky optimizations, other pages might get accidently exposed - It breaks the spec for a different case Odds are - none of these happen with the patches, but when others don't review these conditions is when 'oops' slip through. -Tim neal wrote: What are the security problems and why doesn't Apache or other major web servers have this problem (or do they)? If this is made optional (with the default turned off) is the problem with it breaking an app ... really a problem? -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 1:58 AM To: Tomcat Developers List Subject: Re: Request to Fix Tomcat Standalone 302 redirect Issue Bill Barker wrote: - Original Message - From: neal [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Sunday, February 16, 2003 8:00 PM Subject: RE: Request to Fix Tomcat Standalone 302 redirect Issue So it *will* be in tomcat 5? My head is spinning...so confusing. How does one access o.a.t.u.http.mapper.Mapper? Is this something that will be configurable via web.xml? It will be in configurable in 'server.xml' (or, at least it will be when I do my next commit :). Good, the code looks like as if I had written it myself :) However, it poses the usual security problems, and breaks the admin webapp. Remy - 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]
cvs commit: jakarta-tomcat-5 tomcat.nsi
remm2003/02/17 05:05:11 Modified:.tomcat.nsi Log: - Makes procrun work. - There's some unknown problem with Jasper, though (it apparently fails to find the compiler). Revision ChangesPath 1.24 +14 -7 jakarta-tomcat-5/tomcat.nsi Index: tomcat.nsi === RCS file: /home/cvs/jakarta-tomcat-5/tomcat.nsi,v retrieving revision 1.23 retrieving revision 1.24 diff -u -r1.23 -r1.24 --- tomcat.nsi17 Feb 2003 07:43:42 - 1.23 +++ tomcat.nsi17 Feb 2003 13:05:11 - 1.24 @@ -13,6 +13,9 @@ !define MUI_WELCOMEPAGE !define MUI_FINISHPAGE !define MUI_FINISHPAGE_SHOWREADME $INSTDIR\webapps\ROOT\RELEASE-NOTES.txt + !define MUI_FINISHPAGE_RUN $INSTDIR\bin\tomcatw.exe + !define MUI_FINISHPAGE_RUN_PARAMETERS //GT//Tomcat5 + !define MUI_FINISHPAGE_NOREBOOTSUPPORT !define MUI_LICENSEPAGE @@ -129,6 +132,10 @@ Call configure + ExecWait '$INSTDIR\bin\tomcatw.exe //IS//Tomcat5 --DisplayName Apache Tomcat @VERSION@ --Description Apache Tomcat @VERSION@ Server - http://jakarta.apache.org/tomcat/; --Install $INSTDIR\bin\tomcat.exe --ImagePath $INSTDIR\bin\bootstrap.jar --StartupClass org.apache.catalina.startup.Bootstrap;main;start --ShutdownClass org.apache.catalina.startup.Bootstrap;main;stop --Java java --Startup manual' + + ExecWait '$INSTDIR\bin\tomcatw.exe //US//Tomcat5 --JavaOptions -Dcatalina.home=\$INSTDIR\#-Djava.endorsed.dirs=\$INSTDIR\common\endorsed\ --StdOutputFile $INSTDIR\logs\stdout.log --StdErrorFile $INSTDIR\logs\stderr.log --WorkingPath $INSTDIR' + SectionEnd Section Service SecTomcatService @@ -140,7 +147,7 @@ Call findJVMPath Pop $2 - ExecWait '$INSTDIR\bin\tomcat.exe //IS//Tomcat5 --DisplayName Apache Tomcat @VERSION@ --Description Apache Tomcat @VERSION@ Server - http://jakarta.apache.org/tomcat/; --Install $INSTDIR\bin\tomcat.exe --ImagePath $INSTDIR\bin\bootstrap.jar --StartupClass org.apache.catalina.startup.Bootstrap;main;start --ShutdownClass org.apache.catalina.startup.Bootstrap;main;stop --Java auto --JavaOptions -Djava.endorsed.dirs=$INSTDIR\common\endorsed#-Dcatalina.home=$INSTDIR --StdOutputFile $INSTDIR\logs\stdout.log --StdErrorFile $INSTDIR\logs\stderr.log --WorkingPath $INSTDIR' + ExecWait '$INSTDIR\bin\tomcatw.exe //US//Tomcat5 --Startup auto' BringToFront ClearErrors @@ -195,15 +202,15 @@ CreateShortCut $SMPROGRAMS\Apache Tomcat 5.0\Tomcat 5.0 Program Directory.lnk \ $INSTDIR - CreateShortCut $SMPROGRAMS\Apache Tomcat 5.0\Start Tomcat.lnk \ + CreateShortCut $SMPROGRAMS\Apache Tomcat 5.0\Start Tomcat (old).lnk \ $2\bin\java.exe \ '-Duser.dir=$INSTDIR\bin LauncherBootstrap -launchfile catalina.xml catalina start' \ $INSTDIR\tomcat.ico 0 SW_SHOWNORMAL - CreateShortCut $SMPROGRAMS\Apache Tomcat 5.0\Stop Tomcat.lnk \ - $2\bin\java.exe \ - '-Duser.dir=$INSTDIR\bin LauncherBootstrap -launchfile catalina.xml catalina stop' \ - $INSTDIR\tomcat.ico 0 SW_SHOWMINIMIZED + CreateShortCut $SMPROGRAMS\Apache Tomcat 5.0\Start Tomcat.lnk \ + $INSTDIR\bin\tomcatw.exe \ + '//GT//Tomcat5' \ + $INSTDIR\tomcat.ico 0 SW_SHOWNORMAL SectionEnd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Procrun problems / New loader
[EMAIL PROTECTED] wrote: -Original Message- From: jean-frederic clere [mailto:[EMAIL PROTECTED]] Sent: 17. veljaa 2003 12:14 To: Tomcat Developers List Subject: Re: [5.0] Procrun problems / New loader #ifdefs No... I remember doing this in instmain.c (jakarta-commons-sandbox/daemon/src/native/nt/service). Should I copy/adapte this code to procrun? Well, that was just an idea (using ifdefs), you can use OS guessing inside the procrun itself. In that case you'll need to make something like procrun_install_service9x and call that instead procrun_install_service. Also you'll need the wrap the update_service and delete_service functions. I would like to see that as a new functions, not just to support the 9x inside the existing one. Everthing else should work as is, so you are wellcome to copy that from instmain. All that sounds great :) There's a puzzling side effect to procrun, though: Ant fails to start the Java compiler in fork mode. If I disable forking javac, it works. Does the Java process lose the right to fork other processes when it is run through procrun ? That would be really weird, because the JNI based JavaService didn't have that problem (AFAIK). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 3973] - session.getAttribute() locks-up in HttpSessionListener.sessionDestroyed()
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=3973. 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=3973 session.getAttribute() locks-up in HttpSessionListener.sessionDestroyed() [EMAIL PROTECTED] changed: What|Removed |Added Severity|Major |Blocker Priority|Other |High - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mod_jk and Apache timeouts?
I have some strange error messages in mod_jk.log that I cannot explain, and that I need to resolve urgently. Server: Dual Xeon 2.5Ghz server. Windows 2000 Professional SP3 Apache 2.0.44 Tomcat 4.1.18 Mod_jk 1.2.2 [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (681)]: ERROR: can't receive the response message from tomcat, network problems or tomcat is down. [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (1050)]: Error reading reply from tomcat. Tomcat is down or network problems. [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (1187)]: ERROR: Receiving from tomcat failed, recoverable operation. err=0 [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (681)]: ERROR: can't receive the response message from tomcat, network problems or tomcat is down. [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (1050)]: Error reading reply from tomcat. Tomcat is down or network problems. [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (1187)]: ERROR: Receiving from tomcat failed, recoverable operation. err=1 [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (681)]: ERROR: can't receive the response message from tomcat, network problems or tomcat is down. [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (1050)]: Error reading reply from tomcat. Tomcat is down or network problems. [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (1187)]: ERROR: Receiving from tomcat failed, recoverable operation. err=2 [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (1198)]: Error connecting to tomcat. Tomcat is probably not started or is listenning on the wrong port. Failed errno = 0 The line 'ERROR: Receiving from tomcat failed, recoverable operation. err=0' happens all the time but when the above happens i.e. err=0 - err=1 - err=2 the browser is returned an error 500. I have a much slower box (P4 1.7Ghz) that gets the err=0 line all the time but never gets the err=1 and err=2 lines and therefore never responds with an error 500. I have a feeling that there is a retry that is happening but the box is so quick the threads on the Tomcat side aren't refreshed before Apache gives up. If this can be fixed by changing the config files then I think this should be noted in the docs otherwise this is a bug!?!? Here is the relevant parts of the config. Server.xml: Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8009 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=443 acceptCount=10 debug=0 connectionTimeout=2 useURIValidationHack=false protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler/ workers.properties: worker.ajp13.port=8009 worker.ajp13.host=localhost worker.ajp13.type=ajp13 worker.ajp13.lbfactor=1 worker.ajp13.cachesize=10 worker.ajp13.cache_timeout=600 Thanks for your help. Dave Oxley Development Team Leader Workplace Systems Plc * +44 (0)118 9515 755 * mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] * http://www.workplace-systems.plc.uk/ http://www.workplace-systems.plc.uk There was once a young man who, in his youth, professed his desire to become a great writer. When asked to define great, he said, I want to write stuff that the whole world will read, stuff that people will react to on a truly emotional level, stuff that will make them scream, cry, howl in pain and anger! He now works for Microsoft writing error messages. Workplace Systems plc, Precedent Drive, Rooksley, Milton Keynes, MK13 8PP. Registered in England No. 2016236 Unless expressly stated the views expressed in this email may not be the views of Workplace Systems plc and the company, its directors, officers or employees accept no liability for its contents. Unless expressly stated no contracts may be concluded on behalf of Workplace Systems plc by means of e-mail communication. This e-mail, and any attachments are strictly confidential and intended for the addressee(s) only. If they have come to you in error you must take no action based on the contents, nor may you copy or show them to anyone. Please notify the sender of the error by return email. Please ensure you have adequate virus protection before you open or detach any documents from this transmission. Workplace Systems plc does not accept any liability for viruses. This e-mail has been scanned for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk
DO NOT REPLY [Bug 17130] New: - Reusing tags doesn't calls reuse before cache tag is used
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=17130.
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=17130
Reusing tags doesn't calls reuse before cache tag is used
Summary: Reusing tags doesn't calls reuse before cache tag is
used
Product: Tomcat 4
Version: 4.1.20
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Look at TagHandlerPool.java
Method resuse should call always the release method of the tag, if not the
variables of the class are not initialized and if the tag is used from the
cache, release is never called.
This has been tested on an tag intensive application. Please patch it for
4.1.21. Next I inclose how the reuse method of TagHandlerPool should be:
public synchronized void reuse(Tag handler) {
if (current (handlers.length - 1))
handlers[++current] = handler;
// Why else ?, always release resources and prepare for next use
// else
handler.release();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17130] - Reusing tags doesn't release resources if cache tag is used
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=17130. 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=17130 Reusing tags doesn't release resources if cache tag is used [EMAIL PROTECTED] changed: What|Removed |Added Summary|Reusing tags doesn't calls |Reusing tags doesn't release |reuse before cache tag is |resources if cache tag is |used|used --- Additional Comments From [EMAIL PROTECTED] 2003-02-17 15:54 --- Changing to a better summary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17130] - Reusing tags doesn't release resources if cache tag is used
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=17130. 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=17130 Reusing tags doesn't release resources if cache tag is used [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-02-17 15:55 --- *** This bug has been marked as a duplicate of 16001 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16001] - Tag.release() not invoked
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=16001. 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=16001 Tag.release() not invoked [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-02-17 15:55 --- *** Bug 17130 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Procrun problems / New loader
[EMAIL PROTECTED] wrote: -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] There's a puzzling side effect to procrun, though: Ant fails to start the Java compiler in fork mode. If I disable forking javac, it works. Does the Java process lose the right to fork other processes when it is run through procrun ? That would be really weird, because the JNI based JavaService didn't have that problem (AFAIK). Try running in console mode: procrun.exe //TS//Tomcat5. That's with the GT option. Does that make a difference ? I'll check it more (but right after I fix a minor bug in the mapper). If that's OK then it's a security issue thought. Also what Java and OS? Mine is Sun's 1.4.1 and WIN2K Server. 1.4.1 + XP I'm running TC 4.1.20 and web.xml has set: init-param param-namedevelopment/param-name param-valuefalse/param-value /init-param I'm using the fork init-param to fix it: init-param param-namefork/param-name param-valuefalse/param-value /init-param The error page is the one you get when the compiler is not found. For each jsp I see that the javac is launched under SYSTEM account. So it works. Didn't test with 5.0 but I think that there isn't much difference for that case. There is other problem with the running TC using redirected Java, and that is the lack of gracefull shutdown option. I'm working on that right now. It will enable JVM invocation of Bootstrap with (stop or stopd) in that case if enabled. It's ok if it just sends a term signal to the VM (there's a shutdown hook). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/native/common jk_ajp_common.c
costin 2003/02/17 08:24:31
Modified:jk/native/common jk_ajp_common.c
Log:
Added more info to the log - the return code. It may help debug problems.
Revision ChangesPath
1.34 +17 -16jakarta-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.33
retrieving revision 1.34
diff -u -r1.33 -r1.34
--- jk_ajp_common.c 21 Nov 2002 17:53:48 - 1.33
+++ jk_ajp_common.c 17 Feb 2003 16:24:31 - 1.34
@@ -678,7 +678,7 @@
rc = jk_tcp_socket_recvfull(ae-sd, head, AJP_HEADER_LEN);
if(rc 0) {
-jk_log(l, JK_LOG_ERROR, ERROR: can't receive the response message from
tomcat, network problems or tomcat is down.\n);
+jk_log(l, JK_LOG_ERROR, ERROR: can't receive the response message from
tomcat, network problems or tomcat is down. err=%d\n, rc);
return JK_FALSE;
}
@@ -721,7 +721,7 @@
rc = jk_tcp_socket_recvfull(ae-sd, jk_b_get_buff(msg), msglen);
if(rc 0) {
-jk_log(l, JK_LOG_ERROR, ERROR: can't receive the response message from
tomcat, network problems or tomcat is down\n);
+jk_log(l, JK_LOG_ERROR, ERROR: can't receive the response message from
tomcat, network problems or tomcat is down %d\n, rc);
return JK_FALSE;
}
@@ -975,26 +975,27 @@
case JK_AJP13_GET_BODY_CHUNK:
{
-int len = (int)jk_b_get_int(msg);
+int len = (int)jk_b_get_int(msg);
+if(len 0) {
+len = 0;
+}
if(len AJP13_MAX_SEND_BODY_SZ) {
len = AJP13_MAX_SEND_BODY_SZ;
}
-if(len ae-left_bytes_to_send) {
+if((unsigned int)len ae-left_bytes_to_send) {
len = ae-left_bytes_to_send;
}
-if(len 0) {
-len = 0;
-}
-
-/* the right place to add file storage for upload */
-if ((len = ajp_read_into_msg_buff(ae, r, pmsg, len, l)) = 0) {
-r-content_read += len;
-return JK_AJP13_HAS_RESPONSE;
-}
-jk_log(l, JK_LOG_ERROR, ERROR reading POST data from client. Connection
aborted or network problems\n);
-return JK_INTERNAL_ERROR;
+/* the right place to add file storage for upload */
+if ((len = ajp_read_into_msg_buff(ae, r, pmsg, len, l)) = 0) {
+r-content_read += len;
+return JK_AJP13_HAS_RESPONSE;
+}
+
+jk_log(l, JK_LOG_ERROR, ERROR reading POST data from client.
+Connection aborted or network problems\n);
+return JK_INTERNAL_ERROR;
}
break;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper Mapper.java
remm2003/02/17 08:31:45
Modified:util/java/org/apache/tomcat/util/http/mapper Mapper.java
Log:
- Fix a bug where the wilcard mapping caused an array out of bounds if the
URI started with the path, but couldn't mapped to it, and it was in the first
position (found using the HTML manager help file).
- Fix same bug for context mapping, but this could only happen if there was no
root context (which doesn't happen too often).
Revision ChangesPath
1.6 +6 -0
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper/Mapper.java
Index: Mapper.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/mapper/Mapper.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- Mapper.java 17 Feb 2003 03:38:54 - 1.5
+++ Mapper.java 17 Feb 2003 16:31:44 - 1.6
@@ -415,6 +415,9 @@
break;
}
pos--;
+if (pos 0) {
+break;
+}
}
if (!found) {
if (contexts[0].name.equals()) {
@@ -589,6 +592,9 @@
break;
}
pos--;
+if (pos 0) {
+break;
+}
}
if (found) {
mappingData.wrapperPath.setString(wrappers[pos].name);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/admin frameset.jsp index.jsp
remm2003/02/17 08:32:44 Modified:webapps/admin index.jsp Added: webapps/admin frameset.jsp Log: - The index now does a redirect to a separate page which loads the frameset. - Workaround for the change in welcome file processing. Revision ChangesPath 1.4 +1 -27 jakarta-tomcat-catalina/webapps/admin/index.jsp Index: index.jsp === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/admin/index.jsp,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- index.jsp 23 Jan 2003 00:07:07 - 1.3 +++ index.jsp 17 Feb 2003 16:32:44 - 1.4 @@ -1,27 +1 @@ -!-- Standard Struts Entries -- - -%@ page language=java contentType=text/html;charset=utf-8 % -%@ taglib uri=/WEB-INF/struts-bean.tld prefix=bean % -%@ taglib uri=/WEB-INF/struts-html.tld prefix=html % -%@ taglib uri=/WEB-INF/struts-logic.tld prefix=logic % - -html:html locale=true - -!-- Standard Content -- - -%@ include file=header.jsp % - -!-- Body -- -frameset rows=117,685* cols=* frameborder=NO border=3 framespacing=3 - frame name=banner src='%= response.encodeURL(banner.jsp) %' scrolling=no title=commit and logout banner - frameset cols=300,* frameborder=YES border=2 -frame name=tree src='%= response.encodeURL(setUpTree.do) %' scrolling=auto title=application navigation tree -frame name=content src='%= response.encodeURL(blank.jsp) %' scrolling=auto title=content editing - /frameset -/frameset - -!-- Standard Footer -- - -%@ include file=footer.jsp % - -/html:html +% response.sendRedirect(frameset.jsp); % \ No newline at end of file 1.1 jakarta-tomcat-catalina/webapps/admin/frameset.jsp Index: frameset.jsp === !-- Standard Struts Entries -- %@ page language=java contentType=text/html;charset=utf-8 % %@ taglib uri=/WEB-INF/struts-bean.tld prefix=bean % %@ taglib uri=/WEB-INF/struts-html.tld prefix=html % %@ taglib uri=/WEB-INF/struts-logic.tld prefix=logic % html:html locale=true !-- Standard Content -- %@ include file=header.jsp % !-- Body -- frameset rows=117,685* cols=* frameborder=NO border=3 framespacing=3 frame name=banner src='%= response.encodeURL(banner.jsp) %' scrolling=no title=commit and logout banner frameset cols=300,* frameborder=YES border=2 frame name=tree src='%= response.encodeURL(setUpTree.do) %' scrolling=auto title=application navigation tree frame name=content src='%= response.encodeURL(blank.jsp) %' scrolling=auto title=content editing /frameset /frameset !-- Standard Footer -- %@ include file=footer.jsp % /html:html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Procrun problems / New loader
[EMAIL PROTECTED] wrote: -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] There's a puzzling side effect to procrun, though: Ant fails to start the Java compiler in fork mode. If I disable forking javac, it works. Does the Java process lose the right to fork other processes when it is run through procrun ? That would be really weird, because the JNI based JavaService didn't have that problem (AFAIK). Try running in console mode: procrun.exe //TS//Tomcat5. If that's OK then it's a security issue thought. Also what Java and OS? Mine is Sun's 1.4.1 and WIN2K Server. TS does the same as GT. (ie, it fails with fork being true, which is the default, and works with fork being false). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Request to Fix Tomcat Standalone 302 redirect Issue
Tim Funk wrote: A patch (which I didn't look at yet) could introduce the following: - Bypassing a security contraints, eg:index.jsp is protected but / isn't - Vulnerabilities - Through a wacky optimizations, other pages might get accidently exposed Just curious... I assume the patch uses RequestDispatcher.forward to handle the request, right? But these checks should already be done by the RequestDispatcher, otherwise _anything_ that uses rd.forward could break security. So if we trust rd, what's the issue? If we don't, um, why _not_? - donald - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5.0] Procrun problems / New loader
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: -Original Message- From: jean-frederic clere [mailto:[EMAIL PROTECTED]] Sent: 17. veljaa 2003 12:14 To: Tomcat Developers List Subject: Re: [5.0] Procrun problems / New loader #ifdefs No... I remember doing this in instmain.c (jakarta-commons-sandbox/daemon/src/native/nt/service). Should I copy/adapte this code to procrun? Well, that was just an idea (using ifdefs), you can use OS guessing inside the procrun itself. In that case you'll need to make something like procrun_install_service9x and call that instead procrun_install_service. Also you'll need the wrap the update_service and delete_service functions. I would like to see that as a new functions, not just to support the 9x inside the existing one. Everthing else should work as is, so you are wellcome to copy that from instmain. All that sounds great :) I have just committed the support for win9x but I have not tested it yet. There's a puzzling side effect to procrun, though: Ant fails to start the Java compiler in fork mode. If I disable forking javac, it works. Does the Java process lose the right to fork other processes when it is run through procrun ? That would be really weird, because the JNI based JavaService didn't have that problem (AFAIK). Remy - 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/native/common jk_connect.c
costin 2003/02/17 08:59:47
Modified:jk/native/common jk_connect.c
Log:
Return more usefull information from recv, to help debug.
Revision ChangesPath
1.8 +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.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- jk_connect.c 6 Dec 2002 18:52:50 - 1.7
+++ jk_connect.c 17 Feb 2003 16:59:47 - 1.8
@@ -263,11 +263,11 @@
return sent;
}
-/** receive len bytes.
+/** receive len bytes. Used in ajp_common.
* @param sd opened socket.
* @param b buffer to store the data.
* @param len length to receive.
- * @return-1: receive failed or connection closed.
+ * @return0: receive failed or connection closed.
*0: length of the received data.
*/
int jk_tcp_socket_recvfull(int sd,
@@ -283,6 +283,7 @@
0);
if(-1 == this_time) {
#if defined(WIN32) || (defined(NETWARE) defined(__NOVELL_LIBC__))
+/* I assume SOCKET_ERROR == -1 */
if(SOCKET_ERROR == this_time) {
errno = WSAGetLastError() - WSABASEERR;
}
@@ -290,8 +291,9 @@
if(EAGAIN == errno) {
continue;
-}
-return -1;
+}
+/** Pass the errno to the caller */
+return (errno0) ? -errno : errno;
}
if(0 == this_time) {
return -1;
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk and Apache timeouts?
I suspect it's a windows specific return code from recv(). The code in question calls socket_recvfull - which in turn calls recv() to fill a buffer. It handles EAGAIN - but knowing windows, it may be something else. If you can do a checkout from HEAD and built again - you should see the errno at the end of the message, so we can figure out what happens. The first error is the one that matters - the others are just jk doing a retry. The message is bad - err=0,1,2 should be retry=0,1,2 Costin Oxley, David wrote: I have some strange error messages in mod_jk.log that I cannot explain, and that I need to resolve urgently. Server: Dual Xeon 2.5Ghz server. Windows 2000 Professional SP3 Apache 2.0.44 Tomcat 4.1.18 Mod_jk 1.2.2 [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (681)]: ERROR: can't receive the response message from tomcat, network problems or tomcat is down. [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (1050)]: Error reading reply from tomcat. Tomcat is down or network problems. [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (1187)]: ERROR: Receiving [from tomcat failed, recoverable operation. err=0 [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (681)]: ERROR: can't receive the response message from tomcat, network problems or tomcat is down. [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (1050)]: Error reading reply from tomcat. Tomcat is down or network problems. [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (1187)]: ERROR: Receiving [from tomcat failed, recoverable operation. err=1 [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (681)]: ERROR: can't receive the response message from tomcat, network problems or tomcat is down. [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (1050)]: Error reading reply from tomcat. Tomcat is down or network problems. [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (1187)]: ERROR: Receiving [from tomcat failed, recoverable operation. err=2 [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (1198)]: Error connecting to tomcat. Tomcat is probably not started or is listenning on the wrong port. Failed errno = 0 The line 'ERROR: Receiving from tomcat failed, recoverable operation. err=0' happens all the time but when the above happens i.e. err=0 - err=1 - err=2 the browser is returned an error 500. I have a much slower box (P4 1.7Ghz) that gets the err=0 line all the time but never gets the err=1 and err=2 lines and therefore never responds with an error 500. I have a feeling that there is a retry that is happening but the box is so quick the threads on the Tomcat side aren't refreshed before Apache gives up. If this can be fixed by changing the config files then I think this should be noted in the docs otherwise this is a bug!?!? Here is the relevant parts of the config. Server.xml: Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8009 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=443 acceptCount=10 debug=0 connectionTimeout=2 useURIValidationHack=false protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler/ workers.properties: worker.ajp13.port=8009 worker.ajp13.host=localhost worker.ajp13.type=ajp13 worker.ajp13.lbfactor=1 worker.ajp13.cachesize=10 worker.ajp13.cache_timeout=600 Thanks for your help. Dave Oxley Development Team Leader Workplace Systems Plc * +44 (0)118 9515 755 * mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] * http://www.workplace-systems.plc.uk/ http://www.workplace-systems.plc.uk There was once a young man who, in his youth, professed his desire to become a great writer. When asked to define great, he said, I want to write stuff that the whole world will read, stuff that people will react to on a truly emotional level, stuff that will make them scream, cry, howl in pain and anger! He now works for Microsoft writing error messages. Workplace Systems plc, Precedent Drive, Rooksley, Milton Keynes, MK13 8PP. Registered in England No. 2016236 Unless expressly stated the views expressed in this email may not be the views of Workplace Systems plc and the company, its directors, officers or employees accept no liability for its contents. Unless expressly stated no contracts may be concluded on behalf of Workplace Systems plc by means of e-mail communication. This e-mail, and any attachments are strictly confidential and intended for the addressee(s) only. If they have come to you in error you must take no action based on the contents, nor may you copy or show them to anyone. Please notify the sender of the error by return email. Please ensure you have adequate virus protection before you open or detach any documents from this transmission. Workplace Systems plc does not accept any liability for viruses. This
RE: mod_jk and Apache timeouts?
Costin, I will rebuild from HEAD now and give it a try. But I think I may have sorted found the problem. I have changed the Connector timeout to -1 in server.xml, and error 500's is no longer returned. Therefore on this box, mod_jk is too quick for Tomcat (I think). mod_jk tries to connect and fails 3 times (before TC has restarted its Connector threads) and returns an error 500 to the client. Dave. -Original Message- From: Costin Manolache [mailto:[EMAIL PROTECTED]] Sent: 17 February 2003 17:02 To: [EMAIL PROTECTED] Subject: Re: mod_jk and Apache timeouts? I suspect it's a windows specific return code from recv(). The code in question calls socket_recvfull - which in turn calls recv() to fill a buffer. It handles EAGAIN - but knowing windows, it may be something else. If you can do a checkout from HEAD and built again - you should see the errno at the end of the message, so we can figure out what happens. The first error is the one that matters - the others are just jk doing a retry. The message is bad - err=0,1,2 should be retry=0,1,2 Costin Oxley, David wrote: I have some strange error messages in mod_jk.log that I cannot explain, and that I need to resolve urgently. Server: Dual Xeon 2.5Ghz server. Windows 2000 Professional SP3 Apache 2.0.44 Tomcat 4.1.18 Mod_jk 1.2.2 [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (681)]: ERROR: can't receive the response message from tomcat, network problems or tomcat is down. [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (1050)]: Error reading reply from tomcat. Tomcat is down or network problems. [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (1187)]: ERROR: Receiving [from tomcat failed, recoverable operation. err=0 [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (681)]: ERROR: can't receive the response message from tomcat, network problems or tomcat is down. [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (1050)]: Error reading reply from tomcat. Tomcat is down or network problems. [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (1187)]: ERROR: Receiving [from tomcat failed, recoverable operation. err=1 [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (681)]: ERROR: can't receive the response message from tomcat, network problems or tomcat is down. [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (1050)]: Error reading reply from tomcat. Tomcat is down or network problems. [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (1187)]: ERROR: Receiving [from tomcat failed, recoverable operation. err=2 [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (1198)]: Error connecting to tomcat. Tomcat is probably not started or is listenning on the wrong port. Failed errno = 0 The line 'ERROR: Receiving from tomcat failed, recoverable operation. err=0' happens all the time but when the above happens i.e. err=0 - err=1 - err=2 the browser is returned an error 500. I have a much slower box (P4 1.7Ghz) that gets the err=0 line all the time but never gets the err=1 and err=2 lines and therefore never responds with an error 500. I have a feeling that there is a retry that is happening but the box is so quick the threads on the Tomcat side aren't refreshed before Apache gives up. If this can be fixed by changing the config files then I think this should be noted in the docs otherwise this is a bug!?!? Here is the relevant parts of the config. Server.xml: Connector className=org.apache.coyote.tomcat4.CoyoteConnector port=8009 minProcessors=5 maxProcessors=75 enableLookups=true redirectPort=443 acceptCount=10 debug=0 connectionTimeout=2 useURIValidationHack=false protocolHandlerClassName=org.apache.jk.server.JkCoyoteHandler/ workers.properties: worker.ajp13.port=8009 worker.ajp13.host=localhost worker.ajp13.type=ajp13 worker.ajp13.lbfactor=1 worker.ajp13.cachesize=10 worker.ajp13.cache_timeout=600 Thanks for your help. Dave Oxley Development Team Leader Workplace Systems Plc * +44 (0)118 9515 755 * mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] * http://www.workplace-systems.plc.uk/ http://www.workplace-systems.plc.uk There was once a young man who, in his youth, professed his desire to become a great writer. When asked to define great, he said, I want to write stuff that the whole world will read, stuff that people will react to on a truly emotional level, stuff that will make them scream, cry, howl in pain and anger! He now works for Microsoft writing error messages. Workplace Systems plc, Precedent Drive, Rooksley, Milton Keynes, MK13 8PP. Registered in England No. 2016236 Unless expressly stated the views expressed in this email may not be the views of Workplace Systems plc and the company, its directors, officers or employees accept no liability for its
RE: mod_jk and Apache timeouts?
Costin, Here is the log produced with mod_jk HEAD: [Mon Feb 17 17:23:26 2003] [jk_ajp_common.c (681)]: ERROR: can't receive the response message from tomcat, network problems or tomcat is down. err=-53 [Mon Feb 17 17:23:26 2003] [jk_ajp_common.c (1051)]: Error reading reply from tomcat. Tomcat is down or network problems. [Mon Feb 17 17:23:26 2003] [jk_ajp_common.c (1188)]: ERROR: Receiving from tomcat failed, recoverable operation. err=0 [Mon Feb 17 17:23:26 2003] [jk_ajp_common.c (681)]: ERROR: can't receive the response message from tomcat, network problems or tomcat is down. err=-1 [Mon Feb 17 17:23:26 2003] [jk_ajp_common.c (1051)]: Error reading reply from tomcat. Tomcat is down or network problems. [Mon Feb 17 17:23:26 2003] [jk_ajp_common.c (1188)]: ERROR: Receiving from tomcat failed, recoverable operation. err=1 [Mon Feb 17 17:23:26 2003] [jk_ajp_common.c (681)]: ERROR: can't receive the response message from tomcat, network problems or tomcat is down. err=-1 [Mon Feb 17 17:23:26 2003] [jk_ajp_common.c (1051)]: Error reading reply from tomcat. Tomcat is down or network problems. [Mon Feb 17 17:23:26 2003] [jk_ajp_common.c (1188)]: ERROR: Receiving from tomcat failed, recoverable operation. err=2 [Mon Feb 17 17:23:26 2003] [jk_ajp_common.c (1199)]: Error connecting to tomcat. Tomcat is probably not started or is listenning on the wrong port. Failed errno = 53 Cheers. Dave. -Original Message- From: Oxley, David [mailto:[EMAIL PROTECTED]] Sent: 17 February 2003 17:00 To: 'Tomcat Developers List' Subject: RE: mod_jk and Apache timeouts? Costin, I will rebuild from HEAD now and give it a try. But I think I may have sorted found the problem. I have changed the Connector timeout to -1 in server.xml, and error 500's is no longer returned. Therefore on this box, mod_jk is too quick for Tomcat (I think). mod_jk tries to connect and fails 3 times (before TC has restarted its Connector threads) and returns an error 500 to the client. Dave. -Original Message- From: Costin Manolache [mailto:[EMAIL PROTECTED]] Sent: 17 February 2003 17:02 To: [EMAIL PROTECTED] Subject: Re: mod_jk and Apache timeouts? I suspect it's a windows specific return code from recv(). The code in question calls socket_recvfull - which in turn calls recv() to fill a buffer. It handles EAGAIN - but knowing windows, it may be something else. If you can do a checkout from HEAD and built again - you should see the errno at the end of the message, so we can figure out what happens. The first error is the one that matters - the others are just jk doing a retry. The message is bad - err=0,1,2 should be retry=0,1,2 Costin Oxley, David wrote: I have some strange error messages in mod_jk.log that I cannot explain, and that I need to resolve urgently. Server: Dual Xeon 2.5Ghz server. Windows 2000 Professional SP3 Apache 2.0.44 Tomcat 4.1.18 Mod_jk 1.2.2 [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (681)]: ERROR: can't receive the response message from tomcat, network problems or tomcat is down. [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (1050)]: Error reading reply from tomcat. Tomcat is down or network problems. [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (1187)]: ERROR: Receiving [from tomcat failed, recoverable operation. err=0 [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (681)]: ERROR: can't receive the response message from tomcat, network problems or tomcat is down. [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (1050)]: Error reading reply from tomcat. Tomcat is down or network problems. [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (1187)]: ERROR: Receiving [from tomcat failed, recoverable operation. err=1 [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (681)]: ERROR: can't receive the response message from tomcat, network problems or tomcat is down. [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (1050)]: Error reading reply from tomcat. Tomcat is down or network problems. [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (1187)]: ERROR: Receiving [from tomcat failed, recoverable operation. err=2 [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (1198)]: Error connecting to tomcat. Tomcat is probably not started or is listenning on the wrong port. Failed errno = 0 The line 'ERROR: Receiving from tomcat failed, recoverable operation. err=0' happens all the time but when the above happens i.e. err=0 - err=1 - err=2 the browser is returned an error 500. I have a much slower box (P4 1.7Ghz) that gets the err=0 line all the time but never gets the err=1 and err=2 lines and therefore never responds with an error 500. I have a feeling that there is a retry that is happening but the box is so quick the threads on the Tomcat side aren't refreshed before Apache gives up. If this can be fixed by changing
Re: Request to Fix Tomcat Standalone 302 redirect Issue
On Mon, 17 Feb 2003, Donald Ball wrote: Date: Mon, 17 Feb 2003 11:44:16 -0500 From: Donald Ball [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: Re: Request to Fix Tomcat Standalone 302 redirect Issue Tim Funk wrote: A patch (which I didn't look at yet) could introduce the following: - Bypassing a security contraints, eg:index.jsp is protected but / isn't - Vulnerabilities - Through a wacky optimizations, other pages might get accidently exposed Just curious... I assume the patch uses RequestDispatcher.forward to handle the request, right? But these checks should already be done by the RequestDispatcher, otherwise _anything_ that uses rd.forward could break security. So if we trust rd, what's the issue? If we don't, um, why _not_? Security constraints are only checked on the original request URL, not on RD.forward or RD.include calls -- the container assumes that the application knows what it is doing in executing those calls within the app. If the container wants to use RD (or the internal equivalent) to implement welcome file support, or other container level features like error files, it had better pay attention to the security constraints. - donald Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Request to Fix Tomcat Standalone 302 redirect Issue
I thought I had an answer but the more I delved into the code the more I realized I should shut up. (I rather give no reply than a wrong reply) Now going back to read more code. -Tim I'm starting to hate snow (after shoveling over 2 feet with more coming) Donald Ball wrote: Tim Funk wrote: A patch (which I didn't look at yet) could introduce the following: - Bypassing a security contraints, eg:index.jsp is protected but / isn't - Vulnerabilities - Through a wacky optimizations, other pages might get accidently exposed Just curious... I assume the patch uses RequestDispatcher.forward to handle the request, right? But these checks should already be done by the RequestDispatcher, otherwise _anything_ that uses rd.forward could break security. So if we trust rd, what's the issue? If we don't, um, why _not_? - donald - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17137] New: - mod_jk compiled in 64-bit does not connect to remote tomcat
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=17137. 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=17137 mod_jk compiled in 64-bit does not connect to remote tomcat Summary: mod_jk compiled in 64-bit does not connect to remote tomcat Product: Tomcat 4 Version: 4.0 Beta 1 Platform: Sun OS/Version: Solaris Status: NEW Severity: Major Priority: Other Component: Connector:JK/AJP (deprecated) AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have apache-2.0.43 + mod_jk 4.1.18 compiled on Solaris 8 in 64-bit mode. Tomcat runs both on the local machine, and on a remote. If a worker is configured to connect to tomcat on the local machine, it works fine. When configured to connect to tomcat on a remote machine, it fails. If apache and mod_jk are compiled on the same box in 32-bit mode, then it works fine both against local and remote tomcat. 32-bit compilation is forced by using -m32 flag. System description: root@mpwww10:~# uname -a SunOS mpwww10.mpstage.com 5.8 Generic_108528-16 sun4u sparc SUNW,UltraSPARC-IIi-cEngine root@mpwww10:~# gcc -v Reading specs from /usr/local/lib/gcc-lib/sparcv9-sun-solaris2.8/3.0.4/specs Configured with: ./configure --host=sparcv9-sun-solaris2.8 Thread model: posix gcc version 3.0.4 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17088] - Can't bring up Tomcat - any builds SEVERE:PARSE Fatal Error
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=17088. 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=17088 Can't bring up Tomcat - any builds SEVERE:PARSE Fatal Error [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-02-17 18:29 --- The problem was a corrupted servlet.jar or an old servlet.jar that was placed in the Java/JRE/ext directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17137] - mod_jk compiled in 64-bit does not connect to remote tomcat
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=17137. 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=17137 mod_jk compiled in 64-bit does not connect to remote tomcat [EMAIL PROTECTED] changed: What|Removed |Added Priority|Other |Medium Version|4.0 Beta 1 |4.1.18 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 16001] - Tag.release() not invoked
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=16001.
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=16001
Tag.release() not invoked
--- Additional Comments From [EMAIL PROTECTED] 2003-02-17 20:23 ---
OK guys, release() method is NOT guaranteed to be called on any tag handler, so
..there may be multiple invocations on doStartTag and doEndTag in between.
But programmers needs a method to initialize the tag between uses. Initializing
it at doStartTag method is not OK because setters are called before doStartTag
so programmer could clear the setted variables.
We need a method to initialize the tag before it's called, Maybe changing the
get method get() at TagHandlerPool.java
If not, please great gurus, how can we use tag pooling without this
initialization issues. JSP spec is not clear about this!
public synchronized Tag get(Class handlerClass) throws JspException {
Tag handler = null;
if (current = 0) {
handler = handlers[current--];
// If handler is already in the cache release it
// It cannot be done at startTag not at EndTag because closed tags can
// return a java object
handler.release();
} else {
try {
return (Tag) handlerClass.newInstance();
} catch (Exception e) {
throw new JspException(e.getMessage(), e);
}
}
return handler;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: mod_jk and Apache timeouts?
I think: From winsock.h: #define WSABASEERR 1 #define WSAECONNABORTED (WSABASEERR+53) From VC.NET help files: WSAECONNABORTED=The virtual circuit was terminated due to a time-out or other failure. The application should close the socket as it is no longer usable. Dave. Thanks Dave. Now if someone has windows and can grep what errno 53 means... Costin Oxley, David wrote: Costin, Here is the log produced with mod_jk HEAD: [Mon Feb 17 17:23:26 2003] [jk_ajp_common.c (681)]: ERROR: can't receive the response message from tomcat, network problems or tomcat is down. err=-53 [Mon Feb 17 17:23:26 2003] [jk_ajp_common.c (1051)]: Error reading reply from tomcat. Tomcat is down or network problems. [Mon Feb 17 17:23:26 2003] [jk_ajp_common.c (1188)]: ERROR: Receiving [from tomcat failed, recoverable operation. err=0 [Mon Feb 17 17:23:26 2003] [jk_ajp_common.c (681)]: ERROR: can't receive the response message from tomcat, network problems or tomcat is down. err=-1 [Mon Feb 17 17:23:26 2003] [jk_ajp_common.c (1051)]: Error reading reply from tomcat. Tomcat is down or network problems. [Mon Feb 17 17:23:26 2003] [jk_ajp_common.c (1188)]: ERROR: Receiving [from tomcat failed, recoverable operation. err=1 [Mon Feb 17 17:23:26 2003] [jk_ajp_common.c (681)]: ERROR: can't receive the response message from tomcat, network problems or tomcat is down. err=-1 [Mon Feb 17 17:23:26 2003] [jk_ajp_common.c (1051)]: Error reading reply from tomcat. Tomcat is down or network problems. [Mon Feb 17 17:23:26 2003] [jk_ajp_common.c (1188)]: ERROR: Receiving [from tomcat failed, recoverable operation. err=2 [Mon Feb 17 17:23:26 2003] [jk_ajp_common.c (1199)]: Error connecting to tomcat. Tomcat is probably not started or is listenning on the wrong port. Failed errno = 53 Cheers. Dave. -Original Message- From: Oxley, David [mailto:[EMAIL PROTECTED]] Sent: 17 February 2003 17:00 To: 'Tomcat Developers List' Subject: RE: mod_jk and Apache timeouts? Costin, I will rebuild from HEAD now and give it a try. But I think I may have sorted found the problem. I have changed the Connector timeout to -1 in server.xml, and error 500's is no longer returned. Therefore on this box, mod_jk is too quick for Tomcat (I think). mod_jk tries to connect and fails 3 times (before TC has restarted its Connector threads) and returns an error 500 to the client. Dave. -Original Message- From: Costin Manolache [mailto:[EMAIL PROTECTED]] Sent: 17 February 2003 17:02 To: [EMAIL PROTECTED] Subject: Re: mod_jk and Apache timeouts? I suspect it's a windows specific return code from recv(). The code in question calls socket_recvfull - which in turn calls recv() to fill a buffer. It handles EAGAIN - but knowing windows, it may be something else. If you can do a checkout from HEAD and built again - you should see the errno at the end of the message, so we can figure out what happens. The first error is the one that matters - the others are just jk doing a retry. The message is bad - err=0,1,2 should be retry=0,1,2 Costin Oxley, David wrote: I have some strange error messages in mod_jk.log that I cannot explain, and that I need to resolve urgently. Server: Dual Xeon 2.5Ghz server. Windows 2000 Professional SP3 Apache 2.0.44 Tomcat 4.1.18 Mod_jk 1.2.2 [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (681)]: ERROR: can't receive the response message from tomcat, network problems or tomcat is down. [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (1050)]: Error reading reply from tomcat. Tomcat is down or network problems. [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (1187)]: ERROR: [Receiving from tomcat failed, recoverable operation. err=0 [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (681)]: ERROR: can't receive the response message from tomcat, network problems or tomcat is down. [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (1050)]: Error reading reply from tomcat. Tomcat is down or network problems. [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (1187)]: ERROR: [Receiving from tomcat failed, recoverable operation. err=1 [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (681)]: ERROR: can't receive the response message from tomcat, network problems or tomcat is down. [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (1050)]: Error reading reply from tomcat. Tomcat is down or network problems. [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (1187)]: ERROR: [Receiving from tomcat failed, recoverable operation. err=2 [Mon Feb 17 14:49:38 2003] [jk_ajp_common.c (1198)]: Error [connecting to tomcat. Tomcat is probably not started or is listenning on the wrong port. Failed errno = 0 The line 'ERROR: Receiving from tomcat failed, recoverable operation. err=0' happens all the time but when the
[OT] tomcat as topic level project?
Since ant is a top level project, is there a reason that tomcat should or should not be a top level project. What issues does this raise? My guess is top level projects have the opportunity to have sub-projects which seems to be what tomcat already has. My guess the main project is tomcat (the distributed binary) and the subprojects are: - catalina - connectors - modules (the add-ons to 5 like cluster, ...) - jasper - ??? I apologize if this was discussed in other circles, I'm just stuck in over 2 ft of snow and am getting restless. -Tim - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Compiler.java
glenn 2003/02/17 14:36:00
Modified:jasper2/src/share/org/apache/jasper/compiler Compiler.java
Log:
An ant Project uses the current directory as its base directory by default.
The base directory doesn't matter but ant always checks it. This can cause
problems when using the SecurityManager with a strict policy. The Compiler
now explicitely sets the ant Project base dir to catalina.home.
Revision ChangesPath
1.53 +1 -0
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java
Index: Compiler.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java,v
retrieving revision 1.52
retrieving revision 1.53
diff -u -r1.52 -r1.53
--- Compiler.java 12 Feb 2003 23:44:22 - 1.52
+++ Compiler.java 17 Feb 2003 22:36:00 - 1.53
@@ -152,6 +152,7 @@
logger.setErrorPrintStream(System.err);
logger.setMessageOutputLevel(Project.MSG_INFO);
project.addBuildListener( logger);
+project.setBasedir( System.getProperty(catalina.home));
if( options.getCompiler() != null ) {
if( log.isDebugEnabled() )
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Compiler.java
glenn 2003/02/17 14:36:08
Modified:jasper2/src/share/org/apache/jasper/compiler Tag:
tomcat_4_branch Compiler.java
Log:
An ant Project uses the current directory as its base directory by default.
The base directory doesn't matter but ant always checks it. This can cause
problems when using the SecurityManager with a strict policy. The Compiler
now explicitely sets the ant Project base dir to catalina.home.
Revision ChangesPath
No revision
No revision
1.18.2.12 +5 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java
Index: Compiler.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java,v
retrieving revision 1.18.2.11
retrieving revision 1.18.2.12
diff -u -r1.18.2.11 -r1.18.2.12
--- Compiler.java 10 Feb 2003 18:18:05 - 1.18.2.11
+++ Compiler.java 17 Feb 2003 22:36:08 - 1.18.2.12
@@ -161,7 +161,8 @@
logger.setMessageOutputLevel( Project.MSG_INFO );
}
project.addBuildListener( logger );
-
+project.setBasedir( System.getProperty(catalina.home));
+
if( options.getCompiler() != null ) {
Constants.jasperLog.log(Compiler + options.getCompiler(),
Logger.INFORMATION);
project.setProperty(build.compiler, options.getCompiler() );
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17146] New: - Simplify build.xml using property environment=env /
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=17146.
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=17146
Simplify build.xml using property environment=env /
Summary: Simplify build.xml using property environment=env /
Product: Tomcat 4
Version: 4.1.18
Platform: Other
URL: http://localhost:8080/tomcat-docs/appdev/build.xml.txt
OS/Version: Other
Status: NEW
Severity: Enhancement
Priority: Other
Component: Webapps:Examples
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Where it says UPDATE THIS
replace that line with these two.
property enviornment=env /
property name=catalina.home value=${env.CATALINA_HOME}
If the user has CATALINA_HOME set,
then the build will run without any changes.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17153] New: - Error in build.xml
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=17153. 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=17153 Error in build.xml Summary: Error in build.xml Product: Tomcat 4 Version: 4.1.18 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Webapps:Examples AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] build.xml has an error in dist task mkdir does not allow argument todir /name=dist/ /mkdir/s/to// - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
