DO NOT REPLY [Bug 11117] - Coyote connector does not correctly deal with large PUT when using chunked transfer encoding

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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-01 07:14 ---
Problem diagnosed, patch attached.
The detailed cause:

This code sets a particular buffer in a ByteChunk, and sets a specific start/end
to this buffer. This allows sharing of the buffers, rather than copying them
around.

In this code, the buffer was set (in chunk - the output ByteChunk) as pointing
to some part of the buffer in readChunk (the input ByteChunk), which is fine.
However, in one particular code path, this was immediately followed by a call to
parseCRLF() - which simply swallows a CRLF pair. In the very unfortunate event
(which happened on sufficiently large inputs with some regularity) of this CRLF
being over the end of the buffer, more content would need to be read in order to
do this. This refilled readChunk, but because this was shared with the (output)
chunk, the output buffer was _also_ overwritten. Output is then corrupted.

This is fixed here by deferring the parseCRLF() until later (the next call to
doRead())

This fix is critical for PUT (and presumably things like POST, or anything else
with a request-body) to work reliably with chunked transfer-encoding. 

Index: filters/ChunkedInputFilter.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/filters/ChunkedInputFilter.java,v
retrieving revision 1.5
diff -u -r1.5 ChunkedInputFilter.java
--- filters/ChunkedInputFilter.java 20 Jun 2002 11:14:30 -  1.5
+++ filters/ChunkedInputFilter.java 1 Aug 2002 07:13:44 -
@@ -136,6 +136,12 @@
  */
 protected boolean endChunk = false;
 
+/**
+ * Flag set to true if the next call to doRead() must parse a CRLF pair
+ * before doing anything else.
+ */
+protected boolean needCRLFParse = false;
+
 
 // - Properties
 
@@ -158,6 +164,11 @@
 if (endChunk)
 return -1;
 
+if(needCRLFParse) {
+needCRLFParse = false;
+parseCRLF();
+}
+
 if (remaining <= 0) {
 if (!parseChunkHeader()) {
 throw new IOException("Invalid chunk");
@@ -184,7 +195,7 @@
 chunk.setBytes(buf, pos, remaining);
 pos = pos + remaining;
 remaining = 0;
-parseCRLF();
+needCRLFParse = true;
 }
 
 return result;

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 11307] - Deadlock in ClassLoader

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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-01 05:58 ---
Could you provide a simple example web application and instructions
on how to reproduce this?

Also, what JVM are you using?

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-5 BUILDING.txt build.properties.default build.xml

[patrickl]

patrickl2002/07/31 22:52:59

  Modified:.BUILDING.txt build.properties.default build.xml
  Log:
  Updated build instructions, build.properties, and download target to use the latest 
Xerces 2 nightly build since it is the official Xerces 2 releases do not support XML 
schemas properly. Thanks go to Jean-Francois Arcand for helping find a parser that 
handles XML schemas properly.
  
  Revision  ChangesPath
  1.8   +6 -7  jakarta-tomcat-5/BUILDING.txt
  
  Index: BUILDING.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/BUILDING.txt,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- BUILDING.txt  31 Jul 2002 17:27:01 -  1.7
  +++ BUILDING.txt  1 Aug 2002 05:52:59 -   1.8
  @@ -84,17 +84,16 @@
   * This is optional with JDK 1.3 or later.
   
   
  -(4) Download and Install the Xerces 2.0.2 or Higher Distribution
  +(4) Download and Install the Xerces 2 nightly build July 31, 2002 or Higher
  +Distribution
   
  -* Download a binary distribution from:
  +* Download the xercesImpl.jar and xmlParserAPIs.jar files from:
   
  -  http://xml.apache.org/dist/xerces-j/
  +  http://gump.covalent.net/jars/latest/xml-xerces2/
   
  -* Unpack the binary distribution into a convenient location so that the
  +* Place the downloaded files in a convenient location so that the
 distribution resides in its own directory (conventionally named
 "xerces-x_y_z").
  -
  -* This is optional with JDK 1.4 or later.
   
   
   (5) Download and Install Subproject Source Code
  
  
  
  1.12  +7 -5  jakarta-tomcat-5/build.properties.default
  
  Index: build.properties.default
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- build.properties.default  31 Jul 2002 17:27:01 -  1.11
  +++ build.properties.default  1 Aug 2002 05:52:59 -   1.12
  @@ -102,13 +102,15 @@
   
regexp.loc=http://jakarta.apache.org/builds/jakarta-regexp/release/v1.2/jakarta-regexp-1.2.tar.gz
   
   
  -# - Xerces XML Parser, version 2.0.2 or later -
  -# Note: Optional with JDK 1.4+
  -xerces.home=${base.path}/xerces-2_0_2
  +# - Xerces XML Parser, version 2 nightly build July 31, 2002 or later -
  +#xerces.home=${base.path}/xerces-2_0_2
  +xerces.home=${base.path}/xerces-2-latest
   xerces.lib=${xerces.home}
   xercesImpl.jar=${xerces.lib}/xercesImpl.jar
   xmlParserAPIs.jar=${xerces.lib}/xmlParserAPIs.jar
  -xerces.loc=http://xml.apache.org/dist/xerces-j/Xerces-J-bin.2.0.2.tar.gz
  +#xerces.loc=http://xml.apache.org/dist/xerces-j/Xerces-J-bin.2.0.2.tar.gz
  +xercesImpl.loc=http://gump.covalent.net/jars/latest/xml-xerces2/xercesImpl.jar
  +xmlParserAPIs.loc=http://gump.covalent.net/jars/latest/xml-xerces2/xmlParserAPIs.jar
   
   
   # --
  
  
  
  1.14  +18 -1 jakarta-tomcat-5/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- build.xml 31 Jul 2002 03:09:19 -  1.13
  +++ build.xml 1 Aug 2002 05:52:59 -   1.14
  @@ -517,10 +517,27 @@
 
   
   
  +
  +
 
 
  +
  +-->
  +
  +
  +
  +  
  +  
  +  
  +
  +
  +  
  +  
  +  
   
   
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: mod_jk, mod_jk2 URI spaces

[Bojan Smojver]

Cool!

Bojan

Quoting Mladen Turk <[EMAIL PROTECTED]>:

> > -Original Message-
> > From: Bojan Smojver [mailto:[EMAIL PROTECTED]] 
> > Sent: Thursday, August 01, 2002 12:00 AM
> > To: Tomcat Dev List
> > Subject: RE: mod_jk, mod_jk2 URI spaces
> > 
> > This above sentence is confusing. You probably meant 
> > configuration options as a series of include/exclude 
> > switches, rsync style.
> >
> 
> Yes something like that.
> This will allow to serve the compiled applications and still deliver
> the
> static context from those locations, overlaying Apache URI space (if
> set) over already resolved TC uri space. 
> Well, at least the configuration will be IMHO easier.
> 
> > 
> > PS. Given 1.2.0 is due for a release when Henri comes back 
> > from holidays (in about 2 weeks time), are you planning the 
> > patches for this before of after the release?
> > 
> 
> After 1.2.0, If I figure out how to do that cross-server.
> I'll make that for jk2 first, I hope :).
> 
> MT.
> 
> 
> --
> To unsubscribe, e-mail:  
> 
> For additional commands, e-mail:
> 
> 
> 

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup CatalinaLaunchFilter.java

[patrickl]

patrickl2002/07/31 21:59:24

  Modified:catalina build.xml
   catalina/src/bin shutdown.bat shutdown.sh startup.bat
startup.sh
   catalina/src/conf catalina.policy
  Added:   catalina/src/bin catalina.xml
   catalina/src/share/org/apache/catalina/startup
CatalinaLaunchFilter.java
  Removed: catalina/src/bin catalina.sh
  Log:
  Converted the catalina.[sh|bat] scripts to use commons-launcher. Also, since all of 
the scripting options in the catalina.[sh|bat] scripts to catalina.xml, the 
catalina.[sh|bat] scripts are no longer needed and have been removed.
  
  Revision  ChangesPath
  1.7   +3 -3  jakarta-tomcat-catalina/catalina/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/build.xml,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- build.xml 30 Jul 2002 20:03:08 -  1.6
  +++ build.xml 1 Aug 2002 04:59:24 -   1.7
  @@ -700,6 +700,7 @@
 
   
   
  +
   
   
   
  @@ -710,7 +711,6 @@
   
   
   
  -
   
   
   
  @@ -999,7 +999,6 @@
   
   
   
  -
   
   
   
  @@ -1041,6 +1040,7 @@
 
   
   
  +
   
   
   
  @@ -1058,6 +1058,7 @@
   
   
   
  +
   
   
   
  @@ -1174,7 +1175,6 @@
   
   
   
  -
   
   
   
  
  
  
  1.2   +21 -22jakarta-tomcat-catalina/catalina/src/bin/shutdown.bat
  
  Index: shutdown.bat
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/bin/shutdown.bat,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- shutdown.bat  18 Jul 2002 16:48:14 -  1.1
  +++ shutdown.bat  1 Aug 2002 04:59:24 -   1.2
  @@ -1,33 +1,31 @@
   @echo off
   if "%OS%" == "Windows_NT" setlocal
  +
   rem ---
  -rem Stop script for the CATALINA Server
   rem
  -rem $Id$
  +rem Script for shutting down Catalina using the Launcher
  +rem
   rem ---
   
  -rem Guess CATALINA_HOME if not defined
  -if not "%CATALINA_HOME%" == "" goto gotHome
  -set CATALINA_HOME=.
  -if exist "%CATALINA_HOME%\bin\catalina.bat" goto okHome
  -set CATALINA_HOME=..
  -:gotHome
  -if exist "%CATALINA_HOME%\bin\catalina.bat" goto okHome
  -echo The CATALINA_HOME environment variable is not defined correctly
  -echo This environment variable is needed to run this program
  -goto end
  -:okHome
  -
  -set EXECUTABLE=%CATALINA_HOME%\bin\catalina.bat
  +rem Get standard environment variables
  +set PRG=%0
  +if exist %PRG%\..\setenv.bat goto gotCmdPath
  +rem %0 must have been found by DOS using the %PATH% so we assume that
  +rem setenv.bat will also be found in the %PATH%
  +call setenv.bat
  +goto doneSetenv
  +:gotCmdPath
  +call %PRG%\..\setenv.bat
  +:doneSetenv
   
  -rem Check that target executable exists
  -if exist "%EXECUTABLE%" goto okExec
  -echo Cannot find %EXECUTABLE%
  -echo This file is needed to run this program
  +rem Make sure prerequisite environment variables are set
  +if not "%JAVA_HOME%" == "" goto gotJavaHome
  +echo The JAVA_HOME environment variable is not defined
  +echo This environment variable is needed to run this program
   goto end
  -:okExec
  +:gotJavaHome
   
  -rem Get remaining unshifted command line arguments and save them in the
  +rem Get command line arguments and save them with the proper quoting
   set CMD_LINE_ARGS=
   :setArgs
   if ""%1""== goto doneSetArgs
  @@ -36,6 +34,7 @@
   goto setArgs
   :doneSetArgs
   
  -call "%EXECUTABLE%" stop %CMD_LINE_ARGS%
  +rem Execute the Launcher using the "catalina" target
  +"%JAVA_HOME%\bin\java.exe" -classpath %PRG%\..;"%PATH%" LauncherBootstrap 
-launchfile catalina.xml -verbose catalina %CMD_LINE_ARGS% stop
   
   :end
  
  
  
  1.2   +11 -13jakarta-tomcat-catalina/catalina/src/bin/shutdown.sh
  
  Index: shutdown.sh
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/src/bin/shutdown.sh,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- shutdown.sh   18 Jul 2002 16:48:14 -  1.1
  +++ shutdown.sh   1 Aug 2002 04:59:24 -   1.2
  @@ -1,14 +1,15 @@
   #!/bin/sh
  +
   # -
  -# Stop script for the CATALINA Server
   #
  -# $Id$
  +# Script for shutting down Catalina using the Launcher
  +#
   # -
   
  -# re

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup Constants.java ContextConfig.java

[patrickl]

patrickl2002/07/31 21:53:03

  Modified:catalina/src/share/org/apache/catalina/startup
Constants.java ContextConfig.java
  Log:
  Correct resource locations to match patch to jakarta-servletapi-5 build
  
  Revision  ChangesPath
  1.3   +7 -7  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Constants.java
  
  Index: Constants.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Constants.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- Constants.java1 Aug 2002 00:21:30 -   1.2
  +++ Constants.java1 Aug 2002 04:53:03 -   1.3
  @@ -95,7 +95,7 @@
   public static final String TldSchemaPublicId_20 =
   "web-jsptaglibrary_2_0.xsd";
   public static final String TldSchemaResourcePath_20 =
  -"/javax/servlet/resources/web-jsptaglibrary_2_0.xsd";
  +"/javax/servlet/jsp/resources/web-jsptaglibrary_2_0.xsd";
   
   public static final String WebDtdPublicId_22 =
   "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN";
  @@ -109,7 +109,7 @@
   //  "conf/web_23.dtd";
   "/javax/servlet/resources/web-app_2_3.dtd";
   
  -public static final String WebSchemaPubliId_24 =
  +public static final String WebSchemaPublicId_24 =
   "web-app_2_4.xsd";
   public static final String WebSchemaResourcePath_24 =
   "/javax/servlet/resources/web-app_2_4.xsd";
  @@ -127,6 +127,6 @@
   public static final String JspSchemaPublicId_20 =
   "jsp_2_0.xsd";
   public static final String JspSchemaResourcePath_20 =
  -"/javax/servlet/resources/jsp_2_0.xsd";
  +"/javax/servlet/jsp/resources/jsp_2_0.xsd";
   
   }
  
  
  
  1.4   +7 -4  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java
  
  Index: ContextConfig.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- ContextConfig.java1 Aug 2002 00:21:30 -   1.3
  +++ ContextConfig.java1 Aug 2002 04:53:03 -   1.4
  @@ -535,6 +535,9 @@
url.toString());
   
   url = ContextConfig.class.getResource(Constants.WebSchemaResourcePath_24);
  +webDigester.register(Constants.WebSchemaPublicId_24,
  + url.toString());
  +
   
   // to support servlet.jar that does not contains the schema
   if (url != null){
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: webapp/apr cvs tags?

[Pier Fumagalli]

"Punky Tse" <[EMAIL PROTECTED]> wrote:

> Neil,
> 
> I will try tonight if I encounter the same problem.  BTW, if you can
> choose, why not move to httpd 2.0?  At least Pier and me support it! ;-)

That's for sure! :) Apache 2.0 rocks :)

Pier


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[PATCH] jakarta-servletapi-5

[Patrick Luby]

Please apply the attached patch. It adds all of the new *.xsd files to 
the servlet.jar.

Also, please cvs remove the following file as it does not appear to be used:

src/share/dtd/web-app_2_3.dtd.backup

Thanks,

Patrick

-- 

Patrick Luby Email: [EMAIL PROTECTED]
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900



