Bug 1006, what's next ?

[Tal Dayan]

Two days ago I filed a bug report regarding a sever hanging problem in
PollTcpEndpoint of Tomcat 3.x. The bug is
at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1006 and also include a
suggestion for a patch.

Since then I did not notice any change in the status or resolution of the
bug report nor any
indication that it got anywhere.

1. Is this is the right place to file the bug ?

2. Is the bug filed correctly ?

3. Should I do anything else to make sure the bug gets the attention of the
relevant maintainers ?

Thanks,

Tal

ajp13 restart patch - next step

[GOMEZ Henri]

Hi,

You could find attached the latest patch for mod_jk
ajp13_worker.

The imsg buf stand now for initial msg. I fixed the naming.

Thanks to comments before I commit it.






 jk_ajp13_worker.diff

Re: [VOTE] Proposed Tomcat 4.0-Beta-2 Code Freeze Date

[Pier P. Fumagalli]

Craig R. McClanahan <[EMAIL PROTECTED]> wrote:
>  -0  [X] I do not support the proposed release, but do not have an
>  alternative to propose

Just got to Dublin, and let me tell you, it's AWFUL... :( I'll try to make
it, but... 

Pier (somewhere in Europe... This time Dublin???)

-- 

Pier Fumagalli    

RE: ajp13 restart patch - next step

[GOMEZ Henri]

Oups not the up to date code.

Find attached the correct patch. It will correctly
handle the tomcat failure (when restarted or down) 
during upload mode 

>-Original Message-
>From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, March 20, 2001 1:40 PM
>To: [EMAIL PROTECTED]
>Cc: Dan Milstein (E-mail); Keith Wannamaker (E-mail)
>Subject: ajp13 restart patch - next step
>
>
>Hi,
>
>You could find attached the latest patch for mod_jk
>ajp13_worker.
>
>The imsg buf stand now for initial msg. I fixed the naming.
>
>Thanks to comments before I commit it.
>
>
>
>
>
>


 jk_ajp13_worker.c.diff

Re: [VOTE] Proposed Tomcat 4.0-Beta-2 Code Freeze Date

[Mel Martinez]

--- "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
> - Clip and Return This Portion -
> 
> +1  [ ]   I support the proposed release, and
> will work to support it
> +0  [ ]   I support the proposed release, but
> cannot work on it
>   at this time
> -0  [ ]   I do not support the proposed release,
> but do not have an
>   alternative to propose
> -1  [ ]   I do not support the proposed release,
> for reasons specified
>   below.
> 
> 
> Craig McClanahan (who votes +1)
> 
> 
> 

+0

Mel

__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail. 
http://personal.mail.yahoo.com/

mod_webapp status?

[Eric L. Anderson]

What is the current status of mod_webapp? I have tried building the connector
from cvs but the build fails with webapplib. The errors seem to indicate there 
are some missing source files.

