Re: Tomcat 4.0 RPMs?

[Christopher Cain]

Hi Vic. We're currently trying to sort out the best way of packaging a 4.0 RPM. 
TC4 has quite a few external jar dependencies ... some optional, some 
mandatory. We're kind of between a rock and a hard place with both a few of the 
RPM packaging policies as well as some jar redistribution issues.

The prevailing theory seems to be that the RPM should include just the absolute 
minimum number of jars required to successfully run a minimal build of Tomcat. 
The rest will still have to be downloaded separately (although we might make 
a "tomcat-supplimental.tar.gz" available containing all of the optional jars 
that we can safely redistribute). The problem is that RPM packaging policies 
frown upon including external binaries (in our case non-TC jars) in the RPM, 
and beyond that, doing so is not really good form anyway.

In other words, the RPM install isn't going to be as painless as we would like. 
If you are comfortable with building from source, and if you need anything 
other than a minimal build, the source might be your best bet. (You could also 
just download the binaries, of course.) I'm not even sure that an exact 
approach for TC4 RPMs has been decided upon, and I'm also not sure what Henri's
(our RPM packager) timeframe is, so AFAIK the date on having an RPM is still up 
in the air.

Quoting Vic Ricker <[EMAIL PROTECTED]>:

> Hi.
> 
> Will RPMs for Tomcat 4.0 be released on the web site any time soon?
> 
> I have no problem installing from the tar but I'd prefer the RPM since
> that's
> how I installed the previous version.
> 
> Thanks,
> -Vic

- Christopher

/**
 * Pleurez, pleurez, mes yeux, et fondez vous en eau!
 * La moitié de ma vie a mis l'autre au tombeau.
 *---Corneille
 */

RE: %=x% expression syntax bug in XML jsp?

[Uther, James]

Ok. Thanks for the reply.

I can see the arguments on both sides. It's a pitty my side lost ;)

james

>-Original Message-
>From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, September 26, 2001 8:59 PM
>To: [EMAIL PROTECTED]
>Subject: Re: %=x% expression syntax bug in XML jsp?
>
>On Wed, 26 Sep 2001, Mark Abbott wrote:
>
>> Date: Wed, 26 Sep 2001 10:43:51 -0700
>> From: Mark Abbott <[EMAIL PROTECTED]>
>> Reply-To: [EMAIL PROTECTED]
>> To: [EMAIL PROTECTED]
>> Subject: Re: %=x% expression syntax bug in XML jsp?
>>
>> Hi Craig -
>>
>> I'm curious whether the expert group has discussed what
>> might be done in the future about this unfortunate
>> aspect of JSP. In what I would think would be a
>> really common case in the future, where one wants to
>> design an app using clean, readable, and purely XML
>> templates (perhaps XHTML for example), but editing by
>> hand rather than with some JSP savvy tool, the choices
>> are:
>>
>> > * Create a custom tag  which just dumps out the
>> >   corresponding  tag
>>
>> Wrapping all the tags in every markup of interest is impractical
>>
>> > * Write the XML syntax in the way that the JSP compiler expects:
>> >
>> >xpos
>> >

Share sessions in JSP and Servlets

[Stefan Berg]

Hi, 

I have just set up my first Tomcat installation.

Under webapps, I have defined a context "mycontext". Within this there is a
dir for my JSP's called "jsp". Like this:

/mycontext/jsp/mypage.jsp 

>From the JSP page, I post a form to my servlet "myservlet" placed in a
WEB-INF/classes dir. Like this:

/mycontext/WEB-INF/classes/myservlet

And here is my problem: When accessing the JSP page for the first time, a
brand new session is initialized (cookie based). But when posting to the
Servlet it starts yet another new session! WHY is this? I thought the
session would be shared across JSP and Servlets within the same context.

I have tried this with both Tomcat 3.1.1 and Tomcat 3.2.3 with the same
result. The JSP and Servlets are running under default configuration for the
/webapps directory. 

Please help me out here. 

/Stefan

Re: Watchdog-4.0 PB

[Forrest R. Girouard]

jean-frederic clere wrote:
> 
> Hi,
> 
> I have a problem running watchdog:
> 
> +++
> servlet:
> 
> execute:
>  [java] Buildfile: conf/servlet-gtest.xml
>  [java]
>  [java] gtestservlet-test:
>  [java]
>  [java] Total time: 1 second
>  [java] [gtest] Error setting project in class
> org.apache.tomcat.task.GTest
>  [java]
>  [java] BUILD FAILED
>  [java]
>  [java] /home/jakarta/jakarta-watchdog-4.0/dist/conf/servlet-gtest.xml:22:
> java.lang.NoSuchMethodException
>  [java] Java Result: 1
> 
> BUILD SUCCESSFUL
> 
> Total time: 2 seconds
> +++
> I am using ant-1.4.
> 
> Any hints?

This problem went away for me when I rebuilt watchdog-4.0 from
the sources so I suspect a problem in the environment used to 
create the nightly builds.

Cheers,
Forrest
-- 
Forrest Girouard @ Openwave Systems Inc.
phone: +1-650-480-4184
mailto:[EMAIL PROTECTED]
http://www.openwave.com

Re: [VOTE] Kin-Man Chung and William Barker for Tomcat CommitterStatus

[cmanolache]

On Wed, 26 Sep 2001, Craig R. McClanahan wrote:

> I'd like to follow up on Nacho's (good) suggestion that we add William
> Barker and Kin-Man Chung as committers on Tomcat.  They've both been
> providing invaluable assistance and patches.
>
> I'm +1 on them.

I already sent a +1, but since there are 2 new commiters I'll add a
seconde one :-)

+1

Costin

Re: Watchdog-4.0 PB

[cmanolache]

On Wed, 26 Sep 2001, jean-frederic clere wrote:

>  [java] /home/jakarta/jakarta-watchdog-4.0/dist/conf/servlet-gtest.xml:22:
> java.lang.NoSuchMethodException
>  [java] Java Result: 1
>
> BUILD SUCCESSFUL
>
> Total time: 2 seconds
> +++
> I am using ant-1.4.

Yes, something changed in ant-1.4 and now all "TaskAdapter"-based tasks
are failing. I'm looking for a workaround ( if any ).

TaskAdapter was used to plug in arbitrary java classes ( that do not
extend Task but follow the ant patterns - i.e. bean setters and
execute()). However something is now broken. A simple fix is to
extend Task ( and add a dependency on the current ant ).



Costin

RE: [PATCH] Potential buffer overflow attach in mod_jk

[Keith Wannamaker]

I was afraid of that... guess os memory allocation it is, then.

Keith

| It looked to me like
| uw_map->p wasn't suitable for per-request allocations (i.e. it would just
| eat memory until the server was re-started), and since this is in common, I
| couldn't use ap_strdup since that breaks all non-Apache servers.

Re: Tomcat next

[Pier Fumagalli]

"Remy Maucherat" <[EMAIL PROTECTED]> wrote:

> Actually, I would be more in favor of releasing a 4.1 before that, focusing
> mostly on small refactorings of the core (like the error report refactoring
> I just did) and optimizations.
> 
> More specifically, that would include:
> - the Service stuff (if done)
> - better mod_webapp

Replying since those two are on my plate... I believe those can go into a
4.0.x release too... I don't think we need to "schedule" them for 4.1, but
before than that...

Pier

Re: Tomcat next

[Pier Fumagalli]

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

> It is not yet decided how we'll release the new modules, but the main
> idea is to keep the 'base' version as small and clean as possible, and
> all features to be 'add-ons', outside of the base distribution, and have
> only bug fixes in 3.3.x-releases.

(Dumb question)... What new modules are planned for 3.3? I seriously don't
know... :)

Pier

Re: Tomcat next

[Pier Fumagalli]

"Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:

> * Implementing a nice administration/configuration interface (as a
> web app), talking to server components through a JMX interface
> (so that Tomcat can be managed by any JMX compliant tool).  Some
> time ago I published some functional requirements for this (in the
> Tomcat documentation, go to "Functional Specs" under "Catalina")
> but it hasn't received much in the way of comment yet.

I like the JMX part of this one :)

Pier

Re: [VOTE] Kin-Man Chung and William Barker for Tomcat Committer Status

[Amy Roh]

+1

Amy

"Craig R. McClanahan" wrote:

> I'd like to follow up on Nacho's (good) suggestion that we add William
> Barker and Kin-Man Chung as committers on Tomcat.  They've both been
> providing invaluable assistance and patches.
>
> I'm +1 on them.
>
> Craig

Re: [VOTE] Kin-Man Chung and William Barker for Tomcat Committer Status

[Remy Maucherat]

> I'd like to follow up on Nacho's (good) suggestion that we add William
> Barker and Kin-Man Chung as committers on Tomcat.  They've both been
> providing invaluable assistance and patches.
> 
> I'm +1 on them.

+1

Remy

[VOTE] Kin-Man Chung and William Barker for Tomcat Committer Status

[Craig R. McClanahan]

I'd like to follow up on Nacho's (good) suggestion that we add William
Barker and Kin-Man Chung as committers on Tomcat.  They've both been
providing invaluable assistance and patches.

I'm +1 on them.

Craig

Re: Tomcat next

[Punky Tse]

> AFAIK there is no plan for a 3.4 release after 3.3 - that doesn't mean 3.x
> will be obsolete, just that the core is now stable and unlikely to
> change, except bugfixes.
>
> Having a stable core is essential for module development and for enhancing
> the current set of modules. Even if there are many improvements we can add
> to 3.3, I believe the benefit of keeping 3.3 stable is far bigger.
>
> It is not yet decided how we'll release the new modules, but the main
> idea is to keep the 'base' version as small and clean as possible, and
> all features to be 'add-ons', outside of the base distribution, and have
> only bug fixes in 3.3.x-releases.
>
> Costin
>
If the added modules and enhancement contribute significant additional
features to the existing 3.3,  I think it is better to call it 3.4 instead
if calling it 3.3.x.

Of course, before we officially call it 3.4, somebody must write a release
proposal first and having the proposal voted in the list. :-)

Punky

Re: [PATCH] Potential buffer overflow attach in mod_jk

[Bill Barker]

Here's with jk_pool_strdup (against RC1, not HEAD).  It looked to me like
uw_map->p wasn't suitable for per-request allocations (i.e. it would just
eat memory until the server was re-started), and since this is in common, I
couldn't use ap_strdup since that breaks all non-Apache servers.
- Original Message -
From: "Keith Wannamaker" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 26, 2001 5:25 PM
Subject: RE: [PATCH] Potential buffer overflow attach in mod_jk


> Hi Bill, would you resubmit a patch that makes use of either
> Apache or jk's pools?  ie ap_strdup or jk_pool_strdup.
> That would be a better way to solve the problem.  Apache
> modules should and do avoid os memory-allocation routines
> like the plague.  I think uw_map->p would be ok, but please
> do some testing.
>
> Thanks,
> Keith
>
> | -Original Message-
> | From: Bill Barker [mailto:[EMAIL PROTECTED]]
> | Sent: Wednesday, September 26, 2001 2:37 PM
> | To: [EMAIL PROTECTED]
> | Subject: Fw: [PATCH] Potential buffer overflow attach in mod_jk
> |
> |
> | Urm, let's try that again with a patch that at least compiles..
>
>


**

This message is intended only for the use of the person(s) listed above 
as the intended recipient(s), and may contain information that is 
PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, 
you may not read, copy, or distribute this message or any attachment.  
If you received this communication in error, please notify us immediately 
by e-mail and then delete all copies of this message and any attachments.


In addition you should be aware that ordinary (unencrypted) e-mail sent 
through the Internet is not secure. Do not send confidential or sensitive 
information, such as social security numbers, account numbers, personal 
identification numbers and passwords, to us via ordinary (unencrypted) 
e-mail. 
 jk_uri_worker_map.diff

DO NOT REPLY [Bug 3823] - sendError and setStatus clear headers already set

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

sendError and setStatus clear headers already set

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2001-09-26 18:07 ---
Fixed in the CVS HEAD branch.

DO NOT REPLY [Bug 3591] - HttpServletResponse.sendError() and sendRedirect() should commit the response

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

HttpServletResponse.sendError() and sendRedirect() should commit the response

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2001-09-26 18:03 ---
Fixed in the HEAD branch.

DO NOT REPLY [Bug 3591] - HttpServletResponse.sendError() and sendRedirect() should commit the response

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

HttpServletResponse.sendError() and sendRedirect() should commit the response

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|LATER   |



--- Additional Comments From [EMAIL PROTECTED]  2001-09-26 18:02 ---
Reopen before marking as fixed.

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves ErrorReportValve.java

[remm]

remm01/09/26 18:01:10

  Modified:catalina/src/share/org/apache/catalina/valves
ErrorReportValve.java
  Log:
  - The error report valve should use the internal response object to ignore the commit
state of the facade.
  
  Revision  ChangesPath
  1.3   +10 -11
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java
  
  Index: ErrorReportValve.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- ErrorReportValve.java 2001/09/26 17:44:51 1.2
  +++ ErrorReportValve.java 2001/09/27 01:01:10 1.3
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java,v
 1.2 2001/09/26 17:44:51 remm Exp $
  - * $Revision: 1.2 $
  - * $Date: 2001/09/26 17:44:51 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java,v
 1.3 2001/09/27 01:01:10 remm Exp $
  + * $Revision: 1.3 $
  + * $Date: 2001/09/27 01:01:10 $
*
* 
*
  @@ -104,7 +104,7 @@
* @author Craig R. McClanahan
* @author mailto:[EMAIL PROTECTED]";>Nicola Ken Barozzi Aisa
* @author mailto:[EMAIL PROTECTED]";>Stefano Mazzocchi
  - * @version $Revision: 1.2 $ $Date: 2001/09/26 17:44:51 $
  + * @version $Revision: 1.3 $ $Date: 2001/09/27 01:01:10 $
*/
   
   public class ErrorReportValve
  @@ -169,11 +169,11 @@
   // Perform the request
   context.invokeNext(request, response);
   
  -ServletResponse sresp = response.getResponse();
  +ServletResponse sresp = (ServletResponse) response;
   if (sresp.isCommitted())
   return;
   
  -ServletRequest sreq = request.getRequest();
  +ServletRequest sreq = (ServletRequest) request;
   Throwable throwable = 
   (Throwable) sreq.getAttribute(Globals.EXCEPTION_ATTR);
   
  @@ -184,12 +184,12 @@
   
   // Reset the response (if possible)
   try {
  -response.getResponse().reset();
  +sresp.reset();
   } catch (IllegalStateException e) {
   ;
   }
   
  -ServletResponse sresponse = response.getResponse();
  +ServletResponse sresponse = (ServletResponse) response;
   if (sresponse instanceof HttpServletResponse)
   ((HttpServletResponse) sresponse).sendError
   (HttpServletResponse.SC_INTERNAL_SERVER_ERROR);
  @@ -237,10 +237,9 @@
   if (!(response instanceof HttpResponse))
   return;
   HttpResponse hresponse = (HttpResponse) response;
  -if (!(response.getResponse() instanceof HttpServletResponse))
  +if (!(response instanceof HttpServletResponse))
   return;
  -HttpServletResponse hres =
  -(HttpServletResponse) response.getResponse();
  +HttpServletResponse hres = (HttpServletResponse) response;
   int statusCode = hresponse.getStatus();
   String message = RequestUtil.filter(hresponse.getMessage());
   if (message == null)
  
  
  

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves ErrorDispatcherValve.java

[remm]

remm01/09/26 18:00:05

  Modified:catalina/src/share/org/apache/catalina/valves
ErrorDispatcherValve.java
  Log:
  - The error dispatcher will recycle the facades before forwarding to an error
page (of course, if the underlying response has been committed, it will still 
fail),
so that you can use an error page along with sendError.
  
  Revision  ChangesPath
  1.3   +6 -4  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorDispatcherValve.java
  
  Index: ErrorDispatcherValve.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorDispatcherValve.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- ErrorDispatcherValve.java 2001/09/26 17:45:52 1.2
  +++ ErrorDispatcherValve.java 2001/09/27 01:00:05 1.3
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorDispatcherValve.java,v
 1.2 2001/09/26 17:45:52 remm Exp $
  - * $Revision: 1.2 $
  - * $Date: 2001/09/26 17:45:52 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorDispatcherValve.java,v
 1.3 2001/09/27 01:00:05 remm Exp $
  + * $Revision: 1.3 $
  + * $Date: 2001/09/27 01:00:05 $
*
* 
*
  @@ -104,7 +104,7 @@
*
* @author Remy Maucherat
* @author Craig R. McClanahan
  - * @version $Revision: 1.2 $ $Date: 2001/09/26 17:45:52 $
  + * @version $Revision: 1.3 $ $Date: 2001/09/27 01:00:05 $
