Question about ByteChunk.substract implementation

Why does the implementation of the substract() methods of org.apache.tomcat.util.buf.ByteChunk.java (http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/buf/ByteChunk.java?rev=1.24view=markup) assume that in.realReadBytes will manipulate the start and end

qn about ResponseFacade.flushBuffer()

In http://cvs.apache.org/viewcvs.cgi/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/connector/ResponseFacade.java?annotate=1.3 What was the intention of the following ? 175 if (isFinished()) 176 resp.setSuspended(true) since 137

[PATCH] TC4.0 - Intermittent IllegalArgumentException inWebappClassLoader

Attaching a patch that fixes an intermittent error (that occurs when an attempt is made to define a package that has already been defined). I noticed this when running a multi-threaded test. - Root Cause - java.lang.IllegalArgumentException: Servlet22.S05_Request at

[TC 4.0/4.1] - Recycling session objects is inherently error prone

Since the lifetime of session objects span requests and since session objects are expired asynchronously by the background thread created by the session manager, if one did recycle session objects then isn't it possible for 2 separate requests to access and possibly modify a session object

Re: $ in JSP names

Craig R. McClanahan wrote: On Mon, 15 Jul 2002, Kin-Man Chung wrote: Date: Mon, 15 Jul 2002 11:55:15 -0700 (PDT) From: Kin-Man Chung [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED], Kin-Man Chung [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: $

[PATCH] TC 4.1 - Prevent NPEs after sessions are recycled

The change made in v1.29 to o.a.c.session.StandardSession.java sets the manager of a session to null *after* the session has been recycled (another thread could pick up and start using the recycled session before manager is set to null). Even under a light session-based workload, this causes NPEs

[PATCH] TC 4.0.4 - Disallow setLocale() on an included response

simple patch to ignore response header changes (by included servlets) via setLocale. -Arvind Index: ApplicationHttpResponse.java === RCS file:

[PATCH] [TC 4.0.4] Missing charset= in JSP Content-Type headers

JSPs don't seem to be setting the Content-Type header correctly. Have attached a patch that adds the missing 'charset=' string to the content-type value. thx, arvind GET /foo.jsp HTTP/1.0 HTTP/1.1 200 OK Content-Type: text/html;ISO-8859-1 Connection: close Date: Mon, 24 Jun 2002 02:07:50 GMT

ArrayIndexOutOfBoundsException in WebappClassLoader

I'm unable to reproduce this easily but I was running some tests (using a multithreaded load generator) on a 4 cpu machine and encountered a couple of ArrayIndexOutOfBoundsException @ lines 1747 and 1754 in o.a.c.loaders.WebappClassLoader.java. 737// Register the full path for

Re: Qn about a performance bottleneck in InvokerServlet

Craig R. McClanahan wrote: The purpose is a performance optimization -- on subsequent requests to /servlet/foo, the container should find an existing mapping for the servlet, so it will get called directly instead of going through the invoker. context.addServletMapping is called on

Re: embedded tomcat and JspServlet

Richard Unger wrote: jsp: init Internal Error: File /WEB-INF/web.xml not found. I believe this particular error message is generated (by o.a.j.compiler.TldLocationsCache.processWebDotXml) when initializing the default context (which doesn't have a WEB-INF/web.xml). I don't think this

TC4: qn about requestdispatcher forwards and input streams

I'd appreciate it if someone can clarify whether the following is a bug in TC4 or not. I have a servlet whose doPost() implementation simply gets hold of a requestdispatcher and invokes forward() on it. The form that is posted contains a couple of name/value parameters. The forwarded-to servlet

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

Hi Remy, I think the performance related change that you made to StandardPipeline can be improved upon in that it can avoid using a HashMap to store/retrieve the pipeline stage and instead simply store/retrieve it from an integer variable in the RequestBase class. Since this codepath

[PATCH] TC4.0 - Propagate Embedded's debug level to loaders it creates

Simple patch to o.a.c.startup.Embedded.java to propagate its debug level to Loaders that it creates. Arvind Index: Embedded.java === RCS file:

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

Christopher St. John wrote: The obvious implementation is to have have ValveContext hold the index. That's how I assumed it worked the first time I saw the Pipeline, Valve and ValveContext classes. I was suprised to see a ThreadLocal. Using ValveContext has the appropriate threading

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

Christopher St. John wrote: No, definitely not. Here's how MinTC (MinimalTomcat) does it (this is alpha code, and I've deleted some of the methods to keep the size down): Thanks..I like MinTC's solution. Arvind -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional

[PATCH] - Make default deployment descriptor file location configurable

This is a patch for RFE# 7564. It allows one to specify/override the location of the default deployment descriptor. Currently, this is hardcoded to 'conf/web.xml' in o.a.c.startup.Constants.java Products that embed the Catalina engine (using Embedded's API) may have a different directory