Re: My patches for Tomcat 3.2 wrt mutlibyte characters
From: Pilho Kim [EMAIL PROTECTED]
Subject: My patches for Tomcat 3.2 wrt mutlibyte characters
Date: Tue, 5 Dec 2000 09:47:38 +0900 (KST)
Message-ID: [EMAIL PROTECTED]
Try to visit
http://www.javaclue.org/tomcat/patch32/dopatch.html
I hope that those would be adopted in TC 3.2.1.
We are developing similar patches for japanese users. Your patches
have a few problems:
1, Don't change a DEFAULT_CHAR_ENCODING constant in
src/share/org/apache/tomcat/core/Constants.java
Web i18n basics is to specify "right" charset. If you specify charset
explicitly in tomcat 3.2, your Web applications work well except for a
few well-known problems (JSP's include charset getParameter() etc. -
they are resolved in Servlet API 2.3 JSP 1.2).
And "iso-8859-1" is defined as default charset in Servlet API 2.3
final draft (See 4.9, 5.4, javax.servlet.ServletResponse). It isn't
desirable to introduce another i18n concept to Servlet API 2.2.
Of cource, some internal modules such as DefaultCMSetter must send a
reply in platform native charset because of native library's localized
messages etc. In this case, it is better to specify charset
internally.
2, Don't change Jasper's default encoding to a platform native
character encoding.
This spoils platform independency of JSP files. For example, it is
very popular to serve JSP files encoded in Shift_JIS (this is used on
Windows-PC) on an unix-variant server which default charset is EUC-JP.
And JSP files specified charset work well except for "include"
directive.
JSP 1.2 provide "pageEncoding" attribute for this problem. But there
are no walkaround in JSP 1.1. This is a serious problem. I think
charset-inheritance mechanism is better if possible.
We have a plan to provide pageEncoding patch (JSP 1.2 feature
implementation to JSP 1.1)for this problem and this patch will be used
in user's own risk. But it isn't good to provide it officially.
3, Don't use non-IANA charset.
Java's default encoding name is almost converter's name but isn't
included in IANA registry.
But there is no best way to convert Java's encoding to IANA charset in
current JDK Tomcat.
I think that it is reasonable to use
org.apache.tomcat.util.LocaleToCharsetMap (see ResponseImpl.java).
I send new patch of org.apache.tomcat.context.DefaultCMSetter. This
patch sets charset to iso-8859-1 in the case that LocaleToCharsetMap
returns null (specified locale isn't registered), but there may be a
better code.
Kazuhiro Kazama ([EMAIL PROTECTED]) NTT Network Innovation Laboratories
--- DefaultCMSetter.java.orig Tue Dec 5 11:49:48 2000
+++ DefaultCMSetter.javaTue Dec 5 18:04:24 2000
@@ -141,17 +141,24 @@
class NotFoundHandler extends ServletWrapper {
static StringManager sm=StringManager.
getManager("org.apache.tomcat.resources");
+String charset;
NotFoundHandler() {
initialized=true;
internal=true;
name="tomcat.notFoundHandler";
+ charset = LocaleToCharsetMap.getCharset(Locale.getDefault());
+ if (charset == null)
+ charset = "ISO-8859-1";
}
public void doService(Request req, Response res)
throws Exception
{
- res.setContentType("text/html");// ISO-8859-1 default
+ if (charset.equalsIgnoreCase("ISO-8859-1"))
+ res.setContentType("text/html");
+ else
+ res.setContentType("text/html; charset=" + charset);
String requestURI = (String)req.
getAttribute("javax.servlet.include.request_uri");
@@ -186,30 +193,28 @@
buf.append("/body\r\n");
- String body = buf.toString();
+ byte[] body = new String(buf).getBytes(charset);
- res.setContentLength(body.length());
+ res.setContentLength(body.length);
- if( res.isUsingStream() ) {
- ServletOutputStream out = res.getOutputStream();
- out.print(body);
- out.flush();
- } else {
- PrintWriter out = res.getWriter();
- out.print(body);
- out.flush();
- }
+ ServletOutputStream out = res.getOutputStream();
+ out.write(body);
+ out.flush();
}
}
class ExceptionHandler extends ServletWrapper {
static StringManager sm=StringManager.
getManager("org.apache.tomcat.resources");
+String charset;
ExceptionHandler() {
initialized=true;
internal=true;
name="tomcat.exceptionHandler";
+ charset = LocaleToCharsetMap.getCharset(Locale.getDefault());
+ if (charset == null)
+ charset = "ISO-8859-1";
}
public void doService(Request req, Response res)
@@ -226,7 +231,10 @@
return;
}
- res.setContentType("text/html");
+ if (charset.equalsIgnoreCase("ISO-8859-1"))
+ res.setContentType("text/html");
+ else
+ res.setContentType("text/html; charset=" + charset);
res.setStatus( 500 );
StringBuffer buf = new
BugRat Report #523 has been filed.
Bug report #523 has just been filed.
You can view the report at the following URL:
http://znutar.cortexity.com/BugRatViewer/ShowReport/523
REPORT #523 Details.
Project: Jasper
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: medium
Severity: serious
Confidence: public
Environment:
Release: tomcat3.2
JVM Release: jdk1.2.2
Operating System: winnt
OS Release: 4
Platform: intel
Synopsis:
Platform Portability Issue
Description:
I have tracked down the cause to bug 418 (sorry I haven't updated bug 418 with this
explaination/fix but the bug system wouldn't let me update the bug).
org.apache.jasper.CommandLineContext has the following function.
/**
* Gets the actual path of a URI relative to the context of
* the compilation.
*/
public String getRealPath(String path) {
path = resolveRelativeUri(path);
if (path.startsWith("/")) {
path = path.substring(1);
}
File f = new File(uriRoot, path.replace('/', File.separatorChar));
return f.getAbsolutePath();
}
As you can see, path.startsWith("/") assumes unix style slashes. I have found that in
some situations this assumption is wrong (see bug 418 for an explaination of when this
occurs).
So a quick hacky fix that I have found works is to replace this function with
/**
* Gets the actual path of a URI relative to the context of
* the compilation.
*/
public String getRealPath(String path) {
path = resolveRelativeUri(path);
if (path.startsWith("/") || path.startsWith("\\")) {
path = path.substring(1);
}
File f = new File(uriRoot, path.replace('/', File.separatorChar));
return f.getAbsolutePath();
}
- Chris.
Title:
BugRat Report #
523
BugRat Report #
523
Project:
Jasper
Release:
tomcat3.2
Category:
Bug Report
SubCategory:
New Bug Report
Class:
swbug
State:
received
Priority:
medium
Severity:
serious
Confidence:
public
Submitter:
Christopher Kirk ([EMAIL PROTECTED])
Date Submitted:
Dec 5 2000, 03:31:02 CST
Responsible:
Z_Tomcat Alias ([EMAIL PROTECTED])
Synopsis:
Platform Portability Issue
Environment: (jvm, os, osrel, platform)
jdk1.2.2, winnt, 4, intel
Additional Environment Description:
Report Description:
I have tracked down the cause to bug 418 (sorry I haven't updated bug 418 with this explaination/fix but the bug system wouldn't let me update the bug).
org.apache.jasper.CommandLineContext has the following function.
/**
* Gets the actual path of a URI relative to the context of
* the compilation.
*/
public String getRealPath(String path) {
path = resolveRelativeUri(path);
if (path.startsWith("/")) {
path = path.substring(1);
}
File f = new File(uriRoot, path.replace('/', File.separatorChar));
return f.getAbsolutePath();
}
As you can see, path.startsWith("/") assumes unix style slashes. I have found that in some situations this assumption is wrong (see bug 418 for an explaination of when this occurs).
So a quick hacky fix that I have found works is to replace this function with
/**
* Gets the actual path of a URI relative to the context of
* the compilation.
*/
public String getRealPath(String path) {
path = resolveRelativeUri(path);
if (path.startsWith("/") || path.startsWith("\\")) {
path = path.substring(1);
}
File f = new File(uriRoot, path.replace('/', File.separatorChar));
return f.getAbsolutePath();
}
- Chris.
View this report online...
Re: tomcat for Debian [RPM for jakarta/xml apaches projects]
*Wipes brow* ok, I'll gracefully run away from this one then ;-) -Thom Amy: deb packages for JDK1.3 (blackdown jdk) at deb http://www.mirror.ac.uk/sites/ftp.blackdown.org/java-linux/debian/ woody non-free HTH On Tue, Dec 05, 2000 at 02:28:32 +0900, Takashi Okamoto said: I didn't know much about debian packaging but there is a tool, alien, which convert from RPM to dpkg. Alien isn't complete. Because policies are different between Redhat and Debian. Stefan is prepareing tomcat package for Debian. Check here. http://master.debian.org/~sgybas/tomcat/ -- Takashi Okamoto
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler DelegatingListener.java JspParseEventListener.java ParseEventListener.java ParserXJspSax.java ParserXJspSaxHandler.java
pierred 00/12/05 03:05:30
Modified:jasper/src/share/org/apache/jasper/compiler
DelegatingListener.java JspParseEventListener.java
ParseEventListener.java ParserXJspSax.java
ParserXJspSaxHandler.java
Log:
Changes from JSP1.2 PD1 to JSP1.2 PFD that were not explicitely flagged
in the PFD changes section:
- Template text not accepted anymore if it is not encapsultated within
the jsp:cdata element
- Tag Libraries used by a JSP document in XML syntax are defined via
the jsp:root xmlns attributes (no jsp:directive.taglib anymore)
Revision ChangesPath
1.6 +12 -8
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/DelegatingListener.java
Index: DelegatingListener.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/DelegatingListener.java,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- DelegatingListener.java 2000/11/30 21:47:48 1.5
+++ DelegatingListener.java 2000/12/05 11:05:19 1.6
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/DelegatingListener.java,v
1.5 2000/11/30 21:47:48 pierred Exp $
- * $Revision: 1.5 $
- * $Date: 2000/11/30 21:47:48 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/DelegatingListener.java,v
1.6 2000/12/05 11:05:19 pierred Exp $
+ * $Revision: 1.6 $
+ * $Date: 2000/12/05 11:05:19 $
*
*
*
@@ -227,13 +227,17 @@
return delegate.getTagLibraries();
}
-public void handleRootBegin(Attributes attrs) {}
+public void handleRootBegin(Attributes attrs) throws JasperException {}
public void handleRootEnd() {}
-public void handleUninterpretedTagBegin(Mark start,Mark stop,String
rawName,Attributes attrs) throws JasperException {}
-
+public void handleUninterpretedTagBegin(Mark start, Mark stop,
+String rawName,Attributes attrs)
+throws JasperException {}
public void handleUninterpretedTagEnd(Mark start, Mark stop,
- String rawName)
- throws JasperException {}
+ String rawName, char[] data)
+throws JasperException {}
+
+public void handleJspCdata(Mark start, Mark stop, char[] data)
+throws JasperException {}
}
1.14 +40 -20
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java
Index: JspParseEventListener.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- JspParseEventListener.java2000/11/30 21:47:54 1.13
+++ JspParseEventListener.java2000/12/05 11:05:19 1.14
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
1.13 2000/11/30 21:47:54 pierred Exp $
- * $Revision: 1.13 $
- * $Date: 2000/11/30 21:47:54 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
1.14 2000/12/05 11:05:19 pierred Exp $
+ * $Revision: 1.14 $
+ * $Date: 2000/12/05 11:05:19 $
*
*
*
@@ -742,21 +742,6 @@
throw new CompileException(start, Constants.getString(
"jsp.error.page.bad_b_and_a_combo"));
- if (directive.equals("taglib")) {
-String uri = attrs.getValue("uri");
-String prefix = attrs.getValue("prefix");
- TagLibraryInfo tl = null;
-
- String[] location =
- ctxt.getTldLocation(uri);
- if (location == null) {
- tl = new TagLibraryInfoImpl(ctxt, prefix, uri);
- } else {
- tl = new TagLibraryInfoImpl(ctxt, prefix, uri, location);
- }
- libraries.addTagLibrary(prefix, tl);
- }
-
if (directive.equals("include")) {
String file = attrs.getValue("file");
String encoding = attrs.getValue("encoding");
@@ -1046,7 +1031,33 @@
xo.append("jsp:root");
}
-public void handleRootBegin(Attributes attrs) {
+public void handleRootBegin(Attributes attrs)
+ throws JasperException
+{
+int attrsLength = attrs.getLength();
+for (int i = 0; i attrsLength; i++) {
+
cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler JspParseEventListener.java
pierred 00/12/05 04:23:53
Modified:jasper/src/share/org/apache/jasper/compiler
JspParseEventListener.java
Log:
Ooops... last fix broke tag libraries handling (was only processed
for XML syntax). Things now back to normal.
Revision ChangesPath
1.15 +32 -14
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java
Index: JspParseEventListener.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
retrieving revision 1.14
retrieving revision 1.15
diff -u -r1.14 -r1.15
--- JspParseEventListener.java2000/12/05 11:05:19 1.14
+++ JspParseEventListener.java2000/12/05 12:23:46 1.15
@@ -1,7 +1,7 @@
/*
- * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
1.14 2000/12/05 11:05:19 pierred Exp $
- * $Revision: 1.14 $
- * $Date: 2000/12/05 11:05:19 $
+ * $Header:
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
1.15 2000/12/05 12:23:46 pierred Exp $
+ * $Revision: 1.15 $
+ * $Date: 2000/12/05 12:23:46 $
*
*
*
@@ -742,6 +742,12 @@
throw new CompileException(start, Constants.getString(
"jsp.error.page.bad_b_and_a_combo"));
+ if (directive.equals("taglib")) {
+ String uri = attrs.getValue("uri");
+ String prefix = attrs.getValue("prefix");
+processTaglibDirective(uri, prefix);
+}
+
if (directive.equals("include")) {
String file = attrs.getValue("file");
String encoding = attrs.getValue("encoding");
@@ -1041,20 +1047,12 @@
String prefix = qName.substring(6);
if (!prefix.equals("jsp")) {
String uri = attrs.getValue(i);
- System.out.println("prefix: " + prefix);
- System.out.println("uri: " + uri);
+ //System.out.println("prefix: " + prefix);
+ //System.out.println("uri: " + uri);
if (uri.startsWith("urn:jsptld:")) {
uri = uri.substring(11);
- }
- TagLibraryInfo tl = null;
- String[] location =
- ctxt.getTldLocation(uri);
- if (location == null) {
- tl = new TagLibraryInfoImpl(ctxt, prefix, uri);
- } else {
- tl = new TagLibraryInfoImpl(ctxt, prefix, uri, location);
}
- libraries.addTagLibrary(prefix, tl);
+ processTaglibDirective(uri, prefix);
}
}
}
@@ -1109,5 +1107,25 @@
new Object[]{tli.getShortName(), msg}));
}
}
+}
+
+/**
+ * Process a taglib directive. This can happen either via the
+ * JSP taglib directive (in JSP syntax) or via xmlns in jsp:root
+ * (in XML syntax).
+ */
+private void processTaglibDirective(String uri, String prefix)
+ throws JasperException
+{
+ TagLibraryInfo tl = null;
+
+ String[] location =
+ ctxt.getTldLocation(uri);
+ if (location == null) {
+ tl = new TagLibraryInfoImpl(ctxt, prefix, uri);
+ } else {
+ tl = new TagLibraryInfoImpl(ctxt, prefix, uri, location);
+ }
+ libraries.addTagLibrary(prefix, tl);
}
}
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core ContextManager.java
larryi 00/12/05 05:20:47
Modified:src/share/org/apache/tomcat/core ContextManager.java
Log:
Port showDebugInfo property from Tomcat 3.2.
Make handlerError() public.
Revision ChangesPath
1.156 +21 -2
jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java
Index: ContextManager.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java,v
retrieving revision 1.155
retrieving revision 1.156
diff -u -r1.155 -r1.156
--- ContextManager.java 2000/12/05 06:24:45 1.155
+++ ContextManager.java 2000/12/05 13:20:46 1.156
@@ -248,6 +248,11 @@
*/
private String installDir;
+/** The flag which controls the display of
+ * debugging information in default responses
+ */
+boolean showDebugInfo = true;
+
// Server properties ( interceptors, etc ) - it's one level above "/"
private Container defaultContainer;
@@ -336,7 +341,21 @@
public final int getState() {
return state;
}
+
+/** The showDebugInfo property state. To be used for controlling the
+ * display of debugging information in default responses.
+ **/
+public final boolean isShowDebugInfo() {
+ return showDebugInfo;
+}
+/** Sets the showDebugInfo property used for controlling the display of
+ * debugging information in default responses.
+ */
+public void setShowDebugInfo(boolean showDebugInfo) {
+ this.showDebugInfo = showDebugInfo;
+}
+
/**
* Parent loader is the "base" class loader of the
* application that starts tomcat, and includes no
@@ -875,7 +894,7 @@
// Error handling
-
+
/** Called for error-codes. Will call the error hook.
*/
public final void handleStatus( Request req, Response res, int code ) {
@@ -895,7 +914,7 @@
/**
* Call error hook
*/
-void handleError( Request req, Response res , Throwable t ) {
+public final void handleError( Request req, Response res , Throwable t ) {
BaseInterceptor ri[];
int status;
ri=req.getContainer().getInterceptors( Container.H_handleError );
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/core Handler.java Request.java Response.java
larryi 00/12/05 06:02:41
Modified:src/facade22/org/apache/tomcat/facade
RequestDispatcherImpl.java ServletWrapper.java
src/facade22/org/apache/tomcat/modules/facade22
JspInterceptor.java
src/share/org/apache/tomcat/context ErrorHandler.java
src/share/org/apache/tomcat/core Handler.java Request.java
Response.java
Log:
Port exception propagation behavior from Tomcat 3.2. Exceptions that occur
in included servlets are throw back to their callers. The exception is handled
only if it occurs or when it reaches the top level handler.
The implementation differs from that of Tomcat 3.2. Where Tomcat 3.2
catches and rethrows the exception at each level, this implementation tries
to catch and save the exception. I think this makes the flow of execution
easier to control. We can give interceptors a chance to examine the
exceptions. Now, only RequestDispatcherImpl rethrows the exceptions.
There are several places that exceptions are saved. Init exceptions and
UnavailableExceptions thrown in the service() method are saved in Handler
along with a "permanent" indication. postServletInit interceptors can find it
here. Also, postServletInit is called even if the init() method throws an
exception.
The first exception that occurs during request processing is saved on the
Response along with the "include" URI, if present. This exception will not
be overwritten if subsequent exceptions occur.
Exceptions during request processing are also saved on the Request. But
unlike the Response exception, the Request exception is overwritten with
each new exception that occurs.
In RequestDispatcherImpl, setting of the "included" flag was restored in
includeNamed() and forwardNamed() since it is used to control error handling
behavior.
JspInterceptor has been updated to set an initial exception if translation or
compilation fails. This way these error won't always show up as a 404 error.
Also, setting the compileTime from the java file was removed. After a restart,
this prevented the error from being recreated. Thus, a new java file will be
created after each restart for a non-compiling JSP, but this is better than
creating one on each request.
Watchdog still passes, but these changes need more review and testing.
Handling of destroy() wasn't addressed in these changes. This needs
review in the context of these changes.
Revision ChangesPath
1.5 +87 -12
jakarta-tomcat/src/facade22/org/apache/tomcat/facade/RequestDispatcherImpl.java
Index: RequestDispatcherImpl.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/facade22/org/apache/tomcat/facade/RequestDispatcherImpl.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- RequestDispatcherImpl.java2000/11/02 21:51:37 1.4
+++ RequestDispatcherImpl.java2000/12/05 14:02:37 1.5
@@ -188,11 +188,26 @@
// CM should have set the wrapper - call it
Handler wr=realRequest.getHandler();
- if( wr!=null ) wr.service(realRequest, realResponse);
+ if( wr!=null )
+ wr.service(realRequest, realResponse);
+ // Clean up the request and response as needed
+ ; // No action required
+
+ // Rethrow original error if present
+ if ( realResponse.isExceptionPresent() ) {
+ Exception ex = realResponse.getErrorException();
+ if ( ex instanceof IOException )
+ throw (IOException) ex;
+ else if ( ex instanceof ServletException )
+ throw (ServletException) ex;
+ else
+ throw new ServletException
+ (sm.getString("dispatcher.forwardException", ex));
+ }
+
// close the response - output after this point will be discarded.
realResponse.finish();
-
}
public void include(ServletRequest request, ServletResponse response)
@@ -313,7 +328,8 @@
// for the realRequest ( since the real request will still have the
// original handler/wrapper )
Handler wr=subRequest.getHandler();
- if( wr!=null ) wr.service(realRequest, realResponse);
+ if( wr!=null )
+ wr.service(realRequest, realResponse);
// After request, we want to restore the include attributes - for
// chained includes.
@@ -335,6 +351,18 @@
if( ! old_included ) {
realResponse.setIncluded( false );
}
+
+ // Rethrow original error if present
+ if ( realResponse.isExceptionPresent() ) {
+ Exception ex = realResponse.getErrorException();
+ if ( ex instanceof IOException )
+ throw (IOException) ex;
+ else if ( ex instanceof ServletException
BugRat Report #526 has been filed.
Bug report #526 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/526 REPORT #526 Details. Project: Tomcat Category: Feature Requests SubCategory: New Feature Class: swbug State: received Priority: medium Severity: serious Confidence: public Environment: Release: 3.2 JVM Release: 1.3 Operating System: WinNT OS Release: 4.0 Platform: x86 Synopsis: HttpServletRequest.getPathTranslated returns null Description: This can be seen from examples/snoop. The output for request: Request URI: /examples/snoop Context Path: /examples Servlet Path: /snoop Path Info: null Path Trans: null Query String: null The value for "Path Trans:" should be something like d:\tomcat\webapps\examples (as seen in release 3.1) Title: BugRat Report # 526 BugRat Report # 526 Project: Tomcat Release: 3.2 Category: Feature Requests SubCategory: New Feature Class: swbug State: received Priority: medium Severity: serious Confidence: public Submitter: Shawfe Sung ([EMAIL PROTECTED]) Date Submitted: Dec 5 2000, 11:08:58 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: HttpServletRequest.getPathTranslated returns null Environment: (jvm, os, osrel, platform) 1.3, WinNT, 4.0, x86 Additional Environment Description: Report Description: This can be seen from examples/snoop. The output for request: Request URI: /examples/snoop Context Path: /examples Servlet Path: /snoop Path Info: null Path Trans: null Query String: null The value for "Path Trans:" should be something like d:\tomcat\webapps\examples (as seen in release 3.1) View this report online...
Modifying the Ajp13 Protocol
As I'm working through the ajp13 code (C and Java), I'm discovering that there is some basic work which needs to be done on the protocol itself (as well as a lot of work on the implementations). Specifically: - If the request contains 8K of header/attribute information, the protocol fails. - There is no authentication step. I believe that this could result in some serious security violations if the web server is performing HTTP authentication (since remote_user is one of the attributes passed over). [side note: if anyone thinks otherwise, let me know] Since connections are maintained across many requests, there is no good reason not to do the authentication (IMHO). To fix these major issues will require modifying the protocol. I have some ideas on how to do so, but I want to get some feedback on the best way to go about making these changes. I could just modify the protocol itself, and change the mod_jk code and Ajp13 code in the tomcat-3.3 branch. My fear is that I'll be changing a protocol which is in production use, without changing its version number. This seems like asking for trouble. Should I therefore leave ajp13 where it is and work on ajp14? Or is that multiplying protocols needlessly? I realize that the new mod_webapp is being worked on, but it seems to me that getting mod_jk / ajp13 working right is probably still worth it -- there are plenty of people who are going to depend on that before Tomcat 4.0 is released. If I do change the protocol, it will require people who download the new version to update their mod_jk.so at the same time as they rebuild the Java classes. What do people think? -Dan -- Dan Milstein // [EMAIL PROTECTED]
Unicode decoding (seems to be a bug)
Hy,
I find a trouble using Tomcat (on win95 with Apache) with unicode chars in
url. Tomcat send me the error:
"Decode error" from unUrlDecode(String) function in the package
org.apache.tomcat.util;
Watching this function, I see that the algorithme only handle chars in %xx
format, but for some unicode chars the value can be in %x%xx format or in
%x%x (for example the char: 014b send by the web client is %1%4b, the char
0303 is %3%3, etc.)
So as I need this function to work well, I change it myself, and I give you
my new version.
Michel Jacobson CNRS.LACITO
[EMAIL PROTECTED]
--
public static String unUrlDecode(String data) {
StringBuffer buf = new StringBuffer();
for (int i = 0; i data.length(); i++) {
char c = data.charAt(i);
switch (c) {
case '+':
buf.append(' ');
break;
case '%':
try {
if(data.charAt(i+2) == '%') {
String hexachars ="0123456789abcdefABCDEF";
if(hexachars.indexOf(data.charAt(i+4)) == -1) {
buf.append((char)
Integer.parseInt(data.substring(i+1,i+2).concat("0").concat(data.substring(i
+3,i+4)), 16));
i += 3;
} else {
buf.append((char)
Integer.parseInt(data.substring(i+1,i+2).concat(data.substring(i+3,i+5)),
16));
i += 4;
}
} else {
buf.append((char) Integer.parseInt(data.substring(i+1,
i+3), 16));
i += 2;
}
} catch (NumberFormatException e) {
String msg = "Decode error ";
throw new IllegalArgumentException(msg);
} catch (StringIndexOutOfBoundsException e) {
String rest = data.substring(i);
buf.append(rest);
if (rest.length()==2)
i++;
}
break;
default:
buf.append(c);
break;
}
}
return buf.toString();
}
bug # 527
There is a bug in the bug reporting system. WorkAround and how to reproduce did not appear with my submission. Here is the description: * how to reproduce Install tomcat on windows98 and try to run using startup.bat file. Workaround WORK AROUND # 1 Include the following line in startup.bat as the first executable line. set TOMCAT_HOME=C:\Tomcat32, where C:\Tomcat32 is the directory in which Tomcat is installed. Include the following line in tomcat.bat as the first executable line. set JAVA_HOME=C:\jdk1.3 (C:\jdk1.3 is path to jdk installation) set TOMCAT_HOME=C:\Tomcat32 (c:\Tomcat32 is path to tomcat installation) set CLASSPATH=%TOMCAT_HOME%\lib;%TOMCAT_HOME%\classes set CP=%TOMCAT_HOME% Please make sure that in following releases of Tomcat, startup.bat and tomcat.bat are created with above modifications. WORK AROUND # 2 To cover 'Out of Environment Space' error do the following: Open a MS-DOS window Click on top left corner of window Select properties option click on memory tab Adjust the initial Environment drop-down box from Auto to 2816 Click OK Close the window Start the server again. please include this instructions in future releases as it consumed one whole day of mine trying to set up and run tomcat on windows 98. Thanks Aman _ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com
Re: BugRat Report #527 has been filed.
From: [EMAIL PROTECTED] Bug report #527 has just been filed. Synopsis: Trouble starting Tomcat Description: 1. On windows 98, classpath, Java_home etc. can't be saved and they should be set each time. 2. MS-DOS window reports 'Out of Environment Space' error message and does not load. This is not a bug, but a problem with your enviroment. Try this: Put the following sentence in your config.sys shell=c:\command.com /p /e:8192 And reboot your machine The /e switch is for setting the environment space. 8192 should be enough. Casper Gjerris
RE: Benchmarks: Catalina M5 vs. Apache 1.3.12
Hello, OpenSta seems to be a good harness test with multiple client. You can find it at http://sourceforge.net/projects/opensta/ Eric -Original Message- From: Curtis Dougherty [mailto:[EMAIL PROTECTED]] Sent: mardi 5 décembre 2000 20:32 To: '[EMAIL PROTECTED]' Subject: RE: Benchmarks: Catalina M5 vs. Apache 1.3.12 Jason - I am attempting to generate some server performance numbers as well. What tool would you recommend to test TOMCAT vs. WebLogic JRun et al.??? If you can point me in the right direction for a good test harness to plug-in I would be very grateful. Thank you for your time and consideration of this matter. Regards, Curtis QA Engineer BusinessThreads -Original Message- From: Jason Brittain [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 05, 2000 12:48 PM To: [EMAIL PROTECTED] Subject: Benchmarks: Catalina M5 vs. Apache 1.3.12 I wrote up a text file about benchmarking and comparing Tomcat-4.0-M5 (pre-release) and Apache 1.3.12. It's attached to this message. I wrote it for anyone who is interested (even non-Java-saavy people) to know how the raw content serving performance of Catalina and its built-in web server compares to that of Apache 1.3.12. It contains lots of information to help people understand some of the important differences between the two servers. Feedback, flames, reproduced test results, etc. are welcome! :) Cheers. -- Jason Brittain Software Engineer, Olliance Inc.http://www.Olliance.com Current Maintainer, Locomotive Project http://www.Locomotive.org
RE: bug # 527
Just clarifying some things: - Windows 98 Control Panel doesn't have System/Environment to set environment variables, if you want some environment variable available to every windows task you must set this on AUTOEXEC.BAT (yes the old batch file ;). If you set an environment variable inside a command window it affects just that process (just a copy of the main environment space). - To solve the 'Out of Environment Space' error you must edit CONFIG.SYS (again, the old MS-DOS not so defunct operating system presence). You must add the following line: SHELL=C:\COMMAND.COM /E:8192 /P please replace C:\COMMAND.COM to the correct location if you moved COMMAND.COM to another location. The "/E:8192" allocates 8k to be used by environment variables. The maximum allowed is 32k (35736). The last parameter, "/P", is used to make this COMMAND.COM instance resident in memory and owner of main environment space (from which every process receives a copy). -Original Message- From: Ashutosh Aman [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 05, 2000 5:18 PM To: [EMAIL PROTECTED] Subject: bug # 527 There is a bug in the bug reporting system. WorkAround and how to reproduce did not appear with my submission. Here is the description: * how to reproduce Install tomcat on windows98 and try to run using startup.bat file. Workaround WORK AROUND # 1 Include the following line in startup.bat as the first executable line. set TOMCAT_HOME=C:\Tomcat32, where C:\Tomcat32 is the directory in which Tomcat is installed. Include the following line in tomcat.bat as the first executable line. set JAVA_HOME=C:\jdk1.3 (C:\jdk1.3 is path to jdk installation) set TOMCAT_HOME=C:\Tomcat32 (c:\Tomcat32 is path to tomcat installation) set CLASSPATH=%TOMCAT_HOME%\lib;%TOMCAT_HOME%\classes set CP=%TOMCAT_HOME% Please make sure that in following releases of Tomcat, startup.bat and tomcat.bat are created with above modifications. WORK AROUND # 2 To cover 'Out of Environment Space' error do the following: Open a MS-DOS window Click on top left corner of window Select properties option click on memory tab Adjust the initial Environment drop-down box from Auto to 2816 Click OK Close the window Start the server again. please include this instructions in future releases as it consumed one whole day of mine trying to set up and run tomcat on windows 98. Thanks Aman _ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com
Benchmarks
Hi Jason, First, it's really great to see the discussions about performance ! Your tests are extremely usefull I use ab and apache very often ( I used it as the main tool to tune tomcat 3.2 and now 3.3 ). One thing that strikes me is the fact that I have a slower computer ( Celeron / 363 ) my numbers for apache ( with -c 60 ) are usually much smaller. ( it happens that I used the same test while rewriting the static servlet to StaticInterceptor ) I did another run, here is the sumarry: ( ab -c 60 -n 1 http://localhost/index.html): - Apache 1.3.12 - DEFAULT CONFIG, no change: First run: RPS: 344.44 Total: 67 172 637 Second run: RPS: 363.40 Total: 85 163 268 - Apache 1.3.12 - your config file First run: RPS: 261.27 Total:105 228 477 Second run: RPS: 253.63 Total: 81 234 402 - Tomcat 3.3 - IBM JDK1.3 First run: RPS: 276.07 Total: 46 216 3265 Second: RPS: 345.55 Total: 17 172 228 - Tomcat 3.3 - Hotspot First: RPS: 287.5 Total: 53 206 764 Second: RPS: 308 Total: 42 193 1134 ( after another run the number get lower - almost same as IBM1.3 ) Of course, tomcat3.3 is not yet completely tuned, and static file handling is still far away from what it should be. Also, note that neither apache nor tomcat3.3 will cache the file - you should use MMapFile to compare with a container that uses caching. ( that adds about 20% performance to apache - since Linux is also caching the file accesses are not a very big factor )( BTW, last Apache2.0 I tried was almost 2x faster than 1.3 ) Costin On Tue, 5 Dec 2000, Jason Brittain wrote: I wrote up a text file about benchmarking and comparing Tomcat-4.0-M5 (pre-release) and Apache 1.3.12. It's attached to this message. I wrote it for anyone who is interested (even non-Java-saavy people) to know how the raw content serving performance of Catalina and its built-in web server compares to that of Apache 1.3.12. It contains lots of information to help people understand some of the important differences between the two servers. Feedback, flames, reproduced test results, etc. are welcome! :) Cheers.
[PATCH] Fix for src/doc/faq - What do different init parameters for the JSP engine mean?
Can someone apply this patch? It looks like the faq had fallen a little out of date while the name of the JspServlet changed. Took me a little while to figure out why JSPs stopped working after following the FAQ. :-) This diff was performed on tomcat-3.2 final src tarball. Thanks, -Dave --- jakarta-tomcat-3.2-src/src/doc/faq.orig Tue Dec 5 12:36:19 2000 +++ jakarta-tomcat-3.2-src/src/doc/faq Tue Dec 5 12:36:29 2000 @@ -225,7 +225,7 @@ jsp /servlet-name servlet-class - org.apache.jasper.runtime.JSPServlet + org.apache.jasper.servlet.JspServlet /servlet-class init-param param-name
Re: Benchmarks: Catalina M5 vs. Apache 1.3.12
Hi there Chris. You can certainly do just what I did, use ApacheBench and see what numbers you get with each server. There's also another tester called Apache JMeter, which will show you graphical views of the tests as they're happening. JMeter has some bugs, but it's good anyway. You can find it here: http://java.apache.org/jmeter/index.html Try that out too. And, it would be great if you could share your results, even if you don't go into the depth about your tests as I did.. Have fun! -- Jason Curtis Dougherty wrote: Jason - I am attempting to generate some server performance numbers as well. What tool would you recommend to test TOMCAT vs. WebLogic JRun et al.??? If you can point me in the right direction for a good test harness to plug-in I would be very grateful. Thank you for your time and consideration of this matter. Regards, Curtis QA Engineer BusinessThreads -Original Message- From: Jason Brittain [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 05, 2000 12:48 PM To: [EMAIL PROTECTED] Subject: Benchmarks: Catalina M5 vs. Apache 1.3.12 I wrote up a text file about benchmarking and comparing Tomcat-4.0-M5 (pre-release) and Apache 1.3.12. It's attached to this message. I wrote it for anyone who is interested (even non-Java-saavy people) to know how the raw content serving performance of Catalina and its built-in web server compares to that of Apache 1.3.12. It contains lots of information to help people understand some of the important differences between the two servers. Feedback, flames, reproduced test results, etc. are welcome! :) Cheers.
BugRat Report #528 has been filed.
Bug report #528 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/528 REPORT #528 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: docbug State: received Priority: medium Severity: non-critical Confidence: public Environment: Release: Tomcat 3.2 JVM Release: all Operating System: all OS Release: all Platform: all Synopsis: src/doc/faq contains wrong information for overriding the JspServlet Description: Can someone apply this patch? It looks like the faq had fallen a little out of date while the name of the JspServlet changed. Took me a little while to figure out why JSPs stopped working after following the FAQ. :-) This diff was performed on tomcat-3.2 final src tarball. Thanks, -Dave PS - I just posted this to the tomcat-dev list, thought it would better to put it into BugRat. --- jakarta-tomcat-3.2-src/src/doc/faq.orig Tue Dec 5 12:36:19 2000 +++ jakarta-tomcat-3.2-src/src/doc/faq Tue Dec 5 12:36:29 2000 @@ -225,7 +225,7 @@ jsp /servlet-name servlet-class - org.apache.jasper.runtime.JSPServlet + org.apache.jasper.servlet.JspServlet /servlet-class init-param param-name Title: BugRat Report # 528 BugRat Report # 528 Project: Tomcat Release: Tomcat 3.2 Category: Bug Report SubCategory: New Bug Report Class: docbug State: received Priority: medium Severity: non-critical Confidence: public Submitter: David Rees ([EMAIL PROTECTED]) Date Submitted: Dec 5 2000, 02:52:00 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: src/doc/faq contains wrong information for overriding the JspServlet Environment: (jvm, os, osrel, platform) all, all, all, all Additional Environment Description: Report Description: Can someone apply this patch? It looks like the faq had fallen a little out of date while the name of the JspServlet changed. Took me a little while to figure out why JSPs stopped working after following the FAQ. :-) This diff was performed on tomcat-3.2 final src tarball. Thanks, -Dave PS - I just posted this to the tomcat-dev list, thought it would better to put it into BugRat. --- jakarta-tomcat-3.2-src/src/doc/faq.orig Tue Dec 5 12:36:19 2000 +++ jakarta-tomcat-3.2-src/src/doc/faq Tue Dec 5 12:36:29 2000 @@ -225,7 +225,7 @@ jsp - org.apache.jasper.runtime.JSPServlet + org.apache.jasper.servlet.JspServlet View this report online...
AW: Benchmarks: Catalina M5 vs. Apache 1.3.12
Hi, The notion of "tomcat is fast enough" used to be a dream but we`re getting there. I am going to run a few big sites on a combo of apache and tomcat, since there are a lot of PHP and mod_perl scripts in use. That means that for a given period of time Apache needs to sit in front of Tomcat to do a lot of work. This amount of work gets smaller and smaller during a period of about 12 months. Plans are to shift slowly to Servlets/JSP only, buts its not easy to get the right programmers for that purpose. In this timeframe we hopefully will see further improvements in regards to stability and performance of tomcat. And i personally hope that the unofficial battle between all the versions of tomcat (3.1, 3.2, 4.x) will improve the overall quality of Tomcat but finally end up in just one version. Tomcat is already the only server for the intranet application server which runs an publishing/content management system. Here we see an performance of up to 25-35 request/s (500 MHz Pii, Suse Linux, 512 MByte, IBM JDK 1.3) including an XML-RPC protocol, which is reason for quite an hefty overhead but its worth it. The real server will have an 1 Gz CPU and 1 GByte of RAM so i expect some more possible request/s. Juergen Fey "don`t drive when you`re dead, tom waits" The box said "Win95 or better", so i installed Linux -Ursprüngliche Nachricht- Von: Jason Brittain [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 5. Dezember 2000 19:48 An: [EMAIL PROTECTED] Betreff: Benchmarks: Catalina M5 vs. Apache 1.3.12 I wrote up a text file about benchmarking and comparing Tomcat-4.0-M5 (pre-release) and Apache 1.3.12. It's attached to this message. I wrote it for anyone who is interested (even non-Java-saavy people) to know how the raw content serving performance of Catalina and its built-in web server compares to that of Apache 1.3.12. It contains lots of information to help people understand some of the important differences between the two servers. Feedback, flames, reproduced test results, etc. are welcome! :) Cheers. -- Jason Brittain Software Engineer, Olliance Inc.http://www.Olliance.com Current Maintainer, Locomotive Project http://www.Locomotive.org
Apache/tomcat config question?
Hi all, I am currently trying to use URL rewriting for using sessions in our JSP application. I used the encodeURL method to encode the URL which returns a ;jsessionid-.. appended to my URL. Now, when I click on this I get a page not found error. We are using Apache/tomcat as our backend. Wanted to find out, whether I need to do some specific configuration on Apache/tomcat for URL rewriting to be recognized? Any help would be appreciated. Thanks, Ajanta.
HTTP Extension Framework Spec
Are there any plans to support HTTP Extension Framework Spec (RFC2774 at http://www.w3.org/Protocols/HTTP/ietf-http-ext/) with Tomcat and Apache Web Server? -thanks bapu patil
Re: Modifying the Ajp13 Protocol
As I'm working through the ajp13 code (C and Java), I'm discovering that there is some basic work which needs to be done on the protocol itself (as well as a lot of work on the implementations). Cool there is some need for. Specifically: - If the request contains 8K of header/attribute information, the protocol fails. - There is no authentication step. I believe that this could result in some serious security violations if the web server is performing HTTP authentication (since remote_user is one of the attributes passed over). [side note: if anyone thinks otherwise, let me know] Since connections are maintained across many requests, there is no good reason not to do the authentication (IMHO). Rigth, a fix is needed. We could use a strategy like hosts.deny and hosts.allow used on Linux systems. We could add also a secret token between the apache server and tomcat. I've also some ideas around. To fix these major issues will require modifying the protocol. I have some ideas on how to do so, but I want to get some feedback on the best way to go about making these changes. I could just modify the protocol itself, and change the mod_jk code and Ajp13 code in the tomcat-3.3 branch. My fear is that I'll be changing a protocol which is in production use, without changing its version number. This seems like asking for trouble. Should I therefore leave ajp13 where it is and work on ajp14? Or is that multiplying protocols needlessly? Please consider also tomcat 3.2 since it could be included in 3.2.1 ;-) BTW: Why not negociating at connect time ? We could have ajp13 on tomcat check if a key is present and then : - It could accept old ajp13 unsecurized - It could require an ajp13 securized via secret token. Even simpler will be to use some ACL to accept only from source IP adress. It will avoid to change the protocol. When using tomcat with apache it's easy to protect the link via routers or firewall. Also the protection could be include in integrated firewall found on Linux/BSD box = No need to modify tomcat or ajp13. I realize that the new mod_webapp is being worked on, but it seems to me that getting mod_jk / ajp13 working right is probably still worth it -- there are plenty of people who are going to depend on that before Tomcat 4.0 is released. Right : for now ajp13 and mod_jk are the only production ready protocol. If I do change the protocol, it will require people who download the new version to update their mod_jk.so at the same time as they rebuild the Java classes. I'll do that job at least for Linux box and could also do that on Windows world (just need to adapt makefile to borland free c compiler) What do people think? +1 PS: You did a nice work on documenting ajp13. Feel free to recontact me directly ;-)
Re: Benchmarks: Catalina M5 vs. Apache 1.3.12
I wrote up a text file about benchmarking and comparing Tomcat-4.0-M5 (pre-release) and Apache 1.3.12. It's attached to this message. I wrote it for anyone who is interested (even non-Java-saavy people) to know how the raw content serving performance of Catalina and its built-in web server compares to that of Apache 1.3.12. It contains lots of information to help people understand some of the important differences between the two servers. may I suggest the same test against the tomcat 3.2 release ;-)
Re: Benchmarks: Catalina M5 vs. Apache 1.3.12
Eric Hartmann [EMAIL PROTECTED] wrote: Hello, OpenSta seems to be a good harness test with multiple client. You can find it at http://sourceforge.net/projects/opensta/ And there's always Apache Jmeter http://java.apache.org/jmeter Pier -- Pier P. Fumagalli Apache Software Foundation mailto:[EMAIL PROTECTED] Neque porro quisquam est qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit... (Cicero: "De Finibus" 1.10.32)
BugRat Report #529 has been filed.
Bug report #529 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/529 REPORT #529 Details. Project: Jasper Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: serious Confidence: public Environment: Release: 3.2 JVM Release: Any Operating System: Any OS Release: Any Platform: Any Synopsis: jsp:include error message is not descriptive Description: When only page attribute is specified to jsp:include, the error message is "Invalid jsp:include tag". Would have been better if it said that required attribute "flush" wasn't specified. This is a common error since most reasonable people assume flush is optional (since the only valid value it true). And the error gives no indication of what the problem is. Fix is to move the attrs.size() != 2 check in org.apache.jasper.compiler.IncludeGenerator couple of checks down to after check for flush. Title: BugRat Report # 529 BugRat Report # 529 Project: Jasper Release: 3.2 Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: serious Confidence: public Submitter: Arun Katkere ([EMAIL PROTECTED]) Date Submitted: Dec 5 2000, 04:09:20 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: error message is not descriptive Environment: (jvm, os, osrel, platform) Any, Any, Any, Any Additional Environment Description: Report Description: When only page attribute is specified to jsp:include, the error message is "Invalid jsp:include tag". Would have been better if it said that required attribute "flush" wasn't specified. This is a common error since most reasonable people assume flush is optional (since the only valid value it true). And the error gives no indication of what the problem is. Fix is to move the attrs.size() != 2 check in org.apache.jasper.compiler.IncludeGenerator couple of checks down to after check for flush. View this report online...
Re: Benchmarks
Hi Costin. [EMAIL PROTECTED] wrote: Hi Jason, First, it's really great to see the discussions about performance ! Your tests are extremely usefull I'm just returning the favor, after sitting through your ApacheCon session about the Tomcat performance/benchmarking.. I use ab and apache very often ( I used it as the main tool to tune tomcat 3.2 and now 3.3 ). It's nice, isn't it? I was going to write something like it, but since it was already there, I just used it. Like I said, it's got a few bugs, but it mostly gives useful information, and works pretty well. One thing that strikes me is the fact that I have a slower computer ( Celeron / 363 ) my numbers for apache ( with -c 60 ) are usually much smaller. I may know why this is. Before running my benchmarks, I played with ab quite a bit on both Apache and on Tomcat4. I wanted to tune the config files to give me the best performance that I could get on my machine. I ran lots of tests, changed config values (mainly threading or processing limits and defaults), and re-ran tests to see how the changes in the config files affected the performance outcomes. I eventually found what I believe to be about the most optimal settings *for my machine* for both Apache and Tomcat4. So, the configs I show in my tests have been tailored to my machine -- its CPU speed, RAM size, everything. Another machine that has different specs may not perform well with my machine's configs.. It may actually perform worse. I came to the conclusion that each different machine needs tailored config files, and that there probably is a process that one could follow to find the optimal settings for a machine. I've even considered writing some automated software to run overnight, all night long, benchmarking and tweaking the configs until the performance of the server on that machine is optimal. Do you realize how many servers could be substantially more efficient if everyone did that? Just an idea, but I think I want to do it.. ( it happens that I used the same test while rewriting the static servlet to StaticInterceptor ) I did another run, here is the sumarry: ( ab -c 60 -n 1 http://localhost/index.html): - Apache 1.3.12 - DEFAULT CONFIG, no change: First run: RPS: 344.44 Total: 67 172 637 Second run: RPS: 363.40 Total: 85 163 268 - Apache 1.3.12 - your config file First run: RPS: 261.27 Total:105 228 477 Second run: RPS: 253.63 Total: 81 234 402 I think this is good evidence that what I said above is in fact happening. By raising the number of processes on your machine (from the default) to the number of processes that are optimal for my machine, your machine gets bogged down a little by the weight of all those processes, and can't easily perform as well as it did before with a smaller number of processes. This also shows why it's a good idea that Apache's default config file sets the defaults the way it does. - Tomcat 3.3 - IBM JDK1.3 First run: RPS: 276.07 Total: 46 216 3265 Second: RPS: 345.55 Total: 17 172 228 - Tomcat 3.3 - Hotspot First: RPS: 287.5 Total: 53 206 764 Second: RPS: 308 Total: 42 193 1134 ( after another run the number get lower - almost same as IBM1.3 ) These numbers look pretty good.. did you also set the VM options like "-Xms96m -Xmx96m"? On my machine, that made the maximum times come down dramatically -- from the thousands of milliseconds to the hundreds of milliseconds. Of course, with a different Tomcat. :) It might do the same for yours though, again depending on your machine's specs. Of course, tomcat3.3 is not yet completely tuned, and static file handling is still far away from what it should be. Also, note that neither apache nor tomcat3.3 will cache the file - you should use MMapFile to compare with a container that uses caching. ( that adds about 20% performance to apache - since Linux is also caching the file accesses are not a very big factor ) I think Tomcat4 does cache the file, but also checks just to make sure that what it's caching hasn't changed on disk. ( BTW, last Apache2.0 I tried was almost 2x faster than 1.3 ) Yeah, that's about what I expect too. It can run in a multithreaded way just like Java servers do. So, no more heavyweight processes to lug around (not entirely sure this is a big deal on Linux, but on Solaris it is, and on other OSs I think it is). Cheers. -- Jason Brittain Software Engineer, Olliance Inc.http://www.Olliance.com Current Maintainer, Locomotive Project http://www.Locomotive.org
Class loading classloader visibility test results
For those that may be interested... I was unclear as to how Tomcat was resolving class loading and the visibility of classes to a context's classloader so I created a simlpe test suite. The test results are attached. Rob Shaw Servidium Inc. Title: Tomcat Test Results Class Loading Tests Setup: A servlet was created that tries to load a class in Package A and a class in Package B via Class.forName(). If either class was found, the class was instantiated via newInstance(). Within the constructor of the class in Package A, an attempt to load a class in Package B is made via Class.forName(). Within the constructor of the class in Package B, an attempt to load a class in Package A is made via Class.forName(). Test Scenarios Results # Servlet in webapp's classes directory Servlet in system classpath Package A in webapp's classes or lib directory Package A in system classpath Package B in webapp's classes or lib directory Package B in system classpath Servlet loaded Package A found Package A able to load package B Package B found Package B able to load package A 1 X . X . X . Yes Yes Yes Yes Yes 2 X . X . . X Yes Yes Yes Yes No 3 X . . X X . Yes Yes No Yes Yes 4 X . . X . X Yes Yes Yes Yes Yes 5 . X X . X . Yes No N/A No N/A 6 . X X . . X Yes No N/A Yes No 7 . X . X X . Yes Yes No No N/A 8 . X . X . X Yes Yes Yes Yes Yes Conclusions: Only scenarios 1, 4, and 8 produced no errors. Scenario 1 says treat an application as an independent unit and place everything that it needs in it's webapps classes or lib directory. Scenario 4 says place only the servlet in the webapps classes directory and have the rest of the supporting classes and JARs outside accessible via the system classpath. Scenario 8 says place everything in a location that is accessible via the system classpath.
No Route To Host exp
While trying to shutdown tomcat, I get this exception: java.net.NoRouteToHostException: Connection timed out at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:312) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:125) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:112) at java.net.Socket.init(Socket.java:273) at java.net.Socket.init(Socket.java:100) at org.apache.tomcat.task.StopTomcat.execute(StopTomcat.java:104) at org.apache.tomcat.startup.Tomcat.stopTomcat(Tomcat.java:267) at org.apache.tomcat.startup.Tomcat.execute(Tomcat.java:174) at org.apache.tomcat.startup.Tomcat.main(Tomcat.java:235) I'm allowed to start Tomcat (ps'ing the box shows running processes, and I can hit :8080), but why can't I shut it down? A word of note, our internal network configuration here is quite, er, simple (we simply don't do routing of any sort), so if there are solutions in that area, I'll track them down first. I have the 3.2 final build of tomcat, binary. java -version : ecom-util:~# java -version java version "1.3.0" Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.3.0-FCS) Java HotSpot(TM) Client VM (build Blackdown-1.3.0-FCS, mixed mode) Any help would be appreciated, Matt
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/log LogEntry.java QueueLogger.java
costin 00/12/05 15:31:16
Modified:src/share/org/apache/tomcat/util/log QueueLogger.java
Added: src/share/org/apache/tomcat/util/log LogEntry.java
Log:
Small change in util.log - expose the LogEntry.
I'm going to do another set of small changes to clean up the way loggers
are set up and maintained in ContextManager.
Among the changes, I would like to split Logger in LogManager and
LogHandler, use the package name to identify loggers. Probably
I'll try few performance enhancements ( recycle and pool LogEntry,
re-add the optional XML output format, try to make the interfaces similar
to the javax.logging so we can easily switch when the spec will be available)
I'll also try to port back the AccessLogValve.
( all this is low-priority, finishing the core is the most important thing)
Revision ChangesPath
1.2 +3 -44
jakarta-tomcat/src/share/org/apache/tomcat/util/log/QueueLogger.java
Index: QueueLogger.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/log/QueueLogger.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- QueueLogger.java 2000/09/29 14:33:37 1.1
+++ QueueLogger.java 2000/12/05 23:31:16 1.2
@@ -126,47 +126,6 @@
public String toString() {
return "QueueLogger(" + getName() + ", " + getPath() + ")";
}
-
-
-/**
- * This is an entry that is created in response to every
- * Logger.log(...) call.
- */
-public final class LogEntry {
- String logName;
- long date=0;
- String message;
- Throwable t;
- QueueLogger l;
-
- LogEntry(QueueLogger l, long date, String message, Throwable t) {
- this.date = date;
- this.message = message;
- this.t = t;
- this.l=l;
- }
-
- LogEntry( QueueLogger l, String message, Throwable t) {
- this.message = message;
- this.t = t;
- this.l=l;
- }
-
- public void print( StringBuffer outSB) {
- if (date!=0) {
- formatTimestamp( date, outSB );
- outSB.append(" - ");
- }
-
- if (message != null)
- outSB.append(message);
-
- if (t != null) {
- outSB.append(" - ");
- outSB.append(throwableToString( t ));
- }
- }
-}
}
/**
* The daemon thread that looks in a queue and if it is not empty
@@ -191,8 +150,8 @@
private void emptyQueue() {
do {
- QueueLogger.LogEntry logEntry =
- (QueueLogger.LogEntry) logQueue.pull();
+ LogEntry logEntry =
+ (LogEntry) logQueue.pull();
QueueLogger tl=logEntry.l;
Writer writer=tl.sink;
if (writer != null) {
@@ -216,7 +175,7 @@
}
} while (!LogDaemon.this.logQueue.isEmpty());
}
-
+
public void run() {
while (true) {
emptyQueue();
1.1
jakarta-tomcat/src/share/org/apache/tomcat/util/log/LogEntry.java
Index: LogEntry.java
===
/*
*
*
* The Apache Software License, Version 1.1
*
* Copyright (c) 1999 The Apache Software Foundation. All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in
*the documentation and/or other materials provided with the
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
*any, must include the following acknowlegement:
* "This product includes software developed by the
*Apache Software Foundation (http://www.apache.org/)."
*Alternately, this acknowlegement may appear in the software itself,
*if and wherever such third-party acknowlegements normally appear.
*
* 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
*Foundation" must not be used to endorse or promote products derived
*from this software without prior written permission. For written
*permission, please contact [EMAIL PROTECTED]
*
* 5. Products derived from this software may not be called "Apache"
*nor may "Apache" appear in their names without prior
RE: Proposal: new commiter
+1 Good Work, Dan. Saludos , Ignacio J. Ortega -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Enviado el: martes 5 de diciembre de 2000 23:49 Para: [EMAIL PROTECTED] Cc: Dan Milstein Asunto: Proposal: new commiter Hi, Please vote for Dan Milstein as a new commiter for tomcat. Dan did an excelent review of the connector code, documented the protocol, proposed many enhancements and re-factored the Ajp13 adapter. We are very lucky to have someone who is interested in this difficult area and continues the great work that Gal Shachor started. Thanks, Costin
Re: Benchmarks
Hi Jason, It's nice, isn't it? I was going to write something like it, but since it was already there, I just used it. Like I said, it's got a few bugs, but it mostly gives useful information, and works pretty well. Open source :-) I may know why this is. Before running my benchmarks, I played with ab quite a bit on both Apache and on Tomcat4. I wanted to tune the config files to give me the best performance that I could get on my machine. I ran lots of tests, changed config values (mainly threading or processing limits and defaults), and re-ran tests to see how the changes in the config files affected the performance outcomes. I eventually found what I believe to be about the most optimal settings *for my machine* for both Apache and Tomcat4. So, the configs I show in my tests have been tailored to my machine -- its CPU speed, RAM size, everything. Another machine that has different specs may not perform well with my machine's configs.. It may actually perform worse. That's one of the best descriptions of what performance tunning means :-) Yes, it's a lot of work - change every parameter and find how it affects your system, test again and again until you find the best combination. Most of the time it's not worth the effort, but for a big site or for a piece of software that is going to be used by many people I think it is worth it. Do you realize how many servers could be substantially more efficient if everyone did that? Just an idea, but I think I want to do it.. The only ways we can get faster servers is to document and discuss those issues. ( wouldn't be nice not to have to wait 5 seconds for a page to display ? ) And we should also continue to tune up and improve the performances of tomcat ( regardless of version number :-). I don't think static file peformance is the main target ( our goal is to write a fast servlet engine), and we should compare with Apache2.0 or NES ( wich in many tests was faster than A2.0 ). What would be very interesting is comparing C modules with servlets ( we can't be that fast, but if we are withing 50% it's perfect ). These numbers look pretty good.. did you also set the VM options like "-Xms96m -Xmx96m"? On my machine, that made the maximum times come down dramatically -- from the thousands of milliseconds to the hundreds of milliseconds. Of course, with a different Tomcat. :) It might do the same for yours though, again depending on your machine's specs. Ops, I forgot about that You're right. ( BTW, last Apache2.0 I tried was almost 2x faster than 1.3 ) Yeah, that's about what I expect too. It can run in a multithreaded way just like Java servers do. So, no more heavyweight processes to lug around (not entirely sure this is a big deal on Linux, but on Solaris it is, and on other OSs I think it is). If you have time, you can also take a look at AOLServer ( another open-source, high-performance server - and it does work with tomcat as well). Costin
Re: Proposal: new commiter
[EMAIL PROTECTED] wrote: Hi, Please vote for Dan Milstein as a new commiter for tomcat. +1 Hans -- Hans Bergsten [EMAIL PROTECTED] Gefion Software http://www.gefionsoftware.com
Re: HTTP Extension Framework Spec
on 12/5/2000 12:59 PM, "PATIL,BAPU (HP-Cupertino,ex1)" [EMAIL PROTECTED] wrote: Are there any plans to support HTTP Extension Framework Spec (RFC2774 at http://www.w3.org/Protocols/HTTP/ietf-http-ext/) with Tomcat and Apache Web Server? -thanks bapu patil Sure! Submit a patch to implement it. :-) -jon
Re: Proposal: new commiter
on 12/5/2000 2:48 PM, "[EMAIL PROTECTED]" [EMAIL PROTECTED] wrote: Hi, Please vote for Dan Milstein as a new commiter for tomcat. Dan did an excelent review of the connector code, documented the protocol, proposed many enhancements and re-factored the Ajp13 adapter. We are very lucky to have someone who is interested in this difficult area and continues the great work that Gal Shachor started. Thanks, Costin +1 -jon -- Honk if you love peace and quiet.
Re: Proposal: new commiter
Hi, Please vote for Dan Milstein as a new commiter for tomcat. +1 Arieh Dan did an excelent review of the connector code, documented the protocol, proposed many enhancements and re-factored the Ajp13 adapter. We are very lucky to have someone who is interested in this difficult area and continues the great work that Gal Shachor started. Thanks, Costin -- Arieh Markel Sun Microsystems Inc. Network Storage500 Eldorado Blvd. MS UBRM11-194 e-mail: [EMAIL PROTECTED] Broomfield, CO 80021 Let's go Panthers Phone: (303) 272-8547 x78547 (e-mail me with subject SEND PUBLIC KEY to get public key)
BugRat Report #530 has been filed.
Bug report #530 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/530 REPORT #530 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: serious Confidence: public Environment: Release: 3.2-final JVM Release: n/a Operating System: n/a OS Release: n/a Platform: n/a Synopsis: [PATCH] bad default character encoding in jsp pages Description: jsp pages served by tomcat contain a bad charset string in their http header. This is not understood by some non iso8859-1 systems/browsers. Macintosh w/ netscape 4.76 will fail to understand that 8859_1 is actually ISO-8859-1. According to src/webpages/docs/api/javax/servlet/ServletResponse.html, the reply should be "ISO-8859-1". According to IANA, the 8859_1 is *not* a way to say ISO-8859-1 in MIME headers http://www.isi.edu/in-notes/iana/assignments/character-sets Name: ISO_8859-1:1987[RFC1345,KXS2] MIBenum: 4 Source: ECMA registry Alias: iso-ir-100 Alias: ISO_8859-1 Alias: ISO-8859-1 (preferred MIME name) Alias: latin1 Alias: l1 Alias: IBM819 Alias: CP819 Alias: csISOLatin1 are all allowed ways to describe a character set in MIME. This is not the same as Java's internal represenation, which truely is 8859_1. Title: BugRat Report # 530 BugRat Report # 530 Project: Tomcat Release: 3.2-final Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: serious Confidence: public Submitter: Palle Girgensohn ([EMAIL PROTECTED]) Date Submitted: Dec 5 2000, 06:52:47 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: [PATCH] bad default character encoding in jsp pages Environment: (jvm, os, osrel, platform) n/a, n/a, n/a, n/a Additional Environment Description: Report Description: jsp pages served by tomcat contain a bad charset string in their http header. This is not understood by some non iso8859-1 systems/browsers. Macintosh w/ netscape 4.76 will fail to understand that 8859_1 is actually ISO-8859-1. According to src/webpages/docs/api/javax/servlet/ServletResponse.html, the reply should be "ISO-8859-1". According to IANA, the 8859_1 is *not* a way to say ISO-8859-1 in MIME headers Name: ISO_8859-1:1987[RFC1345,KXS2] MIBenum: 4 Source: ECMA registry Alias: iso-ir-100 Alias: ISO_8859-1 Alias: ISO-8859-1 (preferred MIME name) Alias: latin1 Alias: l1 Alias: IBM819 Alias: CP819 Alias: csISOLatin1 are all allowed ways to describe a character set in MIME. This is not the same as Java's internal represenation, which truely is 8859_1. How To Reproduce: null Workaround: null View this report online...
Re: Class loading classloader visibility test results
Rob Shaw wrote: I was unclear as to how Tomcat was resolving class loading and the visibility of classes to a context's classloader so I created a simlpe test suite. That is very helpful and informative (and cool!). I (and probably others) would like to know, though: What version of Tomcat were you using? Thanks, Brian
[PATCH] bad default charset encoding in jsp pages
Hi! jsp pages served by tomcat contain a bad charset string in their http header. This is not understood by some non iso8859-1 systems/browsers. Macintosh w/ netscape 4.76, for example will fail to understand that 8859_1 is actually ISO-8859-1. According to jakarta-tomcat/src/webpages/docs/api/javax/servlet/ServletResponse.html, the reply should be "ISO-8859-1". According to IANA, the 8859_1 is *not* a way to say ISO-8859-1 in MIME headers http://www.isi.edu/in-notes/iana/assignments/character-sets: Name: ISO_8859-1:1987[RFC1345,KXS2] MIBenum: 4 Source: ECMA registry Alias: iso-ir-100 Alias: ISO_8859-1 Alias: ISO-8859-1 (preferred MIME name) Alias: latin1 Alias: l1 Alias: IBM819 Alias: CP819 Alias: csISOLatin1 are all allowed ways to describe a character set. 8859_1 is apparently not one of them, although Java uses this string internally, which is fine... Hence, I vote for my enclosed patch, so Mac users can benefit from tomcat jsp pages. ;-) To repeat: create a simple jsp page with some latin1 characters, like åäö. serve this page with tomcat to a Macintosh w/ netscape 4.76. You won't get åäö, but other strange characters instead. Cheers, Palle -- Partitur Informationsteknik AB Wenner-Gren Center +46 8 566 280 02 113 46 Stockholm +46 70 785 86 02 Sweden [EMAIL PROTECTED] Index: src/share/org/apache/jasper/compiler/Compiler.java === RCS file: /home/cvspublic/jakarta-tomcat/src/share/org/apache/jasper/compiler/Compiler.java,v retrieving revision 1.19.2.2 diff -u -u -r1.19.2.2 Compiler.java --- src/share/org/apache/jasper/compiler/Compiler.java 2000/08/28 17:48:24 1.19.2.2 +++ src/share/org/apache/jasper/compiler/Compiler.java 2000/12/06 00:39:09 @@ -142,7 +142,7 @@ // - compiling the generated servlets (pass -encoding to javac). // XXX - There are really three encodings of interest. -String jspEncoding = "8859_1"; // default per JSP spec +String jspEncoding = "ISO-8859-1"; // default per JSP spec String javaEncoding = "UTF8"; // perhaps debatable? // This seems to be a reasonable point to scan the JSP file
Re: Class loading classloader visibility test results
Tomcat 3.1 and 3.2. I haven't run the tests for 4.0. Thanks for the feedback, Rob. - Original Message - From: "Brian Bucknam" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: "Rob Shaw" [EMAIL PROTECTED] Sent: Tuesday, December 05, 2000 6:36 PM Subject: Re: Class loading classloader visibility test results Rob Shaw wrote: I was unclear as to how Tomcat was resolving class loading and the visibility of classes to a context's classloader so I created a simlpe test suite. That is very helpful and informative (and cool!). I (and probably others) would like to know, though: What version of Tomcat were you using? Thanks, Brian
Re: Kudos to Jason and his benchmarking report
Hi Roy. Roy Wilson wrote: Jason, This is an impressive piece of work: very systematic and very well-documented. I wrote it to be similar to the Volano Java benchmarks. (I really enjoy those! :) I have several questions. I ran some similar tests (without adjusting configuration parameters) and noticed variability as large as 10% in throughput that surprised me, even when N = 10,000. You mean your benchmarks in comparison to mine? Not sure what you're comparing here.. To reduce that, I felt compelled to use N = 100,000. Your data seems pretty stable: did you run more tests and just truncate the reporting? I did run lots of test benchmarks to tune first.. but the numbers in my text are "real", since right before the real (shown) tests I shut the server down and restarted it. Something I didn't note in my text is that I wasn't trying to benchmark initialization.. I didn't want my benchmark numbers to include first-request kinds of initialization lag times.. so between restarting the server and when I ran the benchmarks I used ab to make a few single requests to make sure both Apache and Catalina were initialized enough to not show horrible request times due mostly to initialization. So, the first benchmark test shows slower numbers than the second does. I should have noted this in the text, or I shouldn't have done it. It seems that no matter how verbose you try to be with tests like this, you end up forgetting something anyway. :) Probably I should have just let the first test be slow, and explain what happened. Either way, at least the second test for each kind of test contains some good solid numbers. Do you think it would be worthwhile to rerun the test with N = 100,000 maybe two or three times ( my tests took hours )? With that many requests per benchmark, I can certainly see why the tests took hours! :) I came down to 10,000 requests because I felt that the system must have stabilized in that amount of requests (I could be wrong), but also because 100,000 was simply taking too long. Whether the numbers would have turned out very differently is anyone's guess until someone does it.. Maybe I'll try. Costin's ab data shows a ramp up: the shell script I posted a while back was based on that approach. I liked the scripts, but couldn't use them only because I found that I had intentionally *not* installed the process accounting package when I installed RedHat on my laptop.. :) So, I had to drop that part, and that was the main purpose for the scripts as far as I could tell. I will probably install the process accounting package at some point so I can try it out. I have another machine at home now that is bigger and faster, so I may run more benchmarks on that machine, maybe even in an automated fashion. I noticed doing my measurements that Apache throughput increased as C increased (up to C = 100), whereas TC throughput did not (actually it declined). I also wonder what the architectural explanation might be for the different scalability behavior (maybe this is obvious, I haven't thought about it yet). I wonder if you could (in your spare time :-)} repeat the test 3 times for C = 20, 40, 60, 80, 100 with N = 100,000. I will try this as soon as I get a chance.. But, one thing that may be a problem is the request-per-second limits of our boxes. If each of our machines has a limit to the number of requests per second they can handle and we run benchmarks beyond those numbers, then we're no longer seeing accurate benchmarks -- we'll see some slow response times, or even failed requests and it won't be because the server software failed. Take a look at this: http://www.enhydra.org/software/cvs/cvsweb.cgi/~checkout~/Enhydra/modules/EnhydraDirector/src/README.TUNING?rev=1.1content-type=text/plain And also this: http://httpd.apache.org/docs/misc/descriptors.html By reading those, you'll see that there are many upper limits that you could hit without really knowing.. So, if you're running high traffic benchmarks and you're not watching for these problems, then your benchmark numbers are probably bad/wrong at the high end. I want to try your benchmarks like c=100 and N=100,000, but first I want to make sure my machine is ready for that.. :) That's my plan, along with using sar and sa with C = 1 to get CPU demand measures. I need to install those too.. Maybe others will join this little band of performance freaks. Oh I'm sure someone out there reading this will. :) BTW, little credit should go to me re: ab use (or should I say "abuse"). Craig suggested using ab and Costin did it (and did it, ... :-)). Pier "inspired" me to look at ab code and think about how it can be used as a tool for getting information about both behavior and the resource usage that drives it. Okay, they each get my special thanks as well! Your stuff (along with Costin's) might be a key part of a great guide to TCx
BugRat Report #532 has been filed.
Bug report #532 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/532 REPORT #532 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: serious Confidence: public Environment: Release: Tomcat 3.2 final JVM Release: 1.3.0 Operating System: Solaris OS Release: 2.8 Platform: SPARC Synopsis: Tomcat mod_jk.so refuses to load with Apache 1.3.14 undefined symbol Description: I build Apache 1.3.14 from scratch on Solaris 2.8 using GCC 2.95.2. I also built the mod_jk.so from scratch on the same machine. Apache 1.3.14 refuses to load the mod_jk.so module because of an undefined symbol fdatasync. I found this in librt.so and libposix4.so on the machine. The offending call is in jk_util.c:112 Title: BugRat Report # 532 BugRat Report # 532 Project: Tomcat Release: Tomcat 3.2 final Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: serious Confidence: public Submitter: Joe Ceklosky ([EMAIL PROTECTED]) Date Submitted: Dec 5 2000, 07:33:16 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: Tomcat mod_jk.so refuses to load with Apache 1.3.14 undefined symbol Environment: (jvm, os, osrel, platform) 1.3.0, Solaris, 2.8, SPARC Additional Environment Description: None Report Description: I build Apache 1.3.14 from scratch on Solaris 2.8 using GCC 2.95.2. I also built the mod_jk.so from scratch on the same machine. Apache 1.3.14 refuses to load the mod_jk.so module because of an undefined symbol fdatasync. I found this in librt.so and libposix4.so on the machine. The offending call is in jk_util.c:112 How To Reproduce: null Workaround: null View this report online...
Re: MVC problem
I guess, there IS a way to forward the .jsp processing to tomcat's
jsp-servlet, even when you have registered your own servlet to process all
.jps requests.
Instead of using
ServletContext.getRequestDispatcher(url).forward(request, response);
use
ServletContext.getNamedRequestDispatcher("jserv-servlet").forward(request,
response);
It worked for me.
Note: This method does not work if you want to "re-write" the url in your
handler servlet. JSP files processed by the jserv-servlet is always the URL
of the original request.
Kedar
- Original Message -
From: Craig R. McClanahan [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Thursday, November 30, 2000 11:27 PM
Subject: Re: MVC problem
See below.
"Aiken, David" wrote:
hi all..
We're hitting a problem with the MVC approach in tomcat.
Our controller is designed to intercept all requests for URLs within
our
web application so that it can handle internationalization and
security
checks centrally.
The problem is as follows:
- the controller servlet registers interest in URLs of the form
'*.jsp'
- a request for 'a.jsp' arrives and the controller checks security and
negotiates the locale settings
- the controller includes the contents of 'a.jsp' in the response
At this point it seems that tomcat takes over. Unfortunately, it
doesn't
retrieve the contents of the page - it just resubmits the request to
the
controller again, resulting in an endless loop. This also occurs for a
'forward'. Not good.
One of the workarounds is to use URLs of the form '.do' to request
page
content. This allows the controller to forward to a .jsp URL without
getting into a loop. The problem is that someone who knows the
structure
of the www site can submit requests for '.jsp' directly and bypass any
security checks. The obvious workaround for this is to put tags into
the
.jsp pages and java calls into any servlets to perform the security
check
- but this negates any advantage to the MVC approach (and forces
page/servlet developers to remember to place checks into all of their
content).
We're probably missing something - it seems difficult to believe that
the
MVC approach has such a fundamental flaw.
thanks!
David Aiken
BMC Software
What you are hitting is primarily a limitation of the way that servlet
mappings
work in servlet 2.2. If you define a servlet mapping that maps the
"*.jsp"
extension to the JSP servlet (as Tomcat does by default), then the JSP
servlet
will be executed -- bypassing your security checks. If you register the
"*.jsp"
extension to your own servlet, then you will receive the request -- but
there is
no way to forward control later to get the JSP page executed.
This kind of issue was one of the motivating factors for the Filter API of
the
new servlet 2.3 spec (which Tomcat 4.0 supports). This lets you register
filters that can preprocess (and postprocess, if you want) requests to
particular URI patterns, completely independently of which servlets will
actually process those requests.
For your use case, you could write a filter that is mapped to the "*.jsp"
extension. It would look at the request, before the JSP system ever sees
it.
If your security checks are satisfied, simply pass the request on through
the
filter chain, which will cause the page to be executed in the usual way.
If a
check fails, you can redirect the user to an error page instead.
Craig McClanahan
Re: Proposal: new commiter
+1 Thanks Dan [EMAIL PROTECTED] wrote: Hi, Please vote for Dan Milstein as a new commiter for tomcat. Dan did an excelent review of the connector code, documented the protocol, proposed many enhancements and re-factored the Ajp13 adapter. We are very lucky to have someone who is interested in this difficult area and continues the great work that Gal Shachor started. Thanks, Costin -- -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | --
System.out, System.err redirecting request
I'm wondering if the developers of Tomcat might consider implementing something in Tomcat so that a user can add a setting to server.xml similar to how other log files are configured so that you can redirect System.err and System.out to files. IMHO, this would be very useful. In fact, I suspect that many developers and users might prefer that these be redirected to files by default. I know about the redirecting the shell script output, but I still think it would be very useful to have it configurable within server.xml. One reason is that on Windows it is not as easy as doing a "startup.bat stdout.log." That doesn't seem to capture the output since a separate window is being created. So, I'm guessing that you would have to modify the batch file to get it to work. I would much prefer modifying server.xml to get this to work. Note, if you reply, please reply to [EMAIL PROTECTED] because I am not subscribed to this list. Thanks, Jon
BugRat Report #533 has been filed.
Bug report #533 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/533 REPORT #533 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: serious Confidence: public Environment: Release: Tomcat 3.2 Final JVM Release: Sun JDK 1.3.0-C Operating System: NT4 OS Release: SP5 Platform: intel Synopsis: classpath does not include /lib after loading a war file Description: Tomcat 3.2 Final on Win32 does not follow the complete servlet 2.2 spec as it does not add the jar files placed in web-inf/lib into the classpath of the webapp as specified in section 9 of the servlet spec. Title: BugRat Report # 533 BugRat Report # 533 Project: Tomcat Release: Tomcat 3.2 Final Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: serious Confidence: public Submitter: the Blue Adept ([EMAIL PROTECTED]) Date Submitted: Dec 5 2000, 11:15:03 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: classpath does not include /lib after loading a war file Environment: (jvm, os, osrel, platform) Sun JDK 1.3.0-C, NT4, SP5, intel Additional Environment Description: Report Description: Tomcat 3.2 Final on Win32 does not follow the complete servlet 2.2 spec as it does not add the jar files placed in web-inf/lib into the classpath of the webapp as specified in section 9 of the servlet spec. How To Reproduce: null Workaround: null View this report online...
Re: multiple cookies, PR 371, any news?
I thought I'd test out my new status as the resident Ajp13 expert by fixing this bug,
and I think I've got it. I'm attaching patches to util/MimeHeaders.java and
modules/server/Ajp13.java. I've done some minimal testing, and it seems to fix the
problem.
I also did a tiny bit of further cleanup in Ajp13 (in case you look at the patch in
detail).
-Dan
Palle Girgensohn wrote:
Hi!
Just installed tomcat 3.2 final.
I am forced to still use apj12 due to tomcat failing to create
multiple cookies at once when using ajp13 (and possibly also
redirect):
Cheers,
Palle
--
Partitur Informationsteknik AB
Wenner-Gren Center +46 8 566 280 02
113 46 Stockholm +46 70 785 86 02
Sweden [EMAIL PROTECTED]
--
Dan Milstein // [EMAIL PROTECTED]
Index: MimeHeaders.java
===
RCS file:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/util/MimeHeaders.java,v
retrieving revision 1.17
diff -u -r1.17 MimeHeaders.java
--- MimeHeaders.java2000/11/20 21:37:45 1.17
+++ MimeHeaders.java2000/12/06 05:11:38
@@ -210,18 +210,29 @@
//
/**
- * Returns an enumeration of strings representing the header field names.
- * Field names may appear multiple times in this enumeration, indicating
- * that multiple fields with that name exist in this header.
+ * Returns an enumeration of strings representing the header field
+ * names. Field names are unique in this enumeration (which is
+ * actually not that useful)
*/
public Enumeration names() {
return new NamesEnumerator(this);
}
+/**
+ * Return an enumeration of header values for a given name.
+ */
public Enumeration values(String name) {
return new ValuesEnumerator(this, name);
}
+/**
+ * Return an enumeration of 2-element String arrays representing pairs
+ * of header names and header values.
+ */
+public Enumeration getNamesValues() {
+ return new NamesValuesEnumerator(this);
+}
+
// Adding headers
@@ -419,6 +430,47 @@
findNext();
return current.toString();
}
+}
+
+/**
+ * Enumerate the names and values together -- cleans up handling of
+ * multiple headers with identical names (Set-Cookie, say). Each element
+ * of the enumeration is an array of length two: { name, value }
+ **/
+class NamesValuesEnumerator implements Enumeration {
+int pos;
+int size;
+MimeHeaders headers;
+String[] nextNameValuePair = new String[2];
+String[] returnNameValuePair = new String[2]; // Reused -- safe?
+
+NamesValuesEnumerator(MimeHeaders headers) {
+ pos = 0;
+ this.headers = headers;
+ size = headers.size();
+ findNext();
+}
+
+private void findNext() {
+ nextNameValuePair[0] = null;
+ if(pos size) {
+ nextNameValuePair[0] = headers.getName( pos ).toString();
+ nextNameValuePair[1] = headers.getValue( pos ).toString();
+ pos++;
+ }
+}
+
+public boolean hasMoreElements() {
+ return nextNameValuePair[0] != null;
+}
+
+public Object nextElement() {
+ returnNameValuePair[0] = nextNameValuePair[0];
+ returnNameValuePair[1] = nextNameValuePair[1];
+ findNext();
+ return returnNameValuePair;
+}
+
}
class MimeHeaderField {
Index: Ajp13.java
===
RCS file:
/home/cvspublic/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13.java,v
retrieving revision 1.6
diff -u -r1.6 Ajp13.java
--- Ajp13.java 2000/12/05 06:30:15 1.6
+++ Ajp13.java 2000/12/06 05:12:31
@@ -257,7 +257,7 @@
req.serverName().setString( msg.getString());
req.setServerPort( msg.getInt());
- isSSL = (msg.getByte() != 0);
+ isSSL = msg.getBool();
// Decode headers
MimeHeaders headers = req.getMimeHeaders();
@@ -444,16 +444,18 @@
outBuf.appendInt(headers.size());
-Enumeration e = headers.names();
+Enumeration e = headers.getNamesValues();
while(e.hasMoreElements()) {
-String headerName = (String)e.nextElement();
+String[] nameValuePair = (String[]) e.nextElement();
+ String headerName = nameValuePair[0];
+ String headerValue = nameValuePair[1];
int sc = headerNameToSc(headerName);
if(-1 != sc) {
outBuf.appendInt(sc);
} else {
outBuf.appendString(headerName);
}
-outBuf.appendString(headers.getHeader(headerName));
+outBuf.appendString(headerValue);
}
outBuf.end();
@@ -520,13 +522,13 @@
/**
Re: Class loading classloader visibility test results
Aron, Based on the stack trace alone it's difficult to debug the problem. If you want everything to be self contained within your context, then the first thing I would ensure is that every class required by your servlet is contained with the classes or lib directory of your context. Also, since the system classloader is used prior to your webapp's classloader, ensure that your system classpath is clean to avoid inadvertent loading of classes. Ideally this is all you would have to do. As a long shot, I've run into the following gotcha which may apply to xml4j. I've run into problems with code that attempts to grab the current classloader in the following way: Object object = new Object(); ClassLoader loader = object.getClass().getClassLoader(); I've found that the classloader retrieved in this manner is unable to load classes from within my context. My rationale for this is because java.lang.Object is loaded and instantiated via the system classloader, and thus the system classloader is returned. Instead you want to do something like: ClassLoader loader = getClass().getClassLoader(); which should return your webapp's classloader. Hopefully this helps. Rob - Original Message - From: "Aron Kramlik" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, December 05, 2000 8:36 PM Subject: RE: Class loading classloader visibility test results Rob, This is great information. I wonder if you could explain why it is that I need to put xml4j.jar file under the $CLASSPATH (i.e. $TOMCAT_HOME/lib) that is loaded by an init() method of a servlet? Once I do this the class, com.ibm.xml.parsers.DOMParser, is found. Stack trace below. Anyh help would be much appreciated. Thanks again for the great info, Aron. java.lang.ClassNotFoundException: com.ibm.xml.parsers.DOMParser at java.lang.Throwable.init(Throwable.java:96) at java.lang.Exception.init(Exception.java:44) at java.lang.ClassNotFoundException.init(ClassNotFoundException.java:71) at java.net.URLClassLoader.findClass(URLClassLoader.java:205) at java.lang.ClassLoader.loadClass(ClassLoader.java(Compiled Code)) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:380) at java.lang.ClassLoader.loadClass(ClassLoader.java:257) at java.lang.Class.forName1(Native Method) at java.lang.Class.forName(Class.java:134) at org.xml.sax.helpers.ParserFactory.makeParser(ParserFactory.java:124) at com.tenzing.servlet.InitServlet.setXMLParser(InitServlet.java:331) at com.tenzing.servlet.InitServlet.initializeConfiguration(InitServlet.java:298 ) at com.tenzing.servlet.InitServlet.init(InitServlet.java:181) at org.apache.tomcat.core.ServletWrapper.doInit(ServletWrapper.java:317) -Original Message- From: Rob Shaw [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 05, 2000 2:49 PM To: [EMAIL PROTECTED] Subject: Class loading classloader visibility test results For those that may be interested... I was unclear as to how Tomcat was resolving class loading and the visibility of classes to a context's classloader so I created a simlpe test suite. The test results are attached. Rob Shaw Servidium Inc.
BugRat Report #534 has been filed.
Bug report #534 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/534 REPORT #534 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: serious Confidence: public Environment: Release: Tomcat 3.2 Final JVM Release: Sun JDK 1.3.0-C Operating System: NT4 OS Release: SP5 Platform: intel Synopsis: classpath does not include /lib after loading a war file Description: Tomcat 3.2 Final on Win32 does not follow the complete servlet 2.2 spec as it does not add the jar files placed in web-inf/lib into the classpath of the webapp as specified in section 9 of the servlet spec. Title: BugRat Report # 534 BugRat Report # 534 Project: Tomcat Release: Tomcat 3.2 Final Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: serious Confidence: public Submitter: the Blue Adept ([EMAIL PROTECTED]) Date Submitted: Dec 5 2000, 11:16:49 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: classpath does not include /lib after loading a war file Environment: (jvm, os, osrel, platform) Sun JDK 1.3.0-C, NT4, SP5, intel Additional Environment Description: Report Description: Tomcat 3.2 Final on Win32 does not follow the complete servlet 2.2 spec as it does not add the jar files placed in web-inf/lib into the classpath of the webapp as specified in section 9 of the servlet spec. How To Reproduce: null Workaround: null View this report online...
BugRat Report #535 has been filed.
Bug report #535 has just been filed. You can view the report at the following URL: http://znutar.cortexity.com/BugRatViewer/ShowReport/535 REPORT #535 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: serious Confidence: public Environment: Release: Tomcat 3.2 Final JVM Release: Sun JDK 1.3.0-C Operating System: NT4 OS Release: SP5 Platform: intel Synopsis: mime-types are not properly handled. Description: Adding a mime-type extension to the web.xml file for a war file does not add the mime-type to the extension. Title: BugRat Report # 535 BugRat Report # 535 Project: Tomcat Release: Tomcat 3.2 Final Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: serious Confidence: public Submitter: the Blue Adept ([EMAIL PROTECTED]) Date Submitted: Dec 5 2000, 11:22:42 CST Responsible: Z_Tomcat Alias ([EMAIL PROTECTED]) Synopsis: mime-types are not properly handled. Environment: (jvm, os, osrel, platform) Sun JDK 1.3.0-C, NT4, SP5, intel Additional Environment Description: Report Description: Adding a mime-type extension to the web.xml file for a war file does not add the mime-type to the extension. How To Reproduce: null Workaround: null View this report online...
Re: multiple cookies, PR 371, any news?
Hi Dan, I think you'll be able to commit the patch yourself very soon. I just have few comments - it's a good patch ( as it solves the problem), but it's not good for performance. We definitely need to do a refactoring of MimeHeaders :-) The idea behind MimeHeaders is to allow efficient storage and access to headers - without creating intermediary objects and with minimal pain. For example, output headers are stored by the servlet or container and most of the time are accessed only once, when the output is sent. In this case it's enough to do indexed access ( using size(), getName( int idx), getValue( int idx ) ). Creating an enumeration and all the string[] for each request is not a good idea IMHO. Costin
problem about the path of servlet
Hi, i am new comer to tomcat world. Now I meet a problem. After I config and start the tomcat, when I execute the servlet examples. It doesn't work. I check the log files, and it reads can't find the class. But the class files is right in the web-inf/classes directory, And I tried snoop, it doesn't work too. also it reads can't find snoop servlet. WHo can help me
Re: Benchmarks: Catalina M5 vs. Apache 1.3.12
Quoting Jason Brittain [EMAIL PROTECTED]: I wrote up a text file about benchmarking and comparing Tomcat-4.0-M5 (pre-release) and Apache 1.3.12. It's attached to this message. I wrote it for anyone who is interested (even non-Java-saavy people) to know how the raw content serving performance of Catalina and its built-in web server compares to that of Apache 1.3.12. It contains lots of information to help people understand some of the important differences between the two servers. Feedback, flames, reproduced test results, etc. are welcome! :) I'm glad it's not too bad (right now the static file serving is very badly optimized). There are some optimizations in, but we also do lots of unnecessary IO operations for each request. We won't do further optimizations on this before TC 4.0 is released, because we might get rid of the whole resources package after 4.0 (more on this after M5 is out). Remy