*/
   
   public class ErrorDispatcherValve
  @@ -224,6 +224,7 @@
   }
   
   if (errorPage != null) {
  +response.recycleFacade();
   ServletRequest sreq = request.getRequest();
   ServletResponse sresp = response.getResponse();
   sreq.setAttribute(Globals.ERROR_MESSAGE_ATTR,
  @@ -276,6 +277,7 @@
   Context context = request.getContext();
   ErrorPage errorPage = context.findErrorPage(statusCode);
   if (errorPage != null) {
  +response.recycleFacade();
   ServletRequest sreq = request.getRequest();
   ServletResponse sresp = response.getResponse();
   sreq.setAttribute(Globals.STATUS_CODE_ATTR,
  
  
  

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector HttpResponseBase.java ResponseBase.java

[remm]

remm01/09/26 17:58:38

  Modified:catalina/src/share/org/apache/catalina/connector
HttpResponseBase.java ResponseBase.java
  Log:
  - Recycle the facades between each request.
  
  Revision  ChangesPath
  1.38  +12 -4 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java
  
  Index: HttpResponseBase.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java,v
  retrieving revision 1.37
  retrieving revision 1.38
  diff -u -r1.37 -r1.38
  --- HttpResponseBase.java 2001/08/24 23:06:08 1.37
  +++ HttpResponseBase.java 2001/09/27 00:58:38 1.38
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java,v
 1.37 2001/08/24 23:06:08 craigmcc Exp $
  - * $Revision: 1.37 $
  - * $Date: 2001/08/24 23:06:08 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseBase.java,v
 1.38 2001/09/27 00:58:38 remm Exp $
  + * $Revision: 1.38 $
  + * $Date: 2001/09/27 00:58:38 $
*
* 
*
  @@ -101,7 +101,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.37 $ $Date: 2001/08/24 23:06:08 $
  + * @version $Revision: 1.38 $ $Date: 2001/09/27 00:58:38 $
*/
   
   public class HttpResponseBase
  @@ -319,6 +319,14 @@
   
   return (this.status);
   
  +}
  +
  +
  +/**
  + * Recycle the facade object.
  + */
  +public void recycleFacade() {
  +facade = new HttpResponseFacade(this);
   }
   
   
  
  
  
  1.17  +13 -4 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/ResponseBase.java
  
  Index: ResponseBase.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/ResponseBase.java,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- ResponseBase.java 2001/08/02 01:43:58 1.16
  +++ ResponseBase.java 2001/09/27 00:58:38 1.17
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/ResponseBase.java,v
 1.16 2001/08/02 01:43:58 remm Exp $
  - * $Revision: 1.16 $
  - * $Date: 2001/08/02 01:43:58 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/ResponseBase.java,v
 1.17 2001/09/27 00:58:38 remm Exp $
  + * $Revision: 1.17 $
  + * $Date: 2001/09/27 00:58:38 $
*
* 
*
  @@ -88,7 +88,7 @@
* the connector-specific methods need to be implemented.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.16 $ $Date: 2001/08/02 01:43:58 $
  + * @version $Revision: 1.17 $ $Date: 2001/09/27 00:58:38 $
*/
   
   public abstract class ResponseBase
  @@ -496,6 +496,14 @@
   
   
   /**
  + * Recycle the facade object.
  + */
  +public void recycleFacade() {
  +facade = new ResponseFacade(this);
  +}
  +
  +
  +/**
* Release all object references, and initialize instance variables, in
* preparation for reuse of this object.
*/
  @@ -517,6 +525,7 @@
   stream = null;
   writer = null;
   error = false;
  +recycleFacade();
   
   }
   
  
  
  

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector HttpResponseFacade.java ResponseFacade.java

[remm]

remm01/09/26 17:58:14

  Modified:catalina/src/share/org/apache/catalina/connector
HttpResponseFacade.java ResponseFacade.java
  Log:
  - The response facade now have its own committed flag, so that the application
layer can be committed (during a sendRedirect or sendError) while not committing
the underlying response object.
  
  Revision  ChangesPath
  1.3   +70 -4 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseFacade.java
  
  Index: HttpResponseFacade.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseFacade.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- HttpResponseFacade.java   2001/07/22 20:25:06 1.2
  +++ HttpResponseFacade.java   2001/09/27 00:58:14 1.3
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseFacade.java,v
 1.2 2001/07/22 20:25:06 pier Exp $
  - * $Revision: 1.2 $
  - * $Date: 2001/07/22 20:25:06 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/HttpResponseFacade.java,v
 1.3 2001/09/27 00:58:14 remm Exp $
  + * $Revision: 1.3 $
  + * $Date: 2001/09/27 00:58:14 $
*
* 
*
  @@ -79,7 +79,7 @@
*
* @author Remy Maucherat
* @author Craig R. McClanahan
  - * @version $Revision: 1.2 $ $Date: 2001/07/22 20:25:06 $
  + * @version $Revision: 1.3 $ $Date: 2001/09/27 00:58:14 $
*/
   
   public final class HttpResponseFacade
  @@ -104,7 +104,12 @@
   
   
   public void addCookie(Cookie cookie) {
  +
  +if (isCommitted())
  +return;
  +
   ((HttpServletResponse) response).addCookie(cookie);
  +
   }
   
   
  @@ -135,59 +140,120 @@
   
   public void sendError(int sc, String msg)
   throws IOException {
  +
  +if (isCommitted())
  +return;
  +
  +committed = true;
  +
   ((HttpServletResponse) response).sendError(sc, msg);
  +
   }
   
   
   public void sendError(int sc)
   throws IOException {
  +
  +if (isCommitted())
  +return;
  +
  +committed = true;
  +
   ((HttpServletResponse) response).sendError(sc);
  +
   }
   
   
   public void sendRedirect(String location)
   throws IOException {
  +
  +if (isCommitted())
  +return;
  +
  +committed = true;
  +
   ((HttpServletResponse) response).sendRedirect(location);
  +
   }
   
   
   public void setDateHeader(String name, long date) {
  +
  +if (isCommitted())
  +return;
  +
   ((HttpServletResponse) response).setDateHeader(name, date);
  +
   }
   
   
   public void addDateHeader(String name, long date) {
  +
  +if (isCommitted())
  +return;
  +
   ((HttpServletResponse) response).addDateHeader(name, date);
  +
   }
   
   
   public void setHeader(String name, String value) {
  +
  +if (isCommitted())
  +return;
  +
   ((HttpServletResponse) response).setHeader(name, value);
  +
   }
   
   
   public void addHeader(String name, String value) {
  +
  +if (isCommitted())
  +return;
  +
   ((HttpServletResponse) response).addHeader(name, value);
  +
   }
   
   
   public void setIntHeader(String name, int value) {
  +
  +if (isCommitted())
  +return;
  +
   ((HttpServletResponse) response).setIntHeader(name, value);
  +
   }
   
   
   public void addIntHeader(String name, int value) {
  +
  +if (isCommitted())
  +return;
  +
   ((HttpServletResponse) response).addIntHeader(name, value);
  +
   }
   
   
   public void setStatus(int sc) {
  +
  +if (isCommitted())
  +return;
  +
   ((HttpServletResponse) response).setStatus(sc);
  +
   }
   
   
   public void setStatus(int sc, String sm) {
  +
  +if (isCommitted())
  +return;
  +
   ((HttpServletResponse) response).setStatus(sc, sm);
  +
   }
   
   
  
  
  
  1.3   +48 -5 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/ResponseFacade.java
  
  Index: ResponseFacade.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/ResponseFacade.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- ResponseFacade.java   2001/07/22 20:25:06 1.2
  +++ ResponseFacade.java   2001/09/27 00:58:14 1.3
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catali

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

[remm]

remm01/09/26 17:55:09

  Modified:catalina/src/share/org/apache/catalina Response.java
  Log:
  - Add new recycle facade method, which is used by the core to recycle
(uncommit) the response facade object.
  
  Revision  ChangesPath
  1.5   +10 -4 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Response.java
  
  Index: Response.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Response.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- Response.java 2001/07/22 20:13:30 1.4
  +++ Response.java 2001/09/27 00:55:09 1.5
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Response.java,v 
1.4 2001/07/22 20:13:30 pier Exp $
  - * $Revision: 1.4 $
  - * $Date: 2001/07/22 20:13:30 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Response.java,v 
1.5 2001/09/27 00:55:09 remm Exp $
  + * $Revision: 1.5 $
  + * $Date: 2001/09/27 00:55:09 $
*
* 
*
  @@ -79,7 +79,7 @@
* based on the processing of a corresponding Request.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.4 $ $Date: 2001/07/22 20:13:30 $
  + * @version $Revision: 1.5 $ $Date: 2001/09/27 00:55:09 $
*/
   
   public interface Response {
  @@ -245,6 +245,12 @@
* preparation for reuse of this object.
*/
   public void recycle();
  +
  +
  +/**
  + * Recycle facade object.
  + */
  +public void recycleFacade();
   
   
   /**
  
  
  

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

[remm]

remm01/09/26 17:54:11

  Modified:catalina/src/share/org/apache/catalina Globals.java
  Log:
  - Update version number.
  
  Revision  ChangesPath
  1.40  +5 -5  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Globals.java
  
  Index: Globals.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Globals.java,v
  retrieving revision 1.39
  retrieving revision 1.40
  diff -u -r1.39 -r1.40
  --- Globals.java  2001/09/18 01:12:53 1.39
  +++ Globals.java  2001/09/27 00:54:11 1.40
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Globals.java,v 
1.39 2001/09/18 01:12:53 craigmcc Exp $
  - * $Revision: 1.39 $
  - * $Date: 2001/09/18 01:12:53 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/Globals.java,v 
1.40 2001/09/27 00:54:11 remm Exp $
  + * $Revision: 1.40 $
  + * $Date: 2001/09/27 00:54:11 $
*
* 
*
  @@ -69,7 +69,7 @@
* Global constants that are applicable to multiple packages within Catalina.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.39 $ $Date: 2001/09/18 01:12:53 $
  + * @version $Revision: 1.40 $ $Date: 2001/09/27 00:54:11 $
*/
   
   public final class Globals {
  @@ -219,7 +219,7 @@
   /**
* The descriptive information about this server and version.
*/
  -public static final String SERVER_INFO = "Apache Tomcat/4.0";
  +public static final String SERVER_INFO = "Apache Tomcat/4.1-dev";
   
   
   /**
  
  
  

Re: Tomcat next

[Bojan Smojver]

[EMAIL PROTECTED] wrote:

> Having a stable core is essential for module development and for enhancing
> the current set of modules. Even if there are many improvements we can add
> to 3.3, I believe the benefit of keeping 3.3 stable is far bigger.

Just to confirm this point, I've been running 3.3 CVS with mod_jk in my
production environment for quite some time now. If we care for it
properly, it might become one of those 'golden' releases ;-)

Bojan

DO NOT REPLY [Bug 3847] New: - Apache authorization headers not passed through to servlet

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

Apache authorization headers not passed through to servlet

   Summary: Apache authorization headers not passed through to
servlet
   Product: Tomcat 3
   Version: 3.3 Release Candidate 1
  Platform: Other
OS/Version: Windows NT/2K
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Unknown
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have a web app where access is managed by Apache using mod_ntlm. The servlet 
uses the req.getRemoteUser() method to determine who is logged in. This has 
worked fine with ApacheJServ and all TC3.3s to now (using ajp13 only - ajp12 
also had this problem)
When I installed TC3.3rc1 this broke. Apache is still authenticating the user 
and the authorization header is being passed through (useless since it is 
encrypted) but the req.getRemoteUser() method returns nothing.

FYI the spec says getRemoteUser is to return the user name "that the client 
authenticated with". It doesn't say that "the client authenticated with the 
servlet container with". By way of clarifiction the servlet 2.3 api docs 
say: "same as the value of the cgi variable REMOTE_USER"

Re: Hard coding HTML within Catalina...

[Remy Maucherat]

> on 9/26/01 10:44 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>
> > +sb.append("");
> > +sb.append(Globals.SERVER_INFO).append(" - ");
> > +sb.append(sm.getString("errorReportValve.errorReport"));
> > +sb.append("");
> > +sb.append("

DO NOT REPLY [Bug 3727] - Switched included request parameters

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

Switched included request parameters

[EMAIL PROTECTED] changed:

   What|Removed |Added

 AssignedTo|tomcat- |[EMAIL PROTECTED]
   |[EMAIL PROTECTED]  |
 Status|ASSIGNED|NEW



--- Additional Comments From [EMAIL PROTECTED]  2001-09-26 17:29 ---
I tried adding the "/foobar/*" dummy mapping and behavior did not change as it
shouldn't.  If you are still able to get altered behavior when adding a dummy
mapping, please specify the dummy mapping and the URL you are using to invoke
it. I'm assuming the "/*" mapping is still present along with the dummy mapping.

As Costin is indicating by marking 3760 as a duplicate, perhaps it was the
restarting of Tomcat, not the dummy mapping itself, that is responsible for
the changing behavior in your test case.  I don't see the changing behavior,
but I may not be duplicating your test case exactly. As a result, we would need
to know your test case in exact detail.  Thanks.

DO NOT REPLY [Bug 3727] - Switched included request parameters

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

Switched included request parameters

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED



--- Additional Comments From [EMAIL PROTECTED]  2001-09-26 17:28 ---
My tests confirm what Bill Barker has said. If you have a mapping for "/*",
requests that don't otherwise match some other mapping will have the
servlet_path empty and path_info non-empty.  See section 4.4 in the Servlet 2.3
spec (this behavior didn't change from 2.2 and the Servlet 2.3 spec has some
typo's fixed that are present in the Servlet 2.2 spec). If you take either
the "/lawn/*" or "/garden/*" examples and replace the "/lawn" or "/garden"
with "", you will see that the servlet_path becomes blank.  Thus your statement
in the last reopen is incorrect.  The servlet_path and path_info are not 
switched.

More to come...

Hard coding HTML within Catalina...

[Jon Stevens]

on 9/26/01 10:44 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:

> +sb.append("");
> +sb.append(Globals.SERVER_INFO).append(" - ");
> +sb.append(sm.getString("errorReportValve.errorReport"));
> +sb.append("");
> +sb.append("

RE: TC 3.3: getRequestURI()

[Keith Wannamaker]

I'm +1 for this.  It is the best solution.

Keith

| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
| 
| 3. Revert to the use of uri ( i.e. the decoded uri ), and
| change the getRequestURI ( the facade ) to generated a
| 'canonical' encoding.
| Problems:

Re: TC 3.3: getRequestURI()

[Bojan Smojver]

[EMAIL PROTECTED] wrote:
> 
> On Wed, 26 Sep 2001, Keith Wannamaker wrote:
> 
> > 0x3b = ';'.  Ignacio is right, SessionID doesn't remove the id
> > because it is not expecting ; to be encoded.  So now it shows
> > up in the URI and has the side effect of breaking sessions
> > that depend on url rewriting.  But, the spec does say the URL
> > should be encoded, so I'd rather fix SessionID with this patch.
> >
> > However, are there other places where TC is manipulating the
> > URL and assuming it is unencoded?
> 
> I'm not sure this is the right solution ( but it's a good patch:-).
> 
> The 'original' URI included a ';' - which is a valid
> character used in the right way. It shouldn't be encoded by
> mod_jk - the whole reason for encoding is to try to reproduce
> the original URI or something equivalent.
> 
> The only use for %3B is to allow the user to specify
> some path-info ( or other path components ) that include the
> ';' character. In a URI ';' is used to pass additional
> informations about the path ( and it seems it can be attached
> to any path component ) - I never saw any server to use
> this feature.
> 
> Well, we have a big nightmare here - and probably the only
> way out is to find some consistent ( and implementable )
>  interpretation of the involved specs and stick with that.
> 
> The encoded URI is used only to satisfy the servlet spec -
> and re-encoding the URI is an imperfect workaround.

While risking to confuse the whole thing even more by my
misunderstanding, this is the chain of events as I understand it:

- original URI from the browser (in whichever form, out of server
control)
- decoded URI by Apache (in order to avoid security problems)
- encoded URI by mod_jk (this introduces %3b and doesn't match the
original URI)
- encoded URI goes into Tomcat

> We have few choices:
> 
> 1. revert to the use of unencoded_uri.
> Problems:
> - what about IIS and NES, where this is not available ?
> - what about integrating with apache, where the decoded
> uri is used for everything ( that means any attempt to
> authenticate using apache modules may create huge problems)
> 
> 2. Use a different encoding function, that doesn't
> encode ';'.
> Problems:
> - encoding/decoding will result in a different URI
> ( thus the servlet spec will not be happy )
> - inconsistency between tomcat standalone and tomcat+server
> 
> 3. Revert to the use of uri ( i.e. the decoded uri ), and
> change the getRequestURI ( the facade ) to generated a
> 'canonical' encoding.
> Problems:
> - again it'll not be the 'original' as required by servlet
> ( but at least this will be consistent across servers)

Although TC 3.3 is not supposed to be 2.3 spec compliant but rather 2.2
complaint (which doesn't mention this explicitly), what is considered
'original' might be the question to ask. Is it:

- as coming from the browser
- as coming into Tomcat

If the answer is 'as coming into Tomcat', then I'd say option 3 would be
a pretty safe bet.

Bojan

RE: [PATCH] Potential buffer overflow attach in mod_jk

[Keith Wannamaker]

Hi Bill, would you resubmit a patch that makes use of either
Apache or jk's pools?  ie ap_strdup or jk_pool_strdup.
That would be a better way to solve the problem.  Apache
modules should and do avoid os memory-allocation routines
like the plague.  I think uw_map->p would be ok, but please
do some testing.

Thanks,
Keith

| -Original Message-
| From: Bill Barker [mailto:[EMAIL PROTECTED]]
| Sent: Wednesday, September 26, 2001 2:37 PM
| To: [EMAIL PROTECTED]
| Subject: Fw: [PATCH] Potential buffer overflow attach in mod_jk
| 
| 
| Urm, let's try that again with a patch that at least compiles..

DO NOT REPLY [Bug 177] - Race condition during servlet initialization BugRat Report#244

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

Race condition during servlet initialization BugRat Report#244

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2001-09-26 17:16 ---
In Tomcat 3.3, ServletHandler.init() is now synchronized as recommended in
the DoubleCheckedLocking document.

Re: Tomcat next

[cmanolache]

On Wed, 26 Sep 2001, Remy Maucherat wrote:

> > What would *you* like to see happen?  (And what would *you* like to work
> > on to make it happen?  :-).

Cleaning up and modularizing the current 4.0 is probably the most
important thing to happen before any more features are added, and that's
what I would like to see happen.


> - a Coyote connector (note: Coyote is the name I've chosen to designate half
> of what is currently the TC 3.3 core)

+1 - using a common architecture for the lower-layer is great.


> - a HTTP/1.1 connector for Coyote

+0 ( I'm happy with Apache's implementation of 1.1, but would be a nice
module for 3.3 )


Costin

RE: TC 3.3: getRequestURI()

[cmanolache]

On Wed, 26 Sep 2001, Keith Wannamaker wrote:

> 0x3b = ';'.  Ignacio is right, SessionID doesn't remove the id
> because it is not expecting ; to be encoded.  So now it shows
> up in the URI and has the side effect of breaking sessions
> that depend on url rewriting.  But, the spec does say the URL
> should be encoded, so I'd rather fix SessionID with this patch.
>
> However, are there other places where TC is manipulating the
> URL and assuming it is unencoded?

I'm not sure this is the right solution ( but it's a good patch:-).

The 'original' URI included a ';' - which is a valid
character used in the right way. It shouldn't be encoded by
mod_jk - the whole reason for encoding is to try to reproduce
the original URI or something equivalent.

The only use for %3B is to allow the user to specify
some path-info ( or other path components ) that include the
';' character. In a URI ';' is used to pass additional
informations about the path ( and it seems it can be attached
to any path component ) - I never saw any server to use
this feature.

Well, we have a big nightmare here - and probably the only
way out is to find some consistent ( and implementable )
 interpretation of the involved specs and stick with that.

The encoded URI is used only to satisfy the servlet spec -
and re-encoding the URI is an imperfect workaround.

We have few choices:

1. revert to the use of unencoded_uri.
Problems:
- what about IIS and NES, where this is not available ?
- what about integrating with apache, where the decoded
uri is used for everything ( that means any attempt to
authenticate using apache modules may create huge problems)

2. Use a different encoding function, that doesn't
encode ';'.
Problems:
- encoding/decoding will result in a different URI
( thus the servlet spec will not be happy )
- inconsistency between tomcat standalone and tomcat+server

3. Revert to the use of uri ( i.e. the decoded uri ), and
change the getRequestURI ( the facade ) to generated a
'canonical' encoding.
Problems:
- again it'll not be the 'original' as required by servlet
( but at least this will be consistent across servers)


Using 'unencoded' URIs is a huge source of security problems -
the server and container _must_ use decoded URIs internally,
because otherwise security constraints would be useless.

On the other side, servlets that are doing any matching
on 'unencoded' URIs are likely to be tricked easily by
encoding tricks. So if a user is doing any security check,
he'll likely repeat all our bugs.

Using a 'canonical' encoding ( where only the chars that
are required to be encoded are encoded ) has the benefit
that gives a consistent output.

My preference would be to do (3).

Costin

Re: Tomcat next

[Remy Maucherat]

> On Wed, 26 Sep 2001, Dave Oxley wrote:
>
> > Date: Wed, 26 Sep 2001 22:59:55 +0100
> > From: Dave Oxley <[EMAIL PROTECTED]>
> > Reply-To: [EMAIL PROTECTED]
> > To: [EMAIL PROTECTED]
> > Subject: Tomcat next
> >
> > Hi all,
> >
> > A couple of questions on future Tomcat releases:
> >
> > 1. Will there be a TC3.4 release or is 3.x obsolete after 3.3?
>
> I don't know on this one.
>
> > 2. Has TC4.0 been branched (i.e. has development started on TC4.1 or are
you
> > waiting for TC4.0.1 to branch?)
>
> Yes, it has been branched ("tomcat_40_branch" is for 4.0.x).  The HEAD
> branch can be used for new development and features.
>
> > 3. Is there a list of planned features for TC4.1?
> >
>
> Hmm, the todo list doc looks like it got lost in the shuffle ...
>
> Two big areas I'd like to see focus on (and where I and some of my
> colleagues will definitely be spending some time) are:
>
> * Major improvements to the JSP page compiler to improve the
>   quality and performance of the code it generates, and to make
>   the compiler itself more maintainable.  A high level requirements
>   doc for my view of what this should include will be circulated soon.
>
> * Implementing a nice administration/configuration interface (as a
>   web app), talking to server components through a JMX interface
>   (so that Tomcat can be managed by any JMX compliant tool).  Some
>   time ago I published some functional requirements for this (in the
>   Tomcat documentation, go to "Functional Specs" under "Catalina")
>   but it hasn't received much in the way of comment yet.
>
> What would *you* like to see happen?  (And what would *you* like to work
> on to make it happen?  :-).

Actually, I would be more in favor of releasing a 4.1 before that, focusing
mostly on small refactorings of the core (like the error report refactoring
I just did) and optimizations.

More specifically, that would include:
- the Service stuff (if done)
- a Coyote connector (note: Coyote is the name I've chosen to designate half
of what is currently the TC 3.3 core)
- a HTTP/1.1 connector for Coyote
- better mod_webapp
- fixes for all the compliance issues that need some refactoring (error
report, response commit, ...)

Such a release could happen relatively soon, and would provide a better
basis for adding all the big new features mentioned above.

Of course, we could decide that all the things mentioned above are small
enough feature additions and refactorings so that they can be released as
part of the 4.0.x branch.

Note: Obviously, I'm in favor of more incremental but more frequent releases
than what has been done in the past.

Remy

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

[remm]

remm01/09/26 16:17:52

  Modified:catalina/src/share/org/apache/catalina/core Tag:
tomcat_40_branch StandardContext.java
  Log:
  - Create the Jasper loader in delegating mode (may prevent trouble).
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.78.2.2  +5 -4  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java
  
  Index: StandardContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
  retrieving revision 1.78.2.1
  retrieving revision 1.78.2.2
  diff -u -r1.78.2.1 -r1.78.2.2
  --- StandardContext.java  2001/09/21 16:28:57 1.78.2.1
  +++ StandardContext.java  2001/09/26 23:17:52 1.78.2.2
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
 1.78.2.1 2001/09/21 16:28:57 craigmcc Exp $
  - * $Revision: 1.78.2.1 $
  - * $Date: 2001/09/21 16:28:57 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
 1.78.2.2 2001/09/26 23:17:52 remm Exp $
  + * $Revision: 1.78.2.2 $
  + * $Date: 2001/09/26 23:17:52 $
*
* 
*
  @@ -142,7 +142,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.78.2.1 $ $Date: 2001/09/21 16:28:57 $
  + * @version $Revision: 1.78.2.2 $ $Date: 2001/09/26 23:17:52 $
*/
   
   public class StandardContext
  @@ -1145,6 +1145,7 @@
   
   // Set up the Jasper class loader
   StandardClassLoader newLoader = new StandardClassLoader(classLoader);
  +newLoader.setDelegate(true);
   File directory = new File(System.getProperty("catalina.home"),
 "jasper");
   if (directory.exists() && directory.canRead() &&
  
  
  

Re: TC 3.3: getRequestURI()

[Bojan Smojver]

Keith Wannamaker wrote:
> 
> 0x3b = ';'.  Ignacio is right, SessionID doesn't remove the id
> because it is not expecting ; to be encoded.  So now it shows
> up in the URI and has the side effect of breaking sessions
> that depend on url rewriting.  But, the spec does say the URL
> should be encoded, so I'd rather fix SessionID with this patch.

Without going into the spec pros and cons, I can confirm that this patch
works.

+1 (pragmatic)

Bojan

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

[remm]

remm01/09/26 16:07:54

  Modified:catalina/src/share/org/apache/catalina/core
StandardContext.java
  Log:
  - Create the Jasper loader in delegating mode (may prevent trouble).
  
  Revision  ChangesPath
  1.80  +5 -4  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java
  
  Index: StandardContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
  retrieving revision 1.79
  retrieving revision 1.80
  diff -u -r1.79 -r1.80
  --- StandardContext.java  2001/09/21 16:31:29 1.79
  +++ StandardContext.java  2001/09/26 23:07:53 1.80
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
 1.79 2001/09/21 16:31:29 craigmcc Exp $
  - * $Revision: 1.79 $
  - * $Date: 2001/09/21 16:31:29 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContext.java,v
 1.80 2001/09/26 23:07:53 remm Exp $
  + * $Revision: 1.80 $
  + * $Date: 2001/09/26 23:07:53 $
*
* 
*
  @@ -142,7 +142,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.79 $ $Date: 2001/09/21 16:31:29 $
  + * @version $Revision: 1.80 $ $Date: 2001/09/26 23:07:53 $
*/
   
   public class StandardContext
  @@ -1145,6 +1145,7 @@
   
   // Set up the Jasper class loader
   StandardClassLoader newLoader = new StandardClassLoader(classLoader);
  +newLoader.setDelegate(true);
   File directory = new File(System.getProperty("catalina.home"),
 "jasper");
   if (directory.exists() && directory.canRead() &&
  
  
  

DO NOT REPLY [Bug 3845] New: - Body content is supposed to be empty

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

Body content is supposed to be empty

   Summary: Body content is supposed to be empty
   Product: Tomcat 4
   Version: 4.0 Final
  Platform: PC
OS/Version: Other
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Jasper
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Once you have defined a custom tag to have a body-content of empty in the TLD 
file, there seem to be problems using it on the page in anything but the 
shortened form (i.e. ). You get an error when you try to use another 
form such as those defined in JSP 2.3.4 (Empty Elements), for example 
. The error given is that the "body content is supposed to 
be empty", even though the body content is empty. Here's the top of the stack 
trace...

org.apache.jasper.compiler.ParseException: /xxx/yyy.jsp(11,16) Body is supposed 
to be empty for xxx:yyy
at org.apache.jasper.compiler.Parser$Tag.accept(Parser.java:842)
at org.apache.jasper.compiler.Parser.parse(Parser.java:1126)
at org.apache.jasper.compiler.Parser.parse(Parser.java:1091)
at org.apache.jasper.compiler.Parser.parse(Parser.java:1087)
at org.apache.jasper.compiler.ParserController.parse
(ParserController.java:213)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:210)
at org.apache.jasper.servlet.JspServlet.loadJSP(JspServlet.java:528)

cvs commit: jakarta-tomcat-4.0/catalina build.xml

[craigmcc]

craigmcc01/09/26 15:49:27

  Modified:catalina build.xml
  Log:
  Copy all static resource files, not just *.properties, into catalina.jar.
  
  Revision  ChangesPath
  1.68  +1 -1  jakarta-tomcat-4.0/catalina/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/build.xml,v
  retrieving revision 1.67
  retrieving revision 1.68
  diff -u -r1.67 -r1.68
  --- build.xml 2001/09/23 00:12:34 1.67
  +++ build.xml 2001/09/26 22:49:27 1.68
  @@ -493,7 +493,7 @@
   
   
 
  -
  +
 
   
   
  
  
  

DO NOT REPLY [Bug 3591] - HttpServletResponse.sendError() and sendRedirect() should commit the response

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

HttpServletResponse.sendError() and sendRedirect() should commit the response

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2001-09-26 15:42 ---
*** Bug 3844 has been marked as a duplicate of this bug. ***

DO NOT REPLY [Bug 3844] - Headers added to HttpServletResponse not ignored by container after call to sendError() or sendRedirect()

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

Headers added to HttpServletResponse not ignored by container after call to 
sendError() or sendRedirect()

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2001-09-26 15:42 ---
Already in the bug database.

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

Re: Tomcat next

[brian moseley]

On Wed, 26 Sep 2001, Craig R. McClanahan wrote:

> What would *you* like to see happen?  (And what would
> *you* like to work on to make it happen?  :-).

did you see my message about virtual host support for
authenticators and realms? :)

i will likely be able to put some time into it in the near
future, but i'd definitely like some feedback on my thoughts
before i consider it.

DO NOT REPLY [Bug 3844] - Headers added to HttpServletResponse not ignored by container after call to sendError() or sendRedirect()

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

Headers added to HttpServletResponse not ignored by container after call to 
sendError() or sendRedirect()





--- Additional Comments From [EMAIL PROTECTED]  2001-09-26 15:32 ---
That should be Servlet spec 2.3 not 3.2.

DO NOT REPLY [Bug 3844] New: - Headers added to HttpServletResponse not ignored by container after call to sendError() or sendRedirect()

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

Headers added to HttpServletResponse not ignored by container after call to 
sendError() or sendRedirect()

   Summary: Headers added to HttpServletResponse not ignored by
container after call to sendError() or sendRedirect()
   Product: Tomcat 4
   Version: 4.0 Final
  Platform: All
OS/Version: All
Status: NEW
  Severity: Major
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


Tomcat currently will forward any headers added after a call to sendError() or
sendRedirect() even though a call to either of these two methods will commit the
response.

Servlet Specification 3.2 section SRV.5.2 states that headers set after
the response has been committed should be ignored.

cvs commit: jakarta-tomcat/src/native/mod_jk/common jk_uri_worker_map.c

[larryi]

larryi  01/09/26 15:30:10

  Modified:src/native/mod_jk/common jk_uri_worker_map.c
  Log:
  Patch for buffer overflow problem.
  
  Submitted by: Bill Barker
  
  Revision  ChangesPath
  1.6   +7 -5  jakarta-tomcat/src/native/mod_jk/common/jk_uri_worker_map.c
  
  Index: jk_uri_worker_map.c
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/common/jk_uri_worker_map.c,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- jk_uri_worker_map.c   2001/05/16 20:49:25 1.5
  +++ jk_uri_worker_map.c   2001/09/26 22:30:09 1.6
  @@ -65,7 +65,7 @@
* servlet container.  *
* *
* Author:  Gal Shachor <[EMAIL PROTECTED]>   *
  - * Version: $Revision: 1.5 $   *
  + * Version: $Revision: 1.6 $   *
***/
   
   #include "jk_pool.h"
  @@ -347,11 +347,11 @@
   unsigned i;
   unsigned best_match = -1;
   unsigned longest_match = 0;
  -char clean_uri[4096];
  +char *clean_uri=NULL;
   char *url_rewrite = strstr(uri, JK_PATH_SESSION_IDENTIFIER);
   
   if(url_rewrite) {
  -strcpy(clean_uri, uri);
  + clean_uri = strdup(uri);
   url_rewrite = strstr(clean_uri, JK_PATH_SESSION_IDENTIFIER);
   *url_rewrite = '\0';
   uri = clean_uri;
  @@ -374,6 +374,7 @@
   "jk_uri_worker_map_t::map_uri_to_worker, Found an exact 
match %s -> %s\n",
   uw_map->maps[i].worker_name,
   uw_map->maps[i].context );
  + free(clean_uri);
   return uw_map->maps[i].worker_name;
   }
   } else if(MATCH_TYPE_CONTEXT == uw_map->maps[i].match_type) {
  @@ -418,6 +419,7 @@
   }
   
   if(-1 != best_match) {
  + free(clean_uri);
   return uw_map->maps[best_match].worker_name;
   } else {
   /*
  @@ -433,7 +435,8 @@
   if(fraud >= 0) {
   jk_log(l, JK_LOG_EMERG, 
  "In jk_uri_worker_map_t::map_uri_to_worker, found a security 
fraud in '%s'\n",
  -   uri);
  +   uri);
  + free(clean_uri);
   return uw_map->maps[fraud].worker_name;
   }
  }
  @@ -441,7 +444,6 @@
   jk_log(l, JK_LOG_ERROR, 
  "In jk_uri_worker_map_t::map_uri_to_worker, wrong parameters\n");
   }
  -
   jk_log(l, JK_LOG_DEBUG, 
  "jk_uri_worker_map_t::map_uri_to_worker, done without a match\n"); 
   
  
  
  

Re: Tomcat next

[cmanolache]

On Wed, 26 Sep 2001, Dave Oxley wrote:

> Hi all,
>
> A couple of questions on future Tomcat releases:
>
> 1. Will there be a TC3.4 release or is 3.x obsolete after 3.3?

AFAIK there is no plan for a 3.4 release after 3.3 - that doesn't mean 3.x
will be obsolete, just that the core is now stable and unlikely to
change, except bugfixes.

Having a stable core is essential for module development and for enhancing
the current set of modules. Even if there are many improvements we can add
to 3.3, I believe the benefit of keeping 3.3 stable is far bigger.

It is not yet decided how we'll release the new modules, but the main
idea is to keep the 'base' version as small and clean as possible, and
all features to be 'add-ons', outside of the base distribution, and have
only bug fixes in 3.3.x-releases.



Costin

Re: Tomcat next

[Craig R. McClanahan]

On Wed, 26 Sep 2001, Dave Oxley wrote:

> Date: Wed, 26 Sep 2001 22:59:55 +0100
> From: Dave Oxley <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Tomcat next
>
> Hi all,
>
> A couple of questions on future Tomcat releases:
>
> 1. Will there be a TC3.4 release or is 3.x obsolete after 3.3?

I don't know on this one.

> 2. Has TC4.0 been branched (i.e. has development started on TC4.1 or are you
> waiting for TC4.0.1 to branch?)

Yes, it has been branched ("tomcat_40_branch" is for 4.0.x).  The HEAD
branch can be used for new development and features.

> 3. Is there a list of planned features for TC4.1?
>

Hmm, the todo list doc looks like it got lost in the shuffle ...

Two big areas I'd like to see focus on (and where I and some of my
colleagues will definitely be spending some time) are:

* Major improvements to the JSP page compiler to improve the
  quality and performance of the code it generates, and to make
  the compiler itself more maintainable.  A high level requirements
  doc for my view of what this should include will be circulated soon.

* Implementing a nice administration/configuration interface (as a
  web app), talking to server components through a JMX interface
  (so that Tomcat can be managed by any JMX compliant tool).  Some
  time ago I published some functional requirements for this (in the
  Tomcat documentation, go to "Functional Specs" under "Catalina")
  but it hasn't received much in the way of comment yet.

What would *you* like to see happen?  (And what would *you* like to work
on to make it happen?  :-).

> Dave
> [EMAIL PROTECTED]
>

Craig

Re: [PATCH] Potential buffer overflow attach in mod_jk

[Andy Armstrong]

+1

[EMAIL PROTECTED] wrote:
> 
> On Wed, 26 Sep 2001, Ignacio J. Ortega wrote:
> 
> > I think we need Bill Barker & Kin-Man Chung aboard already.. if we dont
> > want to have more work that we already have integrating their patches..
> >
> > Next can change subject and call this a vote about giving them committer
> > access ASAP :)
> 
> +1 :-)
> 
> Costin

-- 
Andy Armstrong, Tagish

RE: [PATCH] Potential buffer overflow attach in mod_jk

[cmanolache]

On Wed, 26 Sep 2001, Ignacio J. Ortega wrote:

> I think we need Bill Barker & Kin-Man Chung aboard already.. if we dont
> want to have more work that we already have integrating their patches..
>
> Next can change subject and call this a vote about giving them committer
> access ASAP :)

+1 :-)



Costin

Re: TC 3.3 + mod_jk + j_security_check

[cmanolache]

On Thu, 27 Sep 2001, Bojan Smojver wrote:

> I was referring to the manual configuration, rather then ApacheConfig
> one. Some people (me :-) prefer to do things manually.
>
> I actually tried with /*.jsp (or /*.vm in my case) only and it (still)
> doesn't work (which makes sense and I don't consider it a problem)
> unless you specify:
>
> JkMount /login/j_security_check ajp13
>
> or whichever other place j_security_check is under. That's what I wanted
> to mention in the mod_jk HOWTO. It might save someone considerable
> amount of time.

+1

Manual configuration is the best :-)
( but ApacheConfig is getting very close )

Costin

Tomcat next

[Dave Oxley]

Hi all,

A couple of questions on future Tomcat releases:

1. Will there be a TC3.4 release or is 3.x obsolete after 3.3?
2. Has TC4.0 been branched (i.e. has development started on TC4.1 or are you 
waiting for TC4.0.1 to branch?)
3. Is there a list of planned features for TC4.1?

Dave
[EMAIL PROTECTED]

_
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Re: TC 3.3 + mod_jk + j_security_check

[Bojan Smojver]

I was referring to the manual configuration, rather then ApacheConfig
one. Some people (me :-) prefer to do things manually.

I actually tried with /*.jsp (or /*.vm in my case) only and it (still)
doesn't work (which makes sense and I don't consider it a problem)
unless you specify:

JkMount /login/j_security_check ajp13

or whichever other place j_security_check is under. That's what I wanted
to mention in the mod_jk HOWTO. It might save someone considerable
amount of time.

Bojan

Bill Barker wrote:
> 
> If the web.xml contains no servlet-mappings, then forwardAll="false" will
> generate:
> JkMount /myapp/servlet/* ajp13
> JkMount /myapp/*.jsp ajp13
> 
> and if in addition, the context uses form authorization:
> JkMount /myapp/path/to/j_security_check ajp13
> 
> You need to set noRoot="false" if you want the ROOT context mappings
> generated as well.
> 
> Larry has added other options to allow you to specify the directories where
> various files go (e.g. mod_jk.so), but I don't remember them off the top of
> my head.
> - Original Message -
> From: "Bojan Smojver" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, September 25, 2001 7:51 PM
> Subject: Re: TC 3.3 + mod_jk + j_security_check
> 
> > What if the only mapping is for instance:
> >
> > JkMount /*.jsp ajp13
> >
> > Will it still work?
> >
> > Bojan
> >
> > Bill Barker wrote:
> > >
> > > This is now implemented automatically in the ApacheConfig module.  By
> > > default it does:
> > > JkMount /myapp/* ajp13
> > >
> > > Turning this off (via forwardAll="false"), then it outputs all of the
> > > defined mappings (including j_security_check for form auth contexts).
> > > - Original Message -
> > > From: "Bojan Smojver" <[EMAIL PROTECTED]>
> > > To: "Tomcat Dev List" <[EMAIL PROTECTED]>
> > > Sent: Tuesday, September 25, 2001 5:34 PM
> > > Subject: TC 3.3 + mod_jk + j_security_check
> > >
> > > > Unless this is now implemented automatically in mod_jk, I think it
> would
> > > > be worth mentioning in mod_jk HOWTO about the need to JKMount
> > > > j_security_check when form authentication is used in applications.
> > > >
> > > > I think I should be able to fake a paragraph about it (with examples).
> > > >
> > > > Bojan
> > > >
> > > >
> > >
> > > **
> > >
> > > This message is intended only for the use of the person(s) listed above
> > > as the intended recipient(s), and may contain information that is
> > > PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient,
> > > you may not read, copy, or distribute this message or any attachment.
> > > If you received this communication in error, please notify us
> immediately
> > > by e-mail and then delete all copies of this message and any
> attachments.
> > >
> > > In addition you should be aware that ordinary (unencrypted) e-mail sent
> > > through the Internet is not secure. Do not send confidential or
> sensitive
> > > information, such as social security numbers, account numbers, personal
> > > identification numbers and passwords, to us via ordinary (unencrypted)
> > > e-mail.
> >
> >
> 
> **
> 
> This message is intended only for the use of the person(s) listed above
> as the intended recipient(s), and may contain information that is
> PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient,
> you may not read, copy, or distribute this message or any attachment.
> If you received this communication in error, please notify us immediately
> by e-mail and then delete all copies of this message and any attachments.
> 
> In addition you should be aware that ordinary (unencrypted) e-mail sent
> through the Internet is not secure. Do not send confidential or sensitive
> information, such as social security numbers, account numbers, personal
> identification numbers and passwords, to us via ordinary (unencrypted)
> e-mail.

RE: TC 3.3 Release Plan

[Larry Isaacs]

I will update the RELEASE-PLAN-3.3 tonight to
say the RC2 freeze date is Oct 6 to provide for
the nomal delay between tagging CVS and posting
the release.  Since there isn't a freeze date
involved with the final, I can prepare the
release a little ahead of time, so I'll keep
this as Oct 15'th.

Larry

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 26, 2001 2:17 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: TC 3.3 Release Plan
> 
> 
> On Wed, 26 Sep 2001, Larry Isaacs wrote:
> 
> > Hi David,
> >
> > I had hoped to get Tomcat 3.3 released prior to my up
> > coming house closings and move.  I won't be able to
> > make this target, but hope to get Tomcat 3.3 to RC2
> > not too long after the move, perhaps around October 8.
> > It is RC2 that I plan to propose for release and be
> > voted on.  The vote should last a week, and if approved,
> > I will quickly post the final release.
> 
> That means Oct. 15 should be the target date for the final
> to be posted officially, and the final code will be frozen on Oct. 8.
> 
> Costin
> 
> 

RE: [PATCH] Potential buffer overflow attach in mod_jk

[Ignacio J. Ortega]

I think we need Bill Barker & Kin-Man Chung aboard already.. if we dont
want to have more work that we already have integrating their patches..

Next can change subject and call this a vote about giving them committer
access ASAP :)

Saludos ,
Ignacio J. Ortega


> -Mensaje original-
> De: Bill Barker [mailto:[EMAIL PROTECTED]]
> Enviado el: miércoles 26 de septiembre de 2001 20:31
> Para: [EMAIL PROTECTED]
> Asunto: [PATCH] Potential buffer overflow attach in mod_jk
> 
> 
> While checking to see how mod_jk handled the ;jsessionid= in 
> the URL, I was
> horrified to see how easily it would be to take control of 
> the server with a
> relatively small buffer overflow.  I'm not really an Apache 
> person, so I'm
> certain that this can be improved on.
> 
> 
> **
> 
> This message is intended only for the use of the person(s) 
> listed above 
> as the intended recipient(s), and may contain information that is 
> PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, 
> you may not read, copy, or distribute this message or any 
> attachment.  
> If you received this communication in error, please notify us 
> immediately 
> by e-mail and then delete all copies of this message and any 
> attachments.
> 
> 
> In addition you should be aware that ordinary (unencrypted) 
> e-mail sent 
> through the Internet is not secure. Do not send confidential 
> or sensitive 
> information, such as social security numbers, account 
> numbers, personal 
> identification numbers and passwords, to us via ordinary 
> (unencrypted) 
> e-mail. 
> 

DO NOT REPLY [Bug 3704] - forward errors not reported

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

forward errors not reported

[EMAIL PROTECTED] changed:

   What|Removed |Added

  Component|Jasper  |Catalina



--- Additional Comments From [EMAIL PROTECTED]  2001-09-26 12:56 ---
This is a container problem.

Fw: [PATCH] Potential buffer overflow attach in mod_jk

[Bill Barker]

Urm, let's try that again with a patch that at least compiles..
- Original Message -
From: "Bill Barker" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 26, 2001 11:30 AM
Subject: [PATCH] Potential buffer overflow attach in mod_jk


> While checking to see how mod_jk handled the ;jsessionid= in the URL, I
was
> horrified to see how easily it would be to take control of the server with
a
> relatively small buffer overflow.  I'm not really an Apache person, so I'm
> certain that this can be improved on.
>


**

This message is intended only for the use of the person(s) listed above 
as the intended recipient(s), and may contain information that is 
PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, 
you may not read, copy, or distribute this message or any attachment.  
If you received this communication in error, please notify us immediately 
by e-mail and then delete all copies of this message and any attachments.


In addition you should be aware that ordinary (unencrypted) e-mail sent 
through the Internet is not secure. Do not send confidential or sensitive 
information, such as social security numbers, account numbers, personal 
identification numbers and passwords, to us via ordinary (unencrypted) 
e-mail. 
 jk_uri_worker_map.diff

[PATCH] Potential buffer overflow attach in mod_jk

[Bill Barker]

While checking to see how mod_jk handled the ;jsessionid= in the URL, I was
horrified to see how easily it would be to take control of the server with a
relatively small buffer overflow.  I'm not really an Apache person, so I'm
certain that this can be improved on.


**

This message is intended only for the use of the person(s) listed above 
as the intended recipient(s), and may contain information that is 
PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, 
you may not read, copy, or distribute this message or any attachment.  
If you received this communication in error, please notify us immediately 
by e-mail and then delete all copies of this message and any attachments.


In addition you should be aware that ordinary (unencrypted) e-mail sent 
through the Internet is not secure. Do not send confidential or sensitive 
information, such as social security numbers, account numbers, personal 
identification numbers and passwords, to us via ordinary (unencrypted) 
e-mail. 
 jk_uri_worker_map.diff

DO NOT REPLY [Bug 3841] - incorrect state reported by EmbeddedManager.java:start()

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

incorrect state reported by EmbeddedManager.java:start()

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2001-09-26 11:57 ---
Fixed. Thanks for the patch.

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

[remm]

remm01/09/26 11:56:29

  Modified:catalina/src/share/org/apache/catalina/startup Tag:
tomcat_40_branch EmbeddedManager.java
  Log:
  - If embedded.start() fails, the state would be incorrect.
Thanks to Toby Cabot (toby at caboteria.org) for the patch.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.3.2.1   +11 -11
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/EmbeddedManager.java
  
  Index: EmbeddedManager.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/EmbeddedManager.java,v
  retrieving revision 1.3
  retrieving revision 1.3.2.1
  diff -u -r1.3 -r1.3.2.1
  --- EmbeddedManager.java  2001/07/22 20:25:13 1.3
  +++ EmbeddedManager.java  2001/09/26 18:56:29 1.3.2.1
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/EmbeddedManager.java,v
 1.3 2001/07/22 20:25:13 pier Exp $
  - * $Revision: 1.3 $
  - * $Date: 2001/07/22 20:25:13 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/EmbeddedManager.java,v
 1.3.2.1 2001/09/26 18:56:29 remm Exp $
  + * $Revision: 1.3.2.1 $
  + * $Date: 2001/09/26 18:56:29 $
*
* 
*
  @@ -87,7 +87,7 @@
* Implementation of the Catalina JMX MBean as a wrapper of the Catalina class.
*
* @author mailto:[EMAIL PROTECTED]";>Remy Maucherat
  - * @version $Revision: 1.3 $
  + * @version $Revision: 1.3.2.1 $
*/
   
   public final class EmbeddedManager
  @@ -192,6 +192,13 @@
   
   embedded.start();
   
  +state = STARTED;
  +notification = new AttributeChangeNotification
  +(this, sequenceNumber++, System.currentTimeMillis(),
  + "Started " + NAME, "State", "java.lang.Integer",
  + new Integer(STARTING), new Integer(STARTED));
  +sendNotification(notification);
  +
   } catch (Throwable t) {
   state = STOPPED;
   notification = new AttributeChangeNotification
  @@ -200,13 +207,6 @@
new Integer(STARTING), new Integer(STOPPED));
   sendNotification(notification);
   }
  -
  -state = STARTED;
  -notification = new AttributeChangeNotification
  -(this, sequenceNumber++, System.currentTimeMillis(),
  - "Started " + NAME, "State", "java.lang.Integer",
  - new Integer(STARTING), new Integer(STARTED));
  -sendNotification(notification);
   
   }
   
  
  
  

