Re: cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java

[Remy Maucherat]

[EMAIL PROTECTED] wrote:

remm2003/09/06 10:49:31

  Modified:catalina/src/share/org/apache/catalina/loader
WebappClassLoader.java
  Log:
  - Modify the bundling of commons-logging to fix (hopefully) the nagging CL issues.
  - The commons-logging-api JAR will now be put in the system classloader.
When using an alternate logging implmentation (ex: log4j) you should put the
wrapper implementation in the same classloader or there will likely be trouble.
  - Ex: When using a Struts 1.1 webapp with log4j, there should be commons-logging.jar
(just the log4j logger is fine as well) next to it.
  - Of course, overriding the log4j API in a webapp is still not possible. It wasn't
before as c-logging was treated as a special case by the classloader (like JAXP).
  - This nasty case now works for me (bug 22701), as well as using log4j with
privileged webapps (with or without SSL).
This patch isn't portable to 4.1.x, because the issue there isn't the 
same (it would is Jasper from 4.1.x used commons-logging, but thankfully 
it does not, so the headache level is lower).

I'm suspecting what causes bug 22701 in TC 4.1.x is that the context 
classloader isn't properly reset in the StandardHostValve (I did that on 
purpose originally, thinking it was useless; maybe not ;-) ).

Remy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PATCH] Bug 22666

[Remy Maucherat]

Mark Thomas wrote:

This is obviously a bigger mess than I first thought. As I see it, the 
following options exist for resolving bug 22666.

1. WONTFIX - On the basis that there is too much uncertainty to do anything 
sensible and that any changes made might break interoperability as per Remy's 
point 3 below.

