Re: j-t-c/util, 3.3 and logging

[Costin Manolache]

Bill Barker wrote:

>> > Last time I checked, o.a.t.u.log.Log already implements o.a.c.l.Log.
>>
>> I know, but it needs a factory and manifest to be useable
>> as a c-l impl.  ( I never tried it - it may work if someone already
>> added this )
> 
> I'll look into adding a factory to qlog (since I assume that the 4.x/5.x
> groups aren't interested :).  For me, qlog does what I want, and is much
> lighter-weight than log4J (sorry Ceki, but implementing a 3.3 module for
> http://qos.ch/logging/sc.html is still on my plate, when I have the time
> :).

I have a factory 1/2 written ( well, written but not tested ). I can check 
it in if you're interested.

Costin




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

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/qlog QLogFactory.java

[costin]

costin  2002/12/19 00:03:32

  Added:   src/share/org/apache/tomcat/util/qlog QLogFactory.java
  Log:
  Old code I had in my local dirs. I didn't tested it - but it compiles
  and it should work fine.
  It allows to use qlog implementation for logging. The intention was
  to have it as a smooth transition path for components using
  j-t-c/util Log interface, and eventually to allow qlog to be used
  as a very light logger.
  
  If nobody needs it - please remove it :-)
  
  Revision  ChangesPath
  1.1  
jakarta-tomcat/src/share/org/apache/tomcat/util/qlog/QLogFactory.java
  
  Index: QLogFactory.java
  ===
  /*
   * 
   *
   * The Apache Software License, Version 1.1
   *
   * Copyright (c) 1999-2002 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", "Commons", 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
   * .
   *
   */
  
  package org.apache.tomcat.util.qlog;
  
  
  import java.lang.reflect.Constructor;
  import java.lang.reflect.Method;
  import java.util.Enumeration;
  import java.util.Hashtable;
  import java.util.Vector;
  import org.apache.commons.logging.Log;
  import org.apache.commons.logging.LogConfigurationException;
  import org.apache.commons.logging.LogFactory;
  import org.apache.commons.logging.LogSource;
  
  
  import org.apache.tomcat.util.log.*;
  
  /**
   *
   * @author Costin Manolache
   */
  public final class QLogFactory extends LogFactory {
  static LogManager logManager;
  static LogDaemon logDaemon;
  
  public QLogFactory() {
  super();
  
  if( logManager == null ) {
  logManager=new TomcatLogManager();
  
logDaemon=new LogDaemon();
logDaemon.start();
}
  }
  
  /**
   * The configuration attributes for this {@link LogFactory}.
   */
  private Hashtable attributes = new Hashtable();
  
  // previously returned instances, to avoid creation of proxies
  private Hashtable instances = new Hashtable();
  
  // - Public Methods
  /** Adapter and registry for QueueLoggers
   */
  static class TomcatLogManager extends LogManager {
TomcatLogManager() {
// can't be changed after this
LogManager olm=org.apache.tomcat.util.log.Log.setLogManager( this ); 
this.loggers=olm.getL

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/qlog LogDaemon.java QueueLogger.java

[costin]

costin  2002/12/19 00:04:25

  Modified:src/share/org/apache/tomcat/util/qlog LogDaemon.java
QueueLogger.java
  Log:
  Remove unused imports.
  
  Revision  ChangesPath
  1.3   +0 -1  
jakarta-tomcat/src/share/org/apache/tomcat/util/qlog/LogDaemon.java
  
  Index: LogDaemon.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/qlog/LogDaemon.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- LogDaemon.java23 Apr 2001 00:19:49 -  1.2
  +++ LogDaemon.java19 Dec 2002 08:04:25 -  1.3
  @@ -62,7 +62,6 @@
   
   import java.util.Date;
   
  -import org.apache.tomcat.util.collections.SimplePool;
   import org.apache.tomcat.util.collections.Queue;
   
   /**
  
  
  
  1.3   +0 -1  
jakarta-tomcat/src/share/org/apache/tomcat/util/qlog/QueueLogger.java
  
  Index: QueueLogger.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/qlog/QueueLogger.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- QueueLogger.java  21 Apr 2001 18:23:55 -  1.2
  +++ QueueLogger.java  19 Dec 2002 08:04:25 -  1.3
  @@ -63,7 +63,6 @@
   import java.util.Date;
   
   import org.apache.tomcat.util.collections.SimplePool;
  -import org.apache.tomcat.util.collections.Queue;
   
   /**
* A real implementation of the Logger abstraction.
  
  
  

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

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util/qlog LogDaemon.java LogEntry.java QLogFactory.java QueueLogger.java

[costin]

costin  2002/12/19 00:07:02

  Modified:src/share/org/apache/tomcat/util/qlog LogDaemon.java
LogEntry.java QLogFactory.java QueueLogger.java
  Log:
  More unused imports.
  
  qlog depends on util.log and commons-logging, as well as tomcat.util.collections.
  
  Revision  ChangesPath
  1.4   +0 -6  
jakarta-tomcat/src/share/org/apache/tomcat/util/qlog/LogDaemon.java
  
  Index: LogDaemon.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/qlog/LogDaemon.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- LogDaemon.java19 Dec 2002 08:04:25 -  1.3
  +++ LogDaemon.java19 Dec 2002 08:07:02 -  1.4
  @@ -56,12 +56,6 @@
*/ 
   package org.apache.tomcat.util.qlog;
   
  -import java.io.Writer;
  -import java.io.StringWriter;
  -import java.io.PrintWriter;
  -
  -import java.util.Date;
  -
   import org.apache.tomcat.util.collections.Queue;
   
   /**
  
  
  
  1.3   +0 -6  
jakarta-tomcat/src/share/org/apache/tomcat/util/qlog/LogEntry.java
  
  Index: LogEntry.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/qlog/LogEntry.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- LogEntry.java 21 Apr 2001 18:23:54 -  1.2
  +++ LogEntry.java 19 Dec 2002 08:07:02 -  1.3
  @@ -56,12 +56,6 @@
*/ 
   package org.apache.tomcat.util.qlog;
   
  -import java.io.Writer;
  -import java.io.StringWriter;
  -import java.io.PrintWriter;
  -
  -import java.util.Date;
  -
   /**
* This is an entry that is created in response to every
* Logger.log(...) call.
  
  
  
  1.2   +0 -3  
jakarta-tomcat/src/share/org/apache/tomcat/util/qlog/QLogFactory.java
  
  Index: QLogFactory.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/qlog/QLogFactory.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- QLogFactory.java  19 Dec 2002 08:03:32 -  1.1
  +++ QLogFactory.java  19 Dec 2002 08:07:02 -  1.2
  @@ -58,15 +58,12 @@
   package org.apache.tomcat.util.qlog;
   
   
  -import java.lang.reflect.Constructor;
  -import java.lang.reflect.Method;
   import java.util.Enumeration;
   import java.util.Hashtable;
   import java.util.Vector;
   import org.apache.commons.logging.Log;
   import org.apache.commons.logging.LogConfigurationException;
   import org.apache.commons.logging.LogFactory;
  -import org.apache.commons.logging.LogSource;
   
   
   import org.apache.tomcat.util.log.*;
  
  
  
  1.4   +17 -23
jakarta-tomcat/src/share/org/apache/tomcat/util/qlog/QueueLogger.java
  
  Index: QueueLogger.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/util/qlog/QueueLogger.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- QueueLogger.java  19 Dec 2002 08:04:25 -  1.3
  +++ QueueLogger.java  19 Dec 2002 08:07:02 -  1.4
  @@ -1,9 +1,9 @@
   /*
* 
  - * 
  + *
* The Apache Software License, Version 1.1
*
  - * Copyright (c) 1999 The Apache Software Foundation.  All rights 
  + * Copyright (c) 1999 The Apache Software Foundation.  All rights
* reserved.
*
* Redistribution and use in source and binary forms, with or without
  @@ -11,7 +11,7 @@
* are met:
*
* 1. Redistributions of source code must retain the above copyright
  - *notice, this list of conditions and the following disclaimer. 
  + *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
  @@ -19,15 +19,15 @@
*distribution.
*
* 3. The end-user documentation included with the redistribution, if
  - *any, must include the following acknowlegement:  
  - *   "This product includes software developed by the 
  + *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 
  + *from this software without prior written permission. For written
  

DO NOT REPLY [Bug 15508] - jsp pages have sometimes no output

[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=15508

jsp pages have sometimes no output

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

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

[PATCH] PoolTcpEndpoint.java (was: Thread priority)

[Michael]

Now that you've attracted my attention to this file
I couldn't figure what the point of this code was:

   if (running) {
   if(null!= serverSocket) {
if(factory==null){
   accepted = serverSocket.accept();
   }
   else {
   accepted = factory.acceptSocket(serverSocket);
   }
--->if(!running) {
--->if(null != accepted) {
--->accepted.close();  // rude, but unlikely!
--->accepted = null;
--->}
--->}
   if( factory != null && accepted != null)
   factory.initSocket( accepted );
   }
   }

since it could never be executed, until I realized that you must have 
meant this:

Index: PoolTcpEndpoint.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/PoolTcpEndpoint.java,v
retrieving revision 1.9
diff -u -r1.9 PoolTcpEndpoint.java
--- PoolTcpEndpoint.java19 Dec 2002 05:31:46 -  1.9
+++ PoolTcpEndpoint.java19 Dec 2002 08:20:21 -
@@ -120,7 +120,7 @@
private ServerSocket serverSocket;

ThreadPoolRunnable listener;
-private boolean running = false;
+private volatile boolean running = false;
private boolean initialized = false;
static final int debug=0;

While you're in there, some clean-up would be nice, too:

@@ -338,27 +338,21 @@
//  Private methods

Socket acceptSocket() {
+   if (!running || serverSocket == null)  return null;
+
Socket accepted = null;

   try {
-   if (running) {
-   if(null!= serverSocket) {
- if(factory==null){
-   accepted = serverSocket.accept();
-   }
-   else {
-   accepted = factory.acceptSocket(serverSocket);
-   }
-   if(!running) {
-   if(null != accepted) {
+   accepted = (factory == null) ?
+   serverSocket.accept() :
+   factory.acceptSocket( serverSocket );
+
+   if (!running && accepted != null) {
   accepted.close();  // rude, but unlikely!
   accepted = null;
-   }
-   }
+   }
   if( factory != null && accepted != null)
   factory.initSocket( accepted );
-   }
-   }
   }
   catch(InterruptedIOException iioe) {
   // normal part -- should happen regularly so



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

Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/filtersGzipOutputFilter.java

[Henri Gomez]

[EMAIL PROTECTED] wrote:

remm2002/12/18 12:36:58

  Modified:http11/src/java/org/apache/coyote/http11 Constants.java
Http11Processor.java Http11Protocol.java
  Added:   http11/src/java/org/apache/coyote/http11/filters
GzipOutputFilter.java
  Log:
  - Add support for gzip content encoding.
  - I believe some broken user agents must be excluded.


Great...

I see another test to add also, to avoid compression if the response
is allready gziped.




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

cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4 CoyoteResponse.java CoyoteWriter.java

[remm]

remm2002/12/19 00:59:50

  Modified:coyote/src/java/org/apache/coyote/tomcat4
CoyoteResponse.java CoyoteWriter.java
  Log:
  - Properly recycle writer after an error.
  
  Revision  ChangesPath
  1.31  +6 -4  
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteResponse.java
  
  Index: CoyoteResponse.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteResponse.java,v
  retrieving revision 1.30
  retrieving revision 1.31
  diff -u -r1.30 -r1.31
  --- CoyoteResponse.java   4 Dec 2002 17:43:05 -   1.30
  +++ CoyoteResponse.java   19 Dec 2002 08:59:50 -  1.31
  @@ -320,6 +320,8 @@
   facade = null;
   }
   
  +writer.recycle();
  +
   }
   
   
  
  
  
  1.3   +11 -0 
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteWriter.java
  
  Index: CoyoteWriter.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteWriter.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- CoyoteWriter.java 20 Nov 2002 13:47:58 -  1.2
  +++ CoyoteWriter.java 19 Dec 2002 08:59:50 -  1.3
  @@ -96,6 +96,17 @@
   }
   
   
  +//  Package Methods
  +
  +
  +/**
  + * Recycle.
  + */
  +void recycle() {
  +error = false;
  +}
  +
  +
   // - Writer Methods
   
   
  
  
  

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

cvs commit: jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5 CoyoteResponse.java CoyoteWriter.java

[remm]

remm2002/12/19 01:08:50

  Modified:coyote/src/java/org/apache/coyote/tomcat5
CoyoteResponse.java CoyoteWriter.java
  Log:
  - Properly recycle writer after an error.
  
  Revision  ChangesPath
  1.16  +7 -4  
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteResponse.java
  
  Index: CoyoteResponse.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteResponse.java,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- CoyoteResponse.java   4 Dec 2002 17:42:31 -   1.15
  +++ CoyoteResponse.java   19 Dec 2002 09:08:50 -  1.16
  @@ -332,6 +332,9 @@
   facade.clear();
   facade = null;
   }
  +
  +writer.recycle();
  +
   }
   
   
  
  
  
  1.3   +11 -0 
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteWriter.java
  
  Index: CoyoteWriter.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat5/CoyoteWriter.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- CoyoteWriter.java 20 Nov 2002 13:47:48 -  1.2
  +++ CoyoteWriter.java 19 Dec 2002 09:08:50 -  1.3
  @@ -96,6 +96,17 @@
   }
   
   
  +//  Package Methods
  +
  +
  +/**
  + * Recycle.
  + */
  +void recycle() {
  +error = false;
  +}
  +
  +
   // - Writer Methods
   
   
  
  
  

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

cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java

[hgomez]

hgomez  2002/12/19 01:13:16

  Modified:http11/src/java/org/apache/coyote/http11
Http11Processor.java
  Log:
  If content is allready gzipped, no need to recompress it
  
  Revision  ChangesPath
  1.49  +26 -10
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
  
  Index: Http11Processor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java,v
  retrieving revision 1.48
  retrieving revision 1.49
  diff -u -r1.48 -r1.49
  --- Http11Processor.java  18 Dec 2002 20:36:58 -  1.48
  +++ Http11Processor.java  19 Dec 2002 09:13:16 -  1.49
  @@ -257,6 +257,12 @@
   
   
   /**
  + * Minimum contentsize to make compression.
  + */
  +protected int compressionMinSize = 2048;
  +
  +
  +/**
* Host name (used to avoid useless B2C conversion on the host name).
*/
   protected char[] hostNameC = new char[0];
  @@ -976,17 +982,27 @@
   request.getMimeHeaders().getValue("accept-encoding");
   if ((acceptEncodingMB != null) 
   && (acceptEncodingMB.indexOf("gzip") != -1)) {
  -// Check content-type
  -if (compressionLevel == 1) {
  -int contentLength = response.getContentLength();
  -// FIXME: Make the value configurable
  -if ((contentLength == -1) || (contentLength > 2048)) {
  -useCompression = 
  -response.getContentType().startsWith("text/");
  -}
  -} else {
  -useCompression = true;
  + 
  +// Check in content is not allready gzipped
  +MessageBytes contentEncodingMB =
  + 
response.getMimeHeaders().getValue("Content-Encoding");
  + 
  + if ((contentEncodingMB == null) 
  + || (contentEncodingMB.indexOf("gzip") == -1))
  +{
  + // Check content-type
  + if (compressionLevel == 1) {
  + int contentLength = response.getContentLength();
  + // FIXME: Make the value configurable
  + if ((contentLength == -1) || (contentLength > 
compressionMinSize)) {
  + useCompression = 
  + response.getContentType().startsWith("text/");
  + }
  + } else {
  + useCompression = true;
  + }
   }
  +
   // Change content-length to -1 to force chunking
   if (useCompression) {
   response.setContentLength(-1);
  
  
  

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

cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java

[remm]

remm2002/12/19 01:19:06

  Modified:http11/src/java/org/apache/coyote/http11
Http11Processor.java
  Log:
  - Same, but without the tabs ;-)
  
  Revision  ChangesPath
  1.50  +17 -17
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
  
  Index: Http11Processor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java,v
  retrieving revision 1.49
  retrieving revision 1.50
  diff -u -r1.49 -r1.50
  --- Http11Processor.java  19 Dec 2002 09:13:16 -  1.49
  +++ Http11Processor.java  19 Dec 2002 09:19:06 -  1.50
  @@ -982,25 +982,25 @@
   request.getMimeHeaders().getValue("accept-encoding");
   if ((acceptEncodingMB != null) 
   && (acceptEncodingMB.indexOf("gzip") != -1)) {
  - 
  +
   // Check in content is not allready gzipped
   MessageBytes contentEncodingMB =
  - 
response.getMimeHeaders().getValue("Content-Encoding");
  - 
  - if ((contentEncodingMB == null) 
  - || (contentEncodingMB.indexOf("gzip") == -1))
  -{
  - // Check content-type
  - if (compressionLevel == 1) {
  - int contentLength = response.getContentLength();
  - // FIXME: Make the value configurable
  - if ((contentLength == -1) || (contentLength > 
compressionMinSize)) {
  - useCompression = 
  - response.getContentType().startsWith("text/");
  - }
  - } else {
  - useCompression = true;
  - }
  +response.getMimeHeaders().getValue("Content-Encoding");
  +
  +if ((contentEncodingMB == null) 
  +|| (contentEncodingMB.indexOf("gzip") == -1)){
  +// Check content-type
  +if (compressionLevel == 1) {
  +int contentLength = response.getContentLength();
  +// FIXME: Make the value configurable
  +if ((contentLength == -1) 
  +|| (contentLength > compressionMinSize)) {
  +useCompression = 
  +response.getContentType().startsWith("text/");
  +}
  +} else {
  +useCompression = true;
  +}
   }
   
   // Change content-length to -1 to force chunking
  
  
  

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

cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java

[remm]

remm2002/12/19 01:34:28

  Modified:http11/src/java/org/apache/coyote/http11
Http11Processor.java
  Log:
  - Add a way to set the minimum compression size.
  
  Revision  ChangesPath
  1.51  +10 -1 
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
  
  Index: Http11Processor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java,v
  retrieving revision 1.50
  retrieving revision 1.51
  diff -u -r1.50 -r1.51
  --- Http11Processor.java  19 Dec 2002 09:19:06 -  1.50
  +++ Http11Processor.java  19 Dec 2002 09:34:28 -  1.51
  @@ -295,8 +295,17 @@
   this.compressionLevel = 1;
   } else if (compression.equals("force")) {
   this.compressionLevel = 2;
  -} else {
  +} else if (compression.equals("off")) {
   this.compressionLevel = 0;
  +} else {
  +try {
  +// Try to parse compression as an int, which would give the
  +// minimum compression size
  +compressionMinSize = Integer.parseInt(compression);
  +this.compressionLevel = 1;
  +} catch (Exception e) {
  +this.compressionLevel = 0;
  +}
   }
   }
   
  
  
  

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

Re: cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11Http11Processor.java

[Henri Gomez]

[EMAIL PROTECTED] wrote:

remm2002/12/19 01:19:06

  Modified:http11/src/java/org/apache/coyote/http11
Http11Processor.java
  Log:
  - Same, but without the tabs ;-)


Oups, sorry.



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

DO NOT REPLY [Bug 15105] - pushBody()/popBody() error on tomcat 4.1.12

[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=15105

pushBody()/popBody() error on tomcat 4.1.12





--- Additional Comments From [EMAIL PROTECTED]  2002-12-19 10:05 ---
For now, what I do to bypass this bug is to use the method
.clearBody() before I do a popBody().

But it should not be done this why, should it be ?

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

DO NOT REPLY [Bug 15105] - pushBody()/popBody() error on tomcat 4.1.12

[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=15105

pushBody()/popBody() error on tomcat 4.1.12





--- Additional Comments From [EMAIL PROTECTED]  2002-12-19 10:06 ---
For now, what I do to bypass this bug is to use the method
.clearBody() before I do a popBody().

But it should not be done this WAY, should it be ?

Sorry( I wrote why instead of way)

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

DO NOT REPLY [Bug 15520] New: - JSP-Servlet is broken

[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=15520

JSP-Servlet is broken

   Summary: JSP-Servlet is broken
   Product: Tomcat 4
   Version: 4.1.16
  Platform: PC
OS/Version: Windows NT/2K
Status: NEW
  Severity: Critical
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


We have an application with nearly 300 JSP-Files, JavaScript und Struts 1.0.2.
It is installed as the root-context. Everything works fine with up to Tomcat
4.1.15. With 4.1.16 and 4.1.17 the JSP-servlet seems to be completly broken.
If I access the application there's quite fast (after 4 clicks) a point where
the response of all JSP-Pages is empty (seems to be a default-generated
HTML-Page with an empty HTML-body). And not only our application doesn't work
anymore. No JSP-page works anymore, i.e. the JSP-pages of the shipped
tomcat-examples in their default context (/examples).
It seems that the HTML-output is swallowed somewhere. Because if I write
Java-code into the JSP-page this code is still executed every time I access the
page.
I've tried it with the default Tomcat installation and server.xml with only one
extension - my own context (see below).
I've only tried with Windows NT.





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

DO NOT REPLY [Bug 15446] - request parameters get lost when using the ajp connector

[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=15446

request parameters get lost when using the ajp connector

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-12-19 10:57 
---
Just retested under 4.1.17 and it works now.
Sorry my timing here was bad, filed this just as the new release came out.
Still hopefully this report may save someone some time.

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

DO NOT REPLY [Bug 15474] - tomcatAuthentication ignored for Coyote JK 2 connector

[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=15474

tomcatAuthentication ignored for Coyote JK 2 connector

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-12-19 10:58 ---
You have to add:
request.tomcatAuthentication=false
in the jk2.properties file.

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

[QUESTION]: CoyoteWriter in error, never cleaned up -> NEW RELEASE/FIX

[Torsten Fohrer]

Include the patch please either in the current release or tag a new with him.

Some Reload and the empty page problem, after I have discover her, break down 
to the CoyoteWriter, are solved with this patch.

Torsten

On Thursday 19 December 2002 08:25, you wrote:
> Mark Plotnick wrote:
> > I'm using a rather complicated web page with two frames and
> > a jsp in both frames.
> >
> > The upper frame has an applet, and the applet loads a
> > document by calling a servlet (in the same session as the page).
> >
> > Clicking within the applet will cause new pages to load in the
> > lower page.
> >
> >
> > As a result of all this activity I seem to get the "Socket Error"
> > bug described in thread "Problem with Socket closing" and
> > bug#12810.
> >
> >
> > Things would still not be too bad if the "CoyoteWriter" objects
> > were recycled. When the socket error occurs, the relevant
> > "CoyoteWriter" objects get marked as being in error.
> >
> > The problem is Tomcat (4.1.17 & 16) is still trying to reuse
> > these "CoyoteWriter" objects with the result of tomcat
> > returning blank pages to the browser.
> >
> >
> > CoyoteWriter does have a "isError()" method. A grep through
> > the source reveals nothing is ever calling this method.
> >
> > It seems reasonable that after a socket write error, these
> > objects should get cleaned up and the application would
> > have a reasonable chance to recover.
>
> Yes, this is correct (and a major bug, expect a new release soon).
> There is no problem with recycling after an error. OTOH, the writer must
> not be set to a non error state right away once an IOException occurred.
>
> > I appreciate any insight and feedback on where these
> > "CoyoteWriter" objects should be managed.
>
> Here's a patch:
>
> Index: CoyoteResponse.java
> ===
> RCS file:
> /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomca
>t4/CoyoteResponse.java,v retrieving revision 1.30
> diff -r1.30 CoyoteResponse.java
> 322a323,324
>
>  > writer.recycle();
>
> Index: CoyoteWriter.java
> ===
> RCS file:
> /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomca
>t4/CoyoteWriter.java,v retrieving revision 1.2
> diff -r1.2 CoyoteWriter.java
> 98a99,109
>
>  > // 
>
> Package Methods
>
>  > /**
>  >  * Recycle.
>  >  */
>  > void recycle() {
>  > error = false;
>  > }
>
> Remy
>
>
> --
> To unsubscribe, e-mail:  
>  For additional commands,
> e-mail: 


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

[VOTE] Tomcat 4.1.18 release

[Remy Maucherat]

A bug exists (unfortunately) in Tomcat 4.1.16 and Tomcat 4.1.17 which 
causes the servlet Writer to stay in an invalid state after an 
IOException occurs (99% of the time caused by an abrupt client 
disconnection). After this happens, the processor will never be able to 
output data using the Writer, causing blank pages. This is more often 
seen with JSPs.

The bug affects Coyote HTTP/1.1, and may also affect Coyote JK 2, 
although this is less likely.

It is proposed that Tomcat 4.1.18, based on the Tomcat 4.1.17 code, with 
the addition of the patch committed by Bill fixing JK 2 SSL support, as 
well as the following patch (which I committed one hour ago):

Index: CoyoteResponse.java
===
RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteResponse.java,v
retrieving revision 1.30
diff -r1.30 CoyoteResponse.java
322a323,324
> writer.recycle();
>
Index: CoyoteWriter.java
===
RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteWriter.java,v
retrieving revision 1.2
diff -r1.2 CoyoteWriter.java
98a99,109
> //  
Package Methods
>
>
> /**
>  * Recycle.
>  */
> void recycle() {
> error = false;
> }
>
>

Please review, and vote ASAP:


[ ] Yes
[ ] No


Remy


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

Re: [VOTE] Tomcat 4.1.18 release

[Torsten Fohrer]

As a user that have this problem too.

[YES]


On Thursday 19 December 2002 12:15, you wrote:
> A bug exists (unfortunately) in Tomcat 4.1.16 and Tomcat 4.1.17 which
> causes the servlet Writer to stay in an invalid state after an
> IOException occurs (99% of the time caused by an abrupt client
> disconnection). After this happens, the processor will never be able to
> output data using the Writer, causing blank pages. This is more often
> seen with JSPs.
>
> The bug affects Coyote HTTP/1.1, and may also affect Coyote JK 2,
> although this is less likely.
>
> It is proposed that Tomcat 4.1.18, based on the Tomcat 4.1.17 code, with
> the addition of the patch committed by Bill fixing JK 2 SSL support, as
> well as the following patch (which I committed one hour ago):
>
> Index: CoyoteResponse.java
> ===
> RCS file:
> /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomca
>t4/CoyoteResponse.java,v retrieving revision 1.30
> diff -r1.30 CoyoteResponse.java
> 322a323,324
>
>  > writer.recycle();
>
> Index: CoyoteWriter.java
> ===
> RCS file:
> /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomca
>t4/CoyoteWriter.java,v retrieving revision 1.2
> diff -r1.2 CoyoteWriter.java
> 98a99,109
>
>  > // 
>
> Package Methods
>
>  > /**
>  >  * Recycle.
>  >  */
>  > void recycle() {
>  > error = false;
>  > }
>
> Please review, and vote ASAP:
>
> 
> [ ] Yes
> [ ] No
> 
>
> Remy
>
>
> --
> To unsubscribe, e-mail:  
>  For additional commands,
> e-mail: 


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

cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java

[hgomez]

hgomez  2002/12/19 03:49:55

  Modified:http11/src/java/org/apache/coyote/http11
Http11Processor.java
  Log:
  More parameters to the compression code :
  
  - Add a list of UserAgent for which no compression should be done
  - Add a list of MimeTypes for which compression is ok
  
  Also compression is disabled when not in HTTP 1.1
  
  
  Revision  ChangesPath
  1.52  +165 -40   
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
  
  Index: Http11Processor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java,v
  retrieving revision 1.51
  retrieving revision 1.52
  diff -u -r1.51 -r1.52
  --- Http11Processor.java  19 Dec 2002 09:34:28 -  1.51
  +++ Http11Processor.java  19 Dec 2002 11:49:55 -  1.52
  @@ -118,7 +118,7 @@
   response.setHook(this);
   outputBuffer = new InternalOutputBuffer(response);
   response.setOutputBuffer(outputBuffer);
  - request.setResponse(response);
  +request.setResponse(response);
   
   initializeFilters();
   
  @@ -263,6 +263,18 @@
   
   
   /**
  + * List of user agents to not use gzip with
  + */
  +protected String[] noCompressionUserAgents = null;
  +
  +
  +/**
  + * List of MIMES which could be gzipped
  + */
  +protected String[] compressableMimeTypes = null;
  +
  +
  +/**
* Host name (used to avoid useless B2C conversion on the host name).
*/
   protected char[] hostNameC = new char[0];
  @@ -310,6 +322,67 @@
   }
   
   
  +/**
  + * Add user-agent for which gzip compression didn't works
  + * The user agent String given will be exactly matched
  + * to the user-agent header submitted by the client.
  + * 
  + * @param userAgent user-agent string
  + */
  +public void addNoCompressionUserAgent(String userAgent) {
  + addStringArray(noCompressionUserAgents, userAgent);
  +}
  +
  +
  +/**
  + * Set no compression user agent list (this method is best when used with 
  + * a large number of connectors, where it would be better to have all of 
  + * them referenced a single array).
  + */
  +public void setNoCompressionUserAgents(String[] noCompressionUserAgents) {
  +this.noCompressionUserAgents = noCompressionUserAgents;
  +}
  +
  +
  +/**
  + * Return the list of no compression user agents.
  + */
  +public String[] findNoCompressionUserAgents() {
  +return (noCompressionUserAgents);
  +}
  +
  +
  +/**
  + * Add a mime-type which will be compressable
  + * The mime-type String will be exactly matched
  + * in the response mime-type header .
  + * 
  + * @param userAgent user-agent string
  + */
  +public void addCompressableMimeType(String mimeType) {
  + addStringArray(compressableMimeTypes, mimeType);
  +}
  +
  +
  +/**
  + * Set compressable mime-type list (this method is best when used with 
  + * a large number of connectors, where it would be better to have all of 
  + * them referenced a single array).
  + */
  +public void setCompressableMimeType(String[] compressableMimeTypes) {
  +this.compressableMimeTypes = compressableMimeTypes;
  +}
  +
  +
  +/**
  + * Return the list of restricted user agents.
  + */
  +public String[] findCompressableMimeTypes() {
  +return (compressableMimeTypes);
  +}
  +
  +
  +
   // - Public Methods
   
   
  @@ -336,6 +409,38 @@
   
   
   /**
  + * General use method
  + * 
  + * @param sArray the StringArray 
  + * @param value string
  + */
  +private void addStringArray(String sArray[], String value) {
  +if (sArray == null)
  +sArray = new String[0];
  +String[] results = new String[sArray.length + 1];
  +for (int i = 0; i < sArray.length; i++)
  +results[i] = sArray[i];
  +results[sArray.length] = value;
  +sArray = results;
  +}
  +
  +/**
  + * General use method
  + * 
  + * @param sArray the StringArray 
  + * @param value string
  + */
  +private boolean inStringArray(String sArray[], String value) {
  +for (int i = 0; i < sArray.length; i++) {
  +if (sArray[i].equals(value)) {
  +return true;
  +}
  +}
  +return false;
  +}
  +
  +
  +/**
* Add restricted user-agent (which will downgrade the connector 
* to HTTP/1.0 mode). The user agent String given will be exactly matched
* to the user-agent header submitted by the client.
  @@ -343,13 +448,7 @@
* @param userAgent user-agent string

MOVE method processing of WebdavServlet

[Yokota Takehiko]

Hi, all.

There is a question about WebdavServlet in Tomcat4.1.12.

I tried to send MOVE request to WebdavServlet
and I expected that a file was moved, but it was copied and deleted.

I think org.apache.catalina.servlets.WebdavServlet#doMove() should
move resource instead of copying and deleting. (Or first try to move,
and then copy and delete if it failed).

What do you think this idea is?


  YOKOTA Takehiko
[EMAIL PROTECTED]


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

RE: mod_jk and load balancer - bug?

[Martin Algesten]

A redirect can't be done relatively... The HTTP/1.1 spec for the
Location: header states:

"The field value consists of a single absolute URI."

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30

So the server must figure out how to construct an absolute URL. I've
been bitten by the same thing but in another context where I terminate
SSL on my front servers and then forward the traffic onto port 80 on my
back servers, however I do set the apache environment variable HTTPS=on
which means that my java API gets fooled into thinking the URL was
secure, e.g. request.isSecure() returns true request.getScheme() returns
https, however request.getPort() returns 80, so when I do a redirect it
constructs the URL as "https://someserver:80/something"; which fails...

I would like to see a good solution to these redirection/port/hos issues
once and for all. I believe it should be completely configurable on the
connectors what host and port should be used for redirection for https
and http. There are several bits to solve, and there must be separate
configurations for http and https.

1) hostname changes, e.g. request comes in to host A and is forwarded by
mod_proxy or similar to host B.

2) port changes, e.g. request comes in to host A on port 80 and is
forwarded by mod_proxy or so to host B port 1234.

3) "context" changes, e.g. request comes into http://A:80/some/path/this
and is rewritten to http://B:1234/path/this ... I use this to have a
"shared" SSL certificate e.g.
https://shared.host/site/www.somesite.com/webapp/path is rewritten to
http://www.somesite.com/webapp/path in a generic way. This goes
completely pear shaped since session cookie path is set to "/webapp" and
that results in the browser being completely confused. (It doesn't send
the cookie back since the requested URL is not
https://shared.host/webapp";.

I haven't thought through what needs to be done to solve any of this.
But one day I'm sure I get time to do it :)

Martin


> -Original Message-
> From: Filip Hanik [mailto:[EMAIL PROTECTED]] 
> Sent: 17 December 2002 01:11
> To: Tomcat Developers List
> Subject: mod_jk and load balancer - bug?
> 
> 
> here is a scenario
> 
> hardware stack
> 
> LoadBalancer(port80) - Apache/mod_jk 2.0.43(port81) - Tomcat
> 4.1.12(port8080/8009)
> 
> 1. The load balancer receives a request for 
> http://server/somecontext/ 2. The load > balancer forwards this 
> to apache. Apache detects /somecontext/ and makes a request 
> to Tomcat 3. Tomcat gets the request GET /somecontext/ and 
> looks up welcome files 4. Tomcat finds index.jsp as a welcome 
> file 5. Tomcat constructs a redirect using the absolute URL 
> it got from Apache
> 
> and here is the problem, in step 5 tomcat constructs an 
> absolute URL, and uses the port number from Apache which was 
> 81. hence the redirect will go to port 81.
> 
> the response back to the server is 
> Location:http://server:81/somecontext/index.jsp --which is 
> wrong, the request came in on port 80
> 
> when it would have been better if the response was the relative URL.
> 
> Is this a bug, or could we add a feature to be able to 
> configure the Coyote connector to generate absolute or 
> relative urls on sendRedirect
> 
> Filip
> 
> ~
> Namaste - I bow to the divine in you
> ~
> Filip Hanik
> Software Architect
> www.filip.net
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

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

Re: [VOTE] Tomcat 4.1.18 release

[Henri Gomez]

+1


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

DO NOT REPLY [Bug 15529] New: - Coyote/JK2 AJP 1.3 Connector gives NullPointerException

[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=15529

Coyote/JK2 AJP 1.3 Connector gives NullPointerException

   Summary: Coyote/JK2 AJP 1.3 Connector gives NullPointerException
   Product: Tomcat 4
   Version: 4.1.17
  Platform: PC
OS/Version: Other
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Connector:Coyote JK 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


When browsing in SSL mode, Tomcat prints in the stdout the error below 
reproduced in N times:

Dec 19, 2002 2:26:27 PM org.apache.jk.server.JkCoyoteHandler action
SEVERE: Error in action code
java.lang.NullPointerException
at org.apache.jk.server.JkCoyoteHandler.action(JkCoyoteHandler.java:386)
at org.apache.coyote.Response.action(Response.java:222)
at org.apache.coyote.tomcat4.CoyoteAdapter.postParseRequest
(CoyoteAdapter.java:310)
at org.apache.coyote.tomcat4.CoyoteAdapter.service
(CoyoteAdapter.java:221)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:261)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:360)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:632)
at org.apache.jk.common.ChannelSocket.processConnection
(ChannelSocket.java:590)
at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:707)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:530)
at java.lang.Thread.run(Thread.java:566)

This can be reproduced with the following software version release:
Apache/2.0.43 (Unix) mod_ssl/2.0.43 OpenSSL/0.9.6b DAV/2 mod_jk2/2.0.2

Using mod_jk(1) instead of mod_jk2 will cause the same (or similar) error also 
in non-SSL mode.

Except the printed error in catalina.out (very boring), all seems to work 
perfectly.

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

DO NOT REPLY [Bug 15529] - Coyote/JK2 AJP 1.3 Connector gives NullPointerException

[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=15529

Coyote/JK2 AJP 1.3 Connector gives NullPointerException

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2002-12-19 13:46 ---


*** This bug has been marked as a duplicate of 15456 ***

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

DO NOT REPLY [Bug 15456] - NullPointerException in JkCoyoteHandler when connecting using SSL on Apache server

[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=15456

NullPointerException in JkCoyoteHandler when connecting using SSL on Apache server

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2002-12-19 13:46 ---
*** Bug 15529 has been marked as a duplicate of this bug. ***

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

cvs commit: jakarta-tomcat-4.0 RELEASE-NOTES-4.1.txt

[remm]

remm2002/12/19 05:47:44

  Modified:.RELEASE-NOTES-4.1.txt
  Log:
  - Update release notes.
  
  Revision  ChangesPath
  1.39  +8 -1  jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt
  
  Index: RELEASE-NOTES-4.1.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-NOTES-4.1.txt,v
  retrieving revision 1.38
  retrieving revision 1.39
  diff -u -r1.38 -r1.39
  --- RELEASE-NOTES-4.1.txt 12 Dec 2002 15:47:29 -  1.38
  +++ RELEASE-NOTES-4.1.txt 19 Dec 2002 13:47:44 -  1.39
  @@ -567,6 +567,9 @@
NamingResourcesMBean:
Fix resource link creation.
   
  +[4.1.18] CoyoteWriter, CoyoteResponse:
  + SECURITY: Fix writer reuse after an IOException occurred.
  +
   
   
   Coyote Bug Fixes:
  @@ -707,6 +710,10 @@
   [4.1.17] #15258
JK 2 ChannelSocket:
Bind all addresses by default.
  +
  +[4.1.18] #15456
  + JK 2 CoyoteHandler:
  + Fix NPE occurring in SSL mode.
   
   
   
  
  
  

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

cvs commit: jakarta-tomcat-catalina/webapps/ROOT index.jsp

[remm]

remm2002/12/19 06:01:33

  Modified:webapps/ROOT index.jsp
  Log:
  - I don't see any need to create a session here (and it messes up
with my testing).
  
  Revision  ChangesPath
  1.8   +1 -0  jakarta-tomcat-catalina/webapps/ROOT/index.jsp
  
  Index: index.jsp
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/ROOT/index.jsp,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- index.jsp 14 Nov 2002 16:40:20 -  1.7
  +++ index.jsp 19 Dec 2002 14:01:33 -  1.8
  @@ -1,4 +1,5 @@
   http://www.w3.org/TR/REC-html40/strict.dtd";>
  +<%@ page session="false" %>
   
   
   
  
  
  

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

cvs commit: jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11 Http11Processor.java

[hgomez]

hgomez  2002/12/19 06:02:48

  Modified:http11/src/java/org/apache/coyote/http11
Http11Processor.java
  Log:
  Add minimum safe mime-types
  
  Revision  ChangesPath
  1.53  +1 -1  
jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java
  
  Index: Http11Processor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Processor.java,v
  retrieving revision 1.52
  retrieving revision 1.53
  diff -u -r1.52 -r1.53
  --- Http11Processor.java  19 Dec 2002 11:49:55 -  1.52
  +++ Http11Processor.java  19 Dec 2002 14:02:48 -  1.53
  @@ -271,7 +271,7 @@
   /**
* List of MIMES which could be gzipped
*/
  -protected String[] compressableMimeTypes = null;
  +protected String[] compressableMimeTypes = { "text/html", "text/xml", 
"text/plain" };
   
   
   /**
  
  
  

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

DO NOT REPLY [Bug 15531] New: - Heavy compiling jsp causes exception checkCompile

[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=15531

Heavy compiling jsp causes exception checkCompile

   Summary: Heavy compiling jsp causes exception checkCompile
   Product: Tomcat 4
   Version: Unknown
  Platform: All
OS/Version: Linux
Status: UNCONFIRMED
  Severity: Normal
  Priority: Other
 Component: Jasper 2
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


CAUSE: 
 Using iterator for a Map that is changed by more than 1 thread  
  
STACKTRACE:   
  
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:750)
at java.util.HashMap$ValueIterator.next(HashMap.java:780)
at
org.apache.jasper.compiler.JspRuntimeContext.checkCompile(JspRuntimeContext.java:308)  
  
at
org.apache.jasper.compiler.JspRuntimeContext.run(JspRuntimeContext.java:515)
at java.lang.Thread.run(Thread.java:536)

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

DO NOT REPLY [Bug 15532] New: - Ajp13 does not always contain correct server name

[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=15532

Ajp13 does not always contain correct server name

   Summary: Ajp13 does not always contain correct server name
   Product: Tomcat 3
   Version: 3.1.1 Final
  Platform: All
OS/Version: All
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Connectors
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Ajp13 does not always contain the correct server name. Tomcat version
is 3.3.1.

According to the Servlet API specification
ServletRequest#getServerName() should return the same value as the CGI
environment variable SERVER_NAME.

This is not the case if Tomcat is used with mod_jk and the Apache has
a special server name set with the "ServerName" directive and
"UseCanonicalName on":

* The Ajp13 request does not contain this server name. Instead
  it always includes the name given in the "Host" HTTP header of
  the original request, which is then returned by getServerName().

* A CGI script executed by this Apache does get the correct
  SERVER_NAME, though.

The bug is that mod_jk.c does not use the server name in Ajp13
requests as determined by the web server.

I haven't tried it but propably the fix is to
replace mod_jk.c:431

s->server_name  = (char *)(r->hostname ? r->hostname :
  r->server->server_hostname);

by 

   s->server_name = app_get_server_name(r);

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

DO NOT REPLY [Bug 15532] - Ajp13 does not always contain correct server name

[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=15532

Ajp13 does not always contain correct server name

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2002-12-19 15:23 ---
Fixed since JK 1.2.1, just get the updated release

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

cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/common ChannelSocket.java

[costin]

costin  2002/12/19 07:36:32

  Modified:jk/java/org/apache/jk/common ChannelSocket.java
  Log:
  Change log level to debug for "Connection closed". This is a normal
  message that happens quite often for Apache1.3, where each child
  process can restart after a number of requests. This would avoid
  filling the logs.
  
  Revision  ChangesPath
  1.30  +29 -29
jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelSocket.java
  
  Index: ChannelSocket.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/jk/java/org/apache/jk/common/ChannelSocket.java,v
  retrieving revision 1.29
  retrieving revision 1.30
  diff -u -r1.29 -r1.30
  --- ChannelSocket.java11 Dec 2002 07:34:25 -  1.29
  +++ ChannelSocket.java19 Dec 2002 15:36:32 -  1.30
  @@ -303,34 +303,34 @@
   /**
* @jmx:managed-operation
*/
  -public void init() throws IOException {
  -// Find a port.
  -if (startPort == 0) {
  -port = 0;
  -log.info("JK2: ajp13 disabling channelSocket");
  -running = true;
  -return;
  -}
  -if (maxPort < startPort) 
  -maxPort = startPort;
  -if (getAddress() == null)
  -setAddress("0.0.0.0");
  -for( int i=startPort; i<=maxPort; i++ ) {
  -try {
  -sSocket=new ServerSocket( i, 0, inet );
  -port=i;
  -break;
  -} catch( IOException ex ) {
  -log.info("Port busy " + i + " " + ex.toString());
  -continue;
  -}
  -}
  -
  -if( sSocket==null ) {
  -log.error("Can't find free port " + startPort + " " + maxPort );
  -return;
  -}
  -log.info("JK2: ajp13 listening on " + getAddress() + ":" + port );
  +public void init() throws IOException {
  +// Find a port.
  +if (startPort == 0) {
  +port = 0;
  +log.info("JK2: ajp13 disabling channelSocket");
  +running = true;
  +return;
  +}
  +if (maxPort < startPort) 
  +maxPort = startPort;
  +if (getAddress() == null)
  +setAddress("0.0.0.0");
  +for( int i=startPort; i<=maxPort; i++ ) {
  +try {
  +sSocket=new ServerSocket( i, 0, inet );
  +port=i;
  +break;
  +} catch( IOException ex ) {
  +log.info("Port busy " + i + " " + ex.toString());
  +continue;
  +}
  +}
  +
  +if( sSocket==null ) {
  +log.error("Can't find free port " + startPort + " " + maxPort );
  +return;
  +}
  +log.info("JK2: ajp13 listening on " + getAddress() + ":" + port );
   
   // If this is not the base port and we are the 'main' channleSocket and
   // SHM didn't already set the localId - we'll set the instance id
  @@ -567,7 +567,7 @@
   }
   } catch( Exception ex ) {
   if( ex.getMessage().indexOf( "Connection reset" ) >= 0)
  -log.info( "Server has been restarted or reset this connection");
  +log.debug( "Server has been restarted or reset this connection");
   else if (ex.getMessage().indexOf( "Read timed out" ) >=0 )
   log.info( "connection timeout reached");
   else
  
  
  

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

Re: [VOTE] Tomcat 4.1.18 release

[Costin Manolache]

I think we don't have too many choices here - it's something we must
do. 

+1

Costin

Remy Maucherat wrote:

> A bug exists (unfortunately) in Tomcat 4.1.16 and Tomcat 4.1.17 which
> causes the servlet Writer to stay in an invalid state after an
> IOException occurs (99% of the time caused by an abrupt client
> disconnection). After this happens, the processor will never be able to
> output data using the Writer, causing blank pages. This is more often
> seen with JSPs.
> 
> The bug affects Coyote HTTP/1.1, and may also affect Coyote JK 2,
> although this is less likely.
> 
> It is proposed that Tomcat 4.1.18, based on the Tomcat 4.1.17 code, with
> the addition of the patch committed by Bill fixing JK 2 SSL support, as
> well as the following patch (which I committed one hour ago):
> 
> Index: CoyoteResponse.java
> ===
> RCS file:
> 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteResponse.java,v
> retrieving revision 1.30
> diff -r1.30 CoyoteResponse.java
> 322a323,324
>  > writer.recycle();
>  >
> Index: CoyoteWriter.java
> ===
> RCS file:
> 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteWriter.java,v
> retrieving revision 1.2
> diff -r1.2 CoyoteWriter.java
> 98a99,109
>  > // 
> Package Methods
>  >
>  >
>  > /**
>  >  * Recycle.
>  >  */
>  > void recycle() {
>  > error = false;
>  > }
>  >
>  >
> 
> Please review, and vote ASAP:
> 
> 
> [ ] Yes
> [ ] No
> 
> 
> Remy




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

cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java

[costin]

costin  2002/12/19 07:55:46

  Modified:util/java/org/apache/tomcat/util/net PoolTcpEndpoint.java
  Log:
  Fix from Michael ( with strange email address ).
  Declare the "running" as volatile and some code cleanups.
  
  Revision  ChangesPath
  1.10  +39 -44
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/PoolTcpEndpoint.java
  
  Index: PoolTcpEndpoint.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/net/PoolTcpEndpoint.java,v
  retrieving revision 1.9
  retrieving revision 1.10
  diff -u -r1.9 -r1.10
  --- PoolTcpEndpoint.java  19 Dec 2002 05:31:46 -  1.9
  +++ PoolTcpEndpoint.java  19 Dec 2002 15:55:45 -  1.10
  @@ -120,7 +120,7 @@
   private ServerSocket serverSocket;
   
   ThreadPoolRunnable listener;
  -private boolean running = false;
  +private volatile boolean running = false;
   private boolean initialized = false;
   static final int debug=0;
   
  @@ -338,40 +338,35 @@
   //  Private methods
   
   Socket acceptSocket() {
  +if( !running || serverSocket==null ) return null;
  +
   Socket accepted = null;
   
try {
  - if (running) {
  - if(null!= serverSocket) {
  - if(factory==null){
  - accepted = serverSocket.accept();
  - }
  - else {
  - accepted = factory.acceptSocket(serverSocket);
  - }
  - if(!running) {
  - if(null != accepted) {
  - accepted.close();  // rude, but unlikely!
  - accepted = null;
  - }
  - }
  - if( factory != null && accepted != null)
  - factory.initSocket( accepted );
  - }
  - }
  - }
  - catch(InterruptedIOException iioe) {
  - // normal part -- should happen regularly so
  - // that the endpoint can release if the server
  - // is shutdown.
  - }
  - catch (IOException e) {
  -
  - if (running) {
  -
  - String msg = sm.getString("endpoint.err.nonfatal",
  -   serverSocket, e);
  - log.error(msg, e);
  +if(factory==null) {
  +accepted = serverSocket.accept();
  +} else {
  +accepted = factory.acceptSocket(serverSocket);
  +}
  +if(!running && (null != accepted)) {
  +accepted.close();  // rude, but unlikely!
  +accepted = null;
  +}
  +if( factory != null && accepted != null)
  +factory.initSocket( accepted );
  +}
  +catch(InterruptedIOException iioe) {
  +// normal part -- should happen regularly so
  +// that the endpoint can release if the server
  +// is shutdown.
  +}
  +catch (IOException e) {
  +
  +if (running) {
  +
  +String msg = sm.getString("endpoint.err.nonfatal",
  +serverSocket, e);
  +log.error(msg, e);
   
   if (accepted != null) {
   try {
  @@ -379,7 +374,7 @@
   accepted = null;
   } catch(Exception ex) {
   msg = sm.getString("endpoint.err.nonfatal",
  -   accepted, ex);
  +accepted, ex);
   log.warn(msg, ex);
   }
   }
  @@ -389,7 +384,7 @@
   serverSocket.close();
   } catch(Exception ex) {
   msg = sm.getString("endpoint.err.nonfatal",
  -   serverSocket, ex);
  +serverSocket, ex);
   log.warn(msg, ex);
   }
   serverSocket = null;
  @@ -397,14 +392,14 @@
   if (inet == null) {
   serverSocket = factory.createSocket(port, backlog);
   } else {
  -serverSocket = 
  -factory.createSocket(port, backlog, inet);
  +serverSocket =
  +factory.createSocket(port, backlog, inet);
   }
   if (serverTimeout >= 0)
   serverSocket.setSoTimeout(serverTimeout);
   } catch (Throwable t) {
  -msg = sm.getString("endpoint.err.fatal", 
  -   

Fwd: error-page status codes broken, no response to bugzilla report

[Donald Ball]

What does one have to do to get a response to a bug report around here? I
submitted it to bugzilla, I followed up here. If it's a bug, I'm happy to
help patch. If I'm an idiot, I'd appreciate being told so.

- donald

On 12/18/2002 at 1:00 PM Donald Ball <[EMAIL PROTECTED]> wrote:

>I submitted this bug report a few days ago:
>
>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15406
>
>It seems to me that tomcat is doing the wrong thing when it tags the error
>page contents with status code 200 instead of the actual error status
code.
>If this is the case, is anyone interested in fixing tomcat? If this is not
>the case, can someone try to explain why tomcat's behavior is correct?
>
>- donald


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

Re: [VOTE] Tomcat 4.1.18 release

[Jeanfrancois Arcand]

+1

-- Jeanfrancois

Remy Maucherat wrote:


A bug exists (unfortunately) in Tomcat 4.1.16 and Tomcat 4.1.17 which 
causes the servlet Writer to stay in an invalid state after an 
IOException occurs (99% of the time caused by an abrupt client 
disconnection). After this happens, the processor will never be able 
to output data using the Writer, causing blank pages. This is more 
often seen with JSPs.

The bug affects Coyote HTTP/1.1, and may also affect Coyote JK 2, 
although this is less likely.

It is proposed that Tomcat 4.1.18, based on the Tomcat 4.1.17 code, 
with the addition of the patch committed by Bill fixing JK 2 SSL 
support, as well as the following patch (which I committed one hour ago):

Index: CoyoteResponse.java
===
RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteResponse.java,v 

retrieving revision 1.30
diff -r1.30 CoyoteResponse.java
322a323,324
> writer.recycle();
>
Index: CoyoteWriter.java
===
RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteWriter.java,v 

retrieving revision 1.2
diff -r1.2 CoyoteWriter.java
98a99,109
> //  
Package Methods
>
>
> /**
>  * Recycle.
>  */
> void recycle() {
> error = false;
> }
>
>

Please review, and vote ASAP:


[ ] Yes
[ ] No


Remy


--
To unsubscribe, e-mail:   

For additional commands, e-mail: 





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

Re: [VOTE] Tomcat 4.1.18 release

[Mark Plotnick]

** Reply to message from Remy Maucherat <[EMAIL PROTECTED]> on Thu, 19 Dec 2002
12:15:19 +0100


> 
> It is proposed that Tomcat 4.1.18, based on the Tomcat 4.1.17 code, with 
> 
> Please review, and vote ASAP:
> 
> 
> [ ] Yes
> [ ] No
> 

 [X] Yes

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

RE: [VOTE] Tomcat 4.1.18 release

[Roseanne Zhang]

> 
> [X] Yes
> [ ] No
> 

I'm suffering by the bug. :(

-Original Message-
From: Mark Plotnick [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 19, 2002 10:00 AM
To: Tomcat Developers List
Subject: Re: [VOTE] Tomcat 4.1.18 release


** Reply to message from Remy Maucherat <[EMAIL PROTECTED]> on Thu, 19 Dec
2002
12:15:19 +0100


> 
> It is proposed that Tomcat 4.1.18, based on the Tomcat 4.1.17 code, with 
> 
> Please review, and vote ASAP:
> 
> 
> [ ] Yes
> [ ] No
> 

 [X] Yes

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



This e-mail is for the designated recipient only and may contain privileged
or confidential information. If you have received it in error, please notify
the sender immediately and delete the original. Any other use of this e-mail
is prohibited.


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

RE: j-t-c/util, 3.3 and logging

[Larry Isaacs]

I hope to spend some cycles advancing a Tomcat 3.3.2 release
over the holidays.  I'm not assuming I can finish, but hopefully
a Tomcat 3.3.2 release can be made in January.  I'll also try
to get back up to speed with Tomcat 4 & 5 and J-T-C.

I can try to help with the glog factory if I find time before
Bill does.

Cheers,
Larry

> -Original Message-
> From: Costin Manolache [mailto:[EMAIL PROTECTED]] 
> Sent: Thursday, December 19, 2002 2:52 AM
> To: [EMAIL PROTECTED]
> Subject: Re: j-t-c/util, 3.3 and logging
> 
> 
> Bill Barker wrote:
> 
> >> > Last time I checked, o.a.t.u.log.Log already implements 
> o.a.c.l.Log.
> >>
> >> I know, but it needs a factory and manifest to be useable
> >> as a c-l impl.  ( I never tried it - it may work if someone already
> >> added this )
> > 
> > I'll look into adding a factory to qlog (since I assume 
> that the 4.x/5.x
> > groups aren't interested :).  For me, qlog does what I 
> want, and is much
> > lighter-weight than log4J (sorry Ceki, but implementing a 
> 3.3 module for
> > http://qos.ch/logging/sc.html is still on my plate, when I 
> have the time
> > :).
> 
> I have a factory 1/2 written ( well, written but not tested 
> ). I can check 
> it in if you're interested.
> 
> Costin
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

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

DO NOT REPLY [Bug 15497] - deadlock in threadpool

[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=15497

deadlock in threadpool

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-12-19 16:07 ---
Nothing looks wrong. The threads are waiting for something to do.

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

RE: [VOTE] Tomcat 4.1.18 release

[Larry Isaacs]

+1

Cheers,
Larry

> -Original Message-
> From: Remy Maucherat [mailto:[EMAIL PROTECTED]] 
> Sent: Thursday, December 19, 2002 6:15 AM
> To: Tomcat Developers List
> Subject: [VOTE] Tomcat 4.1.18 release
> 
> 
> A bug exists (unfortunately) in Tomcat 4.1.16 and Tomcat 4.1.17 which 
> causes the servlet Writer to stay in an invalid state after an 
> IOException occurs (99% of the time caused by an abrupt client 
> disconnection). After this happens, the processor will never 
> be able to 
> output data using the Writer, causing blank pages. This is more often 
> seen with JSPs.
> 
> The bug affects Coyote HTTP/1.1, and may also affect Coyote JK 2, 
> although this is less likely.
> 
> It is proposed that Tomcat 4.1.18, based on the Tomcat 4.1.17 
> code, with 
> the addition of the patch committed by Bill fixing JK 2 SSL 
> support, as 
> well as the following patch (which I committed one hour ago):
> 
> Index: CoyoteResponse.java
> ===
> RCS file: 
> /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache
> /coyote/tomcat4/CoyoteResponse.java,v
> retrieving revision 1.30
> diff -r1.30 CoyoteResponse.java
> 322a323,324
>  > writer.recycle();
>  >
> Index: CoyoteWriter.java
> ===
> RCS file: 
> /home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache
> /coyote/tomcat4/CoyoteWriter.java,v
> retrieving revision 1.2
> diff -r1.2 CoyoteWriter.java
> 98a99,109
>  > //  
> Package Methods
>  >
>  >
>  > /**
>  >  * Recycle.
>  >  */
>  > void recycle() {
>  > error = false;
>  > }
>  >
>  >
> 
> Please review, and vote ASAP:
> 
> 
> [ ] Yes
> [ ] No
> 
> 
> Remy
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

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

Re: cvs commit: jakarta-tomcat-connectors/jk/java/org/apache/jk/commonChannelSocket.java

[Henri Gomez]

[EMAIL PROTECTED] wrote:

costin  2002/12/19 07:36:32

  Modified:jk/java/org/apache/jk/common ChannelSocket.java
  Log:
  Change log level to debug for "Connection closed". This is a normal
  message that happens quite often for Apache1.3, where each child
  process can restart after a number of requests. This would avoid
  filling the logs.


It's also the case when you're using Apache 2.0



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

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime JspWriterImpl.java

[remm]

remm2002/12/19 08:28:38

  Modified:jasper2/src/share/org/apache/jasper/runtime Tag:
tomcat_4_branch JspWriterImpl.java
  Log:
  - I don't see any need to flush the buffer twice. And the second attempt could
lead to an IOException.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.3.2.1   +3 -5  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/JspWriterImpl.java
  
  Index: JspWriterImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/JspWriterImpl.java,v
  retrieving revision 1.3
  retrieving revision 1.3.2.1
  diff -u -r1.3 -r1.3.2.1
  --- JspWriterImpl.java31 Mar 2002 19:27:08 -  1.3
  +++ JspWriterImpl.java19 Dec 2002 16:28:37 -  1.3.2.1
  @@ -207,8 +207,6 @@
   flushBuffer();
   if (out != null) {
   out.flush();
  -// Also flush the response buffer.
  -response.flushBuffer();
   }
   }
   
  
  
  

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

cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime JspWriterImpl.java

[remm]

remm2002/12/19 08:29:58

  Modified:jasper2/src/share/org/apache/jasper/runtime
JspWriterImpl.java
  Log:
  - I don't see any need to create a session here (and it messes up
with my testing).
  
  Revision  ChangesPath
  1.6   +3 -5  
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/JspWriterImpl.java
  
  Index: JspWriterImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime/JspWriterImpl.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- JspWriterImpl.java29 Oct 2002 00:53:02 -  1.5
  +++ JspWriterImpl.java19 Dec 2002 16:29:58 -  1.6
  @@ -197,8 +197,6 @@
   flushBuffer();
   if (out != null) {
   out.flush();
  -// Also flush the response buffer.
  -response.flushBuffer();
   }
   }
   
  
  
  

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

RE: j-t-c/util, 3.3 and logging

[Costin Manolache]

Larry Isaacs wrote:

> I hope to spend some cycles advancing a Tomcat 3.3.2 release
> over the holidays.  I'm not assuming I can finish, but hopefully
> a Tomcat 3.3.2 release can be made in January.  I'll also try
> to get back up to speed with Tomcat 4 & 5 and J-T-C.

I hope we'll reach a decision on tomcat5 hooks before that,
and to get the plugins/ working. This doesn't directly 
affect 3.3, but I would like to try to use some of the 
interceptors ( via a small wrapper ) in tomcat5.


> I can try to help with the glog factory if I find time before
> Bill does.

I checked in one. 


Costin



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

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtimeJspWriterImpl.java

[Remy Maucherat]

Martin Algesten wrote:

Interesting log comment...


Why's that?

I'm using ab to test (against that page, as it's easier), and it's too 
dumb to use sessions. So it ends up creating thousands of sessions (1 
request <-> 1 session) very quickly, messing the test results (since I'm 
not trying to test how many sessions can exist before my VM dies).

Remy


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

Re: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtimeJspWriterImpl.java

[Remy Maucherat]

Remy Maucherat wrote:

Martin Algesten wrote:


Interesting log comment...



Why's that?

I'm using ab to test (against that page, as it's easier), and it's too 
dumb to use sessions. So it ends up creating thousands of sessions (1 
request <-> 1 session) very quickly, messing the test results (since I'm 
not trying to test how many sessions can exist before my VM dies).

Ooops, I understand now. Wrong CVS message indeed (caused by a WinCVS 
feature).

Remy


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

Re: j-t-c/util, 3.3 and logging

[Henri Gomez]

Larry Isaacs wrote:

I hope to spend some cycles advancing a Tomcat 3.3.2 release
over the holidays.  I'm not assuming I can finish, but hopefully
a Tomcat 3.3.2 release can be made in January.  I'll also try
to get back up to speed with Tomcat 4 & 5 and J-T-C.

I can try to help with the glog factory if I find time before
Bill does.


+1 for 3.3.2



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

RE: error-page status codes broken, no response to bugzilla report

[Donald Ball]

On 12/19/2002 at 4:02 PM Martin Algesten wrote:

>The problem with this bug is that there are people here who don't agree
>it is a bug... which is just plain ignorant and stupid... THIS IS A
>BUGIT NEEDS FIXING!

Thank you - now I at least know that other people have observed this
behavior and I'm not merely on crack. Now it remains to show that the
behavior is incorrect. The 2.3 servlet specification doesn't explicitly
state that the status code attached to a response handled by an error-page
element should be the original status code... (Perhaps I should write to
the servlet spec group working on 2.4 to suggest making this explicit?)
However, common sense and the HTTP specification both suggest that it would
be the right thing to do. If you send a 200 instead of a 404 status code
along with an html page which says the given resource was not found, search
engines, proxy servers, et. al. will not understand that the resource is
missing.

Hmm. Digging around in the 2.3 spec more deeply, I note the description of
HttpServletResponse.sendError reads:

"Sends an error response to the client using the specified status clearing
the buffer. The server defaults to creating the response to look like an
HTML-formatted server error page containing the specified message, setting
the content type to "text/html", leaving cookies and other headers
unmodified. If an error-page declaration has been made for the web
application corresponding to the status code passed in, it will be served
back in preference to the suggested msg parameter."

The first sentence clearly states that the response sent to the client must
use the specified status code, regardless of whether the content body is
generated by the server automatically or is read from an error-page
location.

>I've tried get this one sorted as well... however, either someone will
>tell you they don't agree it is a bug and/or they will just ignore you
>until you go away.

I can't accept that. If it's a bug, if it doesn't implement the servlet or
HTTP specifications properly, it should be fixed. Apache software has
always been about correctness, security, and speed, in that order.

- donald


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

Re: [VOTE] Tomcat 4.1.18 release

[Jess M. Holle]

I'm not a commiter (so no real vote), but I was just on the verge of 
patching in these very fixes into 4.1.17 as it is useless to me without 
them.

I would *REALLY* appreciate a speedy 4.1.18 release.

--
Jess Holle

Remy Maucherat wrote:

A bug exists (unfortunately) in Tomcat 4.1.16 and Tomcat 4.1.17 which 
causes the servlet Writer to stay in an invalid state after an 
IOException occurs (99% of the time caused by an abrupt client 
disconnection). After this happens, the processor will never be able 
to output data using the Writer, causing blank pages. This is more 
often seen with JSPs.

The bug affects Coyote HTTP/1.1, and may also affect Coyote JK 2, 
although this is less likely.

It is proposed that Tomcat 4.1.18, based on the Tomcat 4.1.17 code, 
with the addition of the patch committed by Bill fixing JK 2 SSL 
support, as well as the following patch (which I committed one hour ago):

Index: CoyoteResponse.java
===
RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteResponse.java,v 

retrieving revision 1.30
diff -r1.30 CoyoteResponse.java
322a323,324
> writer.recycle();
>
Index: CoyoteWriter.java
===
RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteWriter.java,v 

retrieving revision 1.2
diff -r1.2 CoyoteWriter.java
98a99,109
> //  
Package Methods
>
>
> /**
>  * Recycle.
>  */
> void recycle() {
> error = false;
> }
>
>

Please review, and vote ASAP:


[ ] Yes
[ ] No


Remy


--
To unsubscribe, e-mail:   

For additional commands, e-mail: 






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

jsp:plugin tag MAYSCRIPT parameter not supported

[Mark Plotnick]

Because the MAYSCRIPT parameter is not supported in
the jsp:plugin tag I had to switch to directly
using the APPLET tags in my jsp.

I'm not sure who should be made aware of this
to fix the standard but it's possible the JSP
implementors here might want to add this before
it's official since an applet can't call in page
javascript without this parameter.

Mark Plotnick
Ensodex, Inc.

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

Re: [VOTE] Tomcat 4.1.18 release

[Amy Roh]

Please review, and vote ASAP:


[X] Yes
[ ] No




Amy


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

cvs commit: jakarta-tomcat-site/xdocs index.xml

[remm]

remm2002/12/19 10:31:42

  Modified:docs index.html
   xdocsindex.xml
  Log:
  - Update to 4.1.18.
  
  Revision  ChangesPath
  1.34  +2 -2  jakarta-tomcat-site/docs/index.html
  
  Index: index.html
  ===
  RCS file: /home/cvs/jakarta-tomcat-site/docs/index.html,v
  retrieving revision 1.33
  retrieving revision 1.34
  diff -u -r1.33 -r1.34
  --- index.html17 Dec 2002 16:40:23 -  1.33
  +++ index.html19 Dec 2002 18:31:42 -  1.34
  @@ -179,7 +179,7 @@
   
   
   
  -4.1.17
  +4.1.18
   
   
   
  @@ -227,7 +227,7 @@
   Catalina) that is based on completely new architecture.  The 4.x releases
   implement the Servlet 2.3 and JSP 1.2
   specifications.
  -Tomcat 4.1.x.  
Tomcat 4.1.17 Stable is the latest release.
  +Tomcat 4.1.x.  
Tomcat 4.1.18 Stable is the latest release.
   Tomcat 4.1 is a refactoring of Tomcat 4.0.x, and contains significant 
   enhancements, including:
   
  
  
  
  1.27  +2 -2  jakarta-tomcat-site/xdocs/index.xml
  
  Index: index.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-site/xdocs/index.xml,v
  retrieving revision 1.26
  retrieving revision 1.27
  diff -u -r1.26 -r1.27
  --- index.xml 17 Dec 2002 13:26:04 -  1.26
  +++ index.xml 19 Dec 2002 18:31:42 -  1.27
  @@ -45,7 +45,7 @@
   
   
 2.3/1.2
  -  4.1.17
  +  4.1.18
   
   
   
  @@ -75,7 +75,7 @@
   implement the Servlet 2.3 and JSP 1.2
   specifications.
   
  -Tomcat 4.1.x.  Tomcat 4.1.17 Stable is the latest release.
  +Tomcat 4.1.x.  Tomcat 4.1.18 Stable is the latest release.
   Tomcat 4.1 is a refactoring of Tomcat 4.0.x, and contains significant 
   enhancements, including:
   
  
  
  

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

RE: error-page status codes broken, no response to bugzilla report

[Martin Algesten]

The problem with this bug is that there are people here who don't agree
it is a bug... which is just plain ignorant and stupid... THIS IS A
BUGIT NEEDS FIXING!

I've tried get this one sorted as well... however, either someone will
tell you they don't agree it is a bug and/or they will just ignore you
until you go away.

Martin



> -Original Message-
> From: Donald Ball [mailto:[EMAIL PROTECTED]] 
> Sent: 19 December 2002 15:55
> To: [EMAIL PROTECTED]
> Subject: Fwd: error-page status codes broken, no response to 
> bugzilla report
> 
> 
> What does one have to do to get a response to a bug report 
> around here? I submitted it to bugzilla, I followed up here. 
> If it's a bug, I'm happy to help patch. If I'm an idiot, I'd 
> appreciate being told so.
> 
> - donald
> 
> On 12/18/2002 at 1:00 PM Donald Ball <[EMAIL PROTECTED]> wrote:
> 
> >I submitted this bug report a few days ago:
> >
> >http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15406
> >
> >It seems to me that tomcat is doing the wrong thing when it tags the 
> >error page contents with status code 200 instead of the actual error 
> >status
> code.
> >If this is the case, is anyone interested in fixing tomcat? 
> If this is 
> >not the case, can someone try to explain why tomcat's behavior is 
> >correct?
> >
> >- donald
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

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

FW: Broken link, webbaster?

[Pier Fumagalli]

FYI, not acked...

-- Forwarded Message
From: Andrew Moise <[EMAIL PROTECTED]>
Date: Thu, 19 Dec 2002 13:31:00 -0500
To: [EMAIL PROTECTED]
Subject: Broken link, webbaster?

So I'm guessing you know this already, but the link in the top story
on jakarta.apache.org ("17 Dec 2002 - Tomcat 4.1.17 Stable Released")
to binary & source distributions is broken.

Also, the email business at the bottom says "webbaster," which should
probably be fixed if it isn't a joke.
-- End of Forwarded Message


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

Re: jsp:plugin tag MAYSCRIPT parameter not supported

[Mark Roth]

Hi Mark,

Thanks for your feedback.  For best results, please send feedback like 
this to [EMAIL PROTECTED]

This has been an RFE since JSP 1.1.  I'm asking the expert group about 
it now.  If all goes well, we can hopefully add it for JSP 2.0.

---
Mark Roth, Java Software
JSP 2.0 Co-Specification Lead
Sun Microsystems, Inc.


Mark Plotnick wrote:
Because the MAYSCRIPT parameter is not supported in
the jsp:plugin tag I had to switch to directly
using the APPLET tags in my jsp.

I'm not sure who should be made aware of this
to fix the standard but it's possible the JSP
implementors here might want to add this before
it's official since an applet can't call in page
javascript without this parameter.

Mark Plotnick
Ensodex, Inc.

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





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

Re: [VOTE] Tomcat 4.1.18 release

[Matt Fury]

 Please review, and vote ASAP:
 
 
 [x] Yes
 [ ] No
 

-Matt


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

DO NOT REPLY [Bug 15544] New: - fix the documentation for DataSourceRealm

[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=15544

fix the documentation for DataSourceRealm

   Summary: fix the documentation for DataSourceRealm
   Product: Tomcat 4
   Version: 4.1.17
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Webapps:Documentation
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The documentation for the new DataSourceRealm in realm-howto.xml seems to have
been copied from JDBCRealm but it wasn't changed completely to reflect the
proper usage of DataSourceRealm.

I'll attach a patch...

Kevin.

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

DO NOT REPLY [Bug 15544] - fix the documentation for DataSourceRealm

[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=15544

fix the documentation for DataSourceRealm





--- Additional Comments From [EMAIL PROTECTED]  2002-12-19 19:35 ---
Created an attachment (id=4231)
patch realm-howto.xml for new DataSourceRealm

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

Re: [VOTE] Tomcat 4.1.18 release

[Bill Barker]

> Please review, and vote ASAP:
> 
> 
> [X] Yes
> [ ] No
> 
> 



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

RE: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtime JspWriterImpl.java

[Martin Algesten]

Interesting log comment...

Martin

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] 
> Sent: 19 December 2002 16:30
> To: [EMAIL PROTECTED]
> Subject: cvs commit: 
> jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runt
> ime JspWriterImpl.java
> 
> 
> remm2002/12/19 08:29:58
> 
>   Modified:jasper2/src/share/org/apache/jasper/runtime
> JspWriterImpl.java
>   Log:
>   - I don't see any need to create a session here (and it messes up
> with my testing).
>   
>   Revision  ChangesPath
>   1.6   +3 -5  
> jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runt
> ime/JspWriterImpl.java
>   
>   Index: JspWriterImpl.java
>   ===
>   RCS file: 
> /home/cvs/jakarta-tomcat-jasper/jasper2/src/share/org/apache/j
> asper/runtime/JspWriterImpl.java,v
>   retrieving revision 1.5
>   retrieving revision 1.6
>   diff -u -r1.5 -r1.6
>   --- JspWriterImpl.java  29 Oct 2002 00:53:02 -  1.5
>   +++ JspWriterImpl.java  19 Dec 2002 16:29:58 -  1.6
>   @@ -197,8 +197,6 @@
>flushBuffer();
>if (out != null) {
>out.flush();
>   -// Also flush the response buffer.
>   -response.flushBuffer();
>}
>}
>
>   
>   
>   
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

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

Re: MOVE method processing of WebdavServlet

[Michael Smith]

Yokota Takehiko wrote:

Hi, all.

There is a question about WebdavServlet in Tomcat4.1.12.

I tried to send MOVE request to WebdavServlet
and I expected that a file was moved, but it was copied and deleted.

I think org.apache.catalina.servlets.WebdavServlet#doMove() should
move resource instead of copying and deleting. (Or first try to move,
and then copy and delete if it failed).

What do you think this idea is?


The webdav spec says that a MOVE should be treated as a COPY followed by 
a DELETE. It's difficult to precisely maintain these semantics without 
actually _doing_ a copy then a delete (though in the fairly limited 
catalina webdav servlet it shouldn't be too hard). There's no compelling 
reason to make this change.

Mike



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

Re: [VOTE] Tomcat 4.1.18 release

[Punky Tse]

Remy,

I checked the cvs and found there are some number of changes in the 
writer and response in coyote starting from 4.1.12.  (See the diff from 
4.1.12).  Many of the changes are started at around 4.1.15/16.

I think there is the problem in the roll out procedures, especially when 
a release is voted by the committer as stable and before the release 
manager declare it as GA.  Stability test and code review should be 
thoroughly run.

May be in 5.0, we could do better on this.

- Punky

P.S. I remember there was discussion in the release procedure or 
numbering guides.  But I cannot find one in tomcat site.  Is it just 
from http project? (http://httpd.apache.org/dev/release.html)


Remy Maucherat wrote:
A bug exists (unfortunately) in Tomcat 4.1.16 and Tomcat 4.1.17 which 
causes the servlet Writer to stay in an invalid state after an 
IOException occurs (99% of the time caused by an abrupt client 
disconnection). After this happens, the processor will never be able to 
output data using the Writer, causing blank pages. This is more often 
seen with JSPs.

The bug affects Coyote HTTP/1.1, and may also affect Coyote JK 2, 
although this is less likely.

It is proposed that Tomcat 4.1.18, based on the Tomcat 4.1.17 code, with 
the addition of the patch committed by Bill fixing JK 2 SSL support, as 
well as the following patch (which I committed one hour ago):

Index: CoyoteResponse.java
===
RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteResponse.java,v 

retrieving revision 1.30
diff -r1.30 CoyoteResponse.java
322a323,324
 > writer.recycle();
 >
Index: CoyoteWriter.java
===
RCS file: 
/home/cvs/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteWriter.java,v 

retrieving revision 1.2
diff -r1.2 CoyoteWriter.java
98a99,109
 > //  
Package Methods
 >
 >
 > /**
 >  * Recycle.
 >  */
 > void recycle() {
 > error = false;
 > }
 >
 >

Please review, and vote ASAP:


[ ] Yes
[ ] No


Remy


--
To unsubscribe, e-mail:   

For additional commands, e-mail: 




===
RCS file: 
/home/cvspublic/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteResponse.java,v
retrieving revision 1.25
retrieving revision 1.31
diff -u -r1.25 -r1.31
--- 
jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteResponse.java
 2002/09/12 06:42:11 1.25
+++ 
+jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteResponse.java
+ 2002/12/19 08:59:50 1.31
@@ -1,7 +1,7 @@
 /*
- * $Header: 
/home/cvspublic/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteResponse.java,v
 1.25 2002/09/12 06:42:11 amyroh Exp $
- * $Revision: 1.25 $
- * $Date: 2002/09/12 06:42:11 $
+ * $Header: 
+/home/cvspublic/jakarta-tomcat-connectors/coyote/src/java/org/apache/coyote/tomcat4/CoyoteResponse.java,v
+ 1.31 2002/12/19 08:59:50 remm Exp $
+ * $Revision: 1.31 $
+ * $Date: 2002/12/19 08:59:50 $
  *
  * 
  *
@@ -69,7 +69,6 @@
 import java.io.OutputStream;
 import java.io.PrintWriter;
 import java.net.MalformedURLException;
-import java.net.URL;
 import java.text.SimpleDateFormat;
 import java.util.ArrayList;
 import java.util.Date;
@@ -95,6 +94,7 @@
 import org.apache.tomcat.util.buf.UEncoder;
 import org.apache.tomcat.util.http.MimeHeaders;
 import org.apache.tomcat.util.http.ServerCookie;
+import org.apache.tomcat.util.net.URL;
 
 import org.apache.coyote.Response;
 
@@ -116,7 +116,7 @@
  *
  * @author Remy Maucherat
  * @author Craig R. McClanahan
- * @version $Revision: 1.25 $ $Date: 2002/09/12 06:42:11 $
+ * @version $Revision: 1.31 $ $Date: 2002/12/19 08:59:50 $
  */
 
 public class CoyoteResponse
@@ -320,6 +320,8 @@
 facade = null;
 }
 
+writer.recycle();
+
 }
 
 
@@ -330,7 +332,7 @@
  * Return the number of bytes actually written to the output stream.
  */
 public int getContentCount() {
-return outputBuffer.getBytesWritten();
+return outputBuffer.getContentWritten();
 }
 
 
@@ -501,7 +503,6 @@
 } catch(Throwable t) {
 t.printStackTrace();
 }
-coyoteResponse.finish();
 }
 
 
@@ -982,10 +983,16 @@
  * @param url URL to be encoded
  */
 public String encodeURL(String url) {
-
-if (isEncodeable(toAbsolute(url))) {
+
+String absolute = toAbsolute(url);
+if (isEncodeable(absolute)) {
 HttpServletRequest hreq =
 (HttpServletRequest) request.getRequest();
+
+// W3c spec clearly said 
+if (

Re: MOVE method processing of WebdavServlet

[Yokota Takehiko]

> The webdav spec says that a MOVE should be treated as a COPY followed by 
> a DELETE. It's difficult to precisely maintain these semantics without 
> actually _doing_ a copy then a delete (though in the fairly limited 
> catalina webdav servlet it shouldn't be too hard). There's no compelling 
> reason to make this change.
> 
> Mike

I see. Thank you for telling me the reason.


  YOKOTA Takehiko
[EMAIL PROTECTED]


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

DO NOT REPLY [Bug 15554] New: - Connection exception thrown during shutdown

[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=15554

Connection exception thrown during shutdown

   Summary: Connection exception thrown during shutdown
   Product: Tomcat 4
   Version: 4.1.12
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


J2SDK - 1.4.1
OS ver - RedHat 8.0

I have noticed that java.net.ConnectionException: Connection refused is thrown 
when Tomcat is started and shutdown with any http requests. 

My installation shuts down fine if a HTTP request is made but will throw the 
error is I start and shutdown immediately.

[root@lin-webserver root]# startup.sh
Using CATALINA_BASE:   /usr/local/jakarta/jakarta-tomcat-4.1.12
Using CATALINA_HOME:   /usr/local/jakarta/jakarta-tomcat-4.1.12
Using CATALINA_TMPDIR: /usr/local/jakarta/jakarta-tomcat-4.1.12/temp
Using JAVA_HOME:   /usr/java/j2sdk1.4.1_01
[root@lin-webserver root]# shutdown.sh
Using CATALINA_BASE:   /usr/local/jakarta/jakarta-tomcat-4.1.12
Using CATALINA_HOME:   /usr/local/jakarta/jakarta-tomcat-4.1.12
Using CATALINA_TMPDIR: /usr/local/jakarta/jakarta-tomcat-4.1.12/temp
Using JAVA_HOME:   /usr/java/j2sdk1.4.1_01
Catalina.stop: java.net.ConnectException: Connection refused
java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158)
at java.net.Socket.connect(Socket.java:426)
at java.net.Socket.connect(Socket.java:376)
at java.net.Socket.(Socket.java:291)
at java.net.Socket.(Socket.java:119)
at org.apache.catalina.startup.Catalina.stop(Catalina.java:579)
at org.apache.catalina.startup.Catalina.execute(Catalina.java:402)
at org.apache.catalina.startup.Catalina.process(Catalina.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203)
[root@lin-webserver root]# startup.sh
Using CATALINA_BASE:   /usr/local/jakarta/jakarta-tomcat-4.1.12
Using CATALINA_HOME:   /usr/local/jakarta/jakarta-tomcat-4.1.12
Using CATALINA_TMPDIR: /usr/local/jakarta/jakarta-tomcat-4.1.12/temp
Using JAVA_HOME:   /usr/java/j2sdk1.4.1_01
[root@lin-webserver root]# shutdown.sh
Using CATALINA_BASE:   /usr/local/jakarta/jakarta-tomcat-4.1.12
Using CATALINA_HOME:   /usr/local/jakarta/jakarta-tomcat-4.1.12
Using CATALINA_TMPDIR: /usr/local/jakarta/jakarta-tomcat-4.1.12/temp
Using JAVA_HOME:   /usr/java/j2sdk1.4.1_01
[root@lin-webserver root]# startup.sh
Using CATALINA_BASE:   /usr/local/jakarta/jakarta-tomcat-4.1.12
Using CATALINA_HOME:   /usr/local/jakarta/jakarta-tomcat-4.1.12
Using CATALINA_TMPDIR: /usr/local/jakarta/jakarta-tomcat-4.1.12/temp
Using JAVA_HOME:   /usr/java/j2sdk1.4.1_01
[root@lin-webserver root]#

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

DO NOT REPLY [Bug 15554] - Connection exception thrown during shutdown

[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=15554

Connection exception thrown during shutdown

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID



--- Additional Comments From [EMAIL PROTECTED]  2002-12-20 03:31 ---
It is the default behaviour. When you start the server, it binds 8080 port for
HTTP request and 8005 for shutdown request. If you call shutdown before the 
server binds to 8005 then this exception will occur. It simply means either no 
server is running or server is not intialized completely.

 Next time, please ask on userlist before posting a bug.

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

RE: cvs commit: jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runtimeJspWriterImpl.java

[Martin Algesten]

I will not say anything about a certain operating system and
point'n'click kind of user interfaces, even if it is very tempting ;)

Martin


> -Original Message-
> From: Remy Maucherat [mailto:[EMAIL PROTECTED]] 
> Sent: 19 December 2002 16:42
> To: Tomcat Developers List
> Subject: Re: cvs commit: 
> jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/runt
> imeJspWriterImpl.java
> 
> 
> Remy Maucherat wrote:
> > Martin Algesten wrote:
> > 
> >> Interesting log comment...
> > 
> > 
> > Why's that?
> > 
> > I'm using ab to test (against that page, as it's easier), 
> and it's too
> > dumb to use sessions. So it ends up creating thousands of 
> sessions (1 
> > request <-> 1 session) very quickly, messing the test 
> results (since I'm 
> > not trying to test how many sessions can exist before my VM dies).
> 
> Ooops, I understand now. Wrong CVS message indeed (caused by a WinCVS 
> feature).
> 
> Remy
> 
> 
> --
> To unsubscribe, e-mail:   
>  [EMAIL PROTECTED]>
> For 
> additional commands, 
> e-mail: 
> 
> 

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

DO NOT REPLY [Bug 3888] - WebappClassLoader: Lifecycle error : CL stopped

[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=3888

WebappClassLoader: Lifecycle error : CL stopped





--- Additional Comments From [EMAIL PROTECTED]  2002-12-20 05:02 ---
I can now say that I most commonly see this error when I double compile. 

In other words, I will re-compile and it will cause a classloader change. 
Then, if I re-compile once more before loading the servlet, I will see this 
error.

I also see this error happen more often when the files that change are not 
.class files. Say for example, I have a resource bundle .properties file in 
my classpath that requires a change...for example:

WebappClassLoader:   Resource '/WEB-INF/classes/
ScarabBundle.properties' was modified; Date is now: Thu Dec 19 
20:57:57 PST 2002 Was: Thu Dec 19 20:09:44 PST 2002
WebappClassLoader:   Resource '/WEB-INF/classes/org/tigris/scarab/
om/Issue.class' was modified; Date is now: Thu Dec 19 20:59:04 PST 
2002 Was: Thu Dec 19 20:10:42 PST 2002
WebappClassLoader: Lifecycle error : CL stopped
WebappClassLoader: Lifecycle error : CL stopped
WebappClassLoader: Lifecycle error : CL stopped
WebappClassLoader: Lifecycle error : CL stopped
WebappClassLoader: Lifecycle error : CL stopped
WebappClassLoader: Lifecycle error : CL stopped
WebappClassLoader: Lifecycle error : CL stopped

Anyway, maybe that is more hints.

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

DO NOT REPLY [Bug 3888] - WebappClassLoader: Lifecycle error : CL stopped

[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=3888

WebappClassLoader: Lifecycle error : CL stopped





--- Additional Comments From [EMAIL PROTECTED]  2002-12-20 05:03 ---
adding remy to this issue since he is the only one out there that can fix it.

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

DO NOT REPLY [Bug 15555] New: - Setting cookie="false" appears to still use cookies.

[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=1

Setting cookie="false" appears to still use cookies.

   Summary: Setting cookie="false" appears to still use cookies.
   Product: Tomcat 4
   Version: 4.0.6 Final
  Platform: PC
OS/Version: Windows XP
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I'm trying to disable cookies to use URL rewriting.

Using NetBeans, I set the server.xml Context as follows:


However, every time I view a jsp from this context in my browser, a jsessionid
cookie is still set.  Even when the server is restarted, this behaviour continues.

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

DO NOT REPLY [Bug 15557] New: - Remove use of URL.setURLStreamHandlerFactory()

[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=15557

Remove use of URL.setURLStreamHandlerFactory()

   Summary: Remove use of URL.setURLStreamHandlerFactory()
   Product: Tomcat 4
   Version: 4.1.18
  Platform: All
OS/Version: All
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


o.a.c.loader.WebappLoader calls URL.setURLStreamHandlerFactory() with an
instance of o.a.n.resources.DirContextURLStreamHandlerFactory in its start()
method. This factory returns URL stream handlers for the "jndi" protocol used
for web app resources. With the URL stream handler factory in place for this
protocol, URL instances can be created for URLs like
"jar:jndi:/WEB-INF/lib/foo.jar!/" and calling openConnection on such a URL
returns a JarURLConnection. This feature is used in some places in Catalina and
Jasper to scan for JAR entries.

However, registering a URL stream handler factory with
URL.setURLStreamHandlerFactory() has nasty side effects. I'm working on a
slimmed down Tomcat distribution package and among other things it will support
upgrades and feature additions in a live Tomcat instance by replacing the
classloaders for all server classes. This fails when a URL stream handler has
been registered this way, since the URL class keeps a reference to the stream
handler factory instance that was loaded by the original classloader. Since the
setURLStreamHandlerFactory() can only be called once per JVM instance, using it
for Tomcat internals also prevents an application that embeds Tomcat to use it.

I therefore suggest a different approach. The o.a.c.c.ApplicationContext already
returns URL instances that are created with an instance of
DirContextURLStreamHandler as its stream handler. This means that calling
openStream() on a URL returned by ServletContext.getResource() returns a stream
to the underlying JNDI resource. Wrapping a java.util.jar.JarInputStream around
this stream provides access to the JAR entries. A positive side-effect of this
approach is that it solves the problem with closing JarFile that is mentioned in
various places; there's no JarFile to close with this approach and closing the
JarInputStream works fine.

In more detail, this is what needs to be done to avoid the side effects of
setURLStreamHandlerFactory():
1) In o.a.c.loader.WebappLoader#start(), remove the call to
URL.setURLStreamHandlerFactory()
2) Remove the o.a.n.resources.DirContextURLStreamHandlerFactory class
3) In all places where URLs like "jar:jndi:/WEB-INF/lib/foo.jar!/" are created
to access JAR entries, replace it with code that instead wraps a JarInputStream
around the stream retrieved from the ServletContext.getResourceAsStream(). As
far as I can tell, there are three places in Catalina and Jasper (I have not
looked as non-essential code, such as the various management applications):
  + o.a.c.startup.ContextConfig
  + o.a.j.compiler.TagLibrayInfoImpl
  + o.a.j.compiler.TldLocationsCache

I have made these changes for my distribution, but it would be really nice to
see the same changes made in the Tomcat source. Here is an updated version of
the affected o.a.c.startup.ContextConfig code:

private void tldScanJar(String resourcePath, SAXParser saxParser,
DefaultHandler tldHandler) throws Exception {

if (debug >= 1) {
log(" Scanning JAR at resource path '" + resourcePath + "'");
}

String name = null;
JarInputStream jarIS = null;
try {
URL url = context.getServletContext().getResource(resourcePath);
if (url == null) {
throw new IllegalArgumentException
(sm.getString("contextConfig.tldResourcePath",
  resourcePath));
}
jarIS = new JarInputStream(url.openStream());
JarEntry entry = null;
while ((entry = jarIS.getNextJarEntry()) != null) {
name = entry.getName();
if (debug >= 2) {
log(" Looking at '" + name + "' in '" + resourcePath + "'");
}
if (!name.startsWith("META-INF/")) {
continue;
}
if (!name.endsWith(".tld")) {
continue;
}
if (debug >= 2) {
log("  Processing TLD at '" + name + "'");
}
tldScanStream(jarIS, saxParser, tldHandler);
}
} catch (Exception e) {
if (name == null) {
log(sm.getString("co

Logging Error: Unknown error writing event.

[Niket Anand]

Hello,
I have successfully integrated Apache2.0.4(WIN32) with
JBoss-2.4.7_Tomcat-4.0.4 with the help of mod_jk2.dll.
While running the Jboss server with catalina it is running properly but
showing some error in console mentioned at the end.
I think CoyoteRequest class is not able to assign Request object and giving
NullPointerException
I have put


  


in Catalina_Home/conf/server.xml and JBoss_Home/conf/catalina/jboss.jcml

Please help me as I have to track this error out asap.

[17:29:56,609,STDERR] Logging Error: Unknown error writing event.
[17:29:56,609,STDERR] java.lang.NullPointerException
[17:29:56,609,STDERR]  at
org.apache.coyote.tomcat4.CoyoteRequestFacade.getRequestURI(CoyoteRequestFac
ade.java:350)
[17:29:56,609,STDERR]
[17:29:56,609,STDERR]  at
org.apache.cocoon.environment.http.HttpRequest.getRequestURI(HttpRequest.jav
a:144)
[17:29:56,609,STDERR]
[17:29:56,609,STDERR]  at
org.apache.cocoon.util.log.CocoonLogFormatter.getURI(CocoonLogFormatter.java
:155)
[17:29:56,609,STDERR]
[17:29:56,609,STDERR]  at
org.apache.cocoon.util.log.CocoonLogFormatter.formatPatternRun(CocoonLogForm
atter.java:102)
[17:29:56,609,STDERR]
[17:29:56,609,STDERR]  at
org.apache.cocoon.util.log.ExtensiblePatternFormatter.format(ExtensiblePatte
rnFormatter.java:334)
[17:29:56,609,STDERR]
[17:29:56,609,STDERR]  at
org.apache.log.output.AbstractOutputTarget.format(AbstractOutputTarget.java:
133)
[17:29:56,609,STDERR]
[17:29:56,609,STDERR]  at
org.apache.log.output.AbstractOutputTarget.doProcessEvent(AbstractOutputTarg
et.java:92)
[17:29:56,609,STDERR]
[17:29:56,609,STDERR]  at
org.apache.log.output.AbstractTarget.processEvent(AbstractTarget.java:70)
[17:29:56,609,STDERR]
[17:29:56,609,STDERR]  at org.apache.log.Logger.output(Logger.java:559)
[17:29:56,609,STDERR]
[17:29:56,609,STDERR]  at org.apache.log.Logger.output(Logger.java:538)
[17:29:56,609,STDERR]
[17:29:56,609,STDERR]  at org.apache.log.Logger.debug(Logger.java:110)
[17:29:56,609,STDERR]
[17:29:56,609,STDERR]  at
org.apache.cocoon.servlet.CocoonServlet.getEnvironment(CocoonServlet.java:75
7)
[17:29:56,625,STDERR]
[17:29:56,625,STDERR]  at
org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:633)
[17:29:56,625,STDERR]
[17:29:56,625,STDERR]  at
javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
[17:29:56,625,STDERR]
[17:29:56,625,STDERR]  at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application
FilterChain.java:247)
[17:29:56,625,STDERR]
[17:29:56,625,STDERR]  at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh
ain.java:193)
[17:29:56,625,STDERR]
[17:29:56,625,STDERR]  at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja
va:243)

Thanks
Niket



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

Re: help with DataSourceRealm in 4.1.17

[Kevin HaleBoyes]

Replying to my own email...

I think I can see the problem but I'm no further ahead in solving
it.  It seems to be a timing issue.  The realm is being configured
before the Resource is added.

In the localhost_cml_log.2002-12-19.txt file I can see the Realm
error (NameNotFoundException) before the messages for the
NamingContextListener.

2002-12-19 15:54:40 NamingContextListener[/Standalone/localhost/cml]:
Creating JNDI naming context
2002-12-19 15:54:40 NamingContextListener[/Standalone/localhost/cml]:
  Resource parameters for jdbc/Db = ResourceParams[name=jdbc/Db,
parameters={url=jdbc:oracle:thin:@200.65.6.188:1521:tiggs9i,
validationQuery=select sysdate from dual, maxIdle=10, maxActive=20,
driverClassName=oracle.jdbc.OracleDriver, maxWait=-1, username=cml,
factory=org.apache.commons.dbcp.BasicDataSourceFactory,
password=cml}]
2002-12-19 15:54:40 NamingContextListener[/Standalone/localhost/cml]:
  Adding resource ref jdbc/Db

I've considered moving the Resource definitions into the server.xml
file to see if that fixes the problem but that solution is not
desirable as I'd like to keep everything to do with my webapp in
the cml.xml file.

Help would be appreciated.
Kevin.

P.S.  I've included tomcat-dev to the recipients as it seems to be
an internals thing and less of a user issue.  Sorry if I'm wrong
and it doesn't belong on the dev list.



--- Kevin HaleBoyes <[EMAIL PROTECTED]> wrote:
> I've been using JDBCRealm successfully in my application but
> jumped on the DataSourceRealm when I saw it in 4.1.17.
> 
> So, I replaced my JDBCRealm definition to the DataSourceRealm
> but have run into a problem.  I have the following in the
> CATALINA_HOME/webapps/cml.xml file:
> 
>docBase="/usr/local/jakarta/cml"
> debug="99"
>privileged="false">
> 
>  type="javax.sql.DataSource"/>
> 
> factory
>   
>
org.apache.commons.dbcp.BasicDataSourceFactory
> driverClassName
>   
> oracle.jdbc.OracleDriver
> url
>   
>
jdbc:oracle:thin:@200.65.6.188:1521:tiggs9i
> username
>cml
> password
>cml
> maxActive
>20
> maxIdle
>10
> maxWait
>-1
> validationQuery
>select sysdate from
> dual
> 
> 
>  debug="99"
>dataSourceName="java:comp/env/jdbc/Db"
> userTable="mmis_users"
>   userNameCol="user_name"
>   userCredCol="user_pass"
> userRoleTable="mmis_user_roles"
>   roleNameCol="role_name"
>digest="MD5"
> />
> 
> 
> 
> 
> 
> I know the jdbc/Db JNDI resource is configured properly because
> I'm able to access the datasource from the application using:
> 
> Context initCtx = new InitialContext();
> Context envCtx = (Context)initCtx.lookup("java:comp/env");
> DataSource ds = (DataSource)envCtx.lookup("jdbc/Db");
> return ds.getConnection();
> 
> but when Tomcat starts up I get the following error:
> 
> 2002-12-19 14:55:01 DataSourceRealm[/cml]: Exception performing
> authentication
> javax.naming.NameNotFoundException: Name java:comp is not bound in
> this Context
> at
> org.apache.naming.NamingContext.lookup(NamingContext.java:811)
> at
> org.apache.naming.NamingContext.lookup(NamingContext.java:194)
> at
>
org.apache.catalina.realm.DataSourceRealm.open(DataSourceRealm.java:463)
> at
>
org.apache.catalina.realm.DataSourceRealm.start(DataSourceRealm.java:582)
> at
>
org.apache.catalina.core.StandardContext.start(StandardContext.java:3543)
> etc...
> 
> 
> I even tried using
>dataSourceName="java:/comp/env/jdbc/Db"
> in the Realm definition (note the slash after the colon as
> was shown in the Realm HOW-TO) but this gave a similar exception.
> 
> Does anyone know what name I should use for the data source?
> Thanks,
> Kevin.
> 
> 
> __
> Do you Yahoo!?
> Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
> http://mailplus.yahoo.com
> 
> --
> To unsubscribe, e-mail:  
> 
> For additional commands, e-mail:
> 
> 


__
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

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

[ANN] Security update: Apache Tomcat 4.1.18 released

[Remy Maucherat]

Tomcat 4.1.18 has just been released, and includes a fix for an object 
recylcing bug which could be exploited by a denial of service attack. 
The bug was introduced in Tomcat 4.1.16 Beta, and is still present in 
Tomcat 4.1.17 Stable. The release also includes a fix for SSL handling 
in the JK connector.

Binary Downloads:
http://jakarta.apache.org/site/binindex.cgi

Source downloads:
http://jakarta.apache.org/site/sourceindex.cgi

Remy


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