Re: TC 3.3: getRequestURI()

[Bill Barker]

Yes.
- Original Message - 
From: "Keith Wannamaker" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 26, 2001 10:57 AM
Subject: RE: TC 3.3: getRequestURI()


> Are you using mod_jk?
> 
> | -Original Message-
> | From: Bill Barker [mailto:[EMAIL PROTECTED]]
> | Sent: Wednesday, September 26, 2001 1:17 PM
> | To: [EMAIL PROTECTED]
> | Subject: Re: TC 3.3: getRequestURI()
> | 
> | 
> | I don't get this with RC1.  From tomcat-log with debugging enabled for
> 
> 


**

This message is intended only for the use of the person(s) listed above 
as the intended recipient(s), and may contain information that is 
PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, 
you may not read, copy, or distribute this message or any attachment.  
If you received this communication in error, please notify us immediately 
by e-mail and then delete all copies of this message and any attachments.


In addition you should be aware that ordinary (unencrypted) e-mail sent 
through the Internet is not secure. Do not send confidential or sensitive 
information, such as social security numbers, account numbers, personal 
identification numbers and passwords, to us via ordinary (unencrypted) 
e-mail. 

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

[remm]

remm01/09/26 11:55:40

  Modified:catalina/src/share/org/apache/catalina/startup