Index: build.xml
===
RCS file: /home/cvspublic/jakarta-servletapi-5/build.xml,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 build.xml
--- build.xml   16 Jul 2002 16:38:40 -  1.1.1.1
+++ build.xml   1 Aug 2002 04:24:42 -
@@ -71,16 +71,21 @@
 
 
 
-
-  
+
+  
+  
+  
+  
 
 
 
 
 
 
-  
-  
+  
+  
+  
+  
 
 
 



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: mod_jk, mod_jk2 URI spaces

[Mladen Turk]

> -Original Message-
> From: Bojan Smojver [mailto:[EMAIL PROTECTED]] 
> Sent: Thursday, August 01, 2002 12:00 AM
> To: Tomcat Dev List
> Subject: RE: mod_jk, mod_jk2 URI spaces
> 
> This above sentence is confusing. You probably meant 
> configuration options as a series of include/exclude 
> switches, rsync style.
>

Yes something like that.
This will allow to serve the compiled applications and still deliver the
static context from those locations, overlaying Apache URI space (if
set) over already resolved TC uri space. 
Well, at least the configuration will be IMHO easier.

> 
> PS. Given 1.2.0 is due for a release when Henri comes back 
> from holidays (in about 2 weeks time), are you planning the 
> patches for this before of after the release?
> 

After 1.2.0, If I figure out how to do that cross-server.
I'll make that for jk2 first, I hope :).

MT.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: webapp/apr cvs tags?

[Punky Tse]

Neil,

I will try tonight if I encounter the same problem.  BTW, if you can 
choose, why not move to httpd 2.0?  At least Pier and me support it! ;-)

Punky

Neil Cronin wrote:
> I'm trying to build mod_webapp for apache 1.3.26.  I grabbed webapp and 
> apr from cvs.apache.org.  it seems to build fine:
> 
> # ./configure --with-apr=../apr/ --with-apxs
> (configure output)
> # make
> (make output)
> Coonfiguration details:
> 
> module version:  mod_webapp/1.2.0-dev
> httpd version:   Apache/1.3.26 (Unix)
> host machine/os: i686-pc-linux-gnu
> cration date:Tue Jul 30 04:58:30 PDT 2002
> 
> All done...
> 
> # cp apache-1.3/mod_webapp.so /etc/apache/modules
> # /usr/sbin/apache
> Syntax error on line 63 of /etc/apache/conf/apache.conf:
> Cannot load /etc/apache/modules/mod_webapp.so into server: 
> /etc/apache/modules/mod_webapp.so: undefined symbol: apr_thread_mutex_lock
> 
> 
> I've tried mod_webapp 1.0.1 with similar results.  is this a known 
> issue?   is there a 1.1 branch of webapp that I can try?  or another 
> version of apr?
> 
> thanks,
> neil




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java

[luehe]

luehe   2002/07/31 19:12:06

  Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
  Log:
  more compilation error fixes for generated tag handler files
  
  Revision  ChangesPath
  1.54  +25 -25
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.53
  retrieving revision 1.54
  diff -u -r1.53 -r1.54
  --- Generator.java1 Aug 2002 00:32:29 -   1.53
  +++ Generator.java1 Aug 2002 02:12:05 -   1.54
  @@ -1736,7 +1736,7 @@
   
   public void visit(Node.ParamAction n) throws JasperException {
out.printin("params.put(");
  - out.print(n.getAttributeValue("name"));
  + out.print(quote(n.getAttributeValue("name")));
out.print(", ");
out.print(attributeValue(n.getValue(), false,
 String.class, "null"));
  @@ -1765,9 +1765,9 @@
// Store varReader in appropriate scope
if (varReader != null) {
String scopeName = n.getAttributeValue("scope");
  - out.printin("jspContext.setAttribute(\"");
  - out.print(varReader);
  - out.print("\", new java.io.StringReader(sout.toString())");
  + out.printin("getJspContext().setAttribute(");
  + out.print(quote(varReader));
  + out.print(", new java.io.StringReader(sout.toString())");
if (scopeName != null) {
out.print(", ");
out.print(getScopeConstant(scopeName));
  @@ -1785,7 +1785,7 @@
   
   public void visit(Node.ParamAction n) throws JasperException {
out.printin("params.put(");
  - out.print(n.getAttributeValue("name"));
  + out.print(quote(n.getAttributeValue("name")));
out.print(", ");
out.print(attributeValue(n.getValue(), false,
 String.class, "null"));
  @@ -1812,14 +1812,14 @@
out.printin("params.put(");
String name = tagVars[i].getNameGiven();
if (name != null) {
  - out.print(name);
  - out.print(", jspContext.getAttribute(");
  - out.print(name);
  + out.print(quote(name));
  + out.print(", getJspContext().getAttribute(");
  + out.print(quote(name));
out.println("));");
} else {
String getter = 
toGetterMethod(tagVars[i].getNameFromAttribute());
out.print(getter);
  - out.print(", jspContext.getAttribute(");
  + out.print(", getJspContext().getAttribute(");
out.print(getter);
out.println("));");
}
  @@ -1838,9 +1838,9 @@
// Store varReader in appropriate scope
if (varReader != null) {
String scopeName = n.getAttributeValue("scope");
  - out.printin("jspContext.setAttribute(\"");
  - out.print(varReader);
  - out.print("\", new java.io.StringReader(sout.toString())");
  + out.printin("getJspContext().setAttribute(");
  + out.print(quote(varReader));
  + out.print(", new java.io.StringReader(sout.toString())");
if (scopeName != null) {
out.print(", ");
out.print(getScopeConstant(scopeName));
  @@ -2777,8 +2777,8 @@
// if 'varReader' attribute is specified
out.printil("java.io.Writer sout = null;");
   
  - out.printil("javax.servlet.jsp.JspWriter out = jspContext.getOut();");
  - out.printil("jspContext.pushPageScope();");
  + out.printil("javax.servlet.jsp.JspWriter out = getJspContext().getOut();");
  + out.printil("getJspContext().pushPageScope(null);");
generatePageScopedVariables(tagInfo);
out.printil("try {");
out.pushIndent();
  @@ -2788,7 +2788,7 @@
   out.popIndent();
   out.printil("} finally {");
   out.pushIndent();
  -out.printil("jspContext.popPageScope();");
  +out.printil("getJspContext().popPageScope();");
   out.popIndent();
out.printil("}");
out.println();
  @@ -2936,9 +2936,9 @@
if (attrInfos != null) {
for (int i=0; imailto:[EMAIL PROTECTED]>
For additional commands, e-mail: 

Re: New coyote branch

[Peter Lin]

 
I believe remmy is on vacation and is moving to france :)
I guess someone else will have to do it.
 
peter
 Justyna Horwat wrote:I looked in jakarta-tomcat-connectors and it doesn't look like 
jakarta-tomcat-connectors has been branched yet. I checked the archives 
and saw the vote results where it was decided that the HEAD of 
jakarta-tomcat-connectors will be used for Tomcat 5 and Coyote 1.0 would 
be branched.

I'd like to request that this branch be created. Remy?

The reason I ask is that I'm working on a servlet 2.4 servlet request 
events implementation which involves modifying CoyoteRequest.java.

Thanks!

Justy



--
To unsubscribe, e-mail: 
For additional commands, e-mail: 



-
Do You Yahoo!?
Yahoo! Health - Feel better, live better

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core StandardHostDeployer.java

[amyroh]

amyroh  2002/07/31 18:41:43

  Modified:catalina/src/share/org/apache/catalina/core
StandardHostDeployer.java
  Log:
  Minor change that fixes a bug when an application is undeployed (removed),
  ContatinerEvent with the value of REMOVE_EVENT is fired.
  
  Submitted by Jeanfrancois Arcand.
  
  Revision  ChangesPath
  1.10  +5 -4  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardHostDeployer.java
  
  Index: StandardHostDeployer.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardHostDeployer.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- StandardHostDeployer.java 9 Apr 2002 23:48:21 -   1.9
  +++ StandardHostDeployer.java 1 Aug 2002 01:41:43 -   1.10
  @@ -418,6 +418,7 @@
   host.log(sm.getString("standardHost.removing", contextPath));
   try {
   host.removeChild(context);
  +host.fireContainerEvent(REMOVE_EVENT, context);
   } catch (Exception e) {
   host.log(sm.getString("standardHost.removeError", contextPath), e);
   throw new IOException(e.toString());
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core StandardHostDeployer.java

[amyroh]

amyroh  2002/07/31 18:40:49

  Modified:catalina/src/share/org/apache/catalina/core
StandardHostDeployer.java
  Log:
  Minor change that fixes a bug when an application is undeployed (removed),
  ContatinerEvent with the value of REMOVE_EVENT is fired.
  
  Submitted by Jeanfrancois Arcand.
  
  Revision  ChangesPath
  1.2   +5 -4  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardHostDeployer.java
  
  Index: StandardHostDeployer.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardHostDeployer.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- StandardHostDeployer.java 18 Jul 2002 16:48:05 -  1.1
  +++ StandardHostDeployer.java 1 Aug 2002 01:40:49 -   1.2
  @@ -418,6 +418,7 @@
   host.log(sm.getString("standardHost.removing", contextPath));
   try {
   host.removeChild(context);
  +host.fireContainerEvent(REMOVE_EVENT, context);
   } catch (Exception e) {
   host.log(sm.getString("standardHost.removeError", contextPath), e);
   throw new IOException(e.toString());
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

New coyote branch

[Justyna Horwat]

I looked in jakarta-tomcat-connectors and it doesn't look like 
jakarta-tomcat-connectors has been branched yet. I checked the archives 
and saw the vote results where it was decided that the HEAD of 
jakarta-tomcat-connectors will be used for Tomcat 5 and Coyote 1.0 would 
be branched.

I'd like to request that this branch be created. Remy?

The reason I ask is that I'm working on a servlet 2.4 servlet request 
events implementation which involves modifying CoyoteRequest.java.

Thanks!

Justy



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[PATCH][jakarta-tomcat-catalina]

[Jean-francois Arcand]

Hi,

this minor change fixes a bug : when an appllication is undeployed 
(removed), ContainerEvent with the value of REMOVE_EVENT are fired.

The bug is also in jakarta-tomcat-4. Should I send another patch?

Thanks,

-- Jeanfrancois



Index: StandardHostDeployer.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/StandardHostDeployer.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 StandardHostDeployer.java
--- StandardHostDeployer.java   18 Jul 2002 16:48:05 -  1.1.1.1
+++ StandardHostDeployer.java   1 Aug 2002 00:58:15 -
@@ -418,7 +418,8 @@
 host.log(sm.getString("standardHost.removing", contextPath));
 try {
 host.removeChild(context);
-} catch (Exception e) {
+host.fireContainerEvent(REMOVE_EVENT, context);
+   } catch (Exception e) {
 host.log(sm.getString("standardHost.removeError", contextPath), e);
 throw new IOException(e.toString());
 }



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java

[luehe]

luehe   2002/07/31 17:32:29

  Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
  Log:
  fixed some compilation errors in generated tag handler file
  
  Revision  ChangesPath
  1.53  +16 -11
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.52
  retrieving revision 1.53
  diff -u -r1.52 -r1.53
  --- Generator.java31 Jul 2002 23:04:47 -  1.52
  +++ Generator.java1 Aug 2002 00:32:29 -   1.53
  @@ -1815,13 +1815,13 @@
out.print(name);
out.print(", jspContext.getAttribute(");
out.print(name);
  - out.println(");");
  + out.println("));");
} else {
String getter = 
toGetterMethod(tagVars[i].getNameFromAttribute());
out.print(getter);
out.print(", jspContext.getAttribute(");
out.print(getter);
  - out.println(");");
  + out.println("));");
}
}
}
  @@ -2757,7 +2757,8 @@
out.print(" extends javax.servlet.jsp.tagext.SimpleTagSupport");
if (tagInfo.hasDynamicAttributes())
out.print(" implements javax.servlet.jsp.tagext.DynamicAttributes");
  - out.print(" {");
  + out.println(" {");
  + out.println();
out.pushIndent();

// Class body begins here
  @@ -2767,14 +2768,14 @@
if (tagInfo.hasDynamicAttributes())
generateSetDynamicAttribute();
   
  - out.printil("public int doTag() throws JspException {");
  + out.printil("public int doTag() throws javax.servlet.jsp.JspException {");
out.pushIndent();
// Declare parameter map for fragment/body invocation
  - out.println("java.util.Map params = null;");
  + out.printil("java.util.Map params = null;");
   
// Declare writer used for storing result of fragment/body invocation
// if 'varReader' attribute is specified
  - out.println("java.io.Writer sout = null;");
  + out.printil("java.io.Writer sout = null;");
   
out.printil("javax.servlet.jsp.JspWriter out = jspContext.getOut();");
out.printil("jspContext.pushPageScope();");
  @@ -2820,6 +2821,7 @@
out.print(attrInfos[i].getName());
out.println(";");
}
  + out.println();
}
   
// Declare fragment attributes
  @@ -2829,6 +2831,7 @@
out.print(fragAttrInfos[i].getName());
out.println(";");
}
  + out.println();
}
   
// Define getter and setter methods for "normal" attributes
  @@ -2860,6 +2863,7 @@
out.println(";");
out.popIndent();
out.printil("}");
  + out.println();
}
}
   
  @@ -2892,6 +2896,7 @@
out.println(";");
out.popIndent();
out.printil("}");
  + out.println();
}
}
   }
  @@ -2931,7 +2936,7 @@
