Re: [Tomcat 4] Initializing PRNGs for Session Identifiers

[Bojan Smojver]

"Craig R. McClanahan" wrote:
> 
> Christopher Cain has raised some concerns (both in private email and
> publicly on this list) regarding the initialization of pseudo random
> number generators (PRNGs) used to calculate session id values.  We need to
> have a quick discussion about this, to determine whether we want to change
> the current approach.  The purpose of this particular mail thread is to
> decide what to do for Tomcat 4 -- developers on the other versions are
> welcome to chip in and describe what they do, and what their preferences
> might be as well.
> 
> BACKGROUND:
> 
> Tomcat 4 uses an instance of java.security.SecureRandom to generate
> session identifiers for a particular session.  The instance is initialized
> the first time (after Tomcat is started, or after a webapp is restarted)
> that a session identifier is requested.  The issue at hand for this
> discussion is the mechanism used to seed the random number generator
> instance.  (If the seed is predicatable, then the entire sequence of
> session ids that will be generated is also predictable, which is a nasty
> security risk.)
> 
> The default seeding algorithm (i.e. if you do not seed it yourself)
> gathers system entropy information based on current system activity.  The
> good news is that this tends to create a very random starting value.  The
> bad news is that it can take many seconds to calculate, with noticeable
> impact on the response time for the first session-related request.
> 
> To ameliorate this, Tomcat 4 seeds the random number generator based on a
> combination of:
> 
> * The current timestamp (in milliseconds) when the first request for
>   a session id for this web app occurs
> 
> * An optional entropy-increasing string value that you can specify
>   in your "conf/server.xml" file, like this:
> 
> 
> ...
> 
> ...
> 
> 
>   If no entropy property is specified, a default (and therefore
>   predictable) entropy string is used.
> 
> This approach has the advantage of seeding much more quickly, but the
> disadvantage that the sequence of session ids is potentially predicatable.
> Predicatability is *much* easier if an attacker can manage to read
> "conf/server.xml" (although, as I've pointed out to Christopher, security
> of your session ids is the *least* of your problems if this happens).  The
> current approach is also the one that was recommended the last time this
> issue was raised (when Tomcat 3.1 had a *very* weak approach to
> calculating session ids).
> 
> The decision we face, of course, is whether or not to change this.  A
> complicating factor is that some platforms offer facilities (such as
> /dev/random) to take advantage of entropy gathered by the OS -- but such
> things are obviously not portable, so they cannot be relied on to satisfy
> all requiremnts.
> 
> It seems to me we have a number of overlapping decisions.  My thoughts are
> after each decision area -- I'm looking for input from others.
> 
> DECISION 1 - WHAT SEEDING MECHANISMS SHOULD WE SUPPORT?
> 
> (1A) Default seeding of java.security.SecureRandom (time consuming but
>  reasonably secure)
> 
> (1B) Current mechanism of timestamp + entropy string (very fast,
>  potentially not secure)
> 
> (1C) Plug-in seeding API to allow use of platform-specific algorithms
>  if desired
> 
> Currently, Tomcat 4 only supports (1B).  It certainly makes sense to offer
> (1A) as well.  Offering (1C) is more work, but is not conceptually
> difficult.
> 
> DECISION 2 - WHAT SEEDING MECHANISM SHOULD BE THE DEFAULT?
>   (assumes, of course, that we support them both)
> 
> (2A) Default seeding
> 
> (2B) Current mechanism
> 
> Currently, (2B) is supported, because only (1B) is supported.  This is
> likely to be a much more involved discussion that Decision 1.  I could be
> persuaded to (2A), but I'm not really certain that this is an issue in the
> majority of Tomcat installations -- if we allow people who care about it
> to choose (2A), but not make people suffer when they don't feel session id
> predicatability is an issue, that seems like a reasonable approach.
> 
> DECISION 3 - WHAT PLUG-INS FOR (1C) SHOULD WE OFFER AS STANDARD?
> 
> (3A) Unix systems /dev/random
> 
> (3B) Unix systems /dev/urandom
> 
> (3C) ???
> 
> Currently, none of these are supported.
> 
> Craig McClanahan

Some of that stuff has been implemented in Tomcat 3.3 (3.x?). The file
SessionIdGenerator.java should be able to explain how TC 3.3 handles
those issues.

>From memory, there was a discussion about using /dev/urandom on this
list in relation to Tomcat 3.x (search for '/dev/urandom' and/or
'SessionIdGenerator' on this list) and also the differences of it as
compared to /dev/random. Doug Barnes nicely explained a lot of that
stuff. This can also be helpful.

In practice, having /dev/urandom helping with session ID's is essential.
It speeds up Tomcat significantly.

Also, if you inspect the above mentioned code, you'll notice that if
platform s

[DO NOT REPLY: Bug 3578] Manager Applications broken

[bugzilla]

PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT
ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW
AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE
DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL
BE LOST SOMEWHERE.

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

*** shadow/3578 Wed Sep 12 21:57:45 2001
--- shadow/3578.tmp.29175   Wed Sep 12 22:09:40 2001
***
*** 2,9 
  | Manager Applications broken|
  ++
  |Bug #: 3578Product: Tomcat 4|
! |   Status: NEW Version: 4.0 Release Candidate 1 |
! |   Resolution:Platform: PC  |
  | Severity: MajorOS/Version: Windows NT/2K   |
  | Priority: Other Component: Webapps |
  ++
--- 2,9 
  | Manager Applications broken|
  ++
  |Bug #: 3578Product: Tomcat 4|
! |   Status: RESOLVEDVersion: 4.0 Release Candidate 1 |
! |   Resolution: DUPLICATE  Platform: PC  |
  | Severity: MajorOS/Version: Windows NT/2K   |
  | Priority: Other Component: Webapps |
  ++
***
*** 64,67 
  --- Additional Comments From [EMAIL PROTECTED]  2001-09-12 21:57 ---
  -Also, the log that registered the stack trace was catalina log.  
  -No "authentication popup" appeared in my browser
! -All other logs were blank
--- 64,74 
  --- Additional Comments From [EMAIL PROTECTED]  2001-09-12 21:57 ---
  -Also, the log that registered the stack trace was catalina log.  
  -No "authentication popup" appeared in my browser
! -All other logs were blank
! 
! --- Additional Comments From [EMAIL PROTECTED]  2001-09-12 22:09 ---
! This is a bug with the MemoryRealm which was introduced just before releasing 
! RC1. This has been fixed almost immediately after the RC1 release. RC2 (which 
! will be released later today or tomorrow) will have the fix.
! 
! *** This bug has been marked as a duplicate of 3524 ***

Re: [Tomcat 4] Initializing PRNGs for Session Identifiers

[Remy Maucherat]

> BACKGROUND:

> * An optional entropy-increasing string value that you can specify
>   in your "conf/server.xml" file, like this:
>
> 
> ...
> 
> ...
> 
>
>   If no entropy property is specified, a default (and therefore
>   predictable) entropy string is used.
>
> This approach has the advantage of seeding much more quickly, but the
> disadvantage that the sequence of session ids is potentially predicatable.
> Predicatability is *much* easier if an attacker can manage to read
> "conf/server.xml" (although, as I've pointed out to Christopher, security
> of your session ids is the *least* of your problems if this happens).  The
> current approach is also the one that was recommended the last time this
> issue was raised (when Tomcat 3.1 had a *very* weak approach to
> calculating session ids).
>
> The decision we face, of course, is whether or not to change this.  A
> complicating factor is that some platforms offer facilities (such as
> /dev/random) to take advantage of entropy gathered by the OS -- but such
> things are obviously not portable, so they cannot be relied on to satisfy
> all requiremnts.
>
> It seems to me we have a number of overlapping decisions.  My thoughts are
> after each decision area -- I'm looking for input from others.
>
>
> DECISION 1 - WHAT SEEDING MECHANISMS SHOULD WE SUPPORT?
>
> (1A) Default seeding of java.security.SecureRandom (time consuming but
>  reasonably secure)
>
> (1B) Current mechanism of timestamp + entropy string (very fast,
>  potentially not secure)

I think the current mechanism is good enough. With a carefully chosen
secret, I don't see how that could be cracked, and if it turns out it's
actually doable, it must be a lot easier to try to find another way in.

Also, maybe we can find a way to slightly improve the randomness of the
seed.

> (1C) Plug-in seeding API to allow use of platform-specific algorithms
>  if desired

The plugin mechanism looks like a very good idea, and we should implement it
in the next maintenance release of Tomcat 4.

> Currently, Tomcat 4 only supports (1B).  It certainly makes sense to offer
> (1A) as well.  Offering (1C) is more work, but is not conceptually
> difficult.
>
>
> DECISION 2 - WHAT SEEDING MECHANISM SHOULD BE THE DEFAULT?
>   (assumes, of course, that we support them both)
>
> (2A) Default seeding
>
> (2B) Current mechanism
>
> Currently, (2B) is supported, because only (1B) is supported.  This is
> likely to be a much more involved discussion that Decision 1.  I could be
> persuaded to (2A), but I'm not really certain that this is an issue in the
> majority of Tomcat installations -- if we allow people who care about it
> to choose (2A), but not make people suffer when they don't feel session id
> predicatability is an issue, that seems like a reasonable approach.

The security level provided by 2B seems enough in 99% of the cases, so I
would leave it as the default.

> DECISION 3 - WHAT PLUG-INS FOR (1C) SHOULD WE OFFER AS STANDARD?
>
> (3A) Unix systems /dev/random
>
> (3B) Unix systems /dev/urandom
>
> (3C) ???
>
> Currently, none of these are supported.

We probably will have to start a modules repository to put that kind of
additional features.

Remy

[DO NOT REPLY: Bug 3578] Manager Applications broken

[bugzilla]

PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT
ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW
AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE
DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL
BE LOST SOMEWHERE.

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

*** shadow/3578 Wed Sep 12 21:56:40 2001
--- shadow/3578.tmp.29153   Wed Sep 12 21:57:45 2001
***
*** 59,62 
  (HttpProcessor.java:1005)
at org.apache.catalina.connector.http.HttpProcessor.run
  (HttpProcessor.java:1098)
!   at java.lang.Thread.run(Unknown Source)
--- 59,67 
  (HttpProcessor.java:1005)
at org.apache.catalina.connector.http.HttpProcessor.run
  (HttpProcessor.java:1098)
!   at java.lang.Thread.run(Unknown Source)
! 
! --- Additional Comments From [EMAIL PROTECTED]  2001-09-12 21:57 ---
! -Also, the log that registered the stack trace was catalina log.  
! -No "authentication popup" appeared in my browser
! -All other logs were blank

[DO NOT REPLY: Bug 3578] New: Manager Applications broken

[bugzilla]

PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT
ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW
AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE
DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL
BE LOST SOMEWHERE.

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

*** shadow/3578 Wed Sep 12 21:56:40 2001
--- shadow/3578.tmp.29145   Wed Sep 12 21:56:40 2001
***
*** 0 
--- 1,62 
+ ++
+ | Manager Applications broken|
+ ++
+ |Bug #: 3578Product: Tomcat 4|
+ |   Status: NEW Version: 4.0 Release Candidate 1 |
+ |   Resolution:Platform: PC  |
+ | Severity: MajorOS/Version: Windows NT/2K   |
+ | Priority: Other Component: Webapps |
+ ++
+ |  Assigned To: [EMAIL PROTECTED]|
+ |  Reported By: [EMAIL PROTECTED]|
+ |  CC list: Cc:  |
+ ++
+ |  URL: http://localhost:8080/manager/list   |
+ ++
+ |  DESCRIPTION   |
+ I was able to set up the manager application for Beta 8, but RC1 seems to be 
+ broken.  I get a NullPointerException [stack trace included below].  I tried 
+ reinstalling into a new directory just in case I had libaray miss-matches, and 
+ I cleared out my system's classpath all together. [I used the .exe installation]
+ 
+ Thanks!
+ 
+ -Mike
+ Stacktrace:
+ java.lang.NullPointerException
+   at org.apache.catalina.realm.MemoryRealm.authenticate
+ (MemoryRealm.java:213)
+   at org.apache.catalina.authenticator.BasicAuthenticator.authenticate
+ (BasicAuthenticator.java:161)
+   at org.apache.catalina.authenticator.AuthenticatorBase.invoke
+ (AuthenticatorBase.java:493)
+   at org.apache.catalina.core.StandardPipeline.invokeNext
+ (StandardPipeline.java:564)
+   at org.apache.catalina.core.StandardPipeline.invoke
+ (StandardPipeline.java:472)
+   at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
+   at org.apache.catalina.core.StandardContext.invoke
+ (StandardContext.java:2366)
+   at org.apache.catalina.core.StandardHostValve.invoke
+ (StandardHostValve.java:164)
+   at org.apache.catalina.core.StandardPipeline.invokeNext
+ (StandardPipeline.java:566)
+   at org.apache.catalina.valves.AccessLogValve.invoke
+ (AccessLogValve.java:462)
+   at org.apache.catalina.core.StandardPipeline.invokeNext
+ (StandardPipeline.java:564)
+   at org.apache.catalina.core.StandardPipeline.invoke
+ (StandardPipeline.java:472)
+   at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
+   at org.apache.catalina.core.StandardEngineValve.invoke
+ (StandardEngineValve.java:163)
+   at org.apache.catalina.core.StandardPipeline.invokeNext
+ (StandardPipeline.java:566)
+   at org.apache.catalina.core.StandardPipeline.invoke
+ (StandardPipeline.java:472)
+   at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
+   at org.apache.catalina.connector.http.HttpProcessor.process
+ (HttpProcessor.java:1005)
+   at org.apache.catalina.connector.http.HttpProcessor.run
+ (HttpProcessor.java:1098)
+   at java.lang.Thread.run(Unknown Source)

Ajp13Interceptor

[Bojan Smojver]

I've notice that the most recent Ajp13Interceptor prints something like
this into log files:

--
Ajp13Request: Read:
formid=order&email=a%40aa&customer=a&address=a&city=a&state=a&postcode=a&country=Bermuda&shipping=air&product=Pooh+Cosmology+and+the+Quantum+Physics&quantity=2.0&product=Pooh+Geology+and+the+History+of+Life&quantity=&recalculate=Recalculate
--

After inspecting the code, it turns out that the output is the result of
the call in line 243 to method d(). This is controlled by:

--
private static final int dL=10;
--

How do I disable that from within server.xml (or whichever other conf
file), rather then by modifying the code? For debugging it's OK, but it
creates a lot of noise in the log files...

Bojan

[Tomcat 4] Initializing PRNGs for Session Identifiers

[Craig R. McClanahan]

Christopher Cain has raised some concerns (both in private email and
publicly on this list) regarding the initialization of pseudo random
number generators (PRNGs) used to calculate session id values.  We need to
have a quick discussion about this, to determine whether we want to change
the current approach.  The purpose of this particular mail thread is to
decide what to do for Tomcat 4 -- developers on the other versions are
welcome to chip in and describe what they do, and what their preferences
might be as well.

BACKGROUND:

Tomcat 4 uses an instance of java.security.SecureRandom to generate
session identifiers for a particular session.  The instance is initialized
the first time (after Tomcat is started, or after a webapp is restarted)
that a session identifier is requested.  The issue at hand for this
discussion is the mechanism used to seed the random number generator
instance.  (If the seed is predicatable, then the entire sequence of
session ids that will be generated is also predictable, which is a nasty
security risk.)

The default seeding algorithm (i.e. if you do not seed it yourself)
gathers system entropy information based on current system activity.  The
good news is that this tends to create a very random starting value.  The
bad news is that it can take many seconds to calculate, with noticeable
impact on the response time for the first session-related request.

To ameliorate this, Tomcat 4 seeds the random number generator based on a
combination of:

* The current timestamp (in milliseconds) when the first request for
  a session id for this web app occurs

* An optional entropy-increasing string value that you can specify
  in your "conf/server.xml" file, like this:


...

...


  If no entropy property is specified, a default (and therefore
  predictable) entropy string is used.

This approach has the advantage of seeding much more quickly, but the
disadvantage that the sequence of session ids is potentially predicatable.
Predicatability is *much* easier if an attacker can manage to read
"conf/server.xml" (although, as I've pointed out to Christopher, security
of your session ids is the *least* of your problems if this happens).  The
current approach is also the one that was recommended the last time this
issue was raised (when Tomcat 3.1 had a *very* weak approach to
calculating session ids).

The decision we face, of course, is whether or not to change this.  A
complicating factor is that some platforms offer facilities (such as
/dev/random) to take advantage of entropy gathered by the OS -- but such
things are obviously not portable, so they cannot be relied on to satisfy
all requiremnts.

It seems to me we have a number of overlapping decisions.  My thoughts are
after each decision area -- I'm looking for input from others.


DECISION 1 - WHAT SEEDING MECHANISMS SHOULD WE SUPPORT?

(1A) Default seeding of java.security.SecureRandom (time consuming but
 reasonably secure)

(1B) Current mechanism of timestamp + entropy string (very fast,
 potentially not secure)

(1C) Plug-in seeding API to allow use of platform-specific algorithms
 if desired

Currently, Tomcat 4 only supports (1B).  It certainly makes sense to offer
(1A) as well.  Offering (1C) is more work, but is not conceptually
difficult.


DECISION 2 - WHAT SEEDING MECHANISM SHOULD BE THE DEFAULT?
  (assumes, of course, that we support them both)

(2A) Default seeding

(2B) Current mechanism

Currently, (2B) is supported, because only (1B) is supported.  This is
likely to be a much more involved discussion that Decision 1.  I could be
persuaded to (2A), but I'm not really certain that this is an issue in the
majority of Tomcat installations -- if we allow people who care about it
to choose (2A), but not make people suffer when they don't feel session id
predicatability is an issue, that seems like a reasonable approach.


DECISION 3 - WHAT PLUG-INS FOR (1C) SHOULD WE OFFER AS STANDARD?

(3A) Unix systems /dev/random

(3B) Unix systems /dev/urandom

(3C) ???

Currently, none of these are supported.


Craig McClanahan

Re: Tomcat 4 Documentation

[Craig R. McClanahan]

That is quite odd ... the config/server.xml page works correctly for me on
NS4.7 (Linux and Windows 98) and IE5.5 (Windows 98) at 1024x768, as well
as narrower sizes when I adjust it manually.

I just committed a change to remove the width="100%" entry for attributes
list tables.  Could you take a look at the output in nightly build
20010913 (tonight) and see if this corrects the problem for you?

Craig

On Thu, 13 Sep 2001, TAKAHASHI Hideo(BSD-M1G) wrote:

> Date: Thu, 13 Sep 2001 11:48:09 +0900
> From: "TAKAHASHI Hideo(BSD-M1G)" <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: Tomcat 4 Documentation
>
> Hi.
>
> I have had the same problem. It happens on pages for example
> config/server.html. It happens on NS4.7,NS6.1,IE5.5 alike.
> BTW My screen size is 1280x1024.
>
> I examined the generated html and the stylesheet, and tracked down which
> of the width attributes are the key to this problem.
>
> By taking away the width attribute from the innermost table tag, or
> changing 100% to something like 80% or 90% works for my case. I took it
> off from the table tag found inside  in
> web-apps/tomcat-docs/tomcat-docs.xsl
>
> Specifying no width will cause tables with shorter content to appear in
> smaller width, which might be not very pretty.  Specifying an absolute
> value like 80 or 90 percent will work only with a certain browser window
> size.  When I resize the browser to be narrower, contents will be
> clipped again.
>
> Hideo.
>
> "Craig R. McClanahan" wrote:
> >
> > > > One other thing I noticed with the docs.  On my system at home, Netscape
> > > 4.7
> > > > on FreeBSD the right margin for the docs is cut off and not viewable.
> > >
> > > I noticed the same thing with IE on Windows. Aside from that, I like the way
> > > the new docs look.
> > >
> >
> > The only time I've had this happen to me is when there is a  box
> > that is wider than my current browser window width.  Are either of you
> > seeing this in other circumstances?  It would also be helpful to know
> > which particular pages do this (in most cases, wide source code examples
> > can be reformatted), or if it is all of them.
> >
> > FWIW, the outermost  tag that is generated is
> >
> >   
> >
> > just like the Anakia templates for jakarta-site2, so it is reacting the
> > same way to the same sorts of input.
> >
> > > Jon
> > >
> >
> > Craig
>
> --
> Hideo Takahashi
> Business Solutions Division, Hitachi Ltd.
> http://www.hitachi.co.jp/Div/bisd
>

cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs tomcat-docs.xsl

[craigmcc]

craigmcc01/09/12 19:52:56

  Modified:webapps/tomcat-docs tomcat-docs.xsl
  Log:
  Remove a width="100%" setting from the  generated for attributes lists,
  to see if that helps avoid problems where the right side of the documentation
  pages are cut off for some users.
  
  Revision  ChangesPath
  1.5   +4 -1  jakarta-tomcat-4.0/webapps/tomcat-docs/tomcat-docs.xsl
  
  Index: tomcat-docs.xsl
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/tomcat-docs.xsl,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- tomcat-docs.xsl   2001/09/12 01:03:51 1.4
  +++ tomcat-docs.xsl   2001/09/13 02:52:56 1.5
  @@ -1,7 +1,7 @@
   
   
   
  -
  +
   
   http://www.w3.org/1999/XSL/Transform";
 version="1.0">
  @@ -240,7 +240,10 @@
   
 
 
  +
  +
 
   
 Attribute
  
  
  

Re: Tomcat 4 Documentation

[TAKAHASHI Hideo(BSD-M1G)]

Hi.

I have had the same problem. It happens on pages for example
config/server.html. It happens on NS4.7,NS6.1,IE5.5 alike.
BTW My screen size is 1280x1024.

I examined the generated html and the stylesheet, and tracked down which
of the width attributes are the key to this problem.

By taking away the width attribute from the innermost table tag, or
changing 100% to something like 80% or 90% works for my case. I took it
off from the table tag found inside  in
web-apps/tomcat-docs/tomcat-docs.xsl

Specifying no width will cause tables with shorter content to appear in
smaller width, which might be not very pretty.  Specifying an absolute
value like 80 or 90 percent will work only with a certain browser window
size.  When I resize the browser to be narrower, contents will be
clipped again.

Hideo.