EmbeddedManager.java
  Log:
  - If embedded.start() fails, the state would be incorrect.
Thanks to Toby Cabot (toby at caboteria.org) for the patch.
  
  Revision  ChangesPath
  1.4   +11 -11
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/EmbeddedManager.java
  
  Index: EmbeddedManager.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/EmbeddedManager.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- EmbeddedManager.java  2001/07/22 20:25:13 1.3
  +++ EmbeddedManager.java  2001/09/26 18:55:40 1.4
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/EmbeddedManager.java,v
 1.3 2001/07/22 20:25:13 pier Exp $
  - * $Revision: 1.3 $
  - * $Date: 2001/07/22 20:25:13 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/EmbeddedManager.java,v
 1.4 2001/09/26 18:55:40 remm Exp $
  + * $Revision: 1.4 $
  + * $Date: 2001/09/26 18:55:40 $
*
* 
*
  @@ -87,7 +87,7 @@
* Implementation of the Catalina JMX MBean as a wrapper of the Catalina class.
*
* @author mailto:[EMAIL PROTECTED]";>Remy Maucherat
  - * @version $Revision: 1.3 $
  + * @version $Revision: 1.4 $
*/
   
   public final class EmbeddedManager
  @@ -192,6 +192,13 @@
   
   embedded.start();
   
  +state = STARTED;
  +notification = new AttributeChangeNotification
  +(this, sequenceNumber++, System.currentTimeMillis(),
  + "Started " + NAME, "State", "java.lang.Integer",
  + new Integer(STARTING), new Integer(STARTED));
  +sendNotification(notification);
  +
   } catch (Throwable t) {
   state = STOPPED;
   notification = new AttributeChangeNotification
  @@ -200,13 +207,6 @@
new Integer(STARTING), new Integer(STOPPED));
   sendNotification(notification);
   }
  -
  -state = STARTED;
  -notification = new AttributeChangeNotification
  -(this, sequenceNumber++, System.currentTimeMillis(),
  - "Started " + NAME, "State", "java.lang.Integer",
  - new Integer(STARTING), new Integer(STARTED));
  -sendNotification(notification);
   
   }
   
  
  
  