if (attrInfos != null) {
for (int i=0; imailto:[EMAIL PROTECTED]>
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup Constants.java ContextConfig.java

[amyroh]

amyroh  2002/07/31 17:21:30

  Modified:catalina/src/share/org/apache/catalina/startup
Constants.java ContextConfig.java
  Log:
  Add support for Web App Deployment Descriptor that uses XML Schema (Servlet 2.4)
  
  Submitted by Jeanfrancois Arcand.
  
  Revision  ChangesPath
  1.2   +30 -4 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Constants.java
  
  Index: Constants.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/Constants.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- Constants.java18 Jul 2002 16:47:48 -  1.1
  +++ Constants.java1 Aug 2002 00:21:30 -   1.2
  @@ -69,6 +69,7 @@
* String constants for the startup package.
*
* @author Craig R. McClanahan
  + * @author Jean-Francois Arcand
* @version $Revision$ $Date$
*/
   
  @@ -91,6 +92,11 @@
   //"conf/tld_12.dtd";
   "/javax/servlet/jsp/resources/web-jsptaglibrary_1_2.dtd";
   
  +public static final String TldSchemaPublicId_20 =
  +"web-jsptaglibrary_2_0.xsd";
  +public static final String TldSchemaResourcePath_20 =
  +"/javax/servlet/resources/web-jsptaglibrary_2_0.xsd";
  +
   public static final String WebDtdPublicId_22 =
   "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN";
   public static final String WebDtdResourcePath_22 =
  @@ -102,5 +108,25 @@
   public static final String WebDtdResourcePath_23 =
   //  "conf/web_23.dtd";
   "/javax/servlet/resources/web-app_2_3.dtd";
  +
  +public static final String WebSchemaPubliId_24 =
  +"web-app_2_4.xsd";
  +public static final String WebSchemaResourcePath_24 =
  +"/javax/servlet/resources/web-app_2_4.xsd";
  +
  +public static final String J2eeSchemaPublicId_14 =
  +"j2ee_1_4.xsd";
  +public static final String J2eeSchemaResourcePath_14 =
  +"/javax/servlet/resources/j2ee_1_4.xsd";
  +
  +public static final String W3cSchemaPublicId_10 =
  +"xml.xsd";
  +public static final String W3cSchemaResourcePath_10 =
  +"/javax/servlet/resources/xml.xsd";
  +
  +public static final String JspSchemaPublicId_20 =
  +"jsp_2_0.xsd";
  +public static final String JspSchemaResourcePath_20 =
  +"/javax/servlet/resources/jsp_2_0.xsd";
   
   }
  
  
  
  1.3   +63 -5 
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java
  
  Index: ContextConfig.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/startup/ContextConfig.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- ContextConfig.java30 Jul 2002 03:58:27 -  1.2
  +++ ContextConfig.java1 Aug 2002 00:21:30 -   1.3
  @@ -133,6 +133,7 @@
* of that Context, and the associated defined servlets.
*
* @author Craig R. McClanahan
  + * @author Jean-Francois Arcand
* @version $Revision$ $Date$
*/
   
  @@ -483,6 +484,34 @@
   url = ContextConfig.class.getResource(Constants.TldDtdResourcePath_12);
   tldDigester.register(Constants.TldDtdPublicId_12,
url.toString());
  +
  +url = ContextConfig.class.getResource(Constants.TldSchemaResourcePath_20);
  +// to support servlet.jar that does not contains the schema
  +if (url != null){
  +tldDigester.setSchema(url.toString());
  +}
  +
  +// Add local copy of Servlet 2.4 XML Schema instance.
  +url = ContextConfig.class.getResource(Constants.J2eeSchemaResourcePath_14);
  +tldDigester.register(Constants.J2eeSchemaPublicId_14,
  + url.toString());
  +
  +url = ContextConfig.class.getResource(Constants.W3cSchemaResourcePath_10);
  +tldDigester.register(Constants.W3cSchemaPublicId_10,
  + url.toString());
  +
  +url = ContextConfig.class.getResource(Constants.JspSchemaResourcePath_20);
  +tldDigester.register(Constants.JspSchemaPublicId_20,
  + url.toString());
  +
  +url = ContextConfig.class.getResource(Constants.W3cSchemaResourcePath_10);
  +tldDigester.register(Constants.W3cSchemaPublicId_10,
  + url.toString());
  +
  +url = ContextConfig.class.getResource(Constants.TldSchemaResourcePath_20);
  +tldDigester.register(Constants.TldSchemaPublicId_20,
  + url.toString());
  +
   tldDigester.addRuleSet(new TldRuleSet());
   return (tldDigester);
   
  @@ -504,6 +533,35 @@
   url = ContextConfig.class.get

cvs commit: jakarta-servletapi-5/src/share/dtd XMLSchema.dtd datatypes.dtd xml.xsd

[kinman]

kinman  2002/07/31 17:12:24

  Added:   src/share/dtd XMLSchema.dtd datatypes.dtd xml.xsd
  Log:
  - Patfh supplied by Mark Roth.
  
three files should be added to enable parsing of DDs and TLDs without
needing to fetch these schemas from their global URL each time:
  
 src/share/dtd/xml.xsd
 src/share/dtd/XMLSchema.dtd
 src/share/dtd/datatypes.dtd
  
  Revision  ChangesPath
  1.1  jakarta-servletapi-5/src/share/dtd/XMLSchema.dtd
  
  Index: XMLSchema.dtd
  ===
  
  
 
  
   

  
  
  
  
  
   
   
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  

  

  
  
  
  
  
  
  
  
  
  
  
  
  
  %xs-datatypes;
  
  
  
  http://www.w3.org/2001/XMLSchema'
 xmlnsCDATA  #IMPLIED
 finalDefault %complexDerivationSet; ''
 blockDefault %blockSet; ''
 id   ID #IMPLIED
 elementFormDefault   %formValues;   'unqualified'
 attributeFormDefault %formValues;   'unqualified'
 xml:lang CDATA  #IMPLIED
 %schemaAttrs;>
  
  
   
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
 
  
 
  
  
  http://www.w3.org/2001/XMLSchema.xsd' >
  http://www.w3.org/TR/1998/REC-xml-19980210' >
  
  
  
  1.1  jakarta-servletapi-5/src/share/dtd/datatypes.dtd
  
  Index: datatypes.dtd
  ===
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  1.1  jakarta-servletapi-5/src/share/dtd/xml.xsd
  
  Index: xml.xsd
  ===
  
  
  http://www.w3.org/XML/1998/namespace"; 
xmlns:xs="http://www.w3.org/2001/XMLSchema"; xml:lang="en">
  
   

 See http://www.w3.org/XML/1998/namespace.html and
 http://www.w3.org/TR/REC-xml for information about this namespace.

   
  
   
This schema defines attributes and an attribute group
  suitable for use by
  schemas wishing to allow xml:base, xml:lang or xml:space attributes
  on elements they define.
  
  To enable this, such a schema must import this schema
  for the XML namespace, e.g. as follows:
  
   . . .
   
  
  Subsequently, qualified reference to any of the attributes
  or the group defined below will have the desired effect, e.g.
  
  
   . . .
   
   
   will define a type which will schema-validate an instance
   element with any of those attributes
   
  
   
In keeping with the XML Schema WG's standard versioning
 policy, this schema document will persist at
 http://www.w3.org/2001/03/xml.xsd.
 At the date of issue it can also be found at
 http://www.w3.org/2001/xml.xsd.
 The schema document at that URI may however change in the future,
 in order to remain compatible with the latest version of XML Schema
 itself.  In other words, if the XML Schema namespace changes, the version
 of this document at
 http://www.w3.org/2001/xml.xsd will change
 accordingly; the version at
 http://www.w3.org/2001/03/xml.xsd will not change.

   
  
   

 In due course, we should install the relevant ISO 2- and 
3-letter
   codes as the enumerated possible values . . .

   
  
   

 
  
  
 

   
  
   

 See http://www.w3.org/TR/xmlbase/ for
   information about this attribute.

   
  
   



   
  
  
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-servletapi-5/src/share/javax/servlet/http HttpServletResponse.java

[kinman]

kinman  2002/07/31 17:05:58

  Modified:src/share/javax/servlet/http HttpServletResponse.java
  Log:
  - Patch supplied by Bob Herrmann.
  
"The 2.4 Servlet spec adds a new constant. See section 15.1.5 in the June
24th public draft."
  
  Revision  ChangesPath
  1.2   +13 -0 
jakarta-servletapi-5/src/share/javax/servlet/http/HttpServletResponse.java
  
  Index: HttpServletResponse.java
  ===
  RCS file: 
/home/cvs/jakarta-servletapi-5/src/share/javax/servlet/http/HttpServletResponse.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- HttpServletResponse.java  16 Jul 2002 16:38:41 -  1.1
  +++ HttpServletResponse.java  1 Aug 2002 00:05:58 -   1.2
  @@ -445,9 +445,22 @@
* Status code (302) indicating that the resource has temporarily
* moved to another location, but that future references should
* still use the original URI to access the resource.
  + *
  + * This definition is being retained for backwards compatibility.
  + * SC_FOUND is now the preferred definition.
*/
   
   public static final int SC_MOVED_TEMPORARILY = 302;
  +
  +/**
  +* Status code (302) indicating that the resource reside
  +* temporarily under a different URI. Since the redirection might
  +* be altered on occasion, the client should continue to use the
  +* Request-URI for future requests.(HTTP/1.1) To represent the
  +* status code (302), it is recommended to use this variable.
  +*/
  +
  +public static final int SC_FOUND = 302;
   
   /**
* Status code (303) indicating that the response to the request
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-servletapi-5/src/share/javax/servlet ServletRequestAttributeEvent.java ServletRequestAttributeListener.java ServletRequestEvent.java ServletRequestListener.java

[kinman]

kinman  2002/07/31 16:58:11

  Added:   src/share/javax/servlet ServletRequestAttributeEvent.java
ServletRequestAttributeListener.java
ServletRequestEvent.java
ServletRequestListener.java
  Log:
  - Justyna Horwat supplied this patch.
  
"adds support for Servlet 2.4 servlet request events."
  
  Revision  ChangesPath
  1.1  
jakarta-servletapi-5/src/share/javax/servlet/ServletRequestAttributeEvent.java
  
  Index: ServletRequestAttributeEvent.java
  ===
  /*
   * The Apache Software License, Version 1.1
   *
   * Copyright (c) 1999 The Apache Software Foundation.  All rights 
   * reserved.
   *
   * Redistribution and use in source and binary forms, with or without
   * modification, are permitted provided that the following conditions
   * are met:
   *
   * 1. Redistributions of source code must retain the above copyright
   *notice, this list of conditions and the following disclaimer. 
   *
   * 2. Redistributions in binary form must reproduce the above copyright
   *notice, this list of conditions and the following disclaimer in
   *the documentation and/or other materials provided with the
   *distribution.
   *
   * 3. The end-user documentation included with the redistribution, if
   *any, must include the following acknowlegement:  
   *   "This product includes software developed by the 
   *Apache Software Foundation (http://www.apache.org/)."
   *Alternately, this acknowlegement may appear in the software itself,
   *if and wherever such third-party acknowlegements normally appear.
   *
   * 4. The names "The Jakarta Project", "Tomcat", and "Apache Software
   *Foundation" must not be used to endorse or promote products derived
   *from this software without prior written permission. For written 
   *permission, please contact [EMAIL PROTECTED]
   *
   * 5. Products derived from this software may not be called "Apache"
   *nor may "Apache" appear in their names without prior 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
   * .
   *
   * 
   *
   * This source code implements specifications defined by the Java
   * Community Process. In order to remain compliant with the specification
   * DO NOT add / change / or delete method signatures!
   */
  
  package javax.servlet;
  
  
  /** 
* This is the event class for notifications about changes to the 
* attributes of the servlet request of a web application.
* @see ServletRequestAttributeListener
* @sincev 2.4
*/
  
  public class ServletRequestAttributeEvent extends ServletRequestEvent { 
  private String name;
  private Object value;
  
  /** Construct a ServletRequestAttributeEvent from the given context for the
* given attribute name and attribute value. 
*
* @param sc - the ServletContext that is sending the event.
* @param request - the ServletRequest that is sending the event.
* @param name - the name of the request attribute.
* @param value - the value of the request attribute.
*/
  public ServletRequestAttributeEvent(ServletContext sc, ServletRequest request, 
String name, Object value) {
  super(sc, request);
  this.name = name;
  this.value = value;
  }
  
  /**
* Return the name of the attribute that changed on the ServletRequest.
*
* @return String - the name of the changed request attribute.
*/
  public String getName() {
  return this.name;
  }
  
  /**
* Returns the value of the attribute that has been added removed or 
* replaced. If th

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler ImplicitTagLibraryInfo.java TagFileProcessor.java

[luehe]

luehe   2002/07/31 16:45:50

  Modified:jasper2/src/share/org/apache/jasper/compiler
ImplicitTagLibraryInfo.java TagFileProcessor.java
  Log:
  Modified implicit taglibrary generator to populate new "tagFiles"
  field in TagLibraryInfo
  
  Revision  ChangesPath
  1.5   +22 -14
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ImplicitTagLibraryInfo.java
  
  Index: ImplicitTagLibraryInfo.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ImplicitTagLibraryInfo.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- ImplicitTagLibraryInfo.java   31 Jul 2002 22:46:27 -  1.4
  +++ ImplicitTagLibraryInfo.java   31 Jul 2002 23:45:50 -  1.5
  @@ -63,6 +63,7 @@
   import java.util.*;
   import javax.servlet.jsp.tagext.TagLibraryInfo;
   import javax.servlet.jsp.tagext.TagInfo;
  +import javax.servlet.jsp.tagext.TagFileInfo;
   import org.apache.jasper.JspCompilationContext;
   import org.apache.jasper.JasperException;
   
  @@ -101,7 +102,8 @@
err.jspError("jsp.error.invalid.tagdir", tagdir);
}

  - // Determine the value of the  element
  + // Determine the value of the  subelement of the
  + // "imaginary"  element
if (tagdir.equals(WEB_INF_TAGS)) {
shortname = TAGS_SHORTNAME;
} else {
  @@ -111,24 +113,30 @@
   
Set dirList = ctxt.getResourcePaths(tagdir);
if (dirList != null) {
  - Vector tagVector = new Vector();
  + Vector vec = new Vector();
Iterator it = dirList.iterator();
while (it.hasNext()) {
String path = (String) it.next();
  - if (path.endsWith(".tld")) {
  + if (path.endsWith(TLD_SUFFIX)) {
tldFile = path;
break;
  - } else if (path.endsWith(".tag")) {
  - tagVector.addElement(
  -TagFileProcessor.parseTagFile(pc,
  -   shortname,
  -   path,
  -   this)); 
  + } else if (path.endsWith(TAG_FILE_SUFFIX)) {
  + // use the filename of the tag file, without the .tag
  + // extension, as the  subelement of the "imaginary"
  + //  element
  + String tagName = path.substring(path.lastIndexOf("/") + 1);
  + tagName = tagName.substring(0,
  + tagName.lastIndexOf(TAG_FILE_SUFFIX));
  + TagInfo tagInfo = TagFileProcessor.parseTagFile(pc,
  + tagName,
  + path,
  + this); 
  + vec.addElement(new TagFileInfo(tagName, path, tagInfo));
}
}
   
  - tags = new TagInfo[tagVector.size()];
  - tagVector.copyInto (this.tags);
  + this.tagFiles = new TagFileInfo[vec.size()];
  + vec.copyInto(this.tagFiles);
}
   }
   
  
  
  
  1.6   +6 -6  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagFileProcessor.java
  
  Index: TagFileProcessor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/TagFileProcessor.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- TagFileProcessor.java 31 Jul 2002 21:42:27 -  1.5
  +++ TagFileProcessor.java 31 Jul 2002 23:45:50 -  1.6
  @@ -311,8 +311,9 @@
* handler that it represents is referenced.  The tag file is not compiled
* here.
* @param pc the current ParserController used in this compilation
  - * @param tagile the path for the tagfile
  - * @param tagLibInfo the TaglibraryInfo object associated with this TagInfo
  + * @param name the tag name as specified in the TLD
  + * @param tagfile the path for the tagfile
  + * @param tagLibInfo the TagLibraryInfo object associated with this TagInfo
* @return a TagInfo object assembled from the directives in the tag file.
*/
   public static TagInfo parseTagFile(ParserController pc,
  @@ -321,7 +322,6 @@
   TagLibraryInfo tagLibInfo)
   throws JasperException {
   
  -
   Node.Nodes page = null;
try {
page = pc.parse(tagfile);
  @@ -342,7 +342,7 @@
* Compiles and loads a tagfile.
*/
   public st

[PATCH] jakarta-servletapi-5

[Mark Roth]

The attached archive contains three files that should be added to
jakarta-servletapi-5 to enable parsing of DDs and TLDs without needing
to fetch these schemas from their global URL each time.  Contains:

   src/share/dtd/xml.xsd
   src/share/dtd/XMLSchema.dtd
   src/share/dtd/datatypes.dtd

Please let me know if there are any questions or concerns.

-- 
Mark Roth, Java Software
JSP 2.0 Specification co-lead
Sun Microsystems, Inc.



jakarta-servletapi-5-localschemas-patch.tar
Description: Unix tar archive

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler Generator.java

[luehe]

luehe   2002/07/31 16:04:47

  Modified:jasper2/src/share/org/apache/jasper/compiler Generator.java
  Log:
  Added note that JSP 2.0 spec still needs to clarify what the variable name for a 
dynamic attribute looks like
  
  Revision  ChangesPath
  1.52  +5 -3  
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.51
  retrieving revision 1.52
  diff -u -r1.51 -r1.52
  --- Generator.java31 Jul 2002 21:42:27 -  1.51
  +++ Generator.java31 Jul 2002 23:04:47 -  1.52
  @@ -2907,6 +2907,8 @@
out.pushIndent();
out.printil("if (uri != null)");
out.pushIndent();
  + // XXX Specification still needs to clarify what the variable name
  + // looks like. Assume _ for now.
out.printil("dynamicAttrs.put(uri + \"_\" + localName, value);");
out.popIndent();
out.printil("else");
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 11352] New: - clientauth="false" equivalent to clientauth="true"

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=11352

clientauth="false" equivalent to clientauth="true"

   Summary: clientauth="false" equivalent to clientauth="true"
   Product: Tomcat 3
   Version: 3.3.1 Final
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Auth
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Environment:
J2SDK1.4, Red Hat Linux 7.3, using Tomcat as the web server (no other web server
on the machine). Used both Netscape Communicator 4.79 and Mozilla 0.9.9 with
same results.

As per jakarta-tomcat-3.3.1/doc/tomcat-ssl-howto.html, I wrote this entry in
server.xml and then restarted Tomcat:



When I opened https://localhost:8443/index.html in my Netscape browser, I
received several certificate dialogs (as expected, and which demonstrate that
Tomcat successfully found the keystore) and then I received an error message
that stated that localhost had requested client authorization but that I did not
have a personal certificate. For what it's worth, Tomcat also complained about
the missing client certificate:

Using classpath: /home/davpfg2/jakarta-tomcat-3.3.1/bin/../lib/tomcat.jar
Using JAVA_HOME: /usr/java/j2sdk1.4.0_01
Using TOMCAT_HOME: /home/davpfg2/jakarta-tomcat-3.3.1
2002-07-30 20:45:29 - SessionIdGenerator: Opening /dev/urandom
2002-07-30 20:45:29 - ServerXmlReader: Config=$TOMCAT_HOME/conf/server.xml
2002-07-30 20:45:29 - PathSetter: home=/home/davpfg2/jakarta-tomcat-3.3.1
2002-07-30 20:45:29 - ContextXmlReader: Context
config=$TOMCAT_HOME/conf/apps-127.0.0.1.xml
2002-07-30 20:45:29 - ContextXmlReader: Context
config=$TOMCAT_HOME/conf/apps-admin.xml
2002-07-30 20:45:29 - ContextXmlReader: Context
config=$TOMCAT_HOME/conf/apps-examples.xml
2002-07-30 20:45:29 - AutoWebApp: Loaded from config: DEFAULT:/admin
2002-07-30 20:45:29 - AutoWebApp: Auto-Adding DEFAULT:/
2002-07-30 20:45:29 - AutoWebApp: Loaded from config: DEFAULT:/examples
2002-07-30 20:45:29 - AutoWebApp: Auto-Adding DEFAULT:/soap
2002-07-30 20:45:29 - ContextManager: Tomcat configured and in stable state 
2002-07-30 20:45:29 - ContextManager: Adding  DEFAULT:/admin
2002-07-30 20:45:29 - ContextManager: Adding  DEFAULT:/examples
2002-07-30 20:45:29 - ContextManager: Adding  DEFAULT:/ROOT
2002-07-30 20:45:29 - ContextManager: Adding  DEFAULT:/soap
EmbededTomcat: Init time 1603
2002-07-30 20:45:30 - Http10Interceptor: Starting on 8080
2002-07-30 20:45:30 - Http10Interceptor: Starting on 8443
2002-07-30 20:45:30 - Ajp12Interceptor: Starting on 8007
2002-07-30 20:45:30 - Ajp13Interceptor: Starting on 8009
EmbededTomcat: Startup time 680
PoolTcpEndpoint: Handshake failed
javax.net.ssl.SSLHandshakeException: javax.net.ssl.SSLProtocolException:
handshake alert:  no_certificate
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.b(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275)
at com.sun.net.ssl.internal.ssl.AppOutputStream.write(DashoA6275)
at java.io.OutputStream.write(OutputStream.java:58)
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(DashoA6275)
at
org.apache.tomcat.util.net.JSSESocketFactory.handshake(JSSESocketFactory.java:270)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:479)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:516)
at java.lang.Thread.run(Thread.java:536)
ThreadPool: Caught exception executing
org.apache.tomcat.util.net.TcpWorkerThread@f4f44a, terminating thread
java.lang.NullPointerException
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:498)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:516)
at java.lang.Thread.run(Thread.java:536)
Stop reaper 
SUPER org.apache.tomcat.util.qlog.LogDaemon@4c4975 Exiting
ContextManager: Exiting 