wa.c:69: `wa_connections' undeclared (first use in this function)
wa.c:69: (Each undeclared identifier is reported only once
wa.c:69: for each function it appears in.)
wa.c:72: `cb' undeclared (first use in this function)
wa.c:73: `wa_callbacks' undeclared (first use in this function)

I can not find any trace of an actual definition of "wa_connections" in any 
of the source files. 

-- 
Eric L. Anderson
[EMAIL PROTECTED]

Re: Bug 1006, what's next ?

[cmanolache]

Hi,

I had a (long) weekend without computers. But I still found one and read
the mail once - and your report is very serious and important ( and not
easy to fix ). You have (at least ) my full attention. The read 
timeout will be checked in soon - but the general problem ( with a servlet
hanging a thread ) is very hard to resolve (or I don't know any good
solution ).

We could stop setting an upper limit on the thread count ( we still have
the OS upper limit ), and we could also use the (dangerous,
deprecated) suspend/terminate on the thread that is taking too much time. 

Have you tried any fix ? The timeout will not resolve the "bursts" ( and
high-loaded servers ) - unless it is very short. 

BTW, this is not a tomcat-specific problem ( I would guess Apache does
have the same issue - and we need to find how they deal with that ).

Costin


On Tue, 20 Mar 2001, Tal Dayan wrote:

> 
> Two days ago I filed a bug report regarding a sever hanging problem in
> PollTcpEndpoint of Tomcat 3.x. The bug is
> at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1006 and also include a
> suggestion for a patch.
> 
> Since then I did not notice any change in the status or resolution of the
> bug report nor any
> indication that it got anywhere.
> 
> 1. Is this is the right place to file the bug ?
> 
> 2. Is the bug filed correctly ?
> 
> 3. Should I do anything else to make sure the bug gets the attention of the
> relevant maintainers ?
> 
> Thanks,
> 
> Tal
> 
> 

RE: problem with national language in html form input

[cmanolache]

Hi,

I volunteered to resolve the charset issues, the problem is very complex
and difficult ( and I had very little time for that ). (I'm also an 8859-2
user).

In other words - I need help ( patches, ideas, code to reproduce etc
) ... This is too big and scary issue - and I don't feel confident enough
on my knowledge to start anything major. 

I already added code in 3.3 that would allow a module to set the charset, 
I fixed the generation of UTF8, and I'm looking at the changes that set
the platform encoding - I believe it's a very bad idea ( since you can't
know that the browser is using the same encoding as the server - unless
you are inside intranets ), but I have no other solution right now.

Anyway - I do believe we can' ship 3.3 final without this problem
resolved, and the current design ( with MessageBytes and lazy conversion
from byte->String ) should be able to support a solution ( if we find one)

Maybe using UTF8 as the default for input and output ? ( I saw few RFCs
mentioning that as the best solution - given that most current browsers
do support UTF8). Of course, this can't be enabled the default ( spec
issues ), but it's better than the local server encoding...


Costin





On Mon, 19 Mar 2001, Szegedi, Attila wrote:

> I have also done this once in my private copy of Tomcat, but have abandoned
> it.
> The problem is standards compliance, and standards (both the HTML standard
> and the Servlet spec) are somewhat internationalization-ignorant on this
> point.
> 
> Tomcat follows the HTML standard, which explicitly declares that MIME type
> "application/x-www-form-urlencoded" is suitable ONLY for transferring ASCII
> (but will of course work for ISO 8859-1 as well). See
> http://www.w3.org/TR/html4/interact/forms.html#h-17.13.4.1
> It says:
> 
> 
> "The content type "application/x-www-form-urlencoded" is inefficient for
> sending large quantities of binary data or text containing non-ASCII
> characters. The content type "multipart/form-data" should be used for
> submitting forms that contain files, non-ASCII data, and binary data."
> 
> 
> So, if you want to comply with the HTML standard, you should force sending
> all of your forms containing non-ASCII characters as "multipart/form-data"
> using the "enctype" attribute of the form. Unfortunately, Tomcat will not
> present "multipart/form-data" to your servlet as request parameters.
> 
> The HTML standard is further flawed in that it
> 1. defaults the encoding type of the form to
> "application/x-www-form-urlencoded"
> 2. requires browsers to send form data in the same encoding they received
> the HTML page in, (except if "accept-charset" attribute is set, which is
> usually not).
> So, a complying browser will by default use
> "application/x-www-form-urlencoded" and send data through it in the same
> encoding they received the HTML page in. The trouble is, that they wont send
> the *ENCODING* back to the server in the Content-Type header (at least all
> IE (up to 5.5) and NN (up to 4.75) won't). It will always be
> "application/x-www-form-urlencoded" and not
> "application/x-www-form-urlencoded; charset=whatever"), so Tomcat's
> parsePostData can't determine the charset, it will always sense ISO 8859-1,
> as this is the default.
> 
> I have some back experience working with Microsoft's ASP technology. They
> solved the problem partially by introducing the "session encoding" -- all
> HTML response used this encoding, and all request parameters were parsed
> according to that encoding.
> 
> This could be a solution, however it should go into servlet spec. (Are we
> heard, servlet spec people?)
> 
> My own app uses ISO 8859-2 (as it's in Hungarian), and for now I just
> transcode 8859-1 into 8859-2. I'm lucky I use Model2 paradigm, so I have a
> single servlet handling all requests and a single central place to transcode
> request parameters.
> 
> Cheers,
>   Attila.
> 
> > -Original Message-
> > From: Aleksandras Novikovas [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, March 16, 2001 10:32 AM
> > To: '[EMAIL PROTECTED]'
> > Subject: problem with national language in html form input
> >
> >
> > Hello All,
> >
> > I'm posting for the first time, so please inform me if I do
> > something wrong ...
> >
> > First of all - problem description :
> > I have application in multilanguage (where user can
> > dynamically change charset).
> > Problem rises when user enters information in selected language.
> > After parsePostData in HttpUtils I get lots of "" instead of text.
> > I can not rely on default system encoding, because
> > application has ability to add the languages dynamically
> > without recompilation.
> > So I never know what next encoding system will need.
> >
> > I have written some code to work around this problem and
> > think it would be nice to have it standard package.
> > Actually I've changed parsePostData - added  encoding parameter.
> > Now programmer could choose in what encoding InputStream is supplied.
> > I have t

Re: ajp13 restart patch - next step

[Dan Milstein]

Henri,

A few more problems:  

 1) Take a look at ll. 592-600.  In case of a POST request, this will
overwrite the initial buffer (imsg) with the POST data.  If TC is then
restarted, and that request is resent, it will be garbage (POST data instead
of request data).

How best to fix this?  I would say, pass in *both* buffers to send_request
function.  I might call them request_msg and data_msg.  Use request_msg up
to l 592, and then, if there is extra data, send it over in data_msg.

Will this be fully restartable?  I'm not absolutely sure -- it all depends
on whether or not we can reread the POST data from Apache after a restart
(actually, from *all* of the servers supported by mod_jk).  This depends on
the read() function of the web_server_service object -- look in mod_jk.c ll.
219-241.  I don't know the Apache API well enough to understand how this
would work if called more than once for the POST data.  To fully support the
other web servers, we'd have to understand if the read() method allowed
rereading the initial data.


 2) is_recoverable_error is passed into send_request, and it's value is
assigned to, but it is in no way checked/used.  Was this also true of the
old jk_ajp13 code?  (I believe so, but I'm not sure).  If it's genuinely not
being used, we should remove it, but I would like to understand what it
should be doing, and make sure we're not missing an error state somewhere. 


 3) Log message errors:

l. 639 Should be "Error reading reply", I think.

l. 663 should be "Error sending request data", I think.


 4) Still using 4-space tabs.  A quick look through some of the other C
classes suggests that most of them don't use tabs at all (just spaces). 
Let's try to emulate that -- I'll try to stop using 8-space tabs.

-Dan

GOMEZ Henri wrote:
> 
> Oups not the up to date code.
> 
> Find attached the correct patch. It will correctly
> handle the tomcat failure (when restarted or down)
> during upload mode 
> 
> >-Original Message-
> >From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
> >Sent: Tuesday, March 20, 2001 1:40 PM
> >To: [EMAIL PROTECTED]
> >Cc: Dan Milstein (E-mail); Keith Wannamaker (E-mail)
> >Subject: ajp13 restart patch - next step
> >
> >
> >Hi,
> >
> >You could find attached the latest patch for mod_jk
> >ajp13_worker.
> >
> >The imsg buf stand now for initial msg. I fixed the naming.
> >
> >Thanks to comments before I commit it.
> >
> >
> >
> >
> >
> >
> 
>   
>  Name: jk_ajp13_worker.c.diff
>jk_ajp13_worker.c.diffType: unspecified type (application/octet-stream)
>  Encoding: quoted-printable

-- 

Dan Milstein // [EMAIL PROTECTED]

RE: Bug 1006, what's next ?

[GOMEZ Henri]

Hi,

I may help here since I figth against this kind of TCP
bugs each days on my pay job.

The problem with TCP/IP is that when there is no activity a 
read() system call (that java used) will block the calling
thread.

You could use :

- select() like before read() to see if there is something to
  get. Also on Unix there is many ioctl() for that task (FIONREAD).
  But equivalent call are only present in JDK 1.3

- you could set the socket to non blocking and add a timeout to
  read (ie 1 second), but you'll have after that to create a kind
  of Super read() method with the intelligence to know that a HTTP
  request must'nt take more than 5/10 seconds. 

- You may use something like an Apache server in front of you tomcat
  which as built-in support against that kind of potential DOS attack.

I could try to fix that one ...

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, March 20, 2001 4:03 PM
>To: [EMAIL PROTECTED]
>Subject: Re: Bug 1006, what's next ?
>
>
>Hi,
>
>I had a (long) weekend without computers. But I still found 
>one and read
>the mail once - and your report is very serious and important ( and not
>easy to fix ). You have (at least ) my full attention. The read 
>timeout will be checked in soon - but the general problem ( 
>with a servlet
>hanging a thread ) is very hard to resolve (or I don't know any good
>solution ).
>
>We could stop setting an upper limit on the thread count ( we 
>still have
>the OS upper limit ), and we could also use the (dangerous,
>deprecated) suspend/terminate on the thread that is taking too 
>much time. 
>
>Have you tried any fix ? The timeout will not resolve the 
>"bursts" ( and
>high-loaded servers ) - unless it is very short. 
>
>BTW, this is not a tomcat-specific problem ( I would guess Apache does
>have the same issue - and we need to find how they deal with that ).
>
>Costin
>
>
>On Tue, 20 Mar 2001, Tal Dayan wrote:
>
>> 
>> Two days ago I filed a bug report regarding a sever hanging 
>problem in
>> PollTcpEndpoint of Tomcat 3.x. The bug is
>> at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1006 
>and also include a
>> suggestion for a patch.
>> 
>> Since then I did not notice any change in the status or 
>resolution of the
>> bug report nor any
>> indication that it got anywhere.
>> 
>> 1. Is this is the right place to file the bug ?
>> 
>> 2. Is the bug filed correctly ?
>> 
>> 3. Should I do anything else to make sure the bug gets the 
>attention of the
>> relevant maintainers ?
>> 
>> Thanks,
>> 
>> Tal
>> 
>> 
>

cvs commit: jakarta-tomcat/src/doc tomcat-localization-howto.html

[arieh]

arieh   01/03/20 08:31:10

  Added:   src/doc  Tag: tomcat_32 tomcat-localization-howto.html
  Log:
  First revision of the localization HOWTO.
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.1.2.1   +198 -0jakarta-tomcat/src/doc/Attic/tomcat-localization-howto.html
  
  
  
  

RE: [VOTE] Proposed Tomcat 4.0-Beta-2 Code Freeze Date

[GOMEZ Henri]

>- Clip and Return This Portion -
>
>+1  [ ]   I support the proposed release, and will work to support it
>+0  [ ]   I support the proposed release, but cannot work on it at this
time
>-0  [ ]   I do not support the proposed release, but do not have an
alternative to propose
>-1  [ ]   I do not support the proposed release, for reasons specified
below.

+0 (but I'll package the RPMs as usually)

Re: Bug 1006, what's next ?

[David Rees]

On Tue, Mar 20, 2001 at 07:03:04AM -0800, [EMAIL PROTECTED] wrote:
> 
> I had a (long) weekend without computers. But I still found one and read
> the mail once - and your report is very serious and important ( and not
> easy to fix ). You have (at least ) my full attention. The read 
> timeout will be checked in soon - but the general problem ( with a servlet
> hanging a thread ) is very hard to resolve (or I don't know any good
> solution ).
> 
> We could stop setting an upper limit on the thread count ( we still have
> the OS upper limit ), and we could also use the (dangerous,
> deprecated) suspend/terminate on the thread that is taking too much time. 
> 
> Have you tried any fix ? The timeout will not resolve the "bursts" ( and
> high-loaded servers ) - unless it is very short. 
> 
> BTW, this is not a tomcat-specific problem ( I would guess Apache does
> have the same issue - and we need to find how they deal with that ).

Apache sets limits on the maximum (at least in 1.3.X, not sure about
2.X) number of processes which can be running at a time, this prevents
the machine from getting hosed, but doesn't prevent a DOS from a
determined attacker.  I'm not sure if Apache implements any other methods
to prevent this type of DOS.

-Dave

Re: [VOTE] Proposed Tomcat 4.0-Beta-2 Code Freeze Date

[Glenn Nielsen]

"Craig R. McClanahan" wrote:
> 
> There have been a large number of feature additions and bug fixes to the
> Tomcat 4.0 code base since Tomcat 4.0-beta-1 was published in
> January.  This includes implementation of some changes to the servlet API
> that have been approved by the JSR-053 expert group, and a fix for a cross
> site JavaScript vulnerability that was reported over the weekend.
> 

More items for the B2 changes document:

Implemented the Java SecurityManager.

Added the  element for configuration of defaults
for a Context which can be used in either the Engine or Host scope.

Switched Jasper over to using the URLClassLoader, put JSP java source
code and compiled class files in a directory hierarchy and simplified
the class and file naming.  This improved Jasper compilation performance
by 33% and runtime performance by 25%.

> I propose that we cut a Tomcat 4.0-Beta-2 release that reflects these
> changes and improvements.  The proposed schedule:
> * Release manager:  Craig McClanahan
> * Code freeze in the "jakarta-tomcat-4.0" repository, except for approved
>   but fixes, through Thursday (March 22, 2001).
> * Tag and release 4.0-beta-2 on Thursday night.
> * Open repository for further enhancements on Friday.
> 
> Before voting, you might want to see my subsequent message on overall
> Tomcat 4.0 planning and strategy.
> 
> - Clip and Return This Portion -
> 
> +1  [ ]   I support the proposed release, and will work to support it
> +0  [ ]   I support the proposed release, but cannot work on it
>   at this time
> -0  [ ]   I do not support the proposed release, but do not have an
>   alternative to propose
> -1  [ ]   I do not support the proposed release, for reasons specified
>   below.
> 
> Craig McClanahan (who votes +1)

-1  This is pretty short notice to release Beta 2.  I haven't had a chance
yet to test the new mod_webapp code.  I also would like to get my proposed
changes to how Tomcat unpacks web apps and the manager servlet done, I consider
some of this to be a bug fix. I should have these changes done in 2-4 days.
I would suggest waiting until the 27-30'th, get it out before ApacheCon.

Regards,

Glenn


--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

Re: FYI: Tomcat 4.0 Release Planning Futures

[Glenn Nielsen]

+1 

"Craig R. McClanahan" wrote:
> 
> Many TOMCAT-DEV readers might be unaware that the Apache Software
> Foundation (the group that sponsors the Jakarta project, along with many
> others) is an Executive Member of the Java Community Process program,
> which is the group which accepts or rejects the Java Specification
> Requests (JSRs) that create new Java API standards.  The JSR that most
> directly affects the Tomcat community is JSR-053, under which the new
> specifications for Servlet 2.3 and JSP 1.2 are being developed.  Jason
> Hunter is our voting representative.
> 
> This membership position gives ASF (and the open source developers that
> ASF represents) a powerful voice in shaping the future of the Java
> platform.  In addition, however, it imposes responsibilities to follow the
> rules of the Java Community Process -- the same rules that software
> vendors creating products based on these specifications must follow.
> 
> One particular restriction that affects Tomcat 4.0 is the following -- no
> one is allowed to release a "final" release of a product that implements a
> Java specification that is not itself final.  That is the current state of
> the Servlet 2.3 and JSP 1.2 specifications -- they are in "Proposed Final
> Draft" state at the moment.  Therefore, we can not choose to create a
> "final" release of Tomcat 4.0 until those specifications are finalized
> (which is likely to be several months yet).
> 
> The reasoning behind this standard is obvious -- the specifications being
> implemented can still change.  In fact, several changes approved by the
> JSR-053 expert group have been implemented in the last week (they will
> appear in the next draft of the servlet specification).  It would be very
> confusing, for example, to have "final" servlet containers from different
> vendors that implemented different variations of the servlet 2.3 spec.
> 
> So where does that leave us in the mean time?  I propose that we continue
> to innovate new features in succeeding beta releases of Tomcat 4.0
> (treating them essentially the way that "milestone" releases get treated
> in many development projects).  The quality of the code, and overall
> performance, will continue to improve, and beta releases would be cut only
> at points where the code is stable, and passes all current compliance
> tests.
> 
> If need be, we could create a "production quality" release, as long as
> users understand that the fact that the underlying specifications are
> still subject to change.  Such a release could probably be named "Tomcat
> 4.0 Proposed Final", to correspond with the nomenclature on the
> specifications it is based on.  However, in practical reality such a
> release would be essentially the same as another beta (in terms of overall
> quality, testing, and so on).
> 
> Comments?  Questions?
> 
> Craig McClanahan

-- 
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

RE: Bug 1006, what's next ?

[Marc Saegesser]

Tal,

It has my attention.  I'm in the process of finalizing the second beta
release of Tomcat 3.2.2 and I will try to include this patch.  Would you be
able to test Tomcat 3.2.2 beta 2 (when its ready) to verify that this is
working correctly?

Marc Saegesser

> -Original Message-
> From: Tal Dayan [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 20, 2001 2:27 AM
> To: [EMAIL PROTECTED]
> Subject: Bug 1006, what's next ?
>
>
>
> Two days ago I filed a bug report regarding a sever hanging problem in
> PollTcpEndpoint of Tomcat 3.x. The bug is
> at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1006 and
> also include a
> suggestion for a patch.
>
> Since then I did not notice any change in the status or resolution of the
> bug report nor any
> indication that it got anywhere.
>
> 1. Is this is the right place to file the bug ?
>
> 2. Is the bug filed correctly ?
>
> 3. Should I do anything else to make sure the bug gets the
> attention of the
> relevant maintainers ?
>
> Thanks,
>
> Tal
>
>

Re: [VOTE] Proposed Tomcat 4.0-Beta-2 Code Freeze Date

[Craig R. McClanahan]

On Tue, 20 Mar 2001, Glenn Nielsen wrote:

> "Craig R. McClanahan" wrote:
> > 
> > There have been a large number of feature additions and bug fixes to the
> > Tomcat 4.0 code base since Tomcat 4.0-beta-1 was published in
> > January.  This includes implementation of some changes to the servlet API
> > that have been approved by the JSR-053 expert group, and a fix for a cross
> > site JavaScript vulnerability that was reported over the weekend.
> > 
> 
> More items for the B2 changes document:
> 
> Implemented the Java SecurityManager.
> 
> Added the  element for configuration of defaults
> for a Context which can be used in either the Engine or Host scope.
> 

Hmm, I thought I said both of these (under "new features"), but can make
them more explicit.  One of my personal TODOs is to catch up on the rest
of the server.xml configuration docs.

> Switched Jasper over to using the URLClassLoader, put JSP java source
> code and compiled class files in a directory hierarchy and simplified
> the class and file naming.  This improved Jasper compilation performance
> by 33% and runtime performance by 25%.
> 

Thanks, I'll include the actual numbers as well.

> > I propose that we cut a Tomcat 4.0-Beta-2 release that reflects these
> > changes and improvements.  The proposed schedule:
> > * Release manager:  Craig McClanahan
> > * Code freeze in the "jakarta-tomcat-4.0" repository, except for approved
> >   but fixes, through Thursday (March 22, 2001).
> > * Tag and release 4.0-beta-2 on Thursday night.
> > * Open repository for further enhancements on Friday.
> > 
> > Before voting, you might want to see my subsequent message on overall
> > Tomcat 4.0 planning and strategy.
> > 
> > - Clip and Return This Portion -
> > 
> > +1  [ ]   I support the proposed release, and will work to support it
> > +0  [ ]   I support the proposed release, but cannot work on it
> >   at this time
> > -0  [ ]   I do not support the proposed release, but do not have an
> >   alternative to propose
> > -1  [ ]   I do not support the proposed release, for reasons specified
> >   below.
> > 
> > Craig McClanahan (who votes +1)
> 
> -1  This is pretty short notice to release Beta 2.  I haven't had a chance
> yet to test the new mod_webapp code.  I also would like to get my proposed
> changes to how Tomcat unpacks web apps and the manager servlet done, I consider
> some of this to be a bug fix. I should have these changes done in 2-4 days.
> I would suggest waiting until the 27-30'th, get it out before ApacheCon.
> 

Are we willing to wait for the security bugfix?  You can have the fix now
by downloading the nightly build, but most people wait for betas.

I need to add a note about mod_webapp to the "Known Issues" section.  It's
getting better, but still not at the same quality level as the rest of
4.0.

> Regards,
> 
> Glenn
> 

Craig

Re: FYI: Tomcat 4.0 Release Planning Futures

[Craig R. McClanahan]

On Tue, 20 Mar 2001, Kief Morris wrote:

> Craig R. McClanahan typed the following on 08:52 PM 3/19/2001 -0800
> >So where does that leave us in the mean time?  I propose that we continue
> >to innovate new features in succeeding beta releases of Tomcat 4.0
> >(treating them essentially the way that "milestone" releases get treated
> >in many development projects).  The quality of the code, and overall
> >performance, will continue to improve, and beta releases would be cut only
> >at points where the code is stable, and passes all current compliance
> >tests.
> 
> +1 on this. I'm in a position now where I can start devoting some time
> to this (I've been on the road for the past month), especially the
> persistent & distributed sessions.
> 

Boy do I know about "on the road" :-).  I was in New York for a week,
and arrived in Boston half an hour before it snowed twelve inches in
twelve hours a couple weeks ago.

> Kief
> 
> 

Craig

cvs commit: jakarta-tomcat/src/tests/webpages/sandbox - New directory

[costin]

costin  01/03/20 09:45:35

  jakarta-tomcat/src/tests/webpages/sandbox - New directory

cvs commit: jakarta-tomcat/src/tests/webpages/sandbox filew.jsp

[costin]

costin  01/03/20 09:46:57

  Added:   src/tests/webpages/sandbox filew.jsp
  Log:
  Added one test case for sandboxing.
  
  Revision  ChangesPath
  1.1  jakarta-tomcat/src/tests/webpages/sandbox/filew.jsp
  
  Index: filew.jsp
  ===
  <% 
  java.io.FileOutputStream f=new java.io.FileOutputStream("sandbox.txt");
  f.write("I can do it!".getBytes());
  f.close();
  %>
  No exceptions
  
  
  

Re: Strange problem with URL_PKG_PREFIXES

[tttye]

Remy Maucherat writes:

> 
> I've updated the object factory for the EJB references. It should now
> attempt to resolve ejb-links using a JNDI lookup.
> I can't really test the feature, so I'm waiting for your feedback and stack
> traces, if it goes wrong ;-)
> 
> Remy
> 
Ok, I will test with the 20010320 nightly build when it is available.
(I cannot access all of the Java code I need to build tomcat at work
because of a parinoid fire wall).
Tim

RE: problem with national language in html form input

[Szegedi, Attila]

>
> Hi Attila,
>
> Well, sound simple but I think it's a bit more...
>
> How can the server guess what will be the encoding in the
> first page it
> sends ( that will be used back to send the form, etc ) ? Even
> if you know
> the language ( say it's japanese ), there are many charsets
> that could be
> used.

Even better idea that came to mind since the previous letter is to always
assume the session charset is same as the charset of last response Writer. I
think this would suffice for most real world scenarios. It would break only
when a) sessions use multiple charsets b) sessions get multiple requests
concurrently. Both cases are rare in my opinion.

>
> If we are going to rely on the fact that the browser will use
> the original
> encoding I would rather send UTF in the first page.
>
> One case I don't know how to deal with - say we have a form to type a
> name. And we have people from Japan, Europe, etc - who might have
> non-ascii letters in their names. There is no way to know
> what charset to
> use to decode - or to send the original page. We can't set
> 8859-2 on the
> first page - or jis or anything else ( because we don't know
> what the user
> is going to type ).
>

In my eyes, UTF-8 is definitely the way to go if you think globally.

Cheers,
  Attila.

Re: TOMCAT 4.x SSI Status

[Bip Thelin]

Amy Roh wrote:
> 
> Bip,
> 
> What's the status on the SSI feature that you were working on.  I would like to
> help you finish all the features and commit the code if you'd like.  Status?

Hi, I'll mail the latest source later on today(Pacific time). I've had my ass full
of good 'ol work-work lately. That's why I haven't already mailed something out.

I'll give you a quick update on status and my thoughts around it when I mail out the
source.

Aiight!

..bip

RE: Bug 1006, what's next ?

[Tal Dayan]

Hi,

Our first priority is to make Tomcat to work in normal conditions with good
intentioned users. We will
worry later about DOS (as long as we don't introduce new vulnerabilities).

Yes, we tested the timeout patch all day yesterday with a production system
with real users and normal load and
all the hanging threads and connections was cleaned up perfectly (we are
using 'netstat' to
get the number of HTTP connections and 'ps' to get the number of thread and
all is graphed around the clock by MRTG). We are running with a relatively
timeout of 5 minutes (50*60*1000) just to be on the safe side but a shorter
one can be used.

Note that I am in no way and expert in Tomcat nor do I claim to understand
all the implications of the patch so we need some qualified person to
understand the implication and make sure it does not break anything. For
example, if another service like Ajp uses this connection pool for long term
connections that need to wait long periods for a data from some client (e.g.
a front end web server, client side applets, etc), the patch will break it.
The patch assumes that the connections are should never be idle for a long
period of time.

As for Apache, it supports a request timeout (see
http://httpd.apache.org/docs/mod/core.html#timeout) and this will
will eventually cleanup hanging connections. The timeout in this case is
longer because it is for the entire request and the cleanup will be slower.

Implementing a similar query timeout in Tomcat may require things like
asynchronous thread kill (yuck) or some synchronous termination of the
worker threads, for example by closing the sockets they are waiting on (I
think this will release the socketRead() but I am not sure). But this is of
course a more involved change than simply adding the timeout statement.
Having an asynchronous I/O may help here (see Bug Parade
http://developer.java.sun.com/developer/bugParade/bugs/4075058.html).

BTW, does Tomcat 4.X has the same problem ?

Tal




> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 20, 2001 7:03 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Bug 1006, what's next ?
>
>
> Hi,
>
> I had a (long) weekend without computers. But I still found one and read
> the mail once - and your report is very serious and important ( and not
> easy to fix ). You have (at least ) my full attention. The read
> timeout will be checked in soon - but the general problem ( with a servlet
> hanging a thread ) is very hard to resolve (or I don't know any good
> solution ).
>
> We could stop setting an upper limit on the thread count ( we still have
> the OS upper limit ), and we could also use the (dangerous,
> deprecated) suspend/terminate on the thread that is taking too much time.
>
> Have you tried any fix ? The timeout will not resolve the "bursts" ( and
> high-loaded servers ) - unless it is very short.
>
> BTW, this is not a tomcat-specific problem ( I would guess Apache does
> have the same issue - and we need to find how they deal with that ).
>
> Costin
>
>
> On Tue, 20 Mar 2001, Tal Dayan wrote:
>
> >
> > Two days ago I filed a bug report regarding a sever hanging problem in
> > PollTcpEndpoint of Tomcat 3.x. The bug is
> > at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1006 and
> also include a
> > suggestion for a patch.
> >
> > Since then I did not notice any change in the status or
> resolution of the
> > bug report nor any
> > indication that it got anywhere.
> >
> > 1. Is this is the right place to file the bug ?
> >
> > 2. Is the bug filed correctly ?
> >
> > 3. Should I do anything else to make sure the bug gets the
> attention of the
> > relevant maintainers ?
> >
> > Thanks,
> >
> > Tal
> >
> >
>
>

Re: [VOTE] Proposed Tomcat 4.0-Beta-2 Code Freeze Date

[Glenn Nielsen]

"Craig R. McClanahan" wrote:
> 
> On Tue, 20 Mar 2001, Glenn Nielsen wrote:
> 
> > "Craig R. McClanahan" wrote:
> > >
> > > There have been a large number of feature additions and bug fixes to the
> > > Tomcat 4.0 code base since Tomcat 4.0-beta-1 was published in
> > > January.  This includes implementation of some changes to the servlet API
> > > that have been approved by the JSR-053 expert group, and a fix for a cross
> > > site JavaScript vulnerability that was reported over the weekend.
> > >
> >
> > More items for the B2 changes document:
> >
> > Implemented the Java SecurityManager.
> >
> > Added the  element for configuration of defaults
> > for a Context which can be used in either the Engine or Host scope.
> >
> 
> Hmm, I thought I said both of these (under "new features"), but can make
> them more explicit.  One of my personal TODOs is to catch up on the rest
> of the server.xml configuration docs.
> 

I didn't see the commit of your B2 release notes until after I sent this email.

> > Switched Jasper over to using the URLClassLoader, put JSP java source
> > code and compiled class files in a directory hierarchy and simplified
> > the class and file naming.  This improved Jasper compilation performance
> > by 33% and runtime performance by 25%.
> >
> 
> Thanks, I'll include the actual numbers as well.
> 
> > > I propose that we cut a Tomcat 4.0-Beta-2 release that reflects these
> > > changes and improvements.  The proposed schedule:
> > > * Release manager:  Craig McClanahan
> > > * Code freeze in the "jakarta-tomcat-4.0" repository, except for approved
> > >   but fixes, through Thursday (March 22, 2001).
> > > * Tag and release 4.0-beta-2 on Thursday night.
> > > * Open repository for further enhancements on Friday.
> > >
> > > Before voting, you might want to see my subsequent message on overall
> > > Tomcat 4.0 planning and strategy.
> > >
> > > - Clip and Return This Portion -
> > >
> > > +1  [ ]   I support the proposed release, and will work to support it
> > > +0  [ ]   I support the proposed release, but cannot work on it
> > >   at this time
> > > -0  [ ]   I do not support the proposed release, but do not have an
> > >   alternative to propose
> > > -1  [ ]   I do not support the proposed release, for reasons specified
> > >   below.
> > >
> > > Craig McClanahan (who votes +1)
> >
> > -1  This is pretty short notice to release Beta 2.  I haven't had a chance
> > yet to test the new mod_webapp code.  I also would like to get my proposed
> > changes to how Tomcat unpacks web apps and the manager servlet done, I consider
> > some of this to be a bug fix. I should have these changes done in 2-4 days.
> > I would suggest waiting until the 27-30'th, get it out before ApacheCon.
> >
> 
> Are we willing to wait for the security bugfix?  You can have the fix now
> by downloading the nightly build, but most people wait for betas.
> 

I just think its a bit rushed.  How about a code freeze (except bug fixes)
Monday 3/26 and releasing B2 by Friday 3/30 before ApacheCon.

Regards,

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

RE: Bug 1006, what's next ?

[cmanolache]

Hi Tal,

The timeout patch will certainly go into tomcat3.3, and I think Marc will
add it to 3.2 also - it's a good solution and I don't think it can brake
anything.

I was thinking about what we can do for a more general solution - and 
looking at the code I think there are few easy things that need to be
done related with thread pools:

- use a common thread pool for all endpoints ( right now ajp12 is creating
a full thread pool for itself, etc).

- document the thread pool implementation, remove some old code 

- add an admin page to monitor the thread pools

- use the thread pool to run session expire and verify the expire bugs 

- add a ThreadPoolListener/Event to allow a (future) module to monitor and
manage the thread pool

- add a field to store the current "owner" or "user" of each thread. 

- add some log messages for the case when the thread pool is at the
maximum capacity

- maybe provide a spare "admin" thread that can be used to "un-hang" the
server without restarting tomcat ( i.e. if the thread pool is at max
capacity, and if the connector detects a localhost connection allow it to 
create an extra thread - so an admin application can kill threads ).

- API change in ThreadPool - allow it to run normal Runnable ( the current
ThreadPoolRunnable has some nice performance tricks, but it should be
usable for normal tasks that don't want to take advantage of overhead-free
thread data )

None of those would resolve the DOS problem, but I think it would be nice
to have them (and very easy to implement - without affecting the current
functionality ) 


Costin





On Tue, 20 Mar 2001, Tal Dayan wrote:

> Hi,
> 
> Our first priority is to make Tomcat to work in normal conditions with good
> intentioned users. We will
> worry later about DOS (as long as we don't introduce new vulnerabilities).
> 
> Yes, we tested the timeout patch all day yesterday with a production system
> with real users and normal load and
> all the hanging threads and connections was cleaned up perfectly (we are
> using 'netstat' to
> get the number of HTTP connections and 'ps' to get the number of thread and
> all is graphed around the clock by MRTG). We are running with a relatively
> timeout of 5 minutes (50*60*1000) just to be on the safe side but a shorter
> one can be used.
> 
> Note that I am in no way and expert in Tomcat nor do I claim to understand
> all the implications of the patch so we need some qualified person to
> understand the implication and make sure it does not break anything. For
> example, if another service like Ajp uses this connection pool for long term
> connections that need to wait long periods for a data from some client (e.g.
> a front end web server, client side applets, etc), the patch will break it.
> The patch assumes that the connections are should never be idle for a long
> period of time.
> 
> As for Apache, it supports a request timeout (see
> http://httpd.apache.org/docs/mod/core.html#timeout) and this will
> will eventually cleanup hanging connections. The timeout in this case is
> longer because it is for the entire request and the cleanup will be slower.
> 
> Implementing a similar query timeout in Tomcat may require things like
> asynchronous thread kill (yuck) or some synchronous termination of the
> worker threads, for example by closing the sockets they are waiting on (I
> think this will release the socketRead() but I am not sure). But this is of
> course a more involved change than simply adding the timeout statement.
> Having an asynchronous I/O may help here (see Bug Parade
> http://developer.java.sun.com/developer/bugParade/bugs/4075058.html).
> 
> BTW, does Tomcat 4.X has the same problem ?
> 
> Tal
> 
> 
> 
> 
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, March 20, 2001 7:03 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Bug 1006, what's next ?
> >
> >
> > Hi,
> >
> > I had a (long) weekend without computers. But I still found one and read
> > the mail once - and your report is very serious and important ( and not
> > easy to fix ). You have (at least ) my full attention. The read
> > timeout will be checked in soon - but the general problem ( with a servlet
> > hanging a thread ) is very hard to resolve (or I don't know any good
> > solution ).
> >
> > We could stop setting an upper limit on the thread count ( we still have
> > the OS upper limit ), and we could also use the (dangerous,
> > deprecated) suspend/terminate on the thread that is taking too much time.
> >
> > Have you tried any fix ? The timeout will not resolve the "bursts" ( and
> > high-loaded servers ) - unless it is very short.
> >
> > BTW, this is not a tomcat-specific problem ( I would guess Apache does
> > have the same issue - and we need to find how they deal with that ).
> >
> > Costin
> >
> >
> > On Tue, 20 Mar 2001, Tal Dayan wrote:
> >
> > >
> > > Two days ago I filed a bug report regarding a sever hanging problem in
> > > PollTcpEndpoint of

Re: Strange problem with URL_PKG_PREFIXES

[tttye]

Remy Maucherat writes:
> I've updated the object factory for the EJB references. It should now
> attempt to resolve ejb-links using a JNDI lookup.
> I can't really test the feature, so I'm waiting for your feedback and stack
> traces, if it goes wrong ;-)
> 
I finally got all pieces downloaded and compiled the change
Now we get an exception on the correct class name...:


S_STRESS_31K [true] | org.apache.naming.EjbRef |
javax.naming.NamingException: cool.models.coop07.java.S_STRESS_31KpsHome
  
javax.naming.NamingException: cool.models.coop07.java.S_STRESS_31KpsHome
at org.apache.naming.NamingContext.lookup(NamingContext.java:837)
at org.apache.naming.NamingContext.lookup(NamingContext.java:181)
at org.apache.naming.NamingContext.lookup(NamingContext.java:822)
at org.apache.naming.NamingContext.lookup(NamingContext.java:181)
at org.apache.naming.NamingContext.lookup(NamingContext.java:822)
at org.apache.naming.NamingContext.lookup(NamingContext.java:194)
at org.apache.naming.SelectorContext.lookup(SelectorContext.java:183)
at javax.naming.InitialContext.lookup(InitialContext.java:350)
at SimpleServlet.printContextInfo(SimpleServlet.java:177)
at SimpleServlet.doIt(SimpleServlet.java:99)
at SimpleServlet.doGet(SimpleServlet.java:29)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:534)
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:325)
at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:262)
at
org.apache.catalina.servlets.InvokerServlet.serveRequest(InvokerServlet.java:386)
at
org.apache.catalina.servlets.InvokerServlet.doGet(InvokerServlet.java:144)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:191)
at filters.ExampleFilter.doFilter(ExampleFilter.java:149)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:211)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:191)
at filters.ExampleFilter.doFilter(ExampleFilter.java:149)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:211)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:191)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:254)
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:879)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:213)
at
org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:468)
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:879)
at
org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2175)
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:446)
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:879)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:162)
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:879)
at
org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:827)
at
org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:904)
at java.lang.Thread.run(Thread.java:484)

Tomcat 4, webapp running from WAR file

[Glenn Nielsen]

Is the ability to run from a WAR file directly without unarchiving it
into the webapps directory completely implemented?

Jasper gives me a null pointer when it tries to see if a JSP needs
to be recompiled in its Outdated method because getRealPath() returns null,
getServletConfig().getServletContext().getRealPath(jspUri));

java.lang.NullPointerException
at java.io.File.(File.java:181)
at org.apache.jasper.compiler.JspCompiler.isOutDated(JspCompiler.java:175)
at org.apache.jasper.compiler.Compiler.compile(Compiler.java:118)
at org.apache.jasper.servlet.JspServlet.loadJSP(JspServlet.java:488)
at org.apache.jasper.servlet.JspServlet$JspServletWrapper.loadIfNecessary(Js
pServlet.java:158)
at org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet
.java:170)
at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:340)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:418)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
...

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

Re: Bug 1006, what's next ?

[Shawn McMurdo]

Tal Dayan wrote:

> [...]
> Yes, we tested the timeout patch all day yesterday with a production system
> with real users and normal load and
> all the hanging threads and connections was cleaned up perfectly (we are
> using 'netstat' to
> get the number of HTTP connections and 'ps' to get the number of thread and
> all is graphed around the clock by MRTG). We are running with a relatively
> timeout of 5 minutes (50*60*1000) just to be on the safe side but a shorter
> one can be used.

Is 50 just a typo?  Did you mean 5*60*1000?
Just thought I'd mention it in case it affects your testing.
Shawn

--
Shawn McMurdo  mailto:[EMAIL PROTECTED]
Lutris Technologieshttp://www.lutris.com
Enhydra.Orghttp://www.enhydra.org

Proposal for Compression Filter example

[Amy Roh]

Hi,

I created an example web application using Filter technology and would like to 
add to Tomcat 4 example webapps.  This example includes Data Compression Filter 
which compresses ServletResponse according to the threshold that can be set by 
users.  I think it'll be a good example usage of filters.

What do you think?

Cheers,

Amy

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

[larryi]

larryi  01/03/20 11:01:51

  Modified:src/share/org/apache/tomcat/core Tag: tomcat_32
ContextManager.java
  Log:
  Fix an additional location for the security vulnerability reported by Hiromitsu
  Takagi.  See changes for DefaultCMSetter.java version 1.45.2.10.
  
  Submitted by: Kazuhiro Kazama
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.100.2.22 +2 -2  
jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java
  
  Index: ContextManager.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/ContextManager.java,v
  retrieving revision 1.100.2.21
  retrieving revision 1.100.2.22
  diff -u -r1.100.2.21 -r1.100.2.22
  --- ContextManager.java   2001/01/12 04:39:03 1.100.2.21
  +++ ContextManager.java   2001/03/20 19:01:43 1.100.2.22
  @@ -1221,7 +1221,7 @@
  .append("\r\n");
 buf.append(sm.getString("defaulterrorpage.originalrequest"))
  .append(" ")
  -   .append( requestURI );
  +   .append(RequestUtil.filter(requestURI));
   
 if (getShowDebugInfo()) {
  if (res.isIncluded()) {
  @@ -1232,7 +1232,7 @@
 buf.append("\r\n")
  
.append(sm.getString("defaulterrorpage.notfoundrequest"))
  .append(" ")
  -   .append( requestURI );
  +   .append(RequestUtil.filter(requestURI));
  }
 }
   
  
  
  

RE: Bug 1006, what's next ?

[Tal Dayan]

Hi Mark,

Yes, we will be glad to test it.

BTW, we changed the code of the patch slightly. The timeout is now set even
if there is no factory. I am not
sure where these factories are coming from and whether it can be null but it
seems to be safer this way.

The change is documented in the bug report at
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1006

Tal

> -Original Message-
> From: Marc Saegesser [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 20, 2001 6:18 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: RE: Bug 1006, what's next ?
>
>
> Tal,
>
> It has my attention.  I'm in the process of finalizing the second beta
> release of Tomcat 3.2.2 and I will try to include this patch.
> Would you be
> able to test Tomcat 3.2.2 beta 2 (when its ready) to verify that this is
> working correctly?
>
> Marc Saegesser
>
> > -Original Message-
> > From: Tal Dayan [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, March 20, 2001 2:27 AM
> > To: [EMAIL PROTECTED]
> > Subject: Bug 1006, what's next ?
> >
> >
> >
> > Two days ago I filed a bug report regarding a sever hanging problem in
> > PollTcpEndpoint of Tomcat 3.x. The bug is
> > at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1006 and
> > also include a
> > suggestion for a patch.
> >
> > Since then I did not notice any change in the status or
> resolution of the
> > bug report nor any
> > indication that it got anywhere.
> >
> > 1. Is this is the right place to file the bug ?
> >
> > 2. Is the bug filed correctly ?
> >
> > 3. Should I do anything else to make sure the bug gets the
> > attention of the
> > relevant maintainers ?
> >
> > Thanks,
> >
> > Tal
> >
> >
>
>

RE: Bug 1006, what's next ?

[Marc Saegesser]

Does this mean that the proposed patch to call setSoTimeout() should not be
applied?

> -Original Message-
> From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 20, 2001 10:12 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Bug 1006, what's next ?
>
>
> Hi,
>
> I may help here since I figth against this kind of TCP
> bugs each days on my pay job.
>
> The problem with TCP/IP is that when there is no activity a
> read() system call (that java used) will block the calling
> thread.
>
> You could use :
>
> - select() like before read() to see if there is something to
>   get. Also on Unix there is many ioctl() for that task (FIONREAD).
>   But equivalent call are only present in JDK 1.3
>
> - you could set the socket to non blocking and add a timeout to
>   read (ie 1 second), but you'll have after that to create a kind
>   of Super read() method with the intelligence to know that a HTTP
>   request must'nt take more than 5/10 seconds.
>
> - You may use something like an Apache server in front of you tomcat
>   which as built-in support against that kind of potential DOS attack.
>
> I could try to fix that one ...
>
> >-Original Message-
> >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> >Sent: Tuesday, March 20, 2001 4:03 PM
> >To: [EMAIL PROTECTED]
> >Subject: Re: Bug 1006, what's next ?
> >
> >
> >Hi,
> >
> >I had a (long) weekend without computers. But I still found
> >one and read
> >the mail once - and your report is very serious and important ( and not
> >easy to fix ). You have (at least ) my full attention. The read
> >timeout will be checked in soon - but the general problem (
> >with a servlet
> >hanging a thread ) is very hard to resolve (or I don't know any good
> >solution ).
> >
> >We could stop setting an upper limit on the thread count ( we
> >still have
> >the OS upper limit ), and we could also use the (dangerous,
> >deprecated) suspend/terminate on the thread that is taking too
> >much time.
> >
> >Have you tried any fix ? The timeout will not resolve the
> >"bursts" ( and
> >high-loaded servers ) - unless it is very short.
> >
> >BTW, this is not a tomcat-specific problem ( I would guess Apache does
> >have the same issue - and we need to find how they deal with that ).
> >
> >Costin
> >
> >
> >On Tue, 20 Mar 2001, Tal Dayan wrote:
> >
> >>
> >> Two days ago I filed a bug report regarding a sever hanging
> >problem in
> >> PollTcpEndpoint of Tomcat 3.x. The bug is
> >> at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1006
> >and also include a
> >> suggestion for a patch.
> >>
> >> Since then I did not notice any change in the status or
> >resolution of the
> >> bug report nor any
> >> indication that it got anywhere.
> >>
> >> 1. Is this is the right place to file the bug ?
> >>
> >> 2. Is the bug filed correctly ?
> >>
> >> 3. Should I do anything else to make sure the bug gets the
> >attention of the
> >> relevant maintainers ?
> >>
> >> Thanks,
> >>
> >> Tal
> >>
> >>
> >

RE: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util RequestUtil.java

[Larry Isaacs]

> I found the handleContextNotFound method that also output HTML codes
> in ContextManager.java (but I don't know this method is used in the
> current version).
> 

I committed this fix.  Thanks for letting us know.

> >class RedirectHandler extends ServletWrapper {
> >   @@ -459,7 +460,7 @@
> > append("\r\n").
> > 
> append(sm.getString("defaulterrorpage.thisdocumenthasmoved")).
> > append("  >   - append(location).
> >   + append(RequestUtil.filter(location)).
> > append("\">here.\r\n\r\n");
> 
> This "location" variable is used as a href attribute value of an "a"
> element. In general, URL encode is done instead of HTML encode(?).
> 

The "location" is supposed to already be encoded, so encoding again
would do harm.  If it is encoded, RequestUtil.filter() shouldn't
need to change anything, so I didn't change this one.

Cheers,
Larry

Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory EjbFactory.java

[tttye]

This code does not work because the classloader is different than the
servlet class loader.  The "Class home = Class.forName(homeClassName);"
line fails with "Class.forName() failed: java.lang.ClassNotFoundException:
cool.models.coop07.java.S_STRESS_31KpsHome".
This same line works in the servlet.

Actually, I do not think the test of class type returned is necessary.  
When it is eliminated, the servlet will get an exception when casting the
remote object to the home interface anyway (assuming some type of problem).
 Otherwise, it works and less code is executed.  
Also, if this were an LDAP/IIOP class, ordinary class casting will not
work, the servlet would be using "PortableRemoteObject.narrow(...)"
instead.

So, my suggestion is to erase lines:
>   +String homeClassName = ref.getClassName();
>   +Class home = Class.forName(homeClassName);
>   +if (home.isInstance(beanObj)) {
>   +} else {
>   +throw new NamingException
>   +("Bean of type " + beanObj.getClass().getName() 
>   + + " doesn't implement home interface " 
>   + + home.getName());
>   +}
And leave only line:
>   +return beanObj;

Tim

[EMAIL PROTECTED] writes:

> remm01/03/19 17:21:07
> 
>   Modified:catalina/src/share/org/apache/naming/factory EjbFactory.java
>   Log:
>   - Use the specified ejb-link to resolve the EJB reference.
>   - Will do a JNDI lookup using the URL specified.
>   - Will also check the type of the bean returned, and check if it implements
> the home interface specified in the reference.
>   
>   Revision  ChangesPath
>   1.3   +27 -3 
>jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/EjbFactory.java
>   
>   Index: EjbFactory.java
>   ===
>   RCS file: 
>/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/EjbFactory.java,v
>   retrieving revision 1.2
>   retrieving revision 1.3
>   diff -u -r1.2 -r1.3
>   --- EjbFactory.java 2001/01/23 03:43:53 1.2
>   +++ EjbFactory.java 2001/03/20 01:21:05 1.3
>   @@ -1,7 +1,7 @@
>/*
>   - * $Header: 
>/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/EjbFactory.java,v
> 1.2 2001/01/23 03:43:53 remm Exp $
>   - * $Revision: 1.2 $
>   - * $Date: 2001/01/23 03:43:53 $
>   + * $Header: 
>/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/EjbFactory.java,v
> 1.3 2001/03/20 01:21:05 remm Exp $
>   + * $Revision: 1.3 $
>   + * $Date: 2001/03/20 01:21:05 $
> *
> * 
> *
>   @@ -67,6 +67,7 @@
>import java.util.Hashtable;
>import javax.naming.Name;
>import javax.naming.Context;
>   +import javax.naming.InitialContext;
>import javax.naming.NamingException;
>import javax.naming.Reference;
>import javax.naming.RefAddr;
>   @@ -77,7 +78,7 @@
> * Object factory for EJBs.
> * 
> * @author Remy Maucherat
>   - * @version $Revision: 1.2 $ $Date: 2001/01/23 03:43:53 $
>   + * @version $Revision: 1.3 $ $Date: 2001/03/20 01:21:05 $
> */
>
>public class EjbFactory
>   @@ -110,6 +111,27 @@
>
>if (obj instanceof EjbRef) {
>Reference ref = (Reference) obj;
>   +
>   +// If ejb-link has been specified, resolving the link using JNDI
>   +RefAddr linkRefAddr = ref.get(EjbRef.LINK);
>   +if (linkRefAddr != null) {
>   +// Retrieving the EJB link
>   +String ejbLink = linkRefAddr.getContent().toString();
>   +Object beanObj = (new InitialContext()).lookup(ejbLink);
>   +// Load home interface and checking if bean correctly
>   +// implements specified home interface
>   +String homeClassName = ref.getClassName();
>   +Class home = Class.forName(homeClassName);
>   +if (home.isInstance(beanObj)) {
>   +return beanObj;
>   +} else {
>   +throw new NamingException
>   +("Bean of type " + beanObj.getClass().getName() 
>   + + " doesn't implement home interface " 
>   + + home.getName());
>   +}
>   +}
>   +
>ObjectFactory factory = null;
>RefAddr factoryRefAddr = ref.get(Constants.FACTORY);
>if (factoryRefAddr != null) {
>   @@ -138,6 +160,7 @@
>}
>}
>}
>   +
>// Note: No defaults here
>if (factory != null) {
>return factory.getObjectInstance
>   @@ -146,6 +169,7 @@
>throw new Na

RE: Bug 1006, what's next ?

[GOMEZ Henri]

I was offline for some hours but here is a possible patch
(may be the same that Tal has in mind).

As you can see it use setSoTimeout() to 15s in the HTTP 1.0 Interceptor.
Yes, we need to add parameter in server.xml via geter/seter methods.

In http 1.1 with keep-alive connection we must use another method so
code will be different.

I take a look in apache 1.3.19, and they set Timeout to 300s (5mn) but
I think that 15s in http 1.0 is more than suffisant.

The port to TC 3.2 must be easy :-)

Thanks to comment (Tal, Costin ?)


>-Original Message-
>From: Marc Saegesser [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, March 20, 2001 8:03 PM
>To: [EMAIL PROTECTED]
>Subject: RE: Bug 1006, what's next ?
>
>
>Does this mean that the proposed patch to call setSoTimeout() 
>should not be
>applied?
>
>> -Original Message-
>> From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
>> Sent: Tuesday, March 20, 2001 10:12 AM
>> To: [EMAIL PROTECTED]
>> Subject: RE: Bug 1006, what's next ?
>>
>>
>> Hi,
>>
>> I may help here since I figth against this kind of TCP
>> bugs each days on my pay job.
>>
>> The problem with TCP/IP is that when there is no activity a
>> read() system call (that java used) will block the calling
>> thread.
>>
>> You could use :
>>
>> - select() like before read() to see if there is something to
>>   get. Also on Unix there is many ioctl() for that task (FIONREAD).
>>   But equivalent call are only present in JDK 1.3
>>
>> - you could set the socket to non blocking and add a timeout to
>>   read (ie 1 second), but you'll have after that to create a kind
>>   of Super read() method with the intelligence to know that a HTTP
>>   request must'nt take more than 5/10 seconds.
>>
>> - You may use something like an Apache server in front of you tomcat
>>   which as built-in support against that kind of potential 
>DOS attack.
>>
>> I could try to fix that one ...
>>
>> >-Original Message-
>> >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>> >Sent: Tuesday, March 20, 2001 4:03 PM
>> >To: [EMAIL PROTECTED]
>> >Subject: Re: Bug 1006, what's next ?
>> >
>> >
>> >Hi,
>> >
>> >I had a (long) weekend without computers. But I still found
>> >one and read
>> >the mail once - and your report is very serious and 
>important ( and not
>> >easy to fix ). You have (at least ) my full attention. The read
>> >timeout will be checked in soon - but the general problem (
>> >with a servlet
>> >hanging a thread ) is very hard to resolve (or I don't know any good
>> >solution ).
>> >
>> >We could stop setting an upper limit on the thread count ( we
>> >still have
>> >the OS upper limit ), and we could also use the (dangerous,
>> >deprecated) suspend/terminate on the thread that is taking too
>> >much time.
>> >
>> >Have you tried any fix ? The timeout will not resolve the
>> >"bursts" ( and
>> >high-loaded servers ) - unless it is very short.
>> >
>> >BTW, this is not a tomcat-specific problem ( I would guess 
>Apache does
>> >have the same issue - and we need to find how they deal with that ).
>> >
>> >Costin
>> >
>> >
>> >On Tue, 20 Mar 2001, Tal Dayan wrote:
>> >
>> >>
>> >> Two days ago I filed a bug report regarding a sever hanging
>> >problem in
>> >> PollTcpEndpoint of Tomcat 3.x. The bug is
>> >> at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=1006
>> >and also include a
>> >> suggestion for a patch.
>> >>
>> >> Since then I did not notice any change in the status or
>> >resolution of the
>> >> bug report nor any
>> >> indication that it got anywhere.
>> >>
>> >> 1. Is this is the right place to file the bug ?
>> >>
>> >> 2. Is the bug filed correctly ?
>> >>
>> >> 3. Should I do anything else to make sure the bug gets the
>> >attention of the
>> >> relevant maintainers ?
>> >>
>> >> Thanks,
>> >>
>> >> Tal
>> >>
>> >>
>> >
>


 Http10Interceptor.java.patch

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory EjbFactory.java

[remm]

remm01/03/20 14:04:31

  Modified:catalina/src/share/org/apache/naming/factory EjbFactory.java
  Log:
  - Won't fail when bean isn't of right type, or when failing to load home interface.
Instead, will print out debug traces.
  
  Revision  ChangesPath
  1.4   +23 -12
jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/EjbFactory.java
  
  Index: EjbFactory.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/EjbFactory.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- EjbFactory.java   2001/03/20 01:21:05 1.3
  +++ EjbFactory.java   2001/03/20 22:04:27 1.4
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/EjbFactory.java,v
 1.3 2001/03/20 01:21:05 remm Exp $
  - * $Revision: 1.3 $
  - * $Date: 2001/03/20 01:21:05 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/EjbFactory.java,v
 1.4 2001/03/20 22:04:27 remm Exp $
  + * $Revision: 1.4 $
  + * $Date: 2001/03/20 22:04:27 $
*
* 
*
  @@ -78,7 +78,7 @@
* Object factory for EJBs.
* 
* @author Remy Maucherat
  - * @version $Revision: 1.3 $ $Date: 2001/03/20 01:21:05 $
  + * @version $Revision: 1.4 $ $Date: 2001/03/20 22:04:27 $
*/
   
   public class EjbFactory
  @@ -121,15 +121,26 @@
   // Load home interface and checking if bean correctly
   // implements specified home interface
   String homeClassName = ref.getClassName();
  -Class home = Class.forName(homeClassName);
  -if (home.isInstance(beanObj)) {
  -return beanObj;
  -} else {
  -throw new NamingException
  -("Bean of type " + beanObj.getClass().getName() 
  - + " doesn't implement home interface " 
  - + home.getName());
  +try {
  +Class home = Class.forName(homeClassName);
  +if (home.isInstance(beanObj)) {
  +System.out.println("Bean of type " 
  +   + beanObj.getClass().getName() 
  +   + " doesn't implement home interface " 
  +   + home.getName());
  +} else {
  +/*
  +  throw new NamingException
  +  ("Bean of type " + beanObj.getClass().getName() 
  +  + " doesn't implement home interface " 
  +  + home.getName());
  +*/
  +}
  +} catch (ClassNotFoundException e) {
  +System.out.println("Couldn't load home interface "
  +   + homeClassName);
   }
  +return beanObj;
   }
   
   ObjectFactory factory = null;
  
  
  

Re: Strange problem with URL_PKG_PREFIXES

[Remy Maucherat]

Quoting [EMAIL PROTECTED]:

> 
> Remy Maucherat writes:
> > I've updated the object factory for the EJB references. It should now
> > attempt to resolve ejb-links using a JNDI lookup.
> > I can't really test the feature, so I'm waiting for your feedback and
> stack
> > traces, if it goes wrong ;-)
> > 
> I finally got all pieces downloaded and compiled the change
> Now we get an exception on the correct class name...:
> 
> 
> S_STRESS_31K [true] | org.apache.naming.EjbRef |
> javax.naming.NamingException:
> cool.models.coop07.java.S_STRESS_31KpsHome
>   
> javax.naming.NamingException:
> cool.models.coop07.java.S_STRESS_31KpsHome

The exception isn't very clear. It can't load the home interface, right ?
To debug that problem, the factory won't fail if loading of the home interface 
fails or if the type checking fails. If something like that happens, a message 
will be printed out on the console, but the bean instance will still be 
returned.

However, if the factory can't load the home interface class, your servlet will 
probably not be able to either (which is a problem).

Remy

RE: ajp13 restart patch - next step

[GOMEZ Henri]

> 1) Take a look at ll. 592-600.  In case of a POST request, this will
>overwrite the initial buffer (imsg) with the POST data.  If TC is then
>restarted, and that request is resent, it will be garbage 
>(POST data instead
>of request data).

You're right. I strongly didn't like to see that mixed use of buffer for
both input and output. We have now system with Mb of RAM and trying to
save some Kb is a pitty. We must use at least 2 differents buffers :

One buffer apache => tomcat , another tomcat => apache 


>How best to fix this?  I would say, pass in *both* buffers to 
>send_request
>function.  I might call them request_msg and data_msg.  Use 
>request_msg up
>to l 592, and then, if there is extra data, send it over in data_msg.

AS I said 2 buffers will not cost us only 8Kb more ;)

>Will this be fully restartable?  I'm not absolutely sure -- it 
>all depends
>on whether or not we can reread the POST data from Apache 
>after a restart
>(actually, from *all* of the servers supported by mod_jk).  

We must'nt assume that. In my actual patch by line 633 you'll
see a canrecover var that I set to true when seeing a upload
mode. In that case I consider the situation to be unrecoverable.
The solution is in that case to save all upload datas to file
and in case of error, redo from that file.

>This depends on
>the read() function of the web_server_service object -- look 
>in mod_jk.c ll.
>219-241.  I don't know the Apache API well enough to 
>understand how this
>would work if called more than once for the POST data.  To 
>fully support the
>other web servers, we'd have to understand if the read() method allowed
>rereading the initial data.

I'm not sure that in case of large upload (ie > Mb) Apache store
data from browser somewhere. Did HTTP allow us to reask to browser
to restart the upload ?

> 2) is_recoverable_error is passed into send_request, and it's value is
>assigned to, but it is in no way checked/used.  Was this also 
>true of the
>old jk_ajp13 code?  (I believe so, but I'm not sure).  If it's 
>genuinely not
>being used, we should remove it, but I would like to understand what it
>should be doing, and make sure we're not missing an error 
>state somewhere. 

It is checked at line 737. If false we stop there.

> 3) Log message errors:
>
>l. 639 Should be "Error reading reply", I think.

Yop.

>l. 663 should be "Error sending request data", I think.

ReYop

>
> 4) Still using 4-space tabs.  A quick look through some of the other C
>classes suggests that most of them don't use tabs at all (just 
>spaces). 
>Let's try to emulate that -- I'll try to stop using 8-space tabs.

Yes, I'm not confortable with 4/8 tab switch between java and C. But not
the 'core business' ;-)

I'll modify jp_ajp13_worker.c and resend diff. After that one week of
test (you too ?) and a commit after if nothing is broken.

Ok ?

>-Dan
>
>GOMEZ Henri wrote:
>> 
>> Oups not the up to date code.
>> 
>> Find attached the correct patch. It will correctly
>> handle the tomcat failure (when restarted or down)
>> during upload mode 
>> 
>> >-Original Message-
>> >From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
>> >Sent: Tuesday, March 20, 2001 1:40 PM
>> >To: [EMAIL PROTECTED]
>> >Cc: Dan Milstein (E-mail); Keith Wannamaker (E-mail)
>> >Subject: ajp13 restart patch - next step
>> >
>> >
>> >Hi,
>> >
>> >You could find attached the latest patch for mod_jk
>> >ajp13_worker.
>> >
>> >The imsg buf stand now for initial msg. I fixed the naming.
>> >
>> >Thanks to comments before I commit it.
>> >
>> >
>> >
>> >
>> >
>> >
>> 
>>   
>---
>-
>>  Name: jk_ajp13_worker.c.diff
>>jk_ajp13_worker.c.diffType: unspecified type 
>(application/octet-stream)
>>  Encoding: quoted-printable
>
>-- 
>
>Dan Milstein // [EMAIL PROTECTED]
>

Re: Tomcat 4, webapp running from WAR file

[Remy Maucherat]

Quoting Glenn Nielsen <[EMAIL PROTECTED]>:

> Is the ability to run from a WAR file directly without unarchiving it
> into the webapps directory completely implemented?

No, I'm working on some fixes for Jasper (including one for the trace you 
included).

> Jasper gives me a null pointer when it tries to see if a JSP needs
> to be recompiled in its Outdated method because getRealPath() returns
> null,
> getServletConfig().getServletContext().getRealPath(jspUri));

Here, it should use getServletConfig().getServletContext().getResource
(jspUri).openConnection().getLastModified().

There are other places where Jasper will break because of over reliance on 
getRealPath() and getPathTranslated() (in both cases, the servlet container is 
allowed to return null, and will do so when there is no physical file on the 
filesystem).

Remy

RE: Bug 1006, what's next ?

[GOMEZ Henri]

>> all is graphed around the clock by MRTG). We are running 
>with a relatively
>> timeout of 5 minutes (50*60*1000) just to be on the safe 
>side but a shorter
>> one can be used.
>
>Is 50 just a typo?  Did you mean 5*60*1000?
>Just thought I'd mention it in case it affects your testing.
>Shawn

5 * 60 * 1000 ;-)

RE: Proposal for Compression Filter example

[GOMEZ Henri]

>I created an example web application using Filter technology 
>and would like to 
>add to Tomcat 4 example webapps.  This example includes Data 
>Compression Filter 
>which compresses ServletResponse according to the threshold 
>that can be set by 
>users.  I think it'll be a good example usage of filters.
>
>What do you think?

+1 (may be a module for 3.3 ?)

I also recommand you to take a look at mod_gzip which
done that beautifully 

http://www.remotecommunications.com/apache/mod_gzip/

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/service PoolTcpEndpoint.java

[marcsaeg]

marcsaeg01/03/20 14:21:28

  Modified:src/share/org/apache/tomcat/service Tag: tomcat_32
PoolTcpEndpoint.java
  Log:
  Set the SO_TIMEOUT value on the accepted socket.  This prevents a DOS
  attacked by clients opening connections and never sending any data.
  
  The default timeout was also increased from 1 second to 5 minutes (which
  is the default value used by Apache httpd).
  
  PR:  1006
  Submitted by: [EMAIL PROTECTED] (Tal Dayan)
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.8.2.4   +9 -6  
jakarta-tomcat/src/share/org/apache/tomcat/service/Attic/PoolTcpEndpoint.java
  
  Index: PoolTcpEndpoint.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/Attic/PoolTcpEndpoint.java,v
  retrieving revision 1.8.2.3
  retrieving revision 1.8.2.4
  diff -u -r1.8.2.3 -r1.8.2.4
  --- PoolTcpEndpoint.java  2000/11/17 23:19:55 1.8.2.3
  +++ PoolTcpEndpoint.java  2001/03/20 22:21:25 1.8.2.4
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/Attic/PoolTcpEndpoint.java,v
 1.8.2.3 2000/11/17 23:19:55 craigmcc Exp $
  - * $Revision: 1.8.2.3 $
  - * $Date: 2000/11/17 23:19:55 $
  + * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/Attic/PoolTcpEndpoint.java,v
 1.8.2.4 2001/03/20 22:21:25 marcsaeg Exp $
  + * $Revision: 1.8.2.4 $
  + * $Date: 2001/03/20 22:21:25 $
*
* 
*
  @@ -98,7 +98,7 @@
   private static StringManager sm = 
StringManager.getManager("org.apache.tomcat.service");
   
   private static final int BACKLOG = 100;
  -private static final int TIMEOUT = 1000;
  +private static final int TIMEOUT = 30;  // 5 minutes
   
   private boolean isPool = true;
   
  @@ -290,8 +290,11 @@
accepted = null;
}
}
  - if( factory != null && accepted != null)
  - factory.initSocket( accepted );
  +
  +if(accepted != null)
  +accepted.setSoTimeout(timeout);
  +if( factory != null && accepted != null)
  +factory.initSocket( accepted );
}
}

  
  
  

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory EjbFactory.java

[remm]

remm01/03/20 14:24:34

  Modified:catalina/src/share/org/apache/naming/factory EjbFactory.java
  Log:
  - The debug traces were incorrect (I had reversed the test by accident). Fixed.
  
  Revision  ChangesPath
  1.5   +9 -5  
jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/EjbFactory.java
  
  Index: EjbFactory.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/EjbFactory.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- EjbFactory.java   2001/03/20 22:04:27 1.4
  +++ EjbFactory.java   2001/03/20 22:24:31 1.5
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/EjbFactory.java,v
 1.4 2001/03/20 22:04:27 remm Exp $
  - * $Revision: 1.4 $
  - * $Date: 2001/03/20 22:04:27 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/EjbFactory.java,v
 1.5 2001/03/20 22:24:31 remm Exp $
  + * $Revision: 1.5 $
  + * $Date: 2001/03/20 22:24:31 $
*
* 
*
  @@ -78,7 +78,7 @@
* Object factory for EJBs.
* 
* @author Remy Maucherat
  - * @version $Revision: 1.4 $ $Date: 2001/03/20 22:04:27 $
  + * @version $Revision: 1.5 $ $Date: 2001/03/20 22:24:31 $
*/
   
   public class EjbFactory
  @@ -126,9 +126,13 @@
   if (home.isInstance(beanObj)) {
   System.out.println("Bean of type " 
  + beanObj.getClass().getName() 
  -   + " doesn't implement home interface " 
  +   + " implements home interface " 
  + home.getName());
   } else {
  +System.out.println("Bean of type " 
  +   + beanObj.getClass().getName() 
  +   + " doesn't implement home interface " 
  +   + home.getName());
   /*
 throw new NamingException
 ("Bean of type " + beanObj.getClass().getName() 
  
  
  

RE: Proposal for Compression Filter example

[Craig R. McClanahan]

On Tue, 20 Mar 2001, GOMEZ Henri wrote:

> >I created an example web application using Filter technology 
> >and would like to 
> >add to Tomcat 4 example webapps.  This example includes Data 
> >Compression Filter 
> >which compresses ServletResponse according to the threshold 
> >that can be set by 
> >users.  I think it'll be a good example usage of filters.
> >
> >What do you think?
> 
> +1 (may be a module for 3.3 ?)
> 

Anyone who wants to create a module for this kind of functionality can, of
course, do so.  The advantage of impementing it as a Filter is that it
will be portable to any 2.3 servlet container.

> I also recommand you to take a look at mod_gzip which
> done that beautifully 
> 
> http://www.remotecommunications.com/apache/mod_gzip/
> 

Craig

Re: Tomcat 4, webapp running from WAR file

[Glenn Nielsen]

Remy Maucherat wrote:
> 
> Quoting Glenn Nielsen <[EMAIL PROTECTED]>:
> 
> > Is the ability to run from a WAR file directly without unarchiving it
> > into the webapps directory completely implemented?
> 
> No, I'm working on some fixes for Jasper (including one for the trace you
> included).
> 
> > Jasper gives me a null pointer when it tries to see if a JSP needs
> > to be recompiled in its Outdated method because getRealPath() returns
> > null,
> > getServletConfig().getServletContext().getRealPath(jspUri));
> 
> Here, it should use getServletConfig().getServletContext().getResource
> (jspUri).openConnection().getLastModified().
> 
> There are other places where Jasper will break because of over reliance on
> getRealPath() and getPathTranslated() (in both cases, the servlet container is
> allowed to return null, and will do so when there is no physical file on the
> filesystem).
> 
> Remy


Ok, I ran across that when I started working on implementing the logic
for how webapps are unarchived.  It sidetracked me for a bit.  I'll let
you take care of the Jasper fixes for using JSP's directly from a WAR file.

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

Re: pathTranslated and pathInfo... More unsafe paths

[christopher hull]

Craig R. McClanahan wrote:

> 
> On Wed, 14 Mar 2001, christopher hull wrote:
> 
> 
>> Wow!  Thanks for the quick response.
>> 
>> The problem it turns out has nothing to do with spaces.  When 
>> getResourceAsStream() can't find a resource, it displays a space just 
>> after the root for convenience.  It turns out that getResourceAsStream
>>   is case sensitive.  Is there a way to tell getResourceAsStream
>>   not to be?
>> 
> 
> 
> Servlets are case sensitive.  Tomcat 3.1 and 3.2 (without the .1
> updates) had problems in this area that caused huge security holes because
> they were NOT completely case sensitive.
> 
> If you still want non-case-sensitive Tomcat, well, you've got the source
> code ... but you are totally on your own.
> 
> 
>> Thanks;
>> -Chris
>> 
> 
> 
> Craig McClanahan

Naw, case sensitive Tomcat sounds like the wrong answer.  We want to 
work with any servlet host.  We'll fix our XSL.  Thanks again.

-- 

Christopher Hull
Engineering Group Manager, Senior Software Architect
Mediagate Inc.
iPost Card http://web.mediagate.com/chris.hull
iPost Voice408 261 7201
email  [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory EjbFactory.java

[Remy Maucherat]

> This code does not work because the classloader is different than the
> servlet class loader.  The "Class home = Class.forName(homeClassName);"
> line fails with "Class.forName() failed: java.lang.ClassNotFoundException:
> cool.models.coop07.java.S_STRESS_31KpsHome".
> This same line works in the servlet.

I thought this would be equivalent, but Class.forName doesn't use the
context class loader. Instead, I should directly use the context class
loader to load the home interface ...

I re-read the J2EE 1.3 PFD spec, and I mistakenly interpreted paragraph
5.3.3 as things I had to enforce.

> Actually, I do not think the test of class type returned is necessary.
> When it is eliminated, the servlet will get an exception when casting the
> remote object to the home interface anyway (assuming some type of
problem).
>  Otherwise, it works and less code is executed.
> Also, if this were an LDAP/IIOP class, ordinary class casting will not
> work, the servlet would be using "PortableRemoteObject.narrow(...)"
> instead.

True.

> So, my suggestion is to erase lines:
> >   +String homeClassName = ref.getClassName();
> >   +Class home = Class.forName(homeClassName);
> >   +if (home.isInstance(beanObj)) {
> >   +} else {
> >   +throw new NamingException
> >   +("Bean of type " +
beanObj.getClass().getName()
> >   + + " doesn't implement home interface "
> >   + + home.getName());
> >   +}
> And leave only line:
> >   +return beanObj;

Ok.

Remy

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory EjbFactory.java

[remm]

remm01/03/20 15:17:37

  Modified:catalina/src/share/org/apache/naming/factory EjbFactory.java
  Log:
  - Comment out the type checking, as suggested by Tim Tye.
  
  Revision  ChangesPath
  1.6   +10 -10
jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/EjbFactory.java
  
  Index: EjbFactory.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/EjbFactory.java,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- EjbFactory.java   2001/03/20 22:24:31 1.5
  +++ EjbFactory.java   2001/03/20 23:17:34 1.6
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/EjbFactory.java,v
 1.5 2001/03/20 22:24:31 remm Exp $
  - * $Revision: 1.5 $
  - * $Date: 2001/03/20 22:24:31 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/factory/EjbFactory.java,v
 1.6 2001/03/20 23:17:34 remm Exp $
  + * $Revision: 1.6 $
  + * $Date: 2001/03/20 23:17:34 $
*
* 
*
  @@ -78,7 +78,7 @@
* Object factory for EJBs.
* 
* @author Remy Maucherat
  - * @version $Revision: 1.5 $ $Date: 2001/03/20 22:24:31 $
  + * @version $Revision: 1.6 $ $Date: 2001/03/20 23:17:34 $
*/
   
   public class EjbFactory
  @@ -120,6 +120,7 @@
   Object beanObj = (new InitialContext()).lookup(ejbLink);
   // Load home interface and checking if bean correctly
   // implements specified home interface
  +/*
   String homeClassName = ref.getClassName();
   try {
   Class home = Class.forName(homeClassName);
  @@ -133,17 +134,16 @@
  + beanObj.getClass().getName() 
  + " doesn't implement home interface " 
  + home.getName());
  -/*
  -  throw new NamingException
  -  ("Bean of type " + beanObj.getClass().getName() 
  -  + " doesn't implement home interface " 
  -  + home.getName());
  -*/
  +throw new NamingException
  +("Bean of type " + beanObj.getClass().getName() 
  + + " doesn't implement home interface " 
  + + home.getName());
   }
   } catch (ClassNotFoundException e) {
   System.out.println("Couldn't load home interface "
  + homeClassName);
   }
  +*/
   return beanObj;
   }
   
  
  
  

RE: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/service PoolTcpEndpoint.java

[GOMEZ Henri]

You we're just too fast ;-)

What happen to ajpx connector with that patch ?

If ajp12 is a short life connection, ajp13 need permanent connection !
The setTimeOut in that case will broke it ;(

Si la fortune vient en dormant, ça n'empêche pas les emmerdements de venir
au réveil.
-- Pierre Dac

>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, March 20, 2001 11:21 PM
>To: [EMAIL PROTECTED]
>Subject: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/service
>PoolTcpEndpoint.java
>
>
>marcsaeg01/03/20 14:21:28
>
>  Modified:src/share/org/apache/tomcat/service Tag: tomcat_32
>PoolTcpEndpoint.java
>  Log:
>  Set the SO_TIMEOUT value on the accepted socket.  This prevents a DOS
>  attacked by clients opening connections and never sending any data.
>  
>  The default timeout was also increased from 1 second to 5 
>minutes (which
>  is the default value used by Apache httpd).
>  
>  PR:  1006
>  Submitted by:[EMAIL PROTECTED] (Tal Dayan)
>  
>  Revision  ChangesPath
>  No   revision
>  
>  
>  No   revision
>  
>  
>  1.8.2.4   +9 -6  
>jakarta-tomcat/src/share/org/apache/tomcat/service/Attic/PoolTc
>pEndpoint.java
>  
>  Index: PoolTcpEndpoint.java
>  ===
>  RCS file: 
>/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/At
>tic/PoolTcpEndpoint.java,v
>  retrieving revision 1.8.2.3
>  retrieving revision 1.8.2.4
>  diff -u -r1.8.2.3 -r1.8.2.4
>  --- PoolTcpEndpoint.java 2000/11/17 23:19:55 1.8.2.3
>  +++ PoolTcpEndpoint.java 2001/03/20 22:21:25 1.8.2.4
>  @@ -1,7 +1,7 @@
>   /*
>  - * $Header: 
>/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/At
>tic/PoolTcpEndpoint.java,v 1.8.2.3 2000/11/17 23:19:55 craigmcc Exp $
>  - * $Revision: 1.8.2.3 $
>  - * $Date: 2000/11/17 23:19:55 $
>  + * $Header: 
>/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/At
>tic/PoolTcpEndpoint.java,v 1.8.2.4 2001/03/20 22:21:25 marcsaeg Exp $
>  + * $Revision: 1.8.2.4 $
>  + * $Date: 2001/03/20 22:21:25 $
>*
>* 
>
>*
>  @@ -98,7 +98,7 @@
>   private static StringManager sm = 
>StringManager.getManager("org.apache.tomcat.service");
>   
>   private static final int BACKLOG = 100;
>  -private static final int TIMEOUT = 1000;
>  +private static final int TIMEOUT = 30;  // 5 minutes
>   
>   private boolean isPool = true;
>   
>  @@ -290,8 +290,11 @@
>   accepted = null;
>   }
>   }
>  -if( factory != null && accepted != null)
>  -factory.initSocket( accepted );
>  +
>  +if(accepted != null)
>  +accepted.setSoTimeout(timeout);
>  +if( factory != null && accepted != null)
>  +factory.initSocket( accepted );
>   }
>   }
>   
>  
>  
>  
>

Control Channel and Thread Pool (was bug 1006)

[Tal Dayan]

Hi Costin,


> The timeout patch will certainly go into tomcat3.3, and I think Marc will
> add it to 3.2 also - it's a good solution and I don't think it can brake
> anything.

Great, we will be able to drop soon our proprietry patches.zip library. ;-)

BTW, Our patch library currently contains three patches: the socketRead()
timeout path, the JSP class
encoding patch (to address NT's file name limit of 256 chars), and a patch
that eliminate the full disclosure that Tomcat does
regarding its version, the OS and its version and the JVM and its version
(we consider it to be a security issue, it will be nice to be able to
disable this disclosure or even set our own string for an out of the box
Tomcat).

> I was thinking about what we can do for a more general solution - and
> looking at the code I think there are few easy things that need to be
> done related with thread pools:
>
> - use a common thread pool for all endpoints ( right now ajp12 is creating
> a full thread pool for itself, etc).

Yes, this will be more efficient. For example, the current standlone version
allocates 10 threads by default
for the Ajp connector even though only few may be needed for shutdown. The
problem however is that if you will get
to the max threads, you will not be able to shutdown Tomcat.

> - document the thread pool implementation, remove some old code
>
> - add an admin page to monitor the thread pools

Here is a simple idea that works well for us and will bring great benefit to
the
entire Jakarta project (unless it already exists ;-))

We have in our application a Control mechanism that allows to send commands
and get information from various parts of the application. It is build in a
modular way such that every module can add its command handlers dynamically.
This way, you have very good access to the internals of the server and the
application. Somthing similar to SNMP but simpler.

Then you can use this mechnaism to get any status information from any
module (e.g. ThreadPool), send commands etc. The access to this control can
be with Java API, servlet that uses HTMl or XML, SOAP, XMLRPC, etc and you
can access all of the status and control points in a uniform way.

In our case, the access is done both using Java API and through a servlet.
The servlet present an interactive form in which you can post the commands
and see the results. We also have a simple command-line client (writen in
Java) that allows to send the commands and get the status from a command
line (great for scripting).

We can release the source code of it but I think it will be better if it is
redisgned and implemented in a more general way. This will be easy to do and
will brings great benifit.

> - use the thread pool to run session expire and verify the expire bugs
> - add a ThreadPoolListener/Event to allow a (future) module to monitor and
> manage the thread pool
>
> - add a field to store the current "owner" or "user" of each thread.

Yes, this will be very useful. And with the above control mechanism you will
be able to get not just the status of the pool but also things like how long
does each worker is performing the current task (since it was allocated from
the pool).

BTW, this can be improved even with the current code. Currently when you
perform a thread/stack dump of the JVM, you can see all the threads that are
waiting in the thread pools but you don't know which is which. Setting the
thread names to something like 'PoolName-01' instead of 'Thread-01' will be
very useful.

> - add some log messages for the case when the thread pool is at the
> maximum capacity

Yes, and if you can control the verbosity levels in your logs, you can also
report when they are freed or periodically (by the control thread of the
pool) what is the status of the pool. And with the control mechanism, you
will be able to easily play with all kind of scenarios, for example, by
changing pool parameters while the server is running, issue 'free all unused
thread', or 'abort thread 34' commands, increase the verbosity level of the
thread pool log, etc.

> - maybe provide a spare "admin" thread that can be used to "un-hang" the
> server without restarting tomcat ( i.e. if the thread pool is at max
> capacity, and if the connector detects a localhost connection allow it to
> create an extra thread - so an admin application can kill threads ).

Maybe you can detect the this bad conditions, you may use the control thread
of the thread pool to
abort hanging threads. And with the external control mechanism, you can even
have external monitoring programs to issue a 'soft reset' command to Tomcat.

> - API change in ThreadPool - allow it to run normal Runnable ( the current
> ThreadPoolRunnable has some nice performance tricks, but it should be
> usable for normal tasks that don't want to take advantage of overhead-free
> thread data )
>
> None of those would resolve the DOS problem, but I think it would be nice
> to have them (and very easy to implement - without affecting

RE: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/service PoolTcpEndpoint.java

[GOMEZ Henri]

I suggest you to set the timeout in HttpConnectionHandler :

//  System.out.println("New Connection");
try {
// XXX - Add workarounds for the fact that the underlying
// serverSocket.accept() call can now time out.  This whole
// architecture needs some serious review.
if (connection == null)
return;
//  System.out.print("1");
socket=connection.getSocket();
if (socket == null)
return;

socket.setSoTimeout(15000); // 15s Timeout - must be suffisant
for http 1.0 request

//  System.out.print("2");
InputStream in=socket.getInputStream();
OutputStream out=socket.getOutputStream();


Apache server use 300s (5mn) which is fine for HTTP 1.1 keep-alive
connection. In http 1.0 connection 15s must be suffisant between accept()
and read. The browser must'nt spend more than 15 seconds between to packet
emission (even 1 byte packet) IMHO. 

We must forward the question to Apache gurus. I'll contact Ryan Bloom
for more info 


>-Original Message-
>From: GOMEZ Henri 
>Sent: Wednesday, March 21, 2001 12:19 AM
>To: '[EMAIL PROTECTED]'
>Subject: RE: cvs commit:
>jakarta-tomcat/src/share/org/apache/tomcat/service PoolTcpEndpoint.java
>
>
>You we're just too fast ;-)
>
>What happen to ajpx connector with that patch ?
>
>If ajp12 is a short life connection, ajp13 need permanent connection !
>The setTimeOut in that case will broke it ;(
>
>Si la fortune vient en dormant, ça n'empêche pas les 
>emmerdements de venir au réveil.
>-- Pierre Dac
>
>>-Original Message-
>>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>>Sent: Tuesday, March 20, 2001 11:21 PM
>>To: [EMAIL PROTECTED]
>>Subject: cvs commit: 
>jakarta-tomcat/src/share/org/apache/tomcat/service
>>PoolTcpEndpoint.java
>>
>>
>>marcsaeg01/03/20 14:21:28
>>
>>  Modified:src/share/org/apache/tomcat/service Tag: tomcat_32
>>PoolTcpEndpoint.java
>>  Log:
>>  Set the SO_TIMEOUT value on the accepted socket.  This 
>prevents a DOS
>>  attacked by clients opening connections and never sending any data.
>>  
>>  The default timeout was also increased from 1 second to 5 
>>minutes (which
>>  is the default value used by Apache httpd).
>>  
>>  PR:  1006
>>  Submitted by:   [EMAIL PROTECTED] (Tal Dayan)
>>  
>>  Revision  ChangesPath
>>  No   revision
>>  
>>  
>>  No   revision
>>  
>>  
>>  1.8.2.4   +9 -6  
>>jakarta-tomcat/src/share/org/apache/tomcat/service/Attic/PoolTc
>>pEndpoint.java
>>  
>>  Index: PoolTcpEndpoint.java
>>  ===
>>  RCS file: 
>>/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/At
>>tic/PoolTcpEndpoint.java,v
>>  retrieving revision 1.8.2.3
>>  retrieving revision 1.8.2.4
>>  diff -u -r1.8.2.3 -r1.8.2.4
>>  --- PoolTcpEndpoint.java2000/11/17 23:19:55 1.8.2.3
>>  +++ PoolTcpEndpoint.java2001/03/20 22:21:25 1.8.2.4
>>  @@ -1,7 +1,7 @@
>>   /*
>>  - * $Header: 
>>/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/At
>>tic/PoolTcpEndpoint.java,v 1.8.2.3 2000/11/17 23:19:55 craigmcc Exp $
>>  - * $Revision: 1.8.2.3 $
>>  - * $Date: 2000/11/17 23:19:55 $
>>  + * $Header: 
>>/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/At
>>tic/PoolTcpEndpoint.java,v 1.8.2.4 2001/03/20 22:21:25 marcsaeg Exp $
>>  + * $Revision: 1.8.2.4 $
>>  + * $Date: 2001/03/20 22:21:25 $
>>*
>>* 
>>
>>*
>>  @@ -98,7 +98,7 @@
>>   private static StringManager sm = 
>>StringManager.getManager("org.apache.tomcat.service");
>>   
>>   private static final int BACKLOG = 100;
>>  -private static final int TIMEOUT = 1000;
>>  +private static final int TIMEOUT = 30;  // 5 minutes
>>   
>>   private boolean isPool = true;
>>   
>>  @@ -290,8 +290,11 @@
>>  accepted = null;
>>  }
>>  }
>>  -   if( factory != null && accepted != null)
>>  -   factory.initSocket( accepted );
>>  +
>>  +if(accepted != null)
>>  +accepted.setSoTimeout(timeout);
>>  +if( factory != null && accepted != null)
>>  +factory.initSocket( accepted );
>>  }
>>  }
>>  
>>  
>>  
>>  
>>
>

cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler JspCompiler.java JspReader.java ParserController.java TagLibraryInfoImpl.java

[remm]

remm01/03/20 16:08:53

  Modified:jasper/src/share/org/apache/jasper/compiler JspCompiler.java
JspReader.java ParserController.java
TagLibraryInfoImpl.java
  Log:
  - Jasper should run from WARs (or any other repository which provides a directory
context to access it).
  - All Watchdog 4 tests pass (servlets, JSP, JSP-XML).
  - Of course, the classes and JARs are still extracted from the WAR until the
compilation technology is updated (javac wants files :(( ).
  
  Revision  ChangesPath
  1.4   +7 -5  
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspCompiler.java
  
  Index: JspCompiler.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspCompiler.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- JspCompiler.java  2001/02/04 01:05:02 1.3
  +++ JspCompiler.java  2001/03/21 00:08:50 1.4
  @@ -163,17 +163,19 @@
* from whence it came
*/
   public boolean isOutDated() {
  -File jspReal = null;
  +long jspRealLastModified = 0;
   
  -jspReal = new File(ctxt.getRealPath(jsp.getPath()));
  -
  -if (!jspReal.exists()) {
  +try {
  +jspRealLastModified = ctxt.getResource(jsp.getPath())
  +.openConnection().getLastModified();
  +} catch (Exception e) {
  +e.printStackTrace();
   return true;
   }
   
   File classFile = new File(getClassFileName());
   if (classFile.exists()) {
  -outDated = classFile.lastModified() < jspReal.lastModified();
  +outDated = classFile.lastModified() < jspRealLastModified;
   } else {
   outDated = true;
   }
  
  
  
  1.5   +2 -0  
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspReader.java
  
  Index: JspReader.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspReader.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- JspReader.java2000/10/11 19:35:14 1.4
  +++ JspReader.java2001/03/21 00:08:51 1.5
  @@ -248,6 +248,8 @@
String longName = (context == null)
? file.getAbsolutePath()
: context.getRealPath(file.toString());
  +if (longName == null)
  +longName = file.toString();
   
int fileid = registerSourceFile(longName);
   
  
  
  
  1.12  +1 -1  
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/ParserController.java
  
  Index: ParserController.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/ParserController.java,v
  retrieving revision 1.11
  retrieving revision 1.12
  diff -u -r1.11 -r1.12
  --- ParserController.java 2001/03/15 22:42:12 1.11
  +++ ParserController.java 2001/03/21 00:08:51 1.12
  @@ -187,7 +187,7 @@
   File file = new File(absFileName);
String filePath = (ctxt == null) 
? file.getAbsolutePath()
  - : ctxt.getRealPath(file.toString());
  + : file.toString();//ctxt.getRealPath(file.toString());
//p("filePath: " + filePath);
   
String encoding = topFileEncoding;
  
  
  
  1.21  +8 -4  
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java
  
  Index: TagLibraryInfoImpl.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java,v
  retrieving revision 1.20
  retrieving revision 1.21
  diff -u -r1.20 -r1.21
  --- TagLibraryInfoImpl.java   2001/02/18 02:18:14 1.20
  +++ TagLibraryInfoImpl.java   2001/03/21 00:08:52 1.21
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java,v
 1.20 2001/02/18 02:18:14 craigmcc Exp $
  - * $Revision: 1.20 $
  - * $Date: 2001/02/18 02:18:14 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/TagLibraryInfoImpl.java,v
 1.21 2001/03/21 00:08:52 remm Exp $
  + * $Revision: 1.21 $
  + * $Date: 2001/03/21 00:08:52 $
*
* The Apache Software License, Version 1.1
*
  @@ -152,7 +152,11 @@
   try {
   // see if file exists on the filesystem first
   String real = ctxt.getRealPath(uri);
  -return (real == null) ? null : new FileInputStream(real);
  +if (real == null) {
  +return ctxt.getResourceAsStream(uri);
  +} else {
  +return new FileInputStream(re

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

[remm]

remm01/03/20 16:27:03

  Modified:jasper/src/share/org/apache/jasper/compiler
ParserController.java
  Log:
  - The fix in that source file wasn't the same as in JspReader (and the fix in
JspReader appears to be a bit better).
  
  Revision  ChangesPath
  1.13  +4 -1  
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/ParserController.java
  
  Index: ParserController.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/ParserController.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- ParserController.java 2001/03/21 00:08:51 1.12
  +++ ParserController.java 2001/03/21 00:27:01 1.13
  @@ -187,7 +187,10 @@
   File file = new File(absFileName);
String filePath = (ctxt == null) 
? file.getAbsolutePath()
  - : file.toString();//ctxt.getRealPath(file.toString());
  + : ctxt.getRealPath(file.toString());
  +if (filePath == null) {
  +filePath = file.toString();
  +}
//p("filePath: " + filePath);
   
String encoding = topFileEncoding;
  
  
  

RE: Proposal for Compression Filter example

[Chen, Hao Han]

+1

regards,
haohan

-Original Message-
From: Amy Roh [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 21, 2001 5:05 AM
To: [EMAIL PROTECTED]
Subject: Proposal for Compression Filter example


Hi,

I created an example web application using Filter technology and would like
to 
add to Tomcat 4 example webapps.  This example includes Data Compression
Filter 
which compresses ServletResponse according to the threshold that can be set
by 
users.  I think it'll be a good example usage of filters.

What do you think?

Cheers,

Amy

Re: Proposal for Compression Filter example

[Craig R. McClanahan]

On Tue, 20 Mar 2001, Amy Roh wrote:

> Hi,
> 
> I created an example web application using Filter technology and would like to 
> add to Tomcat 4 example webapps.  This example includes Data Compression Filter 
> which compresses ServletResponse according to the threshold that can be set by 
> users.  I think it'll be a good example usage of filters.
> 
> What do you think?
> 
> Cheers,
> 
> Amy
> 
+1 ... go for it.

Craig

RE: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/service PoolTcpEndpoint.java

[Tal Dayan]

Hi Henri,

Thanks for the fix.

The setSoTimeout controls the max time socketRead() blocks until it
timeouts.  15 seconds is way
too short IMHO. Especially if you don't provide a way to configure it.

If the user uploads a large file through a slow modem and the network has
soft problem for 15 secs, we don't
want to abort that connection yet.

Please consider to increase the hard coded value. Even several minutes
should be ok. I think 15 sec solves one problem
but creates a new one.

Also, are there other services that need to be modified (e.g. SSL) ?

Take care,

Tal

> -Original Message-
> From: GOMEZ Henri [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 20, 2001 3:28 PM
> To: [EMAIL PROTECTED]
> Subject: RE: cvs commit:
> jakarta-tomcat/src/share/org/apache/tomcat/service PoolTcpEndpoint.java
>
>
> I suggest you to set the timeout in HttpConnectionHandler :
>
>   //  System.out.println("New Connection");
>   try {
>   // XXX - Add workarounds for the fact that the underlying
>   // serverSocket.accept() call can now time out.  This whole
>   // architecture needs some serious review.
>   if (connection == null)
>   return;
>   //  System.out.print("1");
>   socket=connection.getSocket();
>   if (socket == null)
>   return;
>
>   socket.setSoTimeout(15000); // 15s Timeout - must be suffisant
> for http 1.0 request
>
>   //  System.out.print("2");
>   InputStream in=socket.getInputStream();
>   OutputStream out=socket.getOutputStream();
>
>
> Apache server use 300s (5mn) which is fine for HTTP 1.1 keep-alive
> connection. In http 1.0 connection 15s must be suffisant between accept()
> and read. The browser must'nt spend more than 15 seconds between to packet
> emission (even 1 byte packet) IMHO.
>
> We must forward the question to Apache gurus. I'll contact Ryan Bloom
> for more info 
>
>
> >-Original Message-
> >From: GOMEZ Henri
> >Sent: Wednesday, March 21, 2001 12:19 AM
> >To: '[EMAIL PROTECTED]'
> >Subject: RE: cvs commit:
> >jakarta-tomcat/src/share/org/apache/tomcat/service PoolTcpEndpoint.java
> >
> >
> >You we're just too fast ;-)
> >
> >What happen to ajpx connector with that patch ?
> >
> >If ajp12 is a short life connection, ajp13 need permanent connection !
> >The setTimeOut in that case will broke it ;(
> >
> >Si la fortune vient en dormant, ça n'empêche pas les
> >emmerdements de venir au réveil.
> >-- Pierre Dac
> >
> >>-Original Message-
> >>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> >>Sent: Tuesday, March 20, 2001 11:21 PM
> >>To: [EMAIL PROTECTED]
> >>Subject: cvs commit:
> >jakarta-tomcat/src/share/org/apache/tomcat/service
> >>PoolTcpEndpoint.java
> >>
> >>
> >>marcsaeg01/03/20 14:21:28
> >>
> >>  Modified:src/share/org/apache/tomcat/service Tag: tomcat_32
> >>PoolTcpEndpoint.java
> >>  Log:
> >>  Set the SO_TIMEOUT value on the accepted socket.  This
> >prevents a DOS
> >>  attacked by clients opening connections and never sending any data.
> >>
> >>  The default timeout was also increased from 1 second to 5
> >>minutes (which
> >>  is the default value used by Apache httpd).
> >>
> >>  PR:  1006
> >>  Submitted by: [EMAIL PROTECTED] (Tal Dayan)
> >>
> >>  Revision  ChangesPath
> >>  No   revision
> >>
> >>
> >>  No   revision
> >>
> >>
> >>  1.8.2.4   +9 -6
> >>jakarta-tomcat/src/share/org/apache/tomcat/service/Attic/PoolTc
> >>pEndpoint.java
> >>
> >>  Index: PoolTcpEndpoint.java
> >>  ===
> >>  RCS file:
> >>/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/At
> >>tic/PoolTcpEndpoint.java,v
> >>  retrieving revision 1.8.2.3
> >>  retrieving revision 1.8.2.4
> >>  diff -u -r1.8.2.3 -r1.8.2.4
> >>  --- PoolTcpEndpoint.java  2000/11/17 23:19:55 1.8.2.3
> >>  +++ PoolTcpEndpoint.java  2001/03/20 22:21:25 1.8.2.4
> >>  @@ -1,7 +1,7 @@
> >>   /*
> >>  - * $Header:
> >>/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/At
> >>tic/PoolTcpEndpoint.java,v 1.8.2.3 2000/11/17 23:19:55 craigmcc Exp $
> >>  - * $Revision: 1.8.2.3 $
> >>  - * $Date: 2000/11/17 23:19:55 $
> >>  + * $Header:
> >>/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/service/At
> >>tic/PoolTcpEndpoint.java,v 1.8.2.4 2001/03/20 22:21:25 marcsaeg Exp $
> >>  + * $Revision: 1.8.2.4 $
> >>  + * $Date: 2001/03/20 22:21:25 $
> >>*
> >>*
> >>
> >>*
> >>  @@ -98,7 +98,7 @@
> >>   private static StringManager sm =
> >>StringManager.getManager("org.apache.tomcat.service");
> >>
> >>   private static final int BACKLOG = 100;
> >>  -private static final int TIMEOUT = 1000;
> >>  +private static final int TIMEOUT = 30;  // 5 minutes
> >>
> >>   private boolean isPool = true;
> >>
> >>  @@ -29

RE: Bug 1006, what's next ?

[Tal Dayan]

Yes, this is a typo. It should by 5.

Here is a verbatim paste of the statement we are using:

private static final int TIMEOUT = 5*60*1000;   // read() timeout in ms

;-)

Tal



> -Original Message-
> From: Shawn McMurdo [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, March 20, 2001 12:55 PM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: Bug 1006, what's next ?
>
>
>
> Tal Dayan wrote:
>
> > [...]
> > Yes, we tested the timeout patch all day yesterday with a
> production system
> > with real users and normal load and
> > all the hanging threads and connections was cleaned up perfectly (we are
> > using 'netstat' to
> > get the number of HTTP connections and 'ps' to get the number
> of thread and
> > all is graphed around the clock by MRTG). We are running with a
> relatively
> > timeout of 5 minutes (50*60*1000) just to be on the safe side
> but a shorter
> > one can be used.
>
> Is 50 just a typo?  Did you mean 5*60*1000?
> Just thought I'd mention it in case it affects your testing.
> Shawn
>
> --
> Shawn McMurdo  mailto:[EMAIL PROTECTED]
> Lutris Technologieshttp://www.lutris.com
> Enhydra.Orghttp://www.enhydra.org
>
>
>

cvs commit: jakarta-tomcat-4.0/catalina/docs/config logger.html realm.html valve.html context.html engine.html host.html

[craigmcc]

craigmcc01/03/20 17:59:21

  Modified:catalina/docs/config context.html engine.html host.html
  Added:   catalina/docs/config logger.html realm.html valve.html
  Log:
  Flesh out configuration documents for the Logger, Realm, and Valve
  utility components.  Several more need to be finished before the
  configuration document can be considered complete.
  
  Revision  ChangesPath
  1.4   +4 -2  jakarta-tomcat-4.0/catalina/docs/config/context.html
  
  Index: context.html
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/docs/config/context.html,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- context.html  2001/02/26 03:48:59 1.3
  +++ context.html  2001/03/21 01:59:18 1.4
  @@ -338,11 +338,13 @@
   
   
   
  -See Request Filter Valve for
  -more information on the syntax of the filters, and the logic that is applied
  +See Remote Address Filter or
  +Remote Host Filter for more
  +information on the syntax of these filters, and the logic that is applied
   when they are executed.
   
   
  +
   
   
   
  
  
  
  1.3   +4 -2  jakarta-tomcat-4.0/catalina/docs/config/engine.html
  
  Index: engine.html
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/docs/config/engine.html,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- engine.html   2001/01/14 04:17:05 1.2
  +++ engine.html   2001/03/21 01:59:19 1.3
  @@ -203,11 +203,13 @@
   
   
   
  -See Request Filter Valve for
  -more information on the syntax of the filters, and the logic that is applied
  +See Remote Address Filter or
  +Remote Host Filter for more
  +information on the syntax of these filters, and the logic that is applied
   when they are executed.
   
   
  +
   
   
   
  
  
  
  1.4   +5 -2  jakarta-tomcat-4.0/catalina/docs/config/host.html
  
  Index: host.html
  ===
  RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/docs/config/host.html,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- host.html 2001/01/27 00:21:38 1.3
  +++ host.html 2001/03/21 01:59:19 1.4
  @@ -284,10 +284,12 @@
   
   
   
  -See Request Filter Valve for
  -more information on the syntax of the filters, and the logic that is applied
  +See Remote Address Filter or
  +Remote Host Filter for more
  +information on the syntax of these filters, and the logic that is applied
   when they are executed.
   
  +
   User Web Applications
   
   Many web servers automtically map a request path starting with a
  @@ -344,6 +346,7 @@
   and all directories above it, for this feature to operate correctly.
   
   
  +
   
   
   
  
  
  
  1.1  jakarta-tomcat-4.0/catalina/docs/config/logger.html
  
  Index: logger.html
  ===
  
  
  The 'Logger' Component
  
  
  
  
  The Logger Component
  
  [Introduction]
  [Common Attributes]
  [Standard Implementation 
Attributes]
  
  
  
  
  
  Introduction
  
  A Logger component represents a mechanism by which event,
  error, and debugging information from a Catalina component, or group of such
  components, can be directed to a common destination.  Each Logger is
  associated with a Container, by being nested inside the
  corresponding , , or
   element for that Container.
  
  If you attach a Logger to an outer Container (such as an
  Engine, that logger will be used for all nested Containers
  (Host and Context components), unless you
  specifically nest a different logger inside the nested Container.
  
  
  
  
  
  Common Attributes
  
  All implementations of the Logger component support the
  following attributes:
  
  
  

  Attribute
  Description

  

  className
  Java class name of the implementation to use.  This class must
  implement the org.apache.catalina.Logger interface.
  Because there is no single standard implementation, this attribute
  is required.  See 
  Standard Implementation Attributes for the names of the
  supported classes.
  

  

  verbosity
  The verbosity level for this logger.  Messages with a higher
  verbosity than the specified level will be silently ignored.
  Available levels are 0 (fatal messages only), 1 (errors),
  2 (warnings), 3 (information), and 4 (debug).  If not specified,
  the default value is 1 (error).  Note that messages logged with
  no verbosity parameter are logged unconditionally.

  
  
  
  
  
  
  
  Standard Implementation Attributes
  
  Unlike most other Catalina components, there is not a single standard
  implementation of the Logger component available.  Inst

Anyone know how I can unsubscribe from this list?

[Andrew Hopkins]

I thought I could just type "unsubscribe" in the body of this email.

RE: Anyone know how I can unsubscribe from this list?

[Mike Braden]

Look at:

http://jakarta.apache.org/site/mail2.html

Try mailto:[EMAIL PROTECTED]

Mike.
--
Mike Braden
[EMAIL PROTECTED]
[EMAIL PROTECTED] 

-Original Message-
From: Andrew Hopkins [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 20, 2001 9:09 PM
To: [EMAIL PROTECTED]
Subject: Anyone know how I can unsubscribe from this list?


I thought I could just type "unsubscribe" in the body of this email.

Re: Strange problem with URL_PKG_PREFIXES

[tttye]

Remy Maucherat writes:

> Quoting [EMAIL PROTECTED]:
> 
> > 
> > Remy Maucherat writes:
> > > I've updated the object factory for the EJB references. It should now
> > > attempt to resolve ejb-links using a JNDI lookup.
> > > I can't really test the feature, so I'm waiting for your feedback and
> > stack
> > > traces, if it goes wrong ;-)
> > > 
> > I finally got all pieces downloaded and compiled the change
> > Now we get an exception on the correct class name...:
> > 
> > 
> > S_STRESS_31K [true] | org.apache.naming.EjbRef |
> > javax.naming.NamingException:
> > cool.models.coop07.java.S_STRESS_31KpsHome
> >   
> > javax.naming.NamingException:
> > cool.models.coop07.java.S_STRESS_31KpsHome
> 
> The exception isn't very clear. It can't load the home interface, right ?
> To debug that problem, the factory won't fail if loading of the home interface 
> fails or if the type checking fails. If something like that happens, a message 
> will be printed out on the console, but the bean instance will still be 
> returned.
> 
> However, if the factory can't load the home interface class, your servlet will 
> probably not be able to either (which is a problem).
> 
> Remy

Please do not test the class of the REMOTE OBJECT returned from the EJB
server.

The servlet has no problem loading or casting the remote object to the home
interface class because the servlet classes include the EJB client classes.

The actual object name of the remote object is $Proxy??? (where ??? is a
number between 0 and 999).  
That proxy object represents the Home Interface and can be cast to the home
interface.   But the remote object cannot be tested correctly with the
'Class' object.  

Please use the following code snip, it includes the only test that actually
succeeds.
if (linkRefAddr != null) {
// Retrieving the EJB link
String ejbLink = linkRefAddr.getContent().toString();
Object beanObj = null;
try {
beanObj = (new InitialContext()).lookup(ejbLink);
String homeClassName = ref.getClassName();
if (!homeClassName.endsWith(beanObj.toString())) 
System.out.println("EJB link \"" + ejbLink
   + "\" of EJB Object: " + beanObj
   + " is not castable to: " + homeClassName);
} catch (Exception e) {
System.out.println("EJB link \""+ejbLink+"\" failed: "+e);
}
return beanObj;
}


Tim

cvs commit: jakarta-tomcat/src/share/org/apache/jasper JasperEngineContext.java

[larryi]

larryi  01/03/20 19:05:26

  Modified:src/share/org/apache/jasper JasperEngineContext.java
  Log:
  Implement resolveRelativeUri() method.
  
  Fix for Bugzilla Bug 1045.
  
  Revision  ChangesPath
  1.2   +6 -1  
jakarta-tomcat/src/share/org/apache/jasper/JasperEngineContext.java
  
  Index: JasperEngineContext.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/JasperEngineContext.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- JasperEngineContext.java  2001/01/28 05:54:34 1.1
  +++ JasperEngineContext.java  2001/03/21 03:05:25 1.2
  @@ -286,7 +286,12 @@
   public String resolveRelativeUri(String uri)
   {
if( debug>0 ) log("resolveRelativeUri " + uri);
  - return null;
  + if (uri.charAt(0) == '/') {
  + return uri;
  +} else {
  +String baseURI = jspFile.substring(0, jspFile.lastIndexOf('/'));
  +return baseURI + '/' + uri;
  +}
   }
   
   public java.io.InputStream getResourceAsStream(String res)
  
  
  

Re: Anyone know how I can unsubscribe from this list?

[Yana]

 send mail to   <[EMAIL PROTECTED]>
  Andrew Hopkins <[EMAIL PROTECTED]> wrote: 
I thought I could just type "unsubscribe" in the body of this email.Do You Yahoo!?
Yahoo! Mail Personal Address - 
Get email at your own domain with Yahoo! Mail.

Re: [VOTE] Proposed Tomcat 4.0-Beta-2 Code Freeze Date

[Jon Stevens]

on 3/19/01 8:32 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:

> +1  [ ]   I support the proposed release, and will work to support it
> +0  [X]   I support the proposed release, but cannot work on it
> at this time
> -0  [ ]   I do not support the proposed release, but do not have an
> alternative to propose
> -1  [ ]   I do not support the proposed release, for reasons specified
> below.


-- 
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous

Re: cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/util FileUtil.java

[Yoshiyuki Karezaki]

Hi arieh,

In article ,
[EMAIL PROTECTED] wrote:
|public static String patch(String path) {
|   -   String patchPath = path;
|   +   String patchPath = path.trim();

The fix of 1.9.2.6 becomes ineffective.
trim() should be removed ?

Yoshiyuki Karezaki   [EMAIL PROTECTED]

Re: ajp13 restart patch - next step

[Dan Milstein]

Henri,

> You're right. I strongly didn't like to see that mixed use of buffer for
> both input and output. We have now system with Mb of RAM and trying to
> save some Kb is a pitty. We must use at least 2 differents buffers :
> 
> One buffer apache => tomcat , another tomcat => apache

That would be fine, but you'd actually need a third to hold the initial
request data (since the apache => tomcat buffer can otherwise get
overwritten by POST data -- even if there is no file upload).  That could
actually be nice -- that way you could hold onto the POST data in the apache
=> tomcat buffer, and you could do a safe restart if there was < 8K of POST
data / file upload.
 
> >Will this be fully restartable?  I'm not absolutely sure -- it
> >all depends
> >on whether or not we can reread the POST data from Apache
> >after a restart
> >(actually, from *all* of the servers supported by mod_jk).
> 
> We must'nt assume that. In my actual patch by line 633 you'll
> see a canrecover var that I set to true when seeing a upload
> mode. In that case I consider the situation to be unrecoverable.
> The solution is in that case to save all upload datas to file
> and in case of error, redo from that file.

Yes, but you're not setting that when there is POST data -- and it sounds
like either a) you need a third buffer as above or b) you need to give up on
requests with POST data.  You would have to pass this back out of
send_request (since that is where the POST data gets sent over).  I incline
towards (a).
 
> I'm not sure that in case of large upload (ie > Mb) Apache store
> data from browser somewhere. Did HTTP allow us to reask to browser
> to restart the upload ?

I just looked through the HTTP spec (RFC 2616), and the File Upload spec
(RFC 1867), and I'm not seeing anything which would help us.  There is a
"503 Service Unavailable" return status code, but I would be astounded if
most browsers handled this correctly (i.e. they pay attention to the
"Retry-After" header).  We could just send 503 with a Retry-After: of 1
second, and maybe it would work.  I dunno.

I feel okay with saying that, if the client is in the middle of a file
upload or a large POST, they just get a server error (we are restarting TC,
after all -- that's going to generate some error conditions).
 
> > 2) is_recoverable_error is passed into send_request, and it's value is
> >assigned to, but it is in no way checked/used.  Was this also
> >true of the
> >old jk_ajp13 code?  (I believe so, but I'm not sure).  If it's
> >genuinely not
> >being used, we should remove it, but I would like to understand what it
> >should be doing, and make sure we're not missing an error
> >state somewhere.
> 
> It is checked at line 737. If false we stop there.

Yes, but, it is reset to JK_TRUE on 732.  Which is *after* send_request is
called.  So, if send_request sets is_recoverable_error to JK_FALSE, it is
prompty reset to JK_TRUE, get_reply is called, and only then is it checked
on line 737.  So whatever send_request is doing with is_recoverable_error is
being totally ignored.  This is what worries me.
 
> > 4) Still using 4-space tabs.  A quick look through some of the other C
> >classes suggests that most of them don't use tabs at all (just
> >spaces).
> >Let's try to emulate that -- I'll try to stop using 8-space tabs.
> 
> Yes, I'm not confortable with 4/8 tab switch between java and C. But not
> the 'core business' ;-)

No worries -- I just fixed my .emacs so that it always uses spaces.  I feel
very virtuous now ;-).
 
> I'll modify jp_ajp13_worker.c and resend diff. After that one week of
> test (you too ?) and a commit after if nothing is broken.

If I have time to test, I will.  I don't think I'll have a lot of time,
unfortunately.

If you fix the buffer issue and can figure out what is_recoverable_error
should be doing in send_request, I'd be happy to see it merged in.  I would
check with Larry, though -- I'm not sure how he would feel about a new
feature going into 3.3 at this point (as the Release Manager).  This is sort
of hairy code we're playing with here.  It would be great to see it in 3.3,
but I would just check with him first.

-Dan

p.s. Can I mention again how great it is that you're working on this?  Not
having to constantly restart Apache will make me a happy, happy man.

-- 

Dan Milstein // [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources DirContextURLStreamHandler.java

[remm]

remm01/03/20 21:05:44

  Modified:catalina/src/share/org/apache/naming/resources
DirContextURLStreamHandler.java
  Log:
  - Fix a problem where the following code would throw a NullPointerException
at line 163 of DirContextURLConnection when excuting the second
(new URL("jndi:/WEB-INF/web.xml")).openStream() :
  
  InputStream is =
 getServletContext().getResource
 ("/WEB-INF/web.xml").openStream();
  is.close();
  is = (new URL("jndi:/WEB-INF/web.xml")).openStream();
  is.close();
  URLClassLoader newcl =
 new URLClassLoader(new URL[0],
 Thread.currentThread().getContextClassLoader());
  Thread.currentThread().setContextClassLoader(newcl);
  is = getServletContext().getResource("/WEB-INF/web.xml")
 .openStream();
  is.close();
  is = (new URL("jndi:/WEB-INF/web.xml")).openStream();
  is.close();
  
  - Now, the stream handler will also check the bindings with the parent of
the context class loader (up to the bootstrap class loader), so that case
should work.
  - If the stream handler fails to retrieve the directory context, it will throw
an IllegalStateException indicating that the class loader configuration is
messed up. That should only happen if a servlet replaces the thread context
class loader with a totally separate loader. In that case, the web
application classloader will be unable to load most classes from /WEB-INF/lib
(because resolving a URL like "jar:jndi:/WEB-INF/lib/foo.jar!/foo/bar.class"
requires some magic), but this shouldn't be a problem since the new
classloader is totally independent, and will be used to load all classes.
  - The ServletContext.getResource(String path) calls should always work,
regardless of how much hacking is done on the classloader (the stream
handler is specified when constructing the URL).
  
  Revision  ChangesPath
  1.3   +13 -5 
jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/DirContextURLStreamHandler.java
  
  Index: DirContextURLStreamHandler.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/DirContextURLStreamHandler.java,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- DirContextURLStreamHandler.java   2001/01/23 22:26:50 1.2
  +++ DirContextURLStreamHandler.java   2001/03/21 05:05:44 1.3
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/DirContextURLStreamHandler.java,v
 1.2 2001/01/23 22:26:50 remm Exp $
  - * $Revision: 1.2 $
  - * $Date: 2001/01/23 22:26:50 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/naming/resources/DirContextURLStreamHandler.java,v
 1.3 2001/03/21 05:05:44 remm Exp $
  + * $Revision: 1.3 $
  + * $Date: 2001/03/21 05:05:44 $
*
* 
*
  @@ -75,7 +75,7 @@
* Stream handler to a JNDI directory context.
* 
* @author mailto:[EMAIL PROTECTED]">Remy Maucherat
  - * @version $Revision: 1.2 $
  + * @version $Revision: 1.3 $
*/
   public class DirContextURLStreamHandler 
   extends URLStreamHandler {
  @@ -161,7 +161,15 @@
   public static DirContext get() {
   ClassLoader currentCL = 
   Thread.currentThread().getContextClassLoader();
  -return (DirContext) clBindings.get(currentCL);
  +DirContext result = null;
  +while ((result == null) && (currentCL != null)) {
  +result = (DirContext) clBindings.get(currentCL);
  +if (result == null)
  +currentCL = currentCL.getParent();
  +}
  +if (result == null)
  +throw new IllegalStateException("Illegal class loader binding");
  +return result;
   }
   
   
  
  
  

cvs commit: jakarta-tomcat/src/shell tomcat.sh

[costin]

costin  01/03/20 22:41:37

  Modified:src/shell tomcat.sh
  Log:
  Few more changes to the .sh script:
  - less verbosity ( no message on the console if the output will be redirected,
  let java do the output for home, classpath )
  
  - fixed the startup with wait
  
  - added a "force" stop ( i.e. kill the process )
  
  - use log for pid and console output ( as sugested )
  
  Revision  ChangesPath
  1.22  +25 -11jakarta-tomcat/src/shell/tomcat.sh
  
  Index: tomcat.sh
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/shell/tomcat.sh,v
  retrieving revision 1.21
  retrieving revision 1.22
  diff -u -r1.21 -r1.22
  --- tomcat.sh 2001/03/15 07:33:19 1.21
  +++ tomcat.sh 2001/03/21 06:41:36 1.22
  @@ -1,6 +1,6 @@
   #!/bin/sh
   #
  -# $Id: tomcat.sh,v 1.21 2001/03/15 07:33:19 costin Exp $
  +# $Id: tomcat.sh,v 1.22 2001/03/21 06:41:36 costin Exp $
   
   # Shell script to start and stop the server
   
  @@ -19,6 +19,7 @@
   fi
   
   #  Guess TOMCAT_HOME 
  +DEBUG_HOMEFIND=false
   # Follow symbolic links to the real tomcat.sh
   # Extract the base dir.
   # Look in well-known places if this fails
  @@ -38,10 +39,14 @@
 done
 
 TOMCAT_HOME_1=`dirname "$PRG"`/..
  -  echo "Guessing TOMCAT_HOME from tomcat.sh to ${TOMCAT_HOME_1}" 
  +  if [ "$DEBUG_HOMEFIND" != "false" ] ; then
  +echo "Guessing TOMCAT_HOME from tomcat.sh to ${TOMCAT_HOME_1}" 
  +  fi
   if [ -d ${TOMCAT_HOME_1}/conf ] ; then 
TOMCAT_HOME=${TOMCAT_HOME_1}
  - echo "Setting TOMCAT_HOME to $TOMCAT_HOME"
  +if [ "$DEBUG_HOMEFIND" != "false" ] ; then
  +  echo "Setting TOMCAT_HOME to $TOMCAT_HOME"
  + fi
   fi
   fi
   
  @@ -50,12 +55,16 @@
 # try to find tomcat
 if [ -d ${HOME}/opt/tomcat/conf ] ; then 
   TOMCAT_HOME=${HOME}/opt/tomcat
  -echo "Defaulting TOMCAT_HOME to $TOMCAT_HOME"
  +if [ "$DEBUG_HOMEFIND" != "false" ] ; then
  +  echo "Defaulting TOMCAT_HOME to $TOMCAT_HOME"
  +fi
 fi
   
 if [ -d /opt/tomcat/conf ] ; then 
   TOMCAT_HOME=/opt/tomcat
  -echo "Defaulting TOMCAT_HOME to $TOMCAT_HOME"
  +if [ "$DEBUG_HOMEFIND" != "false" ] ; then
  +  echo "Defaulting TOMCAT_HOME to $TOMCAT_HOME"
  +fi
 fi

 # Add other "standard" locations for tomcat
  @@ -116,9 +125,6 @@
   #   2) You should use `stop` option instead of ^C to bring down the server
   if [ "$1" = "start" ] ; then 
 shift 
  -  echo Using classpath: ${CLASSPATH}
  -  echo Using JAVA_HOME: ${JAVA_HOME}
  -  echo Using TOMCAT_HOME: ${TOMCAT_HOME}
   
 #Old code for -security: -Djava.security.manager 
-Djava.security.policy==${TOMCAT_HOME}/conf/tomcat.policy 
 # not needed, java starter will do that automatically
  @@ -136,14 +142,17 @@
   
 if [ "$1" = "-noout" ] ; then
   shift
  -$JAVACMD $TOMCAT_OPTS -Dtomcat.home=${TOMCAT_HOME}  $MAIN "$@" 
>${TOMCAT_HOME}/stdout.log 2>&1 &
  +$JAVACMD $TOMCAT_OPTS -Dtomcat.home=${TOMCAT_HOME}  $MAIN "$@" 
>${TOMCAT_HOME}/logs/stdout.log 2>&1 &
 else
  +echo Using classpath: ${CLASSPATH}
  +echo Using JAVA_HOME: ${JAVA_HOME}
  +echo Using TOMCAT_HOME: ${TOMCAT_HOME}
   $JAVACMD $TOMCAT_OPTS -Dtomcat.home=${TOMCAT_HOME}  $MAIN "$@" &
 fi
   
   
 JAVA_PID=$!
  -  echo $JAVA_PID > ${TOMCAT_HOME}/conf/tomcat.pid
  +  echo $JAVA_PID > ${TOMCAT_HOME}/logs/tomcat.pid
   
 # Wait for ajp12.id signaling end of startup
 if [ ! "$WAIT" = "0" ] ; then 
  @@ -151,7 +160,7 @@
   sleep 1
   
   WAIT=`expr $WAIT - 1`
  -if [ "$i" = "0" ] ; then
  +if [ "$WAIT" = "0" ] ; then
   echo "Tomcat was no ready after 120 seconds, giving up waiting "
break;
   fi
  @@ -165,6 +174,11 @@
 echo Using TOMCAT_HOME: ${TOMCAT_HOME}
 CLASSPATH=${CLASSPATH}:${TOMCAT_HOME}/lib/stop-tomcat.jar
 $JAVACMD $TOMCAT_OPTS -Dtomcat.home=${TOMCAT_HOME} 
org.apache.tomcat.startup.StopTomcat "$@"
  +
  +  if [ "$1" = "-force" ] ; then
  +shift
  +kill -9 `cat $TOMCAT_HOME/logs/tomcat.pid`
  +  fi
   
   elif [ "$1" = "run" ] ; then 
 shift 
  
  
  

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

[costin]

costin  01/03/20 22:46:42

  Modified:src/share/org/apache/tomcat/core ServerSession.java
  Log:
  Added the notification call when the session change the state ( as in
  Context and ContextManager ).
  
  Revision  ChangesPath
  1.8   +25 -0 
jakarta-tomcat/src/share/org/apache/tomcat/core/ServerSession.java
  
  Index: ServerSession.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/core/ServerSession.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- ServerSession.java2001/02/27 18:22:58 1.7
  +++ ServerSession.java2001/03/21 06:46:42 1.8
  @@ -149,10 +149,35 @@
return state;
   }
   
  +/** Change the state, call all hooks
  + */
   public void setState( int state ) {
  + if( context != null ) {
  + BaseInterceptor reqI[]=context.getContainer().
  + getInterceptors(Container.H_sessionState);
  + for( int i=0; i< reqI.length; i++ ) {
  + reqI[i].sessionState( null,
  +   this,  state);
  + }
  + }
this.state=state;
   }
   
  +/** Change the state, call all hooks. The request that initiated
  + the event is passed
  + */
  +public void setState( int state, Request req ) {
  + if( context != null ) {
  + BaseInterceptor reqI[]=context.getContainer().
  + getInterceptors(Container.H_sessionState);
  + for( int i=0; i< reqI.length; i++ ) {
  + reqI[i].sessionState( req,
  +   this,  state);
  + }
  + }
  + this.state=state;
  +}
  +
   // - Session Properties
   /** The time stamp associated with this session
*/
  
  
  

cvs commit: jakarta-tomcat/src/share/org/apache/tomcat/modules/session SessionExpirer.java SessionIdGenerator.java SessionId.java SimpleSessionStore.java

[costin]

costin  01/03/20 22:54:02

  Modified:src/share/org/apache/tomcat/modules/session SessionId.java
SimpleSessionStore.java
  Added:   src/share/org/apache/tomcat/modules/session
SessionExpirer.java SessionIdGenerator.java
  Log:
  I'm looking into session expiration bugs and I decided it's easier
  to split the expire code so we can read it and understand what happens.
  
  I also created a separate module for ID generation, as the code is
  independent of the session storage ( which we want to keep it simple
  in case someone wants to backport file store or other advanced
  session stores ).
  
  In the expirer, the main difference is that we use a single expire thread
  per context manager - instead of one thread per context. This allows
  tomcat to scale a bit better when many contexts are deployed
  ( some dynamic loading/unloading is needed, but that can be done later ).
  ( there is no gain in having 100 expire threads working in paralel -
  even if you have a 100 processor machine, you don't want expirer to
  take all the time. You can still have multiple expirers if you explicitely
  define it per context )
  
  I tested the code, and it seems the sessions are expiring fine. I'm
  still working on the admin pages that will show the session statistics
  and allow a bit of control.
  
  Larry - please don't kill me, the changes are not very big ( even if it
  looks like ), I don't think they add too much instability but makes
  the code clearer.
  
  Revision  ChangesPath
  1.9   +1 -7  
jakarta-tomcat/src/share/org/apache/tomcat/modules/session/SessionId.java
  
  Index: SessionId.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/session/SessionId.java,v
  retrieving revision 1.8
  retrieving revision 1.9
  diff -u -r1.8 -r1.9
  --- SessionId.java2001/01/01 00:17:23 1.8
  +++ SessionId.java2001/03/21 06:54:01 1.9
  @@ -237,13 +237,7 @@
   
// if the session was NEW ( never accessed - change it's state )
if( sess.getState() == ServerSession.STATE_NEW ) {
  - reqI= request.getContainer().
  - getInterceptors(Container.H_sessionState);
  - for( int i=0; i< reqI.length; i++ ) {
  - reqI[i].sessionState( request,
  -   sess,  ServerSession.STATE_ACCESSED);
  - }
  - sess.setState( ServerSession.STATE_ACCESSED);
  + sess.setState( ServerSession.STATE_ACCESSED, request);
}
}
return sess;
  
  
  
  1.13  +114 -285  
jakarta-tomcat/src/share/org/apache/tomcat/modules/session/SimpleSessionStore.java
  
  Index: SimpleSessionStore.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/tomcat/modules/session/SimpleSessionStore.java,v
  retrieving revision 1.12
  retrieving revision 1.13
  diff -u -r1.12 -r1.13
  --- SimpleSessionStore.java   2001/03/09 23:47:40 1.12
  +++ SimpleSessionStore.java   2001/03/21 06:54:01 1.13
  @@ -72,18 +72,10 @@
   
   
   /**
  - * This is the adapter between tomcat and a StandardManager.
  - * A session manager should not depend on tomcat internals - so you can
  - * use it in other engines and back. All you need to do is
  - * create an adapter ( tomcat Interceptor).
  + * A simple session store plugin. It will create, store and maintain
  + * session objects using a simple in-memory pool.
*
  - * You can even have multiple session managers per context - the first that
  - * recognize the "requestedSessionId" will create it's own HttpSession object.
  - * By using standard tomcat interceptor mechanisms you can plug in one or
  - * many session managers per context or context manager ( or even per
  - * URL - but that's not standard API feature ).
  - * 
  - * It must be inserted after SessionInterceptor, which does common
  + * It must be inserted after SessionId, which does common
* session stuff ( cookie, rewrite, etc)
*
* @author [EMAIL PROTECTED]
  @@ -93,68 +85,35 @@
*/
   public final class SimpleSessionStore  extends BaseInterceptor {
   int manager_note;
  -
  -int checkInterval = 60;
   int maxActiveSessions = -1;
  -String randomClassName=null;
  -// creating a Random is very expensive, make sure we reuse
  -// instances ( keyed by class name - different contexts can use different
  -// random sources 
  -static Hashtable randoms=new Hashtable();
   
   public SimpleSessionStore() {
   }
   
   //  Configuration properties 
   
  -/**
  - * Set the check interval (in seconds) for this Manager.
  - *
  - * @param checkInterval The new check interval
  - */
  -public void setCheckInterval( 

cvs commit: jakarta-tomcat/src/etc modules.xml server.xml

[costin]

costin  01/03/20 22:55:40

  Modified:src/etc  modules.xml server.xml
  Log:
  Added the new modules ( definitions and in server.xml )
  
  Revision  ChangesPath
  1.2   +13 -3 jakarta-tomcat/src/etc/modules.xml
  
  Index: modules.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/etc/modules.xml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- modules.xml   2001/02/09 04:44:55 1.1
  +++ modules.xml   2001/03/21 06:55:40 1.2
  @@ -280,13 +280,23 @@
   
   
   Not yet
  -
  -Not yet
  -
   
   Not yet
   
  +
  +
  +
  +
  +Not yet
   
  +Not yet
  +
  +
  +
  +
  +
  +Not yet
  +
   Not yet
   
   
  
  
  
  1.71  +5 -2  jakarta-tomcat/src/etc/server.xml
  
  Index: server.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/etc/server.xml,v
  retrieving revision 1.70
  retrieving revision 1.71
  diff -u -r1.70 -r1.71
  --- server.xml2001/02/10 16:53:15 1.70
  +++ server.xml2001/03/21 06:55:40 1.71
  @@ -38,7 +38,11 @@
   
   
   
  +
  +
  +
   
  +
   
   

cvs commit: jakarta-tomcat/src/native/mod_jk/apache1.3 mod_jk.c

[danmil]

danmil  01/03/20 23:12:26

  Modified:src/native/mod_jk/apache1.3 mod_jk.c
  Log:
  Added comments, renamed a few variables for clarity and converted tabs to
  spaces.
  
  Revision  ChangesPath
  1.6   +183 -81   jakarta-tomcat/src/native/mod_jk/apache1.3/mod_jk.c
  
  Index: mod_jk.c
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/native/mod_jk/apache1.3/mod_jk.c,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- mod_jk.c  2001/02/17 05:24:38 1.5
  +++ mod_jk.c  2001/03/21 07:12:26 1.6
  @@ -55,7 +55,9 @@
   
   /***
* Description: Apache 1.3 plugin for Jakarta/Tomcat   *
  + *  See ../common/jk_service.h for general mod_jk info *
* Author:  Gal Shachor <[EMAIL PROTECTED]>   *
  + *  Dan Milstein <[EMAIL PROTECTED]>*
* Version: $ $*
***/
   
  @@ -100,13 +102,18 @@
   #define NULL_FOR_EMPTY(x)   ((x && !strlen(x)) ? NULL : x) 
   
   /*
  - * If you are not using SSL, comment out the following
  - * line. It will make apache run faster.
  + * If you are not using SSL, comment out the following line. It will make
  + * apache run faster.  
  + *
  + * Personally, I (DM), think this may be a lie.
*/
   #define ADD_SSL_INFO
   
   module MODULE_VAR_EXPORT jk_module;
   
  +/*
  + * Configuration object for the mod_jk module.
  + */
   typedef struct {
   char *log_file;
   int  log_level;
  @@ -135,12 +142,28 @@
   server_rec *s;
   } jk_server_conf_t;
   
  +
  +/*
  + * The "private", or subclass portion of the web server service class for
  + * Apache 1.3.  An instance of this class is created for each request
  + * handled.  See jk_service.h for details about the ws_service object in
  + * general.  
  + */
   struct apache_private_data {
  -jk_pool_t p;
  +/* 
  + * For memory management for this request.  Aliased to be identical to
  + * the pool in the superclass (jk_ws_service).  
  + */
  +jk_pool_t p;
   
  -int response_started;
  +/* True iff response headers have been returned to client */
  +int response_started;  
  +
  +/* True iff request body data has been read from Apache */
   int read_body_started;
  -request_rec *r;
  +
  +/* Apache request structure */
  +request_rec *r; 
   };
   typedef struct apache_private_data apache_private_data_t;
   
  @@ -162,11 +185,19 @@
 const void *b,
 unsigned l);
   
  +
  +/* == */
  +/* JK Service step callbacks  */
  +/* == */
   
  -/* = */
  -/* JK Service step callbacks */
  -/* = */
   
  +/*
  + * Send the HTTP response headers back to the browser.
  + *
  + * Think of this function as a method of the apache1.3-specific subclass of
  + * the jk_ws_service class.  Think of the *s param as a "this" or "self"
  + * pointer.  
  + */
   static int JK_METHOD ws_start_response(jk_ws_service_t *s,
  int status,
  const char *reason,
  @@ -176,14 +207,16 @@
   {
   if(s && s->ws_private) {
   unsigned h;
  +
  +/* Obtain a subclass-specific "this" pointer */
   apache_private_data_t *p = s->ws_private;
   request_rec *r = p->r;
   
   if(!reason) {
   reason = "";
   }
  - r->status = status;
  - r->status_line = ap_psprintf(r->pool, "%d %s", status, reason);
  +r->status = status;
  +r->status_line = ap_psprintf(r->pool, "%d %s", status, reason);
   
   for(h = 0 ; h < num_of_headers ; h++) {
   if(!strcasecmp(header_names[h], "Content-type")) {
  @@ -191,20 +224,20 @@
   ap_content_type_tolower(tmp);
   r->content_type = tmp;
   } else if(!strcasecmp(header_names[h], "Location")) {
  - ap_table_set(r->headers_out, header_names[h], header_values[h]);
  - } else if(!strcasecmp(header_names[h], "Content-Length")) {
  - ap_table_set(r->headers_out, header_names[h], header_values[h]);
  - } else if(!strcasecmp(header_names[h], "Transfer-Encoding")) {
  - ap_table_set(r->headers_out, header_name