2. FIX - Patch the parameter class (as per Remy's point 2 below) on the grounds 
that the JSP spec states "The World Wide Web Consortium (http://www.w3.org/) is 
a definitive source of HTTP related information affecting this specification 
and its implementations." and the w3c view 
(http://www.w3.org/International/O-URL-code.html) is that URI encoding should 
always be based on UTF-8. However, this is still likely to break things (back 
to Remy's point 3).

3. FIX - Add a configuration option that enables w3c compliant URI decoding and 
patch the parameter and any other relevant classes to support this option. I am 
not 100% sure where the best place to do this would be. I am leaning towards 
adding it to the context as an optional parameter with a default state of 
disabled.

There are several bugs in bugzilla that look as if they are on similar lines 
and on that basis my own view is that option 3 is way to go. Before I start 
coding, I would be grateful for some feedback/guidance on my planned approach.
I'll vote almost 2 ;-) No client I know of is always cosistently using 
UTF8 to encode the URL, but however, I'm not sure clients are using the 
encoding of the entity body to encode the URL.
Proper character decoding of the decoded (it means %xx decoded here) URL 
is already done (see CoyoteAdapter.convertURI), and there's a 
connector.getURIEncoding() which is available to indicate what encoding 
is to be used for the URL. Note: The default is US-ASCII (because 
something else doesn't work), but you can be compliant with the W3C and 
use UTF8 :) For more flexibility, we can use a new connector field for 
that (let's call it connector.getQueryStringEncoding()), or use 
connector.getURIEncoding(). This would be passed to the Parameters class 
and used exclusively for the query string decoding (the POSTed stuff 
won't use it, obviously). I want (I have to insist ;-) ) the default be 
US-ASCII (so the feature will work in the real world) with a quick and 
dirty B2C conversion in that particular case (like 
CoyoteAdapter.convertURI).

Overall, this looks the most reasonable and flexible.

Note: If you want to code it, you'd better do it really fast ;-)

Remy



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: jakarta-tomcat-connector release cleanup

[Bill Barker]

- Original Message - 
From: "Glenn Nielsen" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, September 06, 2003 9:37 PM
Subject: jakarta-tomcat-connector release cleanup


> I have promised to setup the tomcat connector releases so that they
> can be mirrored when I perform the next mod_jk release.  First I have
> a few questions.
>
> Are the coyote beta release/milestone releases in
> /www/jakarta.apache.org/builds/jakarta-tomcat-connectors/coyote
> still needed?  Will there be separate releases of coyote or will
> it only be bundled with Tomcat 4/5 releases?

Don't forget Tomcat 3.3!  The Tomcat 4/5 releases get issued pretty often,
and the current Connectors build is broken for 3.3, so +1 to remove the
Connectors download.  I'll look into transfering the "how-to-use"
instructions to the 3.3 nightly download page.

>
> mod_webapp is deprecated so should we continue to have the
> /www/jakarta.apache.org/builds/jakarta-tomcat-connectors/webapp
> release directory or should this be moved to archive.apache.org?

+1 for moving.  The fewer mod_webapp questions I have to field on
tomcat-user, the better ;-).

>
> Can /www/jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/nightly/
> be removed?  The last nightly build of this was October of 2002.
>
> Can the old mod_jk 1.2 and mod_jk2 releases be moved to
> archive.apache.org?

+1 for moving.

>
> Thanks,
>
> Glenn
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

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

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Virtual hosts and multiple Tomcat instances

[Thomas Eichberger]

Hi,

please excuse that I ask my question on this list here, but on tomcat-users 
I didn't get a reply (maybe too difficult).



I have Apache 1.3 and Tomcat 4.1.8 on a Red Hat 9 machine.

Apache serves several virutal hosts. We have one Tomcat instance running 
with several web contexts, one context for each virtual host.

Now I would like to change this to have one Tomcat instance for each 
virtual host (this is necessary because Tomcat sometimes crashes, and I 
don't want all virtual hosts to be down then).

I read a book about Tomcat and searched the Web, but could not find out how 
to do this. What I assume is:

In Apache's httpd.conf I have something (after the import of mod_jk):

NameVirtualHost 200.200.200.200 (or whatever)


ServerName www.xxx.com
DocumentRoot /tomcat1/webapps/xxx
JkMount /servlet/* worker1
JkMount /*.jsp worker1
JkMount /*.do worker1


ServerName www.yyy.com
DocumentRoot /tomcat2/webapps/yyy
JkMount /servlet/* worker2
JkMount /*.jsp worker2
JkMount /*.do worker2

Then I will install Tomcat two times, in /tomcat1 and /tomcat2.

The server.xml of each Tomcat contains different ports (for shutdown and 
for the connector for ajp13).

The workers.properties should look like:

worker.list=worker1,worker2
...
worker.worker1.port=8009
worker.worker1.host=localhost
worker.worker1.type=ajp13
...
worker.worker1.port=8010
worker.worker1.host=localhost
worker.worker1.type=ajp13
Is this all correct? Should that work?

Thomas



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

jakarta-tomcat-connector release cleanup

[Glenn Nielsen]

I have promised to setup the tomcat connector releases so that they
can be mirrored when I perform the next mod_jk release.  First I have
a few questions.
Are the coyote beta release/milestone releases in
/www/jakarta.apache.org/builds/jakarta-tomcat-connectors/coyote
still needed?  Will there be separate releases of coyote or will
it only be bundled with Tomcat 4/5 releases?
mod_webapp is deprecated so should we continue to have the
/www/jakarta.apache.org/builds/jakarta-tomcat-connectors/webapp
release directory or should this be moved to archive.apache.org?
Can /www/jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/nightly/
be removed?  The last nightly build of this was October of 2002.
Can the old mod_jk 1.2 and mod_jk2 releases be moved to
archive.apache.org?
Thanks,

Glenn



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

mod_jk 1.2.5 test release source distribution

[Glenn Nielsen]

I have generated a test release source distribution for mod_jk 1.2.5,
you can find it at:
http://jakarta.apache.org/~glenn/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz

Please build and test on as many OS/web servers as possible.

I have already tested on Solaris7/8 Sparc.

If there are no problems with this source release I will call for a
release vote Friday 9/12 and release Monday 9/15 if the vote passes.
Regards,

Glenn

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-connectors/jk/native CHANGES.txt

[glenn]

glenn   2003/09/06 21:20:47

  Modified:jk/native CHANGES.txt
  Log:
  Fix bill barker attribution
  
  Revision  ChangesPath
  1.19  +2 -2  jakarta-tomcat-connectors/jk/native/CHANGES.txt
  
  Index: CHANGES.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/CHANGES.txt,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- CHANGES.txt   7 Sep 2003 03:49:40 -   1.18
  +++ CHANGES.txt   7 Sep 2003 04:20:47 -   1.19
  @@ -3,7 +3,7 @@
   
   Changes with JK 1.2.5
   * Fix a thread safe bug when mapping URI's.
  -  [bbarker]
  +  [billbarker]
   * Fix a thread safe bug when resolving worker host name
 when using mod_jk with Apache 2 and the worker MPM.
 [hgomez]
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-connectors/jk/native CHANGES.txt

[Bill Barker]

- Original Message - 
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, September 06, 2003 8:49 PM
Subject: cvs commit: jakarta-tomcat-connectors/jk/native CHANGES.txt


> glenn   2003/09/06 20:49:40
>
>   Modified:jk/native CHANGES.txt
>   Log:
>   Update changes
>
>   Revision  ChangesPath
>   1.18  +3 -1  jakarta-tomcat-connectors/jk/native/CHANGES.txt
>
>   Index: CHANGES.txt
>   ===
>   RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/CHANGES.txt,v
>   retrieving revision 1.17
>   retrieving revision 1.18
>   diff -u -r1.17 -r1.18
>   --- CHANGES.txt 24 Jul 2003 13:57:53 - 1.17
>   +++ CHANGES.txt 7 Sep 2003 03:49:40 - 1.18
>   @@ -2,6 +2,8 @@
>Last modified at [$Date$]
>
>Changes with JK 1.2.5
>   +* Fix a thread safe bug when mapping URI's.
>   +  [bbarker]

I appreciate the cite, but 'bbarker' isn't a working identifier for me ;-).
On Apache, I'm billbarker.  Change it, don't change it, I really don't care.

>* Fix a thread safe bug when resolving worker host name
>  when using mod_jk with Apache 2 and the worker MPM.
>  [hgomez]
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

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

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: jakarta-tomcat-catalina/catalina/etc bootstrap.MF

[Bill Barker]

- Original Message - 
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, September 06, 2003 10:19 AM
Subject: cvs commit: jakarta-tomcat-catalina/catalina/etc bootstrap.MF


> remm2003/09/06 10:19:36
>
>   Modified:catalina/etc bootstrap.MF
>   Log:
>   - Modify the bundling of commons-logging to fix (hopefully) the nagging
CL issues.
>   - The commons-logging-api JAR will now be put in the system classloader.
> When using an alternate logging implmentation (ex: log4j) you should
put the
> wrapper implementation in the same classloader or there will likely be
trouble.
>   - Ex: When using a Struts 1.1 webapp with log4j, there should be
commons-logging.jar
> (just the log4j logger is fine as well) next to it.
>   - Of course, overriding the log4j API in a webapp is still not possible.
It wasn't
> before as c-logging was treated as a special case by the classloader
(like JAXP).
>   - This nasty case now works for me (bug 22701), as well as using log4j
with
> privileged webapps (with or without SSL).
>

I'm -0 on this one.  The SSL bugs were due to a non-static c-l logger (since
fixed) and/or an undefined state for the Thread ContextClassLoader.  I don't
see a use case where it is necessary to put c-l in the System Loader.

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

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PATCH] Bug 22666

[Bill Barker]

I'd go for 2) personally.  If you force the POST parameters to UTF-8 (which
I understand is what '3' does), you break almost every web-app out there.
Granted, the request line (including the query-string) should be UTF-8, but
I haven't tested how many browsers actually enforce this.  The POST
parameters will generally be in the encoding of the referrer (which usually
isn't UTF-8).

- Original Message - 
From: "Mark Thomas" <[EMAIL PROTECTED]>
To: "'Tomcat Developers List'" <[EMAIL PROTECTED]>
Sent: Saturday, September 06, 2003 3:06 PM
Subject: RE: [PATCH] Bug 22666


> This is obviously a bigger mess than I first thought. As I see it, the
> following options exist for resolving bug 22666.
>
> 1. WONTFIX - On the basis that there is too much uncertainty to do
anything
> sensible and that any changes made might break interoperability as per
Remy's
> point 3 below.
>
> 2. FIX - Patch the parameter class (as per Remy's point 2 below) on the
grounds
> that the JSP spec states "The World Wide Web Consortium
(http://www.w3.org/) is
> a definitive source of HTTP related information affecting this
specification
> and its implementations." and the w3c view
> (http://www.w3.org/International/O-URL-code.html) is that URI encoding
should
> always be based on UTF-8. However, this is still likely to break things
(back
> to Remy's point 3).
>
> 3. FIX - Add a configuration option that enables w3c compliant URI
decoding and
> patch the parameter and any other relevant classes to support this option.
I am
> not 100% sure where the best place to do this would be. I am leaning
towards
> adding it to the context as an optional parameter with a default state of
> disabled.
>
> There are several bugs in bugzilla that look as if they are on similar
lines
> and on that basis my own view is that option 3 is way to go. Before I
start
> coding, I would be grateful for some feedback/guidance on my planned
approach.
>
> Thanks in anticipation.
>
> Mark
>
>
> On Friday, September 05, 2003 8:13 PM, Remy Maucherat
[SMTP:[EMAIL PROTECTED]
> wrote:
> > Mark Thomas wrote:
> > > I was working from
> > >
> > > http://www.w3.org/International/O-URL-code.html
> > >
> > > Applying the patch fixed the problem as reported in bug 22666. I am
happy
> to
> > >
> > > have another look at this. Can you point me in the direction of a
better
> > > reference?
> >
> > Well, -1 because:
> > 1) Everyone ignores this standard
> > 2) Your encoding will apply to *all* parameters, not just URL
> > parameters; you have to patch the Parameters class for your patch to be
> > correct (I would still vote -1, but at least it wouldn't break the
> > specification)
> > 3) It is extremely likely that people expect all parameters to have the
> > same encoding, regardless of what that w3c spec says; if the servlet
> > spec writes in big bold somewhere that the URL is always UTF8 (which
> > would likely break interoperability with a lot of HTTP clients -
> > possibly all), then it's different
> >
> > Remy
> >
> >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

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

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-connectors/jk/native CHANGES.txt

[glenn]

glenn   2003/09/06 20:49:40

  Modified:jk/native CHANGES.txt
  Log:
  Update changes
  
  Revision  ChangesPath
  1.18  +3 -1  jakarta-tomcat-connectors/jk/native/CHANGES.txt
  
  Index: CHANGES.txt
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/native/CHANGES.txt,v
  retrieving revision 1.17
  retrieving revision 1.18
  diff -u -r1.17 -r1.18
  --- CHANGES.txt   24 Jul 2003 13:57:53 -  1.17
  +++ CHANGES.txt   7 Sep 2003 03:49:40 -   1.18
  @@ -2,6 +2,8 @@
   Last modified at [$Date$]
   
   Changes with JK 1.2.5
  +* Fix a thread safe bug when mapping URI's.
  +  [bbarker]
   * Fix a thread safe bug when resolving worker host name
 when using mod_jk with Apache 2 and the worker MPM.
 [hgomez]
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-connectors/jk/xdocs/common tools.xml

[glenn]

glenn   2003/09/06 20:33:24

  Modified:jk/xdocs menu.idx.in style.xsl.in
  Added:   jk/xdocs/common tools.xml
  Log:
  Add documentation for tools and reports
  
  Revision  ChangesPath
  1.4   +24 -23jakarta-tomcat-connectors/jk/xdocs/menu.idx.in
  
  Index: menu.idx.in
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/menu.idx.in,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- menu.idx.in   14 Mar 2003 00:12:10 -  1.3
  +++ menu.idx.in   7 Sep 2003 03:33:24 -   1.4
  @@ -1,23 +1,24 @@
  -
  -
  -
  -
  -]>
  -
  -
  -  
  -  
  -  
  -  
  -  
  -  
  -  
  -  
  -  
  -  
  -  
  [EMAIL PROTECTED]@
  [EMAIL PROTECTED]@
  -  
  -
  +
  +
  +
  +
  +]>
  +
  +
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  +  
  [EMAIL PROTECTED]@
  [EMAIL PROTECTED]@
  +  
  +
  
  
  
  1.16  +1 -1  jakarta-tomcat-connectors/jk/xdocs/style.xsl.in
  
  Index: style.xsl.in
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/xdocs/style.xsl.in,v
  retrieving revision 1.15
  retrieving revision 1.16
  diff -u -r1.15 -r1.16
  --- style.xsl.in  6 Nov 2002 14:31:52 -   1.15
  +++ style.xsl.in  7 Sep 2003 03:33:24 -   1.16
  @@ -50,7 +50,7 @@
   
 
   
  -
  +
   
 
   
  
  
  
  1.1  jakarta-tomcat-connectors/jk/xdocs/common/tools.xml
  
  Index: tools.xml
  ===
  
  
  
  Tools
  Glenn Nielsen
  $Date: 2003/09/07 03:33:24 $
  
  
  Documentation for additional mod_jk related tools.
  
  
  
  
  The mod_jk source distribution contains two perl scripts in the
  jk/tools/reports directory which can be used to analyze the mod_jk
  logs, save statistical data, and generate report graphs.
  
  
  tomcat_trend.pl log_dir archive_dir
  
  Script for analyzing mod_jk.log data when logging tomcat request data using
  the JkRequestLogFormat Apache mod_jk configuration.
  Generates statistics for request latency and errors.  Archives the generated
  data to files for later use in long term trend graphs and reports.
  
  
  tomcat_reports.pl archive_dir reports_dir
  
  Script for generating reports and graphs using statistical data generated
  by the tomcat_trend.pl script.
  
  The following graphs are created:
  
tomcat_request.png - Long term trend graph of total number of tomcat
  requests handled.
tomcat_median.png - Long term overall trend graph of tomcat request
  latency median.
tomcat_deviation.png - Long term overall trend graph of tomcat request
  mean and standard deviation.
tomcat_error.png - Long term trend graph of requests rejected by tomcat.
  Shows requests rejected when tomcat has no request processors available.
  Can be an indicator that tomcat is overloaded or having other scaling
  problems.
tomcat_client.png - Long term trend graph of requests forward to tomcat
  which were aborted by the remote client (browser).  You will normally see
  some aborted requests.  High numbers of these can be an indicator that
  tomcat is overloaded or there are requests which have very high latency.
  
  
  
  
  A great deal of statistical data is generated but at this time
  only long term trend graphs are being created and no reports.
  This is only a start.  Many more graphs and reports could be
  generated from the data. Please consider contributing back any
  new reports or graphs you create.  Thanks.
  
  
  
  These perl scripts depend upon the following perl modules and libraries:
  
GD 1.8.x graphics library http://www.boutell.com/gd/";>
  http://www.boutell.com/gd/
GD 1.4.x perl module
GD Graph perl module
GD TextUtil perl module
StatisticsDescriptive perl module
  
  
  
  
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-connectors/jk HOWTO-RELEASE

[glenn]

glenn   2003/09/06 20:32:19

  Modified:jk   HOWTO-RELEASE
  Log:
  Update how to release to support mirrors and new apache servers
  
  Revision  ChangesPath
  1.6   +26 -9 jakarta-tomcat-connectors/jk/HOWTO-RELEASE
  
  Index: HOWTO-RELEASE
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/HOWTO-RELEASE,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- HOWTO-RELEASE 15 Jul 2003 12:27:35 -  1.5
  +++ HOWTO-RELEASE 7 Sep 2003 03:32:19 -   1.6
  @@ -155,13 +155,15 @@
   
   gpg -abs -o jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz.asc 
jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz
   
  -Upload source distribution and documentation to daedalus.apache.org
  +Upload source distribution and documentation to www.apache.org
   ---
  -ssh to daedalus.apache.org and create the release directory.
  +ssh to www.apache.org and create the release directory.
   
  -mkdir /www/jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/jk/v1.2.5
  +mkdir /www/www.apache.org/dist/jakarta/tomcat-connectors/jk/v1.2.5
   
  -scp jakarta-tomcat-connectors/KEYS to the release directory on daedalus.
  +scp jakarta-tomcat-connectors/KEYS to the
  +/www/www.apache.org/dist/jakarta/tomcat-connectors
  +directory on thewww.apache.org server.
   
   Copy a previous release directory README.html file to the new release
   directory and edit as necessary.
  @@ -179,18 +181,20 @@
   scp ~/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz* to the release src
   directory.
   
  -scp -r jakarta-tomcat-connectors/jk/build/docs/* 
daedalus.apache.org:/www/jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/v1.2.5/doc
  +scp -r jakarta-tomcat-connectors/jk/build/docs/* 
www.apache.org:/www/www.apache.org/dist/jakarta/tomcat-connectors/jk/v1.2.5/doc
   
   Make sure the group write bit is set on all files and directories
   in the new release directory.
   
  -chmod -R g+w 
/www/jakarta.apache.org/builds/jakarta-tomcat-connectors/jk/release/jk/v1.2.5
  +chmod -R g+w /www/www.apache.org/dist/jakarta/tomcat-connectors/jk/v1.2.5
   
  -Build binaries and upload distributions to daedalus.apache.org
  +Build binaries and upload distributions to www.apache.org
   --
   
   Build mod_jk for a specific web server and OS.  Package it as appropriate for
  -the OS and sign the archive using PGP. Please include the ASF License in the 
archive.
  +
  +the OS and sign the archive using PGP. Please include the ASF License, the
  +generated docs, and the tools.
   
   scp the binary distribution and pgp signature file to the appropriate bin/{os} 
directory.
   Create or modify that bin/{os} directory README.html file for the binary release.
  @@ -204,9 +208,22 @@
   Reset JK_VERISRELEASE to 0 and update JK_VERSTRING, JK_VERMAJOR,
   JK_VERMINOR, and JK_VERFIX as needed.  Commit your changes to CVS.
   
  +Move old release distributions to archive.apache.org
  +
  +
  +Move any old mod_jk distribution directories to the
  +/www/archive.apache.org/dist/jakarta/tomcat-connectors/jk/
  +directory on the archive.apache.org server.
  +
   Announcements
   -
   
  +The release distribution directories are mirrored so that the
  +releases can be downloaded from multiple sites.  Please wait
  +24 hours before sending out the announcement so that the mirrors
  +get a chance to get the new release distributions.
  +
   Send an email announcement to [EMAIL PROTECTED],
  [EMAIL PROTECTED], and [EMAIL PROTECTED]
  [EMAIL PROTECTED], [EMAIL PROTECTED],
  +and [EMAIL PROTECTED]
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22961] - WebAppClassLoader tries to load class from system classloader twice

[bugzilla]

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

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

WebAppClassLoader tries to load class from system classloader twice





--- Additional Comments From [EMAIL PROTECTED]  2003-09-07 03:18 ---
WebAppClassLoader will always have a parent (with classpath 
$CATALINA_HOME/shared/classes:$CATALINA_HOME/shared/lib/*.jar).

Lay off the drugs ;-).

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22961] - WebAppClassLoader tries to load class from system classloader twice

[bugzilla]

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

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

WebAppClassLoader tries to load class from system classloader twice





--- Additional Comments From [EMAIL PROTECTED]  2003-09-06 21:52 ---
Oh, yes, this happens only if we have no parent classloader - do we commonly have one? 
If yes, I must 
have been on drugs to try to optimize code that is not being run.. Sorry then!

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22961] - WebAppClassLoader tries to load class from system classloader twice

[bugzilla]

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

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

WebAppClassLoader tries to load class from system classloader twice





--- Additional Comments From [EMAIL PROTECTED]  2003-09-06 21:48 ---
Created an attachment (id=8083)
A possible fix (just a sketch)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22956] - Manager webapp can't treat encvoding correctly

[bugzilla]

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

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

Manager webapp can't treat encvoding correctly





--- Additional Comments From [EMAIL PROTECTED]  2003-09-06 22:57 ---
Previous my modification needs set utf-8 to input socket stream in ant task. I
attached patch.

Index: AbstractCatalinaTask.java
===
RCS file:
/home/cvspublic/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/ant/AbstractCatalinaTask.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 AbstractCatalinaTask.java
--- AbstractCatalinaTask.java   18 Jul 2002 16:48:13 -  1.1.1.1
+++ AbstractCatalinaTask.java   6 Sep 2003 22:51:29 -
@@ -89,7 +89,10 @@
 
 
 // - Instance Variables
-
+   /**
+* manager webapp's encoding.
+*/ 
+private static String CHARSET = "utf-8";
 
 // - Properties
 
@@ -245,7 +248,7 @@
 }
 
 // Process the response message
-reader = new InputStreamReader(hconn.getInputStream());
+reader = new InputStreamReader(hconn.getInputStream(), CHARSET);
 StringBuffer buff = new StringBuffer();
 String error = null;
 boolean first = true;

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: [PATCH] Bug 22666

[Mark Thomas]

This is obviously a bigger mess than I first thought. As I see it, the 
following options exist for resolving bug 22666.

1. WONTFIX - On the basis that there is too much uncertainty to do anything 
sensible and that any changes made might break interoperability as per Remy's 
point 3 below.

2. FIX - Patch the parameter class (as per Remy's point 2 below) on the grounds 
that the JSP spec states "The World Wide Web Consortium (http://www.w3.org/) is 
a definitive source of HTTP related information affecting this specification 
and its implementations." and the w3c view 
(http://www.w3.org/International/O-URL-code.html) is that URI encoding should 
always be based on UTF-8. However, this is still likely to break things (back 
to Remy's point 3).

3. FIX - Add a configuration option that enables w3c compliant URI decoding and 
patch the parameter and any other relevant classes to support this option. I am 
not 100% sure where the best place to do this would be. I am leaning towards 
adding it to the context as an optional parameter with a default state of 
disabled.

There are several bugs in bugzilla that look as if they are on similar lines 
and on that basis my own view is that option 3 is way to go. Before I start 
coding, I would be grateful for some feedback/guidance on my planned approach.

Thanks in anticipation.

Mark


On Friday, September 05, 2003 8:13 PM, Remy Maucherat [SMTP:[EMAIL PROTECTED] 
wrote:
> Mark Thomas wrote:
> > I was working from
> >
> > http://www.w3.org/International/O-URL-code.html
> >
> > Applying the patch fixed the problem as reported in bug 22666. I am happy 
to
> >
> > have another look at this. Can you point me in the direction of a better
> > reference?
>
> Well, -1 because:
> 1) Everyone ignores this standard
> 2) Your encoding will apply to *all* parameters, not just URL
> parameters; you have to patch the Parameters class for your patch to be
> correct (I would still vote -1, but at least it wouldn't break the
> specification)
> 3) It is extremely likely that people expect all parameters to have the
> same encoding, regardless of what that w3c spec says; if the servlet
> spec writes in big bold somewhere that the URL is always UTF8 (which
> would likely break interoperability with a lot of HTTP clients -
> possibly all), then it's different
>
> Remy
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22961] New: - WebAppClassLoader tries to load class from system classloader twice

[bugzilla]

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

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

WebAppClassLoader tries to load class from system classloader twice

   Summary: WebAppClassLoader tries to load class from system
classloader twice
   Product: Tomcat 5
   Version: 5.0.0
  Platform: Other
OS/Version: Other
Status: NEW
  Severity: Enhancement
  Priority: Other
 Component: Catalina
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


Just have been reading WebAppClassLoader.java for self-education,
and it seems that every 
class not found in the system ClassLoader
is being attempted to be loaded from it twice (some 
code has been
removed):

// (0.2)
clazz = system.loadClass(name);
if (clazz != null) 
{
return (clazz);
}
// (1)

ClassLoader loader = parent;
if (loader == null)
loader 
= system;
try {
clazz = loader.loadClass(name);

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [PROPOSAL] archive old unmirrored tomcat releases

[robert burrell donkin]

On Thursday, September 4, 2003, at 07:34 AM, Stefan Bodewig wrote:

On Wed, 3 Sep 2003, robert burrell donkin <[EMAIL PROTECTED]> wrote:


1. all available distributables for the latest tomcat 3, tomcat 4
and tomcat 5 releases be added to the appropriate mirrored
directories and linked to jakarta download pages.
Only the latest stable releases, I'd say.
i've add the latest tomcat 3 release (3.3.1a).

Please also note the conversation between myself and Glenn in another
thread about the connector releases.
i've left the connectors alone.

2. the older releases for tomcat 3, tomcat 4 and tomcat 5 be moved
into the ASF archives
this shouldn't include betas/alphas/milestones either IMHO.

3. move betas/alphas/milestones to .

I'm not sure whether there is any point in keeping unstable releases
that have been superseded by newer releases around at all.  Just MHO.
i couldn't see very many betas or milestones. i've moved all the releases 
into archive and i've added .htaccess file which redirect to the main 
jakarta download page.

- robert

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-catalina/modules/cluster build.xml

[remm]

remm2003/09/06 10:50:59

  Modified:modules/cluster build.xml
  Log:
  - Modify the bundling of commons-logging to fix (hopefully) the nagging CL issues.
  - The commons-logging-api JAR will now be put in the system classloader.
When using an alternate logging implmentation (ex: log4j) you should put the
wrapper implementation in the same classloader or there will likely be trouble.
  - Ex: When using a Struts 1.1 webapp with log4j, there should be commons-logging.jar
(just the log4j logger is fine as well) next to it.
  - Of course, overriding the log4j API in a webapp is still not possible. It wasn't
before as c-logging was treated as a special case by the classloader (like JAXP).
  - This nasty case now works for me (bug 22701), as well as using log4j with
privileged webapps (with or without SSL).
  
  Revision  ChangesPath
  1.6   +1 -1  jakarta-tomcat-catalina/modules/cluster/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/modules/cluster/build.xml,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- build.xml 27 May 2003 17:00:23 -  1.5
  +++ build.xml 6 Sep 2003 17:50:59 -   1.6
  @@ -17,7 +17,7 @@
   
 
   
  -
  +
   
   
 
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-5 build.xml

[remm]

remm2003/09/06 10:49:22

  Modified:.build.xml
  Log:
  - Modify the bundling of commons-logging to fix (hopefully) the nagging CL issues.
  - The commons-logging-api JAR will now be put in the system classloader.
When using an alternate logging implmentation (ex: log4j) you should put the
wrapper implementation in the same classloader or there will likely be trouble.
  - Ex: When using a Struts 1.1 webapp with log4j, there should be commons-logging.jar
(just the log4j logger is fine as well) next to it.
  - Of course, overriding the log4j API in a webapp is still not possible. It wasn't
before as c-logging was treated as a special case by the classloader (like JAXP).
  - This nasty case now works for me (bug 22701), as well as using log4j with
privileged webapps (with or without SSL).
  
  Revision  ChangesPath
  1.157 +4 -4  jakarta-tomcat-5/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/build.xml,v
  retrieving revision 1.156
  retrieving revision 1.157
  diff -u -r1.156 -r1.157
  --- build.xml 5 Sep 2003 06:46:01 -   1.156
  +++ build.xml 6 Sep 2003 17:49:22 -   1.157
  @@ -132,7 +132,7 @@
   
   
  -
   
   
   
  -
   
   
  -
   
  +
   
   
 
  @@ -280,6 +279,7 @@
   
   
 
  +  
 
 
   
  @@ -724,7 +724,6 @@
 
   
   
  -
 
   
   
  @@ -735,6 +734,7 @@
   
   
  +
   
   
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-5 RELEASE-NOTES

[remm]

remm2003/09/06 10:50:07

  Modified:.RELEASE-NOTES
  Log:
  - Remove release notes entry.
  
  Revision  ChangesPath
  1.7   +1 -13 jakarta-tomcat-5/RELEASE-NOTES
  
  Index: RELEASE-NOTES
  ===
  RCS file: /home/cvs/jakarta-tomcat-5/RELEASE-NOTES,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- RELEASE-NOTES 30 Aug 2003 21:03:50 -  1.6
  +++ RELEASE-NOTES 6 Sep 2003 17:50:07 -   1.7
  @@ -21,7 +21,6 @@
   * Security manager URLs
   * Symlinking static resources
   * Enabling invoker servlet
  -* Privileged web applications and log4j
   * When all else fails
   
   
  @@ -201,17 +200,6 @@
   
   Using the invoker servlet in a production environment is not recommended and
   is unsupported.
  -
  -
  --
  -Privileged web applications and log4j:
  --
  -
  -Apache log4j, or other logging systems, cannot be used inside privileged web
  -applications, due to classloading problems caused by commons-logging.
  -
  -Note that privileged contexts are only useful to write web application which
  -extend the container functionality.
   
   
   ---
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

[remm]

remm2003/09/06 10:49:43

  Modified:catalina build.xml
  Log:
  - Modify the bundling of commons-logging to fix (hopefully) the nagging CL issues.
  - The commons-logging-api JAR will now be put in the system classloader.
When using an alternate logging implmentation (ex: log4j) you should put the
wrapper implementation in the same classloader or there will likely be trouble.
  - Ex: When using a Struts 1.1 webapp with log4j, there should be commons-logging.jar
(just the log4j logger is fine as well) next to it.
  - Of course, overriding the log4j API in a webapp is still not possible. It wasn't
before as c-logging was treated as a special case by the classloader (like JAXP).
  - This nasty case now works for me (bug 22701), as well as using log4j with
privileged webapps (with or without SSL).
  
  Revision  ChangesPath
  1.56  +2 -4  jakarta-tomcat-catalina/catalina/build.xml
  
  Index: build.xml
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/build.xml,v
  retrieving revision 1.55
  retrieving revision 1.56
  diff -u -r1.55 -r1.56
  --- build.xml 30 Aug 2003 13:19:40 -  1.55
  +++ build.xml 6 Sep 2003 17:49:43 -   1.56
  @@ -539,6 +539,8 @@
   
   
   
  +
   
  @@ -561,10 +563,6 @@
  file="${commons-beanutils.jar}"/>
   
  -
  -
   
   
 
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java

[remm]

remm2003/09/06 10:49:31

  Modified:catalina/src/share/org/apache/catalina/loader
WebappClassLoader.java
  Log:
  - Modify the bundling of commons-logging to fix (hopefully) the nagging CL issues.
  - The commons-logging-api JAR will now be put in the system classloader.
When using an alternate logging implmentation (ex: log4j) you should put the
wrapper implementation in the same classloader or there will likely be trouble.
  - Ex: When using a Struts 1.1 webapp with log4j, there should be commons-logging.jar
(just the log4j logger is fine as well) next to it.
  - Of course, overriding the log4j API in a webapp is still not possible. It wasn't
before as c-logging was treated as a special case by the classloader (like JAXP).
  - This nasty case now works for me (bug 22701), as well as using log4j with
privileged webapps (with or without SSL).
  
  Revision  ChangesPath
  1.25  +1 -2  
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
  
  Index: WebappClassLoader.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
  retrieving revision 1.24
  retrieving revision 1.25
  diff -u -r1.24 -r1.25
  --- WebappClassLoader.java2 Sep 2003 21:22:03 -   1.24
  +++ WebappClassLoader.java6 Sep 2003 17:49:31 -   1.25
  @@ -192,7 +192,6 @@
   "javax", // Java extensions
   "org.xml.sax",   // SAX 1 & 2
   "org.w3c.dom",   // DOM 1 & 2
  -"org.apache.commons.logging",// Commons logging.
   "org.apache.xerces", // Xerces 1 & 2
   "org.apache.xalan"   // Xalan
   };
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: jakarta-tomcat-connectors/jk/tools/reports tomcat_trend.pl

[glenn]

glenn   2003/09/06 10:44:14

  Modified:jk/tools/reports tomcat_trend.pl
  Log:
  Cleanup debug and minor bug fix
  
  Revision  ChangesPath
  1.6   +11 -24jakarta-tomcat-connectors/jk/tools/reports/tomcat_trend.pl
  
  Index: tomcat_trend.pl
  ===
  RCS file: /home/cvs/jakarta-tomcat-connectors/jk/tools/reports/tomcat_trend.pl,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- tomcat_trend.pl   3 Jul 2003 14:41:12 -   1.5
  +++ tomcat_trend.pl   6 Sep 2003 17:44:14 -   1.6
  @@ -110,7 +110,6 @@
   
   if( -e "$archivedir/global.data" ) {
  # Get the start date from the last entry in global.data
  -   # print "Checking global.data for startdate\n";
  @tail = `tail -1 $archivedir/global.data`;
  $startdate = (split /\s+/,$tail[0])[0];
  ($day, $mon, $year) = (localtime($startdate))[3..5];
  @@ -132,10 +131,7 @@
  ($mon, $day, $time, $year) = (split /\s+/,$head[0])[1..4];
  ($hour, $min, $sec) = split /:/,$time;
  $year =~ s/\]$//;
  -   # print "$head[0]\n";
  -   # print "$mon $day $time $year $hour $min $sec\n";
  $logtime = timelocal($sec,$min,$hour,$day,$MON{$mon},$year-1900);
  -   # print "$logfile $logtime " . scalar(localtime($logtime)) . "\n";
  $modjklog{$logtime} = $logfile;
   }
   
  @@ -166,14 +162,16 @@
   }
   
   print "StartDate: " . scalar(localtime($startdate)) . "\n";
  +$processdate = $startdate;
   
   foreach $key ( sort {$a <=> $b} keys %modjklog ) {
  -   last if( $key >= $curdate );
  +   $logtime = $processdate;
  $logfile = $modjklog{$key};
  +   print "Processing log: $logfile\n";
  +   last if( $key >= $curdate );
  $fh = new FileHandle "<$logfile";  
  die "Open of logfile $logfile failed: $!"
 unless defined $fh;
  -   print "Processing log: $logfile\n";
  while( $line = $fh->getline) {
 chomp($line);
 ($mon, $day, $time, $year) = (split /\s+/,$line)[1..4];
  @@ -183,15 +181,12 @@
print "Unknown log entry: $origline\n" unless $origline =~ /\.c /;
next;
 }
  -  # print "$mon $day $time $year $hour $min $sec\n";
 $logtime = timelocal($sec,$min,$hour,$day,$MON{$mon},$year-1900);
   
  -  if( $logtime > $startdate ) {
  +  if( $logtime > $processdate ) {
$origline = $line;
# Strip off the leading date and time
  - # print "$line\n";
$line =~ s/^\[.*\] //;
  - # print "$line\n";
   
# See if this is a new 5 minute period
$interval = int($logtime/300);
  @@ -212,7 +207,7 @@
# See if this is a new day
if( $day != $prevday ) {
   if( defined $prevday ) {
  -   &DailyStats($startdate,\%Global);
  +   &DailyStats($processdate,\%Global);
   }
   undef %Global;
   undef %GlobalWorkers;
  @@ -224,7 +219,7 @@
   $Global{workers} = \%GlobalWorkers;
   $Global{errors} = "";
   $prevday = $day;
  -$startdate = $logtime;
  +$processdate = $logtime;
}
   
# Stop processing if logtime is today
  @@ -232,7 +227,6 @@
   
if( $line =~ /\d\)\]: / ) {
   # Handle a mod_jk error
  -# print "mod_jk error! " . scalar(localtime($logtime)) . " $line\n";
   if( $line =~ /(jk_tcp_socket_recvfull failed|ERROR: Receiving from 
tomcat failed)/ ) {
  $Global{tomcat_full}++;
  $Interval{tomcat_full}++;
  @@ -243,19 +237,13 @@
   next;
} else {
   # Handle a mod_jk request log entry
  -# print "$line\n";
   $line =~ s/^\[.*\] //;
  -# print "$line\n";
   $line =~ s/\"(GET|POST|OPTIONS|HEAD)[^\"]*\" //;
  -# print "$line\n";
   $line =~ s/[\?\;].*\"//;
  -# print "$line\n";
   $line =~ s/\"//g;
  -# print "$line\n";
   ($work, $host, $page, $status, $latency) = split /\s+/,$line;
   $page =~ s/\/\//\//g;
   $page =~ s/\.\//\//g;
  -# print scalar(localtime($logtime)) . " $work $host $page $status 
$latency\n";
   if( length($work) <= 0 || length($host) <= 0 ||
   length($page) <= 0 || $status !~ /^\d+$/ || $latency !~ 
/^\d+\.\d+$/ ) {
  print "Unknown log entry: $origline\n" unless $origline =~ /\.c /;
  @@ -324,7 +312,6 @@
   }
   $hoster = $$worker{hosts}{$host};
   push @{$$hoster{latency}},$latency;
  -
}
 }
  }
  @@ -335,7 +322,7 @@
   # output the last days data
   if( $logtime < $curdate ) {
  &IntervalStats(\%Global,\%Interval,$previnterval*300);
  -   &DailyStats($startdate,\%Global);
  +   &DailyStats($processdate,\%Global);

cvs commit: jakarta-tomcat-catalina/catalina/etc bootstrap.MF

[remm]

remm2003/09/06 10:19:36

  Modified:catalina/etc bootstrap.MF
  Log:
  - Modify the bundling of commons-logging to fix (hopefully) the nagging CL issues.
  - The commons-logging-api JAR will now be put in the system classloader.
When using an alternate logging implmentation (ex: log4j) you should put the
wrapper implementation in the same classloader or there will likely be trouble.
  - Ex: When using a Struts 1.1 webapp with log4j, there should be commons-logging.jar
(just the log4j logger is fine as well) next to it.
  - Of course, overriding the log4j API in a webapp is still not possible. It wasn't
before as c-logging was treated as a special case by the classloader (like JAXP).
  - This nasty case now works for me (bug 22701), as well as using log4j with
privileged webapps (with or without SSL).
  
  Revision  ChangesPath
  1.4   +1 -1  jakarta-tomcat-catalina/catalina/etc/bootstrap.MF
  
  Index: bootstrap.MF
  ===
  RCS file: /home/cvs/jakarta-tomcat-catalina/catalina/etc/bootstrap.MF,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- bootstrap.MF  16 Aug 2003 02:36:20 -  1.3
  +++ bootstrap.MF  6 Sep 2003 17:19:36 -   1.4
  @@ -1,5 +1,5 @@
   Manifest-Version: 1.0
   Main-Class: org.apache.catalina.startup.Bootstrap
  -Class-Path: commons-daemon.jar
  +Class-Path: commons-daemon.jar commons-logging-api.jar
   Specification-Title: Catalina
   Specification-Version: 1.0
  
  
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22952] - reconnection to database not possible

[bugzilla]

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

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

reconnection to database not possible

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
Summary|reconnection to database not|reconnection to database not
   |possible|possible



--- Additional Comments From [EMAIL PROTECTED]  2003-09-06 11:33 ---
If there is a possibility that your database connections becomes broken (by a
database restart, network problem, ...) then you need to configure connection
validation.

testOnBorrow = true
validationQuery = "select * from dual"
(make sure you use a correct query for your database)

=> more questions: commons-user mailinglist (use [DBCP] subject prefix)

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 20991] - Connection Pool : Datasource cannot retrieve connection.

[bugzilla]

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

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

Connection Pool : Datasource cannot retrieve connection.

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX



--- Additional Comments From [EMAIL PROTECTED]  2003-09-06 10:14 ---
Chirag, you input is very much appreciated. Could you please resubmit this bug under 
Jakarta 
Commons / DBCP as there is nobody among Tomcat developers to fix it?

On the other hand you may 
well just NOT set any validation query at all, I guess it will work that way, won't it?

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22737] - LogConfigurationException when using Tomcat 4.1.27 SSL, common/log

