Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardWrapper.java
[EMAIL PROTECTED] wrote: luehe 2003/09/17 16:26:33 Modified:catalina/src/share/org/apache/catalina/core StandardWrapper.java Log: Fix for Bugtraq 4924326 (JMX registrations of servlets that map to the same jsp-file use the same name) There was also a similar issue in the request dispatcher, where the mapped servlet path was overriden (for no good reason IMO) with the JSP file. What was the reasoning behind this code ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23180] - Deadlock in WebAppClassLoader
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=23180. 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=23180 Deadlock in WebAppClassLoader --- Additional Comments From [EMAIL PROTECTED] 2003-09-18 07:44 --- Another execution, this time in a Solaris 7 box, whith Sun JDK 1.3.1_04: This time I have a deadlock report from the JVM: FOUND A JAVA LEVEL DEADLOCK: Thread-28: waiting to lock monitor 0xa8448 (object 0xf1ada6c8, a sun.misc.Launcher$AppClassLoader), which is locked by Thread-18 Thread-18: waiting to lock monitor 0xa83d8 (object 0xf1afeb48, a sun.misc.Launcher$ExtClassLoader), which is locked by Thread-28 JAVA STACK INFORMATION FOR THREADS LISTED ABOVE: Java Stack for Thread-28: == at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:274) at java.lang.ClassLoader.loadClass(ClassLoader.java:250) at sun.security.x509.OIDMap$1.run(OIDMap.java:254) at java.security.AccessController.doPrivileged(Native Method) at sun.security.x509.OIDMap.loadOidClass(OIDMap.java:251) at sun.security.x509.OIDMap.getClass(OIDMap.java:234) at sun.security.x509.CertificateExtensions.parseExtension (CertificateExtensions.java:83) at sun.security.x509.CertificateExtensions.init (CertificateExtensions.java:76) at sun.security.x509.CertificateExtensions.init (CertificateExtensions.java:55) at sun.security.x509.X509CertInfo.parse(X509CertInfo.java:714) at sun.security.x509.X509CertInfo.init(X509CertInfo.java:150) at sun.security.x509.X509CertImpl.parse(X509CertImpl.java:1039) at sun.security.x509.X509CertImpl.init(X509CertImpl.java:144) at sun.security.provider.X509Factory.engineGenerateCertificate (X509Factory.java:84) at java.security.cert.CertificateFactory.generateCertificate (CertificateFactory.java:281) at sun.security.pkcs.PKCS7.parseSignedData(PKCS7.java:252) at sun.security.pkcs.PKCS7.parse(PKCS7.java:128) at sun.security.pkcs.PKCS7.parse(PKCS7.java:97) at sun.security.pkcs.PKCS7.init(PKCS7.java:85) at sun.security.util.SignatureFileVerifier.init (SignatureFileVerifier.java:62) at java.util.jar.JarVerifier.processEntry(JarVerifier.java:258) at java.util.jar.JarVerifier.update(JarVerifier.java:192) at java.util.jar.JarFile.initializeVerifier(JarFile.java:243) at java.util.jar.JarFile.getInputStream(JarFile.java:305) - locked f1b25510 (a java.util.jar.JarFile) at sun.misc.URLClassPath$4.getInputStream(URLClassPath.java:532) at sun.misc.Resource.getBytes(Resource.java:55) at java.net.URLClassLoader.defineClass(URLClassLoader.java:240) at java.net.URLClassLoader.access$100(URLClassLoader.java:51) at java.net.URLClassLoader$1.run(URLClassLoader.java:190) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:183) at java.lang.ClassLoader.loadClass(ClassLoader.java:294) at java.lang.ClassLoader.loadClass(ClassLoader.java:250) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:310) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.init(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.a(DashoA6275) - locked f1b96408 (a com.sun.net.ssl.internal.ssl.SSLServerSocketImpl) at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(DashoA6275) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.acceptSocket (JSSESocketFactory.java:240) at org.apache.tomcat.util.net.PoolTcpEndpoint.acceptSocket (PoolTcpEndpoint.java:356) at org.apache.tomcat.util.net.TcpWorkerThread.runIt (PoolTcpEndpoint.java:529) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadPool.java:619) at java.lang.Thread.run(Thread.java:479) Java Stack for Thread-18: == at java.lang.ClassLoader.loadClass(ClassLoader.java:283) at java.lang.ClassLoader.loadClass(ClassLoader.java:287) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:281) at java.lang.ClassLoader.loadClass(ClassLoader.java:250) at org.apache.catalina.loader.StandardClassLoader.loadClass (StandardClassLoader.java:941) at org.apache.catalina.loader.StandardClassLoader.loadClass (StandardClassLoader.java:857) at java.util.ResourceBundle.loadBundle(ResourceBundle.java:905) at java.util.ResourceBundle.findBundle(ResourceBundle.java:786) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:635) at
DO NOT REPLY [Bug 23180] - Deadlock in classloader while loading JSSE
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=23180. 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=23180 Deadlock in classloader while loading JSSE [EMAIL PROTECTED] changed: What|Removed |Added Summary|Deadlock in |Deadlock in classloader |WebAppClassLoader |while loading JSSE --- Additional Comments From [EMAIL PROTECTED] 2003-09-18 08:08 --- I don't think Tomcat has anything to do with that problem. JSSE is always loaded by the system classloader (as proven by your stack traces). The locked objects are also related to the system classloader, which (of course) Tomcat doesn't attempt to sync on. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] 5.0.12 stability rating
Remy Maucherat wrote: I didn't get futher reports concerning bug 21763 (and related), so I assume this means things improved. It would be a good idea to release a new 4.1.28 build once this is confirmed to also provide a fix for Tomcat 4.1.x. I've had some updates on this: - Rex Young confirmed than bug 21763 has been fixed (very cool ! Thanks for testing). - Ryan Lissack still experiences problems with the almost-latest (I think it doesn't include the latest catch Throwable change) tomcat-util from TC 5 (no thread is listening on the server socket anymore - for an unknown reason - after a period of time, under low to medium load; debugging traces show that the management of control runnables inside the pool is not at fault). Ryan is using Sun 1.4.1 Server JVM under Linux 2.4 on a 4 CPU server. I had doubts on the Sun Server VM, so he's going to test with the IBM VM (to which he'll switch to, as it performs faster, apparently). I hope the VM switch fixes the issue, because I don't see any problem with the socket handling code (unless the catch Throwable is somehow the needed fix, but there's apparently no trace in the logs about a problem like that). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat RELEASE-NOTES-3.3.2.txt
Larry Isaacs a écrit : Hi Henri, The software I work on in my day job has finally reached lockdown. Only documentation tasks remain. I'll try to get up to speed with with where things stand and begin working on a release plan this week. Sorry for the long delay. Ok, what do you think about imports cleanup ? Could I start commit it ? BTW, I could do the same also for JTC if everybody agree ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Cleaning import in JTC
I've got some time (and eclipse help) to work on cleaning imports. I'd like to start by jakarta-tomcat-connectors. Any objections ? Larry Isaacs a écrit : Hi Henri, The software I work on in my day job has finally reached lockdown. Only documentation tasks remain. I'll try to get up to speed with with where things stand and begin working on a release plan this week. Sorry for the long delay. Ok, what do you think about imports cleanup ? Could I start commit it ? BTW, I could do the same also for JTC if everybody agree ;) - 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: Cleaning import in JTC
Henri Gomez wrote: I've got some time (and eclipse help) to work on cleaning imports. I'd like to start by jakarta-tomcat-connectors. Any objections ? The HEAD should be clean. IMO, that's all that counts, since I think it wouldn't be a good idea to mess up the diffs on the maintenance branch (coyote_10). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 23180] - Deadlock in classloader while loading JSSE
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=23180. 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=23180 Deadlock in classloader while loading JSSE --- Additional Comments From [EMAIL PROTECTED] 2003-09-18 10:07 --- I agree in that the deadlock seems to be related only to JDK internal implementation. Anyway, the problem appears when a request is processed before the SSL connector initialization is finished. Is there any possibility of avoiding it by not accepting any request until all connectors are initialized? Could I force this behaviour through a valve or a filter or simething like this? I can upgrade my JDK, but it is not always possible or easy to do so in a customer host. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Duplicate Sessions Tomcat 4.1.24
I have a deployed web app with a medium size user base (~500) which recently went live. The app relies on the session to retrieve user information. The session usage is simply to store a couple of ids (Strings) and retrieve them from the session to lookup data. This all works perfectly with a small user base (~20) but horror of horrors, when loaded, people are seeing other peoples data. I have trawled through my code and, although as ever keeping an open mind, can only imagine this is happening if SESSIONID's are being duplicated and therefore the data is being overwritten by the other user(s). I remember a thread in January about duplicates in 4.1.18 Duplicate session IDs are *common*, but can't find anything in the bug database. Does anyone know if this ever was a problem or is still a problem in 4.1.24? What puzzles me is the relatively small number of concurrent users which cause this to happen. I am attempting to reproduce the problem in a sterile environment now, any thoughts, help or fixes :o) would be greatly appreciated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Duplicate Sessions Tomcat 4.1.24
Andy Chapman wrote: I have a deployed web app with a medium size user base (~500) which recently went live. The app relies on the session to retrieve user information. The session usage is simply to store a couple of ids (Strings) and retrieve them from the session to lookup data. This all works perfectly with a small user base (~20) but horror of horrors, when loaded, people are seeing other peoples data. I have trawled through my code and, although as ever keeping an open mind, can only imagine this is happening if SESSIONID's are being duplicated and therefore the data is being overwritten by the other user(s). I remember a thread in January about duplicates in 4.1.18 Duplicate session IDs are *common*, but can't find anything in the bug database. Does anyone know if this ever was a problem or is still a problem in 4.1.24? What puzzles me is the relatively small number of concurrent users which cause this to happen. I am attempting to reproduce the problem in a sterile environment now, any thoughts, help or fixes :o) would be greatly appreciated. A race condition in the session recycling code had been identified in 4.1.18, which could cause that (one session object could have been added more than once in the recycled session list). As a result, session recycling was disabled in 4.1.24 (and is removed from 5.0.x). No such issue has been found in 4.1.24, and we haven't had any report on such a behavior since 4.1.24 was released six months ago. I recommend you investigate more. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Duplicate Sessions Tomcat 4.1.24
Thanks Remy, I knew something as major as this would have surfaced and been fixed eons ago. However there is something here. After more brain-racking, a vital piece of the jigsaw has come to light. The app was updated at a suspiciously similar time to when the problem was reported. We use an ant script which does a stopextractstart type thing. Is it possible that after the re-start duplicate ids for the persisted and restored sessions are being created? -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED] Sent: 18 September 2003 12:05 To: Tomcat Developers List Subject: Re: Duplicate Sessions Tomcat 4.1.24 Andy Chapman wrote: I have a deployed web app with a medium size user base (~500) which recently went live. The app relies on the session to retrieve user information. The session usage is simply to store a couple of ids (Strings) and retrieve them from the session to lookup data. This all works perfectly with a small user base (~20) but horror of horrors, when loaded, people are seeing other peoples data. I have trawled through my code and, although as ever keeping an open mind, can only imagine this is happening if SESSIONID's are being duplicated and therefore the data is being overwritten by the other user(s). I remember a thread in January about duplicates in 4.1.18 Duplicate session IDs are *common*, but can't find anything in the bug database. Does anyone know if this ever was a problem or is still a problem in 4.1.24? What puzzles me is the relatively small number of concurrent users which cause this to happen. I am attempting to reproduce the problem in a sterile environment now, any thoughts, help or fixes :o) would be greatly appreciated. A race condition in the session recycling code had been identified in 4.1.18, which could cause that (one session object could have been added more than once in the recycled session list). As a result, session recycling was disabled in 4.1.24 (and is removed from 5.0.x). No such issue has been found in 4.1.24, and we haven't had any report on such a behavior since 4.1.24 was released six months ago. I recommend you investigate more. 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: Duplicate Sessions Tomcat 4.1.24
Andy Chapman wrote: Thanks Remy, I knew something as major as this would have surfaced and been fixed eons ago. However there is something here. After more brain-racking, a vital piece of the jigsaw has come to light. The app was updated at a suspiciously similar time to when the problem was reported. We use an ant script which does a stopextractstart type thing. Is it possible that after the re-start duplicate ids for the persisted and restored sessions are being created? No (it's a being-hit-by-a-meteor thing). However, the old sessions will still be there, which possibly may not be handled correctly by your app. Anyway, this kind of discussion should be posted on tomcat-user, there are no dev related issues at this point. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Help, jsessionid
Hi Use JBoss with Tomcat 4.1. We keep getting jsessionid in the URL's. Members have to accept cookies for our app to work. So how do we disable the jsessionid stuff showing up in the URL. Thanks Rajesh Rajesh Navar Founder, President CEO LiveDeal, Inc 953 Industrial Avenue, Suite 125 Palo Alto, CA 94303 Ph: (650) 320 9070 Office (650) 996 2445 Mobile (650) 320 8274 Fax
DO NOT REPLY [Bug 23233] - Dynfunctioning of the translation from JSP to Java
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=23233. 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=23233 Dynfunctioning of the translation from JSP to Java [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2003-09-18 14:55 --- There seems to be a mistake in the attached JSP (closing of %= should be %). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
build failure - tomcat 3.2.3
Hello,
I'm trying to build
tomcat 3.2.3 on hpux 11.i with java1.4.
#ant
webapps
and get the
following error ( end of output ):
[javac] symbol : class Context [javac]
location: class ContextAdmin
[javac]
Context context = new Context();
[javac]
^ [javac]
/system_dir/Gnu/11.i/64BITS/tomcat/jakarta-tomcat-3.2.3-src/src/admin/WEB-INF/classes/ContextAdmin.java:104:
cannot resolve symbol [javac] symbol : class
Context [javac] location: class
ContextAdmin
[javac]
Context context = new Context();
[javac]
^ [javac]
/system_dir/Gnu/11.i/64BITS/tomcat/jakarta-tomcat-3.2.3-src/src/admin/WEB-INF/classes/ContextAdmin.java:113:
package org.apache.tomcat.core does not exist
[javac]
catch(org.apache.tomcat.core.TomcatException ex) {
[javac]
^ [javac]
/system_dir/Gnu/11.i/64BITS/tomcat/jakarta-tomcat-3.2.3-src/src/admin/WEB-INF/classes/ContextAdmin.java:130:
package org.apache.tomcat.core does not exist
[javac]
catch(org.apache.tomcat.core.TomcatException ex) {
[javac]
^ [javac] 17 errors
BUILD
FAILED
/system_dir/Gnu/11.i/64BITS/tomcat/jakarta-tomcat-3.2.3-src/build.xml:179:
Compile failed, messages should have been provided.
Is this the
CLASSPATH probme?
Thanks in
advance,
Regards, Luda Carmon
-
The information contained in this message is proprietary of Amdocs,
protected from disclosure, and may be privileged.
The information is intended to be conveyed only to the designated recipient(s)
of the message. If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination, use, distribution or copying of
this communication is strictly prohibited and may be unlawful.
If you have received this communication in error, please notify us immediately
by replying to the message and deleting it from your computer.
Thank you.
-
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PATCH] fix compression=on option on coyote connector
OK - here's a simple patch that just fixes the problem and doesn't change
anything controversial :)
I will be glad to make the changes to include two new attributes on the
connector to specify the list of uncompressible mime types and
uncompressible user agents if a committer is willing to consider it.
Index: Http11Processor.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/
http11/Http11Processor.java,v
retrieving revision 1.78
diff -r1.78 Http11Processor.java
462a463,478
/**
* Checks if any entry in the string array starts with the specified
value
*
* @param sArray the StringArray
* @param value string
*/
private boolean startsWithStringArray(String sArray[], String value) {
if (value == null)
return false;
for (int i = 0; i sArray.length; i++) {
if (value.startsWith(sArray[i])) {
return true;
}
}
return false;
}
1216,1217c1232,1233
if (compressableMimeTypes != null)
return (inStringArray(compressableMimeTypes,
response.getContentType()));
---
if (compressableMimeTypes != null)
return (startsWithStringArray(compressableMimeTypes,
response.getContentType()));
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
hgomez 2003/09/18 09:09:16 Modified:util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java Log: Clean Import, the first one Revision ChangesPath 1.18 +15 -10 jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/PoolTcpEndpoint.java Index: PoolTcpEndpoint.java === RCS file: /home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/PoolTcpEndpoint.java,v retrieving revision 1.17 retrieving revision 1.18 diff -u -r1.17 -r1.18 --- PoolTcpEndpoint.java 13 Sep 2003 03:59:57 - 1.17 +++ PoolTcpEndpoint.java 18 Sep 2003 16:09:16 - 1.18 @@ -64,15 +64,20 @@ package org.apache.tomcat.util.net; -import org.apache.tomcat.util.res.*; -import org.apache.tomcat.util.collections.SimplePool; -import org.apache.tomcat.util.threads.*; -//import org.apache.tomcat.util.log.*; +import java.io.IOException; +import java.io.InterruptedIOException; +import java.net.BindException; +import java.net.InetAddress; +import java.net.ServerSocket; +import java.net.Socket; +import java.net.SocketException; + import org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory; - -import java.io.*; -import java.net.*; +import org.apache.tomcat.util.collections.SimplePool; +import org.apache.tomcat.util.res.StringManager; +import org.apache.tomcat.util.threads.ThreadPool; +import org.apache.tomcat.util.threads.ThreadPoolRunnable; /* Similar with MPM module in Apache2.0. Handles all the details related with tcp server functionality - thread management, accept policy, etc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net ServerSocketFactory.java
hgomez 2003/09/18 09:10:46 Modified:util/java/org/apache/tomcat/util/net/puretls PureTLSSocketFactory.java PureTLSImplementation.java PureTLSSupport.java PureTLSSocket.java util/java/org/apache/tomcat/util/net ServerSocketFactory.java Log: More import cleaned Revision ChangesPath 1.5 +11 -6 jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/puretls/PureTLSSocketFactory.java Index: PureTLSSocketFactory.java === RCS file: /home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/puretls/PureTLSSocketFactory.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- PureTLSSocketFactory.java 11 Jul 2003 04:09:43 - 1.4 +++ PureTLSSocketFactory.java 18 Sep 2003 16:10:45 - 1.5 @@ -59,13 +59,18 @@ package org.apache.tomcat.util.net.puretls; -import java.io.*; -import java.net.*; -import java.util.*; +import java.io.IOException; +import java.net.InetAddress; +import java.net.ServerSocket; +import java.net.Socket; +import java.net.SocketException; +import java.util.Vector; -import COM.claymoresystems.ptls.*; -import COM.claymoresystems.cert.*; -import COM.claymoresystems.sslg.*; +import COM.claymoresystems.ptls.SSLContext; +import COM.claymoresystems.ptls.SSLException; +import COM.claymoresystems.ptls.SSLServerSocket; +import COM.claymoresystems.ptls.SSLSocket; +import COM.claymoresystems.sslg.SSLPolicyInt; /** * SSL server socket factory--wraps PureTLS 1.2 +3 -5 jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/puretls/PureTLSImplementation.java Index: PureTLSImplementation.java === RCS file: /home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/puretls/PureTLSImplementation.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- PureTLSImplementation.java4 Oct 2002 20:03:10 - 1.1 +++ PureTLSImplementation.java18 Sep 2003 16:10:45 - 1.2 @@ -59,15 +59,13 @@ package org.apache.tomcat.util.net.puretls; +import java.net.Socket; + import org.apache.tomcat.util.net.SSLImplementation; import org.apache.tomcat.util.net.SSLSupport; import org.apache.tomcat.util.net.ServerSocketFactory; -import java.io.*; -import java.net.*; -import COM.claymoresystems.sslg.*; -import COM.claymoresystems.ptls.*; -import COM.claymoresystems.cert.*; +import COM.claymoresystems.ptls.SSLSocket; /* PureTLSImplementation: 1.3 +8 -7 jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/puretls/PureTLSSupport.java Index: PureTLSSupport.java === RCS file: /home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/puretls/PureTLSSupport.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- PureTLSSupport.java 16 Jun 2003 02:45:56 - 1.2 +++ PureTLSSupport.java 18 Sep 2003 16:10:45 - 1.3 @@ -59,17 +59,18 @@ package org.apache.tomcat.util.net.puretls; -import org.apache.tomcat.util.net.SSLSupport; -import java.io.*; -import java.net.*; -import java.util.Vector; +import java.io.ByteArrayInputStream; +import java.io.IOException; import java.security.cert.CertificateFactory; import java.security.cert.X509Certificate; +import java.util.Vector; + import org.apache.tomcat.util.buf.HexUtils; +import org.apache.tomcat.util.net.SSLSupport; -import COM.claymoresystems.sslg.*; -import COM.claymoresystems.ptls.*; -import COM.claymoresystems.cert.*; +import COM.claymoresystems.cert.X509Cert; +import COM.claymoresystems.ptls.SSLSocket; +import COM.claymoresystems.sslg.SSLPolicyInt; /* PureTLSSupport 1.2 +1 -6 jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/puretls/PureTLSSocket.java Index: PureTLSSocket.java === RCS file: /home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/puretls/PureTLSSocket.java,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- PureTLSSocket.java4 Oct 2002 20:03:10 - 1.1 +++ PureTLSSocket.java18 Sep 2003 16:10:45 - 1.2 @@ -59,12 +59,7 @@ package org.apache.tomcat.util.net.puretls; -import java.io.*; -import java.net.*; - -import COM.claymoresystems.ptls.*; -import COM.claymoresystems.cert.*; -import COM.claymoresystems.sslg.*; +import java.io.IOException; /* *
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat3 CoyoteInterceptor2.java Tomcat3Adapter.java Tomcat3Request.java Tomcat3Response.java
hgomez 2003/09/18 09:13:57 Modified:coyote/src/java/org/apache/coyote/tomcat4 CoyoteInputStream.java CoyoteServerSocketFactory.java Constants.java CoyoteOutputStream.java OutputBuffer.java CoyoteResponse.java CoyoteResponseFacade.java CoyoteRequestFacade.java CoyoteRequest.java CoyoteWriter.java coyote/src/java/org/apache/coyote/tomcat3 CoyoteInterceptor2.java Tomcat3Adapter.java Tomcat3Request.java Tomcat3Response.java Log: More import cleaned Revision ChangesPath 1.3 +1 -3 jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteInputStream.java Index: CoyoteInputStream.java === RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteInputStream.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- CoyoteInputStream.java3 Oct 2002 17:20:52 - 1.2 +++ CoyoteInputStream.java18 Sep 2003 16:13:51 - 1.3 @@ -60,14 +60,12 @@ package org.apache.coyote.tomcat4; -import java.io.InputStream; import java.io.IOException; import javax.servlet.ServletInputStream; -import org.apache.tomcat.util.buf.ByteChunk; - import org.apache.coyote.Request; +import org.apache.tomcat.util.buf.ByteChunk; /** 1.5 +0 -9 jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteServerSocketFactory.java Index: CoyoteServerSocketFactory.java === RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteServerSocketFactory.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- CoyoteServerSocketFactory.java19 Jun 2002 09:25:39 - 1.4 +++ CoyoteServerSocketFactory.java18 Sep 2003 16:13:51 - 1.5 @@ -59,17 +59,8 @@ package org.apache.coyote.tomcat4; import java.io.File; -import java.io.FileInputStream; -import java.io.IOException; import java.net.InetAddress; import java.net.ServerSocket; -import java.security.KeyStore; -import java.security.KeyStoreException; -import java.security.NoSuchAlgorithmException; -import java.security.UnrecoverableKeyException; -import java.security.KeyManagementException; -import java.security.Security; -import java.security.cert.CertificateException; /** 1.7 +0 -1 jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/Constants.java Index: Constants.java === RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/Constants.java,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- Constants.java28 Apr 2003 17:08:25 - 1.6 +++ Constants.java18 Sep 2003 16:13:51 - 1.7 @@ -58,7 +58,6 @@ */ package org.apache.coyote.tomcat4; -import java.util.Locale; /** * Constants. 1.3 +0 -2 jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteOutputStream.java Index: CoyoteOutputStream.java === RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteOutputStream.java,v retrieving revision 1.2 retrieving revision 1.3 diff -u -r1.2 -r1.3 --- CoyoteOutputStream.java 6 Nov 2002 09:26:42 - 1.2 +++ CoyoteOutputStream.java 18 Sep 2003 16:13:51 - 1.3 @@ -64,8 +64,6 @@ import javax.servlet.ServletOutputStream; -import org.apache.coyote.Response; - /** * Coyote implementation of the servlet output stream. * 1.11 +0 -3 jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/OutputBuffer.java Index: OutputBuffer.java === RCS file: /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/OutputBuffer.java,v retrieving revision 1.10 retrieving revision 1.11 diff -u -r1.10 -r1.11 --- OutputBuffer.java 15 Sep 2003 14:16:17 - 1.10 +++ OutputBuffer.java 18 Sep 2003 16:13:51 - 1.11 @@ -60,9 +60,6 @@ package org.apache.coyote.tomcat4; import java.io.IOException; -import java.io.OutputStream; -import java.io.OutputStreamWriter; -import java.io.UnsupportedEncodingException; import java.io.Writer; import java.util.Hashtable; 1.33 +10 -24
Re: [VOTE] 5.0.12 stability rating
Remy Maucherat wrote: ballot [ ] Alpha [X ] Beta /ballot -- Jeanfrancois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java JkCoyoteHandler.java
hgomez 2003/09/18 09:21:02 Modified:jk/java/org/apache/jk/common Shm.java JniHandler.java MsgAjp.java ChannelShm.java WorkerDummy.java ChannelUn.java ChannelJni.java jk/java/org/apache/ajp/tomcat4 Ajp13Processor.java Ajp13Request.java Ajp13Connector.java JkServlet.java jk/java/org/apache/ajp/tomcat33 Ajp14Interceptor.java jk/java/org/apache/jk/apr TomcatStarter.java jk/java/org/apache/jk/config GeneratorJk1.java GeneratorApache2.java GeneratorJk2.java WebXml2Jk.java jk/java/org/apache/ajp AjpHandler.java NegociationHandler.java Ajp13Packet.java RequestHandler.java Ajp13.java jk/java/org/apache/jk/core MsgContext.java Msg.java jk/java/org/apache/ajp/tomcat4/config ApacheConfig.java jk/java/org/apache/jk/server JkMain.java JkCoyoteHandler.java Log: Last batch of clean import. More next week (if Remy didn't drop my commiter status before ;) Revision ChangesPath 1.13 +7 -12 jakarta-tomcat-connectors/jk/java/org/apache/jk/common/Shm.java Index: Shm.java === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/Shm.java,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- Shm.java 28 May 2002 22:51:11 - 1.12 +++ Shm.java 18 Sep 2003 16:21:00 - 1.13 @@ -59,20 +59,15 @@ package org.apache.jk.common; -import java.io.*; - -import java.net.*; -import java.util.*; - -import org.apache.tomcat.util.buf.*; -import org.apache.tomcat.util.http.*; - -import org.apache.tomcat.util.threads.*; - -import org.apache.jk.core.*; -import org.apache.jk.apr.*; +import java.io.IOException; +import java.util.Vector; +import org.apache.jk.apr.AprImpl; +import org.apache.jk.core.Msg; +import org.apache.jk.core.MsgContext; +import org.apache.jk.core.WorkerEnv; import org.apache.tomcat.util.IntrospectionUtils; +import org.apache.tomcat.util.buf.C2BConverter; /* The code is a bit confusing at this moment - the class is used as a Bean, or ant Task, or CLI - i.e. you set properties and call execute. 1.13 +9 -11 jakarta-tomcat-connectors/jk/java/org/apache/jk/common/JniHandler.java Index: JniHandler.java === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/JniHandler.java,v retrieving revision 1.12 retrieving revision 1.13 diff -u -r1.12 -r1.13 --- JniHandler.java 19 Apr 2003 21:09:44 - 1.12 +++ JniHandler.java 18 Sep 2003 16:21:00 - 1.13 @@ -59,20 +59,18 @@ package org.apache.jk.common; -import java.io.*; +import java.io.IOException; -import java.net.*; -import java.util.*; - -import org.apache.tomcat.util.buf.*; -import org.apache.tomcat.util.http.*; - -import org.apache.tomcat.util.threads.*; +import javax.management.ObjectName; -import org.apache.jk.core.*; -import org.apache.jk.apr.*; import org.apache.commons.modeler.Registry; -import javax.management.ObjectName; +import org.apache.jk.apr.AprImpl; +import org.apache.jk.core.JkHandler; +import org.apache.jk.core.Msg; +import org.apache.jk.core.MsgContext; +import org.apache.tomcat.util.buf.ByteChunk; +import org.apache.tomcat.util.buf.C2BConverter; +import org.apache.tomcat.util.buf.MessageBytes; /** 1.14 +3 -12 jakarta-tomcat-connectors/jk/java/org/apache/jk/common/MsgAjp.java Index: MsgAjp.java === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/MsgAjp.java,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- MsgAjp.java 20 Jan 2003 19:20:32 - 1.13 +++ MsgAjp.java 18 Sep 2003 16:21:00 - 1.14 @@ -59,19 +59,10 @@ package org.apache.jk.common; import java.io.IOException; -import java.io.UnsupportedEncodingException; -import java.io.InputStream; -import java.io.OutputStream; -import java.net.Socket; -import java.util.Enumeration; -import java.security.*; -import org.apache.tomcat.util.http.MimeHeaders; -import org.apache.tomcat.util.buf.*; -import org.apache.tomcat.util.http.HttpMessages; -import org.apache.tomcat.util.buf.HexUtils; - -import org.apache.jk.core.*; +import org.apache.jk.core.Msg; +import org.apache.tomcat.util.buf.ByteChunk; +import org.apache.tomcat.util.buf.MessageBytes; /** * A single packet for communication between the
Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkMain.java JkCoyoteHandler.java
[EMAIL PROTECTED] wrote: hgomez 2003/09/18 09:21:02 Modified:jk/java/org/apache/jk/common Shm.java JniHandler.java MsgAjp.java ChannelShm.java WorkerDummy.java ChannelUn.java ChannelJni.java jk/java/org/apache/ajp/tomcat4 Ajp13Processor.java Ajp13Request.java Ajp13Connector.java JkServlet.java jk/java/org/apache/ajp/tomcat33 Ajp14Interceptor.java jk/java/org/apache/jk/apr TomcatStarter.java jk/java/org/apache/jk/config GeneratorJk1.java GeneratorApache2.java GeneratorJk2.java WebXml2Jk.java jk/java/org/apache/ajp AjpHandler.java NegociationHandler.java Ajp13Packet.java RequestHandler.java Ajp13.java jk/java/org/apache/jk/core MsgContext.java Msg.java jk/java/org/apache/ajp/tomcat4/config ApacheConfig.java jk/java/org/apache/jk/server JkMain.java JkCoyoteHandler.java Log: Last batch of clean import. More next week (if Remy didn't drop my commiter status before ;) I'm not root, I can't do that ;-) Anyway, it's weird, I thought I had done it already. Eclipse sucks (or I misconfigured it, which is likely) :) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Temporary (for development) CLASSPATH problem (tomcat 4)
I know Tomcat expects the classes for a given web-app to be here: /webapps/myApplication/WEB-INF/classes or, wherever I point server.xml to: C:/stuff/myApplication/WEB-INF/classes but what if I want /myApplication to exist on a network drive (source control), and my classes for that webApplication to be compiled to my local drive. I want this, so all of my .jsp and such in source control, and editable straight from source control, but I do not want my classes to be compiled AND loaded from the network drive. Is there a way to configure my applications web.xml to include other directories for classes? Peter Swulius Software Engineer Zix Corporation Office: 214-370-2093 Cell: 214-766-2295 [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Temporary (for development) CLASSPATH problem (tomcat 4)
How about using ant to compile and deploy your application? This would enable you to have complete control over the locations of your source files, your compilied classes and the war file. Mark On Thursday, September 18, 2003 6:45 PM, Peter Swulius [SMTP:[EMAIL PROTECTED] wrote: File: ATT00023.txt; charset = Windows-1252 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[patch] wrong rx to invalid url
I'd like to commit something along these lines to the
v4 and v5 CoyoteAdaptors:
--- coyote/src/java/org/apache/coyote/tomcat4/CoyoteAdapter.java16 Mar 2003
01:56:27 - 1.13.2.3
+++ coyote/src/java/org/apache/coyote/tomcat4/CoyoteAdapter.java18 Sep 2003
19:45:09 -
@@ -273,7 +273,13 @@
// URI decoding
req.decodedURI().duplicate(req.requestURI());
-req.getURLDecoder().convert(req.decodedURI(), false);
+try {
+ req.getURLDecoder().convert(req.decodedURI(), false);
+} catch (IOException ioe) {
+res.setStatus(400);
+res.setMessage(Invalid URI);
+throw new IOException(Invalid URI);
+}
req.decodedURI().setEncoding(UTF-8);
// Normalize decoded URI
UDecoder.convert will throw a CharConversionException for
urls which contain '%' with invalid or no trailing hex digits.
This exception is ignored and Tomcat is returning a 200 with
an empty body, which is wrong.
Any suggestions on a better way to correct are welcome.
Keith
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch] wrong rx to invalid url
Keith Wannamaker wrote:
I'd like to commit something along these lines to the
v4 and v5 CoyoteAdaptors:
--- coyote/src/java/org/apache/coyote/tomcat4/CoyoteAdapter.java16 Mar 2003
01:56:27 - 1.13.2.3
+++ coyote/src/java/org/apache/coyote/tomcat4/CoyoteAdapter.java18 Sep 2003
19:45:09 -
@@ -273,7 +273,13 @@
// URI decoding
req.decodedURI().duplicate(req.requestURI());
-req.getURLDecoder().convert(req.decodedURI(), false);
+try {
+ req.getURLDecoder().convert(req.decodedURI(), false);
+} catch (IOException ioe) {
+res.setStatus(400);
+res.setMessage(Invalid URI);
+throw new IOException(Invalid URI);
+}
req.decodedURI().setEncoding(UTF-8);
// Normalize decoded URI
UDecoder.convert will throw a CharConversionException for
urls which contain '%' with invalid or no trailing hex digits.
This exception is ignored and Tomcat is returning a 200 with
an empty body, which is wrong.
Any suggestions on a better way to correct are welcome.
+1, this seems ok (good thing the request is properly recycled anyway).
BTW, can't the original ioe be rethrown (this seems simpler) ?
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
ManagerServlet undeploy
Undeploy fails for any app that's not installed under webapps directory.
For example, an attempt to undeploy /admin will fail with Cannot
undeploy document base for path /admin because of the following lines
from ManagerServlet line 1384
// Validate the docBase path of this application
String deployedPath = deployed.getCanonicalPath();
String docBase = context.getDocBase();
File docBaseDir = new File(docBase);
if (!docBaseDir.isAbsolute()) {
docBaseDir = new File(appBaseDir, docBase);
}
String docBasePath = docBaseDir.getCanonicalPath();
if (!docBasePath.startsWith(deployedPath)) {
writer.println(sm.getString(managerServlet.noDocBase,
displayPath));
return;
}
Any app that's installed using context configuration file with docBase
other than ../webapps will not pass the condition since deployedPath
is always ../webapps.
What is the reasoning behind this validation?
Thanks,
Amy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [patch] wrong rx to invalid url
Yes it can be, good catch.
Keith
| -Original Message-
| From: Remy Maucherat [mailto:[EMAIL PROTECTED]
| Sent: Thursday, September 18, 2003 4:07 PM
| To: Tomcat Developers List
| Subject: Re: [patch] wrong rx to invalid url
|
|
| Keith Wannamaker wrote:
|
| I'd like to commit something along these lines to the
| v4 and v5 CoyoteAdaptors:
|
| --- coyote/src/java/org/apache/coyote/tomcat4/CoyoteAdapter.java16 Mar
2003 01:56:27 - 1.13.2.3
| +++ coyote/src/java/org/apache/coyote/tomcat4/CoyoteAdapter.java18 Sep
2003 19:45:09 -
| @@ -273,7 +273,13 @@
|
| // URI decoding
| req.decodedURI().duplicate(req.requestURI());
| -req.getURLDecoder().convert(req.decodedURI(), false);
| +try {
| + req.getURLDecoder().convert(req.decodedURI(), false);
| +} catch (IOException ioe) {
| +res.setStatus(400);
| +res.setMessage(Invalid URI);
| +throw new IOException(Invalid URI);
| +}
| req.decodedURI().setEncoding(UTF-8);
|
| // Normalize decoded URI
|
| UDecoder.convert will throw a CharConversionException for
| urls which contain '%' with invalid or no trailing hex digits.
| This exception is ignored and Tomcat is returning a 200 with
| an empty body, which is wrong.
|
| Any suggestions on a better way to correct are welcome.
|
| +1, this seems ok (good thing the request is properly recycled anyway).
| BTW, can't the original ioe be rethrown (this seems simpler) ?
|
| 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/coyote/src/java/org/apache/coyote/tomcat4 CoyoteAdapter.java
keith 2003/09/18 13:53:01
Modified:coyote/src/java/org/apache/coyote/tomcat4 CoyoteAdapter.java
Log:
Respond 400 to requests which contain '%' with no or invalid trailing hex digits
Revision ChangesPath
1.20 +11 -5
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteAdapter.java
Index: CoyoteAdapter.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteAdapter.java,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -r1.19 -r1.20
--- CoyoteAdapter.java3 Jul 2003 00:15:16 - 1.19
+++ CoyoteAdapter.java18 Sep 2003 20:53:01 - 1.20
@@ -256,7 +256,13 @@
// URI decoding
req.decodedURI().duplicate(req.requestURI());
-req.getURLDecoder().convert(req.decodedURI(), false);
+try {
+ req.getURLDecoder().convert(req.decodedURI(), false);
+} catch (IOException ioe) {
+res.setStatus(400);
+res.setMessage(Invalid URI);
+throw ioe;
+}
req.decodedURI().setEncoding(UTF-8);
// Normalize decoded URI
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardWrapper.java
Remy Maucherat wrote: [EMAIL PROTECTED] wrote: luehe 2003/09/17 16:26:33 Modified:catalina/src/share/org/apache/catalina/core StandardWrapper.java Log: Fix for Bugtraq 4924326 (JMX registrations of servlets that map to the same jsp-file use the same name) There was also a similar issue in the request dispatcher, where the mapped servlet path was overriden (for no good reason IMO) with the JSP file. What was the reasoning behind this code ? I don't see any reference to StandardWrapper.getJspFile() in ApplicationDispatcher (other than to set the Globals.JSP_FILE_ATTR request attribute), so this should not be an issue any more. Jan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/bin setclasspath.sh
kinman 2003/09/18 14:04:51 Modified:catalina/src/bin setclasspath.sh Log: - Fix so I can debug tomcat on Unix again. Revision ChangesPath 1.6 +2 -2 jakarta-tomcat-catalina/catalina/src/bin/setclasspath.sh Index: setclasspath.sh === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/bin/setclasspath.sh,v retrieving revision 1.5 retrieving revision 1.6 diff -u -r1.5 -r1.6 --- setclasspath.sh 31 Jul 2003 15:17:55 - 1.5 +++ setclasspath.sh 18 Sep 2003 21:04:51 - 1.6 @@ -53,7 +53,7 @@ # Set standard commands for invoking Java. _RUNJAVA=$JAVA_HOME/bin/java -if [ ! $os400 ]; then +if [ $os400 = false ]; then _RUNJDB=$JAVA_HOME/bin/jdb fi _RUNJAVAC=$JAVA_HOME/bin/javac - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [patch] wrong rx to invalid url
+1 From me as well.
- Original Message -
From: Keith Wannamaker [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Thursday, September 18, 2003 1:24 PM
Subject: RE: [patch] wrong rx to invalid url
Yes it can be, good catch.
Keith
| -Original Message-
| From: Remy Maucherat [mailto:[EMAIL PROTECTED]
| Sent: Thursday, September 18, 2003 4:07 PM
| To: Tomcat Developers List
| Subject: Re: [patch] wrong rx to invalid url
|
|
| Keith Wannamaker wrote:
|
| I'd like to commit something along these lines to the
| v4 and v5 CoyoteAdaptors:
|
| --- coyote/src/java/org/apache/coyote/tomcat4/CoyoteAdapter.java
16 Mar 2003 01:56:27 - 1.13.2.3
| +++ coyote/src/java/org/apache/coyote/tomcat4/CoyoteAdapter.java
18 Sep 2003 19:45:09 -
| @@ -273,7 +273,13 @@
|
| // URI decoding
| req.decodedURI().duplicate(req.requestURI());
| -req.getURLDecoder().convert(req.decodedURI(), false);
| +try {
| + req.getURLDecoder().convert(req.decodedURI(), false);
| +} catch (IOException ioe) {
| +res.setStatus(400);
| +res.setMessage(Invalid URI);
| +throw new IOException(Invalid URI);
| +}
| req.decodedURI().setEncoding(UTF-8);
|
| // Normalize decoded URI
|
| UDecoder.convert will throw a CharConversionException for
| urls which contain '%' with invalid or no trailing hex digits.
| This exception is ignored and Tomcat is returning a 200 with
| an empty body, which is wrong.
|
| Any suggestions on a better way to correct are welcome.
|
| +1, this seems ok (good thing the request is properly recycled anyway).
| BTW, can't the original ioe be rethrown (this seems simpler) ?
|
| 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]
This message is intended only for the use of the person(s) listed above as the
intended recipient(s), and may contain information that is PRIVILEGED and
CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or
distribute this message or any attachment. If you received this communication in
error, please notify us immediately by e-mail and then delete all copies of this
message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the
Internet is not secure. Do not send confidential or sensitive information, such as
social security numbers, account numbers, personal identification numbers and
passwords, to us via ordinary (unencrypted) e-mail.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: ManagerServlet undeploy
This is required for when the web app is not run from a war but
unpacked into the appDir for the Host.
I think it is a reasonable restriction to require that a web application
be placed in the appDir configured for the Host. When you are running
with the SecurityManager this can make setting the security policy easier.
Glenn
Amy Roh wrote:
Undeploy fails for any app that's not installed under webapps directory.
For example, an attempt to undeploy /admin will fail with Cannot
undeploy document base for path /admin because of the following lines
from ManagerServlet line 1384
// Validate the docBase path of this application
String deployedPath = deployed.getCanonicalPath();
String docBase = context.getDocBase();
File docBaseDir = new File(docBase);
if (!docBaseDir.isAbsolute()) {
docBaseDir = new File(appBaseDir, docBase);
}
String docBasePath = docBaseDir.getCanonicalPath();
if (!docBasePath.startsWith(deployedPath)) {
writer.println(sm.getString(managerServlet.noDocBase,
displayPath));
return;
}
Any app that's installed using context configuration file with docBase
other than ../webapps will not pass the condition since deployedPath
is always ../webapps.
What is the reasoning behind this validation?
Thanks,
Amy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
--
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteAdapter.java
keith 2003/09/18 15:20:51
Modified:catalina/src/share/org/apache/coyote/tomcat5
CoyoteAdapter.java
Log:
Respond 400 to requests which contain '%' with no or invalid trailing hex digits
Revision ChangesPath
1.13 +11 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteAdapter.java
Index: CoyoteAdapter.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteAdapter.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- CoyoteAdapter.java7 Sep 2003 07:38:42 - 1.12
+++ CoyoteAdapter.java18 Sep 2003 22:20:51 - 1.13
@@ -265,7 +265,13 @@
// URI decoding
MessageBytes decodedURI = req.decodedURI();
decodedURI.duplicate(req.requestURI());
-req.getURLDecoder().convert(decodedURI, false);
+try {
+ req.getURLDecoder().convert(decodedURI, false);
+} catch (IOException ioe) {
+ res.setStatus(400);
+ res.setMessage(Invalid URI);
+ throw ioe;
+}
// Normalize decoded URI
if (!normalize(req.decodedURI())) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteAdapter.java
I been unsuccessful all afternoon at building j-t-catalina, and end-of-day
has caught me. If this commit gives anyone fits, let me know and I'll be
glad to roll it back.
Keith
| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
| Sent: Thursday, September 18, 2003 6:21 PM
| To: [EMAIL PROTECTED]
| Subject: cvs commit:
| jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5
| CoyoteAdapter.java
|
|
| keith 2003/09/18 15:20:51
|
| Modified:catalina/src/share/org/apache/coyote/tomcat5
| CoyoteAdapter.java
| Log:
| Respond 400 to requests which contain '%' with no or invalid trailing hex digits
|
| Revision ChangesPath
| 1.13 +11 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteAdapter.java
|
| Index: CoyoteAdapter.java
| ===
| RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteAdapter.java,v
| retrieving revision 1.12
| retrieving revision 1.13
| diff -u -r1.12 -r1.13
| --- CoyoteAdapter.java 7 Sep 2003 07:38:42 - 1.12
| +++ CoyoteAdapter.java 18 Sep 2003 22:20:51 - 1.13
| @@ -265,7 +265,13 @@
|// URI decoding
|MessageBytes decodedURI = req.decodedURI();
|decodedURI.duplicate(req.requestURI());
| -req.getURLDecoder().convert(decodedURI, false);
| +try {
| + req.getURLDecoder().convert(decodedURI, false);
| +} catch (IOException ioe) {
| + res.setStatus(400);
| + res.setMessage(Invalid URI);
| + throw ioe;
| +}
|
|// Normalize decoded URI
|if (!normalize(req.decodedURI())) {
|
|
|
|
| -
| 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-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteRequest.java
luehe 2003/09/18 15:50:08
Modified:catalina/src/share/org/apache/coyote/tomcat5
CoyoteRequest.java
Log:
Separated JSESSION cookie configuration into its own method, which may be overridden
Revision ChangesPath
1.17 +26 -15
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java
Index: CoyoteRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- CoyoteRequest.java11 Sep 2003 03:56:48 - 1.16
+++ CoyoteRequest.java18 Sep 2003 22:50:08 - 1.17
@@ -2245,19 +2245,10 @@
// Creating a new session cookie based on that session
if ((session != null) (getContext() != null)
- getContext().getCookies()) {
+getContext().getCookies()) {
Cookie cookie = new Cookie(Globals.SESSION_COOKIE_NAME,
session.getId());
-cookie.setMaxAge(-1);
-String contextPath = null;
-if (context != null)
-contextPath = context.getPath();
-if ((contextPath != null) (contextPath.length() 0))
-cookie.setPath(contextPath);
-else
-cookie.setPath(/);
-if (isSecure())
-cookie.setSecure(true);
+configureSessionCookie(cookie);
((HttpServletResponse) response).addCookie(cookie);
}
@@ -2268,6 +2259,26 @@
}
+/**
+ * Configures the given JSESSIONID cookie.
+ *
+ * @param cookie The JSESSIONID cookie to be configured
+ */
+protected void configureSessionCookie(Cookie cookie) {
+cookie.setMaxAge(-1);
+String contextPath = null;
+if (getContext() != null) {
+contextPath = getContext().getPath();
+}
+if ((contextPath != null) (contextPath.length() 0)) {
+cookie.setPath(contextPath);
+} else {
+cookie.setPath(/);
+}
+if (isSecure()) {
+cookie.setSecure(true);
+}
+}
/**
* Parse request parameters.
-
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 Generator.java
kinman 2003/09/18 16:12:39
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
Log:
- When adjusting Java lines for tag handler codes that are generated in a body,
make sure to include the CustomTag node itself. This avoid strange Smap
mappings in some cases.
- Fix 22058: _jspx_push_body_count is not defined in a fragment, causing
compilation errors when it is needed. A _jspx_push_body_count is now
defined in the Fragment_Helper class; its constructor and invokation
adjusted accordingly.
Revision ChangesPath
1.209 +35 -16
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.208
retrieving revision 1.209
diff -u -r1.208 -r1.209
--- Generator.java16 Sep 2003 17:46:43 - 1.208
+++ Generator.java18 Sep 2003 23:12:39 - 1.209
@@ -1636,7 +1636,7 @@
// Set up new buffer for the method
outSave = out;
GenBuffer genBuffer =
-new GenBuffer(n.implementsSimpleTag() ? null : n.getBody());
+new GenBuffer(n.implementsSimpleTag() ? null : n);
methodsBuffered.add(genBuffer);
out = genBuffer.getOut();
@@ -2957,11 +2957,17 @@
isSimpleTagParent = true;
boolean tmpIsFragment = isFragment;
isFragment = true;
+String pushBodyCountVarSave = pushBodyCountVar;
+if (pushBodyCountVar != null) {
+// Use a fixed name for push body count, to simplify code gen
+pushBodyCountVar = _jspx_push_body_count;
+}
visitBody(n);
out = outSave;
parent = tmpParent;
isSimpleTagParent = isSimpleTagParentSave;
isFragment = tmpIsFragment;
+pushBodyCountVar = pushBodyCountVarSave;
fragmentHelperClass.closeFragment(fragment, methodNesting);
// XXX - Need to change pageContext to jspContext if
// we're not in a place where pageContext is defined (e.g.
@@ -2973,6 +2979,8 @@
+ fragment.getId()
+ , pageContext,
+ tagHandlerVar
++ ,
++ pushBodyCountVar
+ ));
}
@@ -3691,14 +3699,17 @@
*/
private static class GenBuffer {
-private Node.Nodes body;
+private Node node;
private java.io.CharArrayWriter charWriter;
protected ServletWriter out;
-GenBuffer(Node.Nodes body) {
-this.body = body;
-if (body != null) {
-body.setGeneratedInBuffer(true);
+GenBuffer(Node n) {
+node = n;
+if (n != null) {
+Node.Nodes body = n.getBody();
+if (body != null) {
+body.setGeneratedInBuffer(true);
+}
}
charWriter = new java.io.CharArrayWriter();
out = new ServletWriter(new java.io.PrintWriter(charWriter));
@@ -3720,9 +3731,10 @@
*/
public void adjustJavaLines(final int offset) {
-if (body != null) {
+if (node != null) {
try {
-body.visit(new Node.Visitor() {
+node.accept(new Node.Visitor() {
+
public void doVisit(Node n) {
if (n.getBeginJavaLine() 0) {
n.setBeginJavaLine(
@@ -3735,7 +3747,11 @@
throws JasperException {
doVisit(n);
Node.Nodes body = n.getBody();
-if (body != null !body.isGeneratedInBuffer()) {
+if (body != null
+((node == n) || !body.isGeneratedInBuffer())) {
+// We want to adjust the Java lines only for
+// top level Custom tags, unless its body is
+// not generated in a buffer.
body.visit(this);
}
}
@@ -3755,9 +3771,9 @@
private GenBuffer genBuffer;
private int id;
-public Fragment(int id, Node.Nodes body) {
+public Fragment(int id, Node node) {
this.id = id;
-genBuffer = new GenBuffer(body);
[PATCH] jakarta-servletapi-5: API update
Hi, The attached file is to update the Servlet 2.4 API. Changes are synchronizing with the latest specification and fixing a typo and a bad indentation. All semantics stay the same. o Fix typo and indentation: jsr154/src/share/javax/servlet/Filter.java jsr154/src/share/javax/servlet/FilterChain.java jsr154/src/share/javax/servlet/GenericServlet.java jsr154/src/share/javax/servlet/ServletContext.java jsr154/src/share/javax/servlet/ServletContextAttributeEvent.java jsr154/src/share/javax/servlet/ServletContextAttributeListener.java jsr154/src/share/javax/servlet/ServletContextEvent.java jsr154/src/share/javax/servlet/ServletOutputStream.java jsr154/src/share/javax/servlet/ServletRequest.java jsr154/src/share/javax/servlet/ServletResponse.java jsr154/src/share/javax/servlet/http/HttpServletRequest.java jsr154/src/share/javax/servlet/http/HttpServletResponse.java jsr154/src/share/javax/servlet/http/HttpSession.java jsr154/src/share/javax/servlet/http/HttpSessionBindingEvent.java o Synchronize with the spec: jsr154/src/share/javax/servlet/ServletContextListener.java jsr154/src/share/javax/servlet/ServletRequestAttributeEvent.java jsr154/src/share/javax/servlet/ServletRequestAttributeListener.java jsr154/src/share/javax/servlet/ServletRequestEvent.java jsr154/src/share/javax/servlet/ServletRequestListener.java == Thank you, Yutaka Yoshida Sun Microsystems Index: jsr154/src/share/javax/servlet/Filter.java === RCS file: /home/cvspublic/jakarta-servletapi-5/jsr154/src/share/javax/servlet/Filter.java,v retrieving revision 1.2 diff -u -r1.2 Filter.java --- jsr154/src/share/javax/servlet/Filter.java 18 Aug 2003 16:50:33 - 1.2 +++ jsr154/src/share/javax/servlet/Filter.java 18 Sep 2003 23:34:58 - @@ -114,7 +114,7 @@ * filter content or headers for output filtering br * 4. a) strongEither/strong invoke the next entity in the chain using the FilterChain object (codechain.doFilter()/code), br ** 4. b) strongor/strong not pass on the request/response pair to the next entity in the filter chain to block the request processingbr - ** 5. Directly set headers on the response after invocation of the next entity in ther filter chain. + ** 5. Directly set headers on the response after invocation of the next entity in the filter chain. **/ public void doFilter ( ServletRequest request, ServletResponse response, FilterChain chain ) throws IOException, ServletException; Index: jsr154/src/share/javax/servlet/FilterChain.java === RCS file: /home/cvspublic/jakarta-servletapi-5/jsr154/src/share/javax/servlet/FilterChain.java,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 FilterChain.java --- jsr154/src/share/javax/servlet/FilterChain.java 13 Aug 2002 16:21:42 - 1.1.1.1 +++ jsr154/src/share/javax/servlet/FilterChain.java 18 Sep 2003 23:34:58 - @@ -66,7 +66,7 @@ * A FilterChain is an object provided by the servlet container to the developer * giving a view into the invocation chain of a filtered request for a resource. Filters * use the FilterChain to invoke the next filter in the chain, or if the calling filter -* is the last filter in the chain, to invoke the rosource at the end of the chain. +* is the last filter in the chain, to invoke the resource at the end of the chain. * * @see Filter * @since Servlet 2.3 Index: jsr154/src/share/javax/servlet/GenericServlet.java === RCS file: /home/cvspublic/jakarta-servletapi-5/jsr154/src/share/javax/servlet/GenericServlet.java,v retrieving revision 1.2 diff -u -r1.2 GenericServlet.java --- jsr154/src/share/javax/servlet/GenericServlet.java 11 Jan 2003 00:26:02 - 1.2 +++ jsr154/src/share/javax/servlet/GenericServlet.java 18 Sep 2003 23:34:58 - @@ -136,7 +136,7 @@ * of the initialization parameter * * @return String a codeString/code containing the value - * of the initalization parameter + * of the initialization parameter * */ Index: jsr154/src/share/javax/servlet/ServletContext.java === RCS file: /home/cvspublic/jakarta-servletapi-5/jsr154/src/share/javax/servlet/ServletContext.java,v retrieving revision 1.5 diff -u -r1.5 ServletContext.java --- jsr154/src/share/javax/servlet/ServletContext.java 2 Sep 2003 21:14:10 - 1.5 +++ jsr154/src/share/javax/servlet/ServletContext.java 18 Sep 2003 23:34:58 - @@ -674,7 +674,7 @@ public void removeAttribute(String name); /** - * Returns the name of this web application correponding
DO NOT REPLY [Bug 22058] - incorrect JSP compilation
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=22058. 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=22058 incorrect JSP compilation [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ManagerServlet undeploy
Amy Roh wrote:
Undeploy fails for any app that's not installed under webapps directory.
For example, an attempt to undeploy /admin will fail with Cannot
undeploy document base for path /admin because of the following lines
from ManagerServlet line 1384
// Validate the docBase path of this application
String deployedPath = deployed.getCanonicalPath();
String docBase = context.getDocBase();
File docBaseDir = new File(docBase);
if (!docBaseDir.isAbsolute()) {
docBaseDir = new File(appBaseDir, docBase);
}
String docBasePath = docBaseDir.getCanonicalPath();
if (!docBasePath.startsWith(deployedPath)) {
writer.println(sm.getString(managerServlet.noDocBase,
displayPath));
return;
}
Any app that's installed using context configuration file with docBase
other than ../webapps will not pass the condition since deployedPath
is always ../webapps.
What is the reasoning behind this validation?
A webapp which isn't in the host appbase shouldn't be deleted because it
wasn't installed by the manager. Not allowing to undeploy is a bit too
much, and I'll fix the condition (maybe I did cut paste from somewhere
else ...) :-)
Basically the updated logic will be:
- if the WAR is somewhere, and the expanded dir is in appBase, remove
the expanded dir
- if there's a context file, remove it
That's consistent with the behavior for a webapp deployed in appBase,
while avoiding removing stuff which isn't under Tomcat control.
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