"Craig R. McClanahan" wrote:
> 
> > > One other thing I noticed with the docs.  On my system at home, Netscape
> > 4.7
> > > on FreeBSD the right margin for the docs is cut off and not viewable.
> >
> > I noticed the same thing with IE on Windows. Aside from that, I like the way
> > the new docs look.
> >
> 
> The only time I've had this happen to me is when there is a  box
> that is wider than my current browser window width.  Are either of you
> seeing this in other circumstances?  It would also be helpful to know
> which particular pages do this (in most cases, wide source code examples
> can be reformatted), or if it is all of them.
> 
> FWIW, the outermost  tag that is generated is
> 
>   
> 
> just like the Anakia templates for jakarta-site2, so it is reacting the
> same way to the same sorts of input.
> 
> > Jon
> >
> 
> Craig

--
Hideo Takahashi
Business Solutions Division, Hitachi Ltd.
http://www.hitachi.co.jp/Div/bisd

failure notice (fwd)

[Craig R. McClanahan]

The commit message was too big to send, but I'm forwarding the comments.
Thanks to Kazuhiro Kazama, Tomcat now speaks Japanese in its log files!

Craig

-- Forwarded message --
Date: 13 Sep 2001 02:23:47 -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: failure notice

Hi. This is the qmail-send program at apache.org.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<[EMAIL PROTECTED]>:
ezmlm-reject: fatal: Sorry, I don't accept messages larger than 10 bytes (#5.2.3)

--- Below this line is a copy of the message.

Return-Path: <[EMAIL PROTECTED]>
Received: (qmail 79567 invoked by uid 500); 13 Sep 2001 02:23:47 -
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 79564 invoked from network); 13 Sep 2001 02:23:47 -
Received: from icarus.apache.org (64.125.133.21)
  by daedalus.apache.org with SMTP; 13 Sep 2001 02:23:47 -
Received: (qmail 83482 invoked by uid 1059); 13 Sep 2001 02:19:22 -
Date: 13 Sep 2001 02:19:22 -
Message-ID: <[EMAIL PROTECTED]>
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/resources 
messages_ja.properties
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

craigmcc01/09/12 19:19:21

  Added:   catalina/src/share/org/apache/catalina/authenticator
LocalStrings_ja.properties
   catalina/src/share/org/apache/catalina/cluster
LocalStrings_ja.properties
   catalina/src/share/org/apache/catalina/connector
LocalStrings_ja.properties
   catalina/src/share/org/apache/catalina/connector/http
LocalStrings_ja.properties
   catalina/src/share/org/apache/catalina/connector/http10
LocalStrings_ja.properties
   catalina/src/share/org/apache/catalina/core
LocalStrings_ja.properties
   catalina/src/share/org/apache/catalina/loader
LocalStrings_ja.properties
   catalina/src/share/org/apache/catalina/logger
LocalStrings_ja.properties
   catalina/src/share/org/apache/catalina/realm
LocalStrings_ja.properties
   catalina/src/share/org/apache/catalina/servlets
LocalStrings_ja.properties
   catalina/src/share/org/apache/catalina/session
LocalStrings_ja.properties
   catalina/src/share/org/apache/catalina/startup
LocalStrings_ja.properties
   catalina/src/share/org/apache/catalina/util
LocalStrings_ja.properties
   catalina/src/share/org/apache/catalina/valves
LocalStrings_ja.properties
   catalina/src/share/org/apache/naming/resources
LocalStrings_ja.properties
   jasper/src/share/org/apache/jasper/resources
messages_ja.properties
  Log:
  Japanese translations for all of the Catalina and Jasper message
  resources.

  (I'm embarrassed to say that I don't know how to say "thank you" in
  Japanese, even translating phonetically to ASCII, but thank you all the
  same ;-)

  Submitted by: Kazuhiro Kazama <[EMAIL PROTECTED]>


(((Details of all the new files snipped)))

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

[craigmcc]

craigmcc01/09/12 19:11:33

  Modified:catalina/src/share/org/apache/catalina/connector
LocalStrings_es.properties
   catalina/src/share/org/apache/catalina/logger
LocalStrings_es.properties
   catalina/src/share/org/apache/catalina/util
LocalStrings_es.properties
   catalina/src/share/org/apache/catalina/valves
LocalStrings_es.properties
  Log:
  Updated Spanish translations for Tomcat 4 message resources.
  
  Muchas gracias!
  
  PR: Bugzilla #3114
  Submitted by: Vincente Salvador <[EMAIL PROTECTED]>
  
  Revision  ChangesPath
  1.2   +6 -11 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/LocalStrings_es.properties
  
  Index: LocalStrings_es.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/LocalStrings_es.properties,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- LocalStrings_es.properties2000/11/09 23:11:42 1.1
  +++ LocalStrings_es.properties2001/09/13 02:11:33 1.2
  @@ -1,23 +1,18 @@
  -# $Id: LocalStrings_es.properties,v 1.1 2000/11/09 23:11:42 nacho Exp $
  -
  -# language es
  -
  -# package org.apache.catalina.connector
  -
  -
  +httpRequestBase.createCommitted=No se puede crear una sesión despues de que la 
respuesta ya ha sido enviada
   httpResponseBase.sendError.ise=No se puede llamar a sendError() despues de que la 
respuesta ha sido enviada
   httpResponseBase.sendRedirect.ise=No se puede llamar a sendRedirect() despues de 
que la respuesta ha sido enviada
  -requestBase.getInputStream.ise=getReader() ya ha sido llamadp para esta peticion
  -requestBase.getReader.ise=getInputStream() ya ha sido llamado para esta peticion
  +requestBase.getInputStream.ise=getReader() ya ha sido llamado para esta petición
  +requestBase.getReader.ise=getInputStream() ya ha sido llamado para esta petición
   requestStream.close.closed=No se puede cerrar el mismo flujo de entrada dos veces
   requestStream.close.skip=skip() a devuelto cero bytes omitidos
  -requestStream.read.closed=Este flujo de entrada ha sdo cerrado
  +requestStream.read.closed=Este flujo de entrada ha sido cerrado
   responseBase.getOutputStream.ise=getWriter() ya ha sido llamado para esta respuesta
   responseBase.getWriter.ise=getOutputStream() ya ha sido llamado para esta respuesta
   responseBase.reset.ise=No se puede hacer reset() despues de que la respuesta ha 
sido escrita
   responseBase.resetBuffer.ise=No se puede reiniciar el buffer despues de que la 
respuesta ha sido escrita
  +requestBase.setAttribute.namenull=El nombre no puede ser nulo
   responseBase.setBufferSize.ise=El tamaño del buffer no puede ser cambiado despues 
de que los datos han sido escritos
  -responseStream.close.closed=Este flujo de salida ha sido ya cerrado
  +responseStream.close.closed=Este flujo de salida ya ha sido cerrado
   responseStream.flush.closed=No se puede vaciar un flujo de salida cerrado
   responseStream.write.closed=No se puede escribir un flujo de salida cerrado
   responseStream.write.count=No se pueden escribir mas bytes que la longitud prevista 
hacia este flujo de salida
  
  
  
  1.2   +2 -7  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/logger/LocalStrings_es.properties
  
  Index: LocalStrings_es.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/logger/LocalStrings_es.properties,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- LocalStrings_es.properties2000/11/10 23:52:06 1.1
  +++ LocalStrings_es.properties2001/09/13 02:11:33 1.2
  @@ -1,11 +1,6 @@
  -# $Id: LocalStrings_es.properties,v 1.1 2000/11/10 23:52:06 nacho Exp $
  -
  -# language es
  -
   # package org.apache.catalina.logger
   
  -
   fileLogger.alreadyStarted=El Registro de actividades de archivos ha sido ya iniciado
  -fileLogger.notStarted=El Registro de actividades  de archivos no ha sido aun 
iniciado
  +fileLogger.notStarted=El Registro de actividades de archivos no ha sido aún iniciado
   tomcatLogger.alreadyStarted=El Registro de actividades de Tomcat ha sido ya iniciado
  -tomcatLogger.notStarted=El Registro de actividades de Tomcat no ha sido aun iniciado
  +tomcatLogger.notStarted=El Registro de actividades de Tomcat no ha sido aún iniciado
  
  
  
  1.2   +2 -7  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/LocalStrings_es.properties
  
  Index: LocalStrings_es.properties
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/util/LocalStrings_es.properties,v
  retrieving revision 1.1
  retrieving revi

Re: Tomcat 4 Documentation

[Craig R. McClanahan]

On Wed, 12 Sep 2001, Jonathan Eric Miller wrote:

> Date: Wed, 12 Sep 2001 20:31:01 -0500
> From: Jonathan Eric Miller <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: Tomcat 4 Documentation
>
>
> - Original Message -
> From: "Glenn Nielsen" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, September 12, 2001 7:30 PM
> Subject: Re: Tomcat 4 Documentation
>
>
> > One other thing I noticed with the docs.  On my system at home, Netscape
> 4.7
> > on FreeBSD the right margin for the docs is cut off and not viewable.
>
> I noticed the same thing with IE on Windows. Aside from that, I like the way
> the new docs look.
>

The only time I've had this happen to me is when there is a  box
that is wider than my current browser window width.  Are either of you
seeing this in other circumstances?  It would also be helpful to know
which particular pages do this (in most cases, wide source code examples
can be reformatted), or if it is all of them.

FWIW, the outermost  tag that is generated is

  

just like the Anakia templates for jakarta-site2, so it is reacting the
same way to the same sorts of input.

> Jon
>

Craig

cvs commit: jakarta-tomcat/src/native/mod_jk/iis jk_isapi_plugin.c

[nacho]

nacho   01/09/12 18:49:52

  Modified:src/native/mod_jk/iis jk_isapi_plugin.c
  Log:
  Oops , logging before the opening of the log file is not a good idea :)
  
  Thanks to Tim Whittington
  
  Revision  ChangesPath
  1.6   +5 -4  jakarta-tomcat/src/native/mod_jk/iis/jk_isapi_plugin.c
  
  Index: jk_isapi_plugin.c
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/iis/jk_isapi_plugin.c,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- jk_isapi_plugin.c 2001/09/13 01:11:25 1.5
  +++ jk_isapi_plugin.c 2001/09/13 01:49:51 1.6
  @@ -57,7 +57,7 @@
* Description: ISAPI plugin for IIS/PWS   *
* Author:  Gal Shachor <[EMAIL PROTECTED]>   *
* Author:  Ignacio J. Ortega <[EMAIL PROTECTED]>   *
  - * Version: $Revision: 1.5 $   *
  + * Version: $Revision: 1.6 $   *
***/
   
   #include 
  @@ -650,6 +650,10 @@
   if(read_registry_init_data()) {
   jk_map_t *map;
   
  +if(!jk_open_file_logger(&logger, log_file, log_level)) {
  +logger = NULL;
  +}
  +
/* Logging the initialization type: registry or properties file in 
virtual dir
*/
if (using_ini_file) {
  @@ -663,9 +667,6 @@
jk_log(logger, JK_LOG_DEBUG, "Using worker file %s.\n", worker_file);
jk_log(logger, JK_LOG_DEBUG, "Using worker mount file %s.\n", 
worker_mount_file);
   
  -if(!jk_open_file_logger(&logger, log_file, log_level)) {
  -logger = NULL;
  -}
   
   if(map_alloc(&map)) {
   if(map_read_properties(map, worker_mount_file)) {
  
  
  

Re: Tomcat 4 Documentation

[Jonathan Eric Miller]

- Original Message -
From: "Glenn Nielsen" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 12, 2001 7:30 PM
Subject: Re: Tomcat 4 Documentation


> One other thing I noticed with the docs.  On my system at home, Netscape
4.7
> on FreeBSD the right margin for the docs is cut off and not viewable.

I noticed the same thing with IE on Windows. Aside from that, I like the way
the new docs look.

Jon

cvs commit: jakarta-tomcat/src/native/mod_jk/iis jk_isapi_plugin.c

[nacho]

nacho   01/09/12 18:11:25

  Modified:src/native/mod_jk/iis jk_isapi_plugin.c
  Log:
  With this patch the ISAPI redirector can load it's initial config
  from a properties file situated in the same virtual dir where the
  isapi_redirect.dll lies.
  
  This patch allows to have multiple Tomcat instances serving various
  IIS virtual servers be configured in easy way.
  
  1) You install the ISAPI filter DLL in a virtual directory.
  
  2) In the same directory you put a properties file of the same name
 (except for the extension)
 i.e. /jakarta/isapi_redirect.dll and /jakarta/isapi_redirect.properties
  
  3) The ini file is a property file with exactly the same properties
  as used to be put in the registry
i.e.
worker_file=C:\tomcat\conf\workers.properties
worker_mount_file=C:\tomcat\conf\uriworkermap.properties
log_level=error
log_file=C:\tomcat\logs\isapi_redirector.log
extension_uri=/jakarta/isapi_redirect.dll
  
  4) The filter loads this ini file and gets its settings from it.
  
  5) If the filter can't find the ini file it uses the registry (old
   behaviour) == 1 ISAPI per machine.
  
  6) You can then install another filter, with another ini file, and
  not have the two conflict.
  
  Submitted by  Tim Whittington [Tim.Whittington at orion.co.nz]
  
  Revision  ChangesPath
  1.5   +119 -53   jakarta-tomcat/src/native/mod_jk/iis/jk_isapi_plugin.c
  
  Index: jk_isapi_plugin.c
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/iis/jk_isapi_plugin.c,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- jk_isapi_plugin.c 2001/09/13 00:07:39 1.4
  +++ jk_isapi_plugin.c 2001/09/13 01:11:25 1.5
  @@ -57,7 +57,7 @@
* Description: ISAPI plugin for IIS/PWS   *
* Author:  Gal Shachor <[EMAIL PROTECTED]>   *
* Author:  Ignacio J. Ortega <[EMAIL PROTECTED]>   *
  - * Version: $Revision: 1.4 $   *
  + * Version: $Revision: 1.5 $   *
***/
   
   #include 
  @@ -121,6 +121,8 @@
   }   \
   }\
   
  +static char ini_file_name[MAX_PATH];
  +static int using_ini_file = JK_FALSE;
   static int   is_inited = JK_FALSE;
   static jk_uri_worker_map_t *uw_map = NULL; 
   static jk_logger_t *logger = NULL; 
  @@ -615,6 +617,10 @@
   LPVOID lpReserved)  // Reserved parameter for future use
   {
   BOOL fReturn = TRUE;
  +char drive[_MAX_DRIVE];
  +char dir[_MAX_DIR];
  +char fname[_MAX_FNAME];
  +char file_name[_MAX_PATH];
   
   switch (ulReason) {
   case DLL_PROCESS_DETACH:
  @@ -627,6 +633,12 @@
   default:
   break;
   } 
  +if (GetModuleFileName( hInst, file_name, sizeof(file_name))) {
  +_splitpath( file_name, drive, dir, fname, NULL );
  +_makepath( ini_file_name, drive, dir, fname, ".properties" );
  +} else {
  +fReturn = JK_FALSE;
  +}
   
   return fReturn;
   }
  @@ -638,6 +650,19 @@
   if(read_registry_init_data()) {
   jk_map_t *map;
   
  + /* Logging the initialization type: registry or properties file in 
virtual dir
  + */
  + if (using_ini_file) {
  +  jk_log(logger, JK_LOG_DEBUG, "Using ini file %s.\n", 
ini_file_name);
  + } else {
  +  jk_log(logger, JK_LOG_DEBUG, "Using registry.\n");
  + }
  + jk_log(logger, JK_LOG_DEBUG, "Using log file %s.\n", log_file);
  + jk_log(logger, JK_LOG_DEBUG, "Using log level %d.\n", log_level);
  + jk_log(logger, JK_LOG_DEBUG, "Using extension uri %s.\n", 
extension_uri);
  + jk_log(logger, JK_LOG_DEBUG, "Using worker file %s.\n", worker_file);
  + jk_log(logger, JK_LOG_DEBUG, "Using worker mount file %s.\n", 
worker_mount_file);
  +
   if(!jk_open_file_logger(&logger, log_file, log_level)) {
   logger = NULL;
   }
  @@ -677,62 +702,103 @@
   HKEY hkey;
   long rc;
   int  ok = JK_TRUE;
  -rc = RegOpenKeyEx(HKEY_LOCAL_MACHINE,
  -  REGISTRY_LOCATION,
  -  (DWORD)0, 
  -  KEY_READ, 
  -  &hkey);
  -if(ERROR_SUCCESS != rc) {
  -return JK_FALSE;
  -} 
  +char *tmp;
  +jk_map_t *map;
   
  -if(get_registry_config_parameter(hkey,
  - JK_LOG_FILE_TAG, 
  - tmpbuf,
  - sizeof(log_file))) {
  -strcpy(log_file, tmpbuf);
  -} else {
  -  

Re: cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docsjndi-resources-howto.xml

[Pier Fumagalli]

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

> on 9/12/01 4:19 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
> 
>> +
>> +
>> +  
>> +Object factory for MyBean instances.
>> +  
>> +  
>> +bean/MyBeanFactory
>> +  
>> +  
>> +com.mycompany.MyBean
>> +  
>> +
>> +
> 
> E
> 
> Anakia's documentation generation doesn't require you to escape that if you
> use CDATA to contain the stuff.

It's not only anakia It's XML :)

Pier

Re: Remaining Tomcat 3.3 Issues

[Craig R. McClanahan]

On Wed, 12 Sep 2001, Bill Barker wrote:

> Date: Wed, 12 Sep 2001 17:04:42 -0700
> From: Bill Barker <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED],
>  Bill Barker <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: Remaining Tomcat 3.3 Issues
>
> Shouldn't 461 be re-classified as a 4.0 issue?
> ServletRequest.setCharacterEncoding is a new feature of 2.3.

Looks like it.

Also looks like it's a bug that was fixed long, long, ago -- so I'm going
to close it as well.

Craig


> - Original Message -
> From: "Larry Isaacs" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, September 12, 2001 8:31 AM
> Subject: Remaining Tomcat 3.3 Issues
>
>
> > Hi All,
> >
> > I have made a pass through all Tomcat3 bugs.  Those listed below
> > are the only ones that remain open as of last night.  Listed for
> > RC1 and RC2 are issues I have accumulated as well as bugs that must
> > be resolved.
> >
> > Each of these issues needs to be considered according to its
> > impact on the stability of Tomcat 3.3.  I think most of the bugs
> > are already fixed, but I need someone more familiar with the
> > code to make a more informed assessment about the appropriate
> > resolution.
> >
> > I am going ahead and posting this even though I haven't spent much
> > time trying to identify which of these I consider showstoppers
> > (mainly due to dancing late into the night with Bugzilla).
> > At this moment, by default I don't consider any of these
> > showstoppers.  I will try to review this and post my opinions later,
> > probably tomorrow. Others are welcome to offer their opinions in this
> > regard.
> >
> > = Tomcat 3.3 Release Issues =
> >
> > To Be Addressed for RC1:
> >
> > 1. HttpSessionFacade.setAttribute() isn't synchronized.  If a second
> request
> > called "setAttribute()" after this request's "removeAttribute()" and
> before
> > "realSession.setAttribute()", the second request's value would be
> overwritten
> > without an valueUnbound() being called.
> >
> > 2. Evaluate Tomcat 3.3's vulnerability to "Double Checked Locking". This
> > is referred to in Bug #177. See:
> > http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
> > for details.  I think ServletHandler.init() is currently subject to this
> > vulnerability.
> >
> > 3. The spec doesn't address whether a the form-login-page and
> form-error-page
> > should be excluded from the security-constraint, but it makes sense that
> > it should.  It might be best to postpone this.
> >
> > 4. Address user authentication via Ajp12 and Ajp13.  Ajp12 has a test for
> > isTomcatAuthentication() to see if req.setRemoteUser() should be called.
> > I think Ajp13 doesn't have this yet and probably should.  Also, if the
> > user is anonymous, i.e. user = "", should we call req.setRemoteUser()
> > with this value?  This prevents Tomcat's normal authentication from being
> > triggered.
> >
> > 5. If a error handler is not found for an exception, check the root cause
> > as well if it is a ServletException.  This is mentioned in Bug 3233.  I
> think
> > it would be a good idea to apply this.  I don't think we are prohibited
> > by the spec.  We could add an option to be safe if there is concern.
> >
> > 6. StaticInterceptor is missing a localization enhancement added to
> > Tomcat 3.2.x.  Should this enhancement be ported to Tomcat 3.3?  Is
> > this still considered a regression, though it isn't part of the
> > Servlet 2.2/JSP 1.1 spec?
> >
> > 7. Evaluate whether anything should be done to deal with the use of
> > non-thread-safe DateFormat and related classes.
> >
> > Must Resolve Bugs:
> >
> > 177   Race condition during servlet initialization BugRat Report#2
> > 182   JSP error-page doesn't work with virtual hosts BugRat Report
> > 274   request.getUserPrincipal() doesn't work when user is authent
> > 437   req.getParameter(name) Ignores charset. always assumes ISO88
> > 461   Use setCharacterEncoding("UTF8") does not change the way get
> > 463   Ctx( /examples ): IOException in: R( /examples + + null) No
> > 1253  Frequent Connection reset by peer errors
> > 1482  Ignored session ids in encoded URLs
> > 1663  Tomcat -SSL problem
> > 1798  Tomcat 3.2.2b5 with Apache and ajp13 stops responding after
> > 3233  exception handling wrt errorpages seems to be incorrect
> > 3486 Session problem (with case insensitive context matching on windows)
> >
> >
> >
> > To Be Addressed by RC2:
> >
> > 8. We need to remove or optionally disable the shutdown support in
> > Ajp13Interceptor.  This allows configuring a password protected
> > Ajp12Interceptor shutdown to be the only shutdown available.
> >
> > 9. Some files under src/native have embedded CR's, i.e. Unix files would
> have
> > CRLF and Windows files would have CRCRLF's.  These need to be fixed.
> >
> > 10. The jk_nt_service, and I assume jniconnect, redirect stdout and stderr
> to
> > files.  With the default server.xml with no path for tc_log, Tomcat's
> > startup output ends

Re: Remaining Tomcat 3.3 Issues

[Bill Barker]

Shouldn't 461 be re-classified as a 4.0 issue?
ServletRequest.setCharacterEncoding is a new feature of 2.3.
- Original Message -
From: "Larry Isaacs" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 12, 2001 8:31 AM
Subject: Remaining Tomcat 3.3 Issues