[bugzilla]

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

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

LogConfigurationException when using Tomcat 4.1.27 SSL, common/log

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2003-09-06 08:13 ---
Please don't file duplicates, esp if you say it is a duplicate in the description.

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[GUMP] Build Failure - jakarta-tomcat-4.0

[Craig McClanahan]

This email is autogenerated from the output from:



Buildfile: build.xml

deploy-prepare:

deploy-static:

deploy:
 [echo] Target: Catalina - Deploy ...

flags:

flags.display:
 [echo] --- Build environment for Catalina ---
 [echo] If ${property_name} is displayed, then the property is not set)
 [echo] --- Build options ---
 [echo] full.dist=${full.dist}
 [echo] build.sysclasspath=only
 [echo] compile.debug=${compile.debug}
 [echo] compile.deprecation=${compile.deprecation}
 [echo] compile.optimize=${compile.optimize}
 [echo] --- Ant Flags ---
 [echo] 

DO NOT REPLY [Bug 22701] - commons-logging and SSL in tomcat with struts

[bugzilla]

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

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

commons-logging and SSL in tomcat with struts

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-09-06 08:16 ---
*** Bug 16189 has been marked as a duplicate of this bug. ***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 16189] - Tomcat Hangs in SSL Mode (Both 4.1.18 and 4.1.18LE for JDK 1.4)