Workaround:
I double-checked the manual and found that the default is clientauth="false", so
I simply removed the clientauth line from server.xml and restarted Tomcat. When
I tried the URL again, my browser successfully displayed index.html.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler ImplicitTagLibraryInfo.java

[luehe]

luehe   2002/07/31 15:46:27

  Modified:jasper2/src/share/org/apache/jasper/compiler
ImplicitTagLibraryInfo.java
  Log:
  Supply name parameter to TagFileProcessor.parseTagFile()
  
  Revision  ChangesPath
  1.4   +8 -6  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ImplicitTagLibraryInfo.java
  
  Index: ImplicitTagLibraryInfo.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/ImplicitTagLibraryInfo.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- ImplicitTagLibraryInfo.java   26 Jul 2002 23:21:00 -  1.3
  +++ ImplicitTagLibraryInfo.java   31 Jul 2002 22:46:27 -  1.4
  @@ -119,9 +119,11 @@
tldFile = path;
break;
} else if (path.endsWith(".tag")) {
  - tagVector.addElement(TagFileProcessor.parseTagFile(pc,
  -path,
  -this)); 
  + tagVector.addElement(
  +TagFileProcessor.parseTagFile(pc,
  +   shortname,
  +   path,
  +   this)); 
}
}
   
  
  
  

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 11208] - form-based authentication failed to use the proper error page

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=11208

form-based authentication failed to use the proper error page





--- Additional Comments From [EMAIL PROTECTED]  2002-07-31 22:26 ---
I found this only happens when a user submitted the right username and password,
but doesn't have the required role. In all the other cases, the user will be
bounced back to the error page. I think Tomcat should provide a way to allow 
developers to display a default error page as long as the user is not 
authenticated.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: mod_jk, mod_jk2 URI spaces

[Bojan Smojver]

On Wed, 2002-07-31 at 23:55, Mladen Turk wrote:
> > Now I propose that we make something like _not_ URI space 
> > filtering. Meaning that one could be able to serve every 
> > .html file through TC except for the /*/some_space/ location. 
> > Right now we are checking and hoping that the TC will accept 
> > the context, and then we forget that immediately. I propose 
> > that we make the map_to_storage two way (If the TC accepts it 
> > and then checking if the Apache configuration rejects it).

This above sentence is confusing. You probably meant configuration
options as a series of include/exclude switches, rsync style.

> After I read my mail, it doesn't make sense even for me :)
> 
> For example (what I have in mind) using mod_jk:
> 
> JkMount /examples/*
> (This  will map /examples URI space and everything belonging to the
> /examples will be served by the TC).
> 
> JkNotMount /examples/*.gif
> JkNotMount /examples/*.jpg
> 
> (This  will map /examples URI space and everything will be served by the
> TC except the gif and jpg files).

I see your point here. You are running a setup where anything not
specifically targeted for Apache goes to Tomcat. As long as this doesn't
affect current situation (and I don't see how it would) where I can set
up that Tomcat only gets what's not specifically targeted for Apache,
I'm +1. This would make mod_jk configuration really flexible.

Bojan

PS. Given 1.2.0 is due for a release when Henri comes back from holidays
(in about 2 weeks time), are you planning the patches for this before of
after the release?


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/servlet JspServletWrapper.java

[kinman]

kinman  2002/07/31 14:42:28

  Modified:jasper2/src/share/org/apache/jasper
JspCompilationContext.java
   jasper2/src/share/org/apache/jasper/compiler Compiler.java
Generator.java JspDocumentParser.java Node.java
Parser.java ParserController.java
TagFileProcessor.java TagLibraryInfoImpl.java
Validator.java
   jasper2/src/share/org/apache/jasper/resources
messages.properties
   jasper2/src/share/org/apache/jasper/servlet
JspServletWrapper.java
  Log:
  - First cut at triggering compilations of tag files on demand.
  
Node: Not fully working yet.  Implicit tag file library not tested.
Use absolute path for tag file in TLD.
  
  Revision  ChangesPath
  1.11  +43 -5 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspCompilationContext.java
  
  Index: JspCompilationContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/JspCompilationContext.java,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- JspCompilationContext.java25 Jul 2002 22:28:45 -  1.10
  +++ JspCompilationContext.java31 Jul 2002 21:42:27 -  1.11
  @@ -65,6 +65,8 @@
   import java.net.*;
   import java.util.Set;
   import javax.servlet.ServletContext;
  +import javax.servlet.jsp.tagext.TagInfo;
  +
   import org.apache.jasper.compiler.JspRuntimeContext;
   import org.apache.jasper.compiler.JspReader;
   import org.apache.jasper.compiler.ServletWriter;
  @@ -116,6 +118,9 @@
   protected URL [] outUrls = new URL[1];
   protected Class servletClass;
   
  +protected boolean isTagFile;
  +protected TagInfo tagInfo;
  +
   // jspURI _must_ be relative to the context
   public JspCompilationContext(String jspUri, boolean isErrPage, Options options,
ServletContext context, JspServletWrapper jsw,
  @@ -141,6 +146,17 @@
   this.rctxt=rctxt;
   }
   
  +public JspCompilationContext(String tagfile, TagInfo tagInfo, 
  + Options options,
  + ServletContext context, JspServletWrapper jsw,
  + JspRuntimeContext rctxt) {
  +
  +this(tagfile, false, options, context, jsw, rctxt);
  +this.isTagFile = true;
  +this.tagInfo = tagInfo;
  +return;
  +}
  +
   /*  Methods to override  */
   
   /** -- Class path and loader -- */
  @@ -304,6 +320,14 @@
   this.isErrPage = isErrPage;
   }
   
  +public boolean isTagFile() {
  + return isTagFile;
  +}
  +
  +public TagInfo getTagInfo() {
  + return tagInfo;
  +}
  +
   /**
* Package name for the generated class.
*/
  @@ -351,6 +375,14 @@
   return options;
   }
   
  +public ServletContext getServletContext() {
  + return context;
  +}
  +
  +public JspRuntimeContext getRuntimeContext() {
  + return rctxt;
  +}
  +
   /**
* Path of the JSP relative to the work directory.
*/
  @@ -503,8 +535,14 @@