> Hi All,
>
> I have made a pass through all Tomcat3 bugs.  Those listed below
> are the only ones that remain open as of last night.  Listed for
> RC1 and RC2 are issues I have accumulated as well as bugs that must
> be resolved.
>
> Each of these issues needs to be considered according to its
> impact on the stability of Tomcat 3.3.  I think most of the bugs
> are already fixed, but I need someone more familiar with the
> code to make a more informed assessment about the appropriate
> resolution.
>
> I am going ahead and posting this even though I haven't spent much
> time trying to identify which of these I consider showstoppers
> (mainly due to dancing late into the night with Bugzilla).
> At this moment, by default I don't consider any of these
> showstoppers.  I will try to review this and post my opinions later,
> probably tomorrow. Others are welcome to offer their opinions in this
> regard.
>
> = Tomcat 3.3 Release Issues =
>
> To Be Addressed for RC1:
>
> 1. HttpSessionFacade.setAttribute() isn't synchronized.  If a second
request
> called "setAttribute()" after this request's "removeAttribute()" and
before
> "realSession.setAttribute()", the second request's value would be
overwritten
> without an valueUnbound() being called.
>
> 2. Evaluate Tomcat 3.3's vulnerability to "Double Checked Locking". This
> is referred to in Bug #177. See:
> http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
> for details.  I think ServletHandler.init() is currently subject to this
> vulnerability.
>
> 3. The spec doesn't address whether a the form-login-page and
form-error-page
> should be excluded from the security-constraint, but it makes sense that
> it should.  It might be best to postpone this.
>
> 4. Address user authentication via Ajp12 and Ajp13.  Ajp12 has a test for
> isTomcatAuthentication() to see if req.setRemoteUser() should be called.
> I think Ajp13 doesn't have this yet and probably should.  Also, if the
> user is anonymous, i.e. user = "", should we call req.setRemoteUser()
> with this value?  This prevents Tomcat's normal authentication from being
> triggered.
>
> 5. If a error handler is not found for an exception, check the root cause
> as well if it is a ServletException.  This is mentioned in Bug 3233.  I
think
> it would be a good idea to apply this.  I don't think we are prohibited
> by the spec.  We could add an option to be safe if there is concern.
>
> 6. StaticInterceptor is missing a localization enhancement added to
> Tomcat 3.2.x.  Should this enhancement be ported to Tomcat 3.3?  Is
> this still considered a regression, though it isn't part of the
> Servlet 2.2/JSP 1.1 spec?
>
> 7. Evaluate whether anything should be done to deal with the use of
> non-thread-safe DateFormat and related classes.
>
> Must Resolve Bugs:
>
> 177   Race condition during servlet initialization BugRat Report#2
> 182   JSP error-page doesn't work with virtual hosts BugRat Report
> 274   request.getUserPrincipal() doesn't work when user is authent
> 437   req.getParameter(name) Ignores charset. always assumes ISO88
> 461   Use setCharacterEncoding("UTF8") does not change the way get
> 463   Ctx( /examples ): IOException in: R( /examples + + null) No
> 1253  Frequent Connection reset by peer errors
> 1482  Ignored session ids in encoded URLs
> 1663  Tomcat -SSL problem
> 1798  Tomcat 3.2.2b5 with Apache and ajp13 stops responding after
> 3233  exception handling wrt errorpages seems to be incorrect
> 3486 Session problem (with case insensitive context matching on windows)
>
>
>
> To Be Addressed by RC2:
>
> 8. We need to remove or optionally disable the shutdown support in
> Ajp13Interceptor.  This allows configuring a password protected
> Ajp12Interceptor shutdown to be the only shutdown available.
>
> 9. Some files under src/native have embedded CR's, i.e. Unix files would
have
> CRLF and Windows files would have CRCRLF's.  These need to be fixed.
>
> 10. The jk_nt_service, and I assume jniconnect, redirect stdout and stderr
to
> files.  With the default server.xml with no path for tc_log, Tomcat's
> startup output ends up in the "stderr" log. I would have expected it to
> be in the "stdout" log.  Is there a reason the o.a.t.u.qlog.Logger uses
> stderr as the default sink instead of stdout?
>
> 11. Make sure we are okay with mod_jk not supporting Apache's rewrite
> in Tomcat 3.3's mod_jk.  I'm fine with not supporting it, but I want
> to include some justification in the documentation to avoid some of
> the "why don't you" questions.
>
> 12. To simplify upgrade development, I would like to see the classpath
> for the "container", "common", and "apps" classloaders include the
> directory so classes p

Re: cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docsjndi-resources-howto.xml

[Jon Stevens]

on 9/12/01 4:19 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:

> +
> +
> +  
> +Object factory for MyBean instances.
> +  
> +  
> +bean/MyBeanFactory
> +  
> +  
> +com.mycompany.MyBean
> +  
> +
> +

E

Anakia's documentation generation doesn't require you to escape that if you
use CDATA to contain the stuff.

-jon

cvs commit: jakarta-tomcat-site/xdocs/stylesheets project.xml

[craigmcc]

craigmcc01/09/12 17:08:30

  Modified:docs index.html news.html
   xdocs/stylesheets project.xml
  Log:
  Remove reference to "experimental" Tomcat 4 docs ... there is now only the
  (new) official set.
  
  Revision  ChangesPath
  1.8   +1 -3  jakarta-tomcat-site/docs/index.html
  
  Index: index.html
  ===
  RCS file: /home/cvs/jakarta-tomcat-site/docs/index.html,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- index.html2001/08/10 16:30:17 1.7
  +++ index.html2001/09/13 00:08:30 1.8
  @@ -50,9 +50,7 @@
   
   Tomcat 3.3
   
  -Tomcat 4.0 
(current)
  -
  -Tomcat 4.0 
(experimental)
  +Tomcat 4.0
   
   
   Download
  
  
  
  1.8   +1 -3  jakarta-tomcat-site/docs/news.html
  
  Index: news.html
  ===
  RCS file: /home/cvs/jakarta-tomcat-site/docs/news.html,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- news.html 2001/09/05 13:03:16 1.7
  +++ news.html 2001/09/13 00:08:30 1.8
  @@ -50,9 +50,7 @@
   
   Tomcat 3.3
   
  -Tomcat 4.0 
(current)
  -
  -Tomcat 4.0 
(experimental)
  +Tomcat 4.0
   
   
   Download
  
  
  
  1.3   +1 -3  jakarta-tomcat-site/xdocs/stylesheets/project.xml
  
  Index: project.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-site/xdocs/stylesheets/project.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- project.xml   2001/07/29 22:50:34 1.2
  +++ project.xml   2001/09/13 00:08:30 1.3
  @@ -14,9 +14,7 @@
   


  - 
  -
  + 
   
   
   
  
  
  

cvs commit: jakarta-tomcat/src/native/mod_jk/iis jk_isapi_plugin.c

[nacho]

nacho   01/09/12 17:07:39

  Modified:src/native/mod_jk/iis jk_isapi_plugin.c
  Log:
  Virtual server support for IIS
  
  This patch adds some syntax sugar to uriworkermap.properties file format
  to allow fine grained control over redirection of tomcat contexts to IIS
  virtual hosts, allowing a syntax like :
  
  /www.somevirtualhost.com/context/*.jsp=ajp13
  
  in UWM.P file.. in addition to the old one of :
  
  /context/*.jsp=ajp13
  
  The old syntax comprises the mapping for the entire server, that is this
  context are honored in all IIS virtual servers..
  
  The new syntax permits to map a context against a unique virtual server, or a group 
of them..
  
  Revision  ChangesPath
  1.4   +22 -7 jakarta-tomcat/src/native/mod_jk/iis/jk_isapi_plugin.c
  
  Index: jk_isapi_plugin.c
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/iis/jk_isapi_plugin.c,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- jk_isapi_plugin.c 2001/09/02 07:27:27 1.3
  +++ jk_isapi_plugin.c 2001/09/13 00:07:39 1.4
  @@ -56,7 +56,8 @@
   /***
* Description: ISAPI plugin for IIS/PWS   *
* Author:  Gal Shachor <[EMAIL PROTECTED]>   *
  - * Version: $Revision: 1.3 $   *
  + * Author:  Ignacio J. Ortega <[EMAIL PROTECTED]>   *
  + * Version: $Revision: 1.4 $   *
***/
   
   #include 
  @@ -402,9 +403,13 @@
   if(is_inited &&
  (SF_NOTIFY_PREPROC_HEADERS == dwNotificationType)) { 
   PHTTP_FILTER_PREPROC_HEADERS p = 
(PHTTP_FILTER_PREPROC_HEADERS)pvNotification;
  -char uri[INTERNET_MAX_URL_LENGTH]; 
  +char uri[INTERNET_MAX_URL_LENGTH];
  + char snuri[INTERNET_MAX_URL_LENGTH]="/";
  + char Host[INTERNET_MAX_URL_LENGTH];
  +
   char *query;
   DWORD sz = sizeof(uri);
  +DWORD szHost = sizeof(Host);
   
   jk_log(logger, JK_LOG_DEBUG, 
  "HttpFilterProc started\n");
  @@ -422,15 +427,25 @@
   }
   
   if(strlen(uri)) {
  -char *worker;
  +char *worker=0;
   query = strchr(uri, '?');
   if(query) {
   *query = '\0';
   }
  -jk_log(logger, JK_LOG_DEBUG, 
  -   "In HttpFilterProc test redirection of %s\n", 
  -   uri);
  -worker = map_uri_to_worker(uw_map, uri, logger);
  + if(p->GetHeader(pfc, "Host:", (LPVOID)Host, (LPDWORD)&szHost)) 
{
  + strcat(snuri,Host);
  + strcat(snuri,uri);
  + jk_log(logger, JK_LOG_DEBUG, 
  +"In HttpFilterProc Virtual Host redirection 
of %s\n", 
  +snuri);
  + worker = map_uri_to_worker(uw_map, snuri, logger); 
   
  + }
  + if (!worker) {
  + jk_log(logger, JK_LOG_DEBUG, 
  +"In HttpFilterProc test Default redirection 
of %s\n", 
  +uri);
  + worker = map_uri_to_worker(uw_map, uri, logger);
  + }
   if(query) {
   *query = '?';
   }
  
  
  

cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs jndi-resources-howto.xml

[craigmcc]

craigmcc01/09/12 17:01:48

  Modified:webapps/tomcat-docs jndi-resources-howto.xml
  Log:
  Document the procedure for creating your own JNDI resource factories.
  
  Revision  ChangesPath
  1.5   +189 -1jakarta-tomcat-4.0/webapps/tomcat-docs/jndi-resources-howto.xml
  
  Index: jndi-resources-howto.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/jndi-resources-howto.xml,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- jndi-resources-howto.xml  2001/09/12 23:19:29 1.4
  +++ jndi-resources-howto.xml  2001/09/13 00:01:48 1.5
  @@ -577,7 +577,195 @@
   
   
   
  -  FIXME
  +  If none of the standard resource factories meet your needs, you can
  +  write your own factory and integrate it into Tomcat 4, and then configure
  +  the use of this factory in the conf/server.xml configuration
  +  file.  In the example below, we will create a factory that only knows how
  +  to create com.mycompany.MyBean beans, from the
  +  Generic JavaBean Resources
  +  example, above.
  +
  +  1.  Write A Resource Factory Class
  +
  +  You must write a class that implements the JNDI service provider
  +  javax.naming.spi.ObjectFactory inteface.  Every time your
  +  web application calls lookup() on a context entry that is
  +  bound to this factory, the getObjectInstance() method is
  +  called, with the following arguments:
  +  
  +  Object obj - The (possibly null) object containing
  +  location or reference information that can be used in creating an
  +  object.  For Tomcat, this will always be an object of type
  +  javax.naming.Reference, which contains the class name
  +  of this factory class, as well as the configuration properties
  +  (from conf/server.xml) to use in creating objects
  +  to be returned.
  +  Name name - The name to which this factory is bound
  +  relative to nameCtx, or null if no name
  +  is specified.
  +  Context nameCtx - The context relative to which the
  +  name parameter is specified, or null if
  +  name is relative to the default initial context.
  +  Hashtable environment - The (possibly null)
  +  environment that is used in creating this object.  This is generally
  +  ignored in Tomcat object factories.
  +  
  +
  +  To create a resource factory that knows how to produce MyBean
  +  instances, you might create a class like this:
  +
  +
  +package com.mycompany;
  +
  +import java.util.Enumeration;
  +import java.util.Hashtable;
  +import javax.naming.Context;
  +import javax.naming.Name;
  +import javax.naming.NamingException;
  +import javax.naming.RefAddr;
  +import javax.naming.Reference;
  +import javax.naming.spi.ObjectFactory;
  +
  +public class MyBeanFactory implements ObjectFactory {
  +
  +  public Object getObjectInstance(Object obj,
  +  Name name, Context nameCtx, Hashtable environment)
  +  throws NamingException {
  +
  +  // Acquire an instance of our specified bean class
  +  MyBean bean = new MyBean();
  +
  +  // Customize the bean properties from our attributes
  +  Reference ref = (Reference) obj;
  +  Enumeration addrs = ref.getAll();
  +  while (addrs.hasMoreElements()) {
  +  RefAddr addr = (RefAddr) addrs.nextElement();
  +  String name = addr.getType();
  +  String value = (String) addr.getContent();
  +  if (name.equals("foo")) {
  +  bean.setFoo(value);
  +  } else if (name.equals("bar")) {
  +  try {
  +  bean.setBar(Integer.parseInt(value));
  +  } catch (NumberFormatException e) {
  +  throw new NamingException("Invalid 'bar' value " + value);
  +  }
  +  }
  +  }
  +
  +  // Return the customized instance
  +  return (bean);
  +
  +  }
  +
  +}
  +
  +
  +  In this example, we are unconditionally creating a new instance of
  +  the com.mycompany.MyBean class, and populating its properties
  +  based on the parameters included in the 
  +  element that configures this factory (see below).  You should note that any
  +  parameter named factory should be skipped - that parameter is
  +  used to specify the name of the factory class itself (in this case,
  +  com.mycompany.MyBeanFactory) rather than a property of the
  +  bean being configured.
  +
  +  For more information about ObjectFactory, see the
  +  http://java.sun.com/products/jndi/docs.html";>JNDI 1.2 Service
  +  Provider Interface (SPI) Specification.
  +
  +  You will need to compile this class against a class path that includes
  +  all of the JAR files in the $CATALINA_HOME/common/lib and
  +  $CATALINA_HOME/server/lib directories.  When you are through,
  +  place the factory class (and the corresponding 

Re: [DO NOT REPLY: Bug 3524] New: NullPointerException in MemoryRealm

[Remy Maucherat]

> I'm running into this problem in RC1. Was this fixed post RC1?

Yes. The regression was caused by a last minute change.
Sorry about the trouble.

Remy

RE: NT Service Manager

[Scott Stitson]

Dave,

I would love to help you out.  I was actually working on the same thing for
tomcat 4.  I can create services for java but could not figure which file I
needed to wrap.  It took me a bit to find out how to make services and have
not been able to learn more about the structure of Catalina.  I get stuck at
the bootstrap.

Anyway.  I would love to contrubute if I can.

-Scott Stitson

-Original Message-
From: Dave Oxley [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 10, 2001 1:45 PM
To: [EMAIL PROTECTED]
Subject: RE: NT Service Manager


Costin,

I think thats a good idea. I want it to work with all versions of TC (3.2.4,

3.3 and 4.0) and I will supply patches to their respective Service 
implementations.

Dave
[EMAIL PROTECTED]


>From: <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
>Subject: RE: NT Service Manager
>Date: Mon, 10 Sep 2001 10:35:32 -0700 (PDT)
>
>Hi David,
>
>I have another point I would like to add to the list: "do we have to
>include it in the 'official' 3.3, or would it be better for it to be a
>module ?"
>
>Keep in mind that we have a relatively slow release cycle, and any feature
>is adding more overhead for each release, and impose constraints on the
>development of that feature itself ( because you have to sync with the
>whole thing ).
>
>I really want to keep each 'feature' in a separate module, if possible.
>IMHO the whole nt-service should be packaged as a separate module and
>released as such.
>
>Of course, we never did that - and I'm sure your fix will have a good
>impact on usability, so I'm +1 on including it in 3.3, but I would like
>to start thinking in terms of modules...
>
>Costin
>


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

[DO NOT REPLY: Bug 3574] Basic authentication doesn't work.

[bugzilla]

PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT
ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW
AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE
DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL
BE LOST SOMEWHERE.

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

*** shadow/3574 Wed Sep 12 11:13:35 2001
--- shadow/3574.tmp.23861   Wed Sep 12 16:43:52 2001
***
*** 7,13 
  | Severity: Critical OS/Version: All |
  | Priority: Other Component: Connectors  |
  ++
! |  Assigned To: [EMAIL PROTECTED]|
  |  Reported By: [EMAIL PROTECTED] |
  |  CC list: Cc:  |
  ++
--- 7,13 
  | Severity: Critical OS/Version: All |
  | Priority: Other Component: Connectors  |
  ++
! |  Assigned To: [EMAIL PROTECTED] |
  |  Reported By: [EMAIL PROTECTED] |
  |  CC list: Cc:  |
  ++

RE: Remaining Tomcat 3.3 Issues

[Ignacio J. Ortega]

This is my try for the "most stupid question of the century prize", as
usual, 

Perhaps confused with some old messages about mod_jserv.. perhaps..

In any case i would prefer to be able to use mod_rewrite with tomcat.

It's possible to detect if the uri was changed by another prior module? 

Saludos ,
Ignacio J. Ortega


> -Mensaje original-
> De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Enviado el: jueves 13 de septiembre de 2001 1:16
> Para: '[EMAIL PROTECTED]'
> Asunto: RE: Remaining Tomcat 3.3 Issues
> 
> 
> On Thu, 13 Sep 2001, Ignacio J. Ortega wrote:
> 
> > Please give me some info..
> >
> > It's possible to use no cookies sessions without using 
> mod_rewrite in
> > apache?
> 
> I don't know what you mean - mod_jk is taking care of decuding the
> sessionId, and it support both cookie and URL decoding.
> 
> I didn't even know that people are using mod_rewrite for 
> that. Maybe to
> integrate with other session schemes ( used for non-servlet 
> applications )
> 
> Costin
> 
> 

cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs jndi-resources-howto.xml

[craigmcc]

craigmcc01/09/12 16:19:29

  Modified:webapps/tomcat-docs jndi-resources-howto.xml
  Log:
  Add a description of the "Generic JavaBean" JNDI resource factory.  This
  can be used when you want to return new instances of preconfigured beans
  when a lookup() operation is performed, where the bean's properties can
  be customized by suitable entries in "conf/web.xml".
  
  Revision  ChangesPath
  1.4   +135 -0jakarta-tomcat-4.0/webapps/tomcat-docs/jndi-resources-howto.xml
  
  Index: jndi-resources-howto.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/jndi-resources-howto.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- jndi-resources-howto.xml  2001/09/09 23:31:53 1.3
  +++ jndi-resources-howto.xml  2001/09/12 23:19:29 1.4
  @@ -127,6 +127,141 @@
 configure, and use your own custom resource factory classes with
 Tomcat 4.
   
  +  NOTE - Of the standard resource factories, only the
  +  "JDBC Data Source" and "User Transaction" factories are mandated to
  +  be available on other platforms, and then they are required only if
  +  the platform implements the Java2 Enterprise Edition (J2EE) specs.
  +  All other standard resource factories, plus custom resource factories
  +  that you write yourself, are specific to Tomcat and cannot be assumed
  +  to be available on other containers.
  +
  +  
  +
  +0.  Introduction
  +
  +This resource factory can be used to create objects of any
  +Java class that conforms to standard JavaBeans naming conventions (i.e.
  +it has a zero-arguments constructor, and has property setters that
  +conform to the setFoo() naming pattern.  The resource factory will
  +create a new instance of the appropriate bean class every time a
  +lookup() for this entry is made.
  +
  +The steps required to use this facility are described below.
  +
  +1.  Create Your JavaBean Class
  +
  +Create the JavaBean class which will be instantiated each time
  +that the resource factory is looked up.  For this example, assume
  +you create a class com.mycompany.MyBean, which looks
  +like this:
  +
  +
  +package com.mycompany;
  +
  +public class MyBean {
  +
  +  private String foo = "Default Foo";
  +
  +  public String getFoo() {
  +return (this.foo);
  +  }
  +
  +  public void setFoo(String foo) {
  +this.foo = foo;
  +  }
  +
  +  private int bar = 0;
  +
  +  public int getBar() {
  +return (this.bar);
  +  }
  +
  +  public void setBar(int bar) {
  +this.bar = bar;
  +  }
  +
  +
  +}
  +
  +
  +  2.  Declare Your Resource Requirements
  +
  +  Next, modify your web application deployment descriptor
  +  (/WEB-INF/web.xml) to declare the JNDI name under which
  +  you will request new instances of this bean.  The simplest approach is
  +  to use a  element, like this:
  +
  +
  +
  +  
  +Object factory for MyBean instances.
  +  
  +  
  +bean/MyBeanFactory
  +  
  +  
  +com.mycompany.MyBean
  +  
  +
  +
  +
  +WARNING - Be sure you respect the element ordering
  +that is required by the DTD for web application deployment descriptors!
  +See the
  +http://java.sun.com/products/servlet/download.html";>Servlet
  +Specification for details.
  +
  +  3.  Code Your Application's Use Of This Resource
  +
  +  A typical use of this resource environment reference might look
  +  like this:
  +
  +
  +Context initCtx = new InitialContext();
  +Context envCtx = (Context) initCtx.lookup("java:comp/env");
  +MyBean bean = (MyBean) envCtx.lookup("bean/MyBeanFactory");
  +
  +writer.println("foo = " + bean.getFoo() + ", bar = " +
  +   bean.getBar());
  +
  +
  +4.  Configure Tomcat's Resource Factory
  +
  +To configure Tomcat's resource factory, add an elements like this to the
  +$CATALINA_HOME/conf/server.xml file, nested inside the
  +Context element for this web application (or nested inside
  +a DefaultContext element for the surrounding
  + or  element.
  +
  +
  +  ...
  +  
  +  
  +
  +  factory
  +  org.apache.naming.factory.BeanFactory
  +
  +
  +  bar
  +  23
  +
  +  
  +  ...
  +
  +
  +
  +Note that the resource name (here, bean/MyBeanFactory
  +must match the value 

RE: Remaining Tomcat 3.3 Issues

[cmanolache]

On Thu, 13 Sep 2001, Ignacio J. Ortega wrote:

> Please give me some info..
>
> It's possible to use no cookies sessions without using mod_rewrite in
> apache?

I don't know what you mean - mod_jk is taking care of decuding the
sessionId, and it support both cookie and URL decoding.

I didn't even know that people are using mod_rewrite for that. Maybe to
integrate with other session schemes ( used for non-servlet applications )

Costin

Re: Bug in TC 3.3 DependClassLoader

[Bojan Smojver]

Bojan Smojver wrote:
> 
> [EMAIL PROTECTED] wrote:
> >
> > Sorry, I had a lot on my had in the last days.
> >
> > Bojan - if you want to send a patch, it would be great. If not - I can fix
> > the bug ( but I would prefer you to send a patch - who knows, maybe later
> > you'll send another one, the first is allways harder :-)
> >
> > Costin
> 
> Sorry, had to sleep ;-)
> 
> I already have the code, but I'm still testing to make sure it does
> work. You'll have it this morning (Sydney time).
> 
> Bojan

This does the trick for me...

Bojan

--- 
/home/groups/devel/jakarta/jakarta-tomcat/src/share/org/apache/tomcat/util/depend/DependClassLoader.java
Tue Sep 11 17:42:11 2001
+++ src/share/org/apache/tomcat/util/depend/DependClassLoader.java  Thu Sep 13 
+09:05:00 2001
@@ -238,9 +238,16 @@
int idx=fileN.indexOf( "!" );
if( idx>=0 )
fileN=fileN.substring( 0, idx) ;
-   f=new File( fileN );
-   if( debug > 0 ) log( "Jar dep "  +f );
-   if( ! f.exists()) f=null;
+
+try{
+  f=new File(new URL(fileN).getFile());
+  if( debug > 0 ) log( "Jar dep "  +f );
+  if( ! f.exists()) f=null;
+} catch(NullPointerException npe){
+  f=null;
+} catch(MalformedURLException mue){
+  f=null;
+}
}
 
if( f==null ) return;

Re: [DO NOT REPLY: Bug 3524] New: NullPointerException in MemoryRealm

[Jonathan Eric Miller]

I'm running into this problem in RC1. Was this fixed post RC1?

Jon

- Original Message -
From: "Remy Maucherat" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, September 10, 2001 11:34 AM
Subject: Re: [DO NOT REPLY: Bug 3524] New: NullPointerException in
MemoryRealm


> Hi,
>
> > PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT
> > ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW
> > AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE
> > DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL
> > BE LOST SOMEWHERE.
> >
> > http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3524
> >
> > *** shadow/3524 Mon Sep 10 07:40:23 2001
> > --- shadow/3524.tmp.7486 Mon Sep 10 07:40:23 2001
> > ***
> > *** 0 
> > --- 1,72 
> > +
>
+===
> =+
> > + | NullPointerException in MemoryRealm
> |
> > +
>
+---
> -+
> > + |Bug #: 3524Product: Tomcat 4
> |
> > + |   Status: NEW Version: 4.0 Beta 8
> |
> > + |   Resolution:Platform: PC
> |
> > + | Severity: Normal   OS/Version: Windows NT/2K
> |
> > + | Priority: Other Component: Catalina
> |
> > +
>
+---
> -+
> > + |  Assigned To: [EMAIL PROTECTED]
> |
> > + |  Reported By: [EMAIL PROTECTED]
> |
> > + |  CC list: Cc:
> |
> > +
>
+---
> -+
> > + |  URL:
> |
> > +
>
+===
> =+
> > + |  DESCRIPTION
> |
> > + This is actually a bug for Tomcat 4.0 RC1 but that's not yet available
> in
> > + the "version" list :-)
> > +
> > + I'm getting a NullPointerException in MemoryRealm, line 213, when
trying
> to do
> > + anything with BASIC authentication. (Will upload a test case in a
> moment.) As
> > + an alternative quick demonstration of the problem, the manager
> application is
> > + showing the problem.
> > +
> > + Symptoms:
> > +
> > + * In the browser window, "HTTP Status 500 - Internal Server Error"
with
> > +   no further message
> > + * In the catalina_log.2001-09-10.txt file, the following stack trace:
> > +
> > + 2001-09-10 14:24:01 HttpProcessor[80][0] process.invoke
> > + java.lang.NullPointerException
> > + at
> org.apache.catalina.realm.MemoryRealm.authenticate(MemoryRealm.java:2
> > + 13)
> > + at
> org.apache.catalina.authenticator.BasicAuthenticator.authenticate(Bas
> > + icAuthenticator.java:161)
> > + at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica
> > + torBase.java:493)
> > + at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
> > + .java:564)
> > + at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
> > + a:472)
> > + at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> > + at
> org.apache.catalina.core.StandardContext.invoke(StandardContext.java:
> > + 2366)
> > + at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j
> > + ava:164)
> > + at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
> > + .java:566)
> > + at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:
> > + 462)
> > + at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
> > + .java:564)
> > + at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
> > + a:472)
> > + at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> > + at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal
> > + ve.java:163)
> > + at
> org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline
> > + .java:566)
> > + at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.jav
> > + a:472)
> > + at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
> > + at
> org.apache.catalina.connector.http.HttpProcessor.process(HttpProcesso
> > + r.java:1005)
> > + at
> org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.ja
> > + va:1098)
> > + at java.lang.Thread.run(Unknown Source)
> > +
> > +
> > + These lines of code (around MemoryRealm.java:213) are among those
> altered
> > + lately to do case-insensitive comparison of digested passwords.
>
> Christopher, did you run the tester before committing your patch ? ;-)
>
> Remy
>

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

