Re: [PATCH] Bug 22666
Mark Thomas wrote: This is obviously a bigger mess than I first thought. As I see it, the following options exist for resolving bug 22666. 1. WONTFIX - On the basis that there is too much uncertainty to do anything sensible and that any changes made might break interoperability as per Remy's point 3 below. 2. FIX - Patch the parameter class (as per Remy's point 2 below) on the grounds that the JSP spec states The World Wide Web Consortium (http://www.w3.org/) is a definitive source of HTTP related information affecting this specification and its implementations. and the w3c view (http://www.w3.org/International/O-URL-code.html) is that URI encoding should always be based on UTF-8. However, this is still likely to break things (back to Remy's point 3). 3. FIX - Add a configuration option that enables w3c compliant URI decoding and patch the parameter and any other relevant classes to support this option. I am not 100% sure where the best place to do this would be. I am leaning towards adding it to the context as an optional parameter with a default state of disabled. There are several bugs in bugzilla that look as if they are on similar lines and on that basis my own view is that option 3 is way to go. Before I start coding, I would be grateful for some feedback/guidance on my planned approach. I'll vote almost 2 ;-) No client I know of is always cosistently using UTF8 to encode the URL, but however, I'm not sure clients are using the encoding of the entity body to encode the URL. Proper character decoding of the decoded (it means %xx decoded here) URL is already done (see CoyoteAdapter.convertURI), and there's a connector.getURIEncoding() which is available to indicate what encoding is to be used for the URL. Note: The default is US-ASCII (because something else doesn't work), but you can be compliant with the W3C and use UTF8 :) For more flexibility, we can use a new connector field for that (let's call it connector.getQueryStringEncoding()), or use connector.getURIEncoding(). This would be passed to the Parameters class and used exclusively for the query string decoding (the POSTed stuff won't use it, obviously). I want (I have to insist ;-) ) the default be US-ASCII (so the feature will work in the real world) with a quick and dirty B2C conversion in that particular case (like CoyoteAdapter.convertURI). Overall, this looks the most reasonable and flexible. Note: If you want to code it, you'd better do it really fast ;-) Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java
[EMAIL PROTECTED] wrote: remm2003/09/06 10:49:31 Modified:catalina/src/share/org/apache/catalina/loader WebappClassLoader.java Log: - Modify the bundling of commons-logging to fix (hopefully) the nagging CL issues. - The commons-logging-api JAR will now be put in the system classloader. When using an alternate logging implmentation (ex: log4j) you should put the wrapper implementation in the same classloader or there will likely be trouble. - Ex: When using a Struts 1.1 webapp with log4j, there should be commons-logging.jar (just the log4j logger is fine as well) next to it. - Of course, overriding the log4j API in a webapp is still not possible. It wasn't before as c-logging was treated as a special case by the classloader (like JAXP). - This nasty case now works for me (bug 22701), as well as using log4j with privileged webapps (with or without SSL). This patch isn't portable to 4.1.x, because the issue there isn't the same (it would is Jasper from 4.1.x used commons-logging, but thankfully it does not, so the headache level is lower). I'm suspecting what causes bug 22701 in TC 4.1.x is that the context classloader isn't properly reset in the StandardHostValve (I did that on purpose originally, thinking it was useless; maybe not ;-) ). Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http Parameters.java
remm2003/09/07 00:37:12
Modified:util/java/org/apache/tomcat/util/http Parameters.java
Log:
- Handle query string decoding as a special case.
- Char decoding is not lazy anymore (if parameter parsing is requested), but
the difference was mostly rhetorical.
- This will change behavior in TC 3.3 (to be identical with the new TC 5
default).
- I didn't test the change with UTF8.
Revision ChangesPath
1.11 +25 -8
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/Parameters.java
Index: Parameters.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/http/Parameters.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- Parameters.java 2 Sep 2003 21:34:39 - 1.10
+++ Parameters.java 7 Sep 2003 07:37:12 - 1.11
@@ -101,6 +101,7 @@
private Parameters currentChild=null;
String encoding=null;
+String queryStringEncoding=null;
/**
*
@@ -122,6 +123,11 @@
if(debug0) log( Set encoding to + s );
}
+public void setQueryStringEncoding( String s ) {
+ queryStringEncoding=s;
+ if(debug0) log( Set query string encoding to + s );
+}
+
public void recycle() {
super.recycle();
paramHashStringArray.clear();
@@ -281,22 +287,33 @@
public void handleQueryParameters() {
if( didQueryParameters ) return;
-if( queryMB != null)
-queryMB.setEncoding( encoding );
didQueryParameters=true;
- if( debug 0 )
- log( Decoding query + queryMB + + encoding);
-
+
if( queryMB==null || queryMB.isNull() )
return;
try {
- decodedQuery.duplicate( queryMB );
- decodedQuery.setEncoding(encoding);
+decodedQuery.duplicate( queryMB );
+if (queryStringEncoding == null) {
+ByteChunk bc = decodedQuery.getByteChunk();
+CharChunk cc = decodedQuery.getCharChunk();
+cc.allocate(bc.getLength(), -1);
+// Default encoding: fast conversion
+byte[] bbuf = bc.getBuffer();
+char[] cbuf = cc.getBuffer();
+int start = bc.getStart();
+for (int i = 0; i bc.getLength(); i++) {
+cbuf[i] = (char) (bbuf[i + start] 0xff);
+}
+decodedQuery.setChars(cbuf, 0, bc.getLength());
+} else {
+decodedQuery.setEncoding(queryStringEncoding);
+decodedQuery.toChars();
+}
} catch( IOException ex ) {
}
if( debug 0 )
- log( Decoding query + decodedQuery + + encoding);
+ log( Decoding query + decodedQuery + + queryStringEncoding);
processParameters( decodedQuery );
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5 CoyoteAdapter.java
remm2003/09/07 00:38:42
Modified:catalina/src/share/org/apache/coyote/tomcat5
CoyoteAdapter.java
Log:
- Handle query string decoding as a special case.
- The URI encoding is used for now. Add a new field for more flexibility.
- The encoding needs to be set once on the parameters, as they are tied to
the connector.
Revision ChangesPath
1.12 +8 -4
jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteAdapter.java
Index: CoyoteAdapter.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/coyote/tomcat5/CoyoteAdapter.java,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -r1.11 -r1.12
--- CoyoteAdapter.java2 Sep 2003 21:21:59 - 1.11
+++ CoyoteAdapter.java7 Sep 2003 07:38:42 - 1.12
@@ -187,6 +187,10 @@
req.setNote(ADAPTER_NOTES, request);
res.setNote(ADAPTER_NOTES, response);
+// Set query string encoding
+req.getParameters().setQueryStringEncoding
+(connector.getURIEncoding());
+
}
if (connector.isXpoweredBy()) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Bug 22666
Remy Maucherat wrote: I'll vote almost 2 ;-) No client I know of is always cosistently using UTF8 to encode the URL, but however, I'm not sure clients are using the encoding of the entity body to encode the URL. Proper character decoding of the decoded (it means %xx decoded here) URL is already done (see CoyoteAdapter.convertURI), and there's a connector.getURIEncoding() which is available to indicate what encoding is to be used for the URL. Note: The default is US-ASCII (because something else doesn't work), but you can be compliant with the W3C and use UTF8 :) For more flexibility, we can use a new connector field for that (let's call it connector.getQueryStringEncoding()), or use connector.getURIEncoding(). This would be passed to the Parameters class and used exclusively for the query string decoding (the POSTed stuff won't use it, obviously). I want (I have to insist ;-) ) the default be US-ASCII (so the feature will work in the real world) with a quick and dirty B2C conversion in that particular case (like CoyoteAdapter.convertURI). Overall, this looks the most reasonable and flexible. Note: If you want to code it, you'd better do it really fast ;-) I've just committed a very simple implementation of this (without the extra queryStringEncoding field, although this is not hard to add). Comments ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22848] - [PATCH] Fix typos/grammar in changelog.html
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=22848. 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=22848 [PATCH] Fix typos/grammar in changelog.html [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | Version|Unknown |5.0.10 --- Additional Comments From [EMAIL PROTECTED] 2003-09-07 11:57 --- Adding small new patch for 5.0.10 to this ticket. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22965] - [PATCH] Tidy up conf/web.xml
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22965. 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=22965 [PATCH] Tidy up conf/web.xml --- Additional Comments From [EMAIL PROTECTED] 2003-09-07 12:59 --- Created an attachment (id=8088) Fix some typos/formatting, add/update some content - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22965] New: - [PATCH] Tidy up conf/web.xml
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22965. 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=22965 [PATCH] Tidy up conf/web.xml Summary: [PATCH] Tidy up conf/web.xml Product: Tomcat 4 Version: Unknown Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Patch below for conf/web.xml: - fix minor spelling mistakes - reference parameters by '[parametername]', parameter values by [value] for easier reading - reindent/format all paragraphs - update comments: * default servlet is disabled by default, too * update/add some documentation to Welcome File List - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads ThreadPool.java
remm2003/09/07 06:25:26
Modified:util/java/org/apache/tomcat/util/threads ThreadPool.java
Log:
- Null a busy processor in the pool array. This isn't particularly useful, but is
more consistent with the rest of the algorithm, and helps get a clearer picture
when debugging.
Revision ChangesPath
1.13 +13 -4
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java
Index: ThreadPool.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/threads/ThreadPool.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- ThreadPool.java 28 Jul 2003 11:23:56 - 1.12
+++ ThreadPool.java 7 Sep 2003 13:25:26 - 1.13
@@ -308,14 +308,16 @@
private ControlRunnable findControlRunnable() {
ControlRunnable c=null;
-if(0 == currentThreadCount || stopThePool) {
+if (0 == currentThreadCount || stopThePool) {
throw new IllegalStateException();
}
+
// Obtain a free thread from the pool.
synchronized(this) {
-if(currentThreadsBusy == currentThreadCount) {
+
+if (currentThreadsBusy == currentThreadCount) {
// All threads are busy
-if(currentThreadCount maxThreads) {
+if (currentThreadCount maxThreads) {
// Not all threads were open,
// Open new threads up to the max number of idel threads
int toOpen = currentThreadCount + minSpareThreads;
@@ -345,8 +347,11 @@
}
// If we are here it means that there is a free thread. Take it.
-c = pool[currentThreadCount - currentThreadsBusy - 1];
+int pos = currentThreadCount - currentThreadsBusy - 1;
+c = pool[pos];
+pool[pos] = null;
currentThreadsBusy++;
+
}
return c;
}
@@ -395,6 +400,7 @@
if(stopThePool) {
return;
}
+
if((currentThreadCount - currentThreadsBusy) maxSpareThreads) {
int toFree = currentThreadCount -
currentThreadsBusy -
@@ -406,7 +412,9 @@
pool[currentThreadCount - currentThreadsBusy - 1] = null;
currentThreadCount --;
}
+
}
+
}
/**
@@ -527,6 +535,7 @@
public void run() {
while(true) {
try {
+
// Sleep for a while.
synchronized(this) {
this.wait(WORK_WAIT_TIMEOUT);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[5.0] JSP performance ...
... is not as good as it should be. I found a benchmark where TC is
currently not too good. The problem occurs when dealing with lots of
strings.
I'm attaching the benchmark, the code generated by TC, and the code
generated by Resin. Resin String handling tricks ends with it making
about half the amount of writes, and writing char arrays instead of
Strings. I believe this is faster :-D
While the benchmark is quite lame, I believe a lot of pages have similar
amounts of interleaved static HTML, so optimizing this would give a
healthy performance increase. (Note: I did a quick review with a
profiler, and all the CPU time is spent in the _jspService method body,
using a compiled JSP, so the performance overhead is in the generated
code for this particular test)
(I found this while looking for optimization ideas)
Can we get the same kind of stuff ? Kin-Man, Jan, others ?
Remy
%@ page session='false' import='java.util.*'%
htmlheadtitle%= request.getParameter(title) %/title/headbody
%
// build tight loop table with array data, multidimensional 5x6
String array[] = { Hello, World, 2000, Hello, World, 2000 };
Arrays.sort(array);
String multi[][] = { array, array, array, array, array };
%
table
% for(int row=0; row multi.length; row++) { %
tr bgcolor=%= (row % 2) == 1 ? gray : white %
% for(int col=0; col array.length; col++) { %
td align=centerfont size=+1%= multi[row][col] %/font/td
% } %
/tr
% } %
/table
%
String dummy = request.getParameter(integer);
int param = 2000; //Integer.parseInt(dummy);
for (int i=1; i=10; i++) {
int var = i+param;
%
%=var% Hello World Hello World Hello World Hello World Hello World Hello World
Hello World Hello World Hello World Hello World br/
%=var% Hello World Hello World Hello World Hello World Hello World Hello World
Hello World Hello World Hello World Hello World br/
%=var% Hello World Hello World Hello World Hello World Hello World Hello World
Hello World Hello World Hello World Hello World br/
%=var% Hello World Hello World Hello World Hello World Hello World Hello World
Hello World Hello World Hello World Hello World br/
%=var% Hello World Hello World Hello World Hello World Hello World Hello World
Hello World Hello World Hello World Hello World br/
%=var% Hello World Hello World Hello World Hello World Hello World Hello World
Hello World Hello World Hello World Hello World br/
%=var% Hello World Hello World Hello World Hello World Hello World Hello World
Hello World Hello World Hello World Hello World br/
%=var% Hello World Hello World Hello World Hello World Hello World Hello World
Hello World Hello World Hello World Hello World br/
%=var% Hello World Hello World Hello World Hello World Hello World Hello World
Hello World Hello World Hello World Hello World br/
%=var% Hello World Hello World Hello World Hello World Hello World Hello World
Hello World Hello World Hello World Hello World br/
%=var% Hello World Hello World Hello World Hello World Hello World Hello World
Hello World Hello World Hello World Hello World br/
%=var% Hello World Hello World Hello World Hello World Hello World Hello World
Hello World Hello World Hello World Hello World br/
%=var% Hello World Hello World Hello World Hello World Hello World Hello World
Hello World Hello World Hello World Hello World br/
%=var% Hello World Hello World Hello World Hello World Hello World Hello World
Hello World Hello World Hello World Hello World br/
%=var% Hello World Hello World Hello World Hello World Hello World Hello World
Hello World Hello World Hello World Hello World br/
%=var% Hello World Hello World Hello World Hello World Hello World Hello World
Hello World Hello World Hello World Hello World br/
%=var% Hello World Hello World Hello World Hello World Hello World Hello World
Hello World Hello World Hello World Hello World br/
%=var% Hello World Hello World Hello World Hello World Hello World Hello World
Hello World Hello World Hello World Hello World br/
%=var% Hello World Hello World Hello World Hello World Hello World Hello World
Hello World Hello World Hello World Hello World br/
%=var% Hello World Hello World Hello World Hello World Hello World Hello World
Hello World Hello World Hello World Hello World br/
%
}
%
/body/html
package org.apache.jsp;
import javax.servlet.*;
import javax.servlet.http.*;
import javax.servlet.jsp.*;
import java.util.*;
public final class h2000_jsp extends org.apache.jasper.runtime.HttpJspBase
implements org.apache.jasper.runtime.JspSourceDependent {
private static java.util.Vector _jspx_dependants;
public java.util.List getDependants() {
return _jspx_dependants;
}
public void _jspService(HttpServletRequest request, HttpServletResponse response)
throws java.io.IOException, ServletException {
JspFactory _jspxFactory = null;
PageContext pageContext = null;
ServletContext application = null;
ServletConfig config = null;
JspWriter
[5.0] Planning
Rather than having a vote for 5.0.10, I'd like to release a new 5.0.11 build with the fix for the (nasty) commons-logging classloading issues. The idea is that using Struts 1.1 with log4j is quite common, and using that in conjunction with a context config file cut pasted from the manager or admin (with the privileged=true thingie) would produce a horrible stack trace. So I'd like to have it fixed in a release ASAP :) So the plan is: - have a new 5.0.11 beta this week (or a bit later if there are other issues that need fixing in that build) - have a final beta when the specs are released - have a stable release shortly after Comments ? Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [PATCH] Bug 22666
On Sunday, September 07, 2003 8:47 AM, Remy Maucherat [SMTP:[EMAIL PROTECTED]
wrote:
Remy Maucherat wrote:
I've just committed a very simple implementation of this (without the
extra queryStringEncoding field, although this is not hard to add).
Comments ?
Remy
Thanks for your help with this. I have run through a simple UTF-8 test case and
the problem as reported in bug 22666 is still present. I have tracked down what
I believe to be the root cause to another part of the Parameters class. I have
developed a patch for TC-5 below. I also think that the re-written try block in
your patch for the Parameters class can be reverted as it doesn't appear to
have any affect for UTF-8 query parameters.
Mark
PS I am off on holiday for a few days. I there is any further work remaining on
this, I will do it on my return.
Index: catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java
===
RCS file: /home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apa
che/coyote/tomcat5/CoyoteRequest.java,v
retrieving revision 1.15
diff -u -r1.15 CoyoteRequest.java
--- catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java 31 Aug 2003
21:08:56 - 1.15
+++ catalina/src/share/org/apache/coyote/tomcat5/CoyoteRequest.java 7 Sep 2003
14:10:33 -
@@ -2316,7 +2316,7 @@
formData = new byte[len];
}
readPostBody(formData, len);
-parameters.processParameters(formData, 0, len);
+parameters.processParameters(formData, 0, len, false);
} catch (Throwable t) {
; // Ignore
}
Index: util/java/org/apache/tomcat/util/http/Parameters.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/h
ttp/Parameters.java,v
retrieving revision 1.11
diff -u -r1.11 Parameters.java
--- util/java/org/apache/tomcat/util/http/Parameters.java 7 Sep 2003 07:37:12
- 1.11
+++ util/java/org/apache/tomcat/util/http/Parameters.java 7 Sep 2003 14:11:43
-
@@ -392,7 +392,7 @@
CharChunk tmpNameC=new CharChunk(1024);
CharChunk tmpValueC=new CharChunk(1024);
-public void processParameters( byte bytes[], int start, int len ) {
+public void processParameters( byte bytes[], int start, int len, boolean
query ) {
int end=start+len;
int pos=start;
@@ -434,8 +434,14 @@
}
tmpName.setBytes( bytes, nameStart, nameEnd-nameStart );
tmpValue.setBytes( bytes, valStart, valEnd-valStart );
- tmpName.setEncoding( encoding );
- tmpValue.setEncoding( encoding );
+
+ if (query) {
+ tmpName.setEncoding( queryStringEncoding );
+ tmpValue.setEncoding( queryStringEncoding );
+ } else {
+ tmpName.setEncoding( encoding );
+ tmpValue.setEncoding( encoding );
+ }
try {
if( debug 0 )
@@ -533,13 +539,13 @@
if( data.getType() == MessageBytes.T_BYTES ) {
ByteChunk bc=data.getByteChunk();
processParameters( bc.getBytes(), bc.getOffset(),
- bc.getLength());
+bc.getLength(), true);
} else {
if (data.getType()!= MessageBytes.T_CHARS )
data.toChars();
CharChunk cc=data.getCharChunk();
processParameters( cc.getChars(), cc.getOffset(),
- cc.getLength());
+cc.getLength() );
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Bug report for Tomcat 3 [2003/09/07]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 258|Unc|Nor|2000-11-27|response.SendRedirect() resets/destroys Cookies th| | 2350|Ver|Nor|2001-06-27|ServletConfig.getInitParameter() requires url-patt| | 2478|Opn|Cri|2001-07-06|Passing Session variables between JSP's and Servle| | 4551|Opn|Nor|2001-10-31|Ctx( /tt01 ): IOException in: R( /tt01 + /com/abc/| | 4893|Unc|Blk|2001-11-15|Tomcat dies with following error..| | 4980|New|Min|2001-11-20|Startup message indicates incorrect log file | | 4994|New|Nor|2001-11-21|Tomcat needs a mechanism for clean and certain shu| | 5064|New|Cri|2001-11-25|Socket write error when include files is more than| | 5108|New|Maj|2001-11-26|Docs for Tomcat 3.2.x appear to be for Tomcat 3.3 | | 5137|New|Nor|2001-11-27|Null pointer in class loader after attempting to r| | 5160|Unc|Maj|2001-11-28|'IllegalStateException' | | 5331|New|Nor|2001-12-09|getPathInfo vs URL normalization | | 5510|New|Blk|2001-12-19|How to call ejb deployed in JBoss from Tomcat serv| | 5756|New|Nor|2002-01-08|jspc.bat exits with wrong ERRORLEVEL | | 5797|New|Nor|2002-01-10|UnCatched ? StringIndexOutOfBoundsException: Strin| | 6027|New|Maj|2002-01-25|Tomcat Automatically shuts down as service | | 6168|New|Blk|2002-02-01|IllegalStateException | | 6451|New|Cri|2002-02-14|Stackoverflow | | 6478|New|Enh|2002-02-14|Default Tomcat Encoding | | 6488|Ver|Maj|2002-02-15|Error: 304. Apparent bug in default ErrorHandler c| | 6648|New|Nor|2002-02-25|jakarta-servletapi build with java 1.4 javadoc err| | 6702|New|Cri|2002-02-27|win 2k services not working | | 6796|New|Cri|2002-03-01|Tomcat dies periodically | | 6989|New|Maj|2002-03-08|Unable to read tld file during parallel JSP compil| | 7008|Opn|Maj|2002-03-10|facade.HttpServletRequestFacade.getParameter(HttpS| | 7013|New|Cri|2002-03-10|Entering a servlet path with non-ISO8859-1 charact| | 7227|New|Nor|2002-03-19|error-code directive don't work | | 7236|New|Blk|2002-03-19|Permission denied to do thread.stop | | 7626|New|Nor|2002-03-29|classloader not working properly | | 7652|New|Cri|2002-04-01|Tomcat stalls periodically| | 7762|New|Enh|2002-04-05|stdout logfile handling | | 7785|New|Blk|2002-04-06|tomcat bug in context reloading | | 7789|New|Maj|2002-04-06|JSP Cookie Read/Write Fails With DNS Names| | 7863|New|Maj|2002-04-09|I have a problem when running Tomcat with IIS | | 8154|New|Nor|2002-04-16|logrotate script in RPM rotates non-existing file | | 8155|New|Nor|2002-04-16|Tomcat from RPM doesn't do logrotate | | 8187|New|Cri|2002-04-17|Errors when Tomcat used with MS Access database | | 8239|New|Cri|2002-04-18|Resource temporary unavailable| | 8263|New|Cri|2002-04-18|url-pattern easy to circumvent| | 8634|New|Nor|2002-04-30|no way to specify different modules.xml file | | 8992|New|Blk|2002-05-10|IE6/XP: Limitation of POST Area within HTTP reques| | 9086|New|Enh|2002-05-14|NPE org.apache.tomcat.core.ServerSession.setAttrib| | 9250|New|Maj|2002-05-20|outOfMemoryError | | 9362|New|Nor|2002-05-23|compiilation of JSP that includes a non-existant f| | 9367|New|Maj|2002-05-23|HttpSessionBindingEvent not thrown for HttpSession| | 9390|New|Nor|2002-05-24|jasper compilation error in tomcat| | 9480|New|Nor|2002-05-29|Data connection pooling | | 9607|New|Maj|2002-06-04|precompile JSP| | 9737|New|Nor|2002-06-10|ArrayIndexOutOfBoundsException when sending just p| |1|New|Cri|2002-06-19|IOException Broken Pipe when authenticating JDBCRe| |10039|New|Nor|2002-06-20|TimeStamp will not work correctly.|
Bug report for Watchdog [2003/09/07]
+---+ | Bugzilla Bug ID | | +-+ | | Status: UNC=Unconfirmed NEW=New ASS=Assigned| | | OPN=ReopenedVER=Verified(Skipped Closed/Resolved) | | | +-+ | | | Severity: BLK=Blocker CRI=CriticalMAJ=Major | | | | MIN=Minor NOR=Normal ENH=Enhancement | | | | +-+ | | | | Date Posted | | | | | +--+ | | | | | Description | | | | | | | | 278|Unc|Nor|2000-12-04|Bug in GetParameterValuesTestServlet.java file Bug| | 279|Unc|Nor|2000-12-04|Logical Error in GetParameterValuesTestServlet Bug| | 469|Unc|Nor|2001-01-17|in example-taglib.tld urn should be uri BugRat| | 470|Unc|Nor|2001-01-17|FAIL positiveForward.jsp and positiveInclude.jsp B| | 9634|New|Enh|2002-06-05|No tests exist for ServletContext.getResourcePaths| |10703|New|Enh|2002-07-11|Need to test getRequestURI after RequestDispatcher| |11336|New|Enh|2002-07-31|Test wrapped path methods with RD.foward()| |11663|New|Maj|2002-08-13|JSP precompile tests rely on Jasper specific behav| |11664|New|Maj|2002-08-13|A sweep is needed of all Watchdog 4.0 tag librarie| |11665|New|Maj|2002-08-13|ServletToJSPErrorPageTest and ServletToServletErro| |11666|New|Maj|2002-08-13|SetBufferSize_1TestServlet is invalid.| |14004|New|Maj|2002-10-28|Incorrent behaviour of all attribute-related lifec| |15504|New|Nor|2002-12-18|JSP positiveGetValues test relies on order preserv| +-+---+---+--+--+ | Total 13 bugs | +---+ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Bug 22666
Mark Thomas wrote: On Sunday, September 07, 2003 8:47 AM, Remy Maucherat [SMTP:[EMAIL PROTECTED] wrote: Remy Maucherat wrote: I've just committed a very simple implementation of this (without the extra queryStringEncoding field, although this is not hard to add). Comments ? Remy Thanks for your help with this. I have run through a simple UTF-8 test case and the problem as reported in bug 22666 is still present. I have tracked down what I believe to be the root cause to another part of the Parameters class. I have developed a patch for TC-5 below. I also think that the re-written try block in your patch for the Parameters class can be reverted as it doesn't appear to have any affect for UTF-8 query parameters. The idea is that it would work if the type of the MB is chars (see processParameters(MB)). So that's why handleQueryParameters attempts to convert the URI to chars. I have reviewed the code, and for some reason which eludes me, toChars didn't set the MB type to chars. So the problem is with MessageBytes, and I have added the missing code. There are a few things which are weird in those buffer classes. Probably a cleanup will be needed, but later, as this will undoubtedly cause regressions. Remy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote Request.java
remm2003/09/07 11:03:21
Modified:coyote/src/java/org/apache/coyote Request.java
Log:
- Make the update of the stats an explicit call (I believe it is valid to call
recycle multiple times, and it is hard to avoid with HTTP keepalive).
Revision ChangesPath
1.23 +5 -3
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Request.java
Index: Request.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/Request.java,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -r1.22 -r1.23
--- Request.java 5 Jun 2003 19:46:49 - 1.22
+++ Request.java 7 Sep 2003 18:03:21 - 1.23
@@ -195,7 +195,7 @@
private int bytesRead=0;
// Time of the request - usefull to avoid repeated calls to System.currentTime
-private long startTime;
+private long startTime = 0L;
private RequestInfo reqProcessorMX=new RequestInfo(this);
// - Properties
@@ -494,8 +494,6 @@
public void recycle() {
-// Call RequestProcessorMX
-reqProcessorMX.updateCounters();
bytesRead=0;
contentLength = -1;
@@ -533,6 +531,10 @@
}
// Info
+public void updateCounters() {
+reqProcessorMX.updateCounters();
+}
+
public RequestInfo getRequestProcessor() {
return reqProcessorMX;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java
remm2003/09/07 11:04:58
Modified:http11/src/java/org/apache/coyote/http11
Http11Processor.java
Log:
- Make the update of the stats an explicit call (I believe it is valid to call
recycle multiple times, and it is hard to avoid with HTTP keepalive).
- Decrease the timeout reduction ratio.
- Add a setStatus so an error is counted.
Revision ChangesPath
1.77 +12 -3
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
Index: Http11Processor.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java,v
retrieving revision 1.76
retrieving revision 1.77
diff -u -r1.76 -r1.77
--- Http11Processor.java 30 Aug 2003 02:38:06 - 1.76
+++ Http11Processor.java 7 Sep 2003 18:04:58 - 1.77
@@ -595,13 +595,15 @@
if ((threadRatio 0.33) (threadRatio = 0.66)) {
soTimeout = soTimeout / 2;
} else if (threadRatio 0.66) {
-soTimeout = soTimeout / 5;
+soTimeout = soTimeout / 3;
keepAliveLeft = 1;
}
boolean keptAlive = false;
while (started !error keepAlive) {
+
+// Parsing the request header
try {
if( !disableUploadTimeout keptAlive soTimeout 0 ) {
socket.setSoTimeout(soTimeout);
@@ -617,8 +619,8 @@
} catch (IOException e) {
error = true;
break;
-} catch (Exception e) {
-log.debug(Error parsing HTTP request, e);
+} catch (Throwable t) {
+log.debug(Error parsing HTTP request, t);
// 400 - Bad Request
response.setStatus(400);
error = true;
@@ -688,6 +690,13 @@
log.error(Error finishing response, t);
error = true;
}
+
+// If there was an error, make sure the request is counted as
+// and error, and update the statistics counter
+if (error) {
+response.setStatus(500);
+}
+request.updateCounters();
thrA.setCurrentStage(threadPool, ended);
rp.setStage(org.apache.coyote.Constants.STAGE_KEEPALIVE);
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/server JkCoyoteHandler.java
remm2003/09/07 11:05:15 Modified:jk/java/org/apache/jk/server JkCoyoteHandler.java Log: - Make the update of the stats an explicit call (I believe it is valid to call recycle multiple times, and it is hard to avoid with HTTP keepalive). Revision ChangesPath 1.44 +1 -0 jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkCoyoteHandler.java Index: JkCoyoteHandler.java === RCS file: /home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/server/JkCoyoteHandler.java,v retrieving revision 1.43 retrieving revision 1.44 diff -u -r1.43 -r1.44 --- JkCoyoteHandler.java 2 Sep 2003 00:17:40 - 1.43 +++ JkCoyoteHandler.java 7 Sep 2003 18:05:15 - 1.44 @@ -306,6 +306,7 @@ ep.setStatus( JK_STATUS_NEW ); req.recycle(); +req.updateCounters(); res.recycle(); return OK; } - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager Constants.java HTMLManagerServlet.java ManagerServlet.java StatusTransformer.java
remm2003/09/07 11:47:14 Modified:webapps/manager/WEB-INF/classes/org/apache/catalina/manager Constants.java HTMLManagerServlet.java ManagerServlet.java StatusTransformer.java Log: - Bug 22956: Use UTF8 encoding. - Submitted by Takashi Okamoto Revision ChangesPath 1.8 +5 -4 jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/Constants.java Index: Constants.java === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/Constants.java,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- Constants.java4 Sep 2003 14:39:21 - 1.7 +++ Constants.java7 Sep 2003 18:47:14 - 1.8 @@ -237,9 +237,10 @@ \n + /body\n + /html; +public static final String CHARSET=utf-8; public static final String XML_DECLARATION = -?xml version=\1.0\?; +?xml version=\1.0\ encoding=\+CHARSET+\?; public static final String XML_STYLE = ?xml-stylesheet type=\text/xsl\ href=\xform.xsl\ ?; 1.8 +6 -13 jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/HTMLManagerServlet.java Index: HTMLManagerServlet.java === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/HTMLManagerServlet.java,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- HTMLManagerServlet.java 28 Jul 2003 14:57:47 - 1.7 +++ HTMLManagerServlet.java 7 Sep 2003 18:47:14 - 1.8 @@ -74,7 +74,6 @@ import java.util.Date; import java.util.Iterator; import java.util.List; -import java.util.Locale; import java.util.Map; import java.util.TreeMap; import javax.servlet.ServletException; @@ -136,10 +135,7 @@ String deployWar = request.getParameter(deployWar); // Prepare our output writer to generate the response message -Locale locale = Locale.getDefault(); -String charset = context.getCharsetMapper().getCharset(locale); -response.setLocale(locale); -response.setContentType(text/html; charset= + charset); +response.setContentType(text/html; charset= + Constants.CHARSET); String message = ; // Process the requested command @@ -187,10 +183,7 @@ } // Prepare our output writer to generate the response message -Locale locale = Locale.getDefault(); -String charset = context.getCharsetMapper().getCharset(locale); -response.setLocale(locale); -response.setContentType(text/html; charset= + charset); +response.setContentType(text/html; charset= + Constants.CHARSET); String message = ; 1.9 +6 -12 jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/ManagerServlet.java Index: ManagerServlet.java === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/manager/WEB-INF/classes/org/apache/catalina/manager/ManagerServlet.java,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- ManagerServlet.java 6 Aug 2003 18:21:32 - 1.8 +++ ManagerServlet.java 7 Sep 2003 18:47:14 - 1.9 @@ -76,7 +76,6 @@ import java.net.MalformedURLException; import java.util.Enumeration; import java.util.Iterator; -import java.util.Locale; import java.util.jar.JarEntry; import java.util.jar.JarFile; import javax.naming.Binding; @@ -357,10 +356,7 @@ } // Prepare our output writer to generate the response message -Locale locale = Locale.getDefault(); -String charset = context.getCharsetMapper().getCharset(locale); -response.setLocale(locale); -response.setContentType(text/plain; charset= + charset); +response.setContentType(text/plain; charset= + Constants.CHARSET); PrintWriter writer = response.getWriter(); // Process the requested command (note - /deploy is not listed here) @@ -439,9 +435,7 @@ } // Prepare our output writer to generate the response message -response.setContentType(text/plain); -Locale locale = Locale.getDefault(); -response.setLocale(locale); +response.setContentType(text/plain;charset=+Constants.CHARSET); PrintWriter writer = response.getWriter(); // Process the requested command 1.3 +6 -6
DO NOT REPLY [Bug 22956] - Manager webapp can't treat encvoding correctly
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=22956. 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=22956 Manager webapp can't treat encvoding correctly [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-09-07 18:50 --- I have applied your patch. Thanks :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22961] - WebAppClassLoader tries to load class from system classloader twice
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=22961. 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=22961 WebAppClassLoader tries to load class from system classloader twice [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2003-09-07 19:01 --- Nice optimization. The patch seems ok, but there's no need for it, as Bill said. Thanks anyway. Even in embedded mode, there's a need for a parent classloader which holds the Catalina classes. Of course, you could choose to put everything in the classpath, but that would be quite crazy (and I'm not completely certain it works) ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 22848] - [PATCH] Fix typos/grammar in changelog.html
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=22848. 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=22848 [PATCH] Fix typos/grammar in changelog.html [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2003-09-07 19:11 --- Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
remm2003/09/07 12:05:46 Modified:webapps/docs changelog.xml Log: - Fix typos, submitted by Yann Cébron. Revision ChangesPath 1.19 +4 -4 jakarta-tomcat-catalina/webapps/docs/changelog.xml Index: changelog.xml === RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v retrieving revision 1.18 retrieving revision 1.19 diff -u -r1.18 -r1.19 --- changelog.xml 5 Sep 2003 13:03:57 - 1.18 +++ changelog.xml 7 Sep 2003 19:05:46 - 1.19 @@ -98,7 +98,7 @@ NPE in toString after stop (remm) /fix fix - Avoid references leak: ckean up and recycle all thread local resources, + Avoid references leak: clean up and recycle all thread local resources, and reset the context CL after invoking the pipeline (remm) /fix fix @@ -116,14 +116,14 @@ /fix fix Don't save the config file attribute, as it is always useless, and don't - indent context confug files (remm) + indent context config files (remm) /fix update Allow overriding the Host's unpackWARs using a new unpackWAR attribute on the Context element (remm) /update fix - Include the patInfo when a relative path is used to get a request + Include the pathInfo when a relative path is used to get a request dispatcher, submitted by Mark Thomas (remm) /fix fix @@ -220,7 +220,7 @@ to TagLibraryValidator.validate() match the above (luehe) /fix fix - When precompiling with JSPC, files that mathch the url-pattern specified + When precompiling with JSPC, files that match the url-pattern specified in jsp-config should be included for compilation (kinman) /fix update - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
jakarta-tomcat-connectors/util build broke for j2sdk 1.3
I can no longer build jakarta-tomcat-connectors/util. It looks like a dependency for java 1.4 has crept in with how jsse is being used. Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jakarta-tomcat-connectors/util build broke for j2sdk 1.3
It works fine for me. I just did an update on j-t-c, and a clean build of Tomcat 5, and it worked fine (well, up until it got to the docs, but I've still got an old version of xalan in ant :). - Original Message - From: Glenn Nielsen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, September 07, 2003 7:59 PM Subject: jakarta-tomcat-connectors/util build broke for j2sdk 1.3 I can no longer build jakarta-tomcat-connectors/util. It looks like a dependency for java 1.4 has crept in with how jsse is being used. Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util build.xml
glenn 2003/09/07 20:29:18 Modified:util build.xml Log: Fix the build for jdk 1.3 Revision ChangesPath 1.26 +1 -0 jakarta-tomcat-connectors/util/build.xml Index: build.xml === RCS file: /home/cvs/jakarta-tomcat-connectors/util/build.xml,v retrieving revision 1.25 retrieving revision 1.26 diff -u -r1.25 -r1.26 --- build.xml 14 Jul 2003 16:28:19 - 1.25 +++ build.xml 8 Sep 2003 03:29:18 - 1.26 @@ -73,6 +73,7 @@ exclude name=**/util/threads/ThreadPoolMX* unless=modeler.present/ exclude name=**/util/compat/Jdk14Compat.java unless=jdk1.4.present / exclude name=**/util/net/jsse/JSSE14* unless=jdk1.4.present / +exclude name=**/util/net/jsse/JSSEKeyManager.java unless=jdk1.4.present / /javac !-- Copy static resource files -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jakarta-tomcat-connectors/util build broke for j2sdk 1.3
You had to be using jsse rather than PureTLS and building with jdk 1.4. It is fixed now. A new JSSE class was added for JDK1.4 support but it wasn't excluded from the build if jdk1.4 wasn't present. Glenn Bill Barker wrote: It works fine for me. I just did an update on j-t-c, and a clean build of Tomcat 5, and it worked fine (well, up until it got to the docs, but I've still got an old version of xalan in ant :). - Original Message - From: Glenn Nielsen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Sunday, September 07, 2003 7:59 PM Subject: jakarta-tomcat-connectors/util build broke for j2sdk 1.3 I can no longer build jakarta-tomcat-connectors/util. It looks like a dependency for java 1.4 has crept in with how jsse is being used. Glenn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments. In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
