DO NOT REPLY [Bug 50107] New: StandardPipeline is destroyed two times.
https://issues.apache.org/bugzilla/show_bug.cgi?id=50107
Summary: StandardPipeline is destroyed two times.
Product: Tomcat 7
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: minor
Priority: P2
Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: mashm...@gmail.com
Created an attachment (id=26181)
-- (https://issues.apache.org/bugzilla/attachment.cgi?id=26181)
patch for MBeanFactory.java
When I call MBeanFactory#removeHost operation via JMX(jconsle), I get the
following message.
INFO: The destroy() method was called on component
[Pipeline[StandardHost[localhost]]] after destroy() had already been called.
The second call will be ignored.
StandardPipeline is destroyed two times.
At first, pipeline is destroyed at ContainerBase.java L.1096:
ContainerBase.java destroyInternal() L.1094-1097
1094 // Stop the Valves in our pipeline (including the basic), if
any
1095 if (pipeline instanceof Lifecycle) {
1096 ((Lifecycle) pipeline).destroy();
1097 }
ContainerBase.java destroyInternal() L.1104-1107
1104 // Required if the child is destroyed directly.
1105 if (parent != null) {
1106 parent.removeChild(this);
1107 }
When above-mentioned parent is StandardEngine, the parent.removeChild() calls
the LifecycleBase#child.destroy(), and child.destroy() calls
ContainerBase#destroyInternal().
At this time ContainerBase is StandardHost.
ContainerBase.java removeChild() L.960-964
960 // Set child's parent to null to prevent a loop
961 child.setParent(null);
962 try {
963 child.destroy();
964 } catch (LifecycleException e) {
As a result, pipeline is destroyed again(, and get the above-mentioned info
message).
In Tomcat 6.0, child.destroy() is not called from ContainerBase#removeChild().
But, as seen above, the removeChild() that is contained in Tomcat7.0 calls the
child.destroy().
IMHO, it might not be better to call the child.destroy() from removeHost().
I made the patch that removed host.destroy() from removeHost().
Best regards.
--
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 50108] New: Add missing setter/getter to AbstractXXXProtocol
https://issues.apache.org/bugzilla/show_bug.cgi?id=50108 Summary: Add missing setter/getter to AbstractXXXProtocol Product: Tomcat 7 Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Connectors AssignedTo: dev@tomcat.apache.org ReportedBy: mashm...@gmail.com Created an attachment (id=26182) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=26182) patch for AbstractXXXProtocol Add missing following methods to AbstractHttp11Protocol and AbstractAjpProtocol. - setMinSpareThreads - getMinSpareThreads Best regards. -- 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: r1023678 - /tomcat/trunk/java/org/apache/jasper/compiler/AttributeParser.java
Author: markt
Date: Mon Oct 18 07:53:04 2010
New Revision: 1023678
URL: http://svn.apache.org/viewvc?rev=1023678view=rev
Log:
Comment typo
Modified:
tomcat/trunk/java/org/apache/jasper/compiler/AttributeParser.java
Modified: tomcat/trunk/java/org/apache/jasper/compiler/AttributeParser.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/jasper/compiler/AttributeParser.java?rev=1023678r1=1023677r2=1023678view=diff
==
--- tomcat/trunk/java/org/apache/jasper/compiler/AttributeParser.java (original)
+++ tomcat/trunk/java/org/apache/jasper/compiler/AttributeParser.java Mon Oct
18 07:53:04 2010
@@ -148,7 +148,7 @@ public class AttributeParser {
* - literals that need to be converted for EL processing
* \ - type{'\\'}
* $ - type{'$'}
- * # - type{'$'}
+ * # - type{'#'}
* - start of EL
* ${
* #{
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1023694 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: kfujino Date: Mon Oct 18 09:05:00 2010 New Revision: 1023694 URL: http://svn.apache.org/viewvc?rev=1023694view=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=1023694r1=1023693r2=1023694view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Mon Oct 18 09:05:00 2010 @@ -205,13 +205,13 @@ PATCHES PROPOSED TO BACKPORT: * Backport all JRE leak prevention listener changes to tc6 http://people.apache.org/~markt/patches/2010-10-05-leak-preotection-tc6.patch - +1: markt, kkolinko + +1: markt, kkolinko, kfujino -1: Additional patch: http://svn.apache.org/viewvc?rev=1004868view=rev http://svn.apache.org/viewvc?rev=1004869view=rev - +1: kkolinko, markt + +1: kkolinko, markt, kfujino -1: * Fix path parameter handling. Currently the following URL fails with a 404: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1023707 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: kfujino Date: Mon Oct 18 09:35:28 2010 New Revision: 1023707 URL: http://svn.apache.org/viewvc?rev=1023707view=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=1023707r1=1023706r2=1023707view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Mon Oct 18 09:35:28 2010 @@ -274,12 +274,12 @@ PATCHES PROPOSED TO BACKPORT: Threading patch provided by Takayoshi Kimura http://svn.apache.org/viewvc?rev=1022606view=rev (threading) http://svn.apache.org/viewvc?rev=1022623view=rev (cache sizes) - +1: markt + +1: markt, kfujino -1: * Do not call reset if the default LogManager is in use (an additional fix for https://issues.apache.org/bugzilla/show_bug.cgi?id=48716) Patch by markt. http://svn.apache.org/viewvc?rev=1005802view=rev - +1: kkolinko + +1: kkolinko, kfujino -1: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
welcome files, servlet mappings and jsps (was [VOTE] Release Apache Tomcat 7.0.4)
Actually Glassfish does not differentiate between implicit and explicit mappings. There's just a test on the servlet-name : When determining the wrapper to use for a welcome file, if the physical file is not found, it checks for servlet mappings. If there's such a match, it also checks that the servlet name is different from jsp (overridable by a System property). their source is here : https://grizzly.dev.java.net/source/browse/grizzly/trunk/code/modules/utils/src/main/java/com/sun/grizzly/util/http/mapper/Mapper.java?view=markup I believe we could do the same hack in tomcat 7. The spec might not be very clear but that behavior avoids big surprises for current applications... Sylvain On 18 oct. 2010, at 02:35, Mark Thomas wrote: On 17/10/2010 22:58, Caldarale, Charles R wrote: From: Mark Thomas [mailto:ma...@apache.org] Subject: Re: [VOTE] Release Apache Tomcat 7.0.4 There are no matches for the static files so all is OK for the first sentence. However there is a match (to *.jsp) the second time through so Tomcat passes /catalog/products/default.jsp to the JSP servlet which returns a 404. This might be the crux of the matter: section 12.2.1 of the spec states that *.jsp is an /implicit/ mapping (unless overridden by the webapp), and the second matching protocol in 10.10 seems to be referring to /explicit/ mappings (my interpretation, not definitive in the spec). Tomcat does not differentiate between implicit and explicit mappings, whereas the other containers seem to do so. Implicit seems to be a term used in section exclusively 12.2.1 (OK apart from a single mention in 12.1). It isn't used elsewhere in the Servlet spec so it isn't at all clear what - if any - special treatment implicit mappings are meant to have. 12.2.1 doesn't mention *.jspx which doesn't give me a great deal of confidence in the completeness or correctness of that section. Something else that requires some clarity for Servlet 3.1. I'll add it to my list. My previous suggestion regarding a new config option would at least allow users to control this behaviour until we get some clarity in the spec. 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
Re: [VOTE] Release Apache Tomcat 7.0.4
On Sun, 2010-10-17 at 22:38 +0100, Mark Thomas wrote: Yes, this is stupid but it is what the spec requires. I have to disagree, there was agreement in the expert group that wildcard mappings and welcome files cannot be mixed at the moment, unless for specific proprietary hacks, or if a static file is present. Rémy - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat 7.0.4
On 18/10/2010 16:34, Remy Maucherat wrote: On Sun, 2010-10-17 at 22:38 +0100, Mark Thomas wrote: Yes, this is stupid but it is what the spec requires. I have to disagree, there was agreement in the expert group that wildcard mappings and welcome files cannot be mixed at the moment, unless for specific proprietary hacks, or if a static file is present. Knowing what the expert group agreed is helpful in deciding how we might handle this mess but it remains the case the the specification says the exact opposite of your statement above. Mar - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: welcome files, servlet mappings and jsps (was [VOTE] Release Apache Tomcat 7.0.4)
On 18/10/2010 16:04, Sylvain Laurent wrote: Actually Glassfish does not differentiate between implicit and explicit mappings. There's just a test on the servlet-name : When determining the wrapper to use for a welcome file, if the physical file is not found, it checks for servlet mappings. If there's such a match, it also checks that the servlet name is different from jsp (overridable by a System property). their source is here : https://grizzly.dev.java.net/source/browse/grizzly/trunk/code/modules/utils/src/main/java/com/sun/grizzly/util/http/mapper/Mapper.java?view=markup I believe we could do the same hack in tomcat 7. The spec might not be very clear but that behavior avoids big surprises for current applications... Something along those lines is certainly going to be the way we need to handle this until the EG updates the spec to say what they meant it to say rather than what it currently says. Options look like: 1. system property / context option to enable/disable this behaviour for JSP servlet 2. system property / context option to enable/disable this behaviour for all wildcard mapped servlets 3. system property / context option to enable/disable this behaviour for a user defined set of servlets My preferences (without looking at the code) is for 3 is that doable without an undue amount of complexity. Then 2. Then 1. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