[craigmcc]

craigmcc01/09/12 15:45:24

  Modified:webapps/tomcat-docs/config index.xml
  Log:
  Remove TODOs and flesh out the overview of the Server Configuration Reference.
  
  Revision  ChangesPath
  1.3   +41 -6 jakarta-tomcat-4.0/webapps/tomcat-docs/config/index.xml
  
  Index: index.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/config/index.xml,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- index.xml 2001/08/05 03:42:28 1.2
  +++ index.xml 2001/09/12 22:45:24 1.3
  @@ -20,14 +20,49 @@
   directives that can be included in a conf/server.xml file to
   configure the behavior of the Tomcat 4 servlet/JSP container.  It does not
   attempt to describe which configuration directives should be used to perform
  -specific tasks - for that, see the Server Configuration Guide and
  -related documents.  (TODO - will need hyperlink(s) to this).
  +specific tasks - for that, see the various HOW-TO documents on the
  +main index page.
   
  -TODO - add some verbage about the overall organization of conf/server.xml
  -and the valid nesting that is allowed.
  +The configuration element descriptions are organized into the following
  +major categories:
  +
  +Top Level Elements -  is the
  +root element of the entire configuration file, while
  + represents a group of Connectors that is
  +associated with an Engine.
  +Connectors - Represent the interface between external
  +clients sending requests to (and receiving responses from) a particular
  +Service.
  +Containers - Represent components whose function is to
  +process incoming requests, and create the corresponding responses.
  +An Engine handles all requests for a Service, a Host handles all requests
  +for a particular virtual host, and a Context handles all requests for a
  +specific web application.
  +Nested Components - Represent elements that can be
  +nested inside the element for a Container.  Some elements can be nested
  +inside any Container, while others can only be nested inside a
  +Context.
  +
   
  -TODO - add a brief description of the categories of elements listed in
  -the navigation menu (top level, connectors, containers, nested).
  +For each element, the corresponding documentation follows this general
  +outline:
  +
  +Introduction - Overall description of this particular
  +component.  There will be a corresponding Java interface (in
  +the org.apache.catalina pacakge) that is implemented by one
  +or more standard implementations.
  +Attributes - The set of attributes that are legal for
  +this element.  Generally, this will be subdivided into Common
  +attributes that are supported by all implementations of the corresponding
  +Java interface, and Standard Implementation attributes that are
  +specific to a particular Java class that implements this interface.
  +The names of required attributes are bolded.
  +Nested Components - Enumerates which of the Nested
  +Components can be legally nested within this element.
  +Special Features - Describes the configuration of a large
  +variety of special features (specific to each element type) that are
  +supported by the standard implementation of this interface.
  +
   
   
   
  
  
  

RE: Remaining Tomcat 3.3 Issues

[Ignacio J. Ortega]

Please give me some info..

It's possible to use no cookies sessions without using mod_rewrite in
apache? 


Saludos ,
Ignacio J. Ortega


> -Mensaje original-
> De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Enviado el: jueves 13 de septiembre de 2001 0:28
> Para: [EMAIL PROTECTED]
> Asunto: RE: Remaining Tomcat 3.3 Issues
> 
> 
> On Wed, 12 Sep 2001, Keith Wannamaker wrote:
> 
> > Then we need to be sure to encode r->uri in the main branch
> > and to change r->unparsed_uri to encode(r->uri) in the 3.2
> > branch.  I am swamped now and will put it on a long todo
> > list.. if anyone beats me to it.
> 
> Well, I said that would be my preference, but it's a very 
> delicate issue -
> maybe we should have a vote or discuss it more. The code 
> change is easy,
> deciding one way or another is the real problem.
> 
> Costin
> 
> >
> > | -Original Message-
> > | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > | Sent: Wednesday, September 12, 2001 6:10 PM
> > | To: '[EMAIL PROTECTED]'
> > | Subject: RE: Remaining Tomcat 3.3 Issues
> > |
> > |
> > |
> > | My current 'preference' is to use r->uri, as in the main 
> branch ( and how
> > | it used to be ). That keeps rewrite working and is 
> consistent with most
> > | apache modules.
> >
> 
> 

[DO NOT REPLY: Bug 3573] System.out entries in Java portion of Warp code.

[bugzilla]

PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT
ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW
AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE
DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL
BE LOST SOMEWHERE.

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

*** shadow/3573 Wed Sep 12 11:10:31 2001
--- shadow/3573.tmp.20608   Wed Sep 12 15:28:24 2001
***
*** 7,13 
  | Severity: MinorOS/Version: All |
  | Priority: Other Component: Connectors  |
  ++
! |  Assigned To: [EMAIL PROTECTED]|
  |  Reported By: [EMAIL PROTECTED] |
  |  CC list: Cc:  |
  ++
--- 7,13 
  | Severity: MinorOS/Version: All |
  | Priority: Other Component: Connectors  |
  ++
! |  Assigned To: [EMAIL PROTECTED] |
  |  Reported By: [EMAIL PROTECTED] |
  |  CC list: Cc:  |
  ++

Re: Bug in TC 3.3 DependClassLoader

[Bojan Smojver]

[EMAIL PROTECTED] wrote:
> 
> Sorry, I had a lot on my had in the last days.
> 
> Bojan - if you want to send a patch, it would be great. If not - I can fix
> the bug ( but I would prefer you to send a patch - who knows, maybe later
> you'll send another one, the first is allways harder :-)
> 
> Costin

Sorry, had to sleep ;-)

I already have the code, but I'm still testing to make sure it does
work. You'll have it this morning (Sydney time).

Bojan

cvs commit: jakarta-tomcat-connectors/webapp/java WarpLogger.java

[pier]

pier01/09/12 15:21:08

  Modified:webapp/java WarpLogger.java
  Log:
  Avoid dumping to STDERR unless this is a DEBUG build of the WARP connector.
  
  Revision  ChangesPath
  1.2   +2 -2  jakarta-tomcat-connectors/webapp/java/WarpLogger.java
  
  Index: WarpLogger.java
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/java/WarpLogger.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- WarpLogger.java   2001/07/18 23:12:49 1.1
  +++ WarpLogger.java   2001/09/12 22:21:08 1.2
  @@ -119,13 +119,13 @@
   /** Log to the container logger with the specified level or to stderr */
   private void log(String msg, Exception exc, int lev) {
   if (this.container==null) {
  -dump(msg,exc);
  +if (Constants.DEBUG) dump(msg,exc);
   return;
   }
   
   Logger logg=this.container.getLogger();
   if (logg==null) {
  -dump(msg,exc);
  +if (Constants.DEBUG) dump(msg,exc);
   return;
   }
   
  
  
  

RE: Remaining Tomcat 3.3 Issues

[cmanolache]

On Wed, 12 Sep 2001, Keith Wannamaker wrote:

> Then we need to be sure to encode r->uri in the main branch
> and to change r->unparsed_uri to encode(r->uri) in the 3.2
> branch.  I am swamped now and will put it on a long todo
> list.. if anyone beats me to it.

Well, I said that would be my preference, but it's a very delicate issue -
maybe we should have a vote or discuss it more. The code change is easy,
deciding one way or another is the real problem.

Costin

>
> | -Original Message-
> | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> | Sent: Wednesday, September 12, 2001 6:10 PM
> | To: '[EMAIL PROTECTED]'
> | Subject: RE: Remaining Tomcat 3.3 Issues
> |
> |
> |
> | My current 'preference' is to use r->uri, as in the main branch ( and how
> | it used to be ). That keeps rewrite working and is consistent with most
> | apache modules.
>

RE: Remaining Tomcat 3.3 Issues

[Keith Wannamaker]

Then we need to be sure to encode r->uri in the main branch
and to change r->unparsed_uri to encode(r->uri) in the 3.2
branch.  I am swamped now and will put it on a long todo
list.. if anyone beats me to it.

Keith

| -Original Message-
| From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
| Sent: Wednesday, September 12, 2001 6:10 PM
| To: '[EMAIL PROTECTED]'
| Subject: RE: Remaining Tomcat 3.3 Issues
| 
| 
| 
| My current 'preference' is to use r->uri, as in the main branch ( and how
| it used to be ). That keeps rewrite working and is consistent with most
| apache modules.

[DO NOT REPLY: Bug 3577] NPE when DecodeInterceptor gets confused

[bugzilla]

PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT
ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW
AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE
DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL
BE LOST SOMEWHERE.

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

*** shadow/3577 Wed Sep 12 14:45:19 2001
--- shadow/3577.tmp.20468   Wed Sep 12 15:06:35 2001
***
*** 49,51 
--- 49,62 
  --- Additional Comments From [EMAIL PROTECTED]  2001-09-12 14:45 
---
  Created an attachment (id=531)
  Example servlet
+ 
+ 
+ --- Additional Comments From [EMAIL PROTECTED]  2001-09-12 15:06 
+---
+ I forgot to include instructions:
+ 1) point your browser to http://myserver/servlet/BadServlet
+ 2) Enter some non-iso-latin-1 characters in the box and submit
+ So far, so good. Now hit the browser "back" button.  The browser will show you 
+ the cached page.
+ 3) Hit the submit button again.
+ DecodeInterceptor will think that the charset is iso-latin-1 (since the browser 
+ doesn't send it one), but the browser is sending utf-8.

RE: Remaining Tomcat 3.3 Issues

[cmanolache]

My current 'preference' is to use r->uri, as in the main branch ( and how
it used to be ). That keeps rewrite working and is consistent with most
apache modules.

The downside is that we're on the edge of the spec, which require the
'original' URI. However, since HTTP seem to allow proxies to alter
(normalize) the URI, on some server the 'original' URI is not
available, and the servlet spec covers only the servlet container, not the
web server - and we'll keep whatever enter the servlet container
unchanged - I believe using r->uri is a decent solution.

If the servlet spec would be interpreted to mean 'the URI that the user
typed' - then I believe that's impossible to implement anyway ( at least
on browser alters that ).

I'm not very sure - but beeing consistent across the servers and
consistent with what other modules and server-side programs are doing
seems a good argument.

Costin

On Wed, 12 Sep 2001, Larry Isaacs wrote:

> One of the main aspects of this issue is for me to
> become informed as to the state of Tomcat 3.3's mod_jk
> with respect to this.  Tomcat 3.3's mod_jk.c has:
>
> s->req_uri = r->uri;
>
> which, by the statement below, appears to be "rewrite"
> enabled.  This might explain why it works for Bill.
>
> I recall there being a discussion on tomcat-dev a
> while back about this, but I don't recall the final
> resolution, or if there was one. Formally establishing
> this "resolution"  for Tomcat 3.3 was my reason for
> including item 11.
>
> Thanks,
> Larry
>
> > -Original Message-
> > From: Keith Wannamaker [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, September 12, 2001 3:11 PM
> > To: [EMAIL PROTECTED]
> > Subject: RE: Remaining Tomcat 3.3 Issues
> >
> >
> > mod_jk uses (used?) r->unparsed_uri to preserve encoding.
> > Therefore, any mod_rewrite munging of r->uri is invisible
> > to mod_jk.  This is the issue to which Larry is referring,
> > not Apache module ordering.
> >
> > Keith
> >
> > | -Original Message-
> > | From: Bill Barker [mailto:[EMAIL PROTECTED]]
> > | Sent: Wednesday, September 12, 2001 2:30 PM
> > | To: [EMAIL PROTECTED]
> > | Subject: Re: Remaining Tomcat 3.3 Issues
> > |
> > |
> > | Re. 11)  I use mod_rewrite + mod_jk regularly without
> > problems.  The problem
> > | is that the "out-of-the-box" model order puts mod_jk ahead
> > of mod_rewrite.
> > | The trick to make them play happily together is to simply
> > re-order them in
> > | httpd.conf.  Of course, this has the downside that you
> > can't use the file
> > | generated by ApacheConfig verbatim.  But if you want
> > advanced functionality,
> > | you have to expect to fiddle with the configuration.
> >
>

RE: Bug in TC 3.3 DependClassLoader

[cmanolache]

Sorry, I had a lot on my had in the last days.

Bojan - if you want to send a patch, it would be great. If not - I can fix
the bug ( but I would prefer you to send a patch - who knows, maybe later
you'll send another one, the first is allways harder :-)


Costin

On Wed, 12 Sep 2001, Larry Isaacs wrote:

> Hi Bojan,
>
> Costin is the expert on this section of code.  I need to become
> more familiar with it, so I'm willing to take a look.  If you can
> submit a patch, that would be helpful.  If you need to wait for
> Costin's advice, I understand.  On occasion, I have had to do
> the same.
>
> Cheers,
> Larry
>
> > -Original Message-
> > From: Bojan Smojver [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, September 12, 2001 8:10 AM
> > To: Tomcat Dev List
> > Subject: Bug in TC 3.3 DependClassLoader
> >
> >
> > Since I was playing with distributing all my apps in jars...
> >
> > In method dependency() of that class, there is a section for jars. It
> > goes something like this:
> >
> > 
> > if( "jar".equals( res.getProtocol() )) {
> > String fileN=res.getFile();
> > int idx=fileN.indexOf( "!" );
> > if( idx>=0 )
> > fileN=fileN.substring( 0, idx) ;
> > f=new File( fileN );
> > if( debug > 0 ) log( "Jar dep "  +f );
> > if( ! f.exists()) f=null;
> > }
> >
> > if( f==null ) return;
> > Dependency dep=new Dependency();
> > dep.setLastModified( f.lastModified() );
> > dep.setTarget( c );
> > dep.setOrigin( f );
> >
> > dependM.addDependency( dep );
> > 
> >
> > So if the res is:
> >
> > 
> > jar:file:/home/httpd/html/binarix.dev/WEB-INF/lib/app.jar!/com
> > /binarix/wpm/ParseXML.class
> > 
> >
> > then fileN after res.getFile() is:
> >
> > 
> > file:/home/httpd/html/binarix.dev/WEB-INF/lib/app.jar!/com/bin
> arix/wpm/ParseXML.class
> 
>
> and after tossing everything after the bang, it becomes:
>
> 
> file:/home/httpd/html/binarix.dev/WEB-INF/lib/app.jar
> 
>
> which is NOT a file (a URL maybe?), so f.exists() returns false and f
> becomes null. The method dependency() returns without adding the jar in
> question to the list of dependencies. Aie!
>
> Maybe there should be another 'file' section inside the 'jar' section to
> resolve that URL?
>
> If you guys think that'd work OK, I can write a little patch...
>
> Bojan
>

[DO NOT REPLY: Bug 3577] NPE when DecodeInterceptor gets confused

[bugzilla]

PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT
ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW
AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE
DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL
BE LOST SOMEWHERE.

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

*** shadow/3577 Wed Sep 12 14:43:25 2001
--- shadow/3577.tmp.20404   Wed Sep 12 14:45:19 2001
***
*** 44,47 
  (PoolTcpEndpoint.java:477)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
  (ThreadPool.java:517)
!   at java.lang.Thread.run(Thread.java:484)
--- 44,51 
  (PoolTcpEndpoint.java:477)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
  (ThreadPool.java:517)
!   at java.lang.Thread.run(Thread.java:484)
! 
! --- Additional Comments From [EMAIL PROTECTED]  2001-09-12 14:45 
---
! Created an attachment (id=531)
! Example servlet

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/server Ajp12Interceptor.java Ajp12.java

[nacho]

nacho   01/09/12 14:40:36

  Modified:src/share/org/apache/tomcat/modules/server
Ajp12Interceptor.java Ajp12.java
  Log:
  Defaulting "tomcatAuthentication" to false for Ajp12 too
  
  Revision  ChangesPath
  1.17  +1 -1  
jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp12Interceptor.java
  
  Index: Ajp12Interceptor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp12Interceptor.java,v
  retrieving revision 1.16
  retrieving revision 1.17
  diff -u -r1.16 -r1.17
  --- Ajp12Interceptor.java 2001/08/25 14:19:49 1.16
  +++ Ajp12Interceptor.java 2001/09/12 21:40:36 1.17
  @@ -77,7 +77,7 @@
*/
   public class Ajp12Interceptor extends PoolTcpConnector
   implements  TcpConnectionHandler{
  -private boolean tomcatAuthentication=false;
  +private boolean tomcatAuthentication=true;
   String secret;
   File ajpidFile=null;
   
  
  
  
  1.22  +1 -1  
jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp12.java
  
  Index: Ajp12.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp12.java,v
  retrieving revision 1.21
  retrieving revision 1.22
  diff -u -r1.21 -r1.22
  --- Ajp12.java2001/09/08 00:41:29 1.21
  +++ Ajp12.java2001/09/12 21:40:36 1.22
  @@ -76,7 +76,7 @@
   Socket socket;
   InputStream sin;
   BufferedInputStream ajpin;
  -private boolean tomcatAuthentication=false;
  +private boolean tomcatAuthentication=true;
   boolean shutdown=false;
   boolean isPing=false;
   boolean doLog;
  
  
  

[DO NOT REPLY: Bug 3577] New: NPE when DecodeInterceptor gets confused

[bugzilla]

PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT
ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW
AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE
DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL
BE LOST SOMEWHERE.

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

*** shadow/3577 Wed Sep 12 14:43:25 2001
--- shadow/3577.tmp.20389   Wed Sep 12 14:43:25 2001
***
*** 0 
--- 1,47 
+ ++
+ | NPE when DecodeInterceptor gets confused   |
+ ++
+ |Bug #: 3577Product: Tomcat 3|
+ |   Status: NEW Version: 3.3 Beta 2  |
+ |   Resolution:Platform: Sun |
+ | Severity: Normal   OS/Version: Solaris |
+ | Priority: Other Component: Encoding|
+ ++
+ |  Assigned To: [EMAIL PROTECTED]|
+ |  Reported By: [EMAIL PROTECTED]  |
+ |  CC list: Cc:  |
+ ++
+ |  URL:  |
+ ++
+ |  DESCRIPTION   |
+ When DecodeInterceptor guesses the wrong charset (e.g guesses iso-latin-1 when 
+ it is really utf-8) you get the following:
+ 
+ java.lang.NullPointerException
+   at java.util.Hashtable.containsKey(Hashtable.java:299)
+   at org.apache.tomcat.util.http.Parameters.addParam(Parameters.java:321)
+   at org.apache.tomcat.util.http.Parameters.processParameters
+ (Parameters.java:395)
+   at org.apache.tomcat.core.Request.handlePostParameters(Request.java:436)
+   at org.apache.tomcat.facade.HttpServletRequestFacade.getParameter
+ (HttpServletRequestFacade.java:255)
+   at BadServlet.doPost(BadServlet.java:14)
+   at javax.servlet.http.HttpServlet.service(HttpServlet.java)
+   at javax.servlet.http.HttpServlet.service(HttpServlet.java)
+   at org.apache.tomcat.facade.ServletHandler.doService
+ (ServletHandler.java:500)
+   at org.apache.tomcat.core.Handler.invoke(Handler.java:322)
+   at org.apache.tomcat.core.Handler.service(Handler.java:235)
+   at org.apache.tomcat.facade.ServletHandler.service
+ (ServletHandler.java:448)
+   at org.apache.tomcat.core.ContextManager.internalService
+ (ContextManager.java:914)
+   at org.apache.tomcat.core.ContextManager.service
+ (ContextManager.java:831)
+   at org.apache.tomcat.modules.server.Ajp13Interceptor.processConnection
+ (Ajp13Interceptor.java:167)
+   at org.apache.tomcat.util.net.TcpWorkerThread.runIt
+ (PoolTcpEndpoint.java:477)
+   at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
+ (ThreadPool.java:517)
+   at java.lang.Thread.run(Thread.java:484)

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/server Ajp13Interceptor.java Ajp13.java

[nacho]

nacho   01/09/12 14:35:46

  Modified:src/share/org/apache/tomcat/modules/server
Ajp13Interceptor.java Ajp13.java
  Log:
  Implemented the "tomcatAuthtentication" attribute.
  
  This attribute when true ( de default ) permits
  the user of the Ajp13 protocol to override
  auth from the HTTP Server, and let Tomcat
  deal with auth itself.
  
  Revision  ChangesPath
  1.13  +23 -11
jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13Interceptor.java
  
  Index: Ajp13Interceptor.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13Interceptor.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- Ajp13Interceptor.java 2001/08/29 05:08:07 1.12
  +++ Ajp13Interceptor.java 2001/09/12 21:35:46 1.13
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13Interceptor.java,v
 1.12 2001/08/29 05:08:07 costin Exp $
  - * $Revision: 1.12 $
  - * $Date: 2001/08/29 05:08:07 $
  + * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13Interceptor.java,v
 1.13 2001/09/12 21:35:46 nacho Exp $
  + * $Revision: 1.13 $
  + * $Date: 2001/09/12 21:35:46 $
*
* 
*
  @@ -79,6 +79,7 @@
   public class Ajp13Interceptor extends PoolTcpConnector
   implements  TcpConnectionHandler
   {
  +private boolean tomcatAuthentication=true;
   public Ajp13Interceptor()
   {
   super();
  @@ -99,10 +100,12 @@
   Object thData[]=new Object[3];
   Ajp13Request req=new Ajp13Request();
   Ajp13Response res=new Ajp13Response();
  +Ajp13 con=new Ajp13();
  +con.setTomcatAuthentication(isTomcatAuthentication());
   cm.initRequest(req, res);
   thData[0]=req;
   thData[1]=res;
  -thData[2]=new Ajp13();
  +thData[2]=con;
   
   return  thData;
   }
  @@ -140,12 +143,13 @@
   req = new Ajp13Request();
   res = new Ajp13Response();
   con = new Ajp13();
  +con.setTomcatAuthentication(isTomcatAuthentication());
   cm.initRequest( req, res );
   }
// XXX
req.ajp13=con;
res.ajp13=con;
  - 
  +
   con.setSocket(socket);
   
   boolean moreRequests = true;
  @@ -159,13 +163,13 @@
socket.getInetAddress())) {
moreRequests = false;
continue;
  - }
  + }
}
if( status != 200 )
break;
  - 
  +
