Re: svn commit: r895700 - /tomcat/native/trunk/native/build/tcnative.m4
On 01/04/2010 08:50 PM, Konstantin Kolinko wrote:
2010/1/4 rj...@apache.org:
Author: rjung
Date: Mon Jan 4 16:58:04 2010
New Revision: 895700
URL: http://svn.apache.org/viewvc?rev=895700view=rev
Log:
Fix apr version test i tcnative trunk.
Modified:
tomcat/native/trunk/native/build/tcnative.m4
--- tomcat/native/trunk/native/build/tcnative.m4 (original)
+++ tomcat/native/trunk/native/build/tcnative.m4 Mon Jan 4 16:58:04 2010
@@ -35,8 +35,12 @@
if test ${1} -lt 1; then
AC_MSG_ERROR(You need APR version 1.3.3 or newer installed.)
else
-if test ${2} -lt 2; then
+if test ${2} -lt 3; then
AC_MSG_ERROR(You need APR version 1.3.3 or newer installed.)
+else
+ if test ${2} -lt 3; then
+AC_MSG_ERROR(You need APR version 1.3.3 or newer installed.)
+ fi
fi
fi
I do not understand the above. What is the difference between these checks? :
+if test ${2} -lt 3; then
+ if test ${2} -lt 3; then
Should be
if test ${2} -lt 3; then
if test ${3} -lt 3; then
No?
Cheers
Jean-Frederic
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tcnative] slight apr and openssl version confusion
On 01/04/2010 06:01 PM, Rainer Jung wrote: What is the use of the file native/srclib/VERSIONS in tcnative? Ib the 1.1.x branch it contains the info: = Use the following version of the libraries - APR 1.2.8, http://apr.apache.org - OpenSSL 0.9.8e, http://www.openssl.org = But the build system checks for APR 1.2.1 and OpenSSL = 0.9.7f in native/buildconf and native/build/tcnative.m4. Additionally the buildconf defaults to apr-1.2.7 located in srclib. What happens is that buildconf copies files from apr the idea was to have that information in native/srclib/VERSIONS. I think the file native/srclib/VERSIONS should be created by configure and doesn't need to be in repository. Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tcnative] slight apr and openssl version confusion
On 01/05/2010 09:11 AM, jean-frederic clere wrote: I think the file native/srclib/VERSIONS should be created by configure and doesn't need to be in repository. This file is more like a README. It says which version is recommended/required for the builds. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r895964 - /tomcat/native/branches/1.1.x/xdocs/miscellaneous/changelog.xml
Author: rjung Date: Tue Jan 5 09:46:35 2010 New Revision: 895964 URL: http://svn.apache.org/viewvc?rev=895964view=rev Log: Fix credts for patch. Modified: tomcat/native/branches/1.1.x/xdocs/miscellaneous/changelog.xml Modified: tomcat/native/branches/1.1.x/xdocs/miscellaneous/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/native/branches/1.1.x/xdocs/miscellaneous/changelog.xml?rev=895964r1=895963r2=895964view=diff == --- tomcat/native/branches/1.1.x/xdocs/miscellaneous/changelog.xml (original) +++ tomcat/native/branches/1.1.x/xdocs/miscellaneous/changelog.xml Tue Jan 5 09:46:35 2010 @@ -40,7 +40,7 @@ changelog fix bug48129/bug: Fix build with OpenSSL 1.0.0-beta3. - Patch provided by Ville Skytt. (mturk, rjung) + Patch provided by Tomas Mraz. (mturk, rjung) /fix update Add detection of the Mac OS X JVM. (rjung) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn propchange: r895731 - svn:log
Author: rjung Revision: 895731 Modified property: svn:log Modified: svn:log at Tue Jan 5 09:49:32 2010 -- --- svn:log (original) +++ svn:log Tue Jan 5 09:49:32 2010 @@ -2,4 +2,4 @@ r890720 plus this addition is identical to the fix for BZ48129: Fix build with OpenSSL 1.0.0-beta3, -contributed by Ville Skytt. +contributed by Tomas Mraz. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn propchange: r895733 - svn:log
Author: rjung Revision: 895733 Modified property: svn:log Modified: svn:log at Tue Jan 5 09:50:10 2010 -- --- svn:log (original) +++ svn:log Tue Jan 5 09:50:10 2010 @@ -2,6 +2,6 @@ r890720 plus this addition is identical to the fix for BZ48129: Fix build with OpenSSL 1.0.0-beta3, -contributed by Ville Skytt. +contributed by Tomas Mraz. Backport of r895731. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r894577 - /tomcat/trunk/conf/web.xml
On 05/01/2010 00:17, Konstantin Kolinko wrote: The xsi:schemaLocation attribute above is wrong. It should be a pair of URLs. Fixed. Thanks. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48129] [PATCH] Fix build with OpenSSL 1.0.0-beta3
https://issues.apache.org/bugzilla/show_bug.cgi?id=48129 Rainer Jung rainer.j...@kippdata.de changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #3 from Rainer Jung rainer.j...@kippdata.de 2010-01-05 01:51:56 UTC --- Fixed patch author in changelog and svn log. Sorry about missing that initially. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r895968 - /tomcat/native/trunk/native/build/tcnative.m4
Author: rjung
Date: Tue Jan 5 09:53:36 2010
New Revision: 895968
URL: http://svn.apache.org/viewvc?rev=895968view=rev
Log:
Fix wrong index in APR version number check.
Modified:
tomcat/native/trunk/native/build/tcnative.m4
Modified: tomcat/native/trunk/native/build/tcnative.m4
URL:
http://svn.apache.org/viewvc/tomcat/native/trunk/native/build/tcnative.m4?rev=895968r1=895967r2=895968view=diff
==
--- tomcat/native/trunk/native/build/tcnative.m4 (original)
+++ tomcat/native/trunk/native/build/tcnative.m4 Tue Jan 5 09:53:36 2010
@@ -38,7 +38,7 @@
if test ${2} -lt 3; then
AC_MSG_ERROR(You need APR version 1.3.3 or newer installed.)
else
- if test ${2} -lt 3; then
+ if test ${3} -lt 3; then
AC_MSG_ERROR(You need APR version 1.3.3 or newer installed.)
fi
fi
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r895700 - /tomcat/native/trunk/native/build/tcnative.m4
On 05.01.2010 08:59, jean-frederic clere wrote:
On 01/04/2010 08:50 PM, Konstantin Kolinko wrote:
2010/1/4rj...@apache.org:
Author: rjung
Date: Mon Jan 4 16:58:04 2010
New Revision: 895700
URL: http://svn.apache.org/viewvc?rev=895700view=rev
Log:
Fix apr version test i tcnative trunk.
Modified:
tomcat/native/trunk/native/build/tcnative.m4
--- tomcat/native/trunk/native/build/tcnative.m4 (original)
+++ tomcat/native/trunk/native/build/tcnative.m4 Mon Jan 4 16:58:04 2010
@@ -35,8 +35,12 @@
if test ${1} -lt 1; then
AC_MSG_ERROR(You need APR version 1.3.3 or newer installed.)
else
-if test ${2} -lt 2; then
+if test ${2} -lt 3; then
AC_MSG_ERROR(You need APR version 1.3.3 or newer installed.)
+else
+ if test ${2} -lt 3; then
+AC_MSG_ERROR(You need APR version 1.3.3 or newer installed.)
+ fi
fi
fi
I do not understand the above. What is the difference between these checks? :
+if test ${2} -lt 3; then
+ if test ${2} -lt 3; then
Should be
if test ${2} -lt 3; then
if test ${3} -lt 3; then
No?
Right, sorry, fixed.
Konstantin: JFC is right, it was meant to also check against the third
part of the minimum apr version 1 . 3 . 3.
Regards,
Rainer
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tcnative] slight apr and openssl version confusion
On 05.01.2010 10:04, Mladen Turk wrote: On 01/05/2010 09:11 AM, jean-frederic clere wrote: I think the file native/srclib/VERSIONS should be created by configure and doesn't need to be in repository. This file is more like a README. It says which version is recommended/required for the builds. Hmmm, recommended yes, but not required. The checks during the build test against other (lower) versions. Are we really maintaining that recommendation? Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [tcnative] slight apr and openssl version confusion
On 01/05/2010 10:59 AM, Rainer Jung wrote: On 05.01.2010 10:04, Mladen Turk wrote: On 01/05/2010 09:11 AM, jean-frederic clere wrote: I think the file native/srclib/VERSIONS should be created by configure and doesn't need to be in repository. This file is more like a README. It says which version is recommended/required for the builds. Hmmm, recommended yes, but not required. The checks during the build test against other (lower) versions. Are we really maintaining that recommendation? Yes. It's very important cause some APR errors reflect tcnative, like Solaris port patches for 1.3.8 and 1.3.9. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r895700 - /tomcat/native/trunk/native/build/tcnative.m4
2010/1/5 Rainer Jung rainer.j...@kippdata.de:
On 05.01.2010 08:59, jean-frederic clere wrote:
On 01/04/2010 08:50 PM, Konstantin Kolinko wrote:
2010/1/4rj...@apache.org:
Author: rjung
Date: Mon Jan 4 16:58:04 2010
New Revision: 895700
URL: http://svn.apache.org/viewvc?rev=895700view=rev
Log:
Fix apr version test i tcnative trunk.
Modified:
tomcat/native/trunk/native/build/tcnative.m4
--- tomcat/native/trunk/native/build/tcnative.m4 (original)
+++ tomcat/native/trunk/native/build/tcnative.m4 Mon Jan 4 16:58:04
2010
@@ -35,8 +35,12 @@
if test ${1} -lt 1; then
AC_MSG_ERROR(You need APR version 1.3.3 or newer installed.)
else
- if test ${2} -lt 2; then
+ if test ${2} -lt 3; then
AC_MSG_ERROR(You need APR version 1.3.3 or newer installed.)
+ else
+ if test ${2} -lt 3; then
+ AC_MSG_ERROR(You need APR version 1.3.3 or newer installed.)
+ fi
fi
fi
I do not understand the above. What is the difference between these
checks? :
+ if test ${2} -lt 3; then
+ if test ${2} -lt 3; then
Should be
if test ${2} -lt 3; then
if test ${3} -lt 3; then
No?
Right, sorry, fixed.
Konstantin: JFC is right, it was meant to also check against the third part
of the minimum apr version 1 . 3 . 3.
Regards,
Rainer
Understood.
By the way: you should check the third number
only if the second one is equal to 3.
Looking at
http://apr.apache.org/versioning.html
1.4.x (or whatever the next minor version might be) should be
compatible with 1.3
At least that is what the docs say.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Tomcat Native 1.1.19 pre-release
Hi, I've build the 1.1.19 pre-release http://people.apache.org/~mturk/native/ It is build from 1.1.x branch using the revision 859968 If no one finds any problems with that, I'll tag the 1.1.19 in few hours and create a full release with vote proposal. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r895700 - /tomcat/native/trunk/native/build/tcnative.m4
On 01/05/2010 11:23 AM, Konstantin Kolinko wrote:
2010/1/5 Rainer Jungrainer.j...@kippdata.de:
Konstantin: JFC is right, it was meant to also check against the third part
of the minimum apr version 1 . 3 . 3.
By the way: you should check the third number
only if the second one is equal to 3.
The simplest would just be
if [ ${1}${2}${3} -lt 133 ]; then
echo Minimun required version is 1.3.3
exit 1
fi
Regards
--
^TM
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r895981 - /tomcat/trunk/test/org/apache/catalina/tomcat/
Author: markt Date: Tue Jan 5 10:53:36 2010 New Revision: 895981 URL: http://svn.apache.org/viewvc?rev=895981view=rev Log: Remove empty dirs Removed: tomcat/trunk/test/org/apache/catalina/tomcat/ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r895983 - /tomcat/tc6.0.x/trunk/test/org/apache/catalina/tomcat/
Author: markt Date: Tue Jan 5 10:54:53 2010 New Revision: 895983 URL: http://svn.apache.org/viewvc?rev=895983view=rev Log: When moving cookie test case to correct package, should also have removed empty dirs Removed: tomcat/tc6.0.x/trunk/test/org/apache/catalina/tomcat/ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r895984 - /tomcat/native/trunk/native/build/tcnative.m4
Author: rjung
Date: Tue Jan 5 10:57:52 2010
New Revision: 895984
URL: http://svn.apache.org/viewvc?rev=895984view=rev
Log:
Get rid of nested version test by formatting
version number as one big decimal.
Modified:
tomcat/native/trunk/native/build/tcnative.m4
Modified: tomcat/native/trunk/native/build/tcnative.m4
URL:
http://svn.apache.org/viewvc/tomcat/native/trunk/native/build/tcnative.m4?rev=895984r1=895983r2=895984view=diff
==
--- tomcat/native/trunk/native/build/tcnative.m4 (original)
+++ tomcat/native/trunk/native/build/tcnative.m4 Tue Jan 5 10:57:52 2010
@@ -32,16 +32,9 @@
fi
sapr_version=`echo $sapr_pversion|sed -e 's/\([a-z]*\)$/.\1/'`
tc_save_IFS=$IFS; IFS=.; set $sapr_version; IFS=$tc_save_IFS
- if test ${1} -lt 1; then
+ decimal_apr_version=`printf %02d%02d%03d ${1} ${2} ${3}`
+ if test ${decimal_apr_version} -lt 0101003; then
AC_MSG_ERROR(You need APR version 1.3.3 or newer installed.)
- else
-if test ${2} -lt 3; then
- AC_MSG_ERROR(You need APR version 1.3.3 or newer installed.)
-else
- if test ${3} -lt 3; then
-AC_MSG_ERROR(You need APR version 1.3.3 or newer installed.)
- fi
-fi
fi
APR_BUILD_DIR=`$apr_config --installbuilddir`
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r895984 - /tomcat/native/trunk/native/build/tcnative.m4
On 01/05/2010 11:57 AM, rj...@apache.org wrote:
Author: rjung
Get rid of nested version test by formatting
version number as one big decimal.
+ decimal_apr_version=`printf %02d%02d%03d ${1} ${2} ${3}`
+ if test ${decimal_apr_version} -lt 0101003; then
You should not quote the arithmetic ops though.
Also 0101003 is exactly what? 1.1.3 ?
And the format should be %d%d%03d
APR has 1-1-N digits in formats.
There will never be thing like APR 1.11.X :)
Regards
--
^TM
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r895994 - /tomcat/native/branches/1.1.x/jnirelease.sh
Author: mturk
Date: Tue Jan 5 11:36:32 2010
New Revision: 895994
URL: http://svn.apache.org/viewvc?rev=895994view=rev
Log:
Make sure the win32 source dist has all the parts like .tar.gz version (with
CRLF and -configure)
Modified:
tomcat/native/branches/1.1.x/jnirelease.sh
Modified: tomcat/native/branches/1.1.x/jnirelease.sh
URL:
http://svn.apache.org/viewvc/tomcat/native/branches/1.1.x/jnirelease.sh?rev=895994r1=895993r2=895994view=diff
==
--- tomcat/native/branches/1.1.x/jnirelease.sh (original)
+++ tomcat/native/branches/1.1.x/jnirelease.sh Tue Jan 5 11:36:32 2010
@@ -90,7 +90,7 @@
echo
exit 1
fi
-
+UNIX2DOS=`which unix2dos 2/dev/null || unix2dos $i 21`
echo $JKJNIEXT | egrep -e 'x$' /dev/null 21
if [ $? -eq 0 ]; then
USE_BRANCH=1
@@ -134,11 +134,10 @@
rm -rf ${JKJNIDIST}/jni/xdocs
mv ${JKJNIDIST}/jni/build/docs ${JKJNIDIST}/jni/docs
rm -rf ${JKJNIDIST}/jni/build
-svn cat ${JKJNISVN}/KEYS ${JKJNIDIST}/KEYS
-svn cat ${JKJNISVN}/LICENSE ${JKJNIDIST}/LICENSE
-svn cat ${JKJNISVN}/NOTICE ${JKJNIDIST}/NOTICE
-svn cat ${JKJNISVN}/README.txt ${JKJNIDIST}/README.txt
-
+for i in KEYS LICENSE NOTICE README.txt
+do
+svn cat ${JKJNISVN}/${i} ${JKJNIDIST}/${i}
+done
#
# Prebuild
cd ${JKJNIDIST}/jni/native
@@ -151,10 +150,32 @@
JKWINDIST=tomcat-native-${JKJNIVER}-win32-src
rm -rf ${JKWINDIST}
mkdir -p ${JKWINDIST}/jni
-svn export --native-eol CRLF ${JKJNISVN}/native ${JKWINDIST}/jni/native
-svn cat ${JKJNISVN}/KEYS ${JKWINDIST}/KEYS
-svn cat ${JKJNISVN}/LICENSE ${JKWINDIST}/LICENSE
-svn cat ${JKJNISVN}/NOTICE ${JKWINDIST}/NOTICE
-svn cat ${JKJNISVN}/README.txt ${JKWINDIST}/README.txt
-cp ${JKJNIDIST}/CHANGELOG.txt ${JKWINDIST}/
+for i in native java xdocs examples test build.xml build.properties.default
+do
+svn export --native-eol CRLF ${JKJNISVN}/${i} ${JKWINDIST}/jni/${i}
+if [ $? -ne 0 ]; then
+echo svn export ${i} failed
+exit 1
+fi
+done
+top=`pwd`
+cd ${JKWINDIST}/jni/xdocs
+ant
+$EXPTOOL $EXPOPTS ../build/docs/miscellaneous/printer/changelog.html
../../CHANGELOG.txt 2/dev/null
+cd $top
+
+rm -rf ${JKWINDIST}/jni/xdocs
+mv ${JKWINDIST}/jni/build/docs ${JKWINDIST}/jni/docs
+rm -rf ${JKWINDIST}/jni/build
+for i in KEYS LICENSE NOTICE README.txt
+do
+svn cat ${JKJNISVN}/${i} ${JKWINDIST}/${i}
+if [ -x $UNIX2DOS ]; then
+$UNIX2DOS ${JKWINDIST}/${i}
+fi
+done
+if [ -x $UNIX2DOS ]; then
+$UNIX2DOS ${JKWINDIST}/CHANGELOG.txt 2/dev/null
+fi
zip -9rqyo ${JKWINDIST}.zip ${JKWINDIST}
+
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r895700 - /tomcat/native/trunk/native/build/tcnative.m4
On 05/01/2010, sebb seb...@gmail.com wrote:
On 05/01/2010, Mladen Turk mt...@apache.org wrote:
On 01/05/2010 11:23 AM, Konstantin Kolinko wrote:
2010/1/5 Rainer Jungrainer.j...@kippdata.de:
Konstantin: JFC is right, it was meant to also check against the third
part
of the minimum apr version 1 . 3 . 3.
By the way: you should check the third number
only if the second one is equal to 3.
The simplest would just be
if [ ${1}${2}${3} -lt 133 ]; then
echo Minimun required version is 1.3.3
exit 1
fi
Not sure this works properly if any of the parts is 9
Scrap that, I've just seen the actual fix which coerces the parts to 2
or 3 digits, which should be OK for a lot longer.
Regards
--
^TM
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r895998 - /tomcat/native/branches/1.1.x/jnirelease.sh
Author: mturk Date: Tue Jan 5 11:39:27 2010 New Revision: 895998 URL: http://svn.apache.org/viewvc?rev=895998view=rev Log: Fix copy/pase typo Modified: tomcat/native/branches/1.1.x/jnirelease.sh Modified: tomcat/native/branches/1.1.x/jnirelease.sh URL: http://svn.apache.org/viewvc/tomcat/native/branches/1.1.x/jnirelease.sh?rev=895998r1=895997r2=895998view=diff == --- tomcat/native/branches/1.1.x/jnirelease.sh (original) +++ tomcat/native/branches/1.1.x/jnirelease.sh Tue Jan 5 11:39:27 2010 @@ -90,7 +90,7 @@ echo exit 1 fi -UNIX2DOS=`which unix2dos 2/dev/null || unix2dos $i 21` +UNIX2DOS=`which unix2dos 2/dev/null || type unix2dos 21` echo $JKJNIEXT | egrep -e 'x$' /dev/null 21 if [ $? -eq 0 ]; then USE_BRANCH=1 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r895984 - /tomcat/native/trunk/native/build/tcnative.m4
On 05/01/2010, Mladen Turk mt...@apache.org wrote:
On 01/05/2010 11:57 AM, rj...@apache.org wrote:
Author: rjung
Get rid of nested version test by formatting
version number as one big decimal.
+ decimal_apr_version=`printf %02d%02d%03d ${1} ${2} ${3}`
+ if test ${decimal_apr_version} -lt 0101003; then
You should not quote the arithmetic ops though.
Also 0101003 is exactly what? 1.1.3 ?
For added safety the format could also be used to generate the comparator.
And the format should be %d%d%03d
APR has 1-1-N digits in formats.
There will never be thing like APR 1.11.X :)
Regards
--
^TM
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r895998 - /tomcat/native/branches/1.1.x/jnirelease.sh
Hi Mladen, I seem to remember that the fix line ends perl script is part of the tcnative repos. Regards, Rainer On 05.01.2010 12:39, mt...@apache.org wrote: Author: mturk Date: Tue Jan 5 11:39:27 2010 New Revision: 895998 URL: http://svn.apache.org/viewvc?rev=895998view=rev Log: Fix copy/pase typo Modified: tomcat/native/branches/1.1.x/jnirelease.sh Modified: tomcat/native/branches/1.1.x/jnirelease.sh URL: http://svn.apache.org/viewvc/tomcat/native/branches/1.1.x/jnirelease.sh?rev=895998r1=895997r2=895998view=diff == --- tomcat/native/branches/1.1.x/jnirelease.sh (original) +++ tomcat/native/branches/1.1.x/jnirelease.sh Tue Jan 5 11:39:27 2010 @@ -90,7 +90,7 @@ echo exit 1 fi -UNIX2DOS=`which unix2dos 2/dev/null || unix2dos $i 21` +UNIX2DOS=`which unix2dos 2/dev/null || type unix2dos 21` echo $JKJNIEXT | egrep -e 'x$' /dev/null 21 if [ $? -eq 0 ]; then USE_BRANCH=1 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48488] New: accepCount does not limit connections
https://issues.apache.org/bugzilla/show_bug.cgi?id=48488 Summary: accepCount does not limit connections Product: Tomcat 6 Version: 6.0.20 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Connectors AssignedTo: dev@tomcat.apache.org ReportedBy: pbeich...@gmx.de I tried to limit the number of requests, but Tomcat accepts always all requests. I never receive a connection refused. example: Connector port=8081 acceptCount=6 maxThreads=3 minSpareThreads=1 maxSpareThreads=2 enableLookups=false / If I open 100 parallel requests to a servlet which does nothing else than waiting for 5 seconds, I should get 91 times connection refused with the configuration above. However, the tomcat server queues all requests and I get 100 answers with status 200 which takes a lot of time. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48489] New: Tomcat CL doesn't resolve the array classes.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48489
Summary: Tomcat CL doesn't resolve the array classes.
Product: Tomcat 6
Version: 6.0.0
Platform: All
OS/Version: Linux
Status: NEW
Severity: major
Priority: P2
Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: kakvi...@yahoo.co.in
Attached is the sample app whose index.jsp would explain the error, call this
jsp
http://localhost:8080/sampleapp/index.jsp
The TomcatCL does not resolve the array class e.g
loader.loadClass([Lsample.SampleClass;)
And here is the fix
Index: src/share/classes/org/apache/catalina/loader/WebappClassLoader.java
===
--- src/share/classes/org/apache/catalina/loader/WebappClassLoader.java
(revision 1335)
+++ src/share/classes/org/apache/catalina/loader/WebappClassLoader.java
(working copy)
@@ -902,8 +902,22 @@
throw new ClassNotFoundException(name);
}
} catch (ClassNotFoundException e) {
-if (log.isTraceEnabled())
-log.trace(-- Passing on ClassNotFoundException);
+ if (log.isTraceEnabled())
+ log.trace(We need to check for array class +name);
+if( name.charAt(0) == '[' )
+{
+ clazz = Class.forName(name, true, this);
+ if (log.isTraceEnabled())
+ log.debug( Returning class + clazz);
+ if ((log.isTraceEnabled()) (clazz != null))
+ log.debug( Loaded by + clazz.getClassLoader());
+ return clazz;
+}
+else
+{
+if (log.isTraceEnabled())
+log.trace(-- Passing on ClassNotFoundException);
+}
throw e;
}
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48489] Tomcat CL doesn't resolve the array classes.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48489 --- Comment #1 from VickyKak kakvi...@yahoo.co.in 2010-01-05 05:21:45 UTC --- Created an attachment (id=24795) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24795) Proposed Fix. I did try the patch here http://svn.apache.org/repos/asf/tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoader.java -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48489] Tomcat CL doesn't resolve the array classes.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48489 --- Comment #2 from VickyKak kakvi...@yahoo.co.in 2010-01-05 05:23:24 UTC --- Created an attachment (id=24796) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24796) sample test application. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48489] Tomcat CL doesn't resolve the array classes.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48489 --- Comment #3 from VickyKak kakvi...@yahoo.co.in 2010-01-05 05:29:48 UTC --- Created an attachment (id=24797) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24797) Bug48489.patch -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48489] Tomcat CL doesn't resolve the array classes.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48489 --- Comment #4 from VickyKak kakvi...@yahoo.co.in 2010-01-05 05:30:26 UTC --- Bug48489.patch is the required fix. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r895998 - /tomcat/native/branches/1.1.x/jnirelease.sh
On 01/05/2010 01:34 PM, Rainer Jung wrote: Hi Mladen, I seem to remember that the fix line ends perl script is part of the tcnative repos. Which requires perl, so chicken and egg problem again. Probably could be used if the unix2dos is not found and perl exists. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48489] Tomcat CL doesn't resolve the array classes.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48489 --- Comment #5 from Filip Hanik fha...@apache.org 2010-01-05 05:54:58 UTC --- couldn't you just use -Dsun.lang.ClassLoader.allowArraySyntax=true -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r896039 - /tomcat/native/branches/1.1.x/jnirelease.sh
Author: mturk
Date: Tue Jan 5 13:57:56 2010
New Revision: 896039
URL: http://svn.apache.org/viewvc?rev=896039view=rev
Log:
Use our lineends.pl script instead unix2dos utility
Modified:
tomcat/native/branches/1.1.x/jnirelease.sh
Modified: tomcat/native/branches/1.1.x/jnirelease.sh
URL:
http://svn.apache.org/viewvc/tomcat/native/branches/1.1.x/jnirelease.sh?rev=896039r1=896038r2=896039view=diff
==
--- tomcat/native/branches/1.1.x/jnirelease.sh (original)
+++ tomcat/native/branches/1.1.x/jnirelease.sh Tue Jan 5 13:57:56 2010
@@ -90,7 +90,7 @@
echo
exit 1
fi
-UNIX2DOS=`which unix2dos 2/dev/null || type unix2dos 21`
+PERL=`which perl 2/dev/null || type perl 21`
echo $JKJNIEXT | egrep -e 'x$' /dev/null 21
if [ $? -eq 0 ]; then
USE_BRANCH=1
@@ -170,12 +170,12 @@
for i in KEYS LICENSE NOTICE README.txt
do
svn cat ${JKJNISVN}/${i} ${JKWINDIST}/${i}
-if [ -x $UNIX2DOS ]; then
-$UNIX2DOS ${JKWINDIST}/${i}
+if [ -x $PERL ]; then
+$PERL ${JKWINDIST}/jni/native/build/lineends.pl --cr ${JKWINDIST}/${i}
fi
done
-if [ -x $UNIX2DOS ]; then
-$UNIX2DOS ${JKWINDIST}/CHANGELOG.txt 2/dev/null
+if [ -x $PERL ]; then
+$PERL ${JKWINDIST}/jni/native/build/lineends.pl --cr
${JKWINDIST}/CHANGELOG.txt
fi
zip -9rqyo ${JKWINDIST}.zip ${JKWINDIST}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r895998 - /tomcat/native/branches/1.1.x/jnirelease.sh
On 01/05/2010 01:34 PM, Rainer Jung wrote: Hi Mladen, I seem to remember that the fix line ends perl script is part of the tcnative repos. Done. After second thought the perl is more likely to be present then unix2dos. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r896052 - /tomcat/native/branches/1.1.x/native/include/tcn_version.h
Author: mturk Date: Tue Jan 5 14:11:59 2010 New Revision: 896052 URL: http://svn.apache.org/viewvc?rev=896052view=rev Log: Prepare for 1.1.19 tag Modified: tomcat/native/branches/1.1.x/native/include/tcn_version.h Modified: tomcat/native/branches/1.1.x/native/include/tcn_version.h URL: http://svn.apache.org/viewvc/tomcat/native/branches/1.1.x/native/include/tcn_version.h?rev=896052r1=896051r2=896052view=diff == --- tomcat/native/branches/1.1.x/native/include/tcn_version.h (original) +++ tomcat/native/branches/1.1.x/native/include/tcn_version.h Tue Jan 5 14:11:59 2010 @@ -75,7 +75,7 @@ * This symbol is defined for internal, development copies of TCN. This * symbol will be #undef'd for releases. */ -#define TCN_IS_DEV_VERSION 1 +#define TCN_IS_DEV_VERSION 0 /** The formatted string of APU's version */ @@ -97,3 +97,4 @@ #endif #endif /* TCN_VERSION_H */ + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r896054 - /tomcat/native/tags/TOMCAT_NATIVE_1_1_19/
Author: mturk Date: Tue Jan 5 14:12:24 2010 New Revision: 896054 URL: http://svn.apache.org/viewvc?rev=896054view=rev Log: Tag 1.1.19 Added: tomcat/native/tags/TOMCAT_NATIVE_1_1_19/ (props changed) - copied from r896053, tomcat/native/branches/1.1.x/ Propchange: tomcat/native/tags/TOMCAT_NATIVE_1_1_19/ -- --- svn:ignore (added) +++ svn:ignore Tue Jan 5 14:12:24 2010 @@ -0,0 +1 @@ +dist Propchange: tomcat/native/tags/TOMCAT_NATIVE_1_1_19/ -- svn:mergeinfo = /tomcat/native/trunk:815411 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r896069 - in /tomcat/native/branches/1.1.x/native: include/tcn_version.h os/win32/libtcnative.rc
Author: mturk Date: Tue Jan 5 14:43:18 2010 New Revision: 896069 URL: http://svn.apache.org/viewvc?rev=896069view=rev Log: Advance version to 1.1.20-dev Modified: tomcat/native/branches/1.1.x/native/include/tcn_version.h tomcat/native/branches/1.1.x/native/os/win32/libtcnative.rc Modified: tomcat/native/branches/1.1.x/native/include/tcn_version.h URL: http://svn.apache.org/viewvc/tomcat/native/branches/1.1.x/native/include/tcn_version.h?rev=896069r1=896068r2=896069view=diff == --- tomcat/native/branches/1.1.x/native/include/tcn_version.h (original) +++ tomcat/native/branches/1.1.x/native/include/tcn_version.h Tue Jan 5 14:43:18 2010 @@ -69,13 +69,13 @@ #define TCN_MINOR_VERSION 1 /** patch level */ -#define TCN_PATCH_VERSION 19 +#define TCN_PATCH_VERSION 20 /** * This symbol is defined for internal, development copies of TCN. This * symbol will be #undef'd for releases. */ -#define TCN_IS_DEV_VERSION 0 +#define TCN_IS_DEV_VERSION 1 /** The formatted string of APU's version */ Modified: tomcat/native/branches/1.1.x/native/os/win32/libtcnative.rc URL: http://svn.apache.org/viewvc/tomcat/native/branches/1.1.x/native/os/win32/libtcnative.rc?rev=896069r1=896068r2=896069view=diff == --- tomcat/native/branches/1.1.x/native/os/win32/libtcnative.rc (original) +++ tomcat/native/branches/1.1.x/native/os/win32/libtcnative.rc Tue Jan 5 14:43:18 2010 @@ -20,7 +20,7 @@ See the License for the specific language governing \ permissions and limitations under the License. -#define TCN_VERSION 1.1.19 +#define TCN_VERSION 1.1.20 1000 ICON apache.ico 1001 DIALOGEX 0, 0, 252, 51 @@ -36,8 +36,8 @@ END 1 VERSIONINFO - FILEVERSION 1,1,19,0 - PRODUCTVERSION 1,1,19,0 + FILEVERSION 1,1,20,0 + PRODUCTVERSION 1,1,20,0 FILEFLAGSMASK 0x3fL #ifdef _DEBUG FILEFLAGS 0x1L @@ -68,3 +68,4 @@ VALUE Translation, 0x409, 1200 END END + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[VOTE] Release Apache Tomcat Native 1.1.19
Hi, Native 1.1.19 is available for testing. Compared with 1.1.18 It has minor versioning fix and allows building against OpenSSL 1.0 (well Rainer beat me before the tag :) If you want to take a look, the final source distribution can be downloaded from: http://tomcat.apache.org/dev/dist/tomcat-connectors/native/source/1.1.19 (until synced the builds are available at) http://people.apache.org/~mturk/native/source/1.1.19 Win32/Win64 binaries will be available at: http://tomcat.apache.org/dev/dist/tomcat-connectors/native/binaries/ So here's the vote. It will be closed in about 72 hours (or sooner if enough votes are encountered) Apache Tomcat Native 1.1.19 is: [ ] Stable - no major issues, no regressions [ ] Beta - at least one significant issue -- tell us what it is [ ] Alpha - multiple significant issues -- tell us what they are Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48489] Tomcat CL doesn't resolve the array classes.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48489 --- Comment #6 from VickyKak kakvi...@yahoo.co.in 2010-01-05 08:30:05 UTC --- (In reply to comment #5) couldn't you just use -Dsun.lang.ClassLoader.allowArraySyntax=true I don't see it useful, here is the related bug http://bugs.sun.com/view_bug.do?bug_id=6434149 The TomcatCL does not resolve the custom class array, this should be done via system classloader call as + clazz = Class.forName(name, true, this); -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48489] Tomcat CL doesn't resolve the array classes.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48489 --- Comment #7 from Kris Schneider kschnei...@gmail.com 2010-01-05 08:41:17 UTC --- (In reply to comment #6) http://bugs.sun.com/view_bug.do?bug_id=6434149 That bug, as well as others, implies that your JSP code is wrong. Instead of this: loader.loadClass([Lsample.SampleClass;) you should do this: Class.forName([Lsample.SampleClass;, false, loader) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Problem loading classes with Class.forName() in StandardContext.createWrapper()
On Jan 4, 2010, at 2:56 AM, Mark Thomas wrote: On 04/01/2010 02:46, Tim Whittington wrote: No need to re-post. A ping would have sufficed. We've experienced similar issues integrating lots of third party libraries (Tomcat being one of them) into our OSGi runtime. Thanks for your input. I can't speak for the other Tomcat committers but I know very little about OSGI so it is useful to have input from those more experienced. Essentially this boils down to OSGi liking extension functionality to be provided by instantiation in the providing bundles, and publication using OSGi services. (i.e. pure OSGi services or declarative services etc.). Put another way, the concepts of global application classloaders where Class.forName works (ala Java EE etc.) break down in OSGi. Libraries that use the TCCL in preference to Class.forName help, but in cases like the one you describe where there's no direct invocation from the bundle that has access to the classes it doesn't help. Fragment bundles (and Eclipse specific buddy classloaders) also help, and we've had to use them with tools like Hibernate, but they're less than ideal. I think the conclusion you've reached is correct - either fragment bundles (which is a sub-optimal solution) or a pluggable extension loading framework could be the solution. OK. The consensus amongst those that know OSGI seems to be some form for pluggable extension point. I believe we ran into issues like this when integrating Tomcat 5.5 into our OSGi runtime - we had to patch up the web app ClassLoaders at runtime to make taglib loading work. In that case we were able to wrap the ClassLoaders with the help of some declarative metadata in bundles containing taglibs. If you can tell which bundles can contain implementions of whatever it is you're trying to instantiate, you can construct a ClassLoader spanning those bundles yourself and use that (you'd only want to use it for loading these extensions, as it defeats the purpose/ nature of OSGi to some extent to do this). It might be that the web application bundles would be all you need (and the upcoming OSGi Enterprise Spec will give you a standard way of locating these), and that'd probably be a reasonable limitation, or you could accomodate applications partitioned to a finer degree by some additional marker to include other bundles. The other, more OSGi approach would be for listeners to be published as OSGi services with target properties, that are then just looked up by name by the OSGi version of the extension loader (as opposed to instantiating them). i.e. an instance of the Listener interface is published by a bundle as an OSGi service with a property tomcatClassName=org.myproject.impl.MyListener. The extension loader then looks up the service with a property filter on 'tomcatClassName' to find the available extension. OSGi apps using Tomcat would simply publish these using Declarative Services or similar, and this would be a very natural approach for an OSGi app. Using Services does seem more in the spirit of OSGI. With this latter approach you have delightful lifecycle management issues because of the dynamic nature of OSGi (extension bundles starting after the Tomcat bundles for instance). We solve some of these with a combination of declarative only metadata (using the Eclipse Extension Registry) to advertise extension existence on bundle resolution, and Declarative Services to instantiate and publish the actual extension, and some by having the framework accept dynamic injection of extensions (Listeners come and go). Glad I don't have to worry about those issues :) The main purpose of the InstanceManager is meet some of the requirements for annotations support. As such, it is only used for instances that may have annotations. There is one InstanceManager instance per web application. One thing that isn't clear to me is whether the requirement is for an extension point for web application related instances (ie things that in a J2EE environment would be bundled in the WAR) or for container related instances such as LifecycleListeners. The current patch in bug 48414 seems to focussed on Tomcat internals and I don't understand how the line was drawn between what to access via the InstanceManager and what not to. Thanks for taking another look at this subject. I've been thinking of the InstanceManager as the extension point for creating objects by reflection rather than as the annotation handler, perhaps because of how the Geronimo InstanceManager happens to be implemented. So, it seems to me that adding a newSystemInstance method to it for creating objects that are expected to come from the system rather than application classes is reasonable. I'll try to come up with a patch using this additional method in the next day or two. thanks again! david jencks Mark
DO NOT REPLY [Bug 48414] Use of Class.forName may not work well in osgi environment
https://issues.apache.org/bugzilla/show_bug.cgi?id=48414 david jencks djen...@apache.org changed: What|Removed |Added Attachment #24737|0 |1 is obsolete|| --- Comment #4 from david jencks djen...@apache.org 2010-01-05 11:23:12 UTC --- Created an attachment (id=24798) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24798) half of patch to use new newSystemInstance InstanceManager method add method to instance manager so system and app objects can be distinguished. In two patches. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48414] Use of Class.forName may not work well in osgi environment
https://issues.apache.org/bugzilla/show_bug.cgi?id=48414 --- Comment #5 from david jencks djen...@apache.org 2010-01-05 11:24:12 UTC --- Created an attachment (id=24799) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=24799) 2nd half of patch to use newSystemInstance for system objects 2nd half of patch -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Problem loading classes with Class.forName() in StandardContext.createWrapper()
I've uploaded a couple patches to https://issues.apache.org/bugzilla/show_bug.cgi?id=48414 with a new newSystemInstance method. I'm not sure why this doesn't need to be in a protected block like much of the code that creates objects for the app, but the original code wasn't in such a block so I'm assuming it's not really needed. thanks david jencks On Jan 5, 2010, at 9:41 AM, David Jencks wrote: On Jan 4, 2010, at 2:56 AM, Mark Thomas wrote: On 04/01/2010 02:46, Tim Whittington wrote: No need to re-post. A ping would have sufficed. We've experienced similar issues integrating lots of third party libraries (Tomcat being one of them) into our OSGi runtime. Thanks for your input. I can't speak for the other Tomcat committers but I know very little about OSGI so it is useful to have input from those more experienced. Essentially this boils down to OSGi liking extension functionality to be provided by instantiation in the providing bundles, and publication using OSGi services. (i.e. pure OSGi services or declarative services etc.). Put another way, the concepts of global application classloaders where Class.forName works (ala Java EE etc.) break down in OSGi. Libraries that use the TCCL in preference to Class.forName help, but in cases like the one you describe where there's no direct invocation from the bundle that has access to the classes it doesn't help. Fragment bundles (and Eclipse specific buddy classloaders) also help, and we've had to use them with tools like Hibernate, but they're less than ideal. I think the conclusion you've reached is correct - either fragment bundles (which is a sub-optimal solution) or a pluggable extension loading framework could be the solution. OK. The consensus amongst those that know OSGI seems to be some form for pluggable extension point. I believe we ran into issues like this when integrating Tomcat 5.5 into our OSGi runtime - we had to patch up the web app ClassLoaders at runtime to make taglib loading work. In that case we were able to wrap the ClassLoaders with the help of some declarative metadata in bundles containing taglibs. If you can tell which bundles can contain implementions of whatever it is you're trying to instantiate, you can construct a ClassLoader spanning those bundles yourself and use that (you'd only want to use it for loading these extensions, as it defeats the purpose/nature of OSGi to some extent to do this). It might be that the web application bundles would be all you need (and the upcoming OSGi Enterprise Spec will give you a standard way of locating these), and that'd probably be a reasonable limitation, or you could accomodate applications partitioned to a finer degree by some additional marker to include other bundles. The other, more OSGi approach would be for listeners to be published as OSGi services with target properties, that are then just looked up by name by the OSGi version of the extension loader (as opposed to instantiating them). i.e. an instance of the Listener interface is published by a bundle as an OSGi service with a property tomcatClassName=org.myproject.impl.MyListener. The extension loader then looks up the service with a property filter on 'tomcatClassName' to find the available extension. OSGi apps using Tomcat would simply publish these using Declarative Services or similar, and this would be a very natural approach for an OSGi app. Using Services does seem more in the spirit of OSGI. With this latter approach you have delightful lifecycle management issues because of the dynamic nature of OSGi (extension bundles starting after the Tomcat bundles for instance). We solve some of these with a combination of declarative only metadata (using the Eclipse Extension Registry) to advertise extension existence on bundle resolution, and Declarative Services to instantiate and publish the actual extension, and some by having the framework accept dynamic injection of extensions (Listeners come and go). Glad I don't have to worry about those issues :) The main purpose of the InstanceManager is meet some of the requirements for annotations support. As such, it is only used for instances that may have annotations. There is one InstanceManager instance per web application. One thing that isn't clear to me is whether the requirement is for an extension point for web application related instances (ie things that in a J2EE environment would be bundled in the WAR) or for container related instances such as LifecycleListeners. The current patch in bug 48414 seems to focussed on Tomcat internals and I don't understand how the line was drawn between what to access via the InstanceManager and what not to. Thanks for taking another look at this subject. I've been thinking of the InstanceManager as the extension point for creating objects by reflection rather than as the annotation handler, perhaps
Re: Problem loading classes with Class.forName() in StandardContext.createWrapper()
On 05/01/2010 17:41, David Jencks wrote: On Jan 4, 2010, at 2:56 AM, Mark Thomas wrote: One thing that isn't clear to me is whether the requirement is for an extension point for web application related instances (ie things that in a J2EE environment would be bundled in the WAR) or for container related instances such as LifecycleListeners. The current patch in bug 48414 seems to focussed on Tomcat internals and I don't understand how the line was drawn between what to access via the InstanceManager and what not to. Thanks for taking another look at this subject. I've been thinking of the InstanceManager as the extension point for creating objects by reflection rather than as the annotation handler, perhaps because of how the Geronimo InstanceManager happens to be implemented. So, it seems to me that adding a newSystemInstance method to it for creating objects that are expected to come from the system rather than application classes is reasonable. I'll try to come up with a patch using this additional method in the next day or two. The new patches make it clear that these are what I called container related instances. In this case the InstanceManager feels like the wrong place to do this. InstanceManagers are per web application and not really intended for container level objects. It is also still not clear why some container objects were selected for this new instantiation method and some not. This seems like something you would want for all container objects, rather than a sub-set. Since these are container objects and the default implementation is to call containerClassLoader.loadClass(className) I started to wonder if the container class loader might not be a better point to implement this integration. Something along the lines of a modified ClassLoaderFactory that returned a ClassLoader instance that new how to look things up via OSGI services and/or other OSGI bundles. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r896193 - in /tomcat/trunk/java/org/apache/catalina: connector/Connector.java mbeans/MBeanUtils.java
Author: markt
Date: Tue Jan 5 19:53:38 2010
New Revision: 896193
URL: http://svn.apache.org/viewvc?rev=896193view=rev
Log:
Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=48424
Based on a patch by Ivan
Ensure that the ObjectNames for the Connectors are always generated using the
same method
Modified:
tomcat/trunk/java/org/apache/catalina/connector/Connector.java
tomcat/trunk/java/org/apache/catalina/mbeans/MBeanUtils.java
Modified: tomcat/trunk/java/org/apache/catalina/connector/Connector.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/Connector.java?rev=896193r1=896192r2=896193view=diff
==
--- tomcat/trunk/java/org/apache/catalina/connector/Connector.java (original)
+++ tomcat/trunk/java/org/apache/catalina/connector/Connector.java Tue Jan 5
19:53:38 2010
@@ -932,14 +932,21 @@
protected ObjectName createObjectName(String domain, String type)
throws MalformedObjectNameException {
-String encodedAddr = null;
-if (getProperty(address) != null) {
-encodedAddr = URLEncoder.encode(getProperty(address).toString());
-}
-String addSuffix = (getProperty(address) == null) ? : ,address=
-+ encodedAddr;
-ObjectName _oname = new ObjectName(domain + :type= + type + ,port=
-+ getPort() + addSuffix);
+Object addressObj = getProperty(address);
+
+StringBuilder sb = new StringBuilder(domain);
+sb.append(:type=);
+sb.append(type);
+sb.append(,port=);
+sb.append(getPort());
+if (addressObj != null) {
+String address = addressObj.toString();
+if (address.length() 0) {
+sb.append(,address=);
+sb.append(ObjectName.quote(address));
+}
+}
+ObjectName _oname = new ObjectName(sb.toString());
return _oname;
}
Modified: tomcat/trunk/java/org/apache/catalina/mbeans/MBeanUtils.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/mbeans/MBeanUtils.java?rev=896193r1=896192r2=896193view=diff
==
--- tomcat/trunk/java/org/apache/catalina/mbeans/MBeanUtils.java (original)
+++ tomcat/trunk/java/org/apache/catalina/mbeans/MBeanUtils.java Tue Jan 5
19:53:38 2010
@@ -461,15 +461,20 @@
ObjectName name = null;
try {
-String address = (String)
-IntrospectionUtils.getProperty(connector, address);
+Object addressObj = IntrospectionUtils.getProperty(connector,
address);
Integer port = (Integer)
IntrospectionUtils.getProperty(connector, port);
+
StringBuilder sb = new StringBuilder(domain);
sb.append(:type=Connector);
-sb.append(,port= + port);
-if ((address != null) (address.length()0)) {
-sb.append(,address= + address);
+sb.append(,port=);
+sb.append(port);
+if (addressObj != null) {
+String address = addressObj.toString();
+if (address.length() 0) {
+sb.append(,address=);
+sb.append(ObjectName.quote(address));
+}
}
name = new ObjectName(sb.toString());
return (name);
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48424] Keep same logic for creating the objectnames for connector mbeans
https://issues.apache.org/bugzilla/show_bug.cgi?id=48424 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Mark Thomas ma...@apache.org 2010-01-05 11:56:55 GMT --- Many thanks for the patch. I applied a variation of it to trunk. The changes I made were: - replaced sb.append(A + B); with sb.append(A); sb.append(B); - re-ordered the code to make it clearer that the code was the same It does seem odd that this code is duplicated but I haven't had a chance to look into it. If you want to look into the duplication feel free to open another bug and attach a patch. Thanks again. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Problem loading classes with Class.forName() in StandardContext.createWrapper()
On 01/05/2010 12:38 PM, Mark Thomas wrote: On 05/01/2010 17:41, David Jencks wrote: On Jan 4, 2010, at 2:56 AM, Mark Thomas wrote: One thing that isn't clear to me is whether the requirement is for an extension point for web application related instances (ie things that in a J2EE environment would be bundled in the WAR) or for container related instances such as LifecycleListeners. The current patch in bug 48414 seems to focussed on Tomcat internals and I don't understand how the line was drawn between what to access via the InstanceManager and what not to. Thanks for taking another look at this subject. I've been thinking of the InstanceManager as the extension point for creating objects by reflection rather than as the annotation handler, perhaps because of how the Geronimo InstanceManager happens to be implemented. So, it seems to me that adding a newSystemInstance method to it for creating objects that are expected to come from the system rather than application classes is reasonable. I'll try to come up with a patch using this additional method in the next day or two. The new patches make it clear that these are what I called container related instances. In this case the InstanceManager feels like the wrong place to do this. InstanceManagers are per web application and not really intended for container level objects. It is also still not clear why some container objects were selected for this new instantiation method and some not. This seems like something you would want for all container objects, rather than a sub-set. Since these are container objects and the default implementation is to call containerClassLoader.loadClass(className) I started to wonder if the container class loader might not be a better point to implement this integration. Something along the lines of a modified ClassLoaderFactory that returned a ClassLoader instance that new how to look things up via OSGI services and/or other OSGI bundles. agree with Mark, just make the common/shared/server class loaders configurable/injectable Filip Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48490] New: Changing a node to stopped in uriworkermap.properties not reflected in jkstatus
https://issues.apache.org/bugzilla/show_bug.cgi?id=48490 Summary: Changing a node to stopped in uriworkermap.properties not reflected in jkstatus Product: Tomcat Connectors Version: 1.2.28 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: mod_jk AssignedTo: dev@tomcat.apache.org ReportedBy: smend...@redhat.com After adding “;stopped=node1,node2” to uriworkermap.properties, Apache behaves as expected – both node1 and node2 stopped getting requests. However, on the JkStatus page, both node1 and node2 still show up as “ACT=Active” instead of “STP=Stopped”. The number of Bad/Stopped workers is 0 instead of 2. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r896214 - in /tomcat/trunk: dist.xml extras.xml
Author: markt
Date: Tue Jan 5 20:56:14 2010
New Revision: 896214
URL: http://svn.apache.org/viewvc?rev=896214view=rev
Log:
Improve JavaDoc generation
Based on the proposed patch for
https://issues.apache.org/bugzilla/show_bug.cgi?id=48299
Also ensure the clean targets clean up fully
Modified:
tomcat/trunk/dist.xml
tomcat/trunk/extras.xml
Modified: tomcat/trunk/dist.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/dist.xml?rev=896214r1=896213r2=896214view=diff
==
--- tomcat/trunk/dist.xml (original)
+++ tomcat/trunk/dist.xml Tue Jan 5 20:56:14 2010
@@ -122,6 +122,7 @@
delete dir=${tomcat.deployer}/
delete dir=${tomcat.dist} failonerror=false/
+delete dir=${tomcat.release} /
!-- This is why releasing must be done on a Windows box:
otherwise this check fails and the .exe distro is not generated --
@@ -197,17 +198,28 @@
/target
+ !-- Classpath --
+ path id=tomcat.classpath
+pathelement location=${jdt.jar}/
+ /path
+
target name=dist-javadoc depends=dist-source
description=Create the Tomcat javadoc
javadoc packagenames=org.apache.*
sourcepath=${tomcat.dist}/src/java
destdir=${tomcat.dist}/webapps/docs/api
- author=true version=true
- windowtitle=Tomcat API Documentation
- doctitle=Tomcat API
- bottom=Copyright amp;#169; 2000-${year} Apache Software Foundation.
All Rights Reserved.
+ version=true
+ windowtitle=Apache Tomcat ${version} API Documentation
+ doctitle=Apache Tomcat ${version} API
+ header=lt;bgt;Apache Tomcat ${version}lt;/bgt;
+ bottom=Copyright amp;#169; 2000-${year} Apache Software Foundation.
All Rights Reserved.
additionalparam=-breakiterator
maxmemory=256m
+ classpath
+path refid=tomcat.classpath/
+path location=${ant.core.lib}/
+ /classpath
+ link href=http://java.sun.com/j2se/1.6.0/docs/api//
/javadoc
/target
Modified: tomcat/trunk/extras.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/extras.xml?rev=896214r1=896213r2=896214view=diff
==
--- tomcat/trunk/extras.xml (original)
+++ tomcat/trunk/extras.xml Tue Jan 5 20:56:14 2010
@@ -92,6 +92,7 @@
target name=clean description=Delete the default output folders
delete dir=${tomcat.extras}/
+delete dir=${tomcat.embed}/
/target
target name=commons-logging depends=prepare
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48299] Add Javadoc target to build file
https://issues.apache.org/bugzilla/show_bug.cgi?id=48299 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Mark Thomas ma...@apache.org 2010-01-05 12:58:11 GMT --- I tweaked the Javadoc target in dist to include your improvements. I couldn't see the benefit in duplicating it in the build,xml file. I confirmed that the dist-javadoc target does work from a clean build. I didn't exclude the web services classes as I'd rather they were included in the javadoc even if the jars aren't available. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 47823] Inconsistent naming of boolean getters in StandardContext
https://issues.apache.org/bugzilla/show_bug.cgi?id=47823 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #2 from Mark Thomas ma...@apache.org 2010-01-05 12:58:56 GMT --- I don't see this changing in the Tomcat 7.0.x timeframe -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r896227 - in /tomcat/trunk/modules/tomcat-lite: java/org/apache/coyote/servlet/ test/org/apache/coyote/servlet/
Author: costin Date: Tue Jan 5 21:28:13 2010 New Revision: 896227 URL: http://svn.apache.org/viewvc?rev=896227view=rev Log: Remove the mini-servlet on top of coyote impl - can be reverted if anyone finds a use for it. Removed: tomcat/trunk/modules/tomcat-lite/java/org/apache/coyote/servlet/BodyReader.java tomcat/trunk/modules/tomcat-lite/java/org/apache/coyote/servlet/BodyWriter.java tomcat/trunk/modules/tomcat-lite/java/org/apache/coyote/servlet/CharsetMapperDefault.properties tomcat/trunk/modules/tomcat-lite/java/org/apache/coyote/servlet/ClientAbortException.java tomcat/trunk/modules/tomcat-lite/java/org/apache/coyote/servlet/Connector.java tomcat/trunk/modules/tomcat-lite/java/org/apache/coyote/servlet/CoyoteConnector.java tomcat/trunk/modules/tomcat-lite/java/org/apache/coyote/servlet/FilterChainImpl.java tomcat/trunk/modules/tomcat-lite/java/org/apache/coyote/servlet/FilterConfigImpl.java tomcat/trunk/modules/tomcat-lite/java/org/apache/coyote/servlet/JspLoader.java tomcat/trunk/modules/tomcat-lite/java/org/apache/coyote/servlet/Locale2Charset.java tomcat/trunk/modules/tomcat-lite/java/org/apache/coyote/servlet/ParameterMap.java tomcat/trunk/modules/tomcat-lite/java/org/apache/coyote/servlet/RequestDispatcherImpl.java tomcat/trunk/modules/tomcat-lite/java/org/apache/coyote/servlet/ServletConfigImpl.java tomcat/trunk/modules/tomcat-lite/java/org/apache/coyote/servlet/ServletContextImpl.java tomcat/trunk/modules/tomcat-lite/java/org/apache/coyote/servlet/ServletInputStreamImpl.java tomcat/trunk/modules/tomcat-lite/java/org/apache/coyote/servlet/ServletOutputStreamImpl.java tomcat/trunk/modules/tomcat-lite/java/org/apache/coyote/servlet/ServletReaderImpl.java tomcat/trunk/modules/tomcat-lite/java/org/apache/coyote/servlet/ServletRequestImpl.java tomcat/trunk/modules/tomcat-lite/java/org/apache/coyote/servlet/ServletRequestWrapperImpl.java tomcat/trunk/modules/tomcat-lite/java/org/apache/coyote/servlet/ServletResponseImpl.java tomcat/trunk/modules/tomcat-lite/java/org/apache/coyote/servlet/ServletResponseIncludeWrapper.java tomcat/trunk/modules/tomcat-lite/java/org/apache/coyote/servlet/ServletWriterImpl.java tomcat/trunk/modules/tomcat-lite/java/org/apache/coyote/servlet/TomcatLite.java tomcat/trunk/modules/tomcat-lite/java/org/apache/coyote/servlet/WebappContextMapper.java tomcat/trunk/modules/tomcat-lite/java/org/apache/coyote/servlet/WebappFilterMapper.java tomcat/trunk/modules/tomcat-lite/java/org/apache/coyote/servlet/WebappServletMapper.java tomcat/trunk/modules/tomcat-lite/java/org/apache/coyote/servlet/config.properties tomcat/trunk/modules/tomcat-lite/test/org/apache/coyote/servlet/ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r896228 - in /tomcat/trunk/modules/tomcat-lite/java/org/apache/tomcat/util: buf/ http/HttpRequest.java http/HttpResponse.java http/MimeMap.java http/mapper/
Author: costin Date: Tue Jan 5 21:28:53 2010 New Revision: 896228 URL: http://svn.apache.org/viewvc?rev=896228view=rev Log: Not used any more ( were part of the mini-servlet on top of coyote ) Removed: tomcat/trunk/modules/tomcat-lite/java/org/apache/tomcat/util/buf/ tomcat/trunk/modules/tomcat-lite/java/org/apache/tomcat/util/http/HttpRequest.java tomcat/trunk/modules/tomcat-lite/java/org/apache/tomcat/util/http/HttpResponse.java tomcat/trunk/modules/tomcat-lite/java/org/apache/tomcat/util/http/MimeMap.java tomcat/trunk/modules/tomcat-lite/java/org/apache/tomcat/util/http/mapper/ - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48489] Tomcat CL doesn't resolve the array classes.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48489 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #8 from Mark Thomas ma...@apache.org 2010-01-05 13:54:40 GMT --- This is a 'feature' of the underlying JDK rather than a Tomcat bug. The workarounds already described should be sufficient. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r896252 - in /tomcat/trunk/webapps/docs/config: ajp.xml http.xml
Author: markt Date: Tue Jan 5 22:34:17 2010 New Revision: 896252 URL: http://svn.apache.org/viewvc?rev=896252view=rev Log: Correct default Modified: tomcat/trunk/webapps/docs/config/ajp.xml tomcat/trunk/webapps/docs/config/http.xml Modified: tomcat/trunk/webapps/docs/config/ajp.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/config/ajp.xml?rev=896252r1=896251r2=896252view=diff == --- tomcat/trunk/webapps/docs/config/ajp.xml (original) +++ tomcat/trunk/webapps/docs/config/ajp.xml Tue Jan 5 22:34:17 2010 @@ -237,7 +237,7 @@ pThe maximum queue length for incoming connection requests when all possible request processing threads are in use. Any requests received when the queue is full will be refused. The default - value is 10./p + value is 100./p /attribute attribute name=bufferSize required=false Modified: tomcat/trunk/webapps/docs/config/http.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/config/http.xml?rev=896252r1=896251r2=896252view=diff == --- tomcat/trunk/webapps/docs/config/http.xml (original) +++ tomcat/trunk/webapps/docs/config/http.xml Tue Jan 5 22:34:17 2010 @@ -249,7 +249,7 @@ pThe maximum queue length for incoming connection requests when all possible request processing threads are in use. Any requests received when the queue is full will be refused. The default - value is 10./p + value is 100./p /attribute attribute name=address required=false - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r896253 - /tomcat/tc6.0.x/trunk/webapps/docs/config/http.xml
Author: markt Date: Tue Jan 5 22:35:06 2010 New Revision: 896253 URL: http://svn.apache.org/viewvc?rev=896253view=rev Log: Correct default Modified: tomcat/tc6.0.x/trunk/webapps/docs/config/http.xml Modified: tomcat/tc6.0.x/trunk/webapps/docs/config/http.xml URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/config/http.xml?rev=896253r1=896252r2=896253view=diff == --- tomcat/tc6.0.x/trunk/webapps/docs/config/http.xml (original) +++ tomcat/tc6.0.x/trunk/webapps/docs/config/http.xml Tue Jan 5 22:35:06 2010 @@ -241,7 +241,7 @@ pThe maximum queue length for incoming connection requests when all possible request processing threads are in use. Any requests received when the queue is full will be refused. The default - value is 10./p + value is 100./p /attribute attribute name=address required=false - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r896254 - /tomcat/tc6.0.x/trunk/webapps/docs/config/ajp.xml
Author: markt Date: Tue Jan 5 22:36:03 2010 New Revision: 896254 URL: http://svn.apache.org/viewvc?rev=896254view=rev Log: Correct default Modified: tomcat/tc6.0.x/trunk/webapps/docs/config/ajp.xml Modified: tomcat/tc6.0.x/trunk/webapps/docs/config/ajp.xml URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/config/ajp.xml?rev=896254r1=896253r2=896254view=diff == --- tomcat/tc6.0.x/trunk/webapps/docs/config/ajp.xml (original) +++ tomcat/tc6.0.x/trunk/webapps/docs/config/ajp.xml Tue Jan 5 22:36:03 2010 @@ -236,7 +236,7 @@ pThe maximum queue length for incoming connection requests when all possible request processing threads are in use. Any requests received when the queue is full will be refused. The default - value is 10./p + value is 100./p /attribute attribute name=bufferSize required=false - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48488] accepCount does not limit connections
https://issues.apache.org/bugzilla/show_bug.cgi?id=48488 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #1 from Mark Thomas ma...@apache.org 2010-01-05 14:44:16 GMT --- This works as expected for me. It may be your test environment isn't doing what you think it is. If you need help resolving this, please use the Tomcat users list. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat Native 1.1.19
2010/1/5 Mladen Turk mt...@apache.org: Hi, Native 1.1.19 is available for testing. Compared with 1.1.18 It has minor versioning fix and allows building against OpenSSL 1.0 (well Rainer beat me before the tag :) If you want to take a look, the final source distribution can be downloaded from: http://tomcat.apache.org/dev/dist/tomcat-connectors/native/source/1.1.19 (until synced the builds are available at) http://people.apache.org/~mturk/native/source/1.1.19 Win32/Win64 binaries will be available at: http://tomcat.apache.org/dev/dist/tomcat-connectors/native/binaries/ So here's the vote. It will be closed in about 72 hours (or sooner if enough votes are encountered) Apache Tomcat Native 1.1.19 is: [ ] Stable - no major issues, no regressions [ ] Beta - at least one significant issue -- tell us what it is [ ] Alpha - multiple significant issues -- tell us what they are Regards -- ^TM I see that the Windows binaries are built with OpenSSL 0.9.8k: ( 1) openssl.exe version prints that number, 2) looking for 0.9.8 string inside the DLLs I see that number.) Wasn't it supposed to be 0.9.8l ? OpenSSL changelog; http://openssl.org/news/changelog.html Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Tomcat-Lite update
Hi, I'm still working on lite - right now my primary goal is to finish the connector, and have it usable as part of tomcat7, along with nio and apr connectors. The lite connector is based on nio ( could support apr as well ), but is intended to be directly usable by users - it supports both client and server modes, and instead of coyote it has an API that is very similar with the servlet API - i.e all methods plus setters for use in client mode. I gave up on implementing the 3.0 servlet spec - tomcat-lite will only support running a subset of the servlet API, for anything else ( and to pass the TCK ) will use the full tomcat. The 'servlet' part will just be a small wrapper on top of the connector - I don't want the connector to depend on the servlet API , so it can be used as a http client without requiring the servlet jars, and to avoid any compatibility requirements. As features of the connector: - the low level layer is refactored: instead of a growing ByteBuffer for IO it uses a list of buffers ( avoids copy ), uses NIO for charset conversions instead of the former hack, etc. It is also much closer to apache2 bucket brigades. - instead of coyote, it uses an API that is based on servlet, with the addition of the missing getter/setter or pair APIs, for example Request.setParameter(), Response.getInputStream(), etc. The idea is to allow people to easily port servlets, and to use a familiar API in client mode - it is possible to write handlers that run in the IO thread ( like the http proxy ) - while most of the code is originally copied from the existing connectors, a lot has been changed to make it easier to test and use ( or so I hope ). I also added a SPDY implementation - this is a binary protocol, similar with JK - it is supported by chrome browser ( with some flags ). My goal was to try out the low-level layer - and to evaluate the protocol. We keep discussion JK replacements - this is one option, and I guess having the code to try it out wouldn't hurt. The nice thing about SPDY (compared with JK and http ) is that it's multiplexing requests - while JK and http are blocking, one TCP connection can't be used for multiple forwarded http requests. There is also a header compression option - I haven't done any load tests to see how much it hurts/helps. On the help part - obviously review and testing are the biggest needs. Assuming people are comfortable with a 4th connector - there are a lot of options that need to be ported, the code currently supports only the basic requests. Still missing ( and in need of help ): - compression ( I'm getting close ) - connection management ( working on it ) - sorting out the options in nio/apr and implement them - make sure all servlet methods work in reverse ( for example HttpRequest.setParameter(), HttpResponse.getInputStream(), etc ). Also, I would like to know if other comitters are OK with (temporarily - i.e. until the 7.0 release vote) including lite in the tomcat7 builds, so people can try it out. I would like to have it in common/, so it is visible in servlets - as I mentioned one of the goals is for tomcat-lite to be more of a library that is used for client http, include filters/servlets that can be used in any container, etc. When 7.0 is ready we can remove it or include it if you feel it's ready. Costin
[Tomcat Wiki] Trivial Update of PoweredBy by Leandro de Oliveira
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Tomcat Wiki for change
notification.
The PoweredBy page has been changed by Leandro de Oliveira.
The comment on this change is: includes a brazilian main webhost.
http://wiki.apache.org/tomcat/PoweredBy?action=diffrev1=216rev2=217
--
[[http://www.springsource.com|{{http://www.springframework.org/sites/all/themes/zen/framework/logo.png}}]]
[[http://www.springsource.com/|SpringSource]] Enterprise Ready Server™ (ERS)
is the most comprehensive and widely distributed solution for Apache Web and
Tomcat Application Server management. ERS provides better performance and
security and improves service quality, reliability and scalability by uniquely
enhancing Apache and Tomcat for enterprise use while reducing the costs and
complexity of sophisticated Web infrastructures. Includes multiple versions of
Apache Tomcat. To
download[[http://www.springsource.com/products/ers/apachedownloads]]
+ = KingHost =
+ {{http://www.starhost.com.br/imagens/estrutura/logo_starhost.jpg}}
+ [[http://www.starhost.com.br/|Starhost - Hospedagem de Sites]] I
+
= Strabag SE - BRVZ Gmbh IT =
{{http://strabag.com/databases/internet/_public/files.nsf/SearchView/2E133A2B6711E2E1C125736A003AB086/$File/STRABAG-SE-logo.gif}}
[[http://www.strabag.com|Strabag SE - BRVZ Gmbh IT]] - BRVZ Gmbh IT is the IT
service provider of the Strabag Societas Europea building company. A lot of
internal services are running on 70+ Tomcat instances.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Trivial Update of PoweredBy by Leandro de Oliveira
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Tomcat Wiki for change
notification.
The PoweredBy page has been changed by Leandro de Oliveira.
The comment on this change is: includes a brazilian main webhost.
http://wiki.apache.org/tomcat/PoweredBy?action=diffrev1=217rev2=218
--
[[http://www.springsource.com|{{http://www.springframework.org/sites/all/themes/zen/framework/logo.png}}]]
[[http://www.springsource.com/|SpringSource]] Enterprise Ready Server™ (ERS)
is the most comprehensive and widely distributed solution for Apache Web and
Tomcat Application Server management. ERS provides better performance and
security and improves service quality, reliability and scalability by uniquely
enhancing Apache and Tomcat for enterprise use while reducing the costs and
complexity of sophisticated Web infrastructures. Includes multiple versions of
Apache Tomcat. To
download[[http://www.springsource.com/products/ers/apachedownloads]]
- = KingHost =
+ = Starhost =
{{http://www.starhost.com.br/imagens/estrutura/logo_starhost.jpg}}
- [[http://www.starhost.com.br/|Starhost - Hospedagem de Sites]] I
+ [[http://www.starhost.com.br/|Starhost - Hospedagem de Sites]] Brazilian
webhost provides JSP/Servlets support using Tomcat 5.0, 5.5 and 6.0.
+
= Strabag SE - BRVZ Gmbh IT =
{{http://strabag.com/databases/internet/_public/files.nsf/SearchView/2E133A2B6711E2E1C125736A003AB086/$File/STRABAG-SE-logo.gif}}
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [PROPOSAL] Log rotation in Tomcat Connector
For consistency (with Apache at least) I've gone down the road of mirroring the
functionality of rotatelogs, which was fairly easy.
I'm doing some long running tests (I'm seeing some weird DLL unloading/crashing
behaviour in IIS 5.1 that I want to replicate and account for), but if that
works out I'll port the changes to trunk (I'm developing on JK_1_2_28 at the
moment for some reason) and submit a patch.
The downside of the rotatelogs approach is that it's not easy to do log pruning
(since the filenames are based on the time the log rotates, rather than some
kind of backup suffix scheme), so I may do nothing about that for now - the
best I could do is keep a list in memory and prune, which is sub-optimal.
cheers
tim
- Original Message -
From: Rainer Jung rainer.j...@kippdata.de
To: Tomcat Developers List dev@tomcat.apache.org
Sent: Saturday, 19 December, 2009 1:01:53 AM GMT +12:00 New Zealand
Subject: Re: [PROPOSAL] Log rotation in Tomcat Connector
Hi Tim,
On 18.12.2009 03:26, Tim Whittington wrote:
Hi all
We're experiencing issues with the Tomcat Connector log in some IIS
production sites where the log file grows to a very large size (8GB on one
site).
This is almost entirely due to connection errors between the front end and
back end produced when the back-end Tomcat is restarted after crashes or for
maintenance.
(we have some very high request volume sites - some with hundreds of
concurrent requests -, so you can get thousands of these errors on each
restart).
I'm thinking about implementing log file rotation in the IIS connector as a
solution to this, and wanted to canvas opinions on alternatives and
implementation first.
Good thing, that was open for a long time for the isapi redirector.
What I intend implementing is:
* Daily log file rolling (not configurable) as a clone of the log_to_file
function (check rotation, close and reopen log file, continue)
* Very simple configuration for a daily rolling file appender - basically
'on/off' and 'number of days to keep', possibly a single rotateable=bool/int
parameter.
* The log file name suffix will be appended/inserted to the name of the file
specified in the connector config with a static pattern e.g. _MM_dd
* The log method(s) will be guarded with a mutex to protect the rollover
operation
* I'll only be doing this for the ISAPI redirector at present (so won't need
to refactor jk_mt.h to make the locking primitives available on prefork
builds)
* On rollover, the file will be closed and a new one opened. Older files will
be pruned.
* Rollover checking can be a simple mod operation on the timestamp (since I'm
not intending to handle log formats)
Questions I have:
* Short of silencing the logging, is there an alternative to rolling the
file? (perhaps rolling up of repeated connection errors?)
* Are there any performance concerns about using a mutex on each log? (log4c
uses this approach, so I presume it's not prohibitive)
* Does anyone have any other input into config/behaviour?
Mutex
=
- log rotation for mod_jk with Apache is done using an external process
and logging through a pipe. The external process often used with Apache
is rotatelogs, that comes with apache and thus is also available under
ASL 2.0
- log path for Apache should not change seriously, e.g. no additional
mutex when running mod_jk inside Apache.
- for the redirector I'd say adding a mutex is OK, if it is acquired
after the log line has been formatted and immediately before the line
gets written to the file. So you'll only lock the access to the file.
In apache-2.0/mod_jk.c you will find for example jk_log_to_file(), which
does
rv = apr_global_mutex_lock(jk_log_lock);
if (rv != APR_SUCCESS) {
... log error via Apache ...
}
rv = apr_file_write(p-jklogfp, what, wrote);
if (rv != APR_SUCCESS) {
... log error via Apache ...
}
rv = apr_global_mutex_unlock(jk_log_lock);
if (rv != APR_SUCCESS) {
... log error via Apache ...
}
Rolling
===
You could also think about doing the rolling externally like we do with
Apache and pipes in case the user configured a pipe as the log file. I'm
not sure about ISAPI and the IIS process management, whether this is
feasable, e.g. all IIS processes sharing the file descriptor to the pipe
etc.
Apart from that I think having a simple daily solution, which can be
activated or deactivated would already be a very useful start. We can
always add more features, once the basics are there. Obvious possible
extensions are more fine grained rolling intervals, alternatively basing
the rolling on file size, flexible file name pattern, etc.
Pruning
===
I'm not a big fan of pruning the old files directly from the server
process. I'd say pruning is part of some external log file management,
which usually does compression, transferral to a log server and removing
old files once they are old enough or
DO NOT REPLY [Bug 48489] Tomcat CL doesn't resolve the array classes.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48489 VickyKak kakvi...@yahoo.co.in changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #9 from VickyKak kakvi...@yahoo.co.in 2010-01-05 19:50:39 UTC --- (In reply to comment #8) This is a 'feature' of the underlying JDK rather than a Tomcat bug. The workarounds already described should be sufficient. Could you please explain in detail why don't you think it is an issue with the TomcatCL implementation? What workaround you are referring to, enabling -Dsun.lang.ClassLoader.allowArraySyntax=true does not help as I tried it even though it does not make sense to me. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48489] Tomcat CL doesn't resolve the array classes.
https://issues.apache.org/bugzilla/show_bug.cgi?id=48489 VickyKak kakvi...@yahoo.co.in changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat Native 1.1.19
On 01/06/2010 01:21 AM, Konstantin Kolinko wrote: 2010/1/5 Mladen Turkmt...@apache.org: Hi, Native 1.1.19 is available for testing. Compared with 1.1.18 It has minor versioning fix and allows building against OpenSSL 1.0 (well Rainer beat me before the tag :) If you want to take a look, the final source distribution can be downloaded from: http://tomcat.apache.org/dev/dist/tomcat-connectors/native/source/1.1.19 (until synced the builds are available at) http://people.apache.org/~mturk/native/source/1.1.19 Win32/Win64 binaries will be available at: http://tomcat.apache.org/dev/dist/tomcat-connectors/native/binaries/ So here's the vote. It will be closed in about 72 hours (or sooner if enough votes are encountered) Apache Tomcat Native 1.1.19 is: [ ] Stable - no major issues, no regressions [ ] Beta - at least one significant issue -- tell us what it is [ ] Alpha - multiple significant issues -- tell us what they are Regards -- ^TM I see that the Windows binaries are built with OpenSSL 0.9.8k: ( 1) openssl.exe version prints that number, 2) looking for 0.9.8 string inside the DLLs I see that number.) Wasn't it supposed to be 0.9.8l ? Nope. 0.9.8l is broken, so we switched back to 0.9.8k You might check the OpenSSL dev archive (and our own about that subject) We have a patch in 1.1.18 that fully covers the CVE-2009-3955 like in mod_ssl. Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat Native 1.1.19
On 01/06/2010 07:47 AM, Mladen Turk wrote: On 01/06/2010 01:21 AM, Konstantin Kolinko wrote: 2010/1/5 Mladen Turkmt...@apache.org: Hi, Native 1.1.19 is available for testing. Compared with 1.1.18 It has minor versioning fix and allows building against OpenSSL 1.0 (well Rainer beat me before the tag :) If you want to take a look, the final source distribution can be downloaded from: http://tomcat.apache.org/dev/dist/tomcat-connectors/native/source/1.1.19 (until synced the builds are available at) http://people.apache.org/~mturk/native/source/1.1.19 Win32/Win64 binaries will be available at: http://tomcat.apache.org/dev/dist/tomcat-connectors/native/binaries/ So here's the vote. It will be closed in about 72 hours (or sooner if enough votes are encountered) Apache Tomcat Native 1.1.19 is: [ ] Stable - no major issues, no regressions [ ] Beta - at least one significant issue -- tell us what it is [ ] Alpha - multiple significant issues -- tell us what they are Regards -- ^TM I see that the Windows binaries are built with OpenSSL 0.9.8k: ( 1) openssl.exe version prints that number, 2) looking for 0.9.8 string inside the DLLs I see that number.) Wasn't it supposed to be 0.9.8l ? Nope. 0.9.8l is broken, so we switched back to 0.9.8k You might check the OpenSSL dev archive (and our own about that subject) We have a patch in 1.1.18 that fully Fully... Well it is allow server initiated renegociation like in mod_ssl. Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
