Re: [VOTE] Release Apache Tomcat Connectors 1.2.39
On 02/28/2014 10:35 AM, Mladen Turk wrote: The Apache Tomcat Connectors 1.2.39 is [X] Stable, go ahead and release [ ] Broken because of ... My vote for the record Regards -- ^TM - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[jira] [Created] (MTOMCAT-261) Deploy war with client certificate
Jean Detoeuf created MTOMCAT-261: Summary: Deploy war with client certificate Key: MTOMCAT-261 URL: https://issues.apache.org/jira/browse/MTOMCAT-261 Project: Apache Tomcat Maven Plugin Issue Type: Wish Components: tomcat6, tomcat7 Affects Versions: 2.2 Environment: 2.6.18-238.19.1.el5 #1 SMP Sun Jul 10 08:40:19 EDT 2011 i686 i686 i386 GNU/Linux Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Reporter: Jean Detoeuf Assignee: Olivier Lamy (*$^¨%`£) Priority: Minor With the org.codehaus.mojo tomcat-maven-plugin, it's possible to set MVN_OPTS with javax.net.ssl.keyStore, javax.net.ssl.keyStorePassword and javax.net.ssl.keyStoreType to deploy with client side SSL authentication. I've tried setting these system properties directly in the tomcat6-maven-plugin configuration as described in https://tomcat.apache.org/maven-plugin-2.1/tomcat6-maven-plugin/examples/add-system-properties.html but somehow, these system properties are not taken into account for deploying. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1575262 - in /tomcat/trunk: java/org/apache/catalina/core/StandardContext.java java/org/apache/catalina/core/StandardWrapper.java webapps/docs/changelog.xml
Author: markt
Date: Fri Mar 7 14:04:50 2014
New Revision: 1575262
URL: http://svn.apache.org/r1575262
Log:
Improve the robustness of web application undeployment based on some code
analysis triggered by the report for BZ 54315
Modified:
tomcat/trunk/java/org/apache/catalina/core/StandardContext.java
tomcat/trunk/java/org/apache/catalina/core/StandardWrapper.java
tomcat/trunk/webapps/docs/changelog.xml
Modified: tomcat/trunk/java/org/apache/catalina/core/StandardContext.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/StandardContext.java?rev=1575262r1=1575261r2=1575262view=diff
==
--- tomcat/trunk/java/org/apache/catalina/core/StandardContext.java (original)
+++ tomcat/trunk/java/org/apache/catalina/core/StandardContext.java Fri Mar 7
14:04:50 2014
@@ -475,7 +475,7 @@ public class StandardContext extends Con
/**
* The request processing pause flag (while reloading occurs)
*/
-private boolean paused = false;
+private volatile boolean paused = false;
/**
Modified: tomcat/trunk/java/org/apache/catalina/core/StandardWrapper.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/StandardWrapper.java?rev=1575262r1=1575261r2=1575262view=diff
==
--- tomcat/trunk/java/org/apache/catalina/core/StandardWrapper.java (original)
+++ tomcat/trunk/java/org/apache/catalina/core/StandardWrapper.java Fri Mar 7
14:04:50 2014
@@ -200,7 +200,7 @@ public class StandardWrapper extends Con
/**
* Are we unloading our servlet instance at the moment?
*/
-protected boolean unloading = false;
+protected volatile boolean unloading = false;
/**
@@ -1076,6 +1076,11 @@ public class StandardWrapper extends Con
*/
public synchronized Servlet loadServlet() throws ServletException {
+if (unloading) {
+throw new ServletException(
+sm.getString(standardWrapper.unloading, getName()));
+}
+
// Nothing to do if we already have an instance or an instance pool
if (!singleThreadModel (instance != null))
return instance;
Modified: tomcat/trunk/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1575262r1=1575261r2=1575262view=diff
==
--- tomcat/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/trunk/webapps/docs/changelog.xml Fri Mar 7 14:04:50 2014
@@ -53,6 +53,10 @@
application. (markt)
/fix
fix
+Improve the robustness of web application undeployment based on some
+code analysis triggered by the report for bug54315/bug. (markt)
+ /fix
+ fix
bug56125/bug: Correctly construct the URL for a resource that
represents the root of a JAR file. (markt)
/fix
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1575263 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/catalina/core/StandardContext.java java/org/apache/catalina/core/StandardWrapper.java webapps/docs/changelog.xml
Author: markt
Date: Fri Mar 7 14:10:15 2014
New Revision: 1575263
URL: http://svn.apache.org/r1575263
Log:
Improve the robustness of web application undeployment based on some code
analysis triggered by the report for BZ 54315
Modified:
tomcat/tc7.0.x/trunk/ (props changed)
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/StandardContext.java
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/StandardWrapper.java
tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
Propchange: tomcat/tc7.0.x/trunk/
--
Merged /tomcat/trunk:r1575262
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/StandardContext.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/StandardContext.java?rev=1575263r1=1575262r2=1575263view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/StandardContext.java
(original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/StandardContext.java Fri
Mar 7 14:10:15 2014
@@ -499,7 +499,7 @@ public class StandardContext extends Con
/**
* The request processing pause flag (while reloading occurs)
*/
-private boolean paused = false;
+private volatile boolean paused = false;
/**
Modified:
tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/StandardWrapper.java
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/StandardWrapper.java?rev=1575263r1=1575262r2=1575263view=diff
==
--- tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/StandardWrapper.java
(original)
+++ tomcat/tc7.0.x/trunk/java/org/apache/catalina/core/StandardWrapper.java Fri
Mar 7 14:10:15 2014
@@ -211,7 +211,7 @@ public class StandardWrapper extends Con
/**
* Are we unloading our servlet instance at the moment?
*/
-protected boolean unloading = false;
+protected volatile boolean unloading = false;
/**
@@ -1119,6 +1119,11 @@ public class StandardWrapper extends Con
*/
public synchronized Servlet loadServlet() throws ServletException {
+if (unloading) {
+throw new ServletException(
+sm.getString(standardWrapper.unloading, getName()));
+}
+
// Nothing to do if we already have an instance or an instance pool
if (!singleThreadModel (instance != null))
return instance;
Modified: tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml
URL:
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml?rev=1575263r1=1575262r2=1575263view=diff
==
--- tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc7.0.x/trunk/webapps/docs/changelog.xml Fri Mar 7 14:10:15 2014
@@ -64,6 +64,10 @@
codeWebappClassLoader/code. (markt)
/add
fix
+Improve the robustness of web application undeployment based on some
+code analysis triggered by the report for bug54315/bug. (markt)
+ /fix
+ fix
bug56219/bug:
Improve merging process for web.xml files to take account of the
elements and attributes supported by the Servlet version of the merged
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54315] Redeploying webapp causes NullPointerException in managerBase
https://issues.apache.org/bugzilla/show_bug.cgi?id=54315 --- Comment #14 from Lorenzo loreatt...@gmail.com --- Created attachment 31375 -- https://issues.apache.org/bugzilla/attachment.cgi?id=31375action=edit the logs when I get the null pointer -- 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
[Bug 54315] Redeploying webapp causes NullPointerException in managerBase
https://issues.apache.org/bugzilla/show_bug.cgi?id=54315 --- Comment #15 from Lorenzo loreatt...@gmail.com --- Created attachment 31376 -- https://issues.apache.org/bugzilla/attachment.cgi?id=31376action=edit the logs when the server is redeployed successfully -- 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
[Bug 54315] Redeploying webapp causes NullPointerException in managerBase
https://issues.apache.org/bugzilla/show_bug.cgi?id=54315 --- Comment #16 from Lorenzo loreatt...@gmail.com --- I added some logs with at the INFO level. I hope you can gather some information from it. -- 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
buildbot success in ASF Buildbot on tomcat-7-trunk
The Buildbot has detected a restored build on builder tomcat-7-trunk while building ASF Buildbot. Full details are available at: http://ci.apache.org/builders/tomcat-7-trunk/builds/1794 Buildbot URL: http://ci.apache.org/ Buildslave for this Build: bb-vm_ubuntu Build Reason: scheduler Build Source Stamp: [branch tomcat/tc7.0.x/trunk] 1575263 Blamelist: markt Build succeeded! sincerely, -The Buildbot
Re: NIO 2 connector
2014-03-04 17:16 GMT+01:00 Rémy Maucherat r...@apache.org: The code is there (rebased to the current trunk): https://github.com/rmaucher/tomcat Updated commit here: https://github.com/rmaucher/tomcat/commit/614d8c43d8d1f3eeb4d5e4c2493ead589a72bf2c I have removed the two main hacks and the testsuite status is relatively clean (some failures though, but some of theses are tests which have a timing which looks a bit too adapted for the other connectors; I did look individually at all the problems and made some fixes). So far there are 3 people in favor of merging this in the current trunk (still unbranched 8.0). Any additional comments ? Rémy
Please participate in the mod_jk 1.2.39 release vote
Mladen is patient, but please see if you can find some time to check the release and vote. We only have two votes currently and the release is really overdue. If you already had a look at 1.2.38 you might notice, that the delta between the non-released 1.2.38 and 1.2.39 is very small. Thanks for participating! Regards, Rainer - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 49161] Unknown Publisher when installing tomcat 6.0.26
https://issues.apache.org/bugzilla/show_bug.cgi?id=49161 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Mark Thomas ma...@apache.org --- *** This bug has been marked as a duplicate of bug 56079 *** -- 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
[Bug 56079] Digitally sign the Windows binaries
https://issues.apache.org/bugzilla/show_bug.cgi?id=56079 Mark Thomas ma...@apache.org changed: What|Removed |Added CC||mathada.samartha@googlemail ||.com --- Comment #11 from Mark Thomas ma...@apache.org --- *** Bug 49161 has been marked as a duplicate of this bug. *** -- 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
[jira] [Commented] (MTOMCAT-174) tomcatConfigurationFilesDirectory is not implemented
[ https://issues.apache.org/jira/browse/MTOMCAT-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13924165#comment-13924165 ] Romain Manni-Bucau commented on MTOMCAT-174: This still doesn't work on trunk (i tried system.properties file) tomcatConfigurationFilesDirectory is not implemented Key: MTOMCAT-174 URL: https://issues.apache.org/jira/browse/MTOMCAT-174 Project: Apache Tomcat Maven Plugin Issue Type: Task Components: tomcat7 Affects Versions: 2.0-beta-1 Reporter: Robin Böhm Assignee: Olivier Lamy (*$^¨%`£) Fix For: 2.0 Attachments: patch.diff Hey Ya :) the property tomcatConfigurationFilesDirectory is not implemented yet. There is just a field declaration without any handling. Ive written a quick patch for my own project that i assign on this issue. Maybe someone can take this as base for the implementation... -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: NIO 2 connector
2014-03-07 19:17 GMT+04:00 Rémy Maucherat r...@apache.org: 2014-03-04 17:16 GMT+01:00 Rémy Maucherat r...@apache.org: The code is there (rebased to the current trunk): https://github.com/rmaucher/tomcat Updated commit here: https://github.com/rmaucher/tomcat/commit/614d8c43d8d1f3eeb4d5e4c2493ead589a72bf2c I have removed the two main hacks and the testsuite status is relatively clean (some failures though, but some of theses are tests which have a timing which looks a bit too adapted for the other connectors; I did look individually at all the problems and made some fixes). So far there are 3 people in favor of merging this in the current trunk (still unbranched 8.0). 1. It is a month since release 8.0.3 and thus I think 8.0.4 is expected in a week or so.. I am -1 to destabilize 8.0.x now. To this, as you are saying that some tests do not pass. I woudn't want to make buildbot fail this close to a release, as we may miss something important. So I think the time to merge this is not earlier than 8.0.4 is voted and released + some time to cool off. I think that is about 10 days from now. 2. How am I supposed to review this? Is there some viewable patch against trunk? The comments below are from a quick review of https://github.com/rmaucher/tomcat/commit/614d8c43d8d1f3eeb4d5e4c2493ead589a72bf2c 1) There are a number of unrelated changes, including some comment / typo fixes. That does not help reviewing. Why aren't those in Tomcat trunk yet? 2). There is a lot of code that from the first glance seems similar to Nio1 one. Just a matter of preference, not a stopper. (In your opening e-mail you say there are many differences. This similarity is my first impression. Maybe there aren't any. I'd need some time to compare). 3). What are the selling points of this implementation? The documentation part of the patch does not say anything in particular. Also my -1 that it does not say that this connector is an experimental one. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 54315] Redeploying webapp causes NullPointerException in managerBase
https://issues.apache.org/bugzilla/show_bug.cgi?id=54315 --- Comment #17 from Konstantin Kolinko knst.koli...@gmail.com --- (In reply to Mark Thomas from comment #13) re 2, I don't see how this could lead to the constant NPE issue the OP reported unless deployment failed. I said: TH1: in StandardWrapper.allocate() checks for unloading TH1: in StandardWrapper.allocate() waits for synchronized block TH2: executes StandardWrapper.unload() TH1: in StandardWrapper.allocate() obtains the monitor and allocates a servlet Expected: TH1 should not be able to allocate one, as unloading has already happened. I mean that it continues this way: TH2 continues shutting down the context, as it thinks that all wrappers are unloaded and no request processing is happening at this moment. In StandardContext.stopInternal() TH2 has done children[i].stop(); and the next steps that it does are: * filterStop(); * ((Lifecycle) manager).stop(); In ManagerBase.stopInternal() it does this.sessionIdGenerator = null;. TH1: It goes on with request processing and encounters that the session manager has been stopped and manager.sessionIdGenerator is null. This is just a theory, I have not tested it. -- 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: NIO 2 connector
2014-03-07 23:16 GMT+01:00 Konstantin Kolinko knst.koli...@gmail.com: 1. It is a month since release 8.0.3 and thus I think 8.0.4 is expected in a week or so.. I am -1 to destabilize 8.0.x now. As a new component, it is not supposed to destabilize the other components that are in 8.0. To this, as you are saying that some tests do not pass. I woudn't want to make buildbot fail this close to a release, as we may miss something important. It will cause failures only if the tests are enabled for this connector at build time, there's no reason to do so at the moment since it is experimental. So I think the time to merge this is not earlier than 8.0.4 is voted and released + some time to cool off. I think that is about 10 days from now. 2. How am I supposed to review this? Is there some viewable patch against trunk? You just gave the link for the commit below, it shows all possible diffs, and it is rebased against trunk. The comments below are from a quick review of https://github.com/rmaucher/tomcat/commit/614d8c43d8d1f3eeb4d5e4c2493ead589a72bf2c 1) There are a number of unrelated changes, including some comment / typo fixes. That does not help reviewing. Why aren't those in Tomcat trunk yet? There's only a very small amount of them (maybe 3), it shouldn't hinder reviewing in any way. Actually, that's a good idea, I'll go ahead and commit the changes to the existing classes, since I consider they make some sense on their own. I'm not asking for a full review anyway, just some general feedback on the component. 2). There is a lot of code that from the first glance seems similar to Nio1 one. Just a matter of preference, not a stopper. The shared code can be move to a superclass eventually. But it is very different, a lot of major pieces of code from the NIO1 connector have no equivalent. (In your opening e-mail you say there are many differences. This similarity is my first impression. Maybe there aren't any. I'd need some time to compare). 3). What are the selling points of this implementation? I described some of the pros and cons of the NIO2 API. If the pros end up in the implementation without being degraded, it means the connector should be faster, more resources friendly, simpler (no poller, no selector, etc), since that's what happened with a similar NIO2 connector in JBoss. But I can't make any big promises yet. The documentation part of the patch does not say anything in particular. Also my -1 that it does not say that this connector is an experimental one. On startup, it logs: WARNING [main] org.apache.tomcat.util.net.Nio2Endpoint.startInternal The NIO2 connector is currently EXPERIMENTAL and should not be used in production So it is annoyingly visible, but I can add another mention in the docs. Rémy
