Tomcat 3.3 mod_jk2
Has anyone managed to get tomcat 3.3.1a to work with mod_jk2 and if so how ? Thanks David -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17193] - java.net.bindException during shutdown in Tomcat 4.1.18
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17193. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17193 java.net.bindException during shutdown in Tomcat 4.1.18 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2003-05-30 14:39 --- This is still occuring in Tomcat 4.1.24 Bug 19098 seems to be a duplicate of this, but the resolution isn't helpful. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 9851] - Digest Authentication Doesn't Work Properly with Mozilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9851. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9851 Digest Authentication Doesn't Work Properly with Mozilla --- Additional Comments From [EMAIL PROTECTED] 2003-05-30 16:54 --- Created an attachment (id=6570) patch for DigestAuthenticator.removeQuotes to handle unquoted strings - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 9851] - Digest Authentication Doesn't Work Properly with Mozilla
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9851. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9851 Digest Authentication Doesn't Work Properly with Mozilla [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2003-05-30 16:57 --- In fact rfc2617 sec. 1.2 allows unquoted parameters: auth-param = token = ( token | quoted-string ) and none of the parameters defined in sec. 3.2.2 requires quotes, only in the realm-value (which is defined in sec. 1.2 for all authentication schemes) does: realm = realm = realm-value realm-value = quoted-string so any client could send any parameter without quotes, here is an example from amaya: Digest username=admin,realm=Test,nonce=1db89a32eb4dbb7e24a62a6d0814c50e,uri=/test,qop=auth,nc=0001 ,cnonce=012345678,response=863092c9a25115868640b6e016c2329d,opaque=992b892c6f47ff99b9fef0cb4d425c09 The attached patch addresses this problem, the patch is against this rev: * $Header: /home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/authenticator/DigestAuthenticator.java,v 1.11 2003/03/24 23:19:19 keith Exp $ * $Revision: 1.11 $ * $Date: 2003/03/24 23:19:19 $ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 OutputBuffer.java
remm2003/05/30 10:00:29
Modified:catalina/src/share/org/apache/coyote/tomcat5
OutputBuffer.java
Log:
- Commit the response even if the buffer is empty.
Revision ChangesPath
1.3 +4 -2
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/OutputBuffer.java
Index: OutputBuffer.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/OutputBuffer.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- OutputBuffer.java 1 May 2003 15:02:46 - 1.2
+++ OutputBuffer.java 30 May 2003 17:00:29 - 1.3
@@ -349,8 +349,10 @@
state = BYTE_STATE;
} else if (state == BYTE_STATE) {
bb.flushBuffer();
-} else if (state == INITIAL_STATE)
-realWriteBytes(null, 0, 0); // nothing written yet
+} else if (state == INITIAL_STATE) {
+// If the buffers are empty, commit the response header
+coyoteResponse.sendHeaders();
+}
doFlush = false;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20361] New: - Redirection responses sent on localized OS for Japanese and French are improperly formatted
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20361.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20361
Redirection responses sent on localized OS for Japanese and French are improperly
formatted
Summary: Redirection responses sent on localized OS for Japanese
and French are improperly formatted
Product: Tomcat 3
Version: 3.3.1 Final
Platform: All
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
When performing a redirection response
response.sendRedirect(response.encodeRedirectURL(myurl));
in a Tomcat instance running on a localized Japanese or French OS the
redirection response sent to the browser can be incorrectly encoded or have the
encoding misidentified.
The Tomcat ErrorHandler class explicitly sets the ContentType to be text/html
for redirections. This causes the ContentType header to be text/html.
However the response itself can contain multibyte data taken from the Japanese
and French resource files distibuted with Tomcat. The following section of
code shows how these resource files are used to construct a response based upon
the default locale of the JVM:
From ErrorHandler.java
res.setContentType(text/html);// ISO-8859-1 default
res.setHeader(Location, location);
if( sbNote==0 ) {
sbNote=req.getContextManager().getNoteId
(ContextManager.REQUEST_NOTE,
RedirectHandler.buff);
}
// we can recycle it because
// we don't call toString();
StringBuffer buf=(StringBuffer)req.getNote( sbNote );
if( buf==null ) {
buf = new StringBuffer();
req.setNote( sbNote, buf );
}
buf.append(htmlheadtitle).
append(sm.getString(defaulterrorpage.documentmoved)).
append(/title/head\r\nbodyh1).
append(sm.getString(defaulterrorpage.documentmoved)).
append(/h1\r\n).
append(sm.getString(defaulterrorpage.thisdocumenthasmoved)).
append( a href=\).
append( HttpMessages.filter( location ) ).
append(\here/a.p\r\n/body\r\n/html);
res.setContentLength(buf.length());
res.getBuffer().write( buf );
res.getBuffer().close();
buf.setLength(0);
If the encoding has been specified earlier in the JSP using a page directive:
[EMAIL PROTECTED] contentType=text/html; charset=utf-8%
the encoding of the redirection response will be the charset specified in the
page directive even though the response header indicates otherwise. On some
browsers this disagreement between specified encoding and actual encoding can
cause the browser to hang and not be redirected (seen on IE 6 - strangely only
when the redirection url is sufficiently long).
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20346] - jasper generate invalid package name
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20346. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20346 jasper generate invalid package name [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2003-05-30 17:23 --- I tried the version on Solaris, and the package name generated was org.apache.jsp. In fact, the generated package name is always org.apache.jsp, so I fail to see how it could be otherwise. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20364] New: - Jasper custom tag rtexprvalue=true doesn't seem to be honored for xml attributes
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20364. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20364 Jasper custom tag rtexprvalue=true doesn't seem to be honored for xml attributes Summary: Jasper custom tag rtexprvalue=true doesn't seem to be honored for xml attributes Product: Tomcat 4 Version: 4.1.24 Platform: PC OS/Version: Windows NT/2K Status: UNCONFIRMED Severity: Normal Priority: Other Component: Jasper AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I am using a struts html:link custom tag and the JSP expression is not processed. Example %@ taglib uri=/WEB-INF/struts-html.tld prefix=html % %int id=0;% html:link page=/x.do?id=%=id%link/html:link produces : a href=/webapp-name/x.do?id=%=id%link/a It should produce : a href=/webapp-name/x.do?id=0link/a However, if I place a jsp expression in the body of the html:link tag, it is evaluated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20364] - Jasper custom tag rtexprvalue=true doesn't seem to be honored for xml attributes
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20364. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20364 Jasper custom tag rtexprvalue=true doesn't seem to be honored for xml attributes --- Additional Comments From [EMAIL PROTECTED] 2003-05-30 17:39 --- I am using the default struts struts-html.tld with the page attribute : attribute namepage/name requiredfalse/required rtexprvaluetrue/rtexprvalue /attribute - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[5] EL parsing eats extra character after '?'
Attached below is a message from tomcat-user. I don't know it this is a valid
issue or not. If its not, it has great FAQ potential.
If it is a problem, could it be caused by the following the snippet below? It
looks like any custom tag would be ignored if preceded by a $. This seems to
be the behavior I saw when I put $ in front of the hello world tag in
/jsp-examples/jsp2/tagfiles/hello.jsp.
In org.apache.jasper.compiler.Parser.parseXMLTemplateText()
lines 1502, 1506
if (ch != '{') {
ttext.write('$');
ttext.write(ch);
continue;
}
I really don't know much about Jasper, and was just snooping.
-Tim
Original Message
Subject: Tomcat 5.0.2 Bug
Date: Fri, 30 May 2003 06:36:04 -0700 (PDT)
From: Ed Smith [EMAIL PROTECTED]
Reply-To: Tomcat Users List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
I think there is a bug in Tomcat 5.0.2 (at least under
Windows XP) dealing with placing a $ before (at least
some) tags.
Consider the following JSP:
jsp:useBean id=login class=LoginBean
scope=session/
jsp:setProperty name=login property=username
value=foo/
html
body
$jsp:getProperty name=login
property=username/
/body
/html
In Tomcat 4.1.24, this generates the following HTML
(as expected)
html
body
$foo
/body
/html
In Tomcat 5.0.2, it generates
html
body
$jsp:getProperty name=login
property=username/
/body
/html
The jsp taglib does not get processed in
5.0.2. Note that if I add a space after the $, it
works in 5.0.2
Changing to
$ jsp:getProperty name=login property=username/
gets the following HTML
html
body
$ foo
/body
/html
Am I missing something? I didnt find the problem in
either the bugs database or the mailing list archives.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13172] - Port incorrect in getServerPort and in access log
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13172. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13172 Port incorrect in getServerPort and in access log --- Additional Comments From [EMAIL PROTECTED] 2003-05-30 18:56 --- It seems that the getServerPort() method returns the port as specified in the Host header of the received message, not the port of the connector through which the request arrived. This seems to be a huge security issue. I am currently using a filter in my code to verify that a request arrived on a particular port (for security reasons) and am actually only verifying that the Host header says it came in on the port. It would be trivial for a client to spoof my code if I were to rely on the getServerPort() method as implemented. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup Catalina.java
jfarcand2003/05/30 12:27:44
Modified:catalina/src/share/org/apache/catalina/startup Catalina.java
Log:
Call the proper stop() by not using the nested class method, but the Catalina one
(my mistake).
Revision ChangesPath
1.18 +5 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Catalina.java
Index: Catalina.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Catalina.java,v
retrieving revision 1.17
retrieving revision 1.18
diff -u -r1.17 -r1.18
--- Catalina.java 21 May 2003 00:54:34 - 1.17
+++ Catalina.java 30 May 2003 19:27:44 - 1.18
@@ -659,7 +659,7 @@
public void run() {
if (server != null) {
-this.stop();
+Catalina.this.stop();
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 13172] - Port incorrect in getServerPort and in access log
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13172. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=13172 Port incorrect in getServerPort and in access log --- Additional Comments From [EMAIL PROTECTED] 2003-05-30 19:38 --- getServerName and getServerPort come from the Host header. Virtual hosting basics. For security, you should be using isSecure, getRemoteUser/Principal, getRemoteAddress, getRemoteHost. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [5] EL parsing eats extra character after '?'
Date: Fri, 30 May 2003 13:47:01 -0400
From: Tim Funk [EMAIL PROTECTED]
Subject: [5] EL parsing eats extra character after '?'
To: Tomcat Developers List [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Attached below is a message from tomcat-user. I don't know it this is a valid
issue or not. If its not, it has great FAQ potential.
Argh, this is a bug! JSP 2.0 now recognizes ${...} as an EL expression,
so there are some special handling for $ in the parser. It got this
wrong, apparently.
I'll commit a fix to this as soon as I send this mail out. Note that
the workaound to this problem is to write
\$jsp:getProperty name=login property=username/
instead. Here, \$ is an escape for $. This is new in JSP 2.0.
Note also that this can now be written as
\$${login.username}
taking advantage of EL in tc 5.
If it is a problem, could it be caused by the following the snippet below? It
looks like any custom tag would be ignored if preceded by a $. This seems to
be the behavior I saw when I put $ in front of the hello world tag in
/jsp-examples/jsp2/tagfiles/hello.jsp.
In org.apache.jasper.compiler.Parser.parseXMLTemplateText()
lines 1502, 1506
if (ch != '{') {
ttext.write('$');
ttext.write(ch);
continue;
}
This would not work, since parseXMLTemplateText deals only with
text in the body of jsp:text element.
I really don't know much about Jasper, and was just snooping.
Well, this is a good time to do that, now that Jasper in TC5 has
stablized. Ping me if you need help. :)
-Kin-man
-Tim
Original Message
Subject: Tomcat 5.0.2 Bug
Date: Fri, 30 May 2003 06:36:04 -0700 (PDT)
From: Ed Smith [EMAIL PROTECTED]
Reply-To: Tomcat Users List [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
I think there is a bug in Tomcat 5.0.2 (at least under
Windows XP) dealing with placing a $ before (at least
some) tags.
Consider the following JSP:
jsp:useBean id=login class=LoginBean
scope=session/
jsp:setProperty name=login property=username
value=foo/
html
body
$jsp:getProperty name=login
property=username/
/body
/html
In Tomcat 4.1.24, this generates the following HTML
(as expected)
html
body
$foo
/body
/html
In Tomcat 5.0.2, it generates
html
body
$jsp:getProperty name=login
property=username/
/body
/html
The jsp taglib does not get processed in
5.0.2. Note that if I add a space after the $, it
works in 5.0.2
Changing to
$ jsp:getProperty name=login property=username/
gets the following HTML
html
body
$ foo
/body
/html
Am I missing something? I didnt find the problem in
either the bugs database or the mailing list archives.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Parser.java
kinman 2003/05/30 13:16:19
Modified:jasper2/src/share/org/apache/jasper/compiler Parser.java
Log:
- In a template text, the char after '$' are not handled correctly.
Revision ChangesPath
1.75 +6 -4
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java
Index: Parser.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Parser.java,v
retrieving revision 1.74
retrieving revision 1.75
diff -u -r1.74 -r1.75
--- Parser.java 21 May 2003 18:09:33 - 1.74
+++ Parser.java 30 May 2003 20:16:19 - 1.75
@@ -1432,6 +1432,8 @@
break;
}
ttext.write('$');
+ reader.pushChar();
+ continue;
}
else if (ch == '\\') {
if (!reader.hasMoreInput()) {
@@ -1501,7 +1503,7 @@
ch = reader.nextChar();
if (ch != '{') {
ttext.write('$');
-ttext.write(ch);
+reader.pushChar();
continue;
}
// Create a template text node
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20369] New: - When load a jsp page multiple times, the content falls out of place
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20369. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20369 When load a jsp page multiple times, the content falls out of place Summary: When load a jsp page multiple times, the content falls out of place Product: Tomcat 4 Version: Unknown Platform: Sun OS/Version: Solaris Status: NEW Severity: Critical Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] When trying to load a jsp page multiple times, the content of the jsp page falls out of place. Some field might be missing. The dropdown from one field is appended to the another selection. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler SmapUtil.java
kinman 2003/05/30 14:48:14
Modified:jasper2/src/share/org/apache/jasper/compiler SmapUtil.java
Log:
- Don't generate a smap for jsp:attribute itself, though maps are
still generated for its body.
Revision ChangesPath
1.14 +1 -1
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/SmapUtil.java
Index: SmapUtil.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/SmapUtil.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- SmapUtil.java 26 Apr 2003 01:31:42 - 1.13
+++ SmapUtil.java 30 May 2003 21:48:14 - 1.14
@@ -558,8 +558,8 @@
doSmap(n);
visitBody(n);
}
+
public void visit(Node.NamedAttribute n) throws JasperException {
-doSmap(n);
visitBody(n);
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20374] New: - add way to put additional directories in shared classloader
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20374. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20374 add way to put additional directories in shared classloader Summary: add way to put additional directories in shared classloader Product: Tomcat 4 Version: 4.1.24 Platform: PC OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] It looks like these directories are hard-coded in Bootstrap.java to be fixed subdirectories of CATALINA_BASE. (BTW the documentation still says CATALINA_HOME.) I want to add classes and jar files from some additional directories. (They are at fixed locations in my development environment and I'm migrating from JRun which does make this configurable.) Perhaps a catalina.shared-classpath property? (Symbolic links would work except I'm running on Windows. Guess I'll have to copy them.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20376] New: - Internet Explorer 6.0 Duplicate Requests IE PLEASE HELP
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20376. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20376 Internet Explorer 6.0 Duplicate Requests IE PLEASE HELP Summary: Internet Explorer 6.0 Duplicate Requests IE PLEASE HELP Product: Tomcat 4 Version: 4.1.24 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Connector:Coyote JK 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] For some unknown reason, I found out that MSIE 6.0 with SP 1 not including the cummulative patch released on April 2003 send duplicate post requests for any jsp page. I use IIS with Jakarta ISAPI dll. tomcat version is 4.1.24. I found out when trying to debug intermittent server not found errors for a jsp page where i know the server is up and running and connection is fine. I used TCP trace Etheral where I found out that IE is always posting two identical requests except for the HTTP_REFERER header. After double checking IIS logs I found out that this is correct where there are lots of duplicate enteries. It is not an IE bug because the request comes fine to regular asp pages running on the same server. This bug is very annoying and completely unpredicatable. Havent' noticed it much with IE 5.5 or IE 5.0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[PATCH] RequestDispatcher.forward() problem with wrapped requests
I am fixing a bug filed by Ryan Lubke (Bugtraq 4871238). I do have a fix
in place, but I would like to make sure it's appropriate.
Consider the following scenario: Servlet1 acquires a RequestDispatcher
and forwards the request to Servlet2. However, before forwarding the
request, it wraps the request inside an HttpServletRequestWrapper. The
problem is that Servlet2 never gets invoked.
If you look at ApplicationDispatcher.processRequest(), you'll see that
the target servlet (Servlet2) is invoked only if the
DISPATCHER_TYPE_ATTR attribute has been set on the request.
Since we're passing to the RequestDispatcher an instance of
HttpServletRequestWrapper, ApplicationDispatcher.wrapRequest() will
replace the original wrapped request with an instance of
ApplicationHttpRequest, which is constructed from the original wrapped
request. ApplicationDispatcher.wrapRequest() essentially does this:
HttpServletRequest wrapped = wrapper.getRequest();
wrapper.setRequest(new ApplicationHttpRequest(wrapped));
The problem is that the DISPATCHER_TYPE_ATTR and
DISPATCHER_REQUEST_PATH_ATTR attributes on the original wrapped
request do not get propagated onto the ApplicationHttpRequest, and
therefore, getting these attributes from the
HttpServletRequestWrapper, which simply delegates to the wrapped
ApplicationHttpRequest, returns null, causing the target servlet to
not get invoked.
My suggested fix is to consider these attributes when constructing an
ApplicationHttpRequest from an HttpServletRequest, like this (in
ApplicationHttpRequest.setRequest()):
Index: ApplicationHttpRequest.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationHttpRequest.java,v
retrieving revision 1.8
diff -u -r1.8 ApplicationHttpRequest.java
--- ApplicationHttpRequest.java 26 May 2003 12:02:31 - 1.8
+++ ApplicationHttpRequest.java 31 May 2003 01:05:08 -
@@ -524,6 +524,10 @@
super.setRequest(request);
// Initialize the attributes for this request
+dispatcherType = request.getAttribute(Globals.DISPATCHER_TYPE_ATTR);
+requestDispatcherPath
+ = request.getAttribute(Globals.DISPATCHER_REQUEST_PATH_ATTR);
+
/*
synchronized (attributes) {
attributes.clear();
This fixes the problem.
Please let me know if you agree, and I'll commit.
Thanks,
Jan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/generators ErrorHandler.java
billbarker2003/05/30 19:45:58
Modified:src/share/org/apache/tomcat/modules/generators
ErrorHandler.java
Log:
Localize the charset for all error handlers.
Also change to always set the charset if it is available, since IMHO it is better to
send a charset then to assume that the browser defaults to iso-latin-1 (which is false
for MSIE, for example).
This clearly needs to be done for Japanese servers. It should be a pretty minor
change for en, fr, and sp servers. Other Locals where probably just as broken before.
Fix for bug #20361.
Reported By: Gary [EMAIL PROTECTED]
Revision ChangesPath
1.28 +27 -8
jakarta-tomcat/src/share/org/apache/tomcat/modules/generators/ErrorHandler.java
Index: ErrorHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/generators/ErrorHandler.java,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -r1.27 -r1.28
--- ErrorHandler.java 16 Oct 2002 06:03:39 - 1.27
+++ ErrorHandler.java 31 May 2003 02:45:58 - 1.28
@@ -485,7 +485,14 @@
throws Exception
{
String msg=(String)req.getAttribute(javax.servlet.error.message);
- res.setContentType(text/html);// ISO-8859-1 default
+
+ String charset = LocaleToCharsetMap.getCharset(Locale.getDefault());
+ if (charset == null) {
+ res.setContentType(text/html);
+ } else {
+ res.setContentType(text/html; charset= + charset);
+ res.setUsingWriter(true);
+ }
// javax.servlet.include.request_uri is set to this handler
String requestURI = req.requestURI().toString();
@@ -591,7 +598,7 @@
// only include head...body if reset was successful
if ( needsHead ) {
String charset = LocaleToCharsetMap.getCharset(Locale.getDefault());
- if (charset == null || charset.equalsIgnoreCase(ISO-8859-1))
+ if (charset == null)
res.setContentType(text/html);
else {
res.setContentType(text/html; charset= + charset);
@@ -690,13 +697,18 @@
if( sc == 304 ) {
//NotModified must not return a body
return;
- } else {
- // don't set a content type if we are answering If-Modified-Since.
- // Proxy caches might update their cached content-type with this
- // info (mod_proxy does it). Martin Algesten 15th Oct, 2002.
+ }
+ // don't set a content type if we are answering If-Modified-Since.
+ // Proxy caches might update their cached content-type with this
+ // info (mod_proxy does it). Martin Algesten 15th Oct, 2002.
+ String charset = LocaleToCharsetMap.getCharset(Locale.getDefault());
+ if (charset == null) {
res.setContentType(text/html);
+ } else {
+ res.setContentType(text/html; charset= + charset);
+ res.setUsingWriter(true);
}
-
+
if( sbNote==0 ) {
sbNote=req.getContextManager().getNoteId(ContextManager.REQUEST_NOTE,
StatusHandler.buff);
@@ -815,7 +827,14 @@
if( debug0) ctx.log(Redirect + location + + req );
- res.setContentType(text/html);// ISO-8859-1 default
+ String charset = LocaleToCharsetMap.getCharset(Locale.getDefault());
+ if (charset == null) {
+ res.setContentType(text/html);
+ } else {
+ res.setContentType(text/html; charset= + charset);
+ res.setUsingWriter(true);
+ }
+
res.setHeader(Location, location);
if( sbNote==0 ) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20361] - Redirection responses sent on localized OS for Japanese and French are improperly formatted
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20361. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20361 Redirection responses sent on localized OS for Japanese and French are improperly formatted [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-05-31 02:51 --- I've commited a fix to the CVS that should make this work. The fix should show up in the next 'nightly' (which aren't actually generated nightly anymore :) Unfortunately, I don't have access to a French or Japanese box to test it on. Feel free to re-open if this patch doesn't solve the problem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 20380] New: - AccessLogValve incorrectly calculates timezone
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20380.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20380
AccessLogValve incorrectly calculates timezone
Summary: AccessLogValve incorrectly calculates timezone
Product: Tomcat 4
Version: 4.1.24
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
AccessLogValve.java assumes that all timezones are exact multiples of an hour.
This doesn't work when you live in Adelaide (Australia) and other places around
the world.
When configured in that timezone, the log message looks like:
127.0.0.1 - - [31/May/2003:14:26:23 9050] GET /hello HTTP/1.1 404 683
(Notice the 9050!)
I found this when I was working on a MonthlyAccessLogValve, and fixed it there.
This will presumably be the same in other parts of the logging functionality.
Here's some code that appears to correctly calculate the timezone for both
hour based, and half-hour based timezones.
/**
* Creating a time zone that is formatted as +|-HHMM is not
* made easy by the Java classes. This provides a means of
* creating a suitable formatted timezone.
*/
private String createTimeZoneFormat(TimeZone tz, Date now)
{
int raw = (tz.getRawOffset() / 6);
if (tz.inDaylightTime(now))
{
raw += 60;
}
int hours = raw / 60;
int mins = raw - (hours*60);
StringBuffer sb = new StringBuffer();
if (hours =0)
{
sb.append('+');
}
else
{
sb.append('-');
hours *= (-1);
mins *= (-1);
}
if (hours 10)
{
sb.append('0');
}
sb.append(hours);
if (mins 10)
{
sb.append('0');
}
sb.append(mins);
return sb.toString();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] RequestDispatcher.forward() problem with wrapped requests
Jan Luehe wrote:
I am fixing a bug filed by Ryan Lubke (Bugtraq 4871238). I do have a fix
in place, but I would like to make sure it's appropriate.
Consider the following scenario: Servlet1 acquires a RequestDispatcher
and forwards the request to Servlet2. However, before forwarding the
request, it wraps the request inside an HttpServletRequestWrapper. The
problem is that Servlet2 never gets invoked.
If you look at ApplicationDispatcher.processRequest(), you'll see that
the target servlet (Servlet2) is invoked only if the
DISPATCHER_TYPE_ATTR attribute has been set on the request.
Since we're passing to the RequestDispatcher an instance of
HttpServletRequestWrapper, ApplicationDispatcher.wrapRequest() will
replace the original wrapped request with an instance of
ApplicationHttpRequest, which is constructed from the original wrapped
request. ApplicationDispatcher.wrapRequest() essentially does this:
HttpServletRequest wrapped = wrapper.getRequest();
wrapper.setRequest(new ApplicationHttpRequest(wrapped));
The problem is that the DISPATCHER_TYPE_ATTR and
DISPATCHER_REQUEST_PATH_ATTR attributes on the original wrapped
request do not get propagated onto the ApplicationHttpRequest, and
therefore, getting these attributes from the
HttpServletRequestWrapper, which simply delegates to the wrapped
ApplicationHttpRequest, returns null, causing the target servlet to
not get invoked.
My suggested fix is to consider these attributes when constructing an
ApplicationHttpRequest from an HttpServletRequest, like this (in
ApplicationHttpRequest.setRequest()):
Index: ApplicationHttpRequest.java
===
RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationHttpRequest.java,v
retrieving revision 1.8
diff -u -r1.8 ApplicationHttpRequest.java
--- ApplicationHttpRequest.java 26 May 2003 12:02:31 - 1.8
+++ ApplicationHttpRequest.java 31 May 2003 01:05:08 -
@@ -524,6 +524,10 @@
super.setRequest(request);
// Initialize the attributes for this request
+dispatcherType = request.getAttribute(Globals.DISPATCHER_TYPE_ATTR);
+requestDispatcherPath
+ = request.getAttribute(Globals.DISPATCHER_REQUEST_PATH_ATTR);
+
/*
synchronized (attributes) {
attributes.clear();
This fixes the problem.
Please let me know if you agree, and I'll commit.
Seems ok to me :)
Remy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[GUMP] Build timed out - jk
This email is autogenerated from the output from:
http://cvs.apache.org/builds/gump/2003-05-31/jakarta-tomcat-jk-native.html
Buildfile: build.xml
init:
[echo] /home/rubys
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-connectors/jk/build/jk
[echo] linux=true solaris=${solaris} win32=${win32} hpux=${hpux}
netware=${netware}
apache20:
apache13:
iis:
netscape:
jni:
[mkdir] Created dir: /home/rubys/jakarta/jakarta-tomcat-connectors/jk/build/jk/jni
[so] Compiling 4 out of 4
Compiling /home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/common/jk_map.c
Compiling /home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/common/jk_pool.c
Compiling /home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/common/jk_util.c
Compiling /home/rubys/jakarta/jakarta-tomcat-connectors/jk/native/jni/jk_jnicb.c
Linking /home/rubys/jakarta/jakarta-tomcat-connectors/jk/build/jk/jni/jni_connect.so
/home/rubys/bin/timeout: timed out
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
