DO NOT REPLY [Bug 22956] New: - Manager webapp can't treat encvoding correctly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22956. 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]
Received - Did you check the QNYF Group FAQ?
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 22701] - commons-logging and SSL in tomcat with struts
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22701. 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]
DO NOT REPLY [Bug 16189] - Tomcat Hangs in SSL Mode (Both 4.1.18 and 4.1.18LE for JDK 1.4)
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16189. 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
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22701. 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 22737] - LogConfigurationException when using Tomcat 4.1.27 SSL, common/log
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22737. 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]
DO NOT REPLY [Bug 20991] - Connection Pool : Datasource cannot retrieve connection.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20991. 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 22952] - reconnection to database not possible
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22952. 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]
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). 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]
cvs commit: jakarta-tomcat-connectors/jk/tools/reports tomcat_trend.pl
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);
}
exit;
cvs commit: jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader WebappClassLoader.java
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-catalina/catalina build.xml
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 @@
chmod perm=+x dir=${catalina.build}/bin includes=*.sh/
!-- Common Extensions --
+copy todir=${catalina.build}/bin
+ file=${commons-logging-api.jar}/
!--
copy todir=${catalina.build}/common/lib file=${servlet-api.jar}/
--
@@ -561,10 +563,6 @@
file=${commons-beanutils.jar}/
copy todir=${catalina.build}/server/lib
file=${commons-digester.jar}/
-copy todir=${catalina.build}/server/lib
- file=${commons-logging.jar}/
-copy todir=${catalina.build}/common/lib
- file=${commons-logging-api.jar}/
copy todir=${catalina.build}/server/lib file=${regexp.jar}/
/target
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-5 RELEASE-NOTES
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-5 build.xml
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 @@
copy file=${commons-el.jar}
todir=${tomcat.build}/common/lib/
-copy todir=${tomcat.build}/common/lib
+copy todir=${tomcat.build}/bin
file=${commons-logging-api.jar} /
copy tofile=${tomcat.build}/common/lib/jmx.jar file=${jmx.jar} /
copy tofile=${tomcat.build}/common/lib/jmx-tools.jar
@@ -142,11 +142,10 @@
copy tofile=${tomcat.build}/common/lib/jmx-remote-tools.jar
file=${jmx-remote-tools.jar} failonerror=false /
-copy todir=${tomcat.build}/server/lib file=${commons-logging.jar} /
copy todir=${tomcat.build}/server/lib file=${commons-modeler.jar} /
-copy todir=${tomcat.build}/bin file=${commons-daemon.jsvc.tar.gz} /
copy todir=${tomcat.build}/bin file=${commons-daemon.jar} /
+copy todir=${tomcat.build}/bin file=${commons-daemon.jsvc.tar.gz} /
copy todir=${tomcat.build}/common/lib file=${ant.jar}/
/target
@@ -280,6 +279,7 @@
path id=jspc.classpath
pathelement location=${java.home}/../lib/tools.jar/
+ pathelement location=${commons-logging.jar}/
pathelement location=${tomcat.build}/server/classes/
fileset dir=${tomcat.build}/server/lib
include name=*.jar/
@@ -724,7 +724,6 @@
fileset dir=${tomcat.build}/server/lib
include name=commons-digester.jar/
include name=commons-beanutils.jar/
-include name=commons-logging.jar/
/fileset
/copy
copy todir=${tomcat.deployer}/lib
@@ -735,6 +734,7 @@
copy todir=${tomcat.deployer}/lib
file=${tomcat.build}/server/lib/catalina-ant.jar/
+copy todir=${tomcat.deployer}/lib file=${commons-logging.jar}/
jar jarfile=${tomcat.deployer}/lib/catalina-deployer.jar
index=true
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/modules/cluster build.xml
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 @@
!-- Construct Catalina classpath --
path id=cluster.classpath
pathelement location=${catalina.build}/server/lib/catalina.jar/
-pathelement location=${catalina.build}/server/lib/commons-logging.jar/
+pathelement location=${commons-logging.jar}/
pathelement location=${jmx.jar}/
pathelement location=${catalina.build}/common/lib/servlet-api.jar/
/path
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PROPOSAL] archive old unmirrored tomcat releases
On Thursday, September 4, 2003, at 07:34 AM, Stefan Bodewig wrote: On Wed, 3 Sep 2003, robert burrell donkin [EMAIL PROTECTED] wrote: snip 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 http://cvs.apache.org/dist/jakarta/. 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]
DO NOT REPLY [Bug 22961] New: - WebAppClassLoader tries to load class from system classloader twice
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22961.
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: [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]
DO NOT REPLY [Bug 22956] - Manager webapp can't treat encvoding correctly
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22956. 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]
DO NOT REPLY [Bug 22961] - WebAppClassLoader tries to load class from system classloader twice
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22961. 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 22961] - WebAppClassLoader tries to load class from system classloader twice
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22961. 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
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22961. 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]
cvs commit: jakarta-tomcat-connectors/jk HOWTO-RELEASE
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]
cvs commit: jakarta-tomcat-connectors/jk/xdocs/common tools.xml
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 @@ -?xml version=1.0 encoding=ISO-8859-1? - -!DOCTYPE index [ -!ENTITY JK SYSTEM menu.jk.idx -!ENTITY JK2 SYSTEM menu.jk2.idx -] - -index - section name=Presentation - document href=index.xml/ - /section - - section name=Commons - document href=common/AJPv13.xml/ - document href=common/AJPv13-extensions-proposal.xml/ - document href=common/doccontrib.xml/ - document href=faq.xml/ - /section - [EMAIL PROTECTED]@ [EMAIL PROTECTED]@ - -/index +?xml version=1.0 encoding=ISO-8859-1? + +!DOCTYPE index [ +!ENTITY JK SYSTEM menu.jk.idx +!ENTITY JK2 SYSTEM menu.jk2.idx +] + +index + section name=Presentation + document href=index.xml/ + /section + + section name=Commons + document href=common/AJPv13.xml/ + document href=common/AJPv13-extensions-proposal.xml/ + document href=common/doccontrib.xml/ + document href=common/tools.xml/ + document href=faq.xml/ + /section + [EMAIL PROTECTED]@ [EMAIL PROTECTED]@ + +/index 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 @@ title xsl:value-of select=properties/title/ /title -meta name=copyright content=1999-2002 The Apache Software Foundation/ +meta name=copyright content=1999-2003 The Apache Software Foundation/ xsl:for-each select=properties/date xsl:variable name=date xsl:value-of select=./ 1.1 jakarta-tomcat-connectors/jk/xdocs/common/tools.xml Index: tools.xml === ?xml version=1.0 encoding=UTF-8? document properties titleTools/title authorGlenn Nielsen/author date$Date: 2003/09/07 03:33:24 $/date /properties section name=Introduction pDocumentation for additional mod_jk related tools./p /section section name=Reports p 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. /p pcodetomcat_trend.pl log_dir archive_dir/code/p p Script for analyzing mod_jk.log data when logging tomcat request data using the codeJkRequestLogFormat/code 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. /p pcodetomcat_reports.pl archive_dir reports_dir/code/p p Script for generating reports and graphs using statistical data generated by the codetomcat_trend.pl/code script. The following graphs are created: ul litomcat_request.png - Long term trend graph of total number of tomcat requests handled./li litomcat_median.png - Long term overall trend graph of tomcat request latency median./li litomcat_deviation.png - Long term overall trend graph of tomcat request mean and standard deviation./li litomcat_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./li litomcat_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./li /ul /p p 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. /p p These perl
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] * 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: [PATCH] Bug 22666
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]
Re: cvs commit: jakarta-tomcat-catalina/catalina/etc bootstrap.MF
- 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: cvs commit: jakarta-tomcat-connectors/jk/native CHANGES.txt
- 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]
cvs commit: jakarta-tomcat-connectors/jk/native CHANGES.txt
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]
mod_jk 1.2.5 test release source distribution
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]
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? 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]
Virtual hosts and multiple Tomcat instances
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) VirtualHost 200.200.200.200 ServerName www.xxx.com DocumentRoot /tomcat1/webapps/xxx JkMount /servlet/* worker1 JkMount /*.jsp worker1 JkMount /*.do worker1 /VirtualHost VirtualHost 200.200.200.200 ServerName www.yyy.com DocumentRoot /tomcat2/webapps/yyy JkMount /servlet/* worker2 JkMount /*.jsp worker2 JkMount /*.do worker2 /VirtualHost 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]
Re: jakarta-tomcat-connector release cleanup
- 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]
