DO NOT REPLY [Bug 14007] - Incorrect validation of optional package.
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=14007. 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=14007 Incorrect validation of optional package. --- Additional Comments From [EMAIL PROTECTED] 2002-11-03 10:24 --- Servlet-2.4 spec requires Dependencies On Extensions(see SRV.9.7.1), But Servlet-2.3 spec doesn't require that. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Tomcat scalability
1. For a project my company is working on we have transactions requirements of 1600 transactions per second. The transactions consists of processing a servlet in Tomcat, doing a database call and then displaying the results to the user so the effective number of transactions Tomcat has to process is actually greater than 1600. Can Tomcat cope with 1600 requests in a second(a 4 processor Sunfire machine will be used)? Based upon our current application architecture(our java application has tomcat running inside it), 1600 request per second means we may have 1600 threads open simultaneously. 2. From one article I read at linux journal, Tomcat 3 didn't scale very well with multiple processors because of JVM issues. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
RE: Tomcat scalability
You would be better off to use a load balancer in front of a cluster of Tomcat servers. It gives you very good scalability, with good fault tolerance. -Original Message- From: ryan [mailto:rsburgess;shaw.ca] Sent: 03 November, 2002 12:39 AM To: [EMAIL PROTECTED] Subject: Tomcat scalability 1. For a project my company is working on we have transactions requirements of 1600 transactions per second. The transactions consists of processing a servlet in Tomcat, doing a database call and then displaying the results to the user so the effective number of transactions Tomcat has to process is actually greater than 1600. Can Tomcat cope with 1600 requests in a second(a 4 processor Sunfire machine will be used)? Based upon our current application architecture(our java application has tomcat running inside it), 1600 request per second means we may have 1600 threads open simultaneously. 2. From one article I read at linux journal, Tomcat 3 didn't scale very well with multiple processors because of JVM issues. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Tomcat scalability
That's a tough question to answer, and pretty much the only way you're going to be able to tell is to try it. Here's a few suggestions of things to think about: The first question you might want to ask is can your database handle 1600 transactions per second? If not (and even if it can) you may want to consider whether some kind of caching could help you if the data is largely static. This could be caching of the data itself, or something as simple as caching the pages themselves, with some scheme to flush the cache if the data changes. If your data is not very static, then this wouldn't be as helpful of course. If it's possible on the OS you are using, I'd be tempted to run 4 copies of Tomcat, and dedicate a processor to each one. It's a lot harder to write code that will run reliably on a MP machine than on a SP one, and it seems that Tomcat has a few issues in that regard. Also, remember, it's unlikely you'll ever have that many threads open at once - if you are actually handling 1600 requests/second then each request is, on average, taking less than a millisecond to complete, so you won't have too many overlapping requests. If you can work out how long it takes to process one request, then you'll have a best-case scenario of how many you can handle. In practice, it will be less of course, due to overhead in handling multiple requests at once. -- Rob ryan [EMAIL PROTECTED]To: [EMAIL PROTECTED] a cc: Subject: Tomcat scalability 03/11/2002 02:39 AM Please respond to Tomcat Developers List 1. For a project my company is working on we have transactions requirements of 1600 transactions per second. The transactions consists of processing a servlet in Tomcat, doing a database call and then displaying the results to the user so the effective number of transactions Tomcat has to process is actually greater than 1600. Can Tomcat cope with 1600 requests in a second(a 4 processor Sunfire machine will be used)? Based upon our current application architecture(our java application has tomcat running inside it), 1600 request per second means we may have 1600 threads open simultaneously. 2. From one article I read at linux journal, Tomcat 3 didn't scale very well with multiple processors because of JVM issues. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
RE: Catalina.sh on Tru64 Unix v 5.1 Problem
If you're running ksh, change the first line of$CATALINA_HOME/bin/startup.sh
and $CATALINA_HOME/bin/catalina.sh to reference /bin/ksh rather than
/bin/sh, and you should be all set.
-Original Message-
From: Yon Den Baguse Ngarso [mailto:yon;dugem.com]
Sent: Thursday, October 24, 2002 9:30 PM
To: [EMAIL PROTECTED]
Subject: Catalina.sh on Tru64 Unix v 5.1 Problem
Dear All,
I have extract jakarta-tomcat-4.1.12 on my Tru64 Unix v 5.1 (DEC Alpha).
The problem is catalina.sh couldn't work.
./catalina.sh start
Using CATALINA_BASE: /var/jakarta-tomcat-4.1.12
Using CATALINA_HOME: /var/jakarta-tomcat-4.1.12
Using CATALINA_TMPDIR: /var/jakarta-tomcat-4.1.12/temp
Using JAVA_HOME: /usr/opt/java140
catalina.out:
usage: java org.apache.catalina.startup.Catalina [ -config
{pathname} ] [ -debug ] [ -nonaming ] { start | stop }
But Tomcat can start if i run directly using the following command:
/usr/opt/java140/bin/java
-Djava.endorsed.dirs=/var/jakarta-tomcat-4.1.12/bin:/var/jakarta-t
omcat-4.1.12/common/endorsed -classpath
/usr/opt/java140/lib/tools.jar:/var/jakarta-tomcat-4.1.12/bin/boot
strap.jar -Dcatalina.base=/var/jakarta-tomcat-4.1.12
-Dcatalina.home=/var/jakarta-tomcat-4.1.12
-Djava.io.tmpdir=/var/jakarta-tomcat-4.1.12/temp
org.apache.catalina.startup.Bootstrap start
My Questions:
1. How to fix the catalina.sh?
This problem occur when i run on my DEC Tru64 Unix.
2. Is there any /etc/rc.d/init.d/tomcat4 (start|stop|restart) available
for Tru64 Unix?
TIA,
Yon
_
Get [EMAIL PROTECTED] at http://www.dugem.com
_
Select your own custom email address for FREE! Get
[EMAIL PROTECTED] w/No Ads, 6MB, POP more!
http://www.everyone.net/selectmail?campaign=tag
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
--
To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Tomcat scalability
One good rule of thumb is not to solve problems that don't exist. Your first task is to set up a server and hit it with something a good 20%-50% more demanding than your expected load. There exist several automated tools to do this. One is JMeter at http://jakarta.apache.org/jmeter/index.html . Then, have a look at your actual performance and work on the bottlenecks that arise. If your application is spending most of its time waiting for database results, cache them. If your application is spending most of its time creating and destroying objects, consider pooling. If your app is choking on serving up 1600 images a second, use a web server such as Apache in front of Tomcat. That will help with static requests (images, static HTML) even with a single Tomcat server doing the servlet work. -- Ryan Hoegg ISIS Networks http://www.isisnetworks.net [EMAIL PROTECTED] wrote: That's a tough question to answer, and pretty much the only way you're going to be able to tell is to try it. Here's a few suggestions of things to think about: The first question you might want to ask is can your database handle 1600 transactions per second? If not (and even if it can) you may want to consider whether some kind of caching could help you if the data is largely static. This could be caching of the data itself, or something as simple as caching the pages themselves, with some scheme to flush the cache if the data changes. If your data is not very static, then this wouldn't be as helpful of course. If it's possible on the OS you are using, I'd be tempted to run 4 copies of Tomcat, and dedicate a processor to each one. It's a lot harder to write code that will run reliably on a MP machine than on a SP one, and it seems that Tomcat has a few issues in that regard. Also, remember, it's unlikely you'll ever have that many threads open at once - if you are actually handling 1600 requests/second then each request is, on average, taking less than a millisecond to complete, so you won't have too many overlapping requests. If you can work out how long it takes to process one request, then you'll have a best-case scenario of how many you can handle. In practice, it will be less of course, due to overhead in handling multiple requests at once. -- Rob 1. For a project my company is working on we have transactions requirements of 1600 transactions per second. The transactions consists of processing a servlet in Tomcat, doing a database call and then displaying the results to the user so the effective number of transactions Tomcat has to process is actually greater than 1600. Can Tomcat cope with 1600 requests in a second(a 4 processor Sunfire machine will be used)? Based upon our current application architecture(our java application has tomcat running inside it), 1600 request per second means we may have 1600 threads open simultaneously. 2. From one article I read at linux journal, Tomcat 3 didn't scale very well with multiple processors because of JVM issues. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
Re: Tomcat scalability
Quoting Jon Scott Stevens [EMAIL PROTECTED]: on 2002/11/3 2:24 PM, Bojan Smojver [EMAIL PROTECTED] wrote: I know you have a much better machine, but 1600 transactions does seem a bit high. Not for porn. Nah... they wouldn't use Java for that. They'd use Porn Hypertext Processor (PHP) ;-) Bojan -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
WebDAV methods
I have come accross a problem trying to handle an OPTIONS HTTP method in my servlet. My servlet does not get invoked when Dav Explorer uses this method. I have included the only posting I've been able to find as a reference. It was posted in April of 2000 where Remy Maucherat makes mention that his servlet is not invoked when using the OPTIONS HTTP method. Is this still an issue? I seem to have the problem he refers to and I haven't been able to find a solution. Any help would be greatly appreciated! Rob Gauthier To: [EMAIL PROTECTED] Subject: Re: [Catalina] WebDAV methods From: Craig R. McClanahan [EMAIL PROTECTED] Date: Sat, 29 Apr 2000 16:22:32 -0700 Delivered-To: mailing list [EMAIL PROTECTED] list-help: mailto:tomcat-dev-help;jakarta.apache.org list-post: mailto:tomcat-dev;jakarta.apache.org list-unsubscribe: mailto:tomcat-dev-unsubscribe;jakarta.apache.org Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm References: [EMAIL PROTECTED] 00b001bfb22e$8d30ab40$[EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Remy Maucherat wrote: Your latest patch fixed the 304 error. Static stuff now works great !! Cool! Using the following mapping in the web.xml file, I'm able to load my DAV servlet on startup : servlet servlet-namewebdav/servlet-name servlet-classorg.exolab.slide.webdav.Webdav/servlet-class load-on-startup1/load-on-startup init-param param-namedebug/param-name param-value99/param-value /init-param /servlet !-- The mapping for the webdav servlet -- servlet-mapping servlet-namewebdav/servlet-name url-pattern/dav/*/url-pattern /servlet-mapping It works I mean : the servlet loads on startup, as expected. Note : I don't use the Catalina / Tomcat logging facility, but I will soon :-) I just fixed a bug in the getPathInfo() that your servlet would have received when actually invoked. It should work better now. However, in case Catalina gets a request using an OPTIONS HTTP method, my servlet is not invoked (although the Wrapper seems to be invoked), so DAV functionality though IE doesn't work yet. I'll look into that problem later today, if you don't mind. There is nothing in Catalina itself that should care about which HTTP method was used. There might be something inside javax.servlet.http.HttpServlet itself that is swallowing them. At the moment, I've left a log() call active inside StandardWrapperValve that will log the HTTP method and request URI it's using, just before calling the service() method of the servlet. That should help determine where the problem lies. You can see it working using a standard browser, though. It works with DAV Explorer, though. Go to http://24.12.46.10:8080/dav/ Remy Craig -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5 CoyoteRequestFacade.java CoyoteResponseFacade.java
jfarcand2002/11/03 21:14:09
Modified:coyote/src/java/org/apache/coyote/tomcat5
CoyoteRequestFacade.java CoyoteResponseFacade.java
Log:
Use the catalina.properties file to customize the package protection/access. This
new security m
echanism enable the customization, at runtime, of which package should be protected.
the following package will be protected by default:
o.a.catalina
o.a.jasper(*)
o.a.coyote
o.a.tomcat.util
(*) Tomcat 5 is broken when a JSP use a class from jsp20el.jar and when the
SecurityManager is t
urned on. Even if you remove all the protection, Tomcat fail to properly runs the
example.
o.a.coyote.tomcat5 has been securized in order to support package protection.
Revision ChangesPath
1.2 +194 -20
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteRequestFacade.java
Index: CoyoteRequestFacade.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteRequestFacade.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- CoyoteRequestFacade.java 4 Aug 2002 19:39:49 - 1.1
+++ CoyoteRequestFacade.java 4 Nov 2002 05:14:09 - 1.2
-64,10 +64,12
package org.apache.coyote.tomcat5;
-
import java.io.InputStream;
import java.io.BufferedReader;
import java.io.IOException;
+import java.security.AccessController;
+import java.security.PrivilegedAction;
+import java.security.PrivilegedActionException;
import java.util.Enumeration;
import java.util.Map;
import java.util.Locale;
-83,21 +85,134
import org.apache.catalina.connector.RequestFacade;
import org.apache.catalina.session.StandardSessionFacade;
-
/**
* Facade class that wraps a Coyote request object.
* All methods are delegated to the wrapped request.
*
* author Craig R. McClanahan
* author Remy Maucherat
+ * author Jean-Francois Arcand
* version $Revision$ $Date$
*/
+
public class CoyoteRequestFacade
extends RequestFacade
implements HttpServletRequest {
-
-
+
+
+// --- DoPrivileged
+
+private final class GetAttributePrivilegedAction implements PrivilegedAction{
+
+public Object run() {
+return request.getAttributeNames();
+}
+}
+
+
+private final class GetParameterMapPrivilegedAction implements PrivilegedAction{
+
+public Object run() {
+return request.getParameterMap();
+}
+}
+
+
+private final class GetRequestDispatcherPrivilegedAction implements
PrivilegedAction{
+private String path;
+public GetRequestDispatcherPrivilegedAction(String path){
+this.path = path;
+}
+
+public Object run() {
+return request.getRequestDispatcher(path);
+ }
+}
+
+
+private final class GetParameterPrivilegedAction implements PrivilegedAction{
+public String name;
+public GetParameterPrivilegedAction(String name){
+this.name = name;
+}
+public Object run() {
+return request.getParameter(name);
+}
+}
+
+
+private final class GetParameterNamesPrivilegedAction implements
PrivilegedAction{
+
+public Object run() {
+return request.getParameterNames();
+}
+}
+
+
+private final class GetParameterValuePrivilegedAction implements
PrivilegedAction{
+public String name;
+public GetParameterValuePrivilegedAction(String name){
+this.name = name;
+}
+public Object run() {
+return request.getParameterValues(name);
+}
+}
+
+
+private final class GetCookiesPrivilegedAction implements PrivilegedAction{
+
+ public Object run() {
+return request.getCookies();
+}
+}
+
+
+private final class GetCharacterEncodingPrivilegedAction implements
PrivilegedAction{
+
+public Object run() {
+return request.getCharacterEncoding();
+}
+}
+
+
+private final class GetHeadersPrivilegedAction implements PrivilegedAction{
+private String name;
+public GetHeadersPrivilegedAction(String name){
+this.name = name;
+}
+
+public Object run() {
+
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security SecurityConfig.java SecurityClassLoad.java
jfarcand2002/11/03 21:16:23
Modified:catalina/src/share/org/apache/catalina/security
SecurityConfig.java SecurityClassLoad.java
Log:
Use the catalina.properties file to customize the package protection/access. This
new security m
echanism enable the customization, at runtime, of which package should be protected.
the following package will be protected by default:
o.a.catalina
o.a.jasper(*)
o.a.coyote
o.a.tomcat.util
(*) Tomcat 5 is broken when a JSP use a class from jsp20el.jar and when the
SecurityManager is t
urned on. Even if you remove all the protection, Tomcat fail to properly runs the
example.
o.a.coyote.tomcat5 has been securized in order to support package protection.
Revision ChangesPath
1.4 +48 -14
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security/SecurityConfig.java
Index: SecurityConfig.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/security/SecurityConfig.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- SecurityConfig.java 24 Oct 2002 02:43:20 - 1.3
+++ SecurityConfig.java 4 Nov 2002 05:16:23 - 1.4
-59,6 +59,7
package org.apache.catalina.security;
import java.security.Security;
+import org.apache.catalina.startup.CatalinaProperties;
/**
* Util class to protect Catalina against package access and insertion.
-68,27 +69,51
*/
public final class SecurityConfig{
private static SecurityConfig singleton = null;
+
+private static org.apache.commons.logging.Log log=
+org.apache.commons.logging.LogFactory.getLog( SecurityConfig.class );
+
-private final static String PACKAGE_ACCESS = org.apache.catalina.
-+ ,org.apache.jasper.
+private final static String PACKAGE_ACCESS = sun.,
++ org.apache.catalina.
+ ,org.apache.jsp.
-+ ,org.apache.jk.;
++ ,org.apache.coyote.
++ ,org.apache.tomcat.;
-private final static String PACKAGE_DEFINITION= java.
+private final static String PACKAGE_DEFINITION= java.,sun.
+ ,org.apache.catalina.
-+ ,org.apache.jasper.
+ ,org.apache.coyote.
-+ ,org.apache.jsp.
-+ ,org.apache.jk.;
++ ,org.apache.tomcat.
++ ,org.apache.jsp.;
+/**
+ * List of protected package from conf/catalina.properties
+ */
+private String packageDefinition;
+
+
+/**
+ * List of protected package from conf/catalina.properties
+ */
+private String packageAccess;
+
+
/**
* Create a single instance of this class.
*/
-private SecurityConfig(){
+private SecurityConfig(){
+try{
+packageDefinition =
CatalinaProperties.getProperty(package.definition);
+packageAccess = CatalinaProperties.getProperty(package.access);
+} catch (java.lang.Exception ex){
+if (log.isDebugEnabled()){
+log.debug(Unable to load properties using CatalinaProperties,
ex);
+}
+}
}
/**
- * Retuens the singleton instance of that class.
+ * Returns the singleton instance of that class.
* return an instance of that class.
*/
public static SecurityConfig newInstance(){
-103,7 +128,12
* Set the security package.access value.
*/
public void setPackageAccess(){
-setSecurityProperty(package.access, PACKAGE_ACCESS);
+// If catalina.properties is missing, protect all by default.
+if (packageAccess == null){
+setSecurityProperty(package.access, PACKAGE_ACCESS);
+} else {
+setSecurityProperty(package.access, packageAccess);
+}
}
-111,7 +141,12
* Set the security package.definition value.
*/
public void setPackageDefinition(){
-setSecurityProperty(package.definition, PACKAGE_DEFINITION);
+// If catalina.properties is missing, protect all by default.
+ if (packageDefinition == null){
+
cvs commit: jakarta-tomcat-catalina/catalina/src/conf catalina.properties
jfarcand2002/11/03 21:33:50 Modified:catalina/src/conf catalina.properties Log: Use the catalina.properties file to customize the package protection/access. This new security m echanism enable the customization, at runtime, of which package should be protected. the following package will be protected by default: o.a.catalina o.a.jasper(*) o.a.coyote o.a.tomcat.util (*) Tomcat 5 is broken when a JSP use a class from jsp20el.jar and when the SecurityManager is t urned on. Even if you remove all the protection, Tomcat fail to properly runs the example. o.a.coyote.tomcat5 has been securized in order to support package protection. Revision ChangesPath 1.4 +3 -2 jakarta-tomcat-catalina/catalina/src/conf/catalina.properties Index: catalina.properties === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/conf/catalina.properties,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- catalina.properties 4 Nov 2002 05:12:56 - 1.3 +++ catalina.properties 4 Nov 2002 05:33:50 - 1.4 -4,7 +4,7 # passed to checkPackageAccess unless the # corresponding RuntimePermission (accessClassInPackage.+package) has # been granted. -package.access=sun.,org.apache.catalina.,org.apache.jasper.,org.apache.coyote.,org.apache.tomcat.,org.apache.jsp. +package.access=sun.,org.apache.catalina.,org.apache.coyote.,org.apache.tomcat.,org.apache.jasper.compiler.,org.apache.jasper.core.,org.apache.jasper.logging.,org.apache.jasper.resources.,org.apache.jasper.servlet.,org.apache.jasper.util.,org.apache.jasper.xmlparser # # List of comma-separated packages that start with or equal this string -16,8 +16,9 # by default, no packages are restricted for definition, and none of # the class loaders supplied with the JDK call checkPackageDefinition. # -package.definition=sun.,java.,org.apache.catalina.,org.apache.jasper.,org.apache.coyote.,org.apache.tomcat.,org.apache.jsp +package.definition=sun.,java.,org.apache.catalina.,org.apache.coyote.,org.apache.tomcat.,org.apache.jasper.compiler.,org.apache.jasper.core.,org.apache.jasper.logging.,org.apache.jasper.resources.,org.apache.jasper.servlet.,org.apache.jasper.util.,org.apache.jasper.xmlparser +# # # List of comma-separated paths defining the contents of the common # classloader. Prefixes should be used to define what is the repository type. -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves ErrorDispatcherValve.java
amyroh 2002/11/03 22:33:02 Modified:catalina/src/share/org/apache/catalina/valves ErrorDispatcherValve.java Log: Fix support for changes made between the public draft and public final draft for Filter support in Servlet 2.4. Errors that were generated by a throwable in the ErrorDispatcherValue had filters applied properly but those coming from a setStatus (called from within a servlet) are not having filters applied as specfied in the Servlet specification (See SRV.6.2.5 for details). This fixes compliance with the specification. Submitted by Greg Murray [EMAIL PROTECTED] Revision ChangesPath 1.4 +9 -4 jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/ErrorDispatcherValve.java Index: ErrorDispatcherValve.java === RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/valves/ErrorDispatcherValve.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- ErrorDispatcherValve.java 12 Sep 2002 00:09:28 - 1.3 +++ ErrorDispatcherValve.java 4 Nov 2002 06:33:02 - 1.4 @@ -299,6 +299,10 @@ new Integer(statusCode)); sreq.setAttribute(Globals.ERROR_MESSAGE_ATTR, message); +sreq.setAttribute(ApplicationFilterFactory.DISPATCHER_REQUEST_PATH_ATTR, + errorPage.getLocation()); +sreq.setAttribute(ApplicationFilterFactory.DISPATCHER_TYPE_ATTR, + new Integer(ApplicationFilterFactory.ERROR)); Wrapper wrapper = request.getWrapper(); if (wrapper != null) sreq.setAttribute(Globals.SERVLET_NAME_ATTR, @@ -447,3 +451,4 @@ } + -- To unsubscribe, e-mail: mailto:tomcat-dev-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-dev-help;jakarta.apache.org