cvs commit: jakarta-tomcat-4.0/webapps/examples build.xml

[remm]

remm01/09/26 11:49:08

  Modified:.Tag: tomcat_40_branch BUILDING.txt
build.properties.sample build.xml
   catalina Tag: tomcat_40_branch build.xml
   webapps/examples Tag: tomcat_40_branch build.xml
  Log:
  - Port the new buid scripts to the 4.0 branch.
  - AJP / tomcat-utils is required for a full.dist.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.5.2.1   +27 -14jakarta-tomcat-4.0/BUILDING.txt
  
  Index: BUILDING.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/BUILDING.txt,v
  retrieving revision 1.5
  retrieving revision 1.5.2.1
  diff -u -r1.5 -r1.5.2.1
  --- BUILDING.txt  2001/09/17 06:18:57 1.5
  +++ BUILDING.txt  2001/09/26 18:49:08 1.5.2.1
  @@ -1,4 +1,4 @@
  -$Id: BUILDING.txt,v 1.5 2001/09/17 06:18:57 ccain Exp $
  +$Id: BUILDING.txt,v 1.5.2.1 2001/09/26 18:49:08 remm Exp $
   
   
  Building The Tomcat 4.0 Servlet/JSP Container
  @@ -138,17 +138,23 @@
 distribution resides in its own directory.
   
   
  -(6) Download and Install JDBC Optional Package API
  +(6) Steps (7) - (17) are optional, but are necessary to build a complete binary
  +distribution of Tomcat 4.0. Set the "full.dist" property to "on" in the
  +build.properties file (see step (18)) to build a complete distribution.
  +Regular contributors to Tomcat are encouraged to use the complete build 
  +option.
   
  +
  +(7) Download and Install JDBC Optional Package API Binary Distribution
  +
   * Download the JDBC Optional Pacakge API package (version 2.0) from:
   
   http://java.sun.com/products/jdbc/download.html
   
  -* Unpack the package into a convenient location so that it resides
  -  in its own subdirectory.
  +* Place the jar in a convenient location.
   
   
  -(7) Download and Install the JMX 1.0 Reference Implementation
  +(8) Download and Install the JMX 1.0 Reference Implementation
   
   * Download the JMX Instrumentation and Agent Reference Implementation
 (version 1.0 or later) from
  @@ -159,7 +165,7 @@
 it resides in its own subdirectory.
   
   
  -(8) Download and Install the JNDI 1.2.1 Reference Implementation
  +(9) Download and Install the JNDI 1.2.1 Reference Implementation
   
   * Download the Java Naming and Directory Interface (JNDI) package,
 (version 1.2.1 or later) from
  @@ -173,7 +179,7 @@
 same download page.  Be sure that you unpack "ldap.jar" into the "lib"
 subdirectory of the JNDI directory, parallel to "jndi.jar".
   
  -(9) Download and Install the Java Activation Framework 1.0.1
  +(10) Download and Install the Java Activation Framework 1.0.1
   
   * Download the Java Activation Framework package (version 1.0.1 or later) from
   
  @@ -182,7 +188,7 @@
   * Unpack the package into a convenient location so that it
 resised in its own subdirectory.
   
  -(10) Download and Install JavaMail 1.2
  +(11) Download and Install JavaMail 1.2
   
   * Download the JavaMail package (version 1.2 or later) from
   
  @@ -192,7 +198,7 @@
 it resides in its own subdirectory.
   
   
  -(11) Download and Install the JSSE 1.0.2 Reference Implementation
  +(12) Download and Install the JSSE 1.0.2 Reference Implementation
   
   * Download the Java Secure Sockets Extension (JSSE) package,
 (version 1.0.2 or later) from
  @@ -203,7 +209,7 @@
 it resides in its own subdirectory.
   
   
  -(12) Download and Install the Java Transaction APIs
  +(13) Download and Install the Java Transaction APIs
   
   * Download the Java Transaction API (JTA) package (version 1.0.1) from:
   
  @@ -213,7 +219,7 @@
 own subdirectory.
   
   
  -(13) Download and Install the Tyrex Data Source Package
  +(14) Download and Install the Tyrex Data Source Package
   
   NOTE:  This step is only required if you wish to build the Tyrex connection
   pool implementation for JNDI-accessed data sources.
  @@ -226,7 +232,7 @@
 own subdirectory.
   
   
  -(14) Download and Install the JUnit Testing Package (OPTIONAL)
  +(15) Download and Install the JUnit Testing Package (OPTIONAL)
   
   NOTE:  This step is only required if you wish to build and execute the unit
   tests that are part of the Tomcat 4.0 source base.
  @@ -238,8 +244,15 @@
   * Unpack the package into a convenient location so that it resides in its
 own subdirectory.
   
  +
  +(16) Check out the jakarta-tomcat-connectors repository, using the "TOMCAT_4_1"
  + tag.
  +
  +
  +(17) Compile the "util" module, and the "jk" module.
  +
   
  -(15) Customize Build Properties For This Subproject
  +(18) Customize Build Properties For This Subproject
   
   Most Jakarta subprojects allow you to customize Ant properties (with default
   values defined in the "build.xml" file.  This is done by creating a text file
  @@ -263,7 +276,7 @@
   each developer will have their own 

RE: TC 3.3 Release Plan

[cmanolache]

On Wed, 26 Sep 2001, Larry Isaacs wrote:

> Hi David,
>
> I had hoped to get Tomcat 3.3 released prior to my up
> coming house closings and move.  I won't be able to
> make this target, but hope to get Tomcat 3.3 to RC2
> not too long after the move, perhaps around October 8.
> It is RC2 that I plan to propose for release and be
> voted on.  The vote should last a week, and if approved,
> I will quickly post the final release.

That means Oct. 15 should be the target date for the final
to be posted officially, and the final code will be frozen on Oct. 8.

Costin

cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs/config host.xml

[remm]

remm01/09/26 11:10:28

  Modified:webapps/tomcat-docs/config host.xml
  Log:
  - Update docs on the new property for StandardHost.
  
  Revision  ChangesPath
  1.4   +11 -0 jakarta-tomcat-4.0/webapps/tomcat-docs/config/host.xml
  
  Index: host.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/config/host.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- host.xml  2001/09/26 02:29:21 1.3
  +++ host.xml  2001/09/26 18:10:28 1.4
  @@ -107,6 +107,17 @@
   debugging detail level is zero (0).
 
   
  +  
  +Java class name of the error reporting valve which will be used
  +by this Host. The responsability of this valve is to output error
  +reports. Setting this property allows to customize the look of the
  +error pages which will be generated by Tomcat. This class must 
  +implement the 
  +org.apache.catalina.Valve interface. If none is specified,
  +the value org.apache.catalina.valves.ErrorReportValve 
  +will be used by default.
  +  
  +
 
   Set to true if you want web applications that are
   deployed into this virtual host from a Web Application Archive (WAR)
  
  
  

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

[remm]

remm01/09/26 11:00:09

  Modified:catalina/src/share/org/apache/catalina/core
StandardHost.java
  Log:
  - Error report and dispatching refactoring.
  - The StandardHost will automatically add two valves on startup: the error page
dispatcher valve, and an error report valve.
  - The error report valve used is pluggable. The errorReportValveClass property
allows to specify the valve classname.
  - Since both the error page dispatching and error page output are done at the host
level, that allows to:
- set an error page for 401, 403, 503 (although it will still NOT work if the 
whole context is
  unavailable), as well as the status code returned by the context (404 and 400), 
or
  any exception which happens somewhere else during the processing.
- get nice error reports in nearly all situations.
  - No errors are reported when running the tester with this refactoring.
  
  Revision  ChangesPath
  1.19  +73 -4 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardHost.java
  
  Index: StandardHost.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardHost.java,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- StandardHost.java 2001/08/27 19:10:25 1.18
  +++ StandardHost.java 2001/09/26 18:00:09 1.19
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardHost.java,v
 1.18 2001/08/27 19:10:25 craigmcc Exp $
  - * $Revision: 1.18 $
  - * $Date: 2001/08/27 19:10:25 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardHost.java,v
 1.19 2001/09/26 18:00:09 remm Exp $
  + * $Revision: 1.19 $
  + * $Date: 2001/09/26 18:00:09 $
*
* 
*
  @@ -91,7 +91,9 @@
   import org.apache.catalina.LifecycleListener;
   import org.apache.catalina.Request;
   import org.apache.catalina.Response;
  +import org.apache.catalina.Valve;
   import org.apache.catalina.core.DefaultContext;
  +import org.apache.catalina.valves.ErrorDispatcherValve;
   
   
   /**
  @@ -100,7 +102,8 @@
* requests directed to a particular web application.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.18 $ $Date: 2001/08/27 19:10:25 $
  + * @author Remy Maucherat
  + * @version $Revision: 1.19 $ $Date: 2001/09/26 18:00:09 $
*/
   
   public class StandardHost
  @@ -154,6 +157,14 @@
   
   
   /**
  + * The Java class name of the default error reporter implementation class 
  + * for deployed web applications.
  + */
  +private String errorReportValveClass =
  +"org.apache.catalina.valves.ErrorReportValve";
  +
  +
  +/**
* The descriptive information string for this implementation.
*/
   private static final String info =
  @@ -304,6 +315,34 @@
   
   
   /**
  + * Return the Java class name of the error report valve class
  + * for new web applications.
  + */
  +public String getErrorReportValveClass() {
  +
  +return (this.errorReportValveClass);
  +
  +}
  +
  +
  +/**
  + * Set the Java class name of the error report valve class
  + * for new web applications.
  + *
  + * @param errorReportValveClass The new error report valve class
  + */
  +public void setErrorReportValveClass(String errorReportValveClass) {
  +
  +String oldErrorReportValveClassClass = this.errorReportValveClass;
  +this.errorReportValveClass = errorReportValveClass;
  +support.firePropertyChange("errorReportValveClass",
  +   oldErrorReportValveClassClass, 
  +   this.errorReportValveClass);
  +
  +}
  +
  +
  +/**
* Return the canonical, fully qualified, name of the virtual host
* this Container represents.
*/
  @@ -541,6 +580,36 @@
   sb.append(getName());
   sb.append("]");
   return (sb.toString());
  +
  +}
  +
  +
  +/**
  + * Start this host.
  + *
  + * @exception IllegalStateException if this component has already been
  + *  started
  + * @exception LifecycleException if this component detects a fatal error
  + *  that prevents it from being started
  + */
  +public synchronized void start() throws LifecycleException {
  +
  +// Set error report valve
  +if (errorReportValveClass != null) {
  +try {
  +Valve valve = (Valve) Class.forName(errorReportValveClass)
  +.newInstance();
  +addValve(valve);
  +} catch (Throwable t) {
  +// FIXME
  +t.printStackTrace();
  +}
  +}
  +
  + 

Re: %=x% expression syntax bug in XML jsp?

[Craig R. McClanahan]

On Wed, 26 Sep 2001, Mark Abbott wrote:

> Date: Wed, 26 Sep 2001 10:43:51 -0700
> From: Mark Abbott <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: %=x% expression syntax bug in XML jsp?
>
> Hi Craig -
>
> I'm curious whether the expert group has discussed what
> might be done in the future about this unfortunate
> aspect of JSP. In what I would think would be a
> really common case in the future, where one wants to
> design an app using clean, readable, and purely XML
> templates (perhaps XHTML for example), but editing by
> hand rather than with some JSP savvy tool, the choices
> are:
>
> > * Create a custom tag  which just dumps out the
> >   corresponding  tag
>
> Wrapping all the tags in every markup of interest is impractical
>
> > * Write the XML syntax in the way that the JSP compiler expects:
> >
> >xpos
> >

RE: TC 3.3: getRequestURI()

[Keith Wannamaker]

Are you using mod_jk?

| -Original Message-
| From: Bill Barker [mailto:[EMAIL PROTECTED]]
| Sent: Wednesday, September 26, 2001 1:17 PM
| To: [EMAIL PROTECTED]
| Subject: Re: TC 3.3: getRequestURI()
| 
| 
| I don't get this with RC1.  From tomcat-log with debugging enabled for

RE: TC 3.3 Release Plan

[Larry Isaacs]

Hi David,

I had hoped to get Tomcat 3.3 released prior to my up
coming house closings and move.  I won't be able to
make this target, but hope to get Tomcat 3.3 to RC2
not too long after the move, perhaps around October 8.
It is RC2 that I plan to propose for release and be
voted on.  The vote should last a week, and if approved,
I will quickly post the final release.

Larry

> -Original Message-
> From: Schreibman, David [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 26, 2001 1:35 PM
> To: '[EMAIL PROTECTED]'
> Subject: TC 3.3 Release Plan
> 
> 
> Hi,
> 
> Is there a schedule update in the works?
> 
> I'm working on a migration plan and noticed that the current 
> 3.3 release
> plan calls for RC2 code freeze on Sept. 21 and a final code 
> freeze on Sept.
> 28.
> 
> Thanks,
> 
> -David
> 

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core LocalStrings.properties LocalStrings_ja.properties

[remm]

remm01/09/26 10:51:52

  Modified:catalina/src/share/org/apache/catalina/core
LocalStrings.properties LocalStrings_ja.properties
  Log:
  - Move some strings to the valves package.
  
  Revision  ChangesPath
  1.38  +0 -42 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/LocalStrings.properties
  
  Index: LocalStrings.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/LocalStrings.properties,v
  retrieving revision 1.37
  retrieving revision 1.38
  diff -u -r1.37 -r1.38
  --- LocalStrings.properties   2001/09/16 22:26:33 1.37
  +++ LocalStrings.properties   2001/09/26 17:51:52 1.38
  @@ -149,45 +149,3 @@
   standardWrapper.unavailable=Marking servlet {0} as unavailable
   standardWrapper.unloadException=Servlet {0} threw unload() exception
   standardWrapper.unloading=Cannot allocate servlet {0} because it is being unloaded
  -http.100=The client may continue ({0}).
  -http.101=The server is switching protocols according to the "Upgrade" header ({0}).
  -http.201=The request succeeded and a new resource ({0}) has been created on the 
server.
  -http.202=This request was accepted for processing, but has not been completed ({0}).
  -http.203=The meta information presented by the client did not originate from the 
server ({0}).
  -http.204=The request succeeded but there is no information to return ({0}).
  -http.205=The client should reset the document view which caused this request to be 
sent ({0}).
  -http.206=The server has fulfilled a partial GET request for this resource ({0}).
  -http.207=Multiple status values have been returned ({0}).
  -http.300=The requested resource ({0}) corresponds to any one of a set of 
representations, each with its own specific location.
  -http.301=The requested resource ({0}) has moved permanently to a new location.
  -http.302=The requested resource ({0}) has moved temporarily to a new location.
  -http.303=The response to this request can be found under a different URI ({0}).
  -http.304=The requested resource ({0}) is available and has not been modified.
  -http.305=The requested resource ({0}) must be accessed through the proxy given by 
the "Location" header.
  -http.400=The request sent by the client was syntactically incorrect ({0}).
  -http.401=This request requires HTTP authentication ({0}).
  -http.402=Payment is required for access to this resource ({0}).
  -http.403=Access to the specified resource ({0}) has been forbidden.
  -http.404=The requested resource ({0}) is not available.
  -http.405=The specified HTTP method is not allowed for the requested resource ({0}).
  -http.406=The resource identified by this request is only capable of generating 
responses with characteristics not acceptable according to the request "accept" 
headers ({0}).
  -http.407=The client must first authenticate itself with the proxy ({0}).
  -http.408=The client did not produce a request within the time that the server was 
prepared to wait ({0}).
  -http.409=The request could not be completed due to a conflict with the current 
state of the resource ({0}).
  -http.410=The requested resource ({0}) is no longer available, and no forwarding 
address is known.
  -http.411=This request cannot be handled without a defined content length ({0}).
  -http.412=A specified precondition has failed for this request ({0}).
  -http.413=The request entity is larger than the server is willing or able to process.
  -http.414=The server refused this request because the request URI was too long ({0}).
  -http.415=The server refused this request because the request entity is in a format 
not supported by the requested resource for the requested method ({0}).
  -http.416=The requested byte range cannot be satisfied ({0}).
  -http.417=The expectation given in the "Expect" request header ({0}) could not be 
fulfilled.
  -http.422=The server understood the content type and syntax of the request but was 
unable to process the contained instructions ({0}).
  -http.423=The source or destination resource of a method is locked ({0}).
  -http.500=The server encountered an internal error ({0}) that prevented it from 
fulfilling this request.
  -http.501=The server does not support the functionality needed to fulfill this 
request ({0}).
  -http.502=This server received an invalid response from a server it consulted when 
acting as a proxy or gateway ({0}).
  -http.503=The requested service ({0}) is not currently available.
  -http.504=The server received a timeout from an upstream server while acting as a 
gateway or proxy ({0}).
  -http.505=The server does not support the requested HTTP protocol version ({0}).
  -http.507=The resource does not have sufficient space to record the state of the 
resource after execution of this method ({0}).
  
  
  
  1.3   +0 -42 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina

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

[remm]

remm01/09/26 10:51:07

  Modified:catalina/src/share/org/apache/catalina/core
StandardContextValve.java
  Log:
  - Error report and dispatching refactoring.
  - Remove some status report output code (everything is now done in one
single place).
  
  Revision  ChangesPath
  1.13  +8 -49 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContextValve.java
  
  Index: StandardContextValve.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContextValve.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- StandardContextValve.java 2001/07/25 04:05:50 1.12
  +++ StandardContextValve.java 2001/09/26 17:51:07 1.13
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContextValve.java,v
 1.12 2001/07/25 04:05:50 remm Exp $
  - * $Revision: 1.12 $
  - * $Date: 2001/07/25 04:05:50 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardContextValve.java,v
 1.13 2001/09/26 17:51:07 remm Exp $
  + * $Revision: 1.13 $
  + * $Date: 2001/09/26 17:51:07 $
*
* 
*
  @@ -93,7 +93,7 @@
* when processing HTTP requests.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.12 $ $Date: 2001/07/25 04:05:50 $
  + * @version $Revision: 1.13 $ $Date: 2001/09/26 17:51:07 $
*/
   
   final class StandardContextValve
  @@ -191,21 +191,12 @@
   try {
   wrapper = (Wrapper) context.map(request, true);
   } catch (IllegalArgumentException e) {
  -badRequest(requestURI, (HttpServletResponse) response.getResponse());
  -try {
  -response.finishResponse();
  -} catch (IOException f) {
  -;
  -}
  +badRequest(requestURI, 
  +   (HttpServletResponse) response.getResponse());
   return;
   }
   if (wrapper == null) {
   notFound(requestURI, (HttpServletResponse) response.getResponse());
  -try {
  -response.finishResponse();
  -} catch (IOException e) {
  -;
  -}
   return;
   }
   
  @@ -232,25 +223,9 @@
   private void badRequest(String requestURI, HttpServletResponse response) {
   
   try {
  -requestURI = RequestUtil.filter(requestURI);
  -response.setStatus(HttpServletResponse.SC_BAD_REQUEST);
  -response.setContentType("text/html");
  -PrintWriter writer = response.getWriter();
  -writer.println("");
  -writer.println("");
  -writer.println("Tomcat Error Report");
  -writer.println("");
  -writer.println("");
  -writer.println("HTTP Status 400 - " + requestURI + "");
  -writer.println(sm.getString("standardContext.badRequest",
  -requestURI));
  -writer.println("");
  -writer.println("");
  -writer.flush();
  +response.setStatus(HttpServletResponse.SC_BAD_REQUEST, requestURI);
   } catch (IllegalStateException e) {
   ;
  -} catch (IOException e) {
  -;
   }
   
   }
  @@ -267,24 +242,8 @@
   private void notFound(String requestURI, HttpServletResponse response) {
   
   try {
  -requestURI = RequestUtil.filter(requestURI);
  -response.setStatus(HttpServletResponse.SC_NOT_FOUND);
  -response.setContentType("text/html");
  -PrintWriter writer = response.getWriter();
  -writer.println("");
  -writer.println("");
  -writer.println("Tomcat Error Report");
  -writer.println("");
  -writer.println("");
  -writer.println("HTTP Status 404 - " + requestURI + "");
  -writer.println(sm.getString("standardContext.notFound",
  -requestURI));
  -writer.println("");
  -writer.println("");
  -writer.flush();
  +response.setStatus(HttpServletResponse.SC_NOT_FOUND, requestURI);
   } catch (IllegalStateException e) {
  -;
  -} catch (IOException e) {
   ;
   }
   
  
  
  

Tomcat 4.0 RPMs?

[Vic Ricker]

Hi.

Will RPMs for Tomcat 4.0 be released on the web site any time soon?

I have no problem installing from the tar but I'd prefer the RPM since that's
how I installed the previous version.

Thanks,
-Vic

DO NOT REPLY [Bug 3779] - the value of should be URL encoded

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

the value of  should be URL encoded

[EMAIL PROTECTED] changed:

   What|Removed |Added

  Component|Jasper  |Catalina



--- Additional Comments From [EMAIL PROTECTED]  2001-09-26 10:50 ---
Part of the java code generated for





is

// begin [file="/jsp/test/b3779.jsp";from=(0,0);to=(2,14)]
if (true) {
out.clear();
String _jspx_qfStr = "";
_jspx_qfStr = _jspx_qfStr + "?test1=" + "value = 1";
pageContext.forward("b3779a.jsp" +  _jspx_qfStr);
return;
}
// end

looks perfectly fine.  Looks like a container problem.

Re: TC 3.3: getRequestURI()

[Bill Barker]

I don't get this with RC1.  From tomcat-log with debugging enabled for
Sessions and Decode:
2001-09-26 11:04:29 - DecodeInterceptor: Before
/index.jsp%3bjsessionid=xx7xdv3ca1
2001-09-26 11:04:29 - DecodeInterceptor: After
/index.jsp;jsessionid=xx7xdv3ca1
2001-09-26 11:04:29 - SessionId: Url rewriting, found
org.apache.tomcat.core.ServerSession@7a8a02
2001-09-26 11:04:29 - ContextManager: Before Body xx7xdv3ca1

In other words, SessionId correctly removes the session identifier before it
can reach HttpServletRequest.getRequestURI()
- Original Message -
From: "Bojan Smojver" <[EMAIL PROTECTED]>
To: "Tomcat Dev List" <[EMAIL PROTECTED]>
Sent: Wednesday, September 26, 2001 4:41 AM
Subject: TC 3.3: getRequestURI()


> The latest TC 3.3 CVS with its mod_jk, gives an encoded URI, together
> with the session ID on HttpServletRequest.getRequestURI().
>
> Example:
>
> /login/login.vm%3bjsessionid=q95pbsuof1
>
> Previously, jsessionid wasn't there. The change was intentional, right?
>
> Bojan
>
>


**

This message is intended only for the use of the person(s) listed above 
as the intended recipient(s), and may contain information that is 
PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, 
you may not read, copy, or distribute this message or any attachment.  
If you received this communication in error, please notify us immediately 
by e-mail and then delete all copies of this message and any attachments.


In addition you should be aware that ordinary (unencrypted) e-mail sent 
through the Internet is not secure. Do not send confidential or sensitive 
information, such as social security numbers, account numbers, personal 
identification numbers and passwords, to us via ordinary (unencrypted) 
e-mail. 

DO NOT REPLY [Bug 3841] New: - incorrect state reported by EmbeddedManager.java:start()

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

incorrect state reported by EmbeddedManager.java:start()

   Summary: incorrect state reported by EmbeddedManager.java:start()
   Product: Tomcat 4
   Version: 4.0 Final
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Minor
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


The start() method of EmbeddedManager.java reports its state incorrectly if
Embedded.java:start() throws an exception.  The "catch" block looks OK, it sets
the state to "Stopped", but the problem is that the code after the catch then
gets executed and sends an erroneous AttributeChangeNotification to the JMX
MBean Server.

The fix is to put the AttributeChangeNotification into the try{} block, so that
it won't run if an error is thrown.  Here's a patch:

Index: catalina/src/share/org/apache/catalina/startup/EmbeddedManager.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/EmbeddedManager.java,v
retrieving revision 1.3
diff -u -r1.3 EmbeddedManager.java
--- catalina/src/share/org/apache/catalina/startup/EmbeddedManager.java 2001/07/22 
20:25:13 1.3
+++ catalina/src/share/org/apache/catalina/startup/EmbeddedManager.java 2001/09/26 
+16:19:17
@@ -192,6 +192,13 @@
 
 embedded.start();
 
+
state = STARTED;
+
notification = new AttributeChangeNotification
+
(this, sequenceNumber++, System.currentTimeMillis(),
+
 "Started " + NAME, "State", "java.lang.Integer",
+
 new Integer(STARTING), new Integer(STARTED));
+
sendNotification(notification);
+
 } catch (Throwable t) {
 state = STOPPED;
 notification = new AttributeChangeNotification
@@ -200,13 +207,6 @@
  new Integer(STARTING), new Integer(STOPPED));
 sendNotification(notification);
 }
-
-state = STARTED;
-notification = new AttributeChangeNotification
-(this, sequenceNumber++, System.currentTimeMillis(),
- "Started " + NAME, "State", "java.lang.Integer",
- new Integer(STARTING), new Integer(STARTED));
-sendNotification(notification);
 
 }

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

