RE: [4.1.9] New test milestone released
There is a bug in 4.1.9 (a Jasper bug) that breaks my
application completely.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11552
We use custom tags that do iteration (they implement IterationTag)
but do not modify their content so they do not implement BodyTag.
The latest versions of Jasper2 generates code which only synchronizes
script variables before the first iteration of the tag. (ie before the do {}
while() loop).
There is also another bug whereby if a BodyTag returns EVAL_BODY_INCLUDE,
the script variables will not be synchronized at ALL for the first
iteration.
The problem is in org.apache.jasper.Generator.java. The generated code
for a tag that implements IterationTag synchronizes variables before the tag
loop but not inside it (even for NESTED scoped variables).
Also for BodyTags that return EVAL_BODY_INCLUDE, the synchronization
for the first iteration is skipped completely because it gets placed
together
in the same block of code that sets up the BodyContent buffer and that gets
skipped on EVAL_BODY_INCLUDE.
I have submitted some patches that move the variable synchronization into
the body of the loop for IterationTags and BodyTags. I think this should fix
the
problem but I haven't got round to setting up a build environment yet.
(sorry).
Doing that now.
If someone could take a look at this it would be much appreciated.
Thanks.
-Original Message-
From: Remy Maucherat [mailto:[EMAIL PROTECTED]]
Sent: Sunday, August 11, 2002 1:21 AM
To: Tomcat Developers List; Tomcat Users List
Subject: [4.1.9] New test milestone released
A new test milestone of Tomcat 4.1 has just been released.
Downloads:
http://jakarta.apache.org/builds/jakarta-tomcat-4.0/test/v4.1.9/
Significant changes over 4.1.8 Beta include:
- Jasper 2 bugfixes
- Catalina classloader bugfixes
- Coyote HTTP/1.1 fixes
- Updated commons-dbcp connection pool
The list of changes is available in the release notes.
Remy
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11117] - Coyote connector does not correctly deal with large PUT when using chunked transfer encoding
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=7.
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=7
Coyote connector does not correctly deal with large PUT when using chunked transfer
encoding
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |
--- Additional Comments From [EMAIL PROTECTED] 2002-08-12 07:34 ---
Oh dear. Turns out there's another very closely related case which can be
triggered (but on my development machine, it never is - others have reported
this to me) in very rare circumstances. I changed the logic to compute the
length of the chunk as we read the chunk header, rather than first determining
the chunk header length, then computing it after the entire header has been
read. This is neccesary because it's possible (if unlikely - so it gets
triggered rarely) for the buffer to be re-filled (with new data) in between
this, so the length computation fails.
Here's the patch:
Index: src/java/org/apache/coyote/http11/filters/ChunkedInputFilter.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/filters/ChunkedInputFilter.java,v
retrieving revision 1.6
diff -u -r1.6 ChunkedInputFilter.java
--- src/java/org/apache/coyote/http11/filters/ChunkedInputFilter.java 8 Aug
2002 02:55:35 - 1.6
+++ src/java/org/apache/coyote/http11/filters/ChunkedInputFilter.java 12 Aug
2002 03:12:24 -
@@ -283,8 +283,6 @@
int result = 0;
boolean eol = false;
-int begin = pos;
-int end = begin;
boolean readDigit = false;
while (!eol) {
@@ -299,11 +297,9 @@
eol = true;
} else {
if (HexUtils.DEC[buf[pos]] != -1) {
-if (!readDigit) {
-readDigit = true;
-begin = pos;
-}
-end = pos;
+readDigit = true;
+result *=16;
+result += HexUtils.DEC[buf[pos]];
}
}
@@ -313,15 +309,6 @@
if (!readDigit)
return false;
-
-int offset = 1;
-for (int i = end; i = begin; i--) {
-int val = HexUtils.DEC[buf[i]];
-if (val == -1)
-return false;
-result = result + val * offset;
-offset = offset * 16;
-}
if (result == 0)
endChunk = true;
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11628] New: - web.xml parsing depends on order of appearance
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=11628. 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=11628 web.xml parsing depends on order of appearance Summary: web.xml parsing depends on order of appearance Product: Tomcat 4 Version: 4.1.8 Platform: PC OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] The web.xml file of the Web-Application is not parsed correctly. It depends on the order of the tags. If you have: servlet ...App1 /servlet servlet-mapping ...App1 /servlet-mapping servlet ...App2 /servlet servlet-mapping ...App2 /servlet-mapping Catalina will complain about the second servlet tag. If you have servlet ...App1 /servlet servlet ...App2 /servlet servlet-mapping ...App1 /servlet-mapping servlet-mapping ...App2 /servlet-mapping everything is parsed without complains. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11628] - web.xml parsing depends on order of appearance
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=11628. 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=11628 web.xml parsing depends on order of appearance [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-08-12 10:49 --- The order of the elements is mandated by the DTD. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11619] - Environment entries cause HTTP 500
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=11619. 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=11619 Environment entries cause HTTP 500 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Additional Comments From [EMAIL PROTECTED] 2002-08-12 10:55 --- The examples webapp (try the naming servlet) proves this works fine. Note: When filing a bug, please make it possible to reproduce it. Thanks. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11117] - Coyote connector does not correctly deal with large PUT when using chunked transfer encoding
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=7. 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=7 Coyote connector does not correctly deal with large PUT when using chunked transfer encoding --- Additional Comments From [EMAIL PROTECTED] 2002-08-12 11:02 --- I don't see any reason not to compute the chunk length on the fly, and that makes the algorithm simpler. Sorry for not doing that in the first place ... Bill, can you apply the patch if it looks good to you ? (I would only be able to commit it tomorrow) -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Question about Session in Tomcat 3.3
As I tested, when context reloads in Tomcat 3.3.1, e.g. caused by modification of servlet class, sessions are lost. Is it true for all Tomcat 3.3.x? Is there any switch in source code which can change this behavior and maintain sessions through context reloading? Thanks for your help. Hugh __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HttpSession and CTRL-N / File new window
Launch a new IE from OS, but not a new IE window from current IE. --- John Trollinger [EMAIL PROTECTED] wrote: I have noticed that in IE if you do a CTRL-N to bring up a new window in IE it will have the same session as the currently opened window. Is there anyway around this.. or a way to create a new session in the second window. Thanks, John -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: HttpSession and CTRL-N / File new window
And how do I force all the users of my application to do this? -Original Message- From: Hugh J. L. [mailto:[EMAIL PROTECTED]] Sent: Monday, August 12, 2002 8:23 AM To: Tomcat Developers List Subject: Re: HttpSession and CTRL-N / File new window Launch a new IE from OS, but not a new IE window from current IE. --- John Trollinger [EMAIL PROTECTED] wrote: I have noticed that in IE if you do a CTRL-N to bring up a new window in IE it will have the same session as the currently opened window. Is there anyway around this.. or a way to create a new session in the second window. Thanks, John -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Question about Session in Tomcat 3.3 -- continued...
I changed switch fullReload in ReloadInterceptor from true to false, and sessions are maintained through context reloading. (Of course, because the old context remains.) Is there any disadvantage if I set this way? Anyway fullReload=true is default setting. Thanks. Hugh __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11628] - web.xml parsing depends on order of appearance
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=11628. 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=11628 web.xml parsing depends on order of appearance --- Additional Comments From [EMAIL PROTECTED] 2002-08-12 13:13 --- This is not a bug! And the DTD *is* being parsed correctly.The ordering restriction you are running into is a normal result of using a Document Type Definition to validate an XML document. The DTD is provided by the Servlet Specification and we cannot change it, even if there were a reasonable alternative while still using a DTD. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH] improve internationalization for admin tool
Hi tomcat, (especially amy)
This is the second patch to internationalize the admin tools. First
patch was commited by amy. New patch will improve at following point:
+ store file with utf-8 encoding and add encoding='utf-8' at
xml header.
+ use filter servlet to decode post and get parameters.
(you have to include SetCharacterEncodingFilter in admin web
application with this patch)
Could you apply this patch?
regards,
Takashi Okamoto
diff -uNr
orig/jakarta-tomcat-4.1.8-src/catalina/src/share/org/apache/catalina/core/StandardServer.java
jakarta-tomcat-4.1.8-src/catalina/src/share/org/apache/catalina/core/StandardServer.java
---
orig/jakarta-tomcat-4.1.8-src/catalina/src/share/org/apache/catalina/core/StandardServer.java
Wed Jul 24 00:06:44 2002
+++
+jakarta-tomcat-4.1.8-src/catalina/src/share/org/apache/catalina/core/StandardServer.java
+Sun Aug 4 00:18:37 2002
@@ -71,6 +71,8 @@
import java.beans.PropertyDescriptor;
import java.io.File;
import java.io.FileWriter;
+import java.io.FileOutputStream;
+import java.io.OutputStreamWriter;
import java.io.InputStream;
import java.io.IOException;
import java.io.PrintWriter;
@@ -742,7 +744,7 @@
// Open an output writer for the new configuration file
PrintWriter writer = null;
try {
-writer = new PrintWriter(new FileWriter(configNew));
+writer = new PrintWriter(new OutputStreamWriter(new
+FileOutputStream(configNew), UTF8));
} catch (IOException e) {
if (writer != null) {
try {
@@ -1916,6 +1918,7 @@
Server server) throws Exception {
// Store the beginning of this element
+writer.println(?xml version='1.0' encoding='utf-8'?);
for (int i = 0; i indent; i++) {
writer.print(' ');
}
diff -uNr
orig/jakarta-tomcat-4.1.8-src/catalina/src/share/org/apache/catalina/users/MemoryUserDatabase.java
jakarta-tomcat-4.1.8-src/catalina/src/share/org/apache/catalina/users/MemoryUserDatabase.java
---
orig/jakarta-tomcat-4.1.8-src/catalina/src/share/org/apache/catalina/users/MemoryUserDatabase.java
Wed Jul 24 00:06:44 2002
+++
+jakarta-tomcat-4.1.8-src/catalina/src/share/org/apache/catalina/users/MemoryUserDatabase.java
+ Sun Aug 4 01:09:29 2002
@@ -506,11 +506,11 @@
// Configure our PrintWriter
FileOutputStream fos = new FileOutputStream(fileNew);
-OutputStreamWriter osw = new OutputStreamWriter(fos);
+OutputStreamWriter osw = new OutputStreamWriter(fos, UTF8);
writer = new PrintWriter(osw);
// Print the file prolog
-writer.println(?xml version='1.0'?);
+writer.println(?xml version='1.0' encoding='utf-8'?);
writer.println(tomcat-users);
// Print entries for each defined role, group, and user
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] improve internationalization for admin tool
From: Takashi Okamoto [EMAIL PROTECTED]
Subject: [PATCH] improve internationalization for admin tool
Date: Mon, 12 Aug 2002 22:14:20 +0900 (JST)
This is the second patch to internationalize the admin tools. First
patch was commited by amy. New patch will improve at following point:
.. snip ...
Could you apply this patch?
Oops, I posted wrong patch. Please ignore previous mail. The patch
which is attached this mail is right.
regards,
Takashi Okamoto
? webapps/admin/WEB-INF/classes/filters
Index: catalina/src/share/org/apache/catalina/core/StandardServer.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardServer.java,v
retrieving revision 1.30
diff -u -r1.30 StandardServer.java
--- catalina/src/share/org/apache/catalina/core/StandardServer.java 10 Jul 2002
09:49:01 - 1.30
+++ catalina/src/share/org/apache/catalina/core/StandardServer.java 12 Aug 2002
+12:32:15 -
@@ -71,6 +71,8 @@
import java.beans.PropertyDescriptor;
import java.io.File;
import java.io.FileWriter;
+import java.io.FileOutputStream;
+import java.io.OutputStreamWriter;
import java.io.InputStream;
import java.io.IOException;
import java.io.PrintWriter;
@@ -742,7 +744,7 @@
// Open an output writer for the new configuration file
PrintWriter writer = null;
try {
-writer = new PrintWriter(new FileWriter(configNew));
+writer = new PrintWriter(new OutputStreamWriter(new
+FileOutputStream(configNew), UTF8));
} catch (IOException e) {
if (writer != null) {
try {
@@ -1916,6 +1918,7 @@
Server server) throws Exception {
// Store the beginning of this element
+writer.println(?xml version='1.0' encoding='utf-8'?);
for (int i = 0; i indent; i++) {
writer.print(' ');
}
Index: catalina/src/share/org/apache/catalina/users/MemoryUserDatabase.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/users/MemoryUserDatabase.java,v
retrieving revision 1.6
diff -u -r1.6 MemoryUserDatabase.java
--- catalina/src/share/org/apache/catalina/users/MemoryUserDatabase.java10 Feb
2002 03:20:17 - 1.6
+++ catalina/src/share/org/apache/catalina/users/MemoryUserDatabase.java12 Aug
+2002 12:32:15 -
@@ -506,11 +506,11 @@
// Configure our PrintWriter
FileOutputStream fos = new FileOutputStream(fileNew);
-OutputStreamWriter osw = new OutputStreamWriter(fos);
+OutputStreamWriter osw = new OutputStreamWriter(fos, UTF8);
writer = new PrintWriter(osw);
// Print the file prolog
-writer.println(?xml version='1.0'?);
+writer.println(?xml version='1.0' encoding='utf-8'?);
writer.println(tomcat-users);
// Print entries for each defined role, group, and user
Index: webapps/admin/WEB-INF/web.xml
===
RCS file: /home/cvspublic/jakarta-tomcat-4.0/webapps/admin/WEB-INF/web.xml,v
retrieving revision 1.13
diff -u -r1.13 web.xml
--- webapps/admin/WEB-INF/web.xml 13 Jun 2002 23:43:03 - 1.13
+++ webapps/admin/WEB-INF/web.xml 12 Aug 2002 12:32:16 -
@@ -11,6 +11,25 @@
Tomcat HTML based administration web application.
/description
+ !-- Example filter to set character encoding on each request --
+ filter
+filter-nameSet Character Encoding/filter-name
+filter-classfilters.SetCharacterEncodingFilter/filter-class
+init-param
+ param-nameencoding/param-name
+ param-valueUTF8/param-value
+/init-param
+ /filter
+
+
+ !-- Example filter mapping to apply the Set Character Encoding filter
+ to *all* requests processed by this web application --
+ filter-mapping
+filter-nameSet Character Encoding/filter-name
+url-pattern/*/url-pattern
+ /filter-mapping
+
+
!-- Action Servlet Configuration --
servlet
servlet-nameaction/servlet-name
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Build notes
Patrick Luby wrote: Costin, [EMAIL PROTECTED] wrote: On Sun, 11 Aug 2002, Patrick Luby wrote: commons-digester/logging, etc. I think that this would make the build more reliable since Tomcat 5 is dependent on very specific versions of Apache dependencies (e.g. Xerces 2.0.1 only). IMHO that's _totally_ unacceptable ( having tomcat5 work only with xerces). I think that the dependency on Xerces 2.0.1 is excessively restrictive as well. IIRC (maybe Jean-François could provide some of the details he found?), Xerces 2.0.1 was the only Xerces parser that we have found so far that does not throw StackOverflow or other fatal exceptions when an XML file using XML schema is parsed. I believe (Jean-François: let me know if my understanding is incorrect) that this problem exists even if schema validation is turned off. The StackOverflowException _only_ occurs with released version of Xerces 2.0.2. It has been fixed since the release (nightly build works fine). Yes the problem exist even if the schema validation is on. And having schema validation turned on by default has a strong -1 from me - if the spec _requires_ schema validation, then implement it at deployment time. The performance hit is just unacceptable. Any performance increases through delayed validation sounds good to me. I agree. What behaviour do we want if a xml instance is not well-formed? ( in the process we should also move DTD validation to the same stage and stop doing it on every startup if the xml file didn't change ) Makes sense. Especially since we use this same technique for JSP page compilation. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HttpSession and CTRL-N / File new window
On August 12, 2002 08:32 am, you wrote: And how do I force all the users of my application to do this? Use Netscape :-) And please move usage questions to [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Build notes
[EMAIL PROTECTED] wrote: On Sun, 11 Aug 2002, Bill Barker wrote: I don't know anybody that likes it, but it's required by the JSP-1.2 spec (and still in the current draft of the JSP-2.0 spec). The TLDs may contain Listeners, and the only way to get them registered is to scan at startup. Ops, I missed that one. So you mean even if a webapp has no JSP at all - the TLDs are still processed ( sort of extension to web.xml ) ? I allways tought they are for translation, not runtime. Yes, they are. The spec defines many ways to define some things (not a very good idea IMO), like it has many places where you can put the TLD. I just downloaded the new servlet draft - and it seems the welcome file it defines is still unimplementable and violates all the current practices... I've been saying that for a while in a few messages if you look at the archives. I've been emailing the spec people while I was working at Sun, but I have been politely ignored on that issue :-( Oh well, if it's not implementable, then we won't implement it ;-) I'll make a proposal soon (let's say by wed) to rewrite the mapper, and it will partially handle the new spec requirements. I'm beginning to wonder who is Apache's representative to the JCP and how will he make the decision on what to vote... Jason maybe ? Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Build notes
[EMAIL PROTECTED] wrote: On Sun, 11 Aug 2002, Patrick Luby wrote: commons-digester/logging, etc. I think that this would make the build more reliable since Tomcat 5 is dependent on very specific versions of Apache dependencies (e.g. Xerces 2.0.1 only). IMHO that's _totally_ unacceptable ( having tomcat5 work only with xerces). And having schema validation turned on by default has a strong -1 from me - if the spec _requires_ schema validation, then implement it at deployment time. The performance hit is just unacceptable. I agree with Costin. Startup time of TC 4.1 was bad, 5.0 is unbearable. I now agree with the hacks Costin put in 3.3 ;-) We need that or an option to disable validation. ( in the process we should also move DTD validation to the same stage and stop doing it on every startup if the xml file didn't change ) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: HttpSession and CTRL-N / File new window
Sorry, I hit the wrong to in address book.. just noticed that :-) -Original Message- From: Ian Darwin [mailto:[EMAIL PROTECTED]] Sent: Monday, August 12, 2002 10:23 AM To: Tomcat Developers List Subject: Re: HttpSession and CTRL-N / File new window On August 12, 2002 08:32 am, you wrote: And how do I force all the users of my application to do this? Use Netscape :-) And please move usage questions to [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/filters ChunkedInputFilter.java
remm2002/08/12 07:34:10
Modified:http11/src/java/org/apache/coyote/http11/filters
ChunkedInputFilter.java
Log:
- Fix a derivative of bug 7.
- The buffer could be refilled while reading the chunk header. Also, this
simplifies the algorithm.
- Patch submitted by Michael Smith msmith at ns.xn.com.au
Revision ChangesPath
1.7 +3 -16
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/filters/ChunkedInputFilter.java
Index: ChunkedInputFilter.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/filters/ChunkedInputFilter.java,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- ChunkedInputFilter.java 8 Aug 2002 02:55:35 - 1.6
+++ ChunkedInputFilter.java 12 Aug 2002 14:34:10 - 1.7
@@ -283,8 +283,6 @@
int result = 0;
boolean eol = false;
-int begin = pos;
-int end = begin;
boolean readDigit = false;
while (!eol) {
@@ -299,11 +297,9 @@
eol = true;
} else {
if (HexUtils.DEC[buf[pos]] != -1) {
-if (!readDigit) {
-readDigit = true;
-begin = pos;
-}
-end = pos;
+readDigit = true;
+result *= 16;
+result += HexUtils.DEC[buf[pos]];
}
}
@@ -313,15 +309,6 @@
if (!readDigit)
return false;
-
-int offset = 1;
-for (int i = end; i = begin; i--) {
-int val = HexUtils.DEC[buf[i]];
-if (val == -1)
-return false;
-result = result + val * offset;
-offset = offset * 16;
-}
if (result == 0)
endChunk = true;
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11632] New: - java.net.BindException: The socket name is already in use.
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=11632. 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=11632 java.net.BindException: The socket name is already in use. Summary: java.net.BindException: The socket name is already in use. Product: Tomcat 4 Version: 4.0.4 Final Platform: Other OS/Version: AIX Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Hi everyone, I am turning to you because i belive that you can help me solve this problem. I have tried newsletter with no success. So, this is my story: I just did a fresh installation of Jakarta 4.0.3 and Jakarta 4.0.4 on a test machine. It is a basic installation with no modification in the configuration files. When i try to start Tomcat, i get the same message on both version, which is: java.net.BindException: The socket name is already in use. I have Tomcat Version 3.2.4 setup and this on is working fine. I also tried the Tomcat Version 4.1.7. It is running good, I can access the Manager Section but not the Administration section. (A other story) With the following, can anyone tell me how to solve this problem. Thank you in advance, Simon Lessard Note: I know there is no process listening on port 8080 and 8007 (see netstat -a command I also used lsof to find out and nothing in there also. = Computer setup: Computer:IBM 7044 170 RS6000 OS: AIX 4.3.3 Maint Level: 10 JDK: IBM Version 1.3.1 = = = = = = = = = = = = = = = = = = = = = = = = = Command used to start Tomcat wbmaster@ibm44p(/db04/tomcat_404/bin)# ps -ef | grep java wbmaster 20142 18556 0 16:10:13 pts/1 0:00 grep java wbmaster@ibm44p(/db04/tomcat_404/bin)# grep 8080 /etc/services # java_wbsrv8080/tcp# Java Web Server # java_wbsrv8080/udp# Java Web Server wbmaster@ibm44p(/db04/tomcat_404/bin)# grep 8007 /etc/services # javahndl 8007/tcp# Java Connection Handler # javahndl 8007/udp# Java Connection Handler wbmaster@ibm44p(/db04/tomcat_404/bin)# netstat -a | grep 8080 wbmaster@ibm44p(/db04/tomcat_404/bin)# netstat -a | grep 8007 wbmaster@ibm44p(/db04/tomcat_404/bin)# startup.sh Using CATALINA_BASE: /db04/tomcat_404 Using CATALINA_HOME: /db04/tomcat_404 Using CATALINA_TMPDIR: /db04/tomcat_404/temp Using JAVA_HOME: /usr/java131 wbmaster@ibm44p(/db04/tomcat_404/bin)# cd ../logs wbmaster@ibm44p(/db04/tomcat_404/logs)# ls -l total 32 -rw-r--r-- 1 wbmaster wbmaster2164 Aug 08 16:11 catalina.out -rw-r--r-- 1 wbmaster wbmaster 725 Aug 08 16:11 catalina_log.2002-08-08.tx t -rw-r--r-- 1 wbmaster wbmaster 0 Aug 08 16:11 localhost_access_log.2002- 08-08.txt -rw-r--r-- 1 wbmaster wbmaster1150 Aug 08 16:11 localhost_examples_log.200 2-08-08.txt -rw-r--r-- 1 wbmaster wbmaster3372 Aug 08 16:11 localhost_log.2002-08-08.t xt wbmaster@ibm44p(/db04/tomcat_404/logs)# cat catalina.out Starting service Tomcat-Standalone Apache Tomcat/4.0.4 java.net.BindException: The socket name is already in use. at java.net.PlainSocketImpl.socketBind(Native Method) at java.net.PlainSocketImpl.bind(PlainSocketImpl.java:430) at java.net.ServerSocket.init(ServerSocket.java:191) at java.net.ServerSocket.init(ServerSocket.java:142) at org.apache.catalina.net.DefaultServerSocketFactory.createSocket(Defau ltServerSocketFactory.java:118) at org.apache.ajp.tomcat4.Ajp13Connector.open(Ajp13Connector.java:797) at org.apache.ajp.tomcat4.Ajp13Connector.start(Ajp13Connector.java:1013) at org.apache.catalina.core.StandardService.start(StandardService.java:3 95) at org.apache.catalina.core.StandardServer.start(StandardServer.java:506 ) at org.apache.catalina.startup.Catalina.start(Catalina.java:781) at org.apache.catalina.startup.Catalina.execute(Catalina.java:681) at org.apache.catalina.startup.Catalina.process(Catalina.java:179) at java.lang.reflect.Method.invoke(Native Method) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:243) java.lang.NullPointerException at org.apache.ajp.tomcat4.Ajp13Connector.run(Ajp13Connector.java:841) at java.lang.Thread.run(Thread.java:512) java.lang.IllegalThreadStateException at java.lang.ThreadGroup.add(ThreadGroup.java:814) at java.lang.Thread.init(Thread.java:307) at java.lang.Thread.init(Thread.java:477) at
DO NOT REPLY [Bug 11307] - Deadlock in 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=11307. 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=11307 Deadlock in ClassLoader --- Additional Comments From [EMAIL PROTECTED] 2002-08-12 15:27 --- Yes, this does look to be fixed. Thank you. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1.9] New test milestone released
Because I need features in Tomcat 4.1.x I have been putting each new version into production. There are 2 instances running 4.1.9 with Jasper 2, and one instance running 4.1.8 with Jasper 1. This last instance gets heavy use, 2-3 million tomcat JSP/Servlet requests per month. With spikes 4 times a week of 10-20k requests per hour. This also uses DBCP very heavily. Tracking Tomcat 4.1.x releases but using Jasper 1 (customer isn't ready to switch yet) I haven't been able to get much better than 7-10 days runtime before Tomcat fails or Tomcat requires a restart due to a memory leak. Several months ago I had a run of 4 weeks w/o a failure and w/o a memory leak. MEMORY LEAK --- I have a sneaking suspicion there is a small memory leak in Tomcat 4.1.x. This appears to have been introduced sometime in the last couple of months. This is not due to javac JSP page compiles because jikes is being used as an external page compiler. When I get some time I may try setting up a test server with the customers app and use optimizeit to try and track down the memory leak. JASPER 2 JSP Page Comiles - I would also like to see Jasper 2 changed so that JSP page compiles occur externally outside of the Tomcat4 JVM process. There are two reasons for this: 1. The known memory leak with javac. 2. Removing the extra stress to the Tomcat 4 JVM instance due to javac object creation and GC of those objects. Moving JSP page compiles outside of the Tomcat JVM will improve performance and reliability. Regards, Glenn [EMAIL PROTECTED] wrote: Remy, Let's try to make 4.1.10 the 'stable' release ( and consider 4.1.9 as the 'release candidate ). I cleaned up some of the jk messages and I want to do some more watchdog tests with apache/jk. If everyone agree, I think we should also tag jk2 as 'jk2.0beta' and jk1.2.0 release, even if we don't distribute a standalone package. Costin On Sat, 10 Aug 2002, Remy Maucherat wrote: A new test milestone of Tomcat 4.1 has just been released. Downloads: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/test/v4.1.9/ Significant changes over 4.1.8 Beta include: - Jasper 2 bugfixes - Catalina classloader bugfixes - Coyote HTTP/1.1 fixes - Updated commons-dbcp connection pool The list of changes is available in the release notes. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1.9] New test milestone released
There is also this feature/bug in jasper2 regarding the scope of scripting variables that costin had objected to. The clarifications from JSP spec lead inidcates that costin was right. We should have a fix this week and that should go into 4.1.10. - Kin-man Date: Sat, 10 Aug 2002 09:54:02 -0700 (PDT) From: [EMAIL PROTECTED] Subject: Re: [4.1.9] New test milestone released X-X-Sender: [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] X-Authentication-warning: costinm.sfo.covalent.net: costin owned process doing -bs Remy, Let's try to make 4.1.10 the 'stable' release ( and consider 4.1.9 as the 'release candidate ). I cleaned up some of the jk messages and I want to do some more watchdog tests with apache/jk. If everyone agree, I think we should also tag jk2 as 'jk2.0beta' and jk1.2.0 release, even if we don't distribute a standalone package. Costin On Sat, 10 Aug 2002, Remy Maucherat wrote: A new test milestone of Tomcat 4.1 has just been released. Downloads: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/test/v4.1.9/ Significant changes over 4.1.8 Beta include: - Jasper 2 bugfixes - Catalina classloader bugfixes - Coyote HTTP/1.1 fixes - Updated commons-dbcp connection pool The list of changes is available in the release notes. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Servlet Compilation Takes Way Too Long
Whenever I change a jsp page, it takes forever for the program to compile. (Forever = five to fifteen minutes.) During that time my site is essentially shut down. I am current running aTomcat 4.0 with Struts 1.2. I have an application set for www.myapp.com with the following code in server.xml, where the code for /anniversaries is reapeated for 24 different sites. Context path= docBase=myapp debug=0 reloadbale=true/ Context path=/manager docBase=manager debug=0 privileged=true/ Context path=/mysubapp-0NE docBase=mysubapp-0NE debug=0 reloadable=true/ Context path=/mysubapp-TWO docBase=mysubapp-TWO debug=0 reloadable=true/ ... Context path=/mysubapp-TWENTY-FIVE docBase=mysubapp-TWENTY-FIVE debug=0 reloadable=true/ Am I doing something dumb, or am I misusing one of the applications? Or, what? Thanks. Micael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1.9] New test milestone released
On Mon, 12 Aug 2002, Glenn Nielsen wrote: JASPER 2 JSP Page Comiles - I would also like to see Jasper 2 changed so that JSP page compiles occur externally outside of the Tomcat4 JVM process. There are two reasons for this: What's wrong with that ? It works just fine, just set 'build.compiler' system property ( I think you can do it in web.xml as well ). Costin 1. The known memory leak with javac. 2. Removing the extra stress to the Tomcat 4 JVM instance due to javac object creation and GC of those objects. Moving JSP page compiles outside of the Tomcat JVM will improve performance and reliability. Regards, Glenn [EMAIL PROTECTED] wrote: Remy, Let's try to make 4.1.10 the 'stable' release ( and consider 4.1.9 as the 'release candidate ). I cleaned up some of the jk messages and I want to do some more watchdog tests with apache/jk. If everyone agree, I think we should also tag jk2 as 'jk2.0beta' and jk1.2.0 release, even if we don't distribute a standalone package. Costin On Sat, 10 Aug 2002, Remy Maucherat wrote: A new test milestone of Tomcat 4.1 has just been released. Downloads: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/test/v4.1.9/ Significant changes over 4.1.8 Beta include: - Jasper 2 bugfixes - Catalina classloader bugfixes - Coyote HTTP/1.1 fixes - Updated commons-dbcp connection pool The list of changes is available in the release notes. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Build notes
On Mon, 12 Aug 2002, Jean-francois Arcand wrote: I think that the dependency on Xerces 2.0.1 is excessively restrictive as well. IIRC (maybe Jean-François could provide some of the details he found?), Xerces 2.0.1 was the only Xerces parser that we have found so far that does not throw StackOverflow or other fatal exceptions when an XML file using XML schema is parsed. I believe (Jean-François: let me know if my understanding is incorrect) that this problem exists even if schema validation is turned off. The StackOverflowException _only_ occurs with released version of Xerces 2.0.2. It has been fixed since the release (nightly build works fine). Yes the problem exist even if the schema validation is on. I only tested crimson - it fails if validation is on, but works fine and faster if validation is disabled. And having schema validation turned on by default has a strong -1 from me - if the spec _requires_ schema validation, then implement it at deployment time. The performance hit is just unacceptable. Any performance increases through delayed validation sounds good to me. I agree. What behaviour do we want if a xml instance is not well-formed? Again - this is not 'delayed' validation, the validation and initalization will allways happen before the first request is served, and if an error is found the context will be disabled. There are 2 distinct issues: One is moving the 'validation' to a deploy stage. If validation fails, the app will not be deployed. The second issue is doing the context initialization in background and in parallel. That has nothing to do with validation. If we don't implement the 'deploy' - we can validate the XML file once ( during startup ), and keep a timestamp to avoid future re-validation. But the behavior remains the same - the app will not be started. Costin ( in the process we should also move DTD validation to the same stage and stop doing it on every startup if the xml file didn't change ) Makes sense. Especially since we use this same technique for JSP page compilation. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-servletapi-5/src/share/javax/servlet/jsp JspContext.java
kinman 2002/08/12 10:53:19 Modified:src/share/javax/servlet/jsp JspContext.java Log: - Remove peekPageScope, popPageScope, and pushPageScope: spec api change. Revision ChangesPath 1.4 +0 -46 jakarta-servletapi-5/src/share/javax/servlet/jsp/JspContext.java Index: JspContext.java === RCS file: /home/cvs/jakarta-servletapi-5/src/share/javax/servlet/jsp/JspContext.java,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- JspContext.java 8 Aug 2002 22:20:31 - 1.3 +++ JspContext.java 12 Aug 2002 17:53:19 - 1.4 @@ -77,12 +77,6 @@ * scripting environment * /ul * - * pBMethods Intended for Container Generated Code/B - * p - * To facilitate Simple Tag Extensions, the codepushPageScope()/code, - * codepopPageScope()/code and codepeekPageScope()/code methods are - * added. - * * pBMethods Intended for JSP authors/B * p * The following methods provide Bconvenient access/B to implicit objects: @@ -226,46 +220,6 @@ abstract public JspWriter getOut(); -/** - * Pops the page scope from the stack. After calling this method, the - * PageScope will appear the same as it was before the last call to - * pushPageScope. - * - * @return A Map representing the state of the page scope just before - * it was popped. This object can be passed to pushPageScope to - * restore this state. The keys of the returned Map are Strings - * representing attribute names. The values are the values of - * those attributes. - * @throws java.util.EmptyStackException if this is the last page scope on the - * stack. - */ -public abstract java.util.Map popPageScope() -throws java.util.EmptyStackException; - -/** - * Pushes a page scope on the stack. The scopeState cannot be arbitrary. - * Only a page scope returned from popPageScope() or peekPageScope() may - * be passed in. - * - * @param scopeState If null, a new, empty, page scope is pushed. - * Otherwise, the state of the page scope is restored to the - * contents of the provided Map. - */ -public abstract void pushPageScope( java.util.Map scopeState ); - -/** - * Peeks at the top element of the page scope stack. This value is - * the current state of the page scope. Does not modify the state of - * the stack or copy any objects. - * - * @return A Map representing the state of the page scope currently - * at the top of the stack. This object can be passed to - * pushPageScope to restore this state. The keys of the returned - * Map are Strings representing attribute names. The values are - * the values of those attributes. - */ -public abstract java.util.Map peekPageScope(); - /** * Provides programmatic access to the ExpressionEvaluator. * The JSP Container must return a valid instance of an -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime JspFragmentHelper.java PageContextImpl.java
kinman 2002/08/12 10:55:45
Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
jasper2/src/share/org/apache/jasper/runtime
JspFragmentHelper.java PageContextImpl.java
Log:
- Mods with spec api changes.
- Fix problems when tag files needs page context.
Revision ChangesPath
1.65 +26 -21
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java
Index: Generator.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Generator.java,v
retrieving revision 1.64
retrieving revision 1.65
diff -u -r1.64 -r1.65
--- Generator.java8 Aug 2002 20:41:02 - 1.64
+++ Generator.java12 Aug 2002 17:55:45 - 1.65
@@ -1001,7 +1001,11 @@
out.print( pageParam );
printParams(n, pageParam, page.isLiteral());
out.println(););
- out.printil((methodNesting 0)? return true;: return;);
+ if (isTagFile) {
+ out.printil(throw new javax.servlet.jsp.SkipPageException(););
+ } else {
+ out.printil((methodNesting 0)? return true;: return;);
+ }
out.popIndent();
out.printil(});
@@ -1445,7 +1449,6 @@
makeAttr(java_archive, archive);
out.printil(out.write( +
quote(s0) + s1 + s2 + + + quote(s3) + ););
- out.printil(out.write(\\\n\););
/*
* Generate a 'attr = value' for each jsp:param in plugin body
@@ -1764,7 +1767,7 @@
// Store varReader in appropriate scope
if (varReader != null) {
String scopeName = n.getAttributeValue(scope);
- out.printin(getJspContext().setAttribute();
+ out.printin(pageContext.setAttribute();
out.print(quote(varReader));
out.print(, new java.io.StringReader(sout.toString()));
if (scopeName != null) {
@@ -1812,13 +1815,13 @@
String name = tagVars[i].getNameGiven();
if (name != null) {
out.print(quote(name));
- out.print(, getJspContext().getAttribute();
+ out.print(, pageContext.getAttribute();
out.print(quote(name));
out.println()););
} else {
String getter =
toGetterMethod(tagVars[i].getNameFromAttribute());
out.print(getter);
- out.print(, getJspContext().getAttribute();
+ out.print(, pageContext.getAttribute();
out.print(getter);
out.println()););
}
@@ -1837,7 +1840,7 @@
// Store varReader in appropriate scope
if (varReader != null) {
String scopeName = n.getAttributeValue(scope);
- out.printin(getJspContext().setAttribute();
+ out.printin(pageContext.setAttribute();
out.print(quote(varReader));
out.print(, new java.io.StringReader(sout.toString()));
if (scopeName != null) {
@@ -2797,6 +2800,15 @@
out.println();
}
+ // Generate imports
+ Iterator iter = pageInfo.getImports().iterator();
+ while (iter.hasNext()) {
+ out.printin(import );
+ out.print ((String)iter.next());
+ out.println(;);
+ }
+ out.println();
+
// Generate class declaration
out.printin(public class );
out.print(tagInfo.getTagName());
@@ -2820,6 +2832,7 @@
out.printil(public void doTag() throws javax.servlet.jsp.JspException {);
out.pushIndent();
+ out.printil(PageContext pageContext = new
JspContextWrapper(getJspContext()););
// Declare parameter map for fragment/body invocation
out.printil(java.util.Map params = null;);
@@ -2827,8 +2840,7 @@
// if 'varReader' attribute is specified
out.printil(java.io.Writer sout = null;);
- out.printil(javax.servlet.jsp.JspWriter out = getJspContext().getOut(););
- out.printil(getJspContext().pushPageScope(null););
+ out.printil(javax.servlet.jsp.JspWriter out = pageContext.getOut(););
generatePageScopedVariables(tagInfo);
out.printil(try {);
out.pushIndent();
@@ -2840,10 +2852,6 @@
out.pushIndent();
out.printil(throw new javax.servlet.jsp.JspException(ioe););
out.popIndent();
-out.printil(} finally {);
-out.pushIndent();
-out.printil(getJspContext().popPageScope(););
-out.popIndent();
out.printil(});
out.popIndent();
out.printil(});
@@
Re: [5] [PATCH] HttpSession.logout()
This patch causes logout() and invalidate() to do the Servlet spec 2.4
right thing. I implemented it using the Data field of SessionEvent to
distinguish between logout/invalidate.
Can someone apply this? THANKS.
Cheers,
-bob
On Sat, 2002-08-10 at 23:02, Bob Herrmann wrote:
The servlet 2.4 spec adds a new method, HttpSession.logout();
How do we implement this?
For the non-single signon case, logout() is identical to
invalidate()
For single signon, Tomcat currently uses a single signon valve which
listens for Session Destroy events. When a Session Destroy happens,
all sessions are removed. A Session Destroy happens now when either
invalidate() or logout() happens. For logout, everything is fine, for
invalidate() - only the session for the current web app should be
removed.
So, when a session logout() or invalidate() is called, what should
happen? A Session Destroy with extra data indicating a logout or
invalidate occured? Or should a new session event be created to
indicate a logout is happening?
comments/ideas?
Cheers,
-bob
--
Cheers,
-bob
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Index: authenticator/SingleSignOn.java
===
RCS file: /home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/SingleSignOn.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 SingleSignOn.java
--- authenticator/SingleSignOn.java 18 Jul 2002 16:48:03 - 1.1.1.1
+++ authenticator/SingleSignOn.java 12 Aug 2002 18:34:52 -
@@ -293,6 +293,7 @@
Session session = event.getSession();
if (debug = 1)
log(Process session destroyed on + session);
+
String ssoId = null;
synchronized (reverse) {
ssoId = (String) reverse.get(session);
@@ -300,8 +301,22 @@
if (ssoId == null)
return;
-// Deregister this single session id, invalidating associated sessions
-deregister(ssoId);
+if ( event.getData() != null
+ logout.equals( event.getData().toString() )) {
+
+log(X logout event on + ssoId);
+
+// logout of all applications
+deregister(ssoId);
+
+} else {
+
+log(X invalidate of just one session + ssoId + + session);
+
+// invalidate just one session
+deregister(ssoId, session);
+
+}
}
@@ -442,6 +457,35 @@
}
+/**
+ * Deregister the specified session. If it is the last session,
+ * then also get rid of the single sign on identifier
+ *
+ * @param ssoId Single sign on identifier
+ * @param session Session to be deregistered
+ */
+private void deregister(String ssoId, Session session) {
+
+synchronized (reverse) {
+reverse.remove(session);
+}
+
+SingleSignOnEntry sso = lookup(ssoId);
+if ( sso == null )
+return;
+
+sso.removeSession( session );
+
+// see if we are the last session, if so blow away ssoId
+Session sessions[] = sso.findSessions();
+if ( sessions == null || sessions.length == 0 ) {
+synchronized (cache) {
+sso = (SingleSignOnEntry) cache.remove(ssoId);
+}
+}
+
+}
+
/**
* Deregister the specified single sign on identifier, and invalidate
@@ -449,7 +493,7 @@
*
* @param ssoId Single sign on identifier to deregister
*/
-void deregister(String ssoId) {
+private void deregister(String ssoId) {
if (debug = 1)
log(Deregistering sso id ' + ssoId + ');
@@ -459,6 +503,7 @@
synchronized (cache) {
sso = (SingleSignOnEntry) cache.remove(ssoId);
}
+
if (sso == null)
return;
@@ -601,6 +646,16 @@
results[sessions.length] = session;
sessions = results;
session.addSessionListener(sso);
+}
+
+public synchronized void removeSession(Session session) {
+Session[] nsessions = new Session[sessions.length - 1];
+for (int i = 0, j = 0; i sessions.length; i++) {
+if (session == sessions[i])
+continue;
+nsessions[j++] = sessions[i];
+}
+sessions = nsessions;
}
public synchronized Session[] findSessions() {
Index: session/StandardSession.java
===
RCS file: /home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardSession.java,v
retrieving revision 1.3
diff -u -r1.3 StandardSession.java
--- session/StandardSession.java 8 Aug 2002 04:03:44 - 1.3
+++ session/StandardSession.java 12 Aug 2002 18:34:56 -
@@ -1066,7 +1066,10 @@
throw new IllegalStateException
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session StandardSession.java
patrickl2002/08/12 12:12:44
Modified:catalina/src/share/org/apache/catalina/authenticator
SingleSignOn.java
catalina/src/share/org/apache/catalina/session
StandardSession.java
Log:
This patch causes logout() and invalidate() to do the Servlet spec 2.4 right
thing. It is implemented using the Data field of SessionEvent to distinguish between
logout/invalidate.
Submitted by: Bob Herrmann ([EMAIL PROTECTED])
Revision ChangesPath
1.2 +62 -7
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/SingleSignOn.java
Index: SingleSignOn.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/authenticator/SingleSignOn.java,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- SingleSignOn.java 18 Jul 2002 16:48:03 - 1.1
+++ SingleSignOn.java 12 Aug 2002 19:12:44 - 1.2
@@ -293,6 +293,7 @@
Session session = event.getSession();
if (debug = 1)
log(Process session destroyed on + session);
+
String ssoId = null;
synchronized (reverse) {
ssoId = (String) reverse.get(session);
@@ -300,8 +301,22 @@
if (ssoId == null)
return;
-// Deregister this single session id, invalidating associated sessions
-deregister(ssoId);
+if ( event.getData() != null
+ logout.equals( event.getData().toString() )) {
+
+log(X logout event on + ssoId);
+
+// logout of all applications
+deregister(ssoId);
+
+} else {
+
+log(X invalidate of just one session + ssoId + + session);
+
+// invalidate just one session
+deregister(ssoId, session);
+
+}
}
@@ -442,6 +457,35 @@
}
+/**
+ * Deregister the specified session. If it is the last session,
+ * then also get rid of the single sign on identifier
+ *
+ * @param ssoId Single sign on identifier
+ * @param session Session to be deregistered
+ */
+private void deregister(String ssoId, Session session) {
+
+synchronized (reverse) {
+reverse.remove(session);
+}
+
+SingleSignOnEntry sso = lookup(ssoId);
+if ( sso == null )
+return;
+
+sso.removeSession( session );
+
+// see if we are the last session, if so blow away ssoId
+Session sessions[] = sso.findSessions();
+if ( sessions == null || sessions.length == 0 ) {
+synchronized (cache) {
+sso = (SingleSignOnEntry) cache.remove(ssoId);
+}
+}
+
+}
+
/**
* Deregister the specified single sign on identifier, and invalidate
@@ -449,7 +493,7 @@
*
* @param ssoId Single sign on identifier to deregister
*/
-void deregister(String ssoId) {
+private void deregister(String ssoId) {
if (debug = 1)
log(Deregistering sso id ' + ssoId + ');
@@ -459,6 +503,7 @@
synchronized (cache) {
sso = (SingleSignOnEntry) cache.remove(ssoId);
}
+
if (sso == null)
return;
@@ -601,6 +646,16 @@
results[sessions.length] = session;
sessions = results;
session.addSessionListener(sso);
+}
+
+public synchronized void removeSession(Session session) {
+Session[] nsessions = new Session[sessions.length - 1];
+for (int i = 0, j = 0; i sessions.length; i++) {
+if (session == sessions[i])
+continue;
+nsessions[j++] = sessions[i];
+}
+sessions = nsessions;
}
public synchronized Session[] findSessions() {
1.4 +8 -5
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardSession.java
Index: StandardSession.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardSession.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- StandardSession.java 8 Aug 2002 04:03:44 - 1.3
+++ StandardSession.java 12 Aug 2002 19:12:44 - 1.4
@@ -1066,7 +1066,10 @@
throw new IllegalStateException
(sm.getString(standardSession.isNew.ise));
-invalidate();
+
+// kills all sessions
+fireSessionEvent(Session.SESSION_DESTROYED_EVENT, logout);
+
}
--
To unsubscribe, e-mail:
[5][PATCH] BUILDING.txt and build.properties.default refer to old JTA version
BUILDING.txt and the default build properties refer to an older version of the Java Transaction API. The current version is 1.0.1a, where the old version was 1.0.1. The are semantically the same, just documentation changes. The current version of the jta jar file is named jta.jar, rather than jta-spec1_0_1.jar I'm trying to get the Tomcat 5 build to be as smooth as possible out of the box. 'ant download' makes most of it very straightforward. For optional components, it's a little tougher, as many of them are behind license screens. Several of the APIs that Sun provides also don't define a directory for themselves, such as JNDI and JTA. For these I've always placed them in a directory with the same name as the zip file, sans .zip. After this patch, the build is slightly broken if Tyrex isn't available. It appears that compilation of org/apache/naming/factory/TyrexFactory.java and TyrexResourceFactory are conditioned only on JTA. Patch to follow. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5][PATCH] BUILDING.txt and build.properties.default refer to old JTA version
With patch actually attached ...
On Monday 12 August 2002 03:22 pm, you wrote:
BUILDING.txt and the default build properties refer to an older version of
the Java Transaction API. The current version is 1.0.1a, where the old
version was 1.0.1. The are semantically the same, just documentation
changes. The current version of the jta jar file is named jta.jar, rather
than
jta-spec1_0_1.jar
I'm trying to get the Tomcat 5 build to be as smooth as possible out of the
box. 'ant download' makes most of it very straightforward. For optional
components, it's a little tougher, as many of them are behind license
screens.
Several of the APIs that Sun provides also don't define a directory for
themselves, such as JNDI and JTA. For these I've always placed them in a
directory with the same name as the zip file, sans .zip.
After this patch, the build is slightly broken if Tyrex isn't available. It
appears that compilation of org/apache/naming/factory/TyrexFactory.java
and TyrexResourceFactory are conditioned only on JTA. Patch to follow.
Index: BUILDING.txt
===
RCS file: /home/cvspublic/jakarta-tomcat-5/BUILDING.txt,v
retrieving revision 1.14
diff -u -r1.14 BUILDING.txt
--- BUILDING.txt 7 Aug 2002 14:14:03 - 1.14
+++ BUILDING.txt 12 Aug 2002 19:11:06 -
@@ -337,12 +337,13 @@
(18) Download and Install the Java Transaction APIs
-* Download the Java Transaction API (JTA) package (version 1.0.1) from:
+* Download the Java Transaction API (JTA) package (version 1.0.1a) from:
http://java.sun.com/products/jta/
* Unpack the package into a convenient location so that it resides in its
- own subdirectory.
+ own subdirectory. By default, the Tomcat build expects this to be
+ {base.path}/jta-1_0_1a/
(19) Download and Install the Struts Binary Distribution
Index: build.properties.default
===
RCS file: /home/cvspublic/jakarta-tomcat-5/build.properties.default,v
retrieving revision 1.18
diff -u -r1.18 build.properties.default
--- build.properties.default 8 Aug 2002 05:47:01 - 1.18
+++ build.properties.default 12 Aug 2002 19:11:06 -
@@ -197,9 +197,9 @@
# - Java Transaction API (JTA), version 1.0.1 or later -
-jta.home=${base.path}/jta-spec1_0_1
+jta.home=${base.path}/jta-1_0_1a
jta.lib=${jta.home}
-jta.jar=${jta.lib}/jta-spec1_0_1.jar
+jta.jar=${jta.lib}/jta.jar
# - JUnit Unit Test Suite, version 3.7 or later -
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5][PATCH] BUILDING.txt and build.properties.default refer to old JTA version
On Monday 12 August 2002 03:22 pm, you wrote: SNIP After this patch, the build is slightly broken if Tyrex isn't available. It appears that compilation of org/apache/naming/factory/TyrexFactory.java and TyrexResourceFactory are conditioned only on JTA. Patch to follow. Patch is NOT to have full.dist=on in ~/build.properties. ~/build.properties is nice when you're only building a group of related projects with the same environment. With unrelated projects, it's a source of much strangeness. I worked with one guy who argued for an /etc/build.properties. Fortunately coworkers kept me for strangling him. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Question about Session in Tomcat 3.3 -- continued...
Yes, it seems to be true that sessions are lost on reloading with fullReload=true. I don't think that the case of fullReload=false has been tested much, so it is possible that there could be some strange bugs like in 3.2.x. It looks like the best way to fix this (for the default fullReload=true case) would be to add another hook to the API (e.g. copyContext(Context old, Context new)). This way, SimpleSessionStore could move the old sessions into the new Context before they get destroyed. Comments? - Original Message - From: Hugh J. L. [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, August 12, 2002 5:50 AM Subject: Question about Session in Tomcat 3.3 -- continued... I changed switch fullReload in ReloadInterceptor from true to false, and sessions are maintained through context reloading. (Of course, because the old context remains.) Is there any disadvantage if I set this way? Anyway fullReload=true is default setting. Thanks. Hugh __ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11117] - Coyote connector does not correctly deal with large PUT when using chunked transfer encoding
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=7. 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=7 Coyote connector does not correctly deal with large PUT when using chunked transfer encoding [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-08-12 20:02 --- It seems that Remy found time to commit your patch before I got to it. It's now in the CVS HEAD. Thanks again! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[VOTE] new commiters on tomcat-dev (fwd)
Hi, Please create the accounts for: Ian Darwin [EMAIL PROTECTED] Bob Herrman [EMAIL PROTECTED] We voted them as commiters on tomcat-dev, with no -1 and plenty of +1s. Costin -- Forwarded message -- Date: Wed, 7 Aug 2002 13:36:06 -0700 (PDT) From: [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Subject: [VOTE] new commiters Ian Darwin and Bob Herrmann I think we've seen enough contributions - and is time to propose them as commiters on tomcat. Please send your votes. Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Servlet Compilation Takes Way Too Long
Tomcat 4.1.x uses Jasper 2. Jasper 2 can do JSP compilations in the background. If a JSP page had already been compiled it's class is used to serve pages until the new JSP has finished compilation. Result, no requests are delayed due to recompilation of a JSP page. It can also detect changs in JSP pages which were included at compile time and force a recompile of the page which included them. Regards, Glenn micael wrote: Whenever I change a jsp page, it takes forever for the program to compile. (Forever = five to fifteen minutes.) During that time my site is essentially shut down. I am current running aTomcat 4.0 with Struts 1.2. I have an application set for www.myapp.com with the following code in server.xml, where the code for /anniversaries is reapeated for 24 different sites. Context path= docBase=myapp debug=0 reloadbale=true/ Context path=/manager docBase=manager debug=0 privileged=true/ Context path=/mysubapp-0NE docBase=mysubapp-0NE debug=0 reloadable=true/ Context path=/mysubapp-TWO docBase=mysubapp-TWO debug=0 reloadable=true/ ... Context path=/mysubapp-TWENTY-FIVE docBase=mysubapp-TWENTY-FIVE debug=0 reloadable=true/ Am I doing something dumb, or am I misusing one of the applications? Or, what? Thanks. Micael -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 5507] - Swapping sessions causes exceptions and it doesn't work with FileStore
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=5507. 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=5507 Swapping sessions causes exceptions and it doesn't work with FileStore [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 8459] - Tomcat Crash or stuck without DISPLAY
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=8459. 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=8459 Tomcat Crash or stuck without DISPLAY [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-08-12 21:05 --- The DISPLAY environment variable is an artifact of the JDK implemententation and is not a Tomcat issue. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [4.1.9] New test milestone released
[EMAIL PROTECTED] wrote: On Mon, 12 Aug 2002, Glenn Nielsen wrote: JASPER 2 JSP Page Comiles - I would also like to see Jasper 2 changed so that JSP page compiles occur externally outside of the Tomcat4 JVM process. There are two reasons for this: What's wrong with that ? It works just fine, just set 'build.compiler' system property ( I think you can do it in web.xml as well ). I never noticed that in the Ant docs. Thanks. It would be nice if there were some docs with Tomcat 4 about Jasper. All there is now are the Jasper API Javadocs. Regards, Glenn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 7332] - Error unable to create jar cache in /tmp directory is found numerous times in catalina.out
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=7332. 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=7332 Error unable to create jar cache in /tmp directory is found numerous times in catalina.out [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE | --- Additional Comments From [EMAIL PROTECTED] 2002-08-12 21:09 --- Tried this with 4.0.4 on WinNT with IBM's 1.3.0 (20020124 build) and still get these errors. catalina.bat is setting java.io.tmpdir correctly. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10407] - Tomcat Memory Management
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=10407. 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=10407 Tomcat Memory Management [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-08-12 21:34 --- In short, I don't think this is a Tomcat bug. I think most modern operating systems allocate memory to a process, but processes dont (rarely) return memory back to the OS. The standard malloc/free library can expand the amount of memory a proccess uses (by using sbrk() instruction? - I am reaching back a few years here.), but most malloc/free libaries don't ever return process space back to the OS. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10608] - startup dumps core when using CATALINA_BASE
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=10608. 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=10608 startup dumps core when using CATALINA_BASE [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2002-08-12 21:37 --- Anytime there is a core dump, there is an underlying JVM problem. The JVM is never supposed to core dump. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Compiler.java SmapUtil.java
kinman 2002/08/12 14:58:48
Modified:jasper2/src/share/org/apache/jasper/compiler Compiler.java
SmapUtil.java
Log:
- Turn on jsr045 support with bug fixes.
Patch by Shawn Bayern [EMAIL PROTECTED]
Revision ChangesPath
1.26 +5 -5
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java
Index: Compiler.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Compiler.java,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- Compiler.java 6 Aug 2002 23:40:10 - 1.25
+++ Compiler.java 12 Aug 2002 21:58:48 - 1.26
@@ -253,7 +253,7 @@
writer.close();
//JSR45 Support - note this needs to be checked by a JSR45 guru
- //XXX SmapUtil.generateSmap(ctxt, pageNodes, true);
+ SmapUtil.generateSmap(ctxt, pageNodes, true);
}
/**
@@ -329,7 +329,7 @@
}
//JSR45 Support - note this needs to be checked by a JSR45 guru
- //XXX SmapUtil.installSmap(ctxt);
+ SmapUtil.installSmap(ctxt);
}
/**
1.4 +47 -46
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.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- SmapUtil.java 16 Jul 2002 22:35:04 - 1.3
+++ SmapUtil.java 12 Aug 2002 21:58:48 - 1.4
@@ -73,7 +73,7 @@
*/
public class SmapUtil {
-static final boolean verbose = false;
+private static final boolean verbose = false;
//*
// Constants
@@ -139,10 +139,9 @@
File outSmap = new File(ctxt.getClassFileName() + .smap);
File outServlet = new File(ctxt.getClassFileName());
SDEInstaller.install(outServlet, outSmap);
-if( !ctxt.keepGenerated() ) {
+//if( !ctxt.keepGenerated() ) {
outSmap.delete();
-}
-
+//}
}
@@ -186,18 +185,19 @@
} else if (args.length == 3) {
install(new File(args[0]), new File(args[1]), new File(args[2]));
} else {
-abort(Usage: command input class file +
- attribute file output class file name\n +
+System.err.println(Usage: command input class file +
+ attribute file output class file name\n +
command input/output class file attribute file);
}
}
static void install(File inClassFile, File attrFile, File outClassFile)
-throws IOException {
+throws IOException {
new SDEInstaller(inClassFile, attrFile, outClassFile);
}
-static void install(File inOutClassFile, File attrFile) throws IOException {
+static void install(File inOutClassFile, File attrFile)
+throws IOException {
File tmpFile = new File(inOutClassFile.getPath() + tmp);
new SDEInstaller(inOutClassFile, attrFile, tmpFile);
if (!inOutClassFile.delete()) {
@@ -208,17 +208,13 @@
}
}
-static void abort(String msg) {
-System.err.println(msg);
-System.exit(1);
-}
-
-SDEInstaller(File inClassFile, File attrFile, File outClassFile) throws
IOException {
+SDEInstaller(File inClassFile, File attrFile, File outClassFile)
+throws IOException {
if (!inClassFile.exists()) {
-abort(no such file: + inClassFile);
+throw new FileNotFoundException(no such file: + inClassFile);
}
if (!attrFile.exists()) {
-abort(no such file: + attrFile);
+throw new FileNotFoundException(no such file: + attrFile);
}
// get the bytes
@@ -240,18 +236,22 @@
int len = (int)input.length();
byte[] bytes = new byte[len];
if (inStream.read(bytes, 0, len) != len) {
-abort(expected size: + len);
+throw new IOException(expected size: + len);
}
inStream.close();
return bytes;
}
-void addSDE() throws UnsupportedEncodingException {
+void addSDE() throws UnsupportedEncodingException,
Re: [5.0] Build notes
The only snag is that 'ant download' doesn't download optional
components. And some of them are optional the same way that brakes on a
go-cart are optional. It'll work, just not quite the way you expect it to.
More importantly, any developer building Tomcat needs to build a full
version, otherwise you run the risk of breaking parts of the build that
you happen not to be building because you don't have the optional
component that it depends on. And the build process is fairly quiet
about those missing pieces.
Automating the download of optional components, however, is a bit
tricky, as many of the optional components are behind Sun's license page.
Bob Herrmann wrote:
Yea, I liked your script, this one builds Tomcat 5.
BUILDING.TXT could almost just say All you need is JDK1.4 and Ant1.5
then just type 'ant' and a working Tomcat 5 development tree is built.
(If you are behind a firewall, you may need to adjust proxy settings.)
This should be cross platform (haven't tested it on Win32.)
Cheers,
-bob
project name=CVS Retrieval default=populate
property file=build.properties/
property name=apache.dir value=${user.home}/TC5/
property name=base.path value=${apache.dir}/download/
property name=cvsroot
value=:pserver:[EMAIL PROTECTED]:/home/cvspublic/
target name=populate depends=init,checkout,buildit /
target name=init
tstamp/
mkdir dir=${apache.dir}/
mkdir dir=${base.path}/
/target
target name=checkout depends=init
cvs package=jakarta-servletapi-5
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-catalina
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-5
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-connectors
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-jasper
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-5
cvsRoot=${cvsroot}
dest=${apache.dir}
/
/target
target name=buildit depends=init
echo message=Commons-logging build dies without this
file=${base.path}/LICENSE /
ant dir=${apache.dir}/jakarta-tomcat-5
target=download /
ant dir=${apache.dir}/jakarta-tomcat-5
target=dist /
/target
/project
On Tue, 2002-08-06 at 13:43, Ian Darwin wrote:
On August 6, 2002 01:01 pm, you wrote:
The main thing missing is a target which sets up the CVS repositories,
so it's quite close to what we have now. Problem is, I'm not too happy
at the idea of doing that automatically.
Trivial to do with Ant, but I agree, it's risky to automate this. OTOH if
it's well documented what it's doing, people should be OK with it.
Ian
project name=CVS Retrieval default=populate
!-- $Id: build.xml,v 1.1 2002/06/11 15:35:57 ian Exp $ --
!-- Maybe find a better way of setting this --
property name=apache.dir value=${user.home}/src/apache/
property name=cvs.root
value=:pserver:[EMAIL PROTECTED]:/home/cvspublic/
target name=init
tstamp/
mkdir dir=${apache.dir}/
/target
target name=populate depends=init
cvs package=jakarta-tomcat-4.0
cvsRoot=${cvs.root}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-connectors
cvsRoot=${cvs.root}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-jasper
cvsRoot=${cvs.root}
dest=${apache.dir}
/
/target
/project
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler JspUtil.java
kinman 2002/08/12 15:41:04
Modified:jasper2/src/share/org/apache/jasper/compiler JspUtil.java
Log:
- Fix EL for primitive types in tag attributes bug.
Patch by Shawn Bayern [EMAIL PROTECTED]
Revision ChangesPath
1.10 +58 -6
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspUtil.java
Index: JspUtil.java
===
RCS file:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/JspUtil.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- JspUtil.java 1 Aug 2002 18:47:28 - 1.9
+++ JspUtil.java 12 Aug 2002 22:41:04 - 1.10
@@ -548,21 +548,73 @@
String fnMap,
String defaultPrefix)
{
+/*
+ * Determine which context object to use.
+ */
String jspCtxt = null;
if (isTagFile)
jspCtxt = getJspContext();
else
jspCtxt = pageContext;
-return ( + expectedType.getName() + )
+ /*
+ * Determine whether to use the expected type's textual name
+ * or, if it's a primitive, the name of its correspondent boxed
+ * type.
+ */
+ String targetType = expectedType.getName();
+ String primitiveConverterMethod = null;
+ if (expectedType.isPrimitive()) {
+ if (expectedType.equals(Boolean.TYPE)) {
+ targetType = Boolean.class.getName();
+ primitiveConverterMethod = booleanValue;
+ } else if (expectedType.equals(Byte.TYPE)) {
+ targetType = Byte.class.getName();
+ primitiveConverterMethod = byteValue;
+ } else if (expectedType.equals(Character.TYPE)) {
+ targetType = Character.class.getName();
+ primitiveConverterMethod = charValue;
+ } else if (expectedType.equals(Short.TYPE)) {
+ targetType = Short.class.getName();
+ primitiveConverterMethod = shortValue;
+ } else if (expectedType.equals(Integer.TYPE)) {
+ targetType = Integer.class.getName();
+ primitiveConverterMethod = intValue;
+ } else if (expectedType.equals(Long.TYPE)) {
+ targetType = Long.class.getName();
+ primitiveConverterMethod = longValue;
+ } else if (expectedType.equals(Float.TYPE)) {
+ targetType = Float.class.getName();
+ primitiveConverterMethod = floatValue;
+ } else if (expectedType.equals(Double.TYPE)) {
+ targetType = Double.class.getName();
+ primitiveConverterMethod = doubleValue;
+ }
+ }
+
+ /*
+ * Build up the base call to the interpreter.
+ */
+ StringBuffer call = new StringBuffer(
+ ( + targetType + )
+ Constants.EL_INTERPRETER_CONDUIT_CLASS + .
+ Constants.EL_INTERPRETER_CONDUIT_METHOD
+ ( + Generator.quote(expression) + ,
- + expectedType.getName() + .class,
+ + targetType + .class,
+ jspCtxt + ,
+ prefixMap + ,
+ fnMap + ,
- + Generator.quote( defaultPrefix ) + );
+ + Generator.quote( defaultPrefix ) + ));
+
+ /*
+ * Add the primitive converter method if we need to.
+ */
+ if (primitiveConverterMethod != null) {
+ call.insert(0, ();
+ call.append(). + primitiveConverterMethod + ());
+ }
+
+ return call.toString();
}
/**
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime JspContextWrapper.java
kinman 2002/08/12 15:55:39
Added: jasper2/src/share/org/apache/jasper/runtime
JspContextWrapper.java
Log:
- Forgot to add this one.
Revision ChangesPath
1.1
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/JspContextWrapper.java
Index: JspContextWrapper.java
===
/*
* $Header:
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/JspContextWrapper.java,v
1.1 2002/08/12 22:55:39 kinman Exp $
* $Revision: 1.1 $
* $Date: 2002/08/12 22:55:39 $
*
*
*
* 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 written
*permission of the Apache Group.
*
* THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESSED OR IMPLIED
* WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
* OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE FOUNDATION OR
* ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
* SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
* LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
* USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
* OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*
* This software consists of voluntary contributions made by many
* individuals on behalf of the Apache Software Foundation. For more
* information on the Apache Software Foundation, please see
* http://www.apache.org/.
*
*/
package org.apache.jasper.runtime;
import java.io.IOException;
import java.util.Enumeration;
import java.util.Hashtable;
import javax.servlet.Servlet;
import javax.servlet.ServletConfig;
import javax.servlet.ServletContext;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.ServletException;
import javax.servlet.http.HttpSession;
import javax.servlet.jsp.JspContext;
import javax.servlet.jsp.PageContext;
import javax.servlet.jsp.JspWriter;
import javax.servlet.jsp.tagext.BodyContent;
import javax.servlet.jsp.JspException;
import javax.servlet.jsp.el.ExpressionEvaluator;
/**
* A wrapper class for PageContext class used for providing a tempory
* page scope for invoking a fragment
*
* @author Kin-man Chung
*/
public class JspContextWrapper extends PageContext {
private PageContext pageContext;
private transient Hashtable pageAttributes;
public JspContextWrapper(JspContext jspContext) {
this.pageContext = (PageContext) jspContext;
this.pageAttributes = new Hashtable(16);
}
public void initialize(Servlet servlet, ServletRequest request,
ServletResponse response, String errorPageURL,
boolean needsSession, int bufferSize,
boolean autoFlush)
throws IOException, IllegalStateException, IllegalArgumentException
{
}
public Object getAttribute(String name) {
return pageAttributes.get(name);
[PATCH] jakarta-servletapi-5
The attached patch contains the latest fix of
servlet 2.4 deployment descriptor, web-app_2_4.xsd.
+ change xsd:string to j2ee:string
+ element locale-encoding-mapping-list moved up before
the element deployment-extension
Thank you,
Yutaka Yoshida
Java/XML Software Group
Sun Microsystems Inc.
? patch.txt
Index: src/share/dtd/web-app_2_4.xsd
===
RCS file: /home/cvspublic/jakarta-servletapi-5/src/share/dtd/web-app_2_4.xsd,v
retrieving revision 1.1
diff -u -r1.1 web-app_2_4.xsd
--- src/share/dtd/web-app_2_4.xsd 30 Jul 2002 22:59:45 - 1.1
+++ src/share/dtd/web-app_2_4.xsd 12 Aug 2002 22:58:51 -
@@ -8,7 +8,7 @@
version=2.4
xsd:annotation
xsd:documentation
-@(#)web-app_2_4.xsds 1.32 02/07/26
+@(#)web-app_2_4.xsds 1.34 02/08/01
/xsd:documentation
/xsd:annotation
@@ -479,7 +479,7 @@
/xsd:documentation
/xsd:annotation
-xsd:restriction base=xsd:string/
+xsd:restriction base=j2ee:string/
/xsd:simpleType
@@ -694,9 +694,9 @@
xsd:sequence
xsd:element name=locale
-type=xsd:string/
+type=j2ee:string/
xsd:element name=encoding
-type=xsd:string/
+type=j2ee:string/
/xsd:sequence
/xsd:complexType
@@ -721,7 +721,7 @@
type=j2ee:auth-methodType
minOccurs=0/
xsd:element name=realm-name
- type=xsd:string minOccurs=0
+ type=j2ee:string minOccurs=0
xsd:annotation
xsd:documentation
@@ -763,7 +763,7 @@
/xsd:annotation
xsd:element name=extension
- type=xsd:string/
+ type=j2ee:string/
xsd:element name=mime-type
type=j2ee:mime-typeType/
/xsd:sequence
@@ -786,7 +786,7 @@
/xsd:documentation
/xsd:annotation
-xsd:restriction base=xsd:string
+xsd:restriction base=j2ee:string
xsd:pattern value=[\p{L}\-\p{Nd}]+/[\p{L}\-\p{Nd}\.]+/
/xsd:restriction
@@ -861,7 +861,7 @@
/xsd:documentation
/xsd:annotation
-xsd:restriction base=xsd:string/
+xsd:restriction base=j2ee:string/
/xsd:simpleType
@@ -981,7 +981,8 @@
must be expressed in a whole number of minutes.
If the timeout is 0 or less, the container ensures
the default behaviour of sessions is never to time
-out.
+out. If this element is not specified, the container
+must set its default timeout period.
/xsd:documentation
/xsd:annotation
@@ -1068,7 +1069,7 @@
/xsd:documentation
/xsd:annotation
-xsd:restriction base=xsd:string
+xsd:restriction base=j2ee:string
xsd:enumeration value=2.4/
/xsd:restriction
@@ -1183,14 +1184,14 @@
type=j2ee:message-destinationType
minOccurs=0
maxOccurs=unbounded/
-xsd:element name=deployment-extension
- type=j2ee:deployment-extensionType
- minOccurs=0
- maxOccurs=unbounded/
xsd:element name=locale-encoding-mapping-list
type=j2ee:locale-encoding-mapping-listType
minOccurs=0
maxOccurs=1/
+xsd:element name=deployment-extension
+ type=j2ee:deployment-extensionType
+ minOccurs=0
+ maxOccurs=unbounded/
/xsd:sequence
xsd:attribute name=version
@@ -1218,7 +1219,7 @@
xsd:sequence
xsd:element name=web-resource-name
- type=xsd:string
+ type=j2ee:string
xsd:annotation
xsd:documentation
@@ -1258,7 +1259,7 @@
xsd:sequence
xsd:element name=welcome-file
- type=xsd:string
+ type=j2ee:string
maxOccurs=unbounded
xsd:annotation
xsd:documentation
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [PATCH] improve internationalization for admin tool
Hi Takashi,
Takashi Okamoto wrote:
Hi tomcat, (especially amy)
This is the second patch to internationalize the admin tools. First
patch was commited by amy. New patch will improve at following point:
+ store file with utf-8 encoding and add encoding='utf-8' at
xml header.
+ use filter servlet to decode post and get parameters.
(you have to include SetCharacterEncodingFilter in admin web
application with this patch)
SetCharacterEncodingFilter isn't included in your patch. Can you submit
that as well?
Thanks,
Amy
Could you apply this patch?
regards,
Takashi Okamoto
diff -uNr
orig/jakarta-tomcat-4.1.8-src/catalina/src/share/org/apache/catalina/core/StandardServer.java
jakarta-tomcat-4.1.8-src/catalina/src/share/org/apache/catalina/core/StandardServer.java
---
orig/jakarta-tomcat-4.1.8-src/catalina/src/share/org/apache/catalina/core/StandardServer.java
Wed Jul 24 00:06:44 2002
+++
jakarta-tomcat-4.1.8-src/catalina/src/share/org/apache/catalina/core/StandardServer.java
Sun Aug 4 00:18:37 2002
@@ -71,6 +71,8 @@
import java.beans.PropertyDescriptor;
import java.io.File;
import java.io.FileWriter;
+import java.io.FileOutputStream;
+import java.io.OutputStreamWriter;
import java.io.InputStream;
import java.io.IOException;
import java.io.PrintWriter;
@@ -742,7 +744,7 @@
// Open an output writer for the new configuration file
PrintWriter writer = null;
try {
-writer = new PrintWriter(new FileWriter(configNew));
+writer = new PrintWriter(new OutputStreamWriter(new
FileOutputStream(configNew), UTF8));
} catch (IOException e) {
if (writer != null) {
try {
@@ -1916,6 +1918,7 @@
Server server) throws Exception {
// Store the beginning of this element
+writer.println(?xml version='1.0' encoding='utf-8'?);
for (int i = 0; i indent; i++) {
writer.print(' ');
}
diff -uNr
orig/jakarta-tomcat-4.1.8-src/catalina/src/share/org/apache/catalina/users/MemoryUserDatabase.java
jakarta-tomcat-4.1.8-src/catalina/src/share/org/apache/catalina/users/MemoryUserDatabase.java
---
orig/jakarta-tomcat-4.1.8-src/catalina/src/share/org/apache/catalina/users/MemoryUserDatabase.java
Wed Jul 24 00:06:44 2002
+++
jakarta-tomcat-4.1.8-src/catalina/src/share/org/apache/catalina/users/MemoryUserDatabase.java
Sun Aug 4 01:09:29 2002
@@ -506,11 +506,11 @@
// Configure our PrintWriter
FileOutputStream fos = new FileOutputStream(fileNew);
-OutputStreamWriter osw = new OutputStreamWriter(fos);
+OutputStreamWriter osw = new OutputStreamWriter(fos, UTF8);
writer = new PrintWriter(osw);
// Print the file prolog
-writer.println(?xml version='1.0'?);
+writer.println(?xml version='1.0' encoding='utf-8'?);
writer.println(tomcat-users);
// Print entries for each defined role, group, and user
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
cvs commit: jakarta-servletapi-5/src/share/dtd web-app_2_4.xsd
patrickl2002/08/12 17:01:16
Modified:src/share/dtd web-app_2_4.xsd
Log:
The attached patch contains the latest fix of servlet 2.4 deployment descriptor,
web-app_2_4.xsd.
+ change xsd:string to j2ee:string
+ element locale-encoding-mapping-list moved up before
the element deployment-extension
Submitted by: Yutaka Yoshida ([EMAIL PROTECTED])
Revision ChangesPath
1.2 +17 -16jakarta-servletapi-5/src/share/dtd/web-app_2_4.xsd
Index: web-app_2_4.xsd
===
RCS file: /home/cvs/jakarta-servletapi-5/src/share/dtd/web-app_2_4.xsd,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- web-app_2_4.xsd 30 Jul 2002 22:59:45 - 1.1
+++ web-app_2_4.xsd 13 Aug 2002 00:01:16 - 1.2
@@ -8,7 +8,7 @@
version=2.4
xsd:annotation
xsd:documentation
-@(#)web-app_2_4.xsds 1.32 02/07/26
+@(#)web-app_2_4.xsds 1.34 02/08/01
/xsd:documentation
/xsd:annotation
@@ -479,7 +479,7 @@
/xsd:documentation
/xsd:annotation
-xsd:restriction base=xsd:string/
+xsd:restriction base=j2ee:string/
/xsd:simpleType
@@ -694,9 +694,9 @@
xsd:sequence
xsd:element name=locale
-type=xsd:string/
+type=j2ee:string/
xsd:element name=encoding
-type=xsd:string/
+type=j2ee:string/
/xsd:sequence
/xsd:complexType
@@ -721,7 +721,7 @@
type=j2ee:auth-methodType
minOccurs=0/
xsd:element name=realm-name
- type=xsd:string minOccurs=0
+ type=j2ee:string minOccurs=0
xsd:annotation
xsd:documentation
@@ -763,7 +763,7 @@
/xsd:annotation
xsd:element name=extension
- type=xsd:string/
+ type=j2ee:string/
xsd:element name=mime-type
type=j2ee:mime-typeType/
/xsd:sequence
@@ -786,7 +786,7 @@
/xsd:documentation
/xsd:annotation
-xsd:restriction base=xsd:string
+xsd:restriction base=j2ee:string
xsd:pattern value=[\p{L}\-\p{Nd}]+/[\p{L}\-\p{Nd}\.]+/
/xsd:restriction
@@ -861,7 +861,7 @@
/xsd:documentation
/xsd:annotation
-xsd:restriction base=xsd:string/
+xsd:restriction base=j2ee:string/
/xsd:simpleType
@@ -981,7 +981,8 @@
must be expressed in a whole number of minutes.
If the timeout is 0 or less, the container ensures
the default behaviour of sessions is never to time
-out.
+out. If this element is not specified, the container
+must set its default timeout period.
/xsd:documentation
/xsd:annotation
@@ -1068,7 +1069,7 @@
/xsd:documentation
/xsd:annotation
-xsd:restriction base=xsd:string
+xsd:restriction base=j2ee:string
xsd:enumeration value=2.4/
/xsd:restriction
@@ -1183,14 +1184,14 @@
type=j2ee:message-destinationType
minOccurs=0
maxOccurs=unbounded/
-xsd:element name=deployment-extension
- type=j2ee:deployment-extensionType
- minOccurs=0
- maxOccurs=unbounded/
xsd:element name=locale-encoding-mapping-list
type=j2ee:locale-encoding-mapping-listType
minOccurs=0
maxOccurs=1/
+xsd:element name=deployment-extension
+ type=j2ee:deployment-extensionType
+ minOccurs=0
+ maxOccurs=unbounded/
/xsd:sequence
xsd:attribute name=version
@@ -1218,7 +1219,7 @@
xsd:sequence
xsd:element name=web-resource-name
- type=xsd:string
+ type=j2ee:string
xsd:annotation
xsd:documentation
@@ -1258,7 +1259,7 @@
xsd:sequence
xsd:element name=welcome-file
- type=xsd:string
+ type=j2ee:string
maxOccurs=unbounded
xsd:annotation
xsd:documentation
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [5.0] Build notes
Sort of a mini-gump.
No sense in over-doing what the build file is supposed to do. The idea
is cool, but, gump exists for a reason :) I suspect a change like this
would make things slightly more complex, confusing, and in general take
way to much time to implement - not to mention open up the possibility
for abuse.
But that is just my opinion. Anyhow, the one-step build-from-scratch
still rocks. Any idea when nightly Tomcat 5 builds will start appearing
on Jakarta?
Cheers,
Jayson
Bob Herrmann wrote:
On Sun, 2002-08-11 at 11:25, Jayson Falkner wrote:
I have been using the same thing. The only downside is the download
time, but, IMO it would be great to have this included and encouraged
for use with the Tomcat 5 build file.
Way to go Bob!
Thanks, although I just cut/pasted Ian Darwin's example.
It builds tomcat5 pretty well, but I would really like it if it also did
these things,
- building dist, start tomcat up
- download and run watchdog and generate a report
- If the report fails, then send an email to people who committed in
past 24 hours
- run automatically every 24 hours.
Sort of a mini-gump.
Cheers,
-bob
Jayson Falkner
[EMAIL PROTECTED]
Bob Herrmann wrote:
Yea, I liked your script, this one builds Tomcat 5.
BUILDING.TXT could almost just say All you need is JDK1.4 and Ant1.5
then just type 'ant' and a working Tomcat 5 development tree is built.
(If you are behind a firewall, you may need to adjust proxy settings.)
This should be cross platform (haven't tested it on Win32.)
Cheers,
-bob
project name=CVS Retrieval default=populate
property file=build.properties/
property name=apache.dir value=${user.home}/TC5/
property name=base.path value=${apache.dir}/download/
property name=cvsroot
value=:pserver:[EMAIL PROTECTED]:/home/cvspublic/
target name=populate depends=init,checkout,buildit /
target name=init
tstamp/
mkdir dir=${apache.dir}/
mkdir dir=${base.path}/
/target
target name=checkout depends=init
cvs package=jakarta-servletapi-5
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-catalina
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-5
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-connectors
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-jasper
cvsRoot=${cvsroot}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-5
cvsRoot=${cvsroot}
dest=${apache.dir}
/
/target
target name=buildit depends=init
echo message=Commons-logging build dies without this
file=${base.path}/LICENSE /
ant dir=${apache.dir}/jakarta-tomcat-5
target=download /
ant dir=${apache.dir}/jakarta-tomcat-5
target=dist /
/target
/project
On Tue, 2002-08-06 at 13:43, Ian Darwin wrote:
On August 6, 2002 01:01 pm, you wrote:
The main thing missing is a target which sets up the CVS repositories,
so it's quite close to what we have now. Problem is, I'm not too happy
at the idea of doing that automatically.
Trivial to do with Ant, but I agree, it's risky to automate this. OTOH if
it's well documented what it's doing, people should be OK with it.
Ian
project name=CVS Retrieval default=populate
!-- $Id: build.xml,v 1.1 2002/06/11 15:35:57 ian Exp $ --
!-- Maybe find a better way of setting this --
property name=apache.dir value=${user.home}/src/apache/
property name=cvs.root
value=:pserver:[EMAIL PROTECTED]:/home/cvspublic/
target name=init
tstamp/
mkdir dir=${apache.dir}/
/target
target name=populate depends=init
cvs package=jakarta-tomcat-4.0
cvsRoot=${cvs.root}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-connectors
cvsRoot=${cvs.root}
dest=${apache.dir}
/
cvs package=jakarta-tomcat-jasper
cvsRoot=${cvs.root}
dest=${apache.dir}
/
/target
/project
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To
DO NOT REPLY [Bug 11645] New: - RequestStream and HttpRequestStream throw an IOException when calling close on an already closed stream
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=11645.
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=11645
RequestStream and HttpRequestStream throw an IOException when calling close on an
already closed stream
Summary: RequestStream and HttpRequestStream throw an IOException
when calling close on an already closed stream
Product: Tomcat 4
Version: 4.0.4 Final
Platform: PC
OS/Version: All
Status: NEW
Severity: Normal
Priority: Other
Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Both
catalina/src/share/org/apache/catalina/connector/http/HttpResponseStream.java
and
catalina/src/share/org/apache/catalina/connector/ResponseStream.java
throw a IOException when calling close and the stream is already closed. Since
the is no way to check if a InputStream is open the close method should not
throw an Exception if the stream is already close (the InputStream classes in
the JDK do this). The close method should look like these in both cases:
/**
* Close this input stream. No physical level I-O is performed, but
* any further attempt to read from this stream will throw an IOException.
* If a content length has been set but not all of the bytes have yet been
* consumed, the remaining bytes will be swallowed.
*/
public void close() throws IOException {
if (closed)
//throw new IOException(sm.getString(requestStream.close.closed));
return;
if (length 0) {
while (count length) {
int b = read();
if (b 0)
break;
}
}
closed = true;
}
This bug applies to tomcat 4.1.7 too.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10407] - Tomcat Memory Management
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=10407. 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=10407 Tomcat Memory Management --- Additional Comments From [EMAIL PROTECTED] 2002-08-13 03:51 --- What you are reporting is not a bug, but here are some comments to help explain what you are seeing. Tomcat Threads --- Most all threads (except some tied to a specific Context) in Tomcat are never killed off, they are a resource which are reused. Memory Usage Total memory usage is not controlled by Tomcat, it is controlled by the JVM. Java does have a System.gc() method to force garbage collection but it is not recommended that applications do this, especially with modern JVM's like those with HotSpot. Tomcat 4 forces one GC, that is immediately after startup just before it starts handling requests. The memory usage for Tomcat varies depending on your applications and the volume of requests handled. The memory usage you see for the java JVM process is dependent upon the memory usage startup options you give to java. Settings such as -Xms for minumum stack size -Xmx for maximum stack size -Xss for thread stack size, etc. It is up to you to properly tune your java memory and gc startup options for the System, OS, and applications running in Tomcat. Here is a document which disucsses memory usage and gc: http://java.sun.com/docs/hotspot/gc/ You should also consider profiling Tomcat running your application using tools like OptimizeIt or JProbe. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [PATCH] improve internationalization for admin tool
Hi, Amy. Takashi Okamoto wrote: Hi tomcat, (especially amy) This is the second patch to internationalize the admin tools. First patch was commited by amy. New patch will improve at following point: + store file with utf-8 encoding and add encoding='utf-8' at xml header. + use filter servlet to decode post and get parameters. (you have to include SetCharacterEncodingFilter in admin web application with this patch) SetCharacterEncodingFilter isn't included in your patch. Can you submit that as well? In admin web application, can you add the same filter as filters.SetCharacterEncodingFilter class in Tomcat examples application ??? -- Kan Ogawa [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 11646] New: - Jasper compilation problem: 'else' without 'if'
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=11646. 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=11646 Jasper compilation problem: 'else' without 'if' Summary: Jasper compilation problem: 'else' without 'if' Product: Tomcat 4 Version: 4.1.9 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Jasper 2 AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I am getting a JSP compilation error in 4.1.9test that I had not been getting in 4.0.3. THE ERROR (trimmed for brevity) - org.apache.jasper.JasperException: Unable to compile class for JSP at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:477) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:182) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:289) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240) ... root cause org.apache.jasper.JasperException: Unable to compile class for JSP An error occurred at line: 264 in the jsp file: /netmarkets/jsp/util/begin.jsp Generated servlet error: Detected Java version: 1.3 in: d:\jdk1.3.1_02\jre Detected OS: Windows 2000 [javac] netmarkets\jsp\netmarkets\view_jsp.java added as D:\jakarta-tomcat-4.1.9\work\Tomcat-ForumPass\localhost\forumpass\netmarkets\jsp\netmarkets\view_jsp.class doesn't exist. [javac] Compiling 1 source file [javac] Using modern compiler [javac] Compilation arguments: [javac] '-classpath' [javac] 'D:\jdk1.3.1_02\lib\tools.jar;D:\jakarta-tomcat-4.1.9\bin\bootstrap.jar;D:\jakarta-tomcat-4.1.9\common\lib\servlet.jar;D:\jakarta-tomcat-4.1.9\common\endorsed\xercesImpl.jar;D:\jakarta-tomcat-4.1.9\common\endorsed\xmlParserAPIs.jar;D:\ptc\Windchill\codebase;D:\ptc\Windchill\codebase\WEB-INF\lib\ie.jar;D:\ptc\Windchill\codebase\WEB-INF\lib\JGL.jar;D:\ptc\Windchill\codebase\WEB-INF\lib\HTTPClient.jar;D:\evincible\jlib\privacy.jar;D:\evincible\jlib\xercesImpl.jar;D:\evincible\jlib\xalan.jar;D:\evincible\jlib\iaik_jce.jar;D:\evincible\jlib\xss4j.jar;D:\evincible\jlib\log4j.jar;D:\evincible\jlib\classes12_9.jar;D:\evincible\jlib\xml-apis.jar;D:\evincible\jlib\kmcsp.jar;D:\evincible\jlib\kmjava.jar;D:\evincible\jlib\nfjava.jar;D:\ptc\Windchill\codebase\WEB-INF\lib\CommonCoreMeta.jar;D:\ptc\Windchill\codebase\WEB-INF\lib\Copy of
DO NOT REPLY [Bug 11647] New: - Encoding of Response Headers Violates HTTP Spec.
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=11647.
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=11647
Encoding of Response Headers Violates HTTP Spec.
Summary: Encoding of Response Headers Violates HTTP Spec.
Product: Tomcat 4
Version: 4.1.8
Platform: All
OS/Version: All
Status: UNCONFIRMED
Severity: Normal
Priority: Other
Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
Hello,
I'm using Tomcat v4.1.8 on Win 2k, SP3. My client (i.e., browswer) is running
on a separate Win 2k, SP3 machine. I've tested this issue with IE 6 and
Navigator 6.2. I've also used the Wild Packets sniffer to see what bytes Tomcat
was sending.
Here's the problem: If a servlet sets the charset within the Content-Type
response header (e.g., text/html;charset=UTF-16), the response headers will
be encoded according to the specified encoding, rather than US-ASCII as
specified by RFC 2616 (http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2616.html).
Below is a simple servlet that shows the problem.
The servlet below specifies an encoding of UTF-16. The PrintWriter correctly
encodes the response body as UTF-16. The problem is that the response *headers*
are also being encoded as UTF-16, which violates the HTTP spec (see Section
2.2). The headers should be encoded as US-ASCII (or US-ASCII compatible).
I know it's possible to use UTF-8 or some other US-ASCII compatible encoding
where the first 127 characters are encoded the same as US-ASCII -- I realize
that's a possible work around. IMHO, however, Tomcat should encode headers
according to the spec, regardless of how the response body is encoded.
This is the first time I've submitted a Tomcat bug. Can you tell me if there is
a way for me to check the status? Thanks.
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
public class Tester extends HttpServlet {
public void doGet(HttpServletRequest request,
HttpServletResponse response)
throws ServletException, IOException {
response.setContentType(text/html;charset=UTF-16);
PrintWriter pw = response.getWriter();
pw.println(htmlheadtitleTest/title/head +
bodyp /p/body/html);
} // doGet()
} // Tester
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[PATCH][4.1.9] Jasper bug - script variables not synchronized
OK I have got my build working. Wasn't as painful
as it initially looked.
This patch works for me (fixes the problems mentioned below).
And at least I don't think it breaks anything (ahem, I think).
With this problem out of the way Tomcat 4.1.9 works nicely for me.
Be great to see a release soon.
Thanks to everyone for their efforts on Tomcat !
-Original Message-
From: David Shanahan
Sent: Monday, August 12, 2002 3:54 PM
To: '[EMAIL PROTECTED]'
Subject: RE: [4.1.9] New test milestone released
There is a bug in 4.1.9 (a Jasper bug) that breaks my
application completely.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=11552
We use custom tags that do iteration (they implement IterationTag)
but do not modify their content so they do not implement BodyTag.
The latest versions of Jasper2 generates code which only synchronizes
script variables before the first iteration of the tag. (ie before the do {}
while() loop).
There is also another bug whereby if a BodyTag returns EVAL_BODY_INCLUDE,
the script variables will not be synchronized at ALL for the first
iteration.
The problem is in org.apache.jasper.Generator.java. The generated code
for a tag that implements IterationTag synchronizes variables before the tag
loop but not inside it (even for NESTED scoped variables).
Also for BodyTags that return EVAL_BODY_INCLUDE, the synchronization
for the first iteration is skipped completely because it gets placed
together
in the same block of code that sets up the BodyContent buffer and that gets
skipped on EVAL_BODY_INCLUDE.
I have submitted some patches that move the variable synchronization into
the body of the loop for IterationTags and BodyTags. I think this should fix
the
problem but I haven't got round to setting up a build environment yet.
(sorry).
Doing that now.
If someone could take a look at this it would be much appreciated.
Thanks.
-Original Message-
From: Remy Maucherat [mailto:[EMAIL PROTECTED]]
Sent: Sunday, August 11, 2002 1:21 AM
To: Tomcat Developers List; Tomcat Users List
Subject: [4.1.9] New test milestone released
A new test milestone of Tomcat 4.1 has just been released.
Downloads:
http://jakarta.apache.org/builds/jakarta-tomcat-4.0/test/v4.1.9/
Significant changes over 4.1.8 Beta include:
- Jasper 2 bugfixes
- Catalina classloader bugfixes
- Coyote HTTP/1.1 fixes
- Updated commons-dbcp connection pool
The list of changes is available in the release notes.
Remy
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
script_var_sync-head.patch
Description: Binary data
script_var_sync-tomcat_4_branch.patch
Description: Binary data
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 11646] New: - Jasper compilation problem:'else' without 'if'
I don't think this is an error in jasper but in your source code.
If you do the if else the following way there shouldn't be any
compilation error:
% if (ua.indexOf(wildfire withtrail)=0) { %
SCRIPT LANGUAGE=JavaScript1.2var is_Wildfire=true/SCRIPT
% } else { %
SCRIPT LANGUAGE=JavaScript1.2var is_Wildfire=false/SCRIPT
% } %
[EMAIL PROTECTED] wrote:
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=11646.
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=11646
Jasper compilation problem: 'else' without 'if'
Summary: Jasper compilation problem: 'else' without 'if'
Product: Tomcat 4
Version: 4.1.9
Platform: PC
OS/Version: Windows NT/2K
Status: NEW
Severity: Major
Priority: Other
Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
I am getting a JSP compilation error in 4.1.9test that I had not been getting in
4.0.3.
THE ERROR (trimmed for brevity)
-
org.apache.jasper.JasperException: Unable to compile class for JSP
at
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:477)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:182)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:289)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:240)
...
root cause
org.apache.jasper.JasperException: Unable to compile class for JSP
An error occurred at line: 264 in the jsp file: /netmarkets/jsp/util/begin.jsp
Generated servlet error:
Detected Java version: 1.3 in: d:\jdk1.3.1_02\jre
Detected OS: Windows 2000
[javac] netmarkets\jsp\netmarkets\view_jsp.java added as
D:\jakarta-tomcat-4.1.9\work\Tomcat-ForumPass\localhost\forumpass\netmarkets\jsp\netmarkets\view_jsp.class
doesn't exist.
[javac] Compiling 1 source file
[javac] Using modern compiler
[javac] Compilation arguments:
[javac] '-classpath'
[javac]
'D:\jdk1.3.1_02\lib\tools.jar;D:\jakarta-tomcat-4.1.9\bin\bootstrap.jar;D:\jakarta-tomcat-4.1.9\common\lib\servlet.jar;D:\jakarta-tomcat-4.1.9\common\endorsed\xercesImpl.jar;D:\jakarta-tomcat-4.1.9\common\endorsed\xmlParserAPIs.jar;D:\ptc\Windchill\codebase;D:\ptc\Windchill\codebase\WEB-INF\lib\ie.jar;D:\ptc\Windchill\codebase\WEB-INF\lib\JGL.jar;D:\ptc\Windchill\codebase\WEB-INF\lib\HTTPClient.jar;D:\evincible\jlib\privacy.jar;D:\evincible\jlib\xercesImpl.jar;D:\evincible\jlib\xalan.jar;D:\evincible\jlib\iaik_jce.jar;D:\evincible\jlib\xss4j.jar;D:\evincible\jlib\log4j.jar;D:\evincible\jlib\classes12_9.jar;D:\evincible\jlib\xml-apis.jar;D:\evincible\jlib\kmcsp.jar;D:\evincible\jlib\kmjava.jar;D:\evincible\jlib\nfjava.jar;D:\ptc\Windchill\codebase\WEB-INF\lib\CommonCoreMeta.jar;D:\ptc\Windchill\codebase\WEB-INF\lib\Copy
of
xalan.jar;D:\ptc\Windchill\codebase\WEB-INF\lib\JClass.jar;D:\ptc\Windchill\codebase\WEB-INF\lib\OracleThinDrivers.jar;D:\ptc\Windchill\codebase\WEB-INF\lib\RetrievalWare.jar;D:\ptc\Windchill\codebase\WEB-INF\lib\activation.jar;D:\ptc\Windchill\codebase\WEB-INF\lib\avalon-framework-4.0.jar;D:\ptc\Windchill\codebase\WEB-INF\lib\batik-awt-util.jar;D:\ptc\Windchill\codebase\WEB-INF\lib\batik-bridge.jar;D:\ptc\Windchill\codebase\WEB-INF\lib\batik-css.jar;D:\ptc\Windchill\codebase\WEB-INF\lib\batik-dom.jar;D:\ptc\Windchill\codebase\WEB-INF\lib\batik-ext.jar;D:\ptc\Windchill\codebase\WEB-INF\lib\batik-extension.jar;D:\ptc\Windchill\codebase\WEB-INF\lib\batik-gui-util.jar;D:\ptc\Windchill\codebase\WEB-INF\lib\batik-gvt.jar;D:\ptc\Windchill\codebase\WEB-INF\lib\batik-parser.jar;D:\ptc\Windchill\codebase\WEB-INF\lib\batik-script.jar;D:\ptc\Windchill\codebase\WEB-INF\lib\batik-svg-dom.jar;D:\ptc\Windchill\codebase\WEB-INF\lib\batik-svggen.jar;D:\ptc\Windchill\codebase\WEB-INF\lib\ba
RE: pageEncoding for Shift_JIS doesn't work by using Apache Tomcat/4.1.8-LE-jdk14
I found that if you don't specify the language attribute then encoding seems to be ignored. example: %@ page contentType="text/html; charset=Shift_JIS" pageEncoding="Shift_JIS" % Does NOT work (UFT8 is assumed) but... %@ page language="java" contentType="text/html; charset=Shift_JIS" pageEncoding="Shift_JIS" % DOES work. -Original Message- From: Osamu Hashimoto [mailto:[EMAIL PROTECTED]] Sent: Monday, August 12, 2002 12:26 AM To: Tomcat Developers List Cc: [EMAIL PROTECTED] Subject: pageEncoding for Shift_JIS doesn't work by using Apache Tomcat/4.1.8-LE-jdk14 Hi ! JSP's directive element "pageEncoding" doesn't work by using Apache Tomcat/4.1.8-LE-jdk14. pageEncoding did work on current version of Tomcat 4.1.2 alpha. but the version is not available now. It sounds like Tomcat's degrading incident. I want to have description and opinion by commiter, and other developer using no UTF-8 charactor. Osamu Hashimoto [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
