DO NOT REPLY [Bug 50161] index.jsp is added to paths ending in a / before doFilter is called on matching Filters
https://issues.apache.org/bugzilla/show_bug.cgi?id=50161 --- Comment #1 from hossman hossman_apachebugzi...@fucit.org 2010-10-27 01:59:45 EDT --- Note: this is (evidently) the root cause of SOLR-2022... https://issues.apache.org/jira/browse/SOLR-2022 -- 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 50138] Lack of synchronization in org.apache.catalina.security.SecurityUtil
https://issues.apache.org/bugzilla/show_bug.cgi?id=50138 --- Comment #4 from Dmitry Mikhaylov mikhailov.dmi...@gmail.com 2010-10-27 02:44:00 EDT --- Thanks for prompt fix, waiting for 6.0.30. -- 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: r1027846 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: kfujino Date: Wed Oct 27 07:34:51 2010 New Revision: 1027846 URL: http://svn.apache.org/viewvc?rev=1027846view=rev Log: vote 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=1027846r1=1027845r2=1027846view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Wed Oct 27 07:34:51 2010 @@ -141,7 +141,7 @@ PATCHES PROPOSED TO BACKPORT: * Make sure Contexts defined in server.xml pick up any configClass setting from the parent Host. http://people.apache.org/~markt/patches/2010-09-11-configClass.patch - +1: markt, kkolinko + +1: markt, kkolinko, kfujino -1: kkolinko: Though 1) I do not see any documentation on configClass attribute in the docs at all. Though it is in JavaDoc for StandardHost. @@ -154,7 +154,7 @@ PATCHES PROPOSED TO BACKPORT: Stop accepting new requests (inc keep-alive) once the BIO connector is paused and the current request has finished processing https://issues.apache.org/bugzilla/attachment.cgi?id=26094 - +1: markt + +1: markt, kfujino -1: * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=49625 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Tomcat Connectors 1.2.31
Sorry, long holiday weekend in NZ. So, Tomcat Connectors 1.2.31 is: [x ] +1 release it [ ] -1 nope, it's broken tim - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat native ia64 binaries wrong?
On Tue, Oct 26, 2010 at 11:42 PM, Mladen Turk mt...@apache.org wrote: On 10/26/2010 11:28 AM, Mark Thomas wrote: Hi, I don't have the hardware to test if this is an issue on ia64 this but the following files have the same MD5 hash: http://www.apache.org/dist/tomcat/tomcat-connectors/native/1.1.20/binaries/win64/ia64/tcnative-1.dll http://www.apache.org/dist/tomcat/tomcat-connectors/native/1.1.20/binaries/win32/tcnative-1.dll That looks suspicious to me. I'd expect the x86 and ia64 binaries to be different. Right, this is actually x86 binary, not an ia64 one. Seems I did a wrong upload back in February. Since you are the first one that figured that out after more then 8 months, it just convinces me that we should drop IA64 binaries altogether. +1. I've seen one non HP-UX IA64 system in 10 years, and that was RHEL. At least I don't plan to produce them any more 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
DO NOT REPLY [Bug 50159] JNDI context returns new datasource instance each request
https://issues.apache.org/bugzilla/show_bug.cgi?id=50159 --- Comment #5 from Mark Thomas ma...@apache.org 2010-10-27 04:29:06 EDT --- David, Thanks for the clarification. Reading that part of the spec and trying to figure out what it actually means always makes my head hurt. I'll leave the shareable flag alone (as far as I can tell, Tomcat doesn't do anything with it). Bug 49994 indicates there are at least some users that want the spec mandated behaviour whilst it appears to be the expectation of most that the same object is returned from multiple look-ups. Configuring this per context would be easy but I think per resource configuration would be better. I'll see if there is a way to make that happen. If nothing simple jumps put at me, I'll likely go with per context configuration for now and we can look at extending it to per resource if there is any demand for that. -- 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 50160] LocalStrings.properties missing from catalina-jmx-remote.jar
https://issues.apache.org/bugzilla/show_bug.cgi?id=50160 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Comment #2 from Mark Thomas ma...@apache.org 2010-10-27 05:13:51 EDT --- The necessary files are in catalina.jar, a required dependency of catalina-jmx-remote.jar. You'll also need tomcat-util.jar and tomcat-juli.jar. Those will give you the English messages. Add the language specific jar if you need another language. -- 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 50158] Tomcat7.0.4 ROOT BUG
https://issues.apache.org/bugzilla/show_bug.cgi?id=50158 --- Comment #5 from Pid pids...@apache.org 2010-10-27 06:07:41 EDT --- Please join the Tomcat Users mailing list and explain the problem there. http://tomcat.apache.org/lists.html -- 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: r1027893 - /tomcat/trunk/build.properties.default
Author: mturk
Date: Wed Oct 27 10:27:03 2010
New Revision: 1027893
URL: http://svn.apache.org/viewvc?rev=1027893view=rev
Log:
Upgrade to latest released Daemon 1.0.4
Modified:
tomcat/trunk/build.properties.default
Modified: tomcat/trunk/build.properties.default
URL:
http://svn.apache.org/viewvc/tomcat/trunk/build.properties.default?rev=1027893r1=1027892r2=1027893view=diff
==
--- tomcat/trunk/build.properties.default (original)
+++ tomcat/trunk/build.properties.default Wed Oct 27 10:27:03 2010
@@ -16,7 +16,7 @@
# -
# build.properties.sample
#
-# This is an example build.properties file, used to customize building
+# This is an example build.properties file, used to customize building
# Tomcat for your local environment. It defines the location of all external
# modules that Tomcat depends on. Copy this file to build.properties
# in the top-level source directory, and customize it as needed.
@@ -94,7 +94,7 @@ servletapi.version=2.3
servletapi.home=${base.path}/servletapi-${servletapi.version}
servletapi.loc=${base-maven1.loc}/servletapi/jars/servletapi-${servletapi.version}.jar
servletapi.jar=${servletapi.home}/servletapi-${servletapi.version}.jar
-
+
# - Webservices - JAX RPC -
jaxrpc-lib.version=1.1-rc4
jaxrpc-lib.home=${base.path}/jaxrpc-${jaxrpc-lib.version}
@@ -144,7 +144,7 @@ nsis.nsisdl.dll=${nsis.home}/Plugins/NSI
nsis.loc=${base-sf.loc}/nsis/nsis-2.46.zip
# - Commons Daemon, version 1.0-Alpha or later -
-commons-daemon.version=1.0.3
+commons-daemon.version=1.0.4
commons-daemon.home=${base.path}/commons-daemon-${commons-daemon.version}
commons-daemon.jar=${commons-daemon.home}/commons-daemon-${commons-daemon.version}.jar
commons-daemon.native.win.home=${commons-daemon.home}/windows
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1027898 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: mturk Date: Wed Oct 27 10:32:23 2010 New Revision: 1027898 URL: http://svn.apache.org/viewvc?rev=1027898view=rev Log: Popose component version update 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=1027898r1=1027897r2=1027898view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Wed Oct 27 10:32:23 2010 @@ -275,3 +275,10 @@ PATCHES PROPOSED TO BACKPORT: http://svn.apache.org/viewvc?rev=1027504view=rev +1: markt -1: + +* Update Commons daemon to 1.0.4 + Version 1.0.4 is bug fixing release. (Patch is trivial changing the version + number to 1.0.4 in build.properties.default, so not provided) + +1: mturk + -1: + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1027901 - /tomcat/tc5.5.x/trunk/STATUS.txt
Author: mturk Date: Wed Oct 27 10:34:56 2010 New Revision: 1027901 URL: http://svn.apache.org/viewvc?rev=1027901view=rev Log: Popose component version update Modified: tomcat/tc5.5.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=1027901r1=1027900r2=1027901view=diff == --- tomcat/tc5.5.x/trunk/STATUS.txt (original) +++ tomcat/tc5.5.x/trunk/STATUS.txt Wed Oct 27 10:34:56 2010 @@ -83,3 +83,10 @@ PATCHES PROPOSED TO BACKPORT: https://issues.apache.org/bugzilla/attachment.cgi?id=26194 +1: kkolinko, kfujino, markt -1: + +* Update Commons daemon to 1.0.4 + Version 1.0.4 is bug fixing release. (Patch is trivial changing the version + number to 1.0.4 in build.properties.default, so not provided) + +1: mturk + -1: + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50158] Tomcat7.0.4 ROOT BUG
https://issues.apache.org/bugzilla/show_bug.cgi?id=50158 --- Comment #6 from Pid pids...@apache.org 2010-10-27 09:12:25 EDT --- (I think it's the session cookie's interfering with each other, because the hostname==ip address and the port isn't defined in the cookie) -- 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 Tomcat Connectors 1.2.31
On 22.10.2010 15:10, Mladen Turk wrote: So, Tomcat Connectors 1.2.31 is: [X] +1 release it Thanks for RMing. Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50158] Tomcat7.0.4 ROOT BUG
https://issues.apache.org/bugzilla/show_bug.cgi?id=50158 --- Comment #7 from 醉我行 zuiwox...@gmail.com 2010-10-27 09:48:00 EDT --- (In reply to comment #6) (I think it's the session cookie's interfering with each other, because the hostname==ip address and the port isn't defined in the cookie) I think so, In the TOMCAT, session related to the generation of whether ContextPath it? Because, deployed in the ROOT directory of the application, contextPath made are empty -- 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: Tomcat native ia64 binaries wrong?
On 10/27/2010 3:10 AM, Tim Whittington wrote: On Tue, Oct 26, 2010 at 11:42 PM, Mladen Turk mt...@apache.org wrote: On 10/26/2010 11:28 AM, Mark Thomas wrote: Hi, I don't have the hardware to test if this is an issue on ia64 this but the following files have the same MD5 hash: http://www.apache.org/dist/tomcat/tomcat-connectors/native/1.1.20/binaries/win64/ia64/tcnative-1.dll http://www.apache.org/dist/tomcat/tomcat-connectors/native/1.1.20/binaries/win32/tcnative-1.dll That looks suspicious to me. I'd expect the x86 and ia64 binaries to be different. Right, this is actually x86 binary, not an ia64 one. Seems I did a wrong upload back in February. Since you are the first one that figured that out after more then 8 months, it just convinces me that we should drop IA64 binaries altogether. +1. I've seen one non HP-UX IA64 system in 10 years, and that was RHEL. At least I don't plan to produce them any more As a reference, Microsoft has dropped IA64... old news, I know... http://www.pcworld.com/article/193426/microsoft_ending_support_for_itanium.html - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50161] index.jsp is added to paths ending in a / before doFilter is called on matching Filters
https://issues.apache.org/bugzilla/show_bug.cgi?id=50161 --- Comment #4 from hossman hossman_apachebugzi...@fucit.org 2010-10-27 14:35:17 EDT --- While i appreciate that the underlying change that caused this bug is most certainly the same as that of bug#49422 i would like to point out that the actual issue is (to me at least) fairly distinct. Having read the comments in bug#49422 I (somewhat) understand the reasons why a servlet wishing to receive requests for /foo/ should be registered with a url-mapping of /foo/* in order to receive the implicit request for /foo/index.jsp but in the case of this bug (bug#50161) We are already using a url-mapping of /* for the Filter in question. The issue at hand is what the return value of HttpServletRequest.getServletPath() should be when the Servlet (or in our case Filter) processes the request. Shouldn't that method (per the javadocs) Returns the part of this request's URL that calls the servlet ... w/o having additional (implicit) values tacked on to the end? -- 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 48895] WebAppClassLoader.clearThreadLocalMap() concurrency issues
https://issues.apache.org/bugzilla/show_bug.cgi?id=48895 --- Comment #4 from quartz quartz...@yahoo.com 2010-10-27 15:32:18 EDT --- If the only threads accessing the instances of a context are the connector's threads, and if you kill those threads when you remove a context, then you cannot have a leak. Sadly, tomcat is ass backwards and has a pool of thread per connectors owned by the service instead of owned by the context. Thus you cannot destroy threads without destroying all context under all hosts under all engines under the service. Solution: destroying a context must mark a thread that visited it for termination, asap. That means the thread would not return in the pool, and the pool would create a replacement thread. That is subpar for other ctx/host/engine that would loose the threadlocal-cached values, but it is not a requirement for j2ee to be efficient under such operation, and the app is still supposed to work as it should expect a threadlocal to be null at any 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 50161] index.jsp is added to paths ending in a / before doFilter is called on matching Filters
https://issues.apache.org/bugzilla/show_bug.cgi?id=50161 --- Comment #5 from Attila Király kiralyattila...@gmail.com 2010-10-27 15:52:31 EDT --- Don't know how legal it is but I use the following workaround in the web.xml (works with 7.0.4): welcome-file-list welcome-file/welcome-file /welcome-file-list This turns off the default welcome file list and adds nothing to the end of the url. -- 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 50165] New: Manually launching Tomcat 7.0.4 on the command line is impossible
https://issues.apache.org/bugzilla/show_bug.cgi?id=50165 Summary: Manually launching Tomcat 7.0.4 on the command line is impossible Product: Tomcat 7 Version: 7.0.4 Platform: PC Status: NEW Severity: blocker Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: anto...@compleasy.com After installing Tomcat you cannot start it manually using bootstrap.jar in the bin directory because an exception rises. For example, provided that base_dir, tomcat_install_dir, my_temp_dir are correct directories, launching Tomcat on the command line results in: C:\Users\MyselfC:\Program Files\Java\jdk\bin\java -Dcatalina.base=base_dir -Dcatalina.h ome=tomcat_install_dir -Djava.io.tmpdir=my_temp_dir -jar tomcat_install_dir\bin\bootstrap.jar start Exception in thread main java.lang.NoClassDefFoundError: org/apache/juli/logging/LogFactory at org.apache.catalina.startup.Bootstrap.clinit(Bootstrap.java:56) Caused by: java.lang.ClassNotFoundException: org.apache.juli.logging.LogFactory at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) ... 1 more Could not find the main class: org.apache.catalina.startup.Bootstrap. Program will exit. This is a blocker bug, especially if you want to use tomcat 7 for development and debugging from IDEs (Eclipse, etc..). Anyway, I discovered where the bug is and fixed it. The solution: Unpacking bootstrap.jar (this is where the bug is), which is present in the direvctory tomcat_install_dir\bin, you discover that in the file /META-INF/MANIFEST.MF there is this line at the end of the file: Class-Path: commons-daemon.jar However the commons-daemon.jar file is not present in the installation of Tomcat 7.0.4 So to fix the bug you just need to replace this line: Class-Path: commons-daemon.jar with this one: Class-Path: tomcat-juli.jar then pack again bootstrap.jar with this modified version of /META-INF/MANIFEST.MF and replace the old bootstrap.jar in the bin directory of tomcat installation with the new packed one. Problem solved. -- 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 50165] Manually launching Tomcat 7.0.4 on the command line is impossible
https://issues.apache.org/bugzilla/show_bug.cgi?id=50165 Konstantin Kolinko knst.koli...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE OS/Version||All Severity|blocker |minor --- Comment #1 from Konstantin Kolinko knst.koli...@gmail.com 2010-10-27 17:45:02 EDT --- It is not a bug, it is a feature. Hint: do not use -jar switch, use -classpath instead, as catalina.(sh|bat) script does. *** This bug has been marked as a duplicate of bug 49857 *** -- 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 49857] the bootstrap.jar's manifest.mf file need tomcat-juli.jar item for command line start
https://issues.apache.org/bugzilla/show_bug.cgi?id=49857 Konstantin Kolinko knst.koli...@gmail.com changed: What|Removed |Added CC||anto...@compleasy.com --- Comment #3 from Konstantin Kolinko knst.koli...@gmail.com 2010-10-27 17:45:02 EDT --- *** Bug 50165 has been marked as a duplicate of this bug. *** -- 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: Tomcat native ia64 binaries wrong?
As a reference, Microsoft has dropped IA64... old news, I know... http://www.pcworld.com/article/193426/microsoft_ending_support_for_itanium.html OOOPS! Guess that's what happens when you depart the ia64 mother ship; you lose track of even old news. -- Chan Channing Benson Senior Consultant vFabric, Cloud Application Platform VMware cben...@vmware.com Work: 610-328-3691 Mobile: 610-909-7349 On Oct 27, 2010, at 1:57 PM, William A. Rowe Jr. wrote: On 10/27/2010 3:10 AM, Tim Whittington wrote: On Tue, Oct 26, 2010 at 11:42 PM, Mladen Turk mt...@apache.org wrote: On 10/26/2010 11:28 AM, Mark Thomas wrote: Hi, I don't have the hardware to test if this is an issue on ia64 this but the following files have the same MD5 hash: http://www.apache.org/dist/tomcat/tomcat-connectors/native/1.1.20/binaries/win64/ia64/tcnative-1.dll http://www.apache.org/dist/tomcat/tomcat-connectors/native/1.1.20/binaries/win32/tcnative-1.dll That looks suspicious to me. I'd expect the x86 and ia64 binaries to be different. Right, this is actually x86 binary, not an ia64 one. Seems I did a wrong upload back in February. Since you are the first one that figured that out after more then 8 months, it just convinces me that we should drop IA64 binaries altogether. +1. I've seen one non HP-UX IA64 system in 10 years, and that was RHEL. At least I don't plan to produce them any more As a reference, Microsoft has dropped IA64... old news, I know... http://www.pcworld.com/article/193426/microsoft_ending_support_for_itanium.html - 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 50161] index.jsp is added to paths ending in a / before doFilter is called on matching Filters
https://issues.apache.org/bugzilla/show_bug.cgi?id=50161 --- Comment #6 from Mark Thomas ma...@apache.org 2010-10-27 21:30:44 EDT --- (In reply to comment #4) The issue at hand is what the return value of HttpServletRequest.getServletPath() should be when the Servlet (or in our case Filter) processes the request. Shouldn't that method (per the javadocs) Returns the part of this request's URL that calls the servlet ... w/o having additional (implicit) values tacked on to the end? There are a couple of ambiguities in the spec in this area: - It isn't clear if filter mapping occurs before or after welcome file processing. The implication is that filter mapping is after welcome file processing. - It isn't clear if the welcome file should be included in getServletPath() etc. The implication is that it should. Both of these issues - and a bunch of others - are on my list of things to nag the EG about. The option(s) that get added for the next 7.0.x release should fix this for you - or at least enable you to work around it. -- 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 47678] Unable to allocate shared memory when using isapi_redirect.dll as an extension and filter
https://issues.apache.org/bugzilla/show_bug.cgi?id=47678 Matti K matti.katajam...@frontrange.com changed: What|Removed |Added Priority|P2 |P1 CC||matti.katajam...@frontrange ||.com OS/Version|Windows 2000|Windows Server 2008 Severity|normal |critical -- 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 50168] New: destory method is called twice while the child is destoryed directly
https://issues.apache.org/bugzilla/show_bug.cgi?id=50168 Summary: destory method is called twice while the child is destoryed directly Product: Tomcat 7 Version: 7.0.4 Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: xhh...@gmail.com While calling the method destory() on the StandardContext directly, it seems that the method destoryInternal() is called twice in the LifecycleMBeanBase, the two stacktraces are below : a. LifecycleMBeanBase.unregister(ObjectName) line: 191 LifecycleMBeanBase.destroyInternal() line: 73 ContainerBase.destroyInternal() line: 1109 StandardContext.destroyInternal() line: 5114 LifecycleBase.destroy() line: 271 ContainerBase.removeChild(Container) line: 963 ContainerBase.destroyInternal() line: 1106 StandardContext.destroyInternal() line: 5114 LifecycleBase.destroy() line: 271 ... b. LifecycleMBeanBase.unregister(ObjectName) line: 191 LifecycleMBeanBase.destroyInternal() line: 73 ContainerBase.destroyInternal() line: 1109 StandardContext.destroyInternal() line: 5114 LifecycleBase.destroy() line: 271 ... -- 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