[remm]

remm01/09/26 10:48:23

  Modified:catalina/src/share/org/apache/catalina/core
StandardWrapperValve.java
  Log:
  - Error report and dispatching refactoring.
  - The error page dispatching code and the error report code now move to the
two new valves.
  - The wrapper code is now a lot simpler.
  
  Revision  ChangesPath
  1.31  +11 -330   
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardWrapperValve.java
  
  Index: StandardWrapperValve.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardWrapperValve.java,v
  retrieving revision 1.30
  retrieving revision 1.31
  diff -u -r1.30 -r1.31
  --- StandardWrapperValve.java 2001/09/14 20:30:01 1.30
  +++ StandardWrapperValve.java 2001/09/26 17:48:23 1.31
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardWrapperValve.java,v
 1.30 2001/09/14 20:30:01 craigmcc Exp $
  - * $Revision: 1.30 $
  - * $Date: 2001/09/14 20:30:01 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/StandardWrapperValve.java,v
 1.31 2001/09/26 17:48:23 remm Exp $
  + * $Revision: 1.31 $
  + * $Date: 2001/09/26 17:48:23 $
*
* 
*
  @@ -103,7 +103,7 @@
* StandardWrapper container implementation.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.30 $ $Date: 2001/09/14 20:30:01 $
  + * @version $Revision: 1.31 $ $Date: 2001/09/26 17:48:23 $