cm.service(req, res);
  - 
  +
req.recycle();
res.recycle();
   }
  @@ -181,13 +185,13 @@
   {
   this.cm=(ContextManager)contextM;
   }
  -
  +
   protected boolean doShutdown(InetAddress serverAddr,
InetAddress clientAddr)
   {
   try {
// close the socket connection before handling any signal
  - // but get the addresses first so they are not corrupted   
 
  + // but get the addresses first so they are not corrupted
   if(Ajp12.isSameAddress(serverAddr, clientAddr)) {
cm.stop();
// same behavior as in past, because it seems that
  @@ -201,7 +205,15 @@
log("Shutdown command ignored");
return false;
   }
  -
  +
  +public boolean isTomcatAuthentication() {
  +return tomcatAuthentication;
  +}
  +
  +public void setTomcatAuthentication(boolean newTomcatAuthentication) {
  +tomcatAuthentication = newTomcatAuthentication;
  +}
  +
   }
   
   class Ajp13Request extends Request 
  
  
  
  1.25  +35 -20
jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13.java
  
  Index: Ajp13.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/server/Ajp13.java,v
  retrieving revision 1.24
  retrieving revision 1.25
  diff -u -r1.24 -r1.25
  --- Ajp13.java2001/09/01 01:53:25 1.24
  +++ Ajp13.java2001/09/12 21:35:46 1.25
  @@ -194,30 +194,40 @@
   Ajp13Packet inBuf  = new Ajp13Packet( MAX_PACKET_SIZE );
   // Boffer used for request head ( and headers )
   Ajp13Packet hBuf=new Ajp13Packet( MAX_PACKET_SIZE );
  -
  +
   // Holds incoming reads of request body data (*not* header data)
   byte []bodyBuff = new byte[MAX_READ_SIZE];
  -
  +
   int blen;  // Length of current chunk of body data in buffer

[DO NOT REPLY: Bug 3576] BootstrapService throws exception on startup when classes directory is present

[bugzilla]

PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT
ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW
AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE
DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL
BE LOST SOMEWHERE.

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

*** shadow/3576 Wed Sep 12 13:37:09 2001
--- shadow/3576.tmp.20320   Wed Sep 12 14:20:59 2001
***
*** 2,9 
  | BootstrapService throws exception on startup when classes directory is pre |
  ++
  |Bug #: 3576Product: Tomcat 4|
! |   Status: NEW Version: 4.0 Release Candidate 1 |
! |   Resolution:Platform: PC  |
  | Severity: Critical OS/Version: Windows NT/2K   |
  | Priority: Other Component: Catalina|
  ++
--- 2,9 
  | BootstrapService throws exception on startup when classes directory is pre |
  ++
  |Bug #: 3576Product: Tomcat 4|
! |   Status: RESOLVEDVersion: 4.0 Release Candidate 1 |
! |   Resolution: FIXED  Platform: PC  |
  | Severity: Critical OS/Version: Windows NT/2K   |
  | Priority: Other Component: Catalina|
  ++
***
*** 41,43 
--- 41,47 
  --- Additional Comments From [EMAIL PROTECTED]  2001-09-12 13:37 ---
  Created an attachment (id=530)
  [PATCH] Replaced "/" with File.separator
+ 
+ 
+ --- Additional Comments From [EMAIL PROTECTED]  2001-09-12 14:20 ---
+ Should be fixed (I applied your patch). Thanks !

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

[remm]

remm01/09/12 14:15:59

  Modified:catalina/src/share/org/apache/catalina/startup
BootstrapService.java
  Log:
  - Forgot to apply some patches to BootstrapService, which made the
init of StandardClassLoader fail.
Thanks to blakest at diebold.com (sorry, I couldn't find your full name anywhere)
for the report and the patch.
  
  Revision  ChangesPath
  1.6   +7 -7  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/BootstrapService.java
  
  Index: BootstrapService.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/BootstrapService.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- BootstrapService.java 2001/09/11 23:34:43 1.5
  +++ BootstrapService.java 2001/09/12 21:15:59 1.6
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/BootstrapService.java,v
 1.5 2001/09/11 23:34:43 craigmcc Exp $
  - * $Revision: 1.5 $
  - * $Date: 2001/09/11 23:34:43 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/BootstrapService.java,v
 1.6 2001/09/12 21:15:59 remm Exp $
  + * $Revision: 1.6 $
  + * $Date: 2001/09/12 21:15:59 $
*
* 
*
  @@ -86,7 +86,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.5 $ $Date: 2001/09/11 23:34:43 $
  + * @version $Revision: 1.6 $ $Date: 2001/09/12 21:15:59 $
*/
   
   public final class BootstrapService 
  @@ -394,7 +394,7 @@
   classes.isDirectory()) {
   try {
   URL url = new URL("file", null,
  -  classes.getCanonicalPath() + "/");
  +  classes.getCanonicalPath() + File.separator);
   if (debug >= 1)
   log("  Adding " + url.toString());
   list.add(url.toString());
  @@ -462,7 +462,7 @@
   classes.isDirectory()) {
   try {
   URL url = new URL("file", null,
  -  classes.getCanonicalPath() + "/");
  +  classes.getCanonicalPath() + File.separator);
   if (debug >= 1)
   log("  Adding " + url.toString());
   list.add(url.toString());
  @@ -527,7 +527,7 @@
   classes.isDirectory()) {
   try {
   URL url = new URL("file", null,
  -  classes.getCanonicalPath() + "/");
  +  classes.getCanonicalPath() + File.separator);
   if (debug >= 1)
   log("  Adding " + url.toString());
   list.add(url.toString());
  
  
  

[DO NOT REPLY: Bug 3576] BootstrapService throws exception on startup when classes directory is present

[bugzilla]

PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT
ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW
AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE
DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL
BE LOST SOMEWHERE.

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

*** shadow/3576 Wed Sep 12 13:32:08 2001
--- shadow/3576.tmp.19382   Wed Sep 12 13:37:09 2001
***
*** 36,39 
  
  --- Additional Comments From [EMAIL PROTECTED]  2001-09-12 13:32 ---
  The same problem occurs if the common\classes or server\classes directories 
! exist.
--- 36,43 
  
  --- Additional Comments From [EMAIL PROTECTED]  2001-09-12 13:32 ---
  The same problem occurs if the common\classes or server\classes directories 
! exist.
! 
! --- Additional Comments From [EMAIL PROTECTED]  2001-09-12 13:37 ---
! Created an attachment (id=530)
! [PATCH] Replaced "/" with File.separator

Re: Loading JSSE JARs from the Classpath

[Amy Roh]

It seems to work fine on Win2K.

Amy

"Craig R. McClanahan" wrote:

> Hmm, the fix I just committed (use the JSSE_HOME environment variable to
> add the JSSE jars to the system classpath used to start Tomcat) seems to
> work great on Linux, but fails on Win98 unless the JSSE jars are really
> installed as system extensions:
>
> Exception during startup processing
> java.lang.reflect.InvocationTargetException:
> java.lang.NoClassDefFoundError: javax/net/ssl/SSLServerSocketFactory
>   at java.lang.Class.forName0(Native Method)
>   at java.lang.Class.forName(Class.java:120)
>   at org.apache.catalina.util.xml.ObjectCreate.start(XmlMapper.java:616)
>   ...
>
> This is with JDK 1.3.0_02.  Could a couple of other Windows folks try this
> and see if they get the same results?
>
> Craig

[DO NOT REPLY: Bug 3576] BootstrapService throws exception on startup when classes directory is present

[bugzilla]

PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT
ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW
AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE
DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL
BE LOST SOMEWHERE.

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

*** shadow/3576 Wed Sep 12 13:23:03 2001
--- shadow/3576.tmp.19354   Wed Sep 12 13:32:08 2001
***
*** 32,34 
--- 32,39 
  --- Additional Comments From [EMAIL PROTECTED]  2001-09-12 13:23 ---
  Created an attachment (id=529)
  Output log
+ 
+ 
+ --- Additional Comments From [EMAIL PROTECTED]  2001-09-12 13:32 ---
+ The same problem occurs if the common\classes or server\classes directories 
+ exist.

cvs commit: jakarta-tomcat-4.0/tester/web/golden JspDoc01.txt

[craigmcc]

craigmcc01/09/12 13:26:31

  Modified:tester/src/bin tester.xml
  Added:   tester/web JspDoc01.jsp
   tester/web/golden JspDoc01.txt
  Log:
  Add unit test to verify correct behavior of parsing JSP documents without
  incorrect rearrangement of character and element data.  (Bugzilla #3350)
  
  Revision  ChangesPath
  1.68  +6 -0  jakarta-tomcat-4.0/tester/src/bin/tester.xml
  
  Index: tester.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/tester/src/bin/tester.xml,v
  retrieving revision 1.67
  retrieving revision 1.68
  diff -u -r1.67 -r1.68
  --- tester.xml2001/08/24 23:06:08 1.67
  +++ tester.xml2001/09/12 20:26:31 1.68
  @@ -547,6 +547,12 @@
request="${context.path}/Property02.jsp" debug="${debug}"
 status="500"/>
   
  +
  +
  +
  +
 
   
   
  
  
  
  1.1  jakarta-tomcat-4.0/tester/web/JspDoc01.jsp
  
  Index: JspDoc01.jsp
  ===
  http://java.sun.com/JSP/Page"; version="1.2">
text
text
text
text
text
text
  
  
  
  
  1.1  jakarta-tomcat-4.0/tester/web/golden/JspDoc01.txt
  
  Index: JspDoc01.txt
  ===
  texttexttexttexttexttext
  
  

cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler ParserXJspSaxHandler.java

[craigmcc]

craigmcc01/09/12 13:25:35

  Modified:jasper/src/share/org/apache/jasper/compiler
ParserXJspSaxHandler.java
  Log:
  Fix for Bugzilla #3350 (character data was rearranged in output).  Patch
  by Kin-Man Chung <[EMAIL PROTECTED]>
  
  PR: Bugzilla #3350
  Submitted by: Mark Abbott <[EMAIL PROTECTED]>
  
  Revision  ChangesPath
  1.14  +17 -2 
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/ParserXJspSaxHandler.java
  
  Index: ParserXJspSaxHandler.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/ParserXJspSaxHandler.java,v
  retrieving revision 1.13
  retrieving revision 1.14
  diff -u -r1.13 -r1.14
  --- ParserXJspSaxHandler.java 2001/04/27 18:09:31 1.13
  +++ ParserXJspSaxHandler.java 2001/09/12 20:25:35 1.14
  @@ -233,8 +233,9 @@
   
   // If previous node is a custom tag, call its
   // begin tag handler
  -if (!name.equals("jsp:root")) {
  -Node prevNode = (Node)stack.peek();
  +Node prevNode = null;
  +if (!stack.empty()) {
  +prevNode = (Node) stack.peek();
   if (prevNode instanceof NodeTag) {
   try {
   processCustomTagBeginDoIt((NodeTag) prevNode, true);
  @@ -273,6 +274,16 @@
}
if (!isCustomTag) {
// uninterpreted tag
  +// If the parent tag is also uninterpreted, then the
  +// characters have to be flushed, to preserve the order
  +// of the tags and characters that may appear in a XML
  +// fragment, such as xyz.
  +if ((prevNode != null) && prevNode.isUninterpretedTag() &&
  +(prevNode.getText() != null)) {
  +jspHandler.handleCharData(prevNode.start, start,
  +  prevNode.getText());
  +prevNode.clearText();
  +}
node.setUninterpreted(true);
jspHandler.handleUninterpretedTagBegin(node.start, 
   node.start, node.rawName, node.attrs);
  @@ -645,6 +656,10 @@
   return text == null 
? null
: text.toString().toCharArray();
  +}
  +
  +void clearText() {
  +text = null;
   }
   
boolean isRoot() {
  
  
  

[DO NOT REPLY: Bug 3576] BootstrapService throws exception on startup when classes directory is present

[bugzilla]

PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT
ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW
AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE
DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL
BE LOST SOMEWHERE.

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

*** shadow/3576 Wed Sep 12 13:22:48 2001
--- shadow/3576.tmp.19296   Wed Sep 12 13:23:03 2001
***
*** 27,29 
--- 27,34 
  --- Additional Comments From [EMAIL PROTECTED]  2001-09-12 13:22 ---
  Created an attachment (id=528)
  Error log
+ 
+ 
+ --- Additional Comments From [EMAIL PROTECTED]  2001-09-12 13:23 ---
+ Created an attachment (id=529)
+ Output log

[DO NOT REPLY: Bug 3576] BootstrapService throws exception on startup when classes directory is present

[bugzilla]

PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT
ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW
AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE
DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL
BE LOST SOMEWHERE.

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

*** shadow/3576 Wed Sep 12 13:21:54 2001
--- shadow/3576.tmp.19287   Wed Sep 12 13:22:48 2001
***
*** 22,25 
  correspond change was not made to BootstrapService.
  http://cvs.apache.org/viewcvs/jakarta-tomcat-
  4.0/catalina/src/share/org/apache/catalina/loader/StandardClassLoader.java.diff?
! r1=1.22&r2=1.23&diff_format=h
--- 22,29 
  correspond change was not made to BootstrapService.
  http://cvs.apache.org/viewcvs/jakarta-tomcat-
  4.0/catalina/src/share/org/apache/catalina/loader/StandardClassLoader.java.diff?
! r1=1.22&r2=1.23&diff_format=h
! 
! --- Additional Comments From [EMAIL PROTECTED]  2001-09-12 13:22 ---
! Created an attachment (id=528)
! Error log

[DO NOT REPLY: Bug 3576] New: BootstrapService throws exception on startup when classes directory is present

[bugzilla]

PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT
ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW
AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE
DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL
BE LOST SOMEWHERE.

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

*** shadow/3576 Wed Sep 12 13:21:54 2001
--- shadow/3576.tmp.19277   Wed Sep 12 13:21:54 2001
***
*** 0 
--- 1,25 
+ ++
+ | BootstrapService throws exception on startup when classes directory is pre |
+ ++
+ |Bug #: 3576Product: Tomcat 4|
+ |   Status: NEW Version: 4.0 Release Candidate 1 |
+ |   Resolution:Platform: PC  |
+ | Severity: Critical OS/Version: Windows NT/2K   |
+ | Priority: Other Component: Catalina|
+ ++
+ |  Assigned To: [EMAIL PROTECTED]|
+ |  Reported By: [EMAIL PROTECTED]  |
+ |  CC list: Cc:  |
+ ++
+ |  URL:  |
+ ++
+ |  DESCRIPTION   |
+ When starting Tomcat as a service on Windows 2000, BootstrapService throws an 
+ IllegalArgumentException on addRepositoryInternal method of StandardClassLoader 
+ when the classes directory is present.
+ 
+ This is because of a change made to StandardClassLoader for RC1 on Aug 15 but a 
+ correspond change was not made to BootstrapService.
+ http://cvs.apache.org/viewcvs/jakarta-tomcat-
+ 4.0/catalina/src/share/org/apache/catalina/loader/StandardClassLoader.java.diff?
+ r1=1.22&r2=1.23&diff_format=h

RE: Remaining Tomcat 3.3 Issues

[Keith Wannamaker]

Oops, yep, that fix only went into the _32 branch.
3.3 still uses r->uri.

IIRC the thread never reached a consensus, except that
a proxy is free to decode and encode requests, so
encode(r->uri) might be permissible, but r->unparsed_uri
is the only way to preserve the encoding.

Keith

| -Original Message-
| From: Larry Isaacs [mailto:[EMAIL PROTECTED]]
| Sent: Wednesday, September 12, 2001 3:19 PM
| To: '[EMAIL PROTECTED]'
| Subject: RE: Remaining Tomcat 3.3 Issues
| 
| 
| One of the main aspects of this issue is for me to 
| become informed as to the state of Tomcat 3.3's mod_jk
| with respect to this.  Tomcat 3.3's mod_jk.c has:

Re: Remaining Tomcat 3.3 Issues

[David Rees]

On Wed, Sep 12, 2001 at 03:19:15PM -0400, Larry Isaacs wrote:
> One of the main aspects of this issue is for me to 
> become informed as to the state of Tomcat 3.3's mod_jk
> with respect to this.  Tomcat 3.3's mod_jk.c has:
> 
> s->req_uri = r->uri;
> 
> which, by the statement below, appears to be "rewrite"
> enabled.  This might explain why it works for Bill.
> 
> I recall there being a discussion on tomcat-dev a
> while back about this, but I don't recall the final
> resolution, or if there was one. Formally establishing
> this "resolution"  for Tomcat 3.3 was my reason for
> including item 11.

Look at this thread (which I started) titled:
  [TC3.2.3][PATCH] mod_jk / mod_rewrite bug fix

You can see the whole thread here:
  http://marc.theaimsgroup.com/?t=9978407791&w=2&r=1

-Dave

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

[John Reilly]

Hi Remy,
Could you check out the patch I submitted a while ago for bug #3194 and
perhaps submit it - I haven't seen either positive or negative feedback on
it.

Thanks,
jr

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, September 09, 2001 6:30 PM
> To: [EMAIL PROTECTED]
> Subject: cvs commit: jakarta-tomcat-4.0/catalina build.xml
>
>
> remm01/09/09 18:29:40
>
>   Modified:catalina build.xml
>   Log:
>   - Path fix.
>   - Some javadoc warning fixes.
>
>   Revision  ChangesPath
>   1.55  +2 -2  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.54
>   retrieving revision 1.55
>   diff -u -r1.54 -r1.55
>   --- build.xml   2001/09/09 04:00:08 1.54
>   +++ build.xml   2001/09/10 01:29:40 1.55
>   @@ -30,7 +30,7 @@
>  
>  
>  
>   -  
>   +  
>   value="${regexp.home}/jakarta-regexp-1.2.jar"/>
>   value="${servletapi.home}/lib/servlet.jar"/>
>
>   @@ -205,7 +205,7 @@
>
>
>   -
> classpath="${parser.jar}:${jaxp.jar}:${jcert.jar}:${jsse.jar}:${jn
> et.jar}:${regexp.jar}:${jmxri.jar}:${servlet.jar}:${catalina.build
> }/classes"
>   +
> classpath="${parser.jar}:${jaxp.jar}:${jcert.jar}:${jsse.jar}:${jn
> et.jar}:${regexp.jar}:${jmxri.jar}:${servlet.jar}:${mail.jar}:${ac
> tivation.jar}:${catalina.build}/classes"
>   sourcepath="src/share"
>  destdir="${catalina.build}/javadoc"
>   author="true"
>
>
>
>

RE: Remaining Tomcat 3.3 Issues

[Larry Isaacs]

One of the main aspects of this issue is for me to 
become informed as to the state of Tomcat 3.3's mod_jk
with respect to this.  Tomcat 3.3's mod_jk.c has:

s->req_uri = r->uri;

which, by the statement below, appears to be "rewrite"
enabled.  This might explain why it works for Bill.

I recall there being a discussion on tomcat-dev a
while back about this, but I don't recall the final
resolution, or if there was one. Formally establishing
this "resolution"  for Tomcat 3.3 was my reason for
including item 11.

Thanks,
Larry

> -Original Message-
> From: Keith Wannamaker [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 12, 2001 3:11 PM
> To: [EMAIL PROTECTED]
> Subject: RE: Remaining Tomcat 3.3 Issues
> 
> 
> mod_jk uses (used?) r->unparsed_uri to preserve encoding.
> Therefore, any mod_rewrite munging of r->uri is invisible
> to mod_jk.  This is the issue to which Larry is referring,
> not Apache module ordering.
> 
> Keith
> 
> | -Original Message-
> | From: Bill Barker [mailto:[EMAIL PROTECTED]]
> | Sent: Wednesday, September 12, 2001 2:30 PM
> | To: [EMAIL PROTECTED]
> | Subject: Re: Remaining Tomcat 3.3 Issues
> | 
> | 
> | Re. 11)  I use mod_rewrite + mod_jk regularly without 
> problems.  The problem
> | is that the "out-of-the-box" model order puts mod_jk ahead 
> of mod_rewrite.
> | The trick to make them play happily together is to simply 
> re-order them in
> | httpd.conf.  Of course, this has the downside that you 
> can't use the file
> | generated by ApacheConfig verbatim.  But if you want 
> advanced functionality,
> | you have to expect to fiddle with the configuration.
> 

Re: Remaining Tomcat 3.3 Issues

[Bill Barker]

That's true of mod_jk in j-t-c.  At least through B2 the mod_jk that ships
with 3.3 uses r->uri.
- Original Message -
From: "Keith Wannamaker" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 12, 2001 12:11 PM
Subject: RE: Remaining Tomcat 3.3 Issues


> mod_jk uses (used?) r->unparsed_uri to preserve encoding.
> Therefore, any mod_rewrite munging of r->uri is invisible
> to mod_jk.  This is the issue to which Larry is referring,
> not Apache module ordering.
>
> Keith
>
> | -Original Message-
> | From: Bill Barker [mailto:[EMAIL PROTECTED]]
> | Sent: Wednesday, September 12, 2001 2:30 PM
> | To: [EMAIL PROTECTED]
> | Subject: Re: Remaining Tomcat 3.3 Issues
> |
> |
> | Re. 11)  I use mod_rewrite + mod_jk regularly without problems.  The
problem
> | is that the "out-of-the-box" model order puts mod_jk ahead of
mod_rewrite.
> | The trick to make them play happily together is to simply re-order them
in
> | httpd.conf.  Of course, this has the downside that you can't use the
file
> | generated by ApacheConfig verbatim.  But if you want advanced
functionality,
> | you have to expect to fiddle with the configuration.
>
>


**

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. 

Novell LDAP Realm

[John Wheeler]

Hello all,

I am new to Tomcat and open source development, and I would like to know if there is 
interest in an LDAP Realm similar to Peachtree's but using 
Novell LDAP instead of Netscape. Functionally, the vendor api's are the
same (for authentication anyway) except there are a few method signitures differences. 
 I haven't done enough research, but here is my vision:

Use the DAO (Data Access Object)  design pattern  in conjunction with abstract 
factory, I would like to provide a novell implementation of ldap realms conforming to 
peachtree's interfaces... if this is possible.

Would this type of development (or some variant of) be of interest?

John Wheeler

RE: Remaining Tomcat 3.3 Issues

[Keith Wannamaker]

mod_jk uses (used?) r->unparsed_uri to preserve encoding.
Therefore, any mod_rewrite munging of r->uri is invisible
to mod_jk.  This is the issue to which Larry is referring,
not Apache module ordering.

Keith

| -Original Message-
| From: Bill Barker [mailto:[EMAIL PROTECTED]]
| Sent: Wednesday, September 12, 2001 2:30 PM
| To: [EMAIL PROTECTED]
| Subject: Re: Remaining Tomcat 3.3 Issues
| 
| 
| Re. 11)  I use mod_rewrite + mod_jk regularly without problems.  The problem
| is that the "out-of-the-box" model order puts mod_jk ahead of mod_rewrite.
| The trick to make them play happily together is to simply re-order them in
| httpd.conf.  Of course, this has the downside that you can't use the file
| generated by ApacheConfig verbatim.  But if you want advanced functionality,
| you have to expect to fiddle with the configuration.

RE: Bug in TC 3.3 DependClassLoader

[Larry Isaacs]

Hi Bojan,

Costin is the expert on this section of code.  I need to become
more familiar with it, so I'm willing to take a look.  If you can
submit a patch, that would be helpful.  If you need to wait for
Costin's advice, I understand.  On occasion, I have had to do
the same.

Cheers,
Larry

> -Original Message-
> From: Bojan Smojver [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 12, 2001 8:10 AM
> To: Tomcat Dev List
> Subject: Bug in TC 3.3 DependClassLoader
> 
> 
> Since I was playing with distributing all my apps in jars...
> 
> In method dependency() of that class, there is a section for jars. It
> goes something like this:
> 
> 
> if( "jar".equals( res.getProtocol() )) {
> String fileN=res.getFile();
> int idx=fileN.indexOf( "!" );
> if( idx>=0 )
> fileN=fileN.substring( 0, idx) ;
> f=new File( fileN );
> if( debug > 0 ) log( "Jar dep "  +f );
> if( ! f.exists()) f=null;
> }
> 
> if( f==null ) return;
> Dependency dep=new Dependency();
> dep.setLastModified( f.lastModified() );
> dep.setTarget( c );
> dep.setOrigin( f );
> 
> dependM.addDependency( dep );
> 
> 
> So if the res is:
> 
> 
> jar:file:/home/httpd/html/binarix.dev/WEB-INF/lib/app.jar!/com
> /binarix/wpm/ParseXML.class
> 
> 
> then fileN after res.getFile() is:
> 
> 
> file:/home/httpd/html/binarix.dev/WEB-INF/lib/app.jar!/com/bin
arix/wpm/ParseXML.class


and after tossing everything after the bang, it becomes:


file:/home/httpd/html/binarix.dev/WEB-INF/lib/app.jar


which is NOT a file (a URL maybe?), so f.exists() returns false and f
becomes null. The method dependency() returns without adding the jar in
question to the list of dependencies. Aie!

Maybe there should be another 'file' section inside the 'jar' section to
resolve that URL?

If you guys think that'd work OK, I can write a little patch...

Bojan

Re: Remaining Tomcat 3.3 Issues

[Bill Barker]

Re. 11)  I use mod_rewrite + mod_jk regularly without problems.  The problem
is that the "out-of-the-box" model order puts mod_jk ahead of mod_rewrite.
The trick to make them play happily together is to simply re-order them in
httpd.conf.  Of course, this has the downside that you can't use the file
generated by ApacheConfig verbatim.  But if you want advanced functionality,
you have to expect to fiddle with the configuration.
- Original Message -
From: "Larry Isaacs" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 12, 2001 8:31 AM
Subject: Remaining Tomcat 3.3 Issues


> Hi All,
>
> I have made a pass through all Tomcat3 bugs.  Those listed below
> are the only ones that remain open as of last night.  Listed for
> RC1 and RC2 are issues I have accumulated as well as bugs that must
> be resolved.
>
> Each of these issues needs to be considered according to its
> impact on the stability of Tomcat 3.3.  I think most of the bugs
> are already fixed, but I need someone more familiar with the
> code to make a more informed assessment about the appropriate
> resolution.
>
> I am going ahead and posting this even though I haven't spent much
> time trying to identify which of these I consider showstoppers
> (mainly due to dancing late into the night with Bugzilla).
> At this moment, by default I don't consider any of these
> showstoppers.  I will try to review this and post my opinions later,
> probably tomorrow. Others are welcome to offer their opinions in this
> regard.
>
> = Tomcat 3.3 Release Issues =
>
> To Be Addressed for RC1:
>
> 1. HttpSessionFacade.setAttribute() isn't synchronized.  If a second
request
> called "setAttribute()" after this request's "removeAttribute()" and
before
> "realSession.setAttribute()", the second request's value would be
overwritten
> without an valueUnbound() being called.
>
> 2. Evaluate Tomcat 3.3's vulnerability to "Double Checked Locking". This
> is referred to in Bug #177. See:
> http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
> for details.  I think ServletHandler.init() is currently subject to this
> vulnerability.
>
> 3. The spec doesn't address whether a the form-login-page and
form-error-page
> should be excluded from the security-constraint, but it makes sense that
> it should.  It might be best to postpone this.
>
> 4. Address user authentication via Ajp12 and Ajp13.  Ajp12 has a test for
> isTomcatAuthentication() to see if req.setRemoteUser() should be called.
> I think Ajp13 doesn't have this yet and probably should.  Also, if the
> user is anonymous, i.e. user = "", should we call req.setRemoteUser()
> with this value?  This prevents Tomcat's normal authentication from being
> triggered.
>
> 5. If a error handler is not found for an exception, check the root cause
> as well if it is a ServletException.  This is mentioned in Bug 3233.  I
think
> it would be a good idea to apply this.  I don't think we are prohibited
> by the spec.  We could add an option to be safe if there is concern.
>
> 6. StaticInterceptor is missing a localization enhancement added to
> Tomcat 3.2.x.  Should this enhancement be ported to Tomcat 3.3?  Is
> this still considered a regression, though it isn't part of the
> Servlet 2.2/JSP 1.1 spec?
>
> 7. Evaluate whether anything should be done to deal with the use of
> non-thread-safe DateFormat and related classes.
>
> Must Resolve Bugs:
>
> 177   Race condition during servlet initialization BugRat Report#2
> 182   JSP error-page doesn't work with virtual hosts BugRat Report
> 274   request.getUserPrincipal() doesn't work when user is authent
> 437   req.getParameter(name) Ignores charset. always assumes ISO88
> 461   Use setCharacterEncoding("UTF8") does not change the way get
> 463   Ctx( /examples ): IOException in: R( /examples + + null) No
> 1253  Frequent Connection reset by peer errors
> 1482  Ignored session ids in encoded URLs
> 1663  Tomcat -SSL problem
> 1798  Tomcat 3.2.2b5 with Apache and ajp13 stops responding after
> 3233  exception handling wrt errorpages seems to be incorrect
> 3486 Session problem (with case insensitive context matching on windows)
>
>
>
> To Be Addressed by RC2:
>
> 8. We need to remove or optionally disable the shutdown support in
> Ajp13Interceptor.  This allows configuring a password protected
> Ajp12Interceptor shutdown to be the only shutdown available.
>
> 9. Some files under src/native have embedded CR's, i.e. Unix files would
have
> CRLF and Windows files would have CRCRLF's.  These need to be fixed.
>
> 10. The jk_nt_service, and I assume jniconnect, redirect stdout and stderr
to
> files.  With the default server.xml with no path for tc_log, Tomcat's
> startup output ends up in the "stderr" log. I would have expected it to
> be in the "stdout" log.  Is there a reason the o.a.t.u.qlog.Logger uses
> stderr as the default sink instead of stdout?
>
> 11. Make sure we are okay with mod_jk not supporting Apache's rewrite
> in Tomcat 3.3's m

[PATH] XML fragments in jsp handled incorrectly

[Kin-Man Chung]

This patch fixes #3350.  In a JSP document, the tags in a XML fragment are
always generated before the characters.  The current fix preserves their
orders.

misto% runsocks cvs diff -u ParserXJspSaxHandler.java
Index: ParserXJspSaxHandler.java
===
RCS file: 
/home/cvspublic/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/P
arserXJspSaxHandler.java,v
retrieving revision 1.13
diff -u -r1.13 ParserXJspSaxHandler.java
--- ParserXJspSaxHandler.java   2001/04/27 18:09:31 1.13
+++ ParserXJspSaxHandler.java   2001/09/12 18:33:59
@@ -233,8 +233,9 @@
 
 // If previous node is a custom tag, call its
 // begin tag handler
-if (!name.equals("jsp:root")) {
-Node prevNode = (Node)stack.peek();
+Node prevNode = null;
+   if (!stack.empty()) {
+   prevNode = (Node)stack.peek();
 if (prevNode instanceof NodeTag) {
 try {
 processCustomTagBeginDoIt((NodeTag) prevNode, true);
@@ -273,6 +274,16 @@
}
if (!isCustomTag) {
// uninterpreted tag
+   // If the parent tag is also uninterpreted, then the
+   // characters have to be flushed, to preserve the order
+   // of the tags and charaters that may appear in a XML
+   // fragment, such as xyz
+   if (prevNode != null && prevNode.isUninterpretedTag() &&
+   prevNode.getText() != null) {
+   jspHandler.handleCharData(prevNode.start, start,
+   prevNode.getText());
+   prevNode.clearText();
+   }
node.setUninterpreted(true);
jspHandler.handleUninterpretedTagBegin(node.start, 
 node.start, node.rawName, node.attrs);
@@ -646,6 +657,10 @@
? null
: text.toString().toCharArray();
 }
+
+   void clearText() {
+   text = null;
+   }
 
boolean isRoot() {
return isRoot;

RE: New resource: Bugs every servlet programmer should know about

[Marc Saegesser]

Jason,

The first bug in the list, about file upload problems with AJP13 was fixed
in 3.2.3.


Marc Saegesser

> -Original Message-
> From: Jason Hunter [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, September 11, 2001 12:11 AM
> To: [EMAIL PROTECTED]
> Subject: New resource: Bugs every servlet programmer should know about
>
>
> I just posted on Servlets.com a new resource listing the top bugs a
> servlet/JSP programmer should know about.  They're culled from my email
> inbox, based on the most
> frequently reported problems sent to me by users.  Several directly
> involve Apache/Tomcat, so I thought this would be a good forum in which
> to post a mention.
>
> http://www.servlets.com/soapbox/bugs.html
>
> If you know of other similarly "high profile bugs", please let me know.
>
> -jh-

Loading JSSE JARs from the Classpath

[Craig R. McClanahan]

Hmm, the fix I just committed (use the JSSE_HOME environment variable to
add the JSSE jars to the system classpath used to start Tomcat) seems to
work great on Linux, but fails on Win98 unless the JSSE jars are really
installed as system extensions:

Exception during startup processing
java.lang.reflect.InvocationTargetException:
java.lang.NoClassDefFoundError: javax/net/ssl/SSLServerSocketFactory
  at java.lang.Class.forName0(Native Method)
  at java.lang.Class.forName(Class.java:120)
  at org.apache.catalina.util.xml.ObjectCreate.start(XmlMapper.java:616)
  ...

This is with JDK 1.3.0_02.  Could a couple of other Windows folks try this
and see if they get the same results?

Craig

Re: Remaining Tomcat 3.3 Issues

[Bill Barker]

Sorry for the typo. Yes, it should be 1482.
- Original Message - 
From: "Larry Isaacs" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 12, 2001 11:08 AM
Subject: RE: Remaining Tomcat 3.3 Issues


> Hi Bill,
> 
> Thanks for the help.  1483 doesn't match a bug number though.  Was it:
> 
> 1482  Ignored session ids in encoded URLs
> 
> Thanks,
> Larry
> 
> > -Original Message-
> > From: Bill Barker [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, September 12, 2001 1:21 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Remaining Tomcat 3.3 Issues
> > 
> > 
> > As I expected (having spent enough time on encoded URLs), I 
> > can't reproduce
> > 1483 against B2.  It always finds the correct session both in 
> > stand-alone
> > and Ajp13.
> 
> 


**

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 3574] New: Basic authentication doesn't work.

[bugzilla]

PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT
ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW
AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE
DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL
BE LOST SOMEWHERE.

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

*** shadow/3574 Wed Sep 12 11:13:35 2001
--- shadow/3574.tmp.18786   Wed Sep 12 11:13:35 2001
***
*** 0 
--- 1,18 
+ ++
+ | Basic authentication doesn't work. |
+ ++
+ |Bug #: 3574Product: Tomcat 4|
+ |   Status: NEW Version: Nightly Build   |
+ |   Resolution:Platform: All |
+ | Severity: Critical OS/Version: All |
+ | Priority: Other Component: Connectors  |
+ ++
+ |  Assigned To: [EMAIL PROTECTED]|
+ |  Reported By: [EMAIL PROTECTED] |
+ |  CC list: Cc:  |
+ ++
+ |  URL:  |
+ ++
+ |  DESCRIPTION   |
+ HTTP-Basic authentication does not work (still) with mod_webapp under 
+ Apache 1.3.

RE: Remaining Tomcat 3.3 Issues

[Larry Isaacs]

Hi Bill,

Thanks for the help.  1483 doesn't match a bug number though.  Was it:

1482  Ignored session ids in encoded URLs

Thanks,
Larry

> -Original Message-
> From: Bill Barker [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 12, 2001 1:21 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Remaining Tomcat 3.3 Issues
> 
> 
> As I expected (having spent enough time on encoded URLs), I 
> can't reproduce
> 1483 against B2.  It always finds the correct session both in 
> stand-alone
> and Ajp13.

RE: Remaining Tomcat 3.3 Issues

[Larry Isaacs]

I'll take a look.  Since jk_nt_service isn't really involved in
the stability of the Tomcat 3.3 server.  I think this patch
could appear in RC2 as well.  Avaiable sooner as a nightly.
I'll try to address it for RC1, though.

Larry

> -Original Message-
> From: David Oxley [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 12, 2001 12:01 PM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Remaining Tomcat 3.3 Issues
> 
> 
> Larry,
> 
> Any chance of committing the attached patch before 3.3rc1. It makes
> jk_nt_service maintain a list of currently installed services in the
> registry. This is so the Service Manager I have written can 
> work. I will be
> submitting the Service Manager in a few hours for committing in
> jakarta-tomcat-service (?? Or wherever appropriate) and I will build a
> binary for the 3.3rc1 release.
> 
> Dave
> [EMAIL PROTECTED]
> 
> -Original Message-
> From: Larry Isaacs [mailto:[EMAIL PROTECTED]]
> Sent: 12 September 2001 16:31
> To: '[EMAIL PROTECTED]'
> Subject: Remaining Tomcat 3.3 Issues
> 
> Hi All,
> 
> I have made a pass through all Tomcat3 bugs.  Those listed below
> are the only ones that remain open as of last night.  Listed for
> RC1 and RC2 are issues I have accumulated as well as bugs that must
> be resolved.
> 
> 
> 
> 

Re: Remaining Tomcat 3.3 Issues

[Bill Barker]

As I expected (having spent enough time on encoded URLs), I can't reproduce
1483 against B2.  It always finds the correct session both in stand-alone
and Ajp13.
- Original Message -
From: "Larry Isaacs" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, September 12, 2001 8:31 AM
Subject: Remaining Tomcat 3.3 Issues


> Hi All,
>
> I have made a pass through all Tomcat3 bugs.  Those listed below
> are the only ones that remain open as of last night.  Listed for
> RC1 and RC2 are issues I have accumulated as well as bugs that must
> be resolved.
>
> Each of these issues needs to be considered according to its
> impact on the stability of Tomcat 3.3.  I think most of the bugs
> are already fixed, but I need someone more familiar with the
> code to make a more informed assessment about the appropriate
> resolution.
>
> I am going ahead and posting this even though I haven't spent much
> time trying to identify which of these I consider showstoppers
> (mainly due to dancing late into the night with Bugzilla).
> At this moment, by default I don't consider any of these
> showstoppers.  I will try to review this and post my opinions later,
> probably tomorrow. Others are welcome to offer their opinions in this
> regard.
>
> = Tomcat 3.3 Release Issues =
>
> To Be Addressed for RC1:
>
> 1. HttpSessionFacade.setAttribute() isn't synchronized.  If a second
request
> called "setAttribute()" after this request's "removeAttribute()" and
before
> "realSession.setAttribute()", the second request's value would be
overwritten
> without an valueUnbound() being called.
>
> 2. Evaluate Tomcat 3.3's vulnerability to "Double Checked Locking". This
> is referred to in Bug #177. See:
> http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
> for details.  I think ServletHandler.init() is currently subject to this
> vulnerability.
>
> 3. The spec doesn't address whether a the form-login-page and
form-error-page
> should be excluded from the security-constraint, but it makes sense that
> it should.  It might be best to postpone this.
>
> 4. Address user authentication via Ajp12 and Ajp13.  Ajp12 has a test for
> isTomcatAuthentication() to see if req.setRemoteUser() should be called.
> I think Ajp13 doesn't have this yet and probably should.  Also, if the
> user is anonymous, i.e. user = "", should we call req.setRemoteUser()
> with this value?  This prevents Tomcat's normal authentication from being
> triggered.
>
> 5. If a error handler is not found for an exception, check the root cause
> as well if it is a ServletException.  This is mentioned in Bug 3233.  I
think
> it would be a good idea to apply this.  I don't think we are prohibited
> by the spec.  We could add an option to be safe if there is concern.
>
> 6. StaticInterceptor is missing a localization enhancement added to
> Tomcat 3.2.x.  Should this enhancement be ported to Tomcat 3.3?  Is
> this still considered a regression, though it isn't part of the
> Servlet 2.2/JSP 1.1 spec?
>
> 7. Evaluate whether anything should be done to deal with the use of
> non-thread-safe DateFormat and related classes.
>
> Must Resolve Bugs:
>
> 177   Race condition during servlet initialization BugRat Report#2
> 182   JSP error-page doesn't work with virtual hosts BugRat Report
> 274   request.getUserPrincipal() doesn't work when user is authent
> 437   req.getParameter(name) Ignores charset. always assumes ISO88
> 461   Use setCharacterEncoding("UTF8") does not change the way get
> 463   Ctx( /examples ): IOException in: R( /examples + + null) No
> 1253  Frequent Connection reset by peer errors
> 1482  Ignored session ids in encoded URLs
> 1663  Tomcat -SSL problem
> 1798  Tomcat 3.2.2b5 with Apache and ajp13 stops responding after
> 3233  exception handling wrt errorpages seems to be incorrect
> 3486 Session problem (with case insensitive context matching on windows)
>
>
>
> To Be Addressed by RC2:
>
> 8. We need to remove or optionally disable the shutdown support in
> Ajp13Interceptor.  This allows configuring a password protected
> Ajp12Interceptor shutdown to be the only shutdown available.
>
> 9. Some files under src/native have embedded CR's, i.e. Unix files would
have
> CRLF and Windows files would have CRCRLF's.  These need to be fixed.
>
> 10. The jk_nt_service, and I assume jniconnect, redirect stdout and stderr
to
> files.  With the default server.xml with no path for tc_log, Tomcat's
> startup output ends up in the "stderr" log. I would have expected it to
> be in the "stdout" log.  Is there a reason the o.a.t.u.qlog.Logger uses
> stderr as the default sink instead of stdout?
>
> 11. Make sure we are okay with mod_jk not supporting Apache's rewrite
> in Tomcat 3.3's mod_jk.  I'm fine with not supporting it, but I want
> to include some justification in the documentation to avoid some of
> the "why don't you" questions.
>
> 12. To simplify upgrade development, I would like to see the classpath
> for the "container", "common", and "ap

Re: [PATCH] SSLServerSocketFactory.java

[Craig R. McClanahan]

As you can see from the commit messages, I committed a variation on your
#1 approach that lets you define a JSSE_HOME environment variable to
locate the JSSE jar files.  Coupled with registering the provider
automatically (your #2 approach), this simplifies the process of getting
set up to use SSL on Tomcat 4.  Thanks for the patches!

Craig


On Mon, 10 Sep 2001, Wolfgang Hoschek wrote:

> Date: Mon, 10 Sep 2001 16:50:26 +0200
> From: Wolfgang Hoschek <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: [PATCH] SSLServerSocketFactory.java
>
> It itched me a lot that to enable SSL in TC4 a standard JDK has to be modified
> (copy JSSE libs into jdk/jre/lib/ext and add
> security.provider.3=com.sun.net.ssl.internal.ssl.Provider).
> This was not necessary in TC 3.2.x because of different class loading
> semantics.
> In our environment jdks cannot well be modified due to separate JDKs/archs,
> TCs, JSSEs, etc on shared read-only filesystems.
>
> So here are three TC4 patches (against the latest CVS) that allow JSSE to
> be picked up from anywhere on the filesystem.
> Patches are along the lines Craig suggested yesterday.
> 1) Modify catalina.sh and catalina.bat as indicated below to be able to add
> external jars to the system classpath (new env var CATALINA_SYSTEM_CLASSPATH).
> 2) Modify
> 
>jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/net/SSLServerSocketFactory.java
> to dynamically add the com.sun.net.ssl.internal.ssl.Provider provider
>
> In case you don't like 1) because it allows external things to be added,
> then 2) is still of value because people don't need to write their own
> SSLServerSocketFactory
> Hope someone wants to try this out and commit before 4.0 FCS.
> Wolfgang.
>
> --- SSLServerSocketFactory.java.orig  Fri Sep  7 20:39:08 2001
> +++ SSLServerSocketFactory.java   Mon Sep 10 15:31:16 2001
> @@ -386,6 +386,14 @@
>   Security.addProvider(new sun.security.provider.Sun());
>   Security.addProvider(new
> com.sun.net.ssl.internal.ssl.Provider());
>   */
> +// even if jsse provider is already installed it can't hurt to
> make sure
> +// and we do need to install it here if it isn't hard-wired in
> jdk/jre/lib/security/java.security
> +try {
> +
> java.security.Security.addProvider(((java.security.Provider)
> Class.forName("com.sun.net.ssl.internal.ssl.Provider").newInstance()));
> +}
> +catch (IllegalAccessException exc) {}
> +catch (ClassNotFoundException exc) {}
> +catch (InstantiationException exc) {}
>
>   // Create an SSL context used to create an SSL socket factory
>   SSLContext context = SSLContext.getInstance(protocol);
>
>
>
> --- jakarta-tomcat-4.0/catalina/src/bin/catalina.sh.orig  Sat Sep  8
> 12:13:28 2001
> +++ jakarta-tomcat-4.0/catalina/src/bin/catalina.sh   Mon Sep 10 16:28:25 2001
> @@ -70,6 +70,12 @@
> CP=$CP:"$JAVA_HOME/lib/tools.jar"
>   fi
>
> +# add CATALINA_SYSTEM_CLASSPATH custom jars to classpath. For example define
> +# export
> 
>CATALINA_SYSTEM_CLASSPATH=/path/to/jsse/lib/jsse.jar:/path/to/jsse/lib/jnet.jar:/path/to/jsse/lib/jcert.jar
> +if [ ! -z "$CATALINA_SYSTEM_CLASSPATH" ] ; then
> +  CP=$CP:$CATALINA_SYSTEM_CLASSPATH
> +fi
> +
>   # convert the existing path to windows
>   if [ "$OSTYPE" = "cygwin32" ] || [ "$OSTYPE" = "cygwin" ] ; then
>  CP=`cygpath --path --windows "$CP"`
>
>
>
>
>
>
> --- jakarta-tomcat-4.0/catalina/src/bin/catalina.bat.orig Mon Aug 27
> 21:10:25 2001
> +++ jakarta-tomcat-4.0/catalina/src/bin/catalina.bat  Mon Sep 10 16:16:43 2001
> @@ -65,6 +65,11 @@
>   rem - Set Up The Runtime Classpath
> 
>
>   set CP=%CATALINA_HOME%\bin\bootstrap.jar;%JAVA_HOME%\lib\tools.jar
> +
> +# add CATALINA_SYSTEM_CLASSPATH custom jars to classpath. For example define
> +# set
> 
>CATALINA_SYSTEM_CLASSPATH=\path\to\jsse\lib\jsse.jar;\path\to\jsse\lib\jnet.jar;\path\to\jsse\lib\jcert.jar
> +set CP=%CP%;%CATALINA_SYSTEM_CLASSPATH%
> +
>   set CLASSPATH=%CP%
>   echo Using CATALINA_BASE: %CATALINA_BASE%
>   echo Using CATALINA_HOME: %CATALINA_HOME%

cvs commit: jakarta-tomcat-4.0/webapps/tomcat-docs ssl-howto.xml

[craigmcc]

craigmcc01/09/12 10:38:47

  Modified:catalina/src/bin catalina.bat catalina.sh
   webapps/tomcat-docs ssl-howto.xml
  Log:
  Simplify the process of installing SSL support by the following actions:
  * Have SSLSocketFactory register the JSSE provider if needed
(see previous commit)
  * Have "catalina.bat" and "catalina.sh" automatically add the JSSE JAR
files to the system classpath used to start Tomcat, if an environment
variable named "JSSE_HOME" is defined.
  * Trimmed out the steps that are no longer needed from the HOW-TO docs.
  
  Submitted by: Wolfgang Hoschek <[EMAIL PROTECTED]>
  
  Revision  ChangesPath
  1.18  +10 -2 jakarta-tomcat-4.0/catalina/src/bin/catalina.bat
  
  Index: catalina.bat
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/bin/catalina.bat,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- catalina.bat  2001/08/27 19:10:25 1.17
  +++ catalina.bat  2001/09/12 17:38:47 1.18
  @@ -16,7 +16,11 @@
   rem
   rem   JAVA_HOME Must point at your Java Development Kit installation.
   rem
  -rem $Id: catalina.bat,v 1.17 2001/08/27 19:10:25 craigmcc Exp $
  +rem   JSSE_HOME (Optional) May point at your Java Secure Sockets Extension
  +rem (JSSE) installation, whose JAR files will be added to the
  +rem system class path used to start Tomcat.
  +rem
  +rem $Id: catalina.bat,v 1.18 2001/09/12 17:38:47 craigmcc Exp $
   rem ---
   
   
  @@ -65,10 +69,14 @@
   rem - Set Up The Runtime Classpath 
   
   set CP=%CATALINA_HOME%\bin\bootstrap.jar;%JAVA_HOME%\lib\tools.jar
  +if "%JSSE_HOME%" == "" goto noJsse
  +set CP=%CP%;%JSSE_HOME%\lib\jcert.jar;%JSSE_HOME%\lib\jnet.jar;%JSSE_HOME%\jsse.jar
  +:noJsse
   set CLASSPATH=%CP%
   echo Using CATALINA_BASE: %CATALINA_BASE%
   echo Using CATALINA_HOME: %CATALINA_HOME%
  -echo Using CLASSPATH: %CLASSPATH%
  +echo Using CLASSPATH: %CLASSPATH%
  +echo Using JAVA_HOME: %JAVA_HOME%
   
   
   rem - Execute The Requested Command ---
  
  
  
  1.19  +8 -1  jakarta-tomcat-4.0/catalina/src/bin/catalina.sh
  
  Index: catalina.sh
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/bin/catalina.sh,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- catalina.sh   2001/09/12 00:54:28 1.18
  +++ catalina.sh   2001/09/12 17:38:47 1.19
  @@ -20,7 +20,11 @@
   # command is executed.  Defaults to
   # "-classic -Xdebug -Xnoagent 
-Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n"
   #
  -# $Id: catalina.sh,v 1.18 2001/09/12 00:54:28 craigmcc Exp $
  +#   JSSE_HOME (Optional) May point at your Java Secure Sockets Extension
  +# (JSSE) installation, whose JAR files will be added to the
  +# system class path used to start Tomcat.
  +#
  +# $Id: catalina.sh,v 1.19 2001/09/12 17:38:47 craigmcc Exp $
   # -
   
   
  @@ -86,6 +90,9 @@
   
   if [ -f "$JAVA_HOME/lib/tools.jar" ] ; then
 CP=$CP:"$JAVA_HOME/lib/tools.jar"
  +fi
  +if [ -f "$JSSE_HOME/lib/jsse.jar" ] ; then
  +  
CP=$CP:"$JSSE_HOME/lib/jcert.jar":"$JSSE_HOME/lib/jnet.jar":"$JSSE_HOME/lib/jsse.jar"
   fi
   
   
  
  
  
  1.7   +15 -62jakarta-tomcat-4.0/webapps/tomcat-docs/ssl-howto.xml
  
  Index: ssl-howto.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/webapps/tomcat-docs/ssl-howto.xml,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- ssl-howto.xml 2001/09/07 18:39:08 1.6
  +++ ssl-howto.xml 2001/09/12 17:38:47 1.7
  @@ -31,20 +31,14 @@
   
   Download JSSE 1.0.2 (or later) from
  http://java.sun.com/products/jsse/";>http://java.sun.com/products/jsse/
  -   and either make it an installed extension on the system, or else add it
  -   to the classpath being passed to Tomcat in the Catalina startup script.
  -
  +   and either make it an installed extension on the system, or else
  +   set an environment variable JSSE_HOME that points at the
  +   directory into which you installed JSSE.
   Create a certificate keystore by executing the following command:
   
   keytool -genkey -alias tomcat -keyalg RSA
   
   and specify a password value of "changeit".
  -Edit $JAVA_HOME/jre/lib/security/java.security and add
  -
  -security.provider.2=com.sun.net.ssl.internal.ssl.Provider
  -
  -(if you already have a security.provider.2 entry, use the
  -next available numeric identifier).
   Uncomment the "SSL HT

Re: Remaining Tomcat 3.3 Issues

[Christopher Cain]

Larry Isaacs wrote:
> I would like to have the "tomcatAuthentication" hack
> available in Ajp13 so this behavior is fully controllable.
> 
> Also, I'm also leaning toward having a default of "true".
> To get the "security" example working when using Apache,
> or other web server, users would have to discover the user
> names and passwords provided by default.  I prefer this
> over requiring they add their own user name(s) and roles.

+1

> Hopefully they would have the sense not to enter a *real*
> password in clear text, but who knows.

I think that might be hoping too much, which is why I agree with your 
assessment.

> Larry
> 
> 
> 
>>-Original Message-
>>From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]]
>>Sent: Wednesday, September 12, 2001 11:54 AM
>>To: '[EMAIL PROTECTED]'
>>Subject: RE: Remaining Tomcat 3.3 Issues
>>
>>
>>
>>>4. Address user authentication via Ajp12 and Ajp13.  Ajp12 
>>>has a test for
>>>isTomcatAuthentication() to see if req.setRemoteUser() should 
>>>be called.
>>>I think Ajp13 doesn't have this yet and probably should.  
>>>
>>Also, if the
>>
>>>user is anonymous, i.e. user = "", should we call 
>>>
>>req.setRemoteUser()
>>
>>>with this value?  This prevents Tomcat's normal 
>>>authentication from being
>>>triggered.
>>>
>>>
>>
>>I have this code prepared for commit, implementing the
>>tomcatAuthentication hack in ajp13.
>>
>>But i've planned to change the hack only testing the received 
>>string for
>>emptyness and not calling setRemoteUser in the case, i think this will
>>render the tomcatAuthentication hack useless... 
>>
>>But perhaps the better is as you say, honor IsTomcatAuthentication and
>>not calling setRemoteUser for the empty string case.. 
>>
>>But i cannot think of a usecase in which were needed to 
>>obviate an auth
>>done in HTTP Server and honor another done in the Servlet container..
>>
>>
>>Saludos ,
>>Ignacio J. Ortega
>>
>>


-- 
- Christopher

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

Re: Remaining Tomcat 3.3 Issues

[jean-frederic clere]

David Oxley wrote:
> 
> Larry,
> 
> Any chance of committing the attached patch before 3.3rc1. It makes
> jk_nt_service maintain a list of currently installed services in the
> registry. This is so the Service Manager I have written can work. I will be
> submitting the Service Manager in a few hours for committing in
> jakarta-tomcat-service (?? Or wherever appropriate)

Would be nice - But the code in jakarta-tomcat-service is quite "a work in
progress" (Do not get afraid!;-)).

> and I will build a
> binary for the 3.3rc1 release.
> 
> Dave
> [EMAIL PROTECTED]
> 
> -Original Message-
> From: Larry Isaacs [mailto:[EMAIL PROTECTED]]
> Sent: 12 September 2001 16:31
> To: '[EMAIL PROTECTED]'
> Subject: Remaining Tomcat 3.3 Issues
> 
> Hi All,
> 
> I have made a pass through all Tomcat3 bugs.  Those listed below
> are the only ones that remain open as of last night.  Listed for
> RC1 and RC2 are issues I have accumulated as well as bugs that must
> be resolved.
> 
>   
> 
>ntservice.diffName: ntservice.diff
>  Type: unspecified type (application/octet-stream)

[DO NOT REPLY: Bug 3570] info page reporting wrong server port when using with apache-2.0

[bugzilla]

PLEASE DO NOT REPLY TO THIS MESSAGE. TO FURTHER COMMENT
ON THE STATUS OF THIS BUG PLEASE FOLLOW THE LINK BELOW
AND USE THE ON-LINE APPLICATION. REPLYING TO THIS MESSAGE
DOES NOT UPDATE THE DATABASE, AND SO YOUR COMMENT WILL
BE LOST SOMEWHERE.

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

*** shadow/3570 Wed Sep 12 09:45:42 2001
--- shadow/3570.tmp.18610   Wed Sep 12 10:31:02 2001
***
*** 7,13 
  | Severity: Normal   OS/Version: Windows NT/2K   |
  | Priority: Other Component: Webapps |
  ++
! |  Assigned To: [EMAIL PROTECTED]|
  |  Reported By: [EMAIL PROTECTED] |
  ++
  |  URL:  |
--- 7,13 
  | Severity: Normal   OS/Version: Windows NT/2K   |
  | Priority: Other Component: Webapps |
  ++
! |  Assigned To: [EMAIL PROTECTED] |
  |  Reported By: [EMAIL PROTECTED] |
  ++
  |  URL:  |
***
*** 20,23 
  it seems that apr_socaddr_port_get() do htons() by itself,
  so mod_webapp.c do extra htons() in wam_invoke()
  
! webapp module was taken from cvs on 11.09
--- 20,26 
  it seems that apr_socaddr_port_get() do htons() by itself,
  so mod_webapp.c do extra htons() in wam_invoke()
  
! webapp module was taken from cvs on 11.09
! 
! --- Additional Comments From [EMAIL PROTECTED]  2001-09-12 10:31 ---
! I am investigating this bug. Assigning it to self.

RE: Remaining Tomcat 3.3 Issues

[Larry Isaacs]

I would like to have the "tomcatAuthentication" hack
available in Ajp13 so this behavior is fully controllable.

Also, I'm also leaning toward having a default of "true".
To get the "security" example working when using Apache,
or other web server, users would have to discover the user
names and passwords provided by default.  I prefer this
over requiring they add their own user name(s) and roles.
Hopefully they would have the sense not to enter a *real*
password in clear text, but who knows.

Larry


> -Original Message-
> From: Ignacio J. Ortega [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 12, 2001 11:54 AM
> To: '[EMAIL PROTECTED]'
> Subject: RE: Remaining Tomcat 3.3 Issues
> 
> 
> > 4. Address user authentication via Ajp12 and Ajp13.  Ajp12 
> > has a test for
> > isTomcatAuthentication() to see if req.setRemoteUser() should 
> > be called.
> > I think Ajp13 doesn't have this yet and probably should.  
> Also, if the
> > user is anonymous, i.e. user = "", should we call 
> req.setRemoteUser()
> > with this value?  This prevents Tomcat's normal 
> > authentication from being
> > triggered.
> > 
> 
> 
> I have this code prepared for commit, implementing the
> tomcatAuthentication hack in ajp13.
> 
> But i've planned to change the hack only testing the received 
> string for
> emptyness and not calling setRemoteUser in the case, i think this will
> render the tomcatAuthentication hack useless... 
> 
> But perhaps the better is as you say, honor IsTomcatAuthentication and
> not calling setRemoteUser for the empty string case.. 
> 
> But i cannot think of a usecase in which were needed to 
> obviate an auth
> done in HTTP Server and honor another done in the Servlet container..
> 
> 
> Saludos ,
> Ignacio J. Ortega
> 

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

[craigmcc]

craigmcc01/09/12 10:00:38

  Modified:catalina/src/share/org/apache/catalina/net
SSLServerSocketFactory.java
  Log:
  Register the JSSE security provider if it is not already there.
  
  Submitted by: Wolfgang Hoschek <[EMAIL PROTECTED]>
  
  Revision  ChangesPath
  1.6   +7 -4  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/net/SSLServerSocketFactory.java
  
  Index: SSLServerSocketFactory.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/net/SSLServerSocketFactory.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- SSLServerSocketFactory.java   2001/09/07 18:39:08 1.5
  +++ SSLServerSocketFactory.java   2001/09/12 17:00:32 1.6
  @@ -382,10 +382,13 @@
   
   try {
   
  -/*
  -Security.addProvider(new sun.security.provider.Sun());
  -Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider());
  -*/
  +// Register the JSSE security Provider (if it is not already there)
  +try {
  +Security.addProvider((java.security.Provider)
  +
Class.forName("com.sun.net.ssl.internal.ssl.Provider").newInstance());
  +} catch (Throwable t) {
  +;
  +}
   
   // Create an SSL context used to create an SSL socket factory
   SSLContext context = SSLContext.getInstance(protocol);
  
  
  

cvs commit: jakarta-tomcat-connectors/webapp/apache-2.0 mod_webapp.c

[pier]

pier01/09/12 09:29:05

  Modified:webapp/apache-2.0 mod_webapp.c
  Log:
  Removed old MMN #ifdefs
  
  Revision  ChangesPath
  1.3   +1 -7  jakarta-tomcat-connectors/webapp/apache-2.0/mod_webapp.c
  
  Index: mod_webapp.c
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/webapp/apache-2.0/mod_webapp.c,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- mod_webapp.c  2001/09/06 17:00:54 1.2
  +++ mod_webapp.c  2001/09/12 16:29:05 1.3
  @@ -57,7 +57,7 @@
   
   /**
* @author  Pier Fumagalli 
  - * @version $Id: mod_webapp.c,v 1.2 2001/09/06 17:00:54 jfclere Exp $
  + * @version $Id: mod_webapp.c,v 1.3 2001/09/12 16:29:05 pier Exp $
*/
   
   #include 
  @@ -413,9 +413,7 @@
   
   /* The uri path is matched: set the handler and return */
   r->handler=apr_pstrdup(r->pool,"webapp-handler");
  -#if (MODULE_MAGIC_NUMBER_MAJOR > 20010808)
   apr_table_setn(r->notes,"webapp-handler", "webapp-handler");
  -#endif
   
   /* Set the webapp request structure into Apache's request structure */
   ap_set_module_config(r->request_config, &webapp_module, appl);
  @@ -510,7 +508,6 @@
   return(OK);
   }
   
  -#if (MODULE_MAGIC_NUMBER_MAJOR > 20010808)
   /* bypass the directory_walk and file_walk for non-file requests */
   static int wam_map_to_storage(request_rec *r)
   {
  @@ -520,16 +517,13 @@
   }
   return DECLINED;
   }
  -#endif
   
   static void register_hooks(apr_pool_t *p)
   {
   ap_hook_handler(wam_invoke, NULL, NULL, APR_HOOK_MIDDLE);
   ap_hook_translate_name(wam_match, NULL, NULL, APR_HOOK_MIDDLE);
   ap_hook_child_init(wam_startup, NULL, NULL, APR_HOOK_MIDDLE);
  -#if (MODULE_MAGIC_NUMBER_MAJOR > 20010808)
   ap_hook_map_to_storage(wam_map_to_storage, NULL, NULL, APR_HOOK_MIDDLE);
  -#endif
   }
   
   /* Apache module declaration */
  
  
  

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

[remm]

remm01/09/12 09:19:25

  Modified:catalina/src/share/org/apache/catalina/servlets
DefaultServlet.java
  Log:
  - Must use rebind when ovewriting,
Bug reported by Holger Menzel 
  
  Revision  ChangesPath
  1.39  +9 -5  
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java
  
  Index: DefaultServlet.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
  retrieving revision 1.38
  retrieving revision 1.39
  diff -u -r1.38 -r1.39
  --- DefaultServlet.java   2001/08/27 11:50:41 1.38
  +++ DefaultServlet.java   2001/09/12 16:19:25 1.39
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
 1.38 2001/08/27 11:50:41 remm Exp $
  - * $Revision: 1.38 $
  - * $Date: 2001/08/27 11:50:41 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/servlets/DefaultServlet.java,v
 1.39 2001/09/12 16:19:25 remm Exp $
  + * $Revision: 1.39 $
  + * $Date: 2001/09/12 16:19:25 $
*
* 
*
  @@ -122,7 +122,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
  - * @version $Revision: 1.38 $ $Date: 2001/08/27 11:50:41 $
  + * @version $Revision: 1.39 $ $Date: 2001/09/12 16:19:25 $
*/
   
   public class DefaultServlet
  @@ -606,7 +606,11 @@
   try {
   Resource newResource = new Resource(req.getInputStream());
   // FIXME: Add attributes
  -resources.bind(path, newResource);
  +if (exists) {
  +resources.rebind(path, newResource);
  +} else {
  +resources.bind(path, newResource);
  +}
   } catch(NamingException e) {
   result = false;
   }
  
  
  

RE: Remaining Tomcat 3.3 Issues

[David Oxley]

Larry,

Any chance of committing the attached patch before 3.3rc1. It makes
jk_nt_service maintain a list of currently installed services in the
registry. This is so the Service Manager I have written can work. I will be
submitting the Service Manager in a few hours for committing in
jakarta-tomcat-service (?? Or wherever appropriate) and I will build a
binary for the 3.3rc1 release.

Dave
[EMAIL PROTECTED]

-Original Message-
From: Larry Isaacs [mailto:[EMAIL PROTECTED]]
Sent: 12 September 2001 16:31
To: '[EMAIL PROTECTED]'
Subject: Remaining Tomcat 3.3 Issues

Hi All,

I have made a pass through all Tomcat3 bugs.  Those listed below
are the only ones that remain open as of last night.  Listed for
RC1 and RC2 are issues I have accumulated as well as bugs that must
be resolved.




 ntservice.diff

Re: Tomcat and session management

[Craig R. McClanahan]

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

> Date: Wed, 12 Sep 2001 14:44:27 +0200
> From: [EMAIL PROTECTED]
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Tomcat and session management
>
> Hello,
>
> I like to have morre information about context management inside
> Tomcat server.

The source code is your best bet.  Details vary a lot by version as well,
so you need to be specific about which version you are talking about.

> Where is the context kept? Is it kept inside memory or
> is it written to some physical medium?

By default, sessions are kept in memory.  Various versions have various
work in progress to make sessions able to be stored in persistent
mechanisms.

> If in my environment multiple
> Tomcat servers are handling client requests, how does he handle the
> context bacause sometimes the request for a client are received by
> server1 and another time the requests for another client are handled
> by server2. So is there context sharing?
>

Tomcat doesn't currently support distributed sessions in the manner you
describe.  Note, also, that the servlet specification *requires* servers
to serve all requests for a particular session, at a particular point in
time, from the *same* JVM.  If/when Tomcat supports this, you can only
migrate a session to a different server "in between" requests.

If you use the "load balancing" feature built in to the web connector
(one front end web server, many back-end Tomcat processes),
what happens is that the session id is dynamically modified to include a
host identifier as well.  Non-session-based requests are allocated
randomly to servers, but once you start a session it always goes back to
the same server.

> Where can I read more detailed information on this issue?
>
> Regards
> Walter
>

Craig McClanahan


> ___
> Walter Heestermans
> Technical Account Manager
> COGNICASE Benelux NV/SA
> tel : ++32-(0)2-714.06.70
> fax: ++32-(0)2-714.06.80
> mailto:[EMAIL PROTECTED]
> Visit our local web site at :
> http://www.cognicase.be
>
> http://www.COGNICASE.be/AdvancedWeb
> ___
>
>

RE: Remaining Tomcat 3.3 Issues

[Ignacio J. Ortega]

> 4. Address user authentication via Ajp12 and Ajp13.  Ajp12 
> has a test for
> isTomcatAuthentication() to see if req.setRemoteUser() should 
> be called.
> I think Ajp13 doesn't have this yet and probably should.  Also, if the
> user is anonymous, i.e. user = "", should we call req.setRemoteUser()
> with this value?  This prevents Tomcat's normal 
> authentication from being
> triggered.
> 


I have this code prepared for commit, implementing the
tomcatAuthentication hack in ajp13.

But i've planned to change the hack only testing the received string for
emptyness and not calling setRemoteUser in the case, i think this will
render the tomcatAuthentication hack useless... 

But perhaps the better is as you say, honor IsTomcatAuthentication and
not calling setRemoteUser for the empty string case.. 

But i cannot think of a usecase in which were needed to obviate an auth
done in HTTP Server and honor another done in the Servlet container..


Saludos ,
Ignacio J. Ortega

Tomcat and session management

[walter . heestermans]

Hello,

I like to have morre information about context management inside Tomcat server. Where 
is the context kept? Is it kept inside memory or is it written to some physical 
medium? If in my environment multiple Tomcat servers are handling client requests, how 
does he handle the context bacause sometimes the request for a client are received by 
server1 and another time the requests for another client are handled by server2. So is 
there context sharing?

Where can I read more detailed information on this issue?

Regards
Walter

___
Walter Heestermans
Technical Account Manager
COGNICASE Benelux NV/SA
tel : ++32-(0)2-714.06.70
fax: ++32-(0)2-714.06.80
mailto:[EMAIL PROTECTED]
Visit our local web site at : 
http://www.cognicase.be

http://www.COGNICASE.be/AdvancedWeb
___

Re: jaas interceptor

[Rickard Öberg]

Ron Lin wrote:
> has anyone ever come across a RequestInterceptor that redirects users to
> JAAS authentication modules?
> 
> anyone know information about using JAAS from Tomcat?

The JBoss server has a JAAS implementation plugin for Tomcat that does
this. See jboss.org for JAAS integration and download info. Also see the
recent article in JavaWorld:
http://www.javaworld.com/javaworld/jw-08-2001/jw-0831-jaas.html

/R

-- 
Rickard Öberg
Software Development Specialist
xlurc - Xpedio Linköping Ubiquitous Research Center
Author of "Mastering RMI"
Email: [EMAIL PROTECTED]

jaas interceptor

[Ron Lin]

has anyone ever come across a RequestInterceptor that redirects users to
JAAS authentication modules?

anyone know information about using JAAS from Tomcat?

thanks,

Ron Lin
Probaris Technologies
[EMAIL PROTECTED]

Remaining Tomcat 3.3 Issues

[Larry Isaacs]

Hi All,

I have made a pass through all Tomcat3 bugs.  Those listed below
are the only ones that remain open as of last night.  Listed for
RC1 and RC2 are issues I have accumulated as well as bugs that must
be resolved.

Each of these issues needs to be considered according to its
impact on the stability of Tomcat 3.3.  I think most of the bugs
are already fixed, but I need someone more familiar with the
code to make a more informed assessment about the appropriate
resolution.

I am going ahead and posting this even though I haven't spent much
time trying to identify which of these I consider showstoppers
(mainly due to dancing late into the night with Bugzilla).
At this moment, by default I don't consider any of these
showstoppers.  I will try to review this and post my opinions later,
probably tomorrow. Others are welcome to offer their opinions in this
regard.

= Tomcat 3.3 Release Issues =

To Be Addressed for RC1:

1. HttpSessionFacade.setAttribute() isn't synchronized.  If a second request
called "setAttribute()" after this request's "removeAttribute()" and before
"realSession.setAttribute()", the second request's value would be overwritten
without an valueUnbound() being called.

2. Evaluate Tomcat 3.3's vulnerability to "Double Checked Locking". This
is referred to in Bug #177. See:
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
for details.  I think ServletHandler.init() is currently subject to this
vulnerability.

3. The spec doesn't address whether a the form-login-page and form-error-page
should be excluded from the security-constraint, but it makes sense that
it should.  It might be best to postpone this.

4. Address user authentication via Ajp12 and Ajp13.  Ajp12 has a test for
isTomcatAuthentication() to see if req.setRemoteUser() should be called.
I think Ajp13 doesn't have this yet and probably should.  Also, if the
user is anonymous, i.e. user = "", should we call req.setRemoteUser()
with this value?  This prevents Tomcat's normal authentication from being
triggered.

5. If a error handler is not found for an exception, check the root cause
as well if it is a ServletException.  This is mentioned in Bug 3233.  I think
it would be a good idea to apply this.  I don't think we are prohibited
by the spec.  We could add an option to be safe if there is concern.

6. StaticInterceptor is missing a localization enhancement added to
Tomcat 3.2.x.  Should this enhancement be ported to Tomcat 3.3?  Is
this still considered a regression, though it isn't part of the
Servlet 2.2/JSP 1.1 spec?

7. Evaluate whether anything should be done to deal with the use of
non-thread-safe DateFormat and related classes.

Must Resolve Bugs:

177   Race condition during servlet initialization BugRat Report#2
182   JSP error-page doesn't work with virtual hosts BugRat Report
274   request.getUserPrincipal() doesn't work when user is authent
437   req.getParameter(name) Ignores charset. always assumes ISO88  
461   Use setCharacterEncoding("UTF8") does not change the way get  
463   Ctx( /examples ): IOException in: R( /examples + + null) No  
1253  Frequent Connection reset by peer errors  
1482  Ignored session ids in encoded URLs  
1663  Tomcat -SSL problem  
1798  Tomcat 3.2.2b5 with Apache and ajp13 stops responding after  
3233  exception handling wrt errorpages seems to be incorrect  
3486 Session problem (with case insensitive context matching on windows)



To Be Addressed by RC2:

8. We need to remove or optionally disable the shutdown support in
Ajp13Interceptor.  This allows configuring a password protected
Ajp12Interceptor shutdown to be the only shutdown available.

9. Some files under src/native have embedded CR's, i.e. Unix files would have
CRLF and Windows files would have CRCRLF's.  These need to be fixed.

10. The jk_nt_service, and I assume jniconnect, redirect stdout and stderr to
files.  With the default server.xml with no path for tc_log, Tomcat's
startup output ends up in the "stderr" log. I would have expected it to
be in the "stdout" log.  Is there a reason the o.a.t.u.qlog.Logger uses
stderr as the default sink instead of stdout?

11. Make sure we are okay with mod_jk not supporting Apache's rewrite
in Tomcat 3.3's mod_jk.  I'm fine with not supporting it, but I want
to include some justification in the documentation to avoid some of
the "why don't you" questions.

12. To simplify upgrade development, I would like to see the classpath
for the "container", "common", and "apps" classloaders include the
directory so classes placed under them will be picked up.

13. Determine cause of pauses running Tomcat's internal test with
Tomcat + IIS.


Must Resolve Bugs:

82Jasper not affected by mod_rewrite BugRat Report#49  (part of issue 11)
111   after httpd reload mod_jk fails to find a worker BugRat Repo  
276   JNI problem: bufferedreader.read fails in Tomcat/IIS/JNI set  
319   Nor Hig All [EMAIL PROTECTED] UNCO  Tomcat does not launch with given
  Unix scrip

Re: cvs commit: jakarta-tomcat-4.0 RELEASE-PLAN-4.0.txt

[Craig R. McClanahan]

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

> Date: Wed, 12 Sep 2001 14:39:51 +0200
> From: jean-frederic clere <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: cvs commit: jakarta-tomcat-4.0 RELEASE-PLAN-4.0.txt
>
> Hi,
>
> How was the issue with sun.tools.javac.Main solved?
>

It is going to be deferred to a future release.  Here's the reasoning:

* The Merlin (i.e. JDK 1.4) folks originally planned to simply
  remove the old compiler entry point.  But they have changed
  plans, and now it is merely deprecated.  The old compiler *will*
  work in the 1.4 final release, so the time pressure is off.

* The new entry point can indeed be programmed to (like Ant does,
  for example), but it has a crippling disadvantage for a servlet
  container - it only writes error messages to System.out, so you
  have to synchronize and do at most one compile at a time.  This
  is not a good thing, and I'd rather see us take some time to
  look at alternative approaches.

> Cheers
>
> Jean-frederic
>

Craig


> [EMAIL PROTECTED] wrote:
> >
> > craigmcc01/09/11 22:25:58
> >
> >   Modified:.RELEASE-PLAN-4.0.txt
> >   Log:
> >   Up to the minute status.
> >
> >   Revision  ChangesPath
> >   1.13  +15 -10jakarta-tomcat-4.0/RELEASE-PLAN-4.0.txt
> >
> >   Index: RELEASE-PLAN-4.0.txt
> >   ===
> >   RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-PLAN-4.0.txt,v
> >   retrieving revision 1.12
> >   retrieving revision 1.13
> >   diff -u -r1.12 -r1.13
> >   --- RELEASE-PLAN-4.0.txt  2001/09/12 00:53:06 1.12
> >   +++ RELEASE-PLAN-4.0.txt  2001/09/12 05:25:58 1.13
> >   @@ -1,4 +1,4 @@
> >   -$Id: RELEASE-PLAN-4.0.txt,v 1.12 2001/09/12 00:53:06 craigmcc Exp $
> >   +$Id: RELEASE-PLAN-4.0.txt,v 1.13 2001/09/12 05:25:58 craigmcc Exp $
> >
> >  Release Plan for Apache Tomcat 4.0
> >  ==
> >   @@ -46,8 +46,12 @@
> >Bugs That Must Be Addressed Before Final Release:
> >
> >
> >   -Connectors  1788mod_webapp errors on Win2k
> >   +Catalina3511Line too long (currently WORKSFORME, awaiting reproducible
> >   +failure case)
> >
> >   +Catalina3515Process hanging after stopping Tomcat (awaiting
> >   +reproducible failure case)
> >   +
> >Connectors  2997Webapp connector should recover when Tomcat is restarted
> >
> >Connectors  3476Cannot use other than default context when using mod_webapp
> >   @@ -57,31 +61,32 @@
> >Connectors  3509Apache 1.3.20 and mod_webapp and Tomcat 4b7 HANGS
> >(likely to be the same issue as 1788)
> >
> >   -Jasper  3079NullPointerException in JakartaCommentGenerator.generateEnd
> >   +Connectors  3510With WARP request.getScheme() returns http instead of https
> >   +
> >   +Connectors  3534File Upload doesn't work with Apache, mod_webapp, Tomcat 4
> >
> >   -Jasper  3127 not supported
> >   +Jasper  3079NullPointerException in JakartaCommentGenerator.generateEnd
> >
> >   -Jasper  3235JSPC command line compiler does not support taglibs
> >   +Jasper  3127 not supported (currently
> >   +WORKSFORME, awaiting reproducible failure case)
> >
> >Jasper  3350Using XML syntax causes content rearrangement
> >
> >   -Jasper  3398Jasper does not support primitive types for tag variables
> >   +Jasper  3529JSPC can't handle taglibs in RC1 (dup of 3235,
> >   +includes a proposed patch)
> >
> >
> >Nice To Have Fixes Before Final Release:
> >---
> >
> >Catalina3114Spanish translations of LocalString.properties files
> >   +(Japanese translations have also been provided)
> >
> >Catalina3194Javadoc errors during build
> >
> >Jasper  3055 tag ignores the name attribute
> >
> >Jasper  3195Javadoc errors during build
> >   -
> >   -Jasper  3340sun.tools.javac.Main has been deprecated in JDK 1.4-beta-2
> >   -
> >   -Jasper  3433Bad performance on JspWriterImpl.java
> >
> >Servletapi  3196Javadoc errors during build
> >
> >
> >
> >
>

Re: Tomcat 4 Bug reports

[Pier Fumagalli]

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

> ...now go to the [EMAIL PROTECTED] mailing list.

Also tomcat 3...

Pier

Tomcat 4 Bug reports

[Jon Stevens]

...now go to the [EMAIL PROTECTED] mailing list.

-jon

RE: [VOTE] Bug Notification E-Mails

[Marc Saegesser]

-1

Marc Saegesser

> -Original Message-
> From: Pier Fumagalli [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 10, 2001 2:03 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [VOTE] Bug Notification E-Mails
>
>
> "Christopher Cain" <[EMAIL PROTECTED]> wrote:
>
> > Also, while I might technically have the ability to call for a vote on
> > anything, it's bad form to call a vote on something that you personally
> > cannot make happen. Since I do not have the ability to set up a new
> > mailing list, it would be the equivalent of me forcing more mailing list
> > duties on Pier.
> >
> > Basically, I did the most that I could do. The only people who could
> > realistically called for a vote on a new mailing list are Jon (who isn't
> > in favor of it), Pier (who I think is fed up with the whole business at
> > this point :), and Craig (who didn't say one way or the other). As I
> > said, I don't personally care how they get into my inbox, so long as
> > they do. So in calling a vote, I simply played the percentages.
>
> Ok, so since I need to try to be the nice guy over here, let's do it this
> way... It seems apparent that the mailing list want to be notified of bugs
> (lots of +1 and no -1), so this is a simple one
>
> [ ] +1 - I want all messages to a new tomcat-bugs mailing list
> [ ] -1 - I want all messages to tomcat-dev
>
> (I'd propose this is a non vetoing vote, so, majority wins)
>
> Pier

Re: cvs commit: jakarta-tomcat-4.0 RELEASE-PLAN-4.0.txt

[jean-frederic clere]

Hi,

How was the issue with sun.tools.javac.Main solved?

Cheers

Jean-frederic

[EMAIL PROTECTED] wrote:
> 
> craigmcc01/09/11 22:25:58
> 
>   Modified:.RELEASE-PLAN-4.0.txt
>   Log:
>   Up to the minute status.
> 
>   Revision  ChangesPath
>   1.13  +15 -10jakarta-tomcat-4.0/RELEASE-PLAN-4.0.txt
> 
>   Index: RELEASE-PLAN-4.0.txt
>   ===
>   RCS file: /home/cvs/jakarta-tomcat-4.0/RELEASE-PLAN-4.0.txt,v
>   retrieving revision 1.12
>   retrieving revision 1.13
>   diff -u -r1.12 -r1.13
>   --- RELEASE-PLAN-4.0.txt  2001/09/12 00:53:06 1.12
>   +++ RELEASE-PLAN-4.0.txt  2001/09/12 05:25:58 1.13
>   @@ -1,4 +1,4 @@
>   -$Id: RELEASE-PLAN-4.0.txt,v 1.12 2001/09/12 00:53:06 craigmcc Exp $
>   +$Id: RELEASE-PLAN-4.0.txt,v 1.13 2001/09/12 05:25:58 craigmcc Exp $
> 
>  Release Plan for Apache Tomcat 4.0
>  ==
>   @@ -46,8 +46,12 @@
>Bugs That Must Be Addressed Before Final Release:
>
> 
>   -Connectors  1788mod_webapp errors on Win2k
>   +Catalina3511Line too long (currently WORKSFORME, awaiting reproducible
>   +failure case)
> 
>   +Catalina3515Process hanging after stopping Tomcat (awaiting
>   +reproducible failure case)
>   +
>Connectors  2997Webapp connector should recover when Tomcat is restarted
> 
>Connectors  3476Cannot use other than default context when using mod_webapp
>   @@ -57,31 +61,32 @@
>Connectors  3509Apache 1.3.20 and mod_webapp and Tomcat 4b7 HANGS
>(likely to be the same issue as 1788)
> 
>   -Jasper  3079NullPointerException in JakartaCommentGenerator.generateEnd
>   +Connectors  3510With WARP request.getScheme() returns http instead of https
>   +
>   +Connectors  3534File Upload doesn't work with Apache, mod_webapp, Tomcat 4
> 
>   -Jasper  3127 not supported
>   +Jasper  3079NullPointerException in JakartaCommentGenerator.generateEnd
> 
>   -Jasper  3235JSPC command line compiler does not support taglibs
>   +Jasper  3127 not supported (currently
>   +WORKSFORME, awaiting reproducible failure case)
> 
>Jasper  3350Using XML syntax causes content rearrangement
> 
>   -Jasper  3398Jasper does not support primitive types for tag variables
>   +Jasper  3529JSPC can't handle taglibs in RC1 (dup of 3235,
>   +includes a proposed patch)
> 
> 
>Nice To Have Fixes Before Final Release:
>---
> 
>Catalina3114Spanish translations of LocalString.properties files
>   +(Japanese translations have also been provided)
> 
>Catalina3194Javadoc errors during build
> 
>Jasper  3055 tag ignores the name attribute
> 
>Jasper  3195Javadoc errors during build
>   -
>   -Jasper  3340sun.tools.javac.Main has been deprecated in JDK 1.4-beta-2
>   -
>   -Jasper  3433Bad performance on JspWriterImpl.java
> 
>Servletapi  3196Javadoc errors during build
> 
> 
> 
>

Bug in TC 3.3 DependClassLoader

[Bojan Smojver]

Since I was playing with distributing all my apps in jars...

In method dependency() of that class, there is a section for jars. It
goes something like this:


if( "jar".equals( res.getProtocol() )) {
String fileN=res.getFile();
int idx=fileN.indexOf( "!" );
if( idx>=0 )
fileN=fileN.substring( 0, idx) ;
f=new File( fileN );
if( debug > 0 ) log( "Jar dep "  +f );
if( ! f.exists()) f=null;
}

if( f==null ) return;
Dependency dep=new Dependency();
dep.setLastModified( f.lastModified() );
dep.setTarget( c );
dep.setOrigin( f );

dependM.addDependency( dep );


So if the res is:


jar:file:/home/httpd/html/binarix.dev/WEB-INF/lib/app.jar!/com/binarix/wpm/ParseXML.class


then fileN after res.getFile() is:


file:/home/httpd/html/binarix.dev/WEB-INF/lib/app.jar!/com/binarix/wpm/ParseXML.class


and after tossing everything after the bang, it becomes:


file:/home/httpd/html/binarix.dev/WEB-INF/lib/app.jar


which is NOT a file (a URL maybe?), so f.exists() returns false and f
becomes null. The method dependency() returns without adding the jar in
question to the list of dependencies. Aie!

Maybe there should be another 'file' section inside the 'jar' section to
resolve that URL?

If you guys think that'd work OK, I can write a little patch...

Bojan

EJB Support and Tomcat

[Anand B N]

Does Tomcat 4.0 include EJB support(whichever version it is)?

Anand

Tomcat cache ?

[Kenny Ma]

I always need to restart tomcat to see the latest result after I change the 
some servlet program.

Is it tomcat cache the servlet program ?
if so, how can I disabled the cache ?

It never happened when I use Jserv before.

Thanks


/* Kenny Ma
   [EMAIL PROTECTED] */