svn commit: r803794 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: kkolinko Date: Thu Aug 13 06:45:11 2009 New Revision: 803794 URL: http://svn.apache.org/viewvc?rev=803794view=rev Log: veto, vote and proposal Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=803794r1=803793r2=803794view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Thu Aug 13 06:45:11 2009 @@ -46,6 +46,17 @@ -0: fhanik - the bug talks about WEB-INF/lib and reload, that would be when reload=true which should be considered development only So to make this bug actually worth while fixing, and not impact performance, then it should only do this check on files that are relevant to the reload of an application, in other words a watched resource + -1: kkolinko: ( + FileDirContext#file() contains a check that file.canRead() is true. + A side-effect of this patch will be that files that are not readable + will be excluded from the enumeration provided by FileDirContext#list() + or FileDirContext#listBindings(). + I think that it is wrong. If file is not readable it should result in error 404 + or something like that. + + Thus, we have to revert this change in trunk. + I am proposing an alternative patch for bug 45403 below. + ) * Backport cleanup of semantics of thisAccessedTime and lastAccessedTime for sessions: @@ -187,8 +198,9 @@ * Improve build.properties comment in ant build files. Backport from trunk. http://svn.apache.org/viewvc?rev=797425view=rev - +1: rjung + +1: rjung, kkolinko -1: + kkolinko: Comments are documentation, and thus RTC. * Port Active Directory improvements to JNDIREalm from trunk Patch testing successfully by willing volunteer on the users list @@ -274,3 +286,14 @@ https://issues.apache.org/bugzilla/attachment.cgi?id=24125 +1: markt -1: + +* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=45403 + Add a check when enumerating jar files, and + do not suppress IO errors when starting a web application. + Note: +- I cannot test bug 45403 on Windows, as it is Un*x-specific +- tested in normal operation, with unpackWARs = true and false +- this has not yet been applied to trunk + http://people.apache.org/~kkolinko/patches/2009-08-13_bug45403-tc6.patch + +1: kkolinko + -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Tomcat Wiki] Update of SummerOfCode2009/LoadingFilterConfiguration by xxd82329
Dear Wiki user, You have subscribed to a wiki page or wiki category on Tomcat Wiki for change notification. The following page has been changed by xxd82329: http://wiki.apache.org/tomcat/SummerOfCode2009/LoadingFilterConfiguration -- pros: keep consistent with the Servlet specification. And maybe least source code that need to write. - cons: the global conf/web.xml file is rather long now. Scrolling this file and adding or altering it could become a burden to developer to some degree. + cons: the global conf/web.xml file is rather long now. Scrolling this file and adding or altering it could become a burden to developer to some degree. And I think those additional parameters harms the portability to some degree. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: DO NOT REPLY [Bug 47655] NullPointerException in MimeHeaders
Hi Mark, I've implemented Axis2 Web Services in Tomcat 5.5.26 and at times of high load (when there are several web service client requests coming in to Tomcat), Tomcat starts throwing following NPE: java.lang.NullPointerException at org.apache.tomcat.util.http.MimeHeaders.clear(MimeHeaders.java:130) Is there a solution for the above exception? N.B.: I tried deploying my Axis2 code on Tomcat 6.0.20 and observed that these NPE do occur but with less frequency. Any help on this will be appreciated. -Nikhil ___ https://issues.apache.org/bugzilla/show_bug.cgi?id=47655 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #4 from Mark Thomas ma...@apache.org 2009-08-06 23:14:17 BST --- That looks very much like the application is holding onto a copy of the response object and trying to use it when Tomcat thinks the request is complete and has recycled the response object for use with a following request. Try setting the system property: org.apache.catalina.connector.RECYCLE_FACADES=true This forces the facades to be recycled more thoroughly. You'll probably still see NPEs but they should occur where a request/response is used in an invalid manner. -- View this message in context: http://www.nabble.com/DO-NOT-REPLY--Bug-47655--New%3A-NullPointerException-in-MimeHeaders-tp24847819p24949709.html Sent from the Tomcat - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
About the place to put the configuration of Converted Filters from Valves ------ GSoC2009
Hello, Dear all, In GSoC2009 project, we've got a design decision to make. Could you please take some time to go over this wiki page : http://wiki.apache.org/tomcat/SummerOfCode2009/LoadingFilterConfiguration?action=show, and give me your opinion? Thank you very much. -- Sincerely yours and Best Regards, Xie Xiaodong
NullPointerException - org.apache.tomcat.util.http.MimeHeaders.clear(MimeHeaders.java:130)
Hi, I've implemented Axis2 Web Services in Tomcat 5.5.26 and at times of high load (when there are several web service client requests coming in to Tomcat), Tomcat starts throwing following NPE: java.lang.NullPointerException at org.apache.tomcat.util.http.MimeHeaders.clear(MimeHeaders.java:130) Is there a solution for the above exception? N.B.: I tried setting the system property ... org.apache.catalina.connector.RECYCLE_FACADES=true ... in vain. Also I tried deploying my Axis2 code on Tomcat 6.0.20 and observed that these NPE do occur but with less frequency. Any help on this will be appreciated. -Nikhil -- View this message in context: http://www.nabble.com/NullPointerException---org.apache.tomcat.util.http.MimeHeaders.clear%28MimeHeaders.java%3A130%29-tp24950134p24950134.html Sent from the Tomcat - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r803803 - /tomcat/native/trunk/native/build/tcnative.m4
Author: jfclere
Date: Thu Aug 13 07:58:04 2009
New Revision: 803803
URL: http://svn.apache.org/viewvc?rev=803803view=rev
Log:
Add detection of the macosx jvm.
BTW: Where r801544 was going...
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=803803r1=803802r2=803803view=diff
==
--- tomcat/native/trunk/native/build/tcnative.m4 (original)
+++ tomcat/native/trunk/native/build/tcnative.m4 Thu Aug 13 07:58:04 2009
@@ -117,13 +117,13 @@
# JAVA_PLATFORM
AC_MSG_CHECKING([Try to guess JDK location])
- for JAVA_PREFIX in /usr/local /usr/local/lib /usr /usr/lib /opt
/usr/java ; do
+ for JAVA_PREFIX in /usr/local /usr/local/lib /usr /usr/lib /opt
/usr/java /System/Library/Frameworks/JavaVM.framework/Versions/ ; do
for JAVA_PLATFORM in 6 5 4 3 2 ; do
- for subversion in .9 .8 .7 .6 .5 .4 .3 .2 .1 ; do
+ for subversion in .9 .8 .7 .6 .5 .4 .3 .2 .1 .0 ; do
-for VARIANT in IBMJava2- java java- jdk jdk-; do
+for VARIANT in IBMJava2- java java- jdk jdk- ; do
GUESS=${JAVA_PREFIX}/${VARIANT}1.${JAVA_PLATFORM}${subversion}
dnl AC_MSG_CHECKING([${GUESS}])
if test -d ${GUESS}/bin test -d ${GUESS}/include ; then
@@ -131,6 +131,11 @@
AC_MSG_RESULT([${GUESS}])
break
fi
+ if test -d ${GUESS}/Commands test -d ${GUESS}/Headers ;
then
+JAVA_HOME=${GUESS}
+AC_MSG_RESULT([${GUESS}])
+break
+ fi
done
if test -n ${JAVA_HOME} ; then
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Taglibs SVN migration to Tomcat
Post discussion between Tomcat PMC and Jakarta PMC (with myself as the go between), the Jakarta Taglibs subproject is going to move over to Tomcat land. Chiefly this means: * The JSTL implementations: 1.0, 1.1 and unreleased 1.2. * RDC Taglib. * An in development 'extended' taglib. The Jakarta Taglibs site will become a Retired page, and move into the Attic once a few remaining bits of code have been picked over for the extended taglib. A year or so. I'd like to do the SVN move, dev@ permitting. This would mean something like the following in the ASF public repo: tomcat/ taglibs/ standard/ tags/ branches/ trunk/ extended/ tags/ (empty) branches/ (empty) trunk/ rdc/ tags/ branches/ (empty) trunk/ site/ [subsite - tomcat.apache.org/taglibs/] taglibs-parent/ [maven parent pom] The tags and branches are generally historical in that they're hard to build directly as there are missing parent build.xml and common.xml files. Trunk uses Maven 2 as its build system. If a JSTL 1.0 or JSTL 1.1 bugfix is needed, then migrating them to Maven2 or fixing their build systems are options. Tomcat svn karma would be given to bayard, kris + rahul. Mailing lists - I'm thinking of moving the taglibs-user@ list from Jakarta to Tomcat while killing the taglibs-dev list in favour of d...@tomcat. Anyway - all open to discussion + debate; let me know what works best from this list's point of view. Hen - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
about setLoopbackMode of McastServiceImpl of tomcat tribes
Hi. I use tomcat tribes to develop my application resently, and I find this line in the source code of the class, org.apache.catalina.tribes.membership.McastServiceImpl, at line 202 (I use apache-tomcat-6.0.20 source code): socket.setLoopbackMode(true);//hint that we don't need loop back messages I think it is better to setLoopbackMode through a construtor's argument or a property. Because I really need debug my program on my single development PC sometimes, or need to run two process of my application to get higher availability. BTW, I think sun's naming way is ugly, about socket.setLoopbackMode at least. When I see this line, I really think it is to enable socket's LoopbackMode if no the following comment, but actually the name of the parameter needed by setLoopbackMode is disable. thanks. -- Jeff Yang - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Taglibs SVN migration to Tomcat
On 08/13/2009 10:48 AM, Henri Yandell wrote: Post discussion between Tomcat PMC and Jakarta PMC (with myself as the go between), the Jakarta Taglibs subproject is going to move over to Tomcat land. Chiefly this means: * The JSTL implementations: 1.0, 1.1 and unreleased 1.2. * RDC Taglib. * An in development 'extended' taglib. The Jakarta Taglibs site will become a Retired page, and move into the Attic once a few remaining bits of code have been picked over for the extended taglib. A year or so. I'd like to do the SVN move, dev@ permitting. This would mean something like the following in the ASF public repo: tomcat/ taglibs/ standard/ tags/ branches/ trunk/ extended/ tags/ (empty) branches/ (empty) trunk/ rdc/ tags/ branches/ (empty) trunk/ site/ [subsite - tomcat.apache.org/taglibs/] taglibs-parent/ [maven parent pom] The tags and branches are generally historical in that they're hard to build directly as there are missing parent build.xml and common.xml files. Trunk uses Maven 2 as its build system. If a JSTL 1.0 or JSTL 1.1 bugfix is needed, then migrating them to Maven2 or fixing their build systems are options. Tomcat svn karma would be given to bayard, kris + rahul. Mailing lists - I'm thinking of moving the taglibs-user@ list from Jakarta to Tomcat while killing the taglibs-dev list in favour of d...@tomcat. Anyway - all open to discussion + debate; let me know what works best from this list's point of view. +1 Cheers Jean-Frederic Hen - 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: NullPointerException - org.apache.tomcat.util.http.MimeHeaders.clear(MimeHeaders.java:130)
Rastogi Nikhil wrote: Hi, I've implemented Axis2 Web Services in Tomcat 5.5.26 and at times of high load (when there are several web service client requests coming in to Tomcat), Tomcat starts throwing following NPE: java.lang.NullPointerException at org.apache.tomcat.util.http.MimeHeaders.clear(MimeHeaders.java:130) Is there a solution for the above exception? N.B.: I tried setting the system property ... org.apache.catalina.connector.RECYCLE_FACADES=true ... in vain. Also I tried deploying my Axis2 code on Tomcat 6.0.20 and observed that these NPE do occur but with less frequency. Any help on this will be appreciated. This is a question for the users list. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Taglibs SVN migration to Tomcat
Henri Yandell wrote: Post discussion between Tomcat PMC and Jakarta PMC (with myself as the go between), the Jakarta Taglibs subproject is going to move over to Tomcat land. Chiefly this means: snip/ site/ [subsite - tomcat.apache.org/taglibs/] snip/ Anyway - all open to discussion + debate; let me know what works best from this list's point of view. +1 Longer term, it might be worth merging the taglibs site into the main tomcat site. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Taglibs SVN migration to Tomcat
+1 welcome aboard, Filip On 08/13/2009 02:48 AM, Henri Yandell wrote: Post discussion between Tomcat PMC and Jakarta PMC (with myself as the go between), the Jakarta Taglibs subproject is going to move over to Tomcat land. Chiefly this means: * The JSTL implementations: 1.0, 1.1 and unreleased 1.2. * RDC Taglib. * An in development 'extended' taglib. The Jakarta Taglibs site will become a Retired page, and move into the Attic once a few remaining bits of code have been picked over for the extended taglib. A year or so. I'd like to do the SVN move, dev@ permitting. This would mean something like the following in the ASF public repo: tomcat/ taglibs/ standard/ tags/ branches/ trunk/ extended/ tags/ (empty) branches/ (empty) trunk/ rdc/ tags/ branches/ (empty) trunk/ site/ [subsite - tomcat.apache.org/taglibs/] taglibs-parent/ [maven parent pom] The tags and branches are generally historical in that they're hard to build directly as there are missing parent build.xml and common.xml files. Trunk uses Maven 2 as its build system. If a JSTL 1.0 or JSTL 1.1 bugfix is needed, then migrating them to Maven2 or fixing their build systems are options. Tomcat svn karma would be given to bayard, kris + rahul. Mailing lists - I'm thinking of moving the taglibs-user@ list from Jakarta to Tomcat while killing the taglibs-dev list in favour of d...@tomcat. Anyway - all open to discussion + debate; let me know what works best from this list's point of view. Hen - 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: r803951 - in /tomcat: tc5.5.x/trunk/STATUS.txt tc6.0.x/trunk/STATUS.txt
Author: kkolinko Date: Thu Aug 13 17:20:27 2009 New Revision: 803951 URL: http://svn.apache.org/viewvc?rev=803951view=rev Log: vote Modified: tomcat/tc5.5.x/trunk/STATUS.txt tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc5.5.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc5.5.x/trunk/STATUS.txt?rev=803951r1=803950r2=803951view=diff == --- tomcat/tc5.5.x/trunk/STATUS.txt (original) +++ tomcat/tc5.5.x/trunk/STATUS.txt Thu Aug 13 17:20:27 2009 @@ -80,7 +80,7 @@ * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=41824 Need to use canonical rather than binary form when writing code http://svn.apache.org/viewvc?rev=797607view=rev - +1: markt, rjung + +1: markt, rjung, kkolinko -1: * Improve build.properties comment in ant build files. Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=803951r1=803950r2=803951view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Thu Aug 13 17:20:27 2009 @@ -192,7 +192,7 @@ * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=41824 Need to use canonical rather than binary form when writing code http://svn.apache.org/viewvc?rev=797607view=rev - +1: markt, rjung + +1: markt, rjung, kkolinko -1: * Improve build.properties comment in ant build files. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Taglibs SVN migration to Tomcat
On Thu, Aug 13, 2009 at 4:48 AM, Henri Yandellflame...@gmail.com wrote: Post discussion between Tomcat PMC and Jakarta PMC (with myself as the go between), the Jakarta Taglibs subproject is going to move over to Tomcat land. Chiefly this means: * The JSTL implementations: 1.0, 1.1 and unreleased 1.2. * RDC Taglib. * An in development 'extended' taglib. snip/ All looks good -- thanks for CC'ing me, but you don't have to (I've been subscribed to Tomcat dev + user for many years now). -Rahul - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Making AJP secret attribute consistent
Other option is to use required.secret instead requiredSecret Much easier because requiredSecret isn't document, so one can only find it browsing the source code. However dunno how to make it using current property set/get methods I have just noticed - the following patch (as currently proposed for tc6.0) is an example of implementing such a dot property (socket.unlockTimeout): * Improve NIO connector shutdown time by doing shutdowns in parallel and with a timeout http://svn.apache.org/viewvc?view=revrevision=791914 I have not dug into details yet, though. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Taglibs SVN migration to Tomcat
And I just added myself back in, but with my employer-independent email... On Thu, Aug 13, 2009 at 1:37 PM, Rahul Akolkarrahul.akol...@gmail.com wrote: On Thu, Aug 13, 2009 at 4:48 AM, Henri Yandellflame...@gmail.com wrote: Post discussion between Tomcat PMC and Jakarta PMC (with myself as the go between), the Jakarta Taglibs subproject is going to move over to Tomcat land. Chiefly this means: * The JSTL implementations: 1.0, 1.1 and unreleased 1.2. * RDC Taglib. * An in development 'extended' taglib. snip/ All looks good -- thanks for CC'ing me, but you don't have to (I've been subscribed to Tomcat dev + user for many years now). -Rahul -- Kris Schneider - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Making AJP secret attribute consistent
On 13/08/09 19:43, Konstantin Kolinko wrote: Other option is to use required.secret instead requiredSecret Much easier because requiredSecret isn't document, so one can only find it browsing the source code. However dunno how to make it using current property set/get methods I have just noticed - the following patch (as currently proposed for tc6.0) is an example of implementing such a dot property (socket.unlockTimeout): * Improve NIO connector shutdown time by doing shutdowns in parallel and with a timeout http://svn.apache.org/viewvc?view=revrevision=791914 I have not dug into details yet, though. It looks like magic ;) I always thought that setName(...) reflects name=..., now it seems it's possible to have setName(...) and socket.name=... Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[proposal] remove worker based connector thread pools in trunk
Here is why I think its good
1. Current pools can't shrink, so when peak has been hit, that's where
were at
2. Current pools are unfair, synchronized (workers) { workers.wait() },
executors are a bit more fair since they only hold a lock for a short period
3. Reduce duplicate code
4. Executors provide more flexibility
5. I have not found a performance difference anymore
6. Async implementation becomes much easier, since
AsyncContext.dispatch() is easily handed off to an executor and
releasing application thread. Otherwise we have to add an executor on
top of the existing thread pool, which is doable, just not pragmatic
best
Filip
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Making AJP secret attribute consistent
On 13.08.2009 20:31, Mladen Turk wrote: On 13/08/09 19:43, Konstantin Kolinko wrote: Other option is to use required.secret instead requiredSecret Much easier because requiredSecret isn't document, so one can only find it browsing the source code. However dunno how to make it using current property set/get methods I have just noticed - the following patch (as currently proposed for tc6.0) is an example of implementing such a dot property (socket.unlockTimeout): * Improve NIO connector shutdown time by doing shutdowns in parallel and with a timeout http://svn.apache.org/viewvc?view=revrevision=791914 I have not dug into details yet, though. It looks like magic ;) I always thought that setName(...) reflects name=..., now it seems it's possible to have setName(...) and socket.name=... A similar feature is used in the cluster. The cluster configuration has elements for the Cluster, Membership, Sender and Receiver, but not e.g. for the Manager. If you want to set property xxx on the cluster manager, you can configure manager.xxx inside the Cluster element. So the part before the dot should express some kind of related class the param should be passed to. That would be true for request.secret, but not for required.secret. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r804057 - /tomcat/trunk/java/org/apache/catalina/ha/session/DeltaSession.java
Author: fhanik
Date: Thu Aug 13 23:10:40 2009
New Revision: 804057
URL: http://svn.apache.org/viewvc?rev=804057view=rev
Log:
Deserialize with the webapp classloader as the context classloader
Modified:
tomcat/trunk/java/org/apache/catalina/ha/session/DeltaSession.java
Modified: tomcat/trunk/java/org/apache/catalina/ha/session/DeltaSession.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/ha/session/DeltaSession.java?rev=804057r1=804056r2=804057view=diff
==
--- tomcat/trunk/java/org/apache/catalina/ha/session/DeltaSession.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/ha/session/DeltaSession.java Thu Aug
13 23:10:40 2009
@@ -169,12 +169,12 @@
try {
lock();
ReplicationStream stream = ( (ClusterManager)
getManager()).getReplicationStream(diff, offset, length);
-getDeltaRequest().readExternal(stream);
ClassLoader contextLoader =
Thread.currentThread().getContextClassLoader();
try {
ClassLoader[] loaders = getClassLoaders();
if (loaders != null loaders.length 0)
Thread.currentThread().setContextClassLoader(loaders[0]);
+getDeltaRequest().readExternal(stream);
getDeltaRequest().execute(this,
((ClusterManager)getManager()).isNotifyListenersOnReplication());
} finally {
Thread.currentThread().setContextClassLoader(contextLoader);
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r804058 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: fhanik Date: Thu Aug 13 23:12:36 2009 New Revision: 804058 URL: http://svn.apache.org/viewvc?rev=804058view=rev Log: proposal Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=804058r1=804057r2=804058view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Thu Aug 13 23:12:36 2009 @@ -297,3 +297,12 @@ http://people.apache.org/~kkolinko/patches/2009-08-13_bug45403-tc6.patch +1: kkolinko -1: + +* Perform deserialization with the context class loader set. + This ensures that code that actually executes Class.forName(...,classloader) during this phase + works properly. + http://svn.apache.org/viewvc?rev=804057view=rev + +1: fhanik + -1: + + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Making AJP secret attribute consistent
2009/8/13 Mladen Turk mt...@apache.org:
On 13/08/09 19:43, Konstantin Kolinko wrote:
Other option is to use required.secret instead requiredSecret
Much easier because requiredSecret isn't document, so one
can only find it browsing the source code.
However dunno how to make it using current property set/get methods
I have just noticed - the following patch (as currently proposed for
tc6.0) is an example of implementing such a dot property
(socket.unlockTimeout):
* Improve NIO connector shutdown time by doing shutdowns in parallel
and with a timeout
http://svn.apache.org/viewvc?view=revrevision=791914
I have not dug into details yet, though.
It looks like magic ;)
I always thought that setName(...) reflects name=...,
now it seems it's possible to have setName(...) and socket.name=...
... The implementation, in this case, is in NioEndpoint#setProperty()
{
final String selectorPoolName = selectorPool.;
final String socketName = socket.;
if (name.startsWith(selectorPoolName)) {
return IntrospectionUtils.setProperty(...);
} else if (name.startsWith(socketName)) {
return IntrospectionUtils.setProperty(...);
} else {
return IntrospectionUtils.setProperty(this,name,value);
}
}
and it is o.a.tomcat.util.IntrospectionUtils#setProperty(..) that
looks for the setProperty method if explicit setter is not
available.
Best regards,
Konstantin Kolinko
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