[bugzilla]

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

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

Tomcat Hangs in SSL Mode (Both 4.1.18 and 4.1.18LE for JDK 1.4)

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||DUPLICATE



--- Additional Comments From [EMAIL PROTECTED]  2003-09-06 08:16 ---
The issue is not the same as originally on the report: I believe any problem, if
any, would only happen with log4j. Please do not reopen this.

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22701] - commons-logging and SSL in tomcat with struts

[bugzilla]

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

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

commons-logging and SSL in tomcat with struts

[EMAIL PROTECTED] changed:

   What|Removed |Added

 CC||[EMAIL PROTECTED]



--- Additional Comments From [EMAIL PROTECTED]  2003-09-06 08:13 ---
*** Bug 22737 has been marked as a duplicate of this bug. ***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Received - Did you check the QNYF Group FAQ?

[quentin]

This is an automated response. Thanks for your email. If you are trying to post an 
email to the QNYF Group, this is the wrong email address. Please re-send your email 
posting to: [EMAIL PROTECTED] . If you are asking a question regarding the QNYF Group, 
please first check the Group FAQ: www.quentinsfriends.com/QNYF-FAQ.html ? Otherwise, 
you should receive a response to your email within 7 days. Best regards, Quentin. 
[EMAIL PROTECTED] www.quentinsfriends.com Sponsor site: www.excelir.com/quentinsfriends



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 22956] New: - Manager webapp can't treat encvoding correctly

[bugzilla]

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

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

Manager webapp can't treat encvoding correctly

   Summary: Manager webapp can't treat encvoding correctly
   Product: Tomcat 5
   Version: Nightly Build
  Platform: All
OS/Version: Other
Status: NEW
  Severity: Normal
  Priority: Other
 Component: Webapps:Manager
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


We Japanese can't read status message because encoding isn't specified in
StatusTransformer.java. I guess other people who use other than English have
same  problem. So,I wrote a pache to resolve this problem.
This patch also include to use utf-8 encoding. Current implementation use locale
depend encoding but utf-8 is unicode standard and it is able to treat all
laungage. This makes code simple. Could you apply my patch?

I put my patch here:
http://yamaguch.sytes.net/~tora/tmp/manager-i18n.patch

kind regards,

Takashi Okamoto

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]