rctxt.getPermissionCollection(),
rctxt.getCodeSource());
   
  -servletClass = jspLoader.loadClass(
  - getServletPackageName() + "." + getServletClassName());
  +String className;
  +if (isTagFile()) {
  +className = tagInfo.getTagClassName();
  +} else {
  +className = getServletPackageName() + "." +
  +getServletClassName();
  +}
  +servletClass = jspLoader.loadClass(className);
   } catch (FileNotFoundException ex) {
   jspCompiler.removeGeneratedFiles();
   throw ex;
  
  
  
  1.22  +7 -3  
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.21
  retrieving revision 1.22
  diff -u -r1.21 -r1.22
  --- Compiler.java 19 Jul 2002 01:13:46 -  1.21
  +++ Compiler.java 31 Jul 2002 21:42:27 -  1.22
  @@ -241,6 +241,10 @@
// Collect page info
Collector.collect(this, pageNodes);
   
  + // Compile (if necessar) and load the tag files referenced in
  + // this compilation unit.
  + TagFileProcessor.loadTagFiles(this, pageNodes);
  +
// generate servlet .java file
Generator.generate(writer, 

prob with tomcat3.2.3 to tomcat 4.0

[junmei]

Hi,Everybody,
I have a question about migrating tomcat3.2.3 to Tomcat 4.0. I 've written
some web apps on Tomcat 3.2.3 + Wind98 + jdk1.3.1_02. How can I migrate my
web applications to Tomcat 4.0 + windows XP + J2SE1.4?
I've tried it ,but fail, when start tomcat 4.0 , it showed me an error msg:
Can't find Include method in jasper.jar runtime library. what's that mean?
how to solve the prob?

Thanks



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: how to do auto update/reload of a class?

[Craig R. McClanahan]

On Wed, 31 Jul 2002, Adrian Prezioso wrote:

> Date: Wed, 31 Jul 2002 11:36:45 -0700 (PDT)
> From: Adrian Prezioso <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: Re: how to do auto update/reload of a class?
>
> Craig,
> who controls loading and reloading jasper class
> loaders?  and how is it being managed?  I'm also
> working on a project where I need to auto-reload Java
> classes at runtime.  If you could point me to any kind
> of documentation, that'd be greatly appreciated.
>

The source code for JspServlet and friends is the best bet for figuring
this out.

> thanks,
> Adrian

Craig

>
> --- "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
> >
> >
> > On Wed, 31 Jul 2002, Babu Wisor wrote:
> >
> > > Date: Wed, 31 Jul 2002 10:15:08 -0700 (PDT)
> > > From: Babu Wisor <[EMAIL PROTECTED]>
> > > Reply-To: Tomcat Developers List
> > <[EMAIL PROTECTED]>
> > > To: Tomcat Developers List
> > <[EMAIL PROTECTED]>
> > > Cc: [EMAIL PROTECTED]
> > > Subject: Re: how to do auto update/reload of a
> > class?
> > >
> > > Hi All,
> > >   Does anyone have any thoughts as to how to
> > auto
> > > re-load the classes, which have been loaded into
> > JVM
> > > using Custom Class loader? I tried writing custom
> > > class loader and loaded all the classes, but don't
> > > know how to re-load the same class, if it has been
> > > modified (re-compiled) without shutting down JVM,
> > > similar to JSP engine, where if we put updated JSP
> > > file, it picks up the new file.
> > >
> >
> > Jasper does this by creating a class loader for each
> > page, and throwing
> > away the class loader when the page is recompiled.
> > The JVM doesn't let
> > you do things any other way.
> >
> > > Note: I learnt that, we need to recreate new class
> > > loader and load all the classes again, but don't
> > know
> > > exactly how to apply that technique in the system.
> > Any
> > > help is greatly appreciated.
> > >
> >
> > My personal advice, after living through (barely :-)
> > getting a class
> > loader that would reload a webapp to work, is to
> > abandon this approach
> > unless you are just doing it for fun and learning
> > how class loading works.
> > You are going to find that the fundamental
> > architecture of Java isn't
> > really oriented towards incremental replacement of
> > classes (although there
> > is a little bit better support in 1.4).
> >
> > > Thank you,
> > > Babu
> >
> > Craig
> >
> > > --- Ian Darwin <[EMAIL PROTECTED]> wrote:
> > > > On July 28, 2002 10:32 pm, you wrote:
> > > > > Does anyone know, how to do auto update of
> > > > classes
> > > > > into the JVM? I
> > > > > tried to write my own custom class loader, and
> > > > loaded
> > > > > all the classes
> > > > > through it, however if I put new updated
> > class, it
> > > > > won't reload the
> > > > > class again. Have anyone tried this before?
> > Help
> > > > is
> > > > > very much
> > > > > appreciated.
> > > >
> > > > This better asked on an advanced-java list; not
> > > > tomcat specific.
> > > >
> > > > For all the cleverness of Java's dynamic loading
> > > > mechanism (ClassLoader,
> > > > Class.forName, newInstance(), etc.), there is no
> > > > published API for unloading or reloading.
> > > > They just didn't think of it in time, perhaps.
> > > >
> > > > What I think Tomcat and others do is basically
> > to
> > > > manage the class loader for each Context
> > > > (which has to be separate from the CL for each
> > other
> > > > Context for configuration
> > > > and security reasons anyway) in such a way that
> > you
> > > > can delete
> > > > it (un-reference it) and assign a new one and
> > reload
> > > > the classes
> > > > for the given Context.
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > >
> > 
> > > > For additional commands, e-mail:
> > > > 
> > > >
> > >
> > >
> > > __
> > > Do You Yahoo!?
> > > Yahoo! Health - Feel better, live better
> > > http://health.yahoo.com
> > >
> > > --
> > > To unsubscribe, e-mail:
> > 
> > > For additional commands, e-mail:
> > 
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > 
> > For additional commands, e-mail:
> > 
> >
>
>
> __
> Do You Yahoo!?
> Yahoo! Health - Feel better, live better
> http://health.yahoo.com
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: how to do auto update/reload of a class?

[Craig R. McClanahan]

On Wed, 31 Jul 2002, Babu Wisor wrote:

> Date: Wed, 31 Jul 2002 11:15:21 -0700 (PDT)
> From: Babu Wisor <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: how to do auto update/reload of a class?
>
> Hello Craig,
>   Thank you, very much for your thought. You
> mentioned that, Jasper does this by creating a class
> loader for each page, can you please explain little
> bit more as to how the system over all works? I mean,
> how does the jasper creates invidual class loader for
> each page and make it available to other classes
> (servlet/another JSP) loaded by other class
> loader(Servlet/another Jasper), since classes loaded
> by one class loader is not visible to other class
> loader.

The Tomcat source code is the best place to get the long answer.  The
short answer:  your final sentence above is not quite accurate.  Classes
loaded by a particular class loader can indeed see the classes loaded from
a *parent* class loader -- that's why, for example, your webapp classes
can see things from common/lib.  The JSP page compiler sets up a class
loader whose parent is the webapp class loader.  Therefore, the JSP page's
generated class can see everything in the webapp, but not the other way
around.

> Please, note that i would like to take similar
> approach in my current project, where it requires auto
> update of classes in the run time.
>
> Note: In the tomcat documentation, I found that these
> things work with Servlet Context, but no documents are
> available as to what technique has been used there.
>

What "these things" are you talking about?  if it's the "reload" attribute
on a  element in server.xml, you should note that this reloads
the entire webapp anytime it detects a change -- not just a single class.

> Thank you, very much for your time,
> Babu
>

Craig

>
>
> --- "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
> >
> >
> > On Wed, 31 Jul 2002, Babu Wisor wrote:
> >
> > > Date: Wed, 31 Jul 2002 10:15:08 -0700 (PDT)
> > > From: Babu Wisor <[EMAIL PROTECTED]>
> > > Reply-To: Tomcat Developers List
> > <[EMAIL PROTECTED]>
> > > To: Tomcat Developers List
> > <[EMAIL PROTECTED]>
> > > Cc: [EMAIL PROTECTED]
> > > Subject: Re: how to do auto update/reload of a
> > class?
> > >
> > > Hi All,
> > >   Does anyone have any thoughts as to how to
> > auto
> > > re-load the classes, which have been loaded into
> > JVM
> > > using Custom Class loader? I tried writing custom
> > > class loader and loaded all the classes, but don't
> > > know how to re-load the same class, if it has been
> > > modified (re-compiled) without shutting down JVM,
> > > similar to JSP engine, where if we put updated JSP
> > > file, it picks up the new file.
> > >
> >
> > Jasper does this by creating a class loader for each
> > page, and throwing
> > away the class loader when the page is recompiled.
> > The JVM doesn't let
> > you do things any other way.
> >
> > > Note: I learnt that, we need to recreate new class
> > > loader and load all the classes again, but don't
> > know
> > > exactly how to apply that technique in the system.
> > Any
> > > help is greatly appreciated.
> > >
> >
> > My personal advice, after living through (barely :-)
> > getting a class
> > loader that would reload a webapp to work, is to
> > abandon this approach
> > unless you are just doing it for fun and learning
> > how class loading works.
> > You are going to find that the fundamental
> > architecture of Java isn't
> > really oriented towards incremental replacement of
> > classes (although there
> > is a little bit better support in 1.4).
> >
> > > Thank you,
> > > Babu
> >
> > Craig
> >
> > > --- Ian Darwin <[EMAIL PROTECTED]> wrote:
> > > > On July 28, 2002 10:32 pm, you wrote:
> > > > > Does anyone know, how to do auto update of
> > > > classes
> > > > > into the JVM? I
> > > > > tried to write my own custom class loader, and
> > > > loaded
> > > > > all the classes
> > > > > through it, however if I put new updated
> > class, it
> > > > > won't reload the
> > > > > class again. Have anyone tried this before?
> > Help
> > > > is
> > > > > very much
> > > > > appreciated.
> > > >
> > > > This better asked on an advanced-java list; not
> > > > tomcat specific.
> > > >
> > > > For all the cleverness of Java's dynamic loading
> > > > mechanism (ClassLoader,
> > > > Class.forName, newInstance(), etc.), there is no
> > > > published API for unloading or reloading.
> > > > They just didn't think of it in time, perhaps.
> > > >
> > > > What I think Tomcat and others do is basically
> > to
> > > > manage the class loader for each Context
> > > > (which has to be separate from the CL for each
> > other
> > > > Context for configuration
> > > > and security reasons anyway) in such a way that
> > you
> > > > can delete
> > > > it (un-reference it) and assign a new one and
> > reload
> > > > the classes
> > > > for the given C

Re: how to do auto update/reload of a class?

[Adrian Prezioso]

Craig,
who controls loading and reloading jasper class
loaders?  and how is it being managed?  I'm also
working on a project where I need to auto-reload Java
classes at runtime.  If you could point me to any kind
of documentation, that'd be greatly appreciated.  

thanks,
Adrian

--- "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
> 
> 
> On Wed, 31 Jul 2002, Babu Wisor wrote:
> 
> > Date: Wed, 31 Jul 2002 10:15:08 -0700 (PDT)
> > From: Babu Wisor <[EMAIL PROTECTED]>
> > Reply-To: Tomcat Developers List
> <[EMAIL PROTECTED]>
> > To: Tomcat Developers List
> <[EMAIL PROTECTED]>
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: how to do auto update/reload of a
> class?
> >
> > Hi All,
> >   Does anyone have any thoughts as to how to
> auto
> > re-load the classes, which have been loaded into
> JVM
> > using Custom Class loader? I tried writing custom
> > class loader and loaded all the classes, but don't
> > know how to re-load the same class, if it has been
> > modified (re-compiled) without shutting down JVM,
> > similar to JSP engine, where if we put updated JSP
> > file, it picks up the new file.
> >
> 
> Jasper does this by creating a class loader for each
> page, and throwing
> away the class loader when the page is recompiled. 
> The JVM doesn't let
> you do things any other way.
> 
> > Note: I learnt that, we need to recreate new class
> > loader and load all the classes again, but don't
> know
> > exactly how to apply that technique in the system.
> Any
> > help is greatly appreciated.
> >
> 
> My personal advice, after living through (barely :-)
> getting a class
> loader that would reload a webapp to work, is to
> abandon this approach
> unless you are just doing it for fun and learning
> how class loading works.
> You are going to find that the fundamental
> architecture of Java isn't
> really oriented towards incremental replacement of
> classes (although there
> is a little bit better support in 1.4).
> 
> > Thank you,
> > Babu
> 
> Craig
> 
> > --- Ian Darwin <[EMAIL PROTECTED]> wrote:
> > > On July 28, 2002 10:32 pm, you wrote:
> > > > Does anyone know, how to do auto update of
> > > classes
> > > > into the JVM? I
> > > > tried to write my own custom class loader, and
> > > loaded
> > > > all the classes
> > > > through it, however if I put new updated
> class, it
> > > > won't reload the
> > > > class again. Have anyone tried this before?
> Help
> > > is
> > > > very much
> > > > appreciated.
> > >
> > > This better asked on an advanced-java list; not
> > > tomcat specific.
> > >
> > > For all the cleverness of Java's dynamic loading
> > > mechanism (ClassLoader,
> > > Class.forName, newInstance(), etc.), there is no
> > > published API for unloading or reloading.
> > > They just didn't think of it in time, perhaps.
> > >
> > > What I think Tomcat and others do is basically
> to
> > > manage the class loader for each Context
> > > (which has to be separate from the CL for each
> other
> > > Context for configuration
> > > and security reasons anyway) in such a way that
> you
> > > can delete
> > > it (un-reference it) and assign a new one and
> reload
> > > the classes
> > > for the given Context.
> > >
> > > --
> > > To unsubscribe, e-mail:
> > >
> 
> > > For additional commands, e-mail:
> > > 
> > >
> >
> >
> > __
> > Do You Yahoo!?
> > Yahoo! Health - Feel better, live better
> > http://health.yahoo.com
> >
> > --
> > To unsubscribe, e-mail:  
> 
> > For additional commands, e-mail:
> 
> >
> >
> 
> 
> --
> To unsubscribe, e-mail:  
> 
> For additional commands, e-mail:
> 
> 


__
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: how to do auto update/reload of a class?

[Babu Wisor]

Hello Craig,
  Thank you, very much for your thought. You
mentioned that, Jasper does this by creating a class
loader for each page, can you please explain little
bit more as to how the system over all works? I mean,
how does the jasper creates invidual class loader for
each page and make it available to other classes
(servlet/another JSP) loaded by other class
loader(Servlet/another Jasper), since classes loaded
by one class loader is not visible to other class
loader. 
Please, note that i would like to take similar
approach in my current project, where it requires auto
update of classes in the run time.

Note: In the tomcat documentation, I found that these
things work with Servlet Context, but no documents are
available as to what technique has been used there.

Thank you, very much for your time,
Babu


 
--- "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
> 
> 
> On Wed, 31 Jul 2002, Babu Wisor wrote:
> 
> > Date: Wed, 31 Jul 2002 10:15:08 -0700 (PDT)
> > From: Babu Wisor <[EMAIL PROTECTED]>
> > Reply-To: Tomcat Developers List
> <[EMAIL PROTECTED]>
> > To: Tomcat Developers List
> <[EMAIL PROTECTED]>
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: how to do auto update/reload of a
> class?
> >
> > Hi All,
> >   Does anyone have any thoughts as to how to
> auto
> > re-load the classes, which have been loaded into
> JVM
> > using Custom Class loader? I tried writing custom
> > class loader and loaded all the classes, but don't
> > know how to re-load the same class, if it has been
> > modified (re-compiled) without shutting down JVM,
> > similar to JSP engine, where if we put updated JSP
> > file, it picks up the new file.
> >
> 
> Jasper does this by creating a class loader for each
> page, and throwing
> away the class loader when the page is recompiled. 
> The JVM doesn't let
> you do things any other way.
> 
> > Note: I learnt that, we need to recreate new class
> > loader and load all the classes again, but don't
> know
> > exactly how to apply that technique in the system.
> Any
> > help is greatly appreciated.
> >
> 
> My personal advice, after living through (barely :-)
> getting a class
> loader that would reload a webapp to work, is to
> abandon this approach
> unless you are just doing it for fun and learning
> how class loading works.
> You are going to find that the fundamental
> architecture of Java isn't
> really oriented towards incremental replacement of
> classes (although there
> is a little bit better support in 1.4).
> 
> > Thank you,
> > Babu
> 
> Craig
> 
> > --- Ian Darwin <[EMAIL PROTECTED]> wrote:
> > > On July 28, 2002 10:32 pm, you wrote:
> > > > Does anyone know, how to do auto update of
> > > classes
> > > > into the JVM? I
> > > > tried to write my own custom class loader, and
> > > loaded
> > > > all the classes
> > > > through it, however if I put new updated
> class, it
> > > > won't reload the
> > > > class again. Have anyone tried this before?
> Help
> > > is
> > > > very much
> > > > appreciated.
> > >
> > > This better asked on an advanced-java list; not
> > > tomcat specific.
> > >
> > > For all the cleverness of Java's dynamic loading
> > > mechanism (ClassLoader,
> > > Class.forName, newInstance(), etc.), there is no
> > > published API for unloading or reloading.
> > > They just didn't think of it in time, perhaps.
> > >
> > > What I think Tomcat and others do is basically
> to
> > > manage the class loader for each Context
> > > (which has to be separate from the CL for each
> other
> > > Context for configuration
> > > and security reasons anyway) in such a way that
> you
> > > can delete
> > > it (un-reference it) and assign a new one and
> reload
> > > the classes
> > > for the given Context.
> > >
> > > --
> > > To unsubscribe, e-mail:
> > >
> 
> > > For additional commands, e-mail:
> > > 
> > >
> >
> >
> > __
> > Do You Yahoo!?
> > Yahoo! Health - Feel better, live better
> > http://health.yahoo.com
> >
> > --
> > To unsubscribe, e-mail:  
> 
> > For additional commands, e-mail:
> 
> >
> >
> 
> 
> --
> To unsubscribe, e-mail:  
> 
> For additional commands, e-mail:
> 
> 


__
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: how to do auto update/reload of a class?

[Craig R. McClanahan]

On Wed, 31 Jul 2002, Babu Wisor wrote:

> Date: Wed, 31 Jul 2002 10:15:08 -0700 (PDT)
> From: Babu Wisor <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Subject: Re: how to do auto update/reload of a class?
>
> Hi All,
>   Does anyone have any thoughts as to how to auto
> re-load the classes, which have been loaded into JVM
> using Custom Class loader? I tried writing custom
> class loader and loaded all the classes, but don't
> know how to re-load the same class, if it has been
> modified (re-compiled) without shutting down JVM,
> similar to JSP engine, where if we put updated JSP
> file, it picks up the new file.
>

Jasper does this by creating a class loader for each page, and throwing
away the class loader when the page is recompiled.  The JVM doesn't let
you do things any other way.

> Note: I learnt that, we need to recreate new class
> loader and load all the classes again, but don't know
> exactly how to apply that technique in the system. Any
> help is greatly appreciated.
>

My personal advice, after living through (barely :-) getting a class
loader that would reload a webapp to work, is to abandon this approach
unless you are just doing it for fun and learning how class loading works.
You are going to find that the fundamental architecture of Java isn't
really oriented towards incremental replacement of classes (although there
is a little bit better support in 1.4).

> Thank you,
> Babu

Craig

> --- Ian Darwin <[EMAIL PROTECTED]> wrote:
> > On July 28, 2002 10:32 pm, you wrote:
> > > Does anyone know, how to do auto update of
> > classes
> > > into the JVM? I
> > > tried to write my own custom class loader, and
> > loaded
> > > all the classes
> > > through it, however if I put new updated class, it
> > > won't reload the
> > > class again. Have anyone tried this before? Help
> > is
> > > very much
> > > appreciated.
> >
> > This better asked on an advanced-java list; not
> > tomcat specific.
> >
> > For all the cleverness of Java's dynamic loading
> > mechanism (ClassLoader,
> > Class.forName, newInstance(), etc.), there is no
> > published API for unloading or reloading.
> > They just didn't think of it in time, perhaps.
> >
> > What I think Tomcat and others do is basically to
> > manage the class loader for each Context
> > (which has to be separate from the CL for each other
> > Context for configuration
> > and security reasons anyway) in such a way that you
> > can delete
> > it (un-reference it) and assign a new one and reload
> > the classes
> > for the given Context.
> >
> > --
> > To unsubscribe, e-mail:
> > 
> > For additional commands, e-mail:
> > 
> >
>
>
> __
> Do You Yahoo!?
> Yahoo! Health - Feel better, live better
> http://health.yahoo.com
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-5 BUILDING.txt build.properties.default

[patrickl]

patrickl2002/07/31 10:27:01

  Modified:.BUILDING.txt build.properties.default
  Log:
  Update required commons-digester version to include XML schema support patch
  
  Revision  ChangesPath
  1.7   +2 -2  jakarta-tomcat-5/BUILDING.txt
  
  Index: BUILDING.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/BUILDING.txt,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- BUILDING.txt  31 Jul 2002 03:12:34 -  1.6
  +++ BUILDING.txt  31 Jul 2002 17:27:01 -  1.7
  @@ -201,7 +201,7 @@
   
   (8) Download and Install the Commons Digester Binary Distribution
   
  -* Download a binary distribution (nightly build 20020731 or later) from:
  +* Download a binary distribution (nightly build 20020801 or later) from:
   
   http://jakarta.apache.org/builds/jakarta-commons/release/commons-digester
   
  
  
  
  1.11  +2 -2  jakarta-tomcat-5/build.properties.default
  
  Index: build.properties.default
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.properties.default,v
  retrieving revision 1.10
  retrieving revision 1.11
  diff -u -r1.10 -r1.11
  --- build.properties.default  31 Jul 2002 03:12:34 -  1.10
  +++ build.properties.default  31 Jul 2002 17:27:01 -  1.11
  @@ -71,7 +71,7 @@
   commons-daemon.loc=jakarta-commons-sandbox/daemon
   
   
  -# - Commons Digester, version 20020731 or later -
  +# - Commons Digester, version 20020801 or later -
   commons-digester.home=${base.path}/commons-digester
   commons-digester.lib=${commons-digester.home}
   commons-digester.jar=${commons-digester.lib}/commons-digester.jar
  
  
  

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

RE: mod_jk, mod_jk2 URI spaces

[costinm]

On Wed, 31 Jul 2002, Mladen Turk wrote:

> > Now I propose that we make something like _not_ URI space 
> > filtering. Meaning that one could be able to serve every 
> > .html file through TC except for the /*/some_space/ location. 
> > Right now we are checking and hoping that the TC will accept 
> > the context, and then we forget that immediately. I propose 
> > that we make the map_to_storage two way (If the TC accepts it 
> > and then checking if the Apache configuration rejects it).
> > 
> > Does that make any sense?
> > 
> 
> After I read my mail, it doesn't make sense even for me :)

I actually understood the orginal mail, it's not that bad 
( i.e. I've written worse messages :-)


> For example (what I have in mind) using mod_jk:
> 
> JkMount /examples/*
> (This  will map /examples URI space and everything belonging to the
> /examples will be served by the TC).
> 
> JkNotMount /examples/*.gif
> JkNotMount /examples/*.jpg
> 
> (This  will map /examples URI space and everything will be served by the
> TC except the gif and jpg files).

+1

The goal is to have tomcat serve dynamic content and apache static
content, respecting as strictly as possible the web.xml semantic.

Anything that helps that goal is good.

However, I would like to see this in jk2 - JkMount is going
to be deprecated and there is the issue of supporting multiple
servers ( it won't be trivial to fix iis/nes in jk1.2 to support
the same thing ). Plus jk1.2 is stable and close to a release.


Costin


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: how to do auto update/reload of a class?

[Babu Wisor]

Hi All,
  Does anyone have any thoughts as to how to auto
re-load the classes, which have been loaded into JVM
using Custom Class loader? I tried writing custom
class loader and loaded all the classes, but don't
know how to re-load the same class, if it has been
modified (re-compiled) without shutting down JVM,
similar to JSP engine, where if we put updated JSP
file, it picks up the new file. 

Note: I learnt that, we need to recreate new class
loader and load all the classes again, but don't know
exactly how to apply that technique in the system. Any
help is greatly appreciated.

Thank you,
Babu
--- Ian Darwin <[EMAIL PROTECTED]> wrote:
> On July 28, 2002 10:32 pm, you wrote:
> > Does anyone know, how to do auto update of
> classes
> > into the JVM? I
> > tried to write my own custom class loader, and
> loaded
> > all the classes
> > through it, however if I put new updated class, it
> > won't reload the
> > class again. Have anyone tried this before? Help
> is
> > very much
> > appreciated.
> 
> This better asked on an advanced-java list; not
> tomcat specific.
> 
> For all the cleverness of Java's dynamic loading
> mechanism (ClassLoader,
> Class.forName, newInstance(), etc.), there is no
> published API for unloading or reloading. 
> They just didn't think of it in time, perhaps.
> 
> What I think Tomcat and others do is basically to
> manage the class loader for each Context
> (which has to be separate from the CL for each other
> Context for configuration
> and security reasons anyway) in such a way that you
> can delete
> it (un-reference it) and assign a new one and reload
> the classes
> for the given Context.
> 
> --
> To unsubscribe, e-mail:  
> 
> For additional commands, e-mail:
> 
> 


__
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: how to do auto update/reload of a class?

[Babu Wisor]

Hi All,
  Thank you, for your response. Do you have any
thoughts as to how to auto re-load the classes, which
have been loaded into JVM using Custom Class loader? I
tried writing custom class loader and loaded all the
classes, but don't know how to re-load the same class,
if it has been modified (re-compiled) without shutting
down JVM, similar to JSP engine, where if we put
updated JSP file, it picks up the new file. 

Note: I learnt that, we need to recreate new class
loader and load all the classes again, but don't know
exactly how to apply that technique in the system. Any
help is greatly appreciated.

Thank you,
Babu
--- Ian Darwin <[EMAIL PROTECTED]> wrote:
> On July 28, 2002 10:32 pm, you wrote:
> > Does anyone know, how to do auto update of
> classes
> > into the JVM? I
> > tried to write my own custom class loader, and
> loaded
> > all the classes
> > through it, however if I put new updated class, it
> > won't reload the
> > class again. Have anyone tried this before? Help
> is
> > very much
> > appreciated.
> 
> This better asked on an advanced-java list; not
> tomcat specific.
> 
> For all the cleverness of Java's dynamic loading
> mechanism (ClassLoader,
> Class.forName, newInstance(), etc.), there is no
> published API for unloading or reloading. 
> They just didn't think of it in time, perhaps.
> 
> What I think Tomcat and others do is basically to
> manage the class loader for each Context
> (which has to be separate from the CL for each other
> Context for configuration
> and security reasons anyway) in such a way that you
> can delete
> it (un-reference it) and assign a new one and reload
> the classes
> for the given Context.
> 
> --
> To unsubscribe, e-mail:  
> 
> For additional commands, e-mail:
> 
> 


__
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 11335] New: - RequestDispatcher.forward() is not 2.3 spec compliant

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=11335

RequestDispatcher.forward() is not 2.3 spec compliant

   Summary: RequestDispatcher.forward() is not 2.3 spec compliant
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Major
  Priority: Other
 Component: Servlet & JSP API
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In SRV.8.4 of the servlet spec it says:

 "The path elements of the request object exposed to the target servlet must   
  reflect the path used to obtain the RequestDispatcher. The only exception to 
  this is if the RequestDispatcher was obtained via the getNamedDispatcher 
  method."

With tomcat 4, if the request passed to forward has been wrapped
(either by the current servlet/filter or by a previous servlet/filter) and that 
wrapper changes the value of the path methods - then the forward method exposes
the wrapped values rather than the values used to obtain the request 
dispatcher.

The Jetty container wraps the forwarded request and re-implements the path
methods so that the correct values are exposed.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Tomcat 4.0

[Craig R. McClanahan]

On Wed, 31 Jul 2002, Thomas Colin de Verdière wrote:

> Date: Wed, 31 Jul 2002 18:04:55 +0200
> From: Thomas Colin de Verdière <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: Re: Tomcat 4.0
>
> There are not very involved since they should use another servlet container, even an
> application server.

> We have many of our customers using Tomcat 3.2.4 but some use Websphere,
> other WebLogic ... Our product work on tomcat we have our own Servlets
> and taglib delivered in WEB-INF/lib/ of our demos applications, we have
> configuration files in a subdirectory of the conf directory. There are
> some properties file for jndi access. Our product can be customized.
> This customization is on the properties file but also on jsps and
> servlets we deliver. For example we can have the customer can change an
> init-param for a servlet and he could also want to modify a Jsp page by
> adding custom tags. This customization the customer can do it anytime.
> But if he wants to port his customized application to another server we
> don't want him to use some jsp 1.2 specific features like using JSTL in
> our jsp since most of products are not jsp 1.2 compatible. The fact is
> that i want to migrate my taglib to jsp 1.2 compatible and i don't want
> to write (and support) it for both jsp 1.1 and jsp 1.2 server. We want a
> smooth migration ..
>

As with web.xml files, tag library descriptors declare which version of
JSP they are written for (1.1 or 1.2).  Tomcat 4 runs apps with JSP 1.1
tag library descriptors just fine, with no changes.

Craig


>
> Michael E. Locasto wrote:
> > Hi,
> >
> > The 2.3/1.2 spec requires implementations to be backward compatible.
> >
> > http://jakarta.apache.org/tomcat/
> >
> > "As required by the specifications, Tomcat 4.0 also supports web
> > applications built for the Servlet 2.2 and JSP 1.1 specifications with no
> > changes."
> >
> > As far as the choice between 3.3.1 and 4.x, people have their favorites. A
> > lot of people run either very happily. There are arguments for both
> > approaches, but I'd say the critical factor for you is how involved your
> > users are in the administration of some Tomcat instance. The decision is
> > yours; I suppose you could offer both environments as "development" for any
> > of your customers interested in migration. Let them do the assessment for
> > you :)
> >
> > Regards,
> > Michael Locasto
> >
> >
> > - Original Message -
> > From: "Thomas Colin de Verdière" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Wednesday, July 31, 2002 8:48 AM
> > Subject: Tomcat 4.0
> >
> >
> >
> >>  Hi,
> >>  we are using Tomcat 3.2.4, we deliver to the customer a solution with
> >>Tomcat 3.2.4 and we would like to use either Tomcat 3.3 either Tomcat 4.0.
> >
> > Our
> >
> >>product work fine with Tomcat 4.0 and Tomcat 3.2.4.
> >>Our customers develop their applications using Tomcat 3.2.4 and so it is
> >>easy for them to a have a free environment then if they wish they can
> >>go to a commercial server.
> >>
> >>As tomcat 4.0 provides some efficient way to manage log .., compilation
> >>JSP, a standard taglib (JSTL)  compatible. We are asking ourself if it
> >>is a good way to upgrade to Tomcat 4.0 or Tomcat 3.3. Because TC 3.3 is
> >>servlet 2.2 and jsp 1.1 compatible, instead Tomcat 4.0 is servlet 2.3
> >>and jsp 1.2 compatible. Most of the commercials products are
> >>working today on 2.2 and 1.1 platform so this is why we are asking this?
> >>We want to keep a compatibility with S 2.2, JSP 1.1 . If any of you have
> >>some responses
> >>they are very welcomed.
> >>
> >>
> >>Thomas Colin de Verdière
> >>--
> >>SCORT
> >>http://www.scort.com
> >>
> >>
> >>--
> >>To unsubscribe, e-mail:
> >
> > 
> >
> >>For additional commands, e-mail:
> >
> > 
> >
> >
> > --
> > To unsubscribe, e-mail:   
> > For additional commands, e-mail: 
> >
> >
> >
>
> --
> Thomas Colin de Verdière
> SCORT
> http://www.scort.com
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Tomcat 4.0

[Craig R. McClanahan]

On Wed, 31 Jul 2002, Thomas Colin de Verdière wrote:

> Date: Wed, 31 Jul 2002 15:52:57 +0200
> From: Thomas Colin de Verdière <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: Re: Tomcat 4.0
>
> Well in fact we would like to use Tomcat 4.0 but our customers may want to use
> Bea Weblogic, ATG dynamo ..

> We don't want to force them to use a specific server. My question should
> be : is there a way in Tomcat 4.0 to make it behave as a servlet 2.2,
> jsp 1.1 server.

You don't have to do anything to make this happen -- just put your servlet
2.2 / jsp 1.1 webapps in the "webapps" directory and run them.

 I looked at web.xml and there is the path to the dtd
> which could be constraint to force the customer not to use filter (for
> example). But for my jsps can i make them specific to a JSP version.
> Since we are developping demos it could be great to port on any server
> the customer would like. Am i clear?
>

A properly set up Servlet 2.2 application will refer to the 2.2 version of
the DTD, so it won't allow the  element.  An application requiring
filters needs to reference the 2.3 (or later) version of the DTD, thereby
declaring itself to be a 2.3 based application.

Craig


>
> Michael E. Locasto wrote:
> > Hi,
> >
> > The 2.3/1.2 spec requires implementations to be backward compatible.
> >
> > http://jakarta.apache.org/tomcat/
> >
> > "As required by the specifications, Tomcat 4.0 also supports web
> > applications built for the Servlet 2.2 and JSP 1.1 specifications with no
> > changes."
> >
> > As far as the choice between 3.3.1 and 4.x, people have their favorites. A
> > lot of people run either very happily. There are arguments for both
> > approaches, but I'd say the critical factor for you is how involved your
> > users are in the administration of some Tomcat instance. The decision is
> > yours; I suppose you could offer both environments as "development" for any
> > of your customers interested in migration. Let them do the assessment for
> > you :)
> >
> > Regards,
> > Michael Locasto
> >
> >
> > - Original Message -
> > From: "Thomas Colin de Verdière" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Wednesday, July 31, 2002 8:48 AM
> > Subject: Tomcat 4.0
> >
> >
> >
> >>  Hi,
> >>  we are using Tomcat 3.2.4, we deliver to the customer a solution with
> >>Tomcat 3.2.4 and we would like to use either Tomcat 3.3 either Tomcat 4.0.
> >
> > Our
> >
> >>product work fine with Tomcat 4.0 and Tomcat 3.2.4.
> >>Our customers develop their applications using Tomcat 3.2.4 and so it is
> >>easy for them to a have a free environment then if they wish they can
> >>go to a commercial server.
> >>
> >>As tomcat 4.0 provides some efficient way to manage log .., compilation
> >>JSP, a standard taglib (JSTL)  compatible. We are asking ourself if it
> >>is a good way to upgrade to Tomcat 4.0 or Tomcat 3.3. Because TC 3.3 is
> >>servlet 2.2 and jsp 1.1 compatible, instead Tomcat 4.0 is servlet 2.3
> >>and jsp 1.2 compatible. Most of the commercials products are
> >>working today on 2.2 and 1.1 platform so this is why we are asking this?
> >>We want to keep a compatibility with S 2.2, JSP 1.1 . If any of you have
> >>some responses
> >>they are very welcomed.
> >>
> >>
> >>Thomas Colin de Verdière
> >>--
> >>SCORT
> >>http://www.scort.com
> >>
> >>
> >>--
> >>To unsubscribe, e-mail:
> >
> > 
> >
> >>For additional commands, e-mail:
> >
> > 
> >
> >
> > --
> > To unsubscribe, e-mail:   
> > For additional commands, e-mail: 
> >
> >
> >
>
> --
> Thomas Colin de Verdière
> SCORT
> http://www.scort.com
>
>
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
>
>


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Tomcat 4.0

[Thomas Colin de Verdière]

There are not very involved since they should use another servlet container, even an
application server. 
We have many of our customers using Tomcat 3.2.4 but some use Websphere, other 
WebLogic ...
Our product work on tomcat we have our own Servlets and taglib delivered in 
WEB-INF/lib/ of our demos applications, we have configuration files in a subdirectory  
of the conf directory. There are some properties file for jndi access. Our product can 
be customized. This customization is on the properties file but also on jsps and 
servlets we deliver.
For example we can have the customer can change an init-param for a servlet and he 
could also want to modify a Jsp page by adding custom tags.
This customization the customer can do it anytime. But if he wants to port his 
customized application to another server we don't want him to use some jsp 1.2 
specific features like using JSTL in our jsp since most of products are not jsp 1.2 
compatible.
The fact is that i want to migrate my taglib to jsp 1.2 compatible and i don't want to 
write (and support) it for both jsp 1.1 and jsp 1.2 server. We want a smooth migration 
..


Michael E. Locasto wrote:
> Hi,
> 
> The 2.3/1.2 spec requires implementations to be backward compatible.
> 
> http://jakarta.apache.org/tomcat/
> 
> "As required by the specifications, Tomcat 4.0 also supports web
> applications built for the Servlet 2.2 and JSP 1.1 specifications with no
> changes."
> 
> As far as the choice between 3.3.1 and 4.x, people have their favorites. A
> lot of people run either very happily. There are arguments for both
> approaches, but I'd say the critical factor for you is how involved your
> users are in the administration of some Tomcat instance. The decision is
> yours; I suppose you could offer both environments as "development" for any
> of your customers interested in migration. Let them do the assessment for
> you :)
> 
> Regards,
> Michael Locasto
> 
> 
> - Original Message -
> From: "Thomas Colin de Verdière" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, July 31, 2002 8:48 AM
> Subject: Tomcat 4.0
> 
> 
> 
>>  Hi,
>>  we are using Tomcat 3.2.4, we deliver to the customer a solution with
>>Tomcat 3.2.4 and we would like to use either Tomcat 3.3 either Tomcat 4.0.
> 
> Our
> 
>>product work fine with Tomcat 4.0 and Tomcat 3.2.4.
>>Our customers develop their applications using Tomcat 3.2.4 and so it is
>>easy for them to a have a free environment then if they wish they can
>>go to a commercial server.
>>
>>As tomcat 4.0 provides some efficient way to manage log .., compilation
>>JSP, a standard taglib (JSTL)  compatible. We are asking ourself if it
>>is a good way to upgrade to Tomcat 4.0 or Tomcat 3.3. Because TC 3.3 is
>>servlet 2.2 and jsp 1.1 compatible, instead Tomcat 4.0 is servlet 2.3
>>and jsp 1.2 compatible. Most of the commercials products are
>>working today on 2.2 and 1.1 platform so this is why we are asking this?
>>We want to keep a compatibility with S 2.2, JSP 1.1 . If any of you have
>>some responses
>>they are very welcomed.
>>
>>
>>Thomas Colin de Verdière
>>--
>>SCORT
>>http://www.scort.com
>>
>>
>>--
>>To unsubscribe, e-mail:
> 
> 
> 
>>For additional commands, e-mail:
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 
> 

-- 
Thomas Colin de Verdière
SCORT
http://www.scort.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources messages.properties messages_es.properties messages_ja.properties

[luehe]

luehe   2002/07/31 09:04:39

  Modified:jasper2/src/share/org/apache/jasper/compiler Validator.java
   jasper2/src/share/org/apache/jasper/resources
messages.properties messages_es.properties
messages_ja.properties
  Log:
  Replaced call to TagExtraInfo.isValid() with the new
  TagExtraInfo.validate(), as required by JSP 2.0.
  
  Revision  ChangesPath
  1.15  +22 -6 
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java
  
  Index: Validator.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/compiler/Validator.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- Validator.java22 Jul 2002 20:35:27 -  1.14
  +++ Validator.java31 Jul 2002 16:04:39 -  1.15
  @@ -837,9 +837,25 @@
err.jspError(n, "jsp.error.missing.tagInfo", n.getName());
}
   
  - if (!tagInfo.isValid(n.getTagData())) {
  - err.jspError(n, "jsp.error.invalid.attributes");
  - }
  + ValidationMessage[] errors = tagInfo.validate(n.getTagData());
  +if (errors != null && errors.length != 0) {
  + StringBuffer errMsg = new StringBuffer();
  +errMsg.append("");
  +errMsg.append(err.getString("jsp.error.tei.invalid.attributes",
  + n.getName()));
  +errMsg.append("");
  +for (int i=0; i");
  + if (errors[i].getId() != null) {
  + errMsg.append(errors[i].getId());
  + errMsg.append(": ");
  + }
  +errMsg.append(errors[i].getMessage());
  +errMsg.append("");
  +}
  +
  + err.jspError(n, errMsg.toString());
  +}
   
visitBody(n);
}
  
  
  
  1.19  +3 -3  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties
  
  Index: messages.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages.properties,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- messages.properties   29 Jul 2002 22:29:01 -  1.18
  +++ messages.properties   31 Jul 2002 16:04:39 -  1.19
  @@ -160,7 +160,6 @@
   jsp.error.unable.to_find_method=Unable to find setter method for attribute: {0}
   jsp.error.unable.to_convert_string=Unable to convert a String to {0} for attribute 
{1}
   jsp.error.unable.to_introspect=Unable to introspect on tag handler class: {0} 
because of {1}
  -jsp.error.invalid_attributes=Attributes are invalid according to TagInfo
   jsp.error.bad_tag=No such tag {0} in the tag library imported with prefix {1}
   jsp.error.bad_string_Character=Cannot extract a Character from a zero length array
   jsp.error.bad_string_char=Cannot extract a char from a zero length array
  @@ -225,7 +224,8 @@
   jspc.error.emptyWebApp=-webapp requires a trailing file argument
   jsp.error.library.invalid=JSP page is invalid according to library {0}: {1}
   jsp.warning.tlvclass.is.null=Could not load TagLibraryValidator class {0}: {1}
  -jsp.error.taglibraryvalidator.invalidpage=Validation error messages from tag 
library {0}
  +jsp.error.tlv.invalid.page=Validation error messages from TagLibraryValidator for 
{0}
  +jsp.error.tei.invalid.attributes=Validation error messages from TagExtraInfo for {0}
   jsp.parser.sax.propertynotsupported=SAX property not supported: {0}
   jsp.parser.sax.propertynotrecognized=SAX property not recognized: {0}
   jsp.parser.sax.featurenotsupported=SAX feature not supported: {0}
  
  
  
  1.4   +4 -3  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_es.properties
  
  Index: messages_es.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/resources/messages_es.properties,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- messages_es.properties8 Jul 2002 17:28:58 -   1.3
  +++ messages_es.properties31 Jul 2002 16:04:39 -  1.4
  @@ -133,7 +133,6 @@
   jsp.error.unable.to_load_taghandler_class=No se puede cargar clase manejadora {0} 
del tag acausa de {1}
   jsp.error.unable.to_find_method=No se puede encontrar el metodo de escritura para 
el atributo: {0}
   jsp.error.unable.to_introspect=No se puede introspect on tag handler clase: {0} a 
causa de {1}
  -jsp.error.invalid_attributes=Los atributos no son validos de acuerdo con TagInfo
   jsp.error.bad_tag=No existe el tag {0} en la libreria importada con prefijo {

web-app_2_3.dtd and servlet spec and tomcat session-timeout expireat 0 problem.

[James Cooley]

Hi,

This came up on the xdoclet-devel mailing list. The xdoclet 
implementation takes follows the dtd saying that a session expires if 
the session-timeout is =< 0, while the spec says it will never expire if 
session-timeout is -1, Tomcat says it will not expire if session-timeout 
is < 0. Now xdoclet sets it to 0 by default while Tomcat defaults it to 
-1 meaning that Tomcat  session expire in under 30 seconds if the 
web.xml is created with xdoclet (or is manually set to 0).

http://cvs.apache.org/viewcvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/PersistentManagerBase.java?rev=1.8&content-type=text/vnd.viewcvs-markup

>   /**
> * Indicate whether the session has been idle for longer
> * than its expiration date as of the supplied time.
> *
> * FIXME: Probably belongs in the Session class.
> */
>protected boolean isSessionStale(Session session, long timeNow) {
>
>int maxInactiveInterval = session.getMaxInactiveInterval();
>if (maxInactiveInterval >= 0) {
>int timeIdle = // Truncate, do not round up
>(int) ((timeNow - session.getLastAccessedTime()) / 1000L);
>if (timeIdle >= maxInactiveInterval)
>return true;
>}
>
>return false;
>
>}
>
It this a bug in the dtd comment (see below)?

James


[EMAIL PROTECTED] wrote:

>No. Check the DTD (http://java.sun.com/dtd/web-app_2_3.dtd). It clearly states this:
>
>The session-timeout element defines the default session timeout
>interval for all sessions created in this web application. The
>specified timeout 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.
>
>Mathias 
>
>
> James Cooley <[EMAIL PROTECTED]> wrote:
>
>Hi,
>  
>
>>I noticed Tomcat 4.0.4 was timing out after about 30 seconds and on 
>>looking at the servlet (2.3) spec it says that if the session timeout is 
>>-1 then the session will not expire which seems at odds with the xdoclet 
>>statement that:
>>
>>
>>
>>>If the timeout is 0 or less, the container ensures the default 
>>>  
>>>
>>behavior of sessions is never to time out.
>>
>>So I guess the default should be -1 instead of 0.
>>
>>James
>>
>>
>>
>>---
>>This sf.net email is sponsored by: Dice - The leading online job board
>>for high-tech professionals. Search and apply for tech jobs today!
>>http://seeker.dice.com/seeker.epl?rel_code=31
>>___
>>Xdoclet-devel mailing list
>>[EMAIL PROTECTED]
>>https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
>>
>>
>
>
>
>
>  
>




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

cvs commit: jakarta-tomcat-catalina/catalina/src/bin launcher.xml

[patrickl]

patrickl2002/07/31 08:24:10

  Removed: catalina/src/bin launcher.xml
  Log:
  Remove sample XML file since it will be replaced by a new file catalina.xml in the 
near future.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Performace: Tomcat 4.0.x vs. Tomcat 4.1.x

[Vasquez, Jason]

Is there a large performance gain from Tomcat 4.0.x to Tomcat 4.1.x? Also
are there performance gains from JVM 1.3 to 1.4 as well?
 
Thanks,
 
Jason Vasquez
 

DO NOT REPLY [Bug 11307] - Deadlock in ClassLoader

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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-07-31 14:43 ---
Sure.  The application is a Struts application utilizing JSP and Servlets.  The
non-tomcat thread that you see in the ClassLoader is from one of the Jini
LookupDiscovery threads handling a response from the LookupService informing it
that a service matching the requested template was found.  This necessitates the
remote class loading to be able to unmarshall the response.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

[PATCH] [5.0] jakarta-servletapi-5

[Bob Herrmann]

The 2.4 Servlet spec adds a new constant. See section 15.1.5 in the June
24th public draft. 

Cheers,
-bob

 



Index: src/share/javax/servlet/http/HttpServletResponse.java
===
RCS file: /home/cvspublic/jakarta-servletapi-5/src/share/javax/servlet/http/HttpServletResponse.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 HttpServletResponse.java
--- src/share/javax/servlet/http/HttpServletResponse.java	16 Jul 2002 16:38:41 -	1.1.1.1
+++ src/share/javax/servlet/http/HttpServletResponse.java	31 Jul 2002 14:07:12 -
@@ -445,9 +445,24 @@
  * Status code (302) indicating that the resource has temporarily
  * moved to another location, but that future references should
  * still use the original URI to access the resource.
+ *
+ * This definition is being retained for backwards compatibility.
+ * SC_FOUND is now the preferred definition.
  */
 
 public static final int SC_MOVED_TEMPORARILY = 302;
+
+/**
+* Status code (302) indicating that the resource reside
+* temporarily under a different URI. Since the redirection might
+* be altered on occasion, the client should continue to use the
+* Request-URI for future requests.(HTTP/1.1) To represent the
+* status code (302), it is recommended to use this variable.
+*
+*/
+
+public static final int SC_FOUND = 302;
+
 
 /**
  * Status code (303) indicating that the response to the request



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

RE: mod_jk, mod_jk2 URI spaces

[Mladen Turk]

> Now I propose that we make something like _not_ URI space 
> filtering. Meaning that one could be able to serve every 
> .html file through TC except for the /*/some_space/ location. 
> Right now we are checking and hoping that the TC will accept 
> the context, and then we forget that immediately. I propose 
> that we make the map_to_storage two way (If the TC accepts it 
> and then checking if the Apache configuration rejects it).
> 
> Does that make any sense?
> 

After I read my mail, it doesn't make sense even for me :)

For example (what I have in mind) using mod_jk:

JkMount /examples/*
(This  will map /examples URI space and everything belonging to the
/examples will be served by the TC).

JkNotMount /examples/*.gif
JkNotMount /examples/*.jpg

(This  will map /examples URI space and everything will be served by the
TC except the gif and jpg files).


MT.



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Tomcat 4.0

[Thomas Colin de Verdière]

Well in fact we would like to use Tomcat 4.0 but our customers may want to use 
Bea Weblogic, ATG dynamo ..
We don't want to force them to use a specific server. My question should be :
is there a way in Tomcat 4.0 to make it behave as a servlet 2.2, jsp 1.1 server.
I looked at web.xml and there is the path to the dtd which could be constraint to 
force the customer not to use filter (for example). But for my jsps can i make them
specific to a JSP version. Since we are developping demos it could be great to port 
on any server the customer would like. Am i clear?


Michael E. Locasto wrote:
> Hi,
> 
> The 2.3/1.2 spec requires implementations to be backward compatible.
> 
> http://jakarta.apache.org/tomcat/
> 
> "As required by the specifications, Tomcat 4.0 also supports web
> applications built for the Servlet 2.2 and JSP 1.1 specifications with no
> changes."
> 
> As far as the choice between 3.3.1 and 4.x, people have their favorites. A
> lot of people run either very happily. There are arguments for both
> approaches, but I'd say the critical factor for you is how involved your
> users are in the administration of some Tomcat instance. The decision is
> yours; I suppose you could offer both environments as "development" for any
> of your customers interested in migration. Let them do the assessment for
> you :)
> 
> Regards,
> Michael Locasto
> 
> 
> - Original Message -
> From: "Thomas Colin de Verdière" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, July 31, 2002 8:48 AM
> Subject: Tomcat 4.0
> 
> 
> 
>>  Hi,
>>  we are using Tomcat 3.2.4, we deliver to the customer a solution with
>>Tomcat 3.2.4 and we would like to use either Tomcat 3.3 either Tomcat 4.0.
> 
> Our
> 
>>product work fine with Tomcat 4.0 and Tomcat 3.2.4.
>>Our customers develop their applications using Tomcat 3.2.4 and so it is
>>easy for them to a have a free environment then if they wish they can
>>go to a commercial server.
>>
>>As tomcat 4.0 provides some efficient way to manage log .., compilation
>>JSP, a standard taglib (JSTL)  compatible. We are asking ourself if it
>>is a good way to upgrade to Tomcat 4.0 or Tomcat 3.3. Because TC 3.3 is
>>servlet 2.2 and jsp 1.1 compatible, instead Tomcat 4.0 is servlet 2.3
>>and jsp 1.2 compatible. Most of the commercials products are
>>working today on 2.2 and 1.1 platform so this is why we are asking this?
>>We want to keep a compatibility with S 2.2, JSP 1.1 . If any of you have
>>some responses
>>they are very welcomed.
>>
>>
>>Thomas Colin de Verdière
>>--
>>SCORT
>>http://www.scort.com
>>
>>
>>--
>>To unsubscribe, e-mail:
> 
> 
> 
>>For additional commands, e-mail:
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
> For additional commands, e-mail: 
> 
> 
> 

-- 
Thomas Colin de Verdière
SCORT
http://www.scort.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 11307] - Deadlock in ClassLoader

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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-07-31 13:45 ---
Could you provide more information about your configuration
and the application you are running.
One of the threads with the deadlock is not a thread created by
Tomcat 4.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

mod_jk, mod_jk2 URI spaces

[Mladen Turk]

Hi,

Just been working for a week on a real-life TC-mod_jk situation, and
found some interesting limitations (well, point of views to the
concept).

What are we doing right now is 'favoring' TC over Apache URI resolving,
meaning that if we set something like /*.html, then all the .html
context will be server by the TC.

Now I propose that we make something like _not_ URI space filtering.
Meaning that one could be able to serve every .html file through TC
except for the /*/some_space/ location. Right now we are checking and
hoping that the TC will accept the context, and then we forget that
immediately. I propose that we make the map_to_storage two way (If the
TC accepts it and then checking if the Apache configuration rejects it).

Does that make any sense?


MT.


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Tomcat 4.0

[Michael E. Locasto]

Hi,

The 2.3/1.2 spec requires implementations to be backward compatible.

http://jakarta.apache.org/tomcat/

"As required by the specifications, Tomcat 4.0 also supports web
applications built for the Servlet 2.2 and JSP 1.1 specifications with no
changes."

As far as the choice between 3.3.1 and 4.x, people have their favorites. A
lot of people run either very happily. There are arguments for both
approaches, but I'd say the critical factor for you is how involved your
users are in the administration of some Tomcat instance. The decision is
yours; I suppose you could offer both environments as "development" for any
of your customers interested in migration. Let them do the assessment for
you :)

Regards,
Michael Locasto


- Original Message -
From: "Thomas Colin de Verdière" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, July 31, 2002 8:48 AM
Subject: Tomcat 4.0


>   Hi,
>   we are using Tomcat 3.2.4, we deliver to the customer a solution with
> Tomcat 3.2.4 and we would like to use either Tomcat 3.3 either Tomcat 4.0.
Our
> product work fine with Tomcat 4.0 and Tomcat 3.2.4.
> Our customers develop their applications using Tomcat 3.2.4 and so it is
> easy for them to a have a free environment then if they wish they can
> go to a commercial server.
>
> As tomcat 4.0 provides some efficient way to manage log .., compilation
> JSP, a standard taglib (JSTL)  compatible. We are asking ourself if it
> is a good way to upgrade to Tomcat 4.0 or Tomcat 3.3. Because TC 3.3 is
> servlet 2.2 and jsp 1.1 compatible, instead Tomcat 4.0 is servlet 2.3
> and jsp 1.2 compatible. Most of the commercials products are
> working today on 2.2 and 1.1 platform so this is why we are asking this?
> We want to keep a compatibility with S 2.2, JSP 1.1 . If any of you have
> some responses
> they are very welcomed.
>
>
> Thomas Colin de Verdière
> --
> SCORT
> http://www.scort.com
>
>
> --
> To unsubscribe, e-mail:

> For additional commands, e-mail:



--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 11328] - Invocation of getWriter() during RequestDispatcher.foward()

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=11328

Invocation of getWriter() during RequestDispatcher.foward()





--- Additional Comments From [EMAIL PROTECTED]  2002-07-31 13:02 ---
Created an attachment (id=2544)
Application to create the phenomenon

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 11328] - Invocation of getWriter() during RequestDispatcher.foward()

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=11328