*/
   
   final class StandardWrapperValve
  @@ -229,7 +229,7 @@
   
   // Create the filter chain for this request
   ApplicationFilterChain filterChain =
  -  createFilterChain(request, servlet);
  +createFilterChain(request, servlet);
   
   // Call the filter chain for this request
   // NOTE: This also calls the servlet's service() method
  @@ -321,12 +321,6 @@
   }
   }
   
  -
  -// Generate a response for the generated HTTP status and message
  -if (throwable == null) {
  -status(request, response);
  -}
  -
   }
   
   
  @@ -442,66 +436,6 @@
   
   
   /**
  - * Handle an HTTP status code or Java exception by forwarding control
  - * to the location included in the specified errorPage object.  It is
  - * assumed that the caller has already recorded any request attributes
  - * that are to be forwarded to this page.  Return true if
  - * we successfully utilized the specified error page location, or
  - * false if the default error report should be rendered.
  - *
  - * @param request The request being processed
  - * @param response The response being generated
  - * @param errorPage The errorPage directive we are obeying
  - */
  -private boolean custom(Request request, Response response,
  -   ErrorPage errorPage) {
  -
  -if (debug >= 1)
  -log("Processing " + errorPage);
  -
  -// Validate our current environment
  -if (!(request instanceof HttpRequest)) {
  -if (debug >= 1)
  -log(" Not processing an HTTP request --> default handling");
  -return (false); // NOTE - Nothing we can do generically
  -}
  -HttpServletRequest hreq =
  -(HttpServletRequest) request.getRequest();
  -if (!(response instanceof HttpResponse)) {
  -if (debug >= 1)
  -log("Not processing an HTTP response --> default handling");
  -return (false); // NOTE - Nothing we can do generically
  -}
  -HttpServletResponse hres =
  -(HttpServletResponse) response.getResponse();
  -
  -try {
  -
  -// Reset the response if possible (else IllegalStateException)
  -hres.reset();
  -
  -// Forward control to the specified location
  -ServletContext servletContext =
  -((Context) container.getParent()).getServletContext();
  -RequestDispatcher rd =
  -servletContext.getRequestDispatcher(errorPage.getLocation());
  -rd.forward(hreq, hres);
  -
  -// Indicate that we have successfully processed this custom page
  -return (true);
  -
  -} catch (Throwable t) {
  -
  -// Report our failure to process this custom page
  -log("Exception Processing " + errorPage, t);
  -return (false);
  -
  -}
  -
  -}
  -
  -
  -/**
* Handle the specified ServletException encountered while processing
* the specified Request to produce the specified Response.  Any
* exceptions that occur during generation of the exception re

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves ErrorDispatcherValve.java

[remm]

remm01/09/26 10:45:52

  Modified:catalina/src/share/org/apache/catalina/valves
ErrorDispatcherValve.java
  Log:
  - Error report and dispatching refactoring.
  - The error page dispatching code is now located in this valve.
  
  Revision  ChangesPath
  1.2   +218 -20   
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorDispatcherValve.java
  
  Index: ErrorDispatcherValve.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorDispatcherValve.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- ErrorDispatcherValve.java 2001/09/25 22:11:49 1.1
  +++ ErrorDispatcherValve.java 2001/09/26 17:45:52 1.2
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorDispatcherValve.java,v
 1.1 2001/09/25 22:11:49 remm Exp $
  - * $Revision: 1.1 $
  - * $Date: 2001/09/25 22:11:49 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorDispatcherValve.java,v
 1.2 2001/09/26 17:45:52 remm Exp $
  + * $Revision: 1.2 $
  + * $Date: 2001/09/26 17:45:52 $
*
* 
*
  @@ -69,6 +69,8 @@
   import java.util.ArrayList;
   import java.util.Enumeration;
   import java.util.Iterator;
  +import javax.servlet.RequestDispatcher;
  +import javax.servlet.ServletContext;
   import javax.servlet.ServletException;
   import javax.servlet.ServletRequest;
   import javax.servlet.ServletResponse;
  @@ -77,6 +79,7 @@
   import javax.servlet.http.HttpServletResponse;
   import org.apache.catalina.Container;
   import org.apache.catalina.Context;
  +import org.apache.catalina.Globals;
   import org.apache.catalina.HttpRequest;
   import org.apache.catalina.HttpResponse;
   import org.apache.catalina.Logger;
  @@ -84,7 +87,9 @@
   import org.apache.catalina.Response;
   import org.apache.catalina.Valve;
   import org.apache.catalina.ValveContext;
  -import org.apache.catalina.connector.HttpResponseWrapper;
  +import org.apache.catalina.Wrapper;
  +import org.apache.catalina.deploy.ErrorPage;
  +import org.apache.catalina.util.RequestUtil;
   import org.apache.catalina.util.StringManager;
   
   
  @@ -99,7 +104,7 @@
*
* @author Remy Maucherat
* @author Craig R. McClanahan
  - * @version $Revision: 1.1 $ $Date: 2001/09/25 22:11:49 $
  + * @version $Revision: 1.2 $ $Date: 2001/09/26 17:45:52 $
*/
   
   public class ErrorDispatcherValve
  @@ -110,9 +115,15 @@
   
   
   /**
  + * The debugging detail level for this component.
  + */
  +protected int debug = 0;
  +
  +
  +/**
* The descriptive information related to this implementation.
*/
  -private static final String info =
  +protected static final String info =
   "org.apache.catalina.valves.ErrorDispatcherValve/1.0";
   
   
  @@ -155,23 +166,17 @@
  ValveContext context)
   throws IOException, ServletException {
   
  -// Skip logging for non-HTTP requests and responses
  -if (!(request instanceof HttpRequest) ||
  -!(response instanceof HttpResponse)) {
  -context.invokeNext(request, response);
  -return;
  -}
  -HttpRequest hrequest = (HttpRequest) request;
  -HttpResponse hresponse = (HttpResponse) response;
  -HttpServletRequest hreq =
  -(HttpServletRequest) hrequest.getRequest();
  -HttpServletResponse hres =
  -(HttpServletResponse) hresponse.getResponse();
  -
   // Perform the request
   context.invokeNext(request, response);
  +
  +ServletRequest sreq = request.getRequest();
  +Throwable t = (Throwable) sreq.getAttribute(Globals.EXCEPTION_ATTR);
   
  -Context mappedContext = request.getContext();
  +if (t != null) {
  +throwable(request, response, t);
  +} else {
  +status(request, response);
  +}
   
   }
   
  @@ -190,6 +195,199 @@
   
   
   // -- Protected Methods
  +
  +
  +/**
  + * Handle the specified Throwable encountered while processing
  + * the specified Request to produce the specified Response.  Any
  + * exceptions that occur during generation of the exception report are
  + * logged and swallowed.
  + *
  + * @param request The request being processed
  + * @param response The response being generated
  + * @param exception The exception that occurred (which possibly wraps
  + *  a root cause exception
  + */
  +protected void throwable(Request request, Response response,
  + Throwable throwable) {
  +
  +Context context = request.

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves ErrorReportValve.java LocalStrings.properties

[remm]

remm01/09/26 10:44:51

  Modified:catalina/src/share/org/apache/catalina/valves
ErrorReportValve.java LocalStrings.properties
  Log:
  - Error report and dispatching refactoring.
  - New (and maybe fancier) error reports.
  - HTML code stolen from the Cocoon 2 error reports.
  - The only thing missing is the response reset code (which should not be 
response.reset,
 but something a bit smarter).
  
  Revision  ChangesPath
  1.2   +192 -17   
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java
  
  Index: ErrorReportValve.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- ErrorReportValve.java 2001/09/25 22:11:49 1.1
  +++ ErrorReportValve.java 2001/09/26 17:44:51 1.2
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java,v
 1.1 2001/09/25 22:11:49 remm Exp $
  - * $Revision: 1.1 $
  - * $Date: 2001/09/25 22:11:49 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/valves/ErrorReportValve.java,v
 1.2 2001/09/26 17:44:51 remm Exp $
  + * $Revision: 1.2 $
  + * $Date: 2001/09/26 17:44:51 $
*
* 
*
  @@ -66,6 +66,9 @@
   
   
   import java.io.IOException;
  +import java.io.PrintWriter;
  +import java.io.StringWriter;
  +import java.io.Writer;
   import java.util.ArrayList;
   import java.util.Enumeration;
   import java.util.Iterator;
  @@ -76,6 +79,7 @@
   import javax.servlet.http.HttpServletRequest;
   import javax.servlet.http.HttpServletResponse;
   import org.apache.catalina.Container;
  +import org.apache.catalina.Globals;
   import org.apache.catalina.HttpRequest;
   import org.apache.catalina.HttpResponse;
   import org.apache.catalina.Logger;
  @@ -84,6 +88,7 @@
   import org.apache.catalina.Valve;
   import org.apache.catalina.ValveContext;
   import org.apache.catalina.connector.HttpResponseWrapper;
  +import org.apache.catalina.util.RequestUtil;
   import org.apache.catalina.util.StringManager;
   
   
  @@ -92,10 +97,14 @@
*
* This Valve should be attached at the Host level, although it will work
* if attached to a Context.
  + * 
  + * HTML code from the Cocoon 2 project.
*
* @author Remy Maucherat
* @author Craig R. McClanahan
  - * @version $Revision: 1.1 $ $Date: 2001/09/25 22:11:49 $
  + * @author mailto:[EMAIL PROTECTED]";>Nicola Ken Barozzi Aisa
  + * @author mailto:[EMAIL PROTECTED]";>Stefano Mazzocchi
  + * @version $Revision: 1.2 $ $Date: 2001/09/26 17:44:51 $
*/
   
   public class ErrorReportValve
  @@ -106,6 +115,12 @@
   
   
   /**
  + * The debugging detail level for this component.
  + */
  +private int debug = 0;
  +
  +
  +/**
* The descriptive information related to this implementation.
*/
   private static final String info =
  @@ -151,24 +166,42 @@
  ValveContext context)
   throws IOException, ServletException {
   
  -// Skip logging for non-HTTP requests and responses
  -if (!(request instanceof HttpRequest) ||
  -!(response instanceof HttpResponse)) {
  -context.invokeNext(request, response);
  -return;
  -}
  -HttpRequest hrequest = (HttpRequest) request;
  -HttpResponse hresponse = (HttpResponse) response;
  -HttpServletRequest hreq =
  -(HttpServletRequest) hrequest.getRequest();
  -HttpServletResponse hres =
  -(HttpServletResponse) hresponse.getResponse();
  -
   // Perform the request
   context.invokeNext(request, response);
   
  +ServletResponse sresp = response.getResponse();
  +if (sresp.isCommitted())
  +return;
  +
  +ServletRequest sreq = request.getRequest();
  +Throwable throwable = 
  +(Throwable) sreq.getAttribute(Globals.EXCEPTION_ATTR);
  +
  +if (throwable != null) {
  +
  +// The response is an error
  +response.setError();
  +
  +// Reset the response (if possible)
  +try {
  +response.getResponse().reset();
  +} catch (IllegalStateException e) {
  +;
  +}
  +
  +ServletResponse sresponse = response.getResponse();
  +if (sresponse instanceof HttpServletResponse)
  +((HttpServletResponse) sresponse).sendError
  +(HttpServletResponse.SC_INTERNAL_SERVER_ERROR);
   
  +}
   
  +try {
  +report(request, response, throwable);
  +} catch (Throwable tt) {
  + 

Re: %=x% expression syntax bug in XML jsp?

[Mark Abbott]

Hi Craig - 

I'm curious whether the expert group has discussed what
might be done in the future about this unfortunate 
aspect of JSP. In what I would think would be a 
really common case in the future, where one wants to 
design an app using clean, readable, and purely XML 
templates (perhaps XHTML for example), but editing by
hand rather than with some JSP savvy tool, the choices
are:

> * Create a custom tag  which just dumps out the
>   corresponding  tag

Wrapping all the tags in every markup of interest is impractical 

> * Write the XML syntax in the way that the JSP compiler expects: 
>
>xpos
>

RE: TC 3.3: getRequestURI()

[Keith Wannamaker]

0x3b = ';'.  Ignacio is right, SessionID doesn't remove the id 
because it is not expecting ; to be encoded.  So now it shows
up in the URI and has the side effect of breaking sessions 
that depend on url rewriting.  But, the spec does say the URL
should be encoded, so I'd rather fix SessionID with this patch.

However, are there other places where TC is manipulating the
URL and assuming it is unencoded?

Keith


| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
| Behalf Of jean-frederic clere
| Sent: Wednesday, September 26, 2001 12:37 PM
| To: [EMAIL PROTECTED]
| Subject: Re: TC 3.3: getRequestURI()
| 
| 
| "Ignacio J. Ortega" wrote:
| > 
| > Probably will be the Session id interceptor that does not understand a
| > encoded jsessionid, not in the mod_jk..
| 
| I was thinking that ap_escape_uri was changing ? into %3b and causing the
| problem...
| 
| > 
| > Saludos ,
| > Ignacio J. Ortega


Index: src/share/org/apache/tomcat/modules/session/SessionId.java
===
RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/session/SessionId.java,v
retrieving revision 1.14
diff -u -b -u -r1.14 SessionId.java
--- src/share/org/apache/tomcat/modules/session/SessionId.java  2001/09/01 00:53:43
 1.14
+++ src/share/org/apache/tomcat/modules/session/SessionId.java  2001/09/26 17:31:22
@@ -123,15 +123,21 @@
}
 
// quick test: if no extra path, no url rewriting.
-   if( request.requestURI().indexOf( ';' ) < 0 )
+   if( request.requestURI().indexOf( ';' ) < 0 &&
+   request.requestURI().indexOf( "%3b" ) < 0)
return 0;

// In case URI rewriting is used, extract the uri and fix
// the request.
-   String sig=";jsessionid=";
+   String decodedSig=";jsessionid=";
+String encodedSig = "%3bjsessionid=";
+String sig = decodedSig;
int foundAt=-1;
String sessionId;

+   if ((foundAt=request.requestURI().indexOf(sig))==-1){
+ sig = encodedSig;
+   }
if ((foundAt=request.requestURI().indexOf(sig))!=-1){
String uri=request.requestURI().toString();
sessionId=uri.substring(foundAt+sig.length());
@@ -140,6 +146,10 @@
 
 // remove from unparsedURI too, if necessary
 if( !request.unparsedURI().isNull() ) {
+sig = decodedSig;
+if (request.unparsedURI().indexOf(sig)==-1) {
+  sig = encodedSig;
+}
 foundAt = request.unparsedURI().indexOf(sig);
 if (foundAt!=-1) {
 uri=request.unparsedURI().toString();


TC 3.3 Release Plan

[Schreibman, David]

Hi,

Is there a schedule update in the works?

I'm working on a migration plan and noticed that the current 3.3 release
plan calls for RC2 code freeze on Sept. 21 and a final code freeze on Sept.
28.

Thanks,

-David

DO NOT REPLY [Bug 3815] - JspServlets produces 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=3815

JspServlets produces NullPointerException

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

Re: TC 3.3 + mod_jk + j_security_check

[Bill Barker]

If the web.xml contains no servlet-mappings, then forwardAll="false" will
generate:
JkMount /myapp/servlet/* ajp13
JkMount /myapp/*.jsp ajp13

and if in addition, the context uses form authorization:
JkMount /myapp/path/to/j_security_check ajp13

You need to set noRoot="false" if you want the ROOT context mappings
generated as well.

Larry has added other options to allow you to specify the directories where
various files go (e.g. mod_jk.so), but I don't remember them off the top of
my head.
- Original Message -
From: "Bojan Smojver" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, September 25, 2001 7:51 PM
Subject: Re: TC 3.3 + mod_jk + j_security_check


> What if the only mapping is for instance:
>
> JkMount /*.jsp ajp13
>
> Will it still work?
>
> Bojan
>
> Bill Barker wrote:
> >
> > This is now implemented automatically in the ApacheConfig module.  By
> > default it does:
> > JkMount /myapp/* ajp13
> >
> > Turning this off (via forwardAll="false"), then it outputs all of the
> > defined mappings (including j_security_check for form auth contexts).
> > - Original Message -
> > From: "Bojan Smojver" <[EMAIL PROTECTED]>
> > To: "Tomcat Dev List" <[EMAIL PROTECTED]>
> > Sent: Tuesday, September 25, 2001 5:34 PM
> > Subject: TC 3.3 + mod_jk + j_security_check
> >
> > > Unless this is now implemented automatically in mod_jk, I think it
would
> > > be worth mentioning in mod_jk HOWTO about the need to JKMount
> > > j_security_check when form authentication is used in applications.
> > >
> > > I think I should be able to fake a paragraph about it (with examples).
> > >
> > > Bojan
> > >
> > >
> >
> > **
> >
> > This message is intended only for the use of the person(s) listed above
> > as the intended recipient(s), and may contain information that is
> > PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient,
> > you may not read, copy, or distribute this message or any attachment.
> > If you received this communication in error, please notify us
immediately
> > by e-mail and then delete all copies of this message and any
attachments.
> >
> > In addition you should be aware that ordinary (unencrypted) e-mail sent
> > through the Internet is not secure. Do not send confidential or
sensitive
> > information, such as social security numbers, account numbers, personal
> > identification numbers and passwords, to us via ordinary (unencrypted)
> > e-mail.
>
>


**

This message is intended only for the use of the person(s) listed above 
as the intended recipient(s), and may contain information that is 
PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, 
you may not read, copy, or distribute this message or any attachment.  
If you received this communication in error, please notify us immediately 
by e-mail and then delete all copies of this message and any attachments.


In addition you should be aware that ordinary (unencrypted) e-mail sent 
through the Internet is not secure. Do not send confidential or sensitive 
information, such as social security numbers, account numbers, personal 
identification numbers and passwords, to us via ordinary (unencrypted) 
e-mail. 

Re: TC 3.3: getRequestURI()

[jean-frederic clere]

"Ignacio J. Ortega" wrote:
> 
> Probably will be the Session id interceptor that does not understand a
> encoded jsessionid, not in the mod_jk..

I was thinking that ap_escape_uri was changing ? into %3b and causing the
problem...

> 
> Saludos ,
> Ignacio J. Ortega
> 
> > -Mensaje original-
> > De: Keith Wannamaker [mailto:[EMAIL PROTECTED]]
> > Enviado el: miércoles 26 de septiembre de 2001 16:55
> > Para: [EMAIL PROTECTED]
> > Asunto: RE: TC 3.3: getRequestURI()
> >
> >
> > I'm not sure I understand why the session id was not
> > also showing up with r->unparsed_uri.  I'm doing some
> > experimenting now..
> >
> > Keith
> >
> > |/login/login.vm%3bjsessionid=q95pbsuof1
> >
> > | Probably not.  It's a side of effect of the last change which was
> > | to use "s->req_uri = ap_escape_uri(r->pool, r->uri);". This looks
> > | like a good example of a re-encoded URI not being equal to the
> > | original.
> > |
> > | Thanks for noticing this.
> > |
> > | Larry
> > |
> >

Re: %=x% expression syntax bug in XML jsp?

[Craig R. McClanahan]

On Wed, 26 Sep 2001, Uther, James wrote:

> Date: Wed, 26 Sep 2001 14:30:21 +0300
> From: "Uther, James" <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: %=x% expression syntax bug in XML jsp?
>
> Hi All,
>
> My reading of ParserXJspSaxHandler.java suggests that the shorthand
> expression syntax for jsp1.3 xml documents (%=x%) is not handled in
> 'uninterpreted' tags (ie: tags that are not taglibs or jsp:).
>
> Is this a bug or per spec? My reading of the spec suggests it's a bug, but i
> could well be missing something.
>

My understanding (confirmed by talking with the JSP spec lead) is that
this is not a bug, but is operating per design.

If you made parsing "%=x%" work in template text (which is what the JSP
compiler thinks you are processing when you're not inside a custom tag),
then users would have to escape this kind of character string
*everywhere*, not just in what looks like a tag attribute.

Also, there's no requirement that the template text itself look like HTML
or XML (i.e. it doesn't have to have a syntax that looks like elements
with attributes).  So, the JSP compiler cannot attach any semantic
significance to what "looks like" a tag but is not a tag it recognizes
(i.e. a built-in  tag or a defined custom tag).

> The problem can be illustrated as follows:
>
> take this jsp page
> ---
> 
>
> http://java.sun.com/JSP/Page";>
> 
> 
>
>   
>   
>x="%=xpos%">t
>   
> 
> ---
>
> My problem is that the
>x="%=xpos%"
> expression is not expanded (in tomcat 4.0), so the generated SVG document
> looks like
>
> 
>   test
> 
>

That's correct, because  is not recognized as a custom tag.
Choices:

* Create a custom tag  which just dumps out the
  corresponding  tag

* Write the XML syntax in the way that the JSP compiler expects:


xpos

DO NOT REPLY [Bug 3839] New: - Problem bookmarking login page

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3839

Problem bookmarking login page

   Summary: Problem bookmarking login page
   Product: Tomcat 4
   Version: 4.0 Final
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: Major
  Priority: Other
 Component: Webapps
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


I have a web application that uses form based authentication.

if I go to a protected page for example:
http://myhost/myapp/index.html
then I get the authentication form:
http://myhost/myapp/login.jsp
I fill it up, and submit and I get authenticated and the page
http://myhost/myapp/index.html
is properly shown.


However, if instead of trying to go to a protected resource, I try to go 
directly to the login.jsp page, and that is pretty common since some people 
like to bookmark the login page, then this is what happens:

I go to the login page:
http://myhost/myapp/login.jsp

the login page gets displayed properly. but if I fill it up and submit, the 
browser gets redirected to this address:

http://myhost/myapp/null
and the following error is shown on the browser:
HTTP Status 404 - /null
The requested resource (/null) is not available. 

The behavior that I would like to see is that the default page for the web 
application be shown.

I think this is what is happening:
if I go to a protected resource the url gets saved somewhere in the session
then after I submit the login information, the server redirects the browers to 
the saved location.

But if I go directly to the login page, then there is no url that failed the 
security constraints, and nothing is saved. After I submit, it tries to go to 
whatever is saved (null in this case) and since there is no page named null an 
error is shown. What is needed is an extra check somewhere that says: if the 
saved location is null, then go to the default webapp page.

RE: TC 3.3: getRequestURI()

[Ignacio J. Ortega]

Probably will be the Session id interceptor that does not understand a
encoded jsessionid, not in the mod_jk..



Saludos ,
Ignacio J. Ortega


> -Mensaje original-
> De: Keith Wannamaker [mailto:[EMAIL PROTECTED]]
> Enviado el: miércoles 26 de septiembre de 2001 16:55
> Para: [EMAIL PROTECTED]
> Asunto: RE: TC 3.3: getRequestURI()
> 
> 
> I'm not sure I understand why the session id was not
> also showing up with r->unparsed_uri.  I'm doing some
> experimenting now..
> 
> Keith
> 
> |/login/login.vm%3bjsessionid=q95pbsuof1
> 
> | Probably not.  It's a side of effect of the last change which was
> | to use "s->req_uri = ap_escape_uri(r->pool, r->uri);". This looks
> | like a good example of a re-encoded URI not being equal to the
> | original.
> | 
> | Thanks for noticing this.
> | 
> | Larry
> | 
> 

Re: tomcat hangging problem

[joseph . vallot]

[EMAIL PROTECTED] wrote:

> > > My bet is that this is related with the VM/libraries. It can of course be
> > > a bug in tomcat, like a deadlock or something - but then it would fail
> > > on all SMP machines.
> >
> > I think like this.  A strange thing I noticed yesterday: on "hangging
> > machines", running with "-Xms100m -Xmx200m" seems to hide problem (I
> > guess hang would occur later, but a less-than-10-minutes process ran all
> > night long (and was running till somebody (!$*ù#@) reboot)).
>
> Aha. I would bet something is wrong in the GC or memory allocator.
>
> Are you running the _latest_ version of the VM ? Can you file a bug
> on this ?

I do think so (but if you tried someday to find something in IBM
website, you know how it is hard to find something!):
./java -fullversion
java full version "J2RE 1.3.0 IBM build ca130-20010615"

where do you expect me to file that bug? ibm? wow!
I did open a call, but via our internal helpdesk, and then via somebody
@ibm.com who does not know anything about java and aix :-( well, it
seems problem has reached more concerned persons, but I really don't
know who :}

> Does it happen with any servlet ( say HelloWorld ) or only with your
> application ? Can you create a simple servlet ( that eventually does
> some allocation - in case the bug is in the GC ), and see if it
> can reproduce the problem ?

well, I did write a sample that shows problem (I can tell more or send
code), but after a couple of hours running: I could make it alloc much
more when looping...  hope this could make it hang faster.

--
Joseph




This message and any attachments (the "message") is
intended solely for the addressees and is confidential. 
If you receive this message in error, please delete it and 
immediately notify the sender. Any use not in accord with 
its purpose, any dissemination or disclosure, either whole 
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message. 
BNP PARIBAS (and its subsidiaries) shall (will) not 
therefore be liable for the message if modified. 

-

Ce message et toutes les pieces jointes (ci-apres le 
"message") sont etablis a l'intention exclusive de ses 
destinataires et sont confidentiels. Si vous recevez ce 
message par erreur, merci de le detruire et d'en avertir 
immediatement l'expediteur. Toute utilisation de ce 
message non conforme a sa destination, toute diffusion 
ou toute publication, totale ou partielle, est interdite, sauf 
autorisation expresse. L'internet ne permettant pas 
d'assurer l'integrite de ce message, BNP PARIBAS (et ses
filiales) decline(nt) toute responsabilite au titre de ce 
message, dans l'hypothese ou il aurait ete modifie.

Re: [J-T-C] ajp13 works from jt to jtc ?

[cmanolache]

On Wed, 26 Sep 2001, GOMEZ Henri wrote:

> Hi to all,
>
> Did someone is planning to port ajp13 java
> changes done in TC 3.3 back to J-T-C ?
>
> If not I'll do it but I want to avoid
> duplicate works ...

Hi Henri,

I do plan to do that - haven't started yet, I was planning
to start after 3.3 final is labeled.



Costin

Re: Réf. : Re: tomcat hangging problem

[cmanolache]

On Wed, 26 Sep 2001 [EMAIL PROTECTED] wrote:

> > I assume this is happening only on SMP machines ( i.e. with multiple
> > CPUs).
>
> that is what we suspect here :-(
> unfortunately, we only run on SMP AIX machines :-((
> dev is done on NT boxes (or whatever, actually), but production machines
> are rs6000 boxes (2 to 8 processors).

Nice :-)

> > My bet is that this is related with the VM/libraries. It can of course be
> > a bug in tomcat, like a deadlock or something - but then it would fail
> > on all SMP machines.
>
> I think like this.  A strange thing I noticed yesterday: on "hangging
> machines", running with "-Xms100m -Xmx200m" seems to hide problem (I
> guess hang would occur later, but a less-than-10-minutes process ran all
> night long (and was running till somebody (!$*ù#@) reboot)).

Aha. I would bet something is wrong in the GC or memory allocator.

Are you running the _latest_ version of the VM ? Can you file a bug
on this ?

Does it happen with any servlet ( say HelloWorld ) or only with your
application ? Can you create a simple servlet ( that eventually does
some allocation - in case the bug is in the GC ), and see if it
can reproduce the problem ?

Costin

RE: TC 3.3: getRequestURI()

[Keith Wannamaker]

I'm not sure I understand why the session id was not
also showing up with r->unparsed_uri.  I'm doing some
experimenting now..

Keith

|/login/login.vm%3bjsessionid=q95pbsuof1

| Probably not.  It's a side of effect of the last change which was
| to use "s->req_uri = ap_escape_uri(r->pool, r->uri);". This looks
| like a good example of a re-encoded URI not being equal to the
| original.
| 
| Thanks for noticing this.
| 
| Larry
| 

Re: TC 3.3: getRequestURI()

[jean-frederic clere]

Larry Isaacs wrote:
> 
> > -Original Message-
> > From: Bojan Smojver [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, September 26, 2001 7:41 AM
> > To: Tomcat Dev List
> > Subject: TC 3.3: getRequestURI()
> >
> >
> > The latest TC 3.3 CVS with its mod_jk, gives an encoded URI, together
> > with the session ID on HttpServletRequest.getRequestURI().
> >
> > Example:
> >
> > /login/login.vm%3bjsessionid=q95pbsuof1
> >
> > Previously, jsessionid wasn't there. The change was
> > intentional, right?
> 
> Probably not.  It's a side of effect of the last change which was
> to use "s->req_uri = ap_escape_uri(r->pool, r->uri);". This looks
> like a good example of a re-encoded URI not being equal to the
> original.

The 2.3 spec's says:
+++
getRequestURI() public java.lang.String getRequestURI() Returns the part of this
request's URL from the protocol name up to the query string in the first line of
the HTTP request. The web container does not decode this String.
+++
What about reversing the change?

> 
> Thanks for noticing this.
> 
> Larry

RE: TC 3.3: getRequestURI()

[Larry Isaacs]

> -Original Message-
> From: Bojan Smojver [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 26, 2001 7:41 AM
> To: Tomcat Dev List
> Subject: TC 3.3: getRequestURI()
> 
> 
> The latest TC 3.3 CVS with its mod_jk, gives an encoded URI, together
> with the session ID on HttpServletRequest.getRequestURI().
> 
> Example:
> 
> /login/login.vm%3bjsessionid=q95pbsuof1
> 
> Previously, jsessionid wasn't there. The change was 
> intentional, right?

Probably not.  It's a side of effect of the last change which was
to use "s->req_uri = ap_escape_uri(r->pool, r->uri);". This looks
like a good example of a re-encoded URI not being equal to the
original.

Thanks for noticing this.

Larry

Re: Watchdog-4.0 PB

[jean-frederic clere]

"Clere, Jean-Frederic" wrote:
> 
> Hi,
> 
> I have a problem running watchdog:
> 
> +++
> servlet:
> 
> execute:
>  [java] Buildfile: conf/servlet-gtest.xml
>  [java]
>  [java] gtestservlet-test:
>  [java]
>  [java] Total time: 1 second
>  [java] [gtest] Error setting project in class
> org.apache.tomcat.task.GTest
>  [java]
>  [java] BUILD FAILED
>  [java]
>  [java] /home/jakarta/jakarta-watchdog-4.0/dist/conf/servlet-gtest.xml:22:
> java.lang.NoSuchMethodException
>  [java] Java Result: 1
> 
> BUILD SUCCESSFUL
> 
> Total time: 2 seconds
> +++
> I am using ant-1.4.
> 
> Any hints?

It works with ant-1.3 ;-)

> 
> Cheers
> 
> Jean-frederic

Réf. : Re: tomcat hangging problem

[joseph . vallot]

[EMAIL PROTECTED] wrote:

> I assume this is happening only on SMP machines ( i.e. with multiple
> CPUs).

that is what we suspect here :-(
unfortunately, we only run on SMP AIX machines :-((
dev is done on NT boxes (or whatever, actually), but production machines
are rs6000 boxes (2 to 8 processors).


> My bet is that this is related with the VM/libraries. It can of course be
> a bug in tomcat, like a deadlock or something - but then it would fail
> on all SMP machines.

I think like this.  A strange thing I noticed yesterday: on "hangging
machines", running with "-Xms100m -Xmx200m" seems to hide problem (I
guess hang would occur later, but a less-than-10-minutes process ran all
night long (and was running till somebody (!$*ù#@) reboot)).


> Could you check with the 'latest' 1.3.0 and make sure you have all the
> patches installed  ( pthred.so, etc ). Also, check the version of the
> libraries between the AIX machines that work and those that don't.

I am trying to 'diff' systems, but it's not that easy on aix :-(


> If you get a core dump - again, this is a clear sign something is wrong
> with the VM/libraries. A java program shouldn't be able to coredump
> regardless of the code inside ( unless JNI is used ), and there's nothing
> we can do in tomcat ( even if we find a workaround, some user code can
> crash the server as well ).

I do agree with that: I do not expect any core from a jvm :-(


> Is anyone else running SMP machines ? I remember long time ago a problem
> on linux/smp, but was solved by using a newer VM.


yes, it would help :} anybody ?

> Costin

--
Joseph Vallot


> >
> > Here is the description of current problem I try to solve...
> > I have already mailed to tomcat-user, but since nobody has a beginning
> > of an answer, and since we can't go on production launch anymore, I try
> > here.
> >
> > environment:
> > - AIX 4.3.3 SMP,
> > - JRE 1.2.2 (several builds), then 1.3.0
> > - tomcat 3.2.1, 3.2.3 then 3.3.b2 (sorry, did not try 3.3.rc1 yet!)
> >
> > problem is: tomcat "hangs" after some time (may be 3 minutes or some
> > hours). I mean tomcat is running ("ps" shows it), but no answer is
> > received to requests when tomcat hangs (telnetting it with a http get
> > request results in no response). Even a kill -3 does nothing.
> >
> > Strangely, problem occurs only on _some_ of AIX 4.3.3 machines where I run
> > tomcat.
> > Some machines, with same jre/tomcat/code, run with no problem (well,
> > maybe problem would occur after a much longer time, I don't really know).
> > And I did not met that on winNT4 (with a Sun jdk: I got to try with
> > an ibm jvm).
> > Note that I got a javacore twice, if somebody can interpret it...
> >
> > I wrote a simple servlet which shows tomcat hangging, if that can help:
> > a singleton deals with doGet: first time it launches 'n' threads, each of
> > them will http-request same singleton every 't' seconds and print result to stdout.
> > other request to singleton only prints text/plain string to response's writer.
> >
> > Thanks
> > --
> > Joseph Vallot




This message and any attachments (the "message") is
intended solely for the addressees and is confidential. 
If you receive this message in error, please delete it and 
immediately notify the sender. Any use not in accord with 
its purpose, any dissemination or disclosure, either whole 
or partial, is prohibited except formal approval. The internet
can not guarantee the integrity of this message. 
BNP PARIBAS (and its subsidiaries) shall (will) not 
therefore be liable for the message if modified. 

-

Ce message et toutes les pieces jointes (ci-apres le 
"message") sont etablis a l'intention exclusive de ses 
destinataires et sont confidentiels. Si vous recevez ce 
message par erreur, merci de le detruire et d'en avertir 
immediatement l'expediteur. Toute utilisation de ce 
message non conforme a sa destination, toute diffusion 
ou toute publication, totale ou partielle, est interdite, sauf 
autorisation expresse. L'internet ne permettant pas 
d'assurer l'integrite de ce message, BNP PARIBAS (et ses
filiales) decline(nt) toute responsabilite au titre de ce 
message, dans l'hypothese ou il aurait ete modifie.

TC 3.3: getRequestURI()

[Bojan Smojver]

The latest TC 3.3 CVS with its mod_jk, gives an encoded URI, together
with the session ID on HttpServletRequest.getRequestURI().

Example:

/login/login.vm%3bjsessionid=q95pbsuof1

Previously, jsessionid wasn't there. The change was intentional, right?

Bojan

%=x% expression syntax bug in XML jsp?

[Uther, James]

Hi All,

My reading of ParserXJspSaxHandler.java suggests that the shorthand
expression syntax for jsp1.3 xml documents (%=x%) is not handled in
'uninterpreted' tags (ie: tags that are not taglibs or jsp:).

Is this a bug or per spec? My reading of the spec suggests it's a bug, but i
could well be missing something.

The problem can be illustrated as follows:

take this jsp page
---


http://java.sun.com/JSP/Page";>





t


---

My problem is that the 
   x="%=xpos%" 
expression is not expanded (in tomcat 4.0), so the generated SVG document
looks like


  test


cheers,

james

-- 
James Uther   www.F-Secure.com
Senior Software Engineer  F-Secure Corporation  

Securing the Mobile Enterprise

Watchdog-4.0 PB

[jean-frederic clere]

Hi,

I have a problem running watchdog:

+++
servlet:
 
execute:
 [java] Buildfile: conf/servlet-gtest.xml
 [java]
 [java] gtestservlet-test:
 [java]
 [java] Total time: 1 second
 [java] [gtest] Error setting project in class
org.apache.tomcat.task.GTest
 [java]
 [java] BUILD FAILED
 [java]
 [java] /home/jakarta/jakarta-watchdog-4.0/dist/conf/servlet-gtest.xml:22:
java.lang.NoSuchMethodException
 [java] Java Result: 1
 
BUILD SUCCESSFUL
 
Total time: 2 seconds
+++
I am using ant-1.4.

Any hints?

Cheers

Jean-frederic