Invocation of getWriter() during RequestDispatcher.foward()





--- Additional Comments From [EMAIL PROTECTED]  2002-07-31 13:01 ---
Created an attachment (id=2543)
Web App Log showing the Invocation Stack Trace

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 11328] - Invocation of getWriter() during RequestDispatcher.foward()

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=11328

Invocation of getWriter() during RequestDispatcher.foward()





--- Additional Comments From [EMAIL PROTECTED]  2002-07-31 13:00 ---
Created an attachment (id=2542)
Request URL Sequence

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 11328] New: - Invocation of getWriter() during RequestDispatcher.foward()

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=11328

Invocation of getWriter() during RequestDispatcher.foward()

   Summary: Invocation of getWriter() during
RequestDispatcher.foward()
   Product: Tomcat 4
   Version: 4.0.3 Final
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When forwarding a request during this process response.getWriter() seems to be 
invoked - at least if the response is wrapped (see detailed report attached).  
As far as I can see, this is illegal since it breaks target resources that want 
to send binary data.

I'll attach:

 - log files that show the invokation
 - an example project with build file to reproduce the error

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Tomcat 4.0

[Thomas Colin de Verdière]

  Hi,
  we are using Tomcat 3.2.4, we deliver to the customer a solution with
Tomcat 3.2.4 and we would like to use either Tomcat 3.3 either Tomcat 4.0. Our 
product work fine with Tomcat 4.0 and Tomcat 3.2.4.
Our customers develop their applications using Tomcat 3.2.4 and so it is 
easy for them to a have a free environment then if they wish they can 
go to a commercial server.

As tomcat 4.0 provides some efficient way to manage log .., compilation 
JSP, a standard taglib (JSTL)  compatible. We are asking ourself if it 
is a good way to upgrade to Tomcat 4.0 or Tomcat 3.3. Because TC 3.3 is 
servlet 2.2 and jsp 1.1 compatible, instead Tomcat 4.0 is servlet 2.3 
and jsp 1.2 compatible. Most of the commercials products are
working today on 2.2 and 1.1 platform so this is why we are asking this?
We want to keep a compatibility with S 2.2, JSP 1.1 . If any of you have 
some responses
they are very welcomed.


Thomas Colin de Verdière
--
SCORT
http://www.scort.com


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Re: Embedded Tomcat and custom connector ?

[Eriam Schaffter]

Hi back

That was not so clear.

What I would like to do is to get *all* http requests and manage them 
trough another connector then the one that passes them to the filesystem.
Example: a http request comes and it's a GET /Test instead of trying to 
fetch the local Test directory I want to redirect this to another 
resource like a sql procedure or something else.

I think that it's possible to do this by creating the connector by 
myself instead of creating it on the high level with createConnector 
method of the Embedded class. Something like creating a HttpConnector 
with an associated EventHanlder ?

Any tips ?
Any idea ?

Thanks in advance.

Eriam

Eriam Schaffter wrote:

> Hi all.
>
> I'm embedding tomcat in a java app using the Embedded class.
>
> What I would like to do know is to use the http connector but I would 
> instantiate it by my own and not via the createConnector method so I 
> handle requests and responses in my program. The goal is to have a 
> connector that handles http request a bit differently then the one in 
> tomcat (redirect get request on another resource).
>
> Any suggestions ?
>
> Eriam
>
>
> -- 
> To unsubscribe, e-mail:   
> 
> For additional commands, e-mail: 
> 
>




--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 11327] New: - HTTP 400 on any request with URL containig UTF-8 sequence staring with %C4

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=11327

HTTP 400 on any request with URL containig UTF-8 sequence staring with %C4

   Summary: HTTP 400 on any request with URL containig UTF-8
sequence staring with %C4
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Major
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Any request to the application with URL containing UTF-8 encoded character 
starting with %C4 e.g.
http://host/some_app/wst%C4%99.html

Result in Tomcat Error Report:

Apache Tomcat/4.0.4 - HTTP Status 400 - /some_app/wst?.html

type Status report

message /some_app/wst?.html

description The request sent by the client was syntactically incorrect 
(/some_app/wst?.html).

Other UTF-8 sequences (e.g. '%C5%82') work

No known workaround (other that use only plain ASCII in URL).

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 11324] New: - forward() doesnt add parameters to query string

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=11324

forward() doesnt add parameters to query string 

   Summary: forward() doesnt add parameters to query string
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Major
  Priority: Other
 Component: Servlet & JSP API
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


In Tomcat 331 I could call forward("fred.dyn?id=222") from a servlet that had 
already been called with a set of parameters say name=fred&location=uk and in 
the forwarded servlet (fred.dyn) I could get query string and it would 
contain: id=222&name=fred&location=uk in tomcat 404 (I havent tried 4.1) the 
query string only contains the id=222.

Now I realise the spec if loose in this area and it doesnt say that the query 
string should be updated - why do other containers BEA 6.0/7, WebSphere4, 
Tomcat3 - I suspect Caucho and Jetty would too (and havent time to test them) -
 do this and TC4 has taken the decision not to ?

Surely this means that there could be servlets out there that will not work in 
TC 4 if they process the query string and dont use getParameter().

I have an example web app if reqd.

james

--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

Problem with HttpSession.setAttribute

[Benno Luthiger]

Hello

Using Tomcat 4 (in this example 4.0.4) I have problems with
HttpSession.setAttribute(String name, Object value).

Tomcat implements this interface which StandardSessionFacade:
StandardSessionFacade.setAttribute(String name, Object value)

The method call is delegated to StandardSession:
StandardSession.setAttribute(String name, Object value)

On line 1185 a HttpSessionBindingEvent is created with the extended
constructor:
new HttpSessionBindingEvent((HttpSession) this, name, value)

This constructor then throws the following
java.lang.NoSuchMethodError
at
org.apache.catalina.session.StandardSession.setAttribute(StandardSession.jav
a:1186)
at
org.apache.catalina.session.StandardSessionFacade.setAttribute(StandardSessi
onFacade.java:191)
at
org.apache.catalina.session.StandardSessionFacade.setAttribute(StandardSessi
onFacade.java:191)
at
org.hip.kernel.servlet.impl.AbstractRequestHandler.getContext(AbstractReques
tHandler.java:261)
at
org.hip.kernel.servlet.impl.AbstractRequestHandler.doGet(AbstractRequestHand
ler.java:172)
at
org.hip.vif.admin.servlets.impl.VIFAdminRequestHandler.doGet(VIFAdminRequest
Handler.java:80)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:247)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:193)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
va:243)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja
va:190)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2347)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180
)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
at
org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.
java:170)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
64)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:170
)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
64)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:468)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
64)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java
:174)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:5
66)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:
1027)
at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:1125
)
at java.lang.Thread.run(Thread.java:484)

An acceptable workaround would be to create the HttpSessionBindingEvent
without the value object, i.e. new
HttpSessionBindingEvent((HttpSession)this, name). After modifying the code
in this way, my application worked without problems with Tomcat 4.

If I had the source-code of javax.servlet.http package, I could debug
further and eventually locate and correct the error.

Greetings
Benno


--
To unsubscribe, e-mail:   
For additional commands, e-mail: 

DO NOT REPLY [Bug 11318] New: - Wrong decoding in HttpServletRequest.getPathInfo()

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=11318

Wrong decoding in HttpServletRequest.getPathInfo()

   Summary: Wrong decoding in HttpServletRequest.getPathInfo()
   Product: Tomcat 4
   Version: 4.0.4 Final
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Major
  Priority: Other
 Component: Servlet & JSP API
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I call my servlet like this
http://host/app/MyServlet/some/path/with_UTF-8_encoded/characters

I have a filter installed that sets request character encoding to UTF-8 on all 
request.

HttpServletRequest.getPathInfo() seems always treat the URL as US-ASCI encoded.
On the other hand HttpServletRequest.getRequestURI() returs properly decoded 
String.

--
To unsubscribe, e-mail:   
For additional commands, e-mail: