[Bug 63206] New: Try to create parent directories before writing an uploaded file to disk
https://bz.apache.org/bugzilla/show_bug.cgi?id=63206 Bug ID: 63206 Summary: Try to create parent directories before writing an uploaded file to disk Product: Tomcat 8 Version: 8.5.38 Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: awilkin...@pivotal.io Target Milestone: When processing a multi-part upload and parsing the parts, a check is made that the output location is a directory. If it is not, an exception is thrown. By contrast, Jetty will try to create the directory [1] before writing the uploaded file into it. I wonder if Tomcat could be modified to behave in the same way as Jetty? In addition to helping the user out when they have configured the output location before have forgotten to create it, it will also help in situations where files are being uploaded to a location within /tmp or similar and it has been deleted by tmpwatch due to a period of inactivity. [1] https://github.com/eclipse/jetty.project/blob/34b2678e6d2b164088dcec0ef9e66f1148a8a527/jetty-http/src/main/java/org/eclipse/jetty/http/MultiPartFormInputStream.java#L522-L523 -- 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 63206] Try to create parent directories before writing an uploaded file to disk
https://bz.apache.org/bugzilla/show_bug.cgi?id=63206 --- Comment #1 from Christopher Schultz --- I'm a -1 on this unless it is a configurable option and disabled by default. Tomcat shouldn't be creating directories unless explicitly directed to do so. -- 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
DEBUG binaries for win32/win64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, At the risk of making the build for Windows even more onerous, would it be possible to distribute DEBUG builds along with the standard ones? The native stack trace in this bug report[1] for example is non-existent and useless because it just says: # Problematic frame: # C [tcnative-1.dll+0x60895] If I had a Windows development environment and that same version from the svn branch and my compiler settings were exactly what was used by the Release Manager for that particular version, I might be able to resolve tcnative-1.dll+0x60895 to the right function and, nf I'm lucky, the right line of code. But the compiler can build all that into the binary, so why bother fiddling with all that nonsense? We should be able to tell the bug-reporter "please replace the regular build with the DEBUG one and try again to get better data" and, likely, we'll get better data. WDYT? Thanks, - -chris [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=63199#c0 -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxz+Q4ACgkQHPApP6U8 pFhuuBAAuTVcPtYBP7IsXhcIOdvOnL4mitk4WvxrkDjdzkP2/RwWE0xckBMqNKZl bzCKHCWO/1VjG33623aCWLeklk9/HXhErTjULvXPwmoplgUJTBmIrWC9lxZ98nD0 sZlANeJG9nCYvNxQWX09qHGYQPfLFW3dAj0sp860diEpKfrfmiHU6V0XF+egWoJF Lemx7nD5a23EpoKVPHdsgTFImrKa/APw/4g8L3yDVGmyzEfUzfF959iKztRsYt2c +zMG/iX7ybvDxfQn6RP9Rku2GAOSBKkuR1UCz3L7Aq5Dc9ZmkLnyPzc0jdzv/sqn A6/aVWXfajIIRrH2niKASwXUtxU6WTgJNi9QDqw+/cqOdj3RlAzbyIxTn5zYwLew uYLzmubaTd84e8g2L57KCiukjiiz4aYRX8eeWTcHSiJisqVZHNavpQMTqCBZLBrC iR3XsL5gRBBjkFlUSuBEQ+mXq7WQUhMWiwTH3U3VtGAVrOSMX5AUC/6jm9Z+TQ+K c/Brz7tlcSLXnLOTsO7ZhgVagl9HVtw07wuf1LlvDXhAVQq25XEatEv+25M8+zhH gms7hKNNYpF6h+0DpddPWfvC9+cGQ5jrMcCHBAz7YwJvYY8J9SO5xDkB4cXdXCqo HnGl2TsRKb824s2hxbTuIhuGgxAIUpco3C/MXNmq2/1/NVEiJp0= =KSaq -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63205] Unable to load certificate store on openjdk
https://bz.apache.org/bugzilla/show_bug.cgi?id=63205 --- Comment #1 from Christopher Schultz --- While we generally don't work-around JVM bugs, this one was reported back in 2016 and doesn't look like there is much likleihood that it will be fixed. -- 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: DEBUG binaries for win32/win64
On 25/02/2019 14:17, Christopher Schultz wrote: > All, > > At the risk of making the build for Windows even more onerous, would > it be possible to distribute DEBUG builds along with the standard ones? > > The native stack trace in this bug report[1] for example is > non-existent and useless because it just says: > > # Problematic frame: > # C [tcnative-1.dll+0x60895] > > If I had a Windows development environment and that same version from > the svn branch and my compiler settings were exactly what was used by > the Release Manager for that particular version, I might be able to > resolve tcnative-1.dll+0x60895 to the right function and, nf I'm > lucky, the right line of code. > > But the compiler can build all that into the binary, so why bother > fiddling with all that nonsense? We should be able to tell the > bug-reporter "please replace the regular build with the DEBUG one and > try again to get better data" and, likely, we'll get better data. > > WDYT? It probably means debug builds for OpenSSL and APR as well. Speaking as the current RM, if someone updates [2] I have no objection to turning the handle. If the expectation is that I figure out what changes are required then it will happen (I think it is a good idea) but it is going to take longer. Mark [2] https://cwiki.apache.org/confluence/display/TOMCAT/Building+the+Tomcat+Native+Connector+binaries+for+Windows > > Thanks, > -chris > > [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=63199#c0 > > - > 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
[Bug 63206] Try to create parent directories before writing an uploaded file to disk
https://bz.apache.org/bugzilla/show_bug.cgi?id=63206 --- Comment #2 from Remy Maucherat --- (In reply to Christopher Schultz from comment #1) > I'm a -1 on this unless it is a configurable option and disabled by default. > Tomcat shouldn't be creating directories unless explicitly directed to do so. +1 for that. -- 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: Git migration: new branch/tag naming scheme
пн, 18 февр. 2019 г. в 11:08, Emmanuel Bourg > > Le 16/02/2019 à 16:09, Michael Osipov a écrit : > > > The given approach, for whatsoever reason, performs an uppercase and > > replaces dots with underscores. This reduces readability, but also > > requires people (esp. package maintainers) to perform sed(1) magic to > > convert back and forth. > > I agree this is cumbersome, we are doing this kind of manipulation in > Debian too to compare the version packaged with the latest upstream release. > 1. What do we do with RC and milestone release tags, e.g. TOMCAT_7_0_0_RC4, TOMCAT_9_0_0_M27? 9.0.0.M27, 9.0.0-M27, 9.0.0_M27, or the same with lowercase 'm'? Historically, Tomcat 9 used a dot "9.0.0.M27" in announcements and in filenames [1][2], Tomcat 8 used a dash "8.0.0-RC10" in announcements and filenames [3][4] . Tomcat 7 used a "-beta" suffix in filenames [5]. Different downstream packagers (e.g. Maven, RPM) may have different rules regarding handling and sorting such names. The '-' symbol may be special. [1] http://tomcat.apache.org/oldnews-2016.html [2] https://archive.apache.org/dist/tomcat/tomcat-9/ [3] http://tomcat.apache.org/oldnews-2013.html [4] https://archive.apache.org/dist/tomcat/tomcat-8/ [5] https://archive.apache.org/dist/tomcat/tomcat-7/ My preference is to stick with the current historical format of tag names (TOMCAT_) and let downstream deal with proper parsing and formatting of these numbers. > to perform sed(1) magic 2. The prefix "TOMCAT_x_y_" is fixed in a particular branch and has known length. I had processed similar strings with 'cut' utility [6]. This can also be processed by parameters substitution in shell [7]. Though somebody may call that magic as well. [6] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/cut.html [7] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_02 Best regards, Konstantin Kolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [RESULT][VOTE] Migrate to git
The following votes were cast: Binding: +1: funkman, csutherl, fschumacher, mgrigorov, remm, ebourg, violetagg, mturk, kfugino, markt Non-Binding: +1: woonsan, michaelo, isapir The vote therefore passes. A big thank you to everyone who contributed to the discussions we have had on this migration. Please keep an eye on the dev@ list for any admin notices as the migration progresses. Thanks, Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: DEBUG binaries for win32/win64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 2/25/19 09:42, Mark Thomas wrote: > On 25/02/2019 14:17, Christopher Schultz wrote: >> All, >> >> At the risk of making the build for Windows even more onerous, >> would it be possible to distribute DEBUG builds along with the >> standard ones? >> >> The native stack trace in this bug report[1] for example is >> non-existent and useless because it just says: >> >> # Problematic frame: # C [tcnative-1.dll+0x60895] >> >> If I had a Windows development environment and that same version >> from the svn branch and my compiler settings were exactly what >> was used by the Release Manager for that particular version, I >> might be able to resolve tcnative-1.dll+0x60895 to the right >> function and, nf I'm lucky, the right line of code. >> >> But the compiler can build all that into the binary, so why >> bother fiddling with all that nonsense? We should be able to tell >> the bug-reporter "please replace the regular build with the DEBUG >> one and try again to get better data" and, likely, we'll get >> better data. >> >> WDYT? > > It probably means debug builds for OpenSSL and APR as well. > > Speaking as the current RM, if someone updates [2] I have no > objection to turning the handle. If the expectation is that I > figure out what changes are required then it will happen (I think > it is a good idea) but it is going to take longer. I think (*think*!) that building a debug version of a binary with msvc++ just requires adding /DEBUG to the command-line, so it should be fairly straightforward. Building tcnative with /DEBUG should be easy even if we don't bundle a DEBUG version of APR and/or OpenSSL. Can we try that to begin with? Thanks, - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlx0BOQACgkQHPApP6U8 pFgQmQ/+LaZX5vRFlrKEGfkCdcy14atOBL0mxwQT7g42wkiCqiyc+RwEkXcoVj0D tiSKGm/7cha4Vp20Ni+jVMsHff1oaOhY5i/5KJTWaPwH7FCpMcfkH7dPyOJVMqc3 fofyWxgr/41kRI2HPDgkKrF+e87xrrOF+Z2JGEnLnoSWAGxv02Bd6oevE0VYEpH1 6tCCRVIUzCdsnzouMzn2kIUhtYvyb3v1uYTqWvxIlnRgSB2OtIzweM07PNyOhse9 GiVn0EahK3wHy9Wm7V07g7TI1JckZZaxIpmmAEzxfZFCw2nm1rhnCHc2ldPgyWMS /2bbN+oEqwJiIZRVM3r2NhZn35UXcFS9s/tkM/69WFMho81oFYylk/eFfhDqtkpU UBXdQ2svsTyIfNJNFzIDSCjOLttmfKjC+8NIeiTK3eEoBTBW5q/PAcPhOqYaEwje ZtSAeqwrnmNwXU1sZ6EiiyafK0uFmWDgREaF+M8QjGBsacv21DdqqKlQIEWDMiFk Y0QaVKGfAycYLYkPHdvvGkAOVsvBuY5SIFrJja00MBXfqHSgMjSPPo3xBCEGyISa OAVVad9AMVRMPLHgvf/5kuDm71YpgYBQxWZZQP6eU7r9e9qQmYgvvRdl6LAGSxZi 3cd513CXHEBqPrrxhQKG1p8oE76BVsThF9K6TLlktubr8jqGLZI= =ak/E -END PGP SIGNATURE- - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63206] Try to create parent directories before writing an uploaded file to disk
https://bz.apache.org/bugzilla/show_bug.cgi?id=63206 --- Comment #3 from Andy Wilkinson --- > Tomcat shouldn't be creating directories unless explicitly directed to do so. That seems a little arbitrary to apply that rule in this case. Tomcat already creates directories in several places. A few examples from a non-exhaustive search of the codebase: - JspCompilationContext will create the output directory if needed during JSP compilation [1] - Tomcat will create the base directory during startup if needed [2] - StandardContext will create its work directory if needed [3] As far as I know, and as far as I can tell from looking at the code, in each of these cases it's the default behaviour to create the directory. I also think it's of benefit to Tomcat's usability that it does so. I can't see why the location used for multipart uploads should be treated any differently. [1] https://github.com/apache/tomcat/blob/c4b006e3dd46ca8604b2c9418a4714b6261aab7c/java/org/apache/jasper/JspCompilationContext.java#L674 [2] https://github.com/apache/tomcat/blob/d9c4f3fcd622c04db8598aa25f0ab5781ea2421f/java/org/apache/catalina/startup/Tomcat.java#L813 [3] https://github.com/apache/tomcat/blob/b4ad8fa8e03b870ee320ac3239059abc08fe1f58/java/org/apache/catalina/core/StandardContext.java#L6053 -- 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
No commits to svn trunk, 8.5.x and 7.0.x after 2019-02-26 07.00 UTC
All, I have informed ASF Infrastructure that they can disable the svn -> git replication any time after 07.00 UTC tomorrow. Please, to keep the migration simple, DO NOT commit to trunk, 8.5.x or 7.0.x after this time. I will notify the list when the git repo is ready for general writing. Note: You will almost certainly see writes from me to the git repo being reported to the mailing list. Please don't take this to mean it is ready for general writes. I will send out a mail when it is ready. Please be aware that we are not planning on disabling committer write access to svn or git at any point during the migration. We intend to rely on social controls only. If this doesn't work my back-up plan is to remove all the committers and PMC members from the relevant LDAP groups, complete the migration and then re-add them. (This is simpler that trying to implement a custom authentication scheme for the duration of the migration.) Thanks, Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: [VOTE] Migrate to git
Hi, > > > > This is a VOTE to migrate the primary source code repository for Apache > > Tomcat 9.0.x, 8.5.x and 7.0.x from svn to git. > > [X] +1 Go ahead with the migration Thanks for the work! -- Best Regards！ Huxing - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 63206] Try to create parent directories before writing an uploaded file to disk
https://bz.apache.org/bugzilla/show_bug.cgi?id=63206
--- Comment #4 from Konstantin Kolinko ---
I think the OP means the following:
If ${catalina.base}/temp directory does not exist, file upload fails.
Unlike ${catalina.base}/work, the "temp" directory is not created automatically
at start time.
Tomcat release packages have a "safeToDelete.tmp" file in the temp directory to
make sure that is is created, as either zip or tar file format does not allow
empty directories.
> a configurable option
Implement as a Listener, configurable in server.xml?
--
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 63206] Try to create parent directories before writing an uploaded file to disk
https://bz.apache.org/bugzilla/show_bug.cgi?id=63206 --- Comment #5 from Christopher Schultz --- (In reply to Andy Wilkinson from comment #3) > > Tomcat shouldn't be creating directories unless explicitly directed to do > > so. > > That seems a little arbitrary to apply that rule in this case. I disagree. > Tomcat already creates directories in several places. A few examples from a > non-exhaustive search of the codebase: > > - JspCompilationContext will create the output directory if needed during > JSP compilation [1] > - Tomcat will create the base directory during startup if needed [2] > - StandardContext will create its work directory if needed [3] Those are all directories that Tomcat manages by itself. If the application, via or @MultipartConfig, sets an output directory, then Tomcat should not be creating that on its own without a specific request to do so. I don't find the distinction arbitrary at all. > As far as I know, and as far as I can tell from looking at the code, in each > of these cases it's the default behaviour to create the directory. I also > think it's of benefit to Tomcat's usability that it does so. I can't see why > the location used for multipart uploads should be treated any differently. Because it can be set by the application and is not configured and/or managed by Tomcat. -- 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 63206] Try to create parent directories before writing an uploaded file to disk
https://bz.apache.org/bugzilla/show_bug.cgi?id=63206
--- Comment #6 from Christopher Schultz ---
(In reply to Konstantin Kolinko from comment #4)
> I think the OP means the following:
> If ${catalina.base}/temp directory does not exist, file upload fails.
>
> Unlike ${catalina.base}/work, the "temp" directory is not created
> automatically at start time.
Auto-creation of the ${catalina.base}/temp directory would be okay with me, but
not the creation of arbitrary "external" directories. IMO, each application
should have its own segregated "uploads" directory, so maybe
${catalina.base}/work/[engine]/[host]/[app]/temp.
As of now, it would interfere with the package namespace for JSPs, so compiled
JSP files ought to go into a "jsp" subdirectory. But that's a fairly major
change.
> Implement as a Listener, configurable in server.xml?
Easy enough to do, but this is really an engine-specific option. Or maybe even
host-specific.
--
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 63206] Try to create parent directories before writing an uploaded file to disk
https://bz.apache.org/bugzilla/show_bug.cgi?id=63206 --- Comment #7 from Andy Wilkinson --- > Because it can be set by the application and is not configured and/or managed > by Tomcat. That was a distinction that you did not make when you stated the following: > Tomcat shouldn't be creating directories unless explicitly directed to do so. Even with that new distinction, I'm not sure that I agree. Why should a usability benefit that is applied to Tomcat itself not also applied to an application that is deployed to Tomcat? Put another way, what harm could be caused by creating the directory? It's also possible that the application does not customise the location via or @MultipartConfig. In that case the location is both configured and managed by Tomcat yet the directory will not be created. That seems unnecessarily inconsistent to me. -- 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 63206] Try to create parent directories before writing an uploaded file to disk
https://bz.apache.org/bugzilla/show_bug.cgi?id=63206 --- Comment #8 from Mark Thomas --- There may be circumstances (e.g. when running under a security manager or due to file system permissions) where it will not be possible to create the directory even if the container tries to do so. This feels like the sort of thing that an application developer should have to take responsibility for so that they give some thought to issues such as: - where the files are uploaded to - how much space is available - file permissions for this location Configuration can be per context as the relevant code already has access to the Context object. My preference is for disabled by default with an option to enable. Also, at least an INFO message when the directory is created. Maybe WARN. Certainly not ERROR. -- 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: r1854326 - in /tomcat/trunk: java/org/apache/tomcat/util/net/ java/org/apache/tomcat/util/net/openssl/ test/org/apache/tomcat/util/net/ webapps/docs/
Author: markt
Date: Mon Feb 25 17:38:35 2019
New Revision: 1854326
URL: http://svn.apache.org/viewvc?rev=1854326&view=rev
Log:
Refactor to a) reduce duplication and b) enable JSSE style config to be
used with APR
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java
tomcat/trunk/java/org/apache/tomcat/util/net/AbstractJsseEndpoint.java
tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
tomcat/trunk/java/org/apache/tomcat/util/net/LocalStrings.properties
tomcat/trunk/java/org/apache/tomcat/util/net/openssl/OpenSSLContext.java
tomcat/trunk/test/org/apache/tomcat/util/net/TestSSLHostConfigCompat.java
tomcat/trunk/webapps/docs/changelog.xml
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java?rev=1854326&r1=1854325&r2=1854326&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java Mon Feb
25 17:38:35 2019
@@ -314,13 +314,34 @@ public abstract class AbstractEndpointhttp://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/AbstractJsseEndpoint.java?rev=1854326&r1=1854325&r2=1854326&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/AbstractJsseEndpoint.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/AbstractJsseEndpoint.java Mon
Feb 25 17:38:35 2019
@@ -117,28 +117,6 @@ public abstract class AbstractJsseEndpoi
}
-protected void destroySsl() throws Exception {
-if (isSSLEnabled()) {
-for (SSLHostConfig sslHostConfig : sslHostConfigs.values()) {
-releaseSSLContext(sslHostConfig);
-}
-}
-}
-
-
-@Override
-protected void releaseSSLContext(SSLHostConfig sslHostConfig) {
-for (SSLHostConfigCertificate certificate :
sslHostConfig.getCertificates(true)) {
-if (certificate.getSslContext() != null) {
-SSLContext sslContext = certificate.getSslContext();
-if (sslContext != null) {
-sslContext.destroy();
-}
-}
-}
-}
-
-
protected SSLEngine createSSLEngine(String sniHostName, List
clientRequestedCiphers,
List clientRequestedApplicationProtocols) {
SSLHostConfig sslHostConfig = getSSLHostConfig(sniHostName);
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java?rev=1854326&r1=1854325&r2=1854326&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java Mon Feb 25
17:38:35 2019
@@ -24,7 +24,6 @@ import java.nio.ByteBuffer;
import java.nio.charset.StandardCharsets;
import java.util.ArrayList;
import java.util.HashMap;
-import java.util.List;
import java.util.Map;
import java.util.Set;
import java.util.concurrent.ConcurrentHashMap;
@@ -43,7 +42,6 @@ import org.apache.tomcat.jni.OS;
import org.apache.tomcat.jni.Poll;
import org.apache.tomcat.jni.Pool;
import org.apache.tomcat.jni.SSL;
-import org.apache.tomcat.jni.SSLConf;
import org.apache.tomcat.jni.SSLContext;
import org.apache.tomcat.jni.SSLContext.SNICallBack;
import org.apache.tomcat.jni.SSLSocket;
@@ -56,8 +54,8 @@ import org.apache.tomcat.util.collection
import org.apache.tomcat.util.net.AbstractEndpoint.Handler.SocketState;
import org.apache.tomcat.util.net.Acceptor.AcceptorState;
import org.apache.tomcat.util.net.SSLHostConfig.Type;
-import org.apache.tomcat.util.net.openssl.OpenSSLConf;
-import org.apache.tomcat.util.net.openssl.OpenSSLEngine;
+import org.apache.tomcat.util.net.openssl.OpenSSLContext;
+import org.apache.tomcat.util.net.openssl.OpenSSLUtil;
/**
@@ -382,6 +380,14 @@ public class AprEndpoint extends Abstrac
Long defaultSSLContext = defaultSSLHostConfig.getOpenSslContext();
sslContext = defaultSSLContext.longValue();
SSLContext.registerDefault(defaultSSLContext, this);
+
+// For now, sendfile is not supported with SSL
+if (getUseSendfile()) {
+setUseSendfileInternal(false);
+if (useSendFileSet) {
+log.warn(sm.getString("endpoint.apr.noSendfileWithSSL"));
+}
+}
}
}
@@ -389,249 +395,29 @@ public class AprEndpoint extends Abstrac
@Override
protected void createSSLContext(SSLHostConfig sslHostConfig) throws
Exception {
+OpenSSLContext sslContext = null;
Set cert
svn commit: r1854327 - in /tomcat/tc8.5.x/trunk: ./ java/org/apache/tomcat/util/net/ java/org/apache/tomcat/util/net/openssl/ test/org/apache/tomcat/util/net/ webapps/docs/
Author: markt Date: Mon Feb 25 17:49:28 2019 New Revision: 1854327 URL: http://svn.apache.org/viewvc?rev=1854327&view=rev Log: Refactor to a) reduce duplication and b) enable JSSE style config to be used with APR Modified: tomcat/tc8.5.x/trunk/ (props changed) tomcat/tc8.5.x/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java tomcat/tc8.5.x/trunk/java/org/apache/tomcat/util/net/AbstractJsseEndpoint.java tomcat/tc8.5.x/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java tomcat/tc8.5.x/trunk/java/org/apache/tomcat/util/net/LocalStrings.properties tomcat/tc8.5.x/trunk/java/org/apache/tomcat/util/net/openssl/OpenSSLContext.java tomcat/tc8.5.x/trunk/test/org/apache/tomcat/util/net/TestSSLHostConfigCompat.java tomcat/tc8.5.x/trunk/webapps/docs/changelog.xml Propchange: tomcat/tc8.5.x/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Mon Feb 25 17:49:28 2019 @@ -1,2 +1,2 @@ /tomcat/tc8.0.x/trunk:1809644 -/tomcat/trunk:1734785,1734799,1734845,1734928,1735041,1735044,1735480,1735577,1735597,1735599-1735600,1735615,1736145,1736162,1736209,1736280,1736297,1736299,1736489,1736646,1736703,1736836,1736849,1737104-1737105,1737112,1737117,1737119-1737120,1737155,1737157,1737192,1737280,1737339,1737632,1737664,1737715,1737748,1737785,1737834,1737860,1737903,1737959,1738005,1738007,1738014-1738015,1738018,1738022,1738039,1738043,1738059-1738060,1738147,1738149,1738174-1738175,1738261,1738589,1738623-1738625,1738643,1738816,1738850,1738855,1738946-1738948,1738953-1738954,1738979,1738982,1739079-1739081,1739087,1739113,1739153,1739172,1739176,1739191,1739474,1739492,1739726,1739762,1739775,1739814,1739817-1739818,1739975,1740131,1740324,1740465,1740495,1740508-1740509,1740520,1740535,1740707,1740803,1740810,1740969,1740980,1740991,1740997,1741015,1741033,1741036,1741058,1741060,1741080,1741147,1741159,1741164,1741173,1741181,1741190,1741197,1741202,1741208,1741213,1741221,1741225,1741232,1741409 ,1741501,1741677,1741892,1741896,1741984,1742023,1742042,1742071,1742090,1742093,1742101,1742105,1742111,1742139,1742146,1742148,1742166,1742181,1742184,1742187,1742246,1742248-1742251,1742263-1742264,1742268,1742276,1742369,1742387,1742448,1742509-1742512,1742917,1742919,1742933,1742975-1742976,1742984,1742986,1743019,1743115,1743117,1743124-1743125,1743134,1743425,1743554,1743679,1743696-1743698,1743700-1743701,1744058,1744064-1744065,1744125,1744149,1744194,1744229,1744270,1744323,1744432,1744684,1744697,1744705,1744713,1744760,1744786,1745083,1745142-1745143,1745145,1745177,1745179-1745180,1745227,1745248,1745254,1745337,1745467,1745473,1745535,1745576,1745735,1745744,1746304,1746306-1746307,1746319,1746327,1746338,1746340-1746341,1746344,1746427,1746441,1746473,1746490,1746492,1746495-1746496,1746499-1746501,1746503-1746507,1746509,1746549,1746551,1746554,1746556,1746558,1746584,1746620,1746649,1746724,1746939,1746989,1747014,1747028,1747035,1747210,1747225,1747234,1747253,1747 404,1747506,1747536,1747924,1747980,1747993,1748001,1748253,1748452,1748547,1748629,1748676,1748715,1749287,1749296,1749328,1749373,1749465,1749506,1749508,1749665-1749666,1749763,1749865-1749866,1749898,1749978,1749980,1750011,1750015,1750056,1750480,1750617,1750634,1750692,1750697,1750700,1750703,1750707,1750714,1750718,1750723,1750774,1750899,1750975,1750995,1751061,1751097,1751173,1751438,1751447,1751463,1751702,1752212,1752737,1752745,1753078,1753080,1753358,1753363,1754111,1754140-1754141,1754281,1754310,1754445,1754467,1754494,1754496,1754528,1754532-1754533,1754613,1754714,1754874,1754941,1754944,1754950-1754951,1755005,1755007,1755009,1755132,1755180-1755181,1755185,1755190,1755204-1755206,1755208,1755214,1755224,1755227,1755230,1755629,1755646-1755647,1755650,1755653,1755675,1755680,1755683,1755693,1755717,1755731-1755737,1755812,1755828,1755884,1755890,1755918-1755919,1755942,1755958,1755960,1755970,1755993,1756013,1756019,1756039,1756056,1756083-1756114,1756175,1756288-1 756289,1756408-1756410,1756778,1756798,1756878,1756898,1756939,1757123-1757124,1757126,1757128,1757132-1757133,1757136,1757145,1757167-1757168,1757175,1757180,1757182,1757195,1757271,1757278,1757347,1757353-1757354,1757363,1757374,1757399,1757406,1757408,1757485,1757495,1757499,1757527,1757578,1757684,1757722,1757727,1757790,1757799,1757813,1757853,1757883,1757903,1757976,1757997,1758000,1758058,1758072-1758075,1758078-1758079,1758223,1758257,1758261,1758276,1758292,1758369,1758378-1758383,1758421,1758423,1758425-1758427,1758430,1758443,1758448,1758459,1758483,1758486-1758487,1758499,1758525,1758556,1758580,1758582,1758584,1758588,1758842,1759019,1759212,1759224,1759227,1759252,1759274,1759513-1759516,1759611,1759757,1759785-1759790,1760005,1760022,1760109-1760110,1760135,1760200-1760201,1760227,1760300,1760397,1760446,1760454,1760640,1760648,1761057,1761422,1761491,1761498,1761500-1761501,1761550,1761553,1761572,1761574,1761625-1761626,1
svn commit: r1854328 - in /tomcat/trunk/test/org/apache/tomcat/util/net: TesterSupport.java keystore-info.txt localhost-copy1.jks localhost-rsa-copy1.jks localhost-rsa.jks localhost.jks
Author: markt
Date: Mon Feb 25 17:59:13 2019
New Revision: 1854328
URL: http://svn.apache.org/viewvc?rev=1854328&view=rev
Log:
Rename keystore files in preparation for adding an EC keystore
Added:
tomcat/trunk/test/org/apache/tomcat/util/net/localhost-rsa-copy1.jks
- copied unchanged from r1854327,
tomcat/trunk/test/org/apache/tomcat/util/net/localhost-copy1.jks
tomcat/trunk/test/org/apache/tomcat/util/net/localhost-rsa.jks
- copied unchanged from r1854327,
tomcat/trunk/test/org/apache/tomcat/util/net/localhost.jks
Removed:
tomcat/trunk/test/org/apache/tomcat/util/net/localhost-copy1.jks
tomcat/trunk/test/org/apache/tomcat/util/net/localhost.jks
Modified:
tomcat/trunk/test/org/apache/tomcat/util/net/TesterSupport.java
tomcat/trunk/test/org/apache/tomcat/util/net/keystore-info.txt
Modified: tomcat/trunk/test/org/apache/tomcat/util/net/TesterSupport.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/tomcat/util/net/TesterSupport.java?rev=1854328&r1=1854327&r2=1854328&view=diff
==
--- tomcat/trunk/test/org/apache/tomcat/util/net/TesterSupport.java (original)
+++ tomcat/trunk/test/org/apache/tomcat/util/net/TesterSupport.java Mon Feb 25
17:59:13 2019
@@ -69,8 +69,8 @@ public final class TesterSupport {
public static final String CA_JKS = SSL_DIR + CA_ALIAS + ".jks";
public static final String CLIENT_ALIAS = "user1";
public static final String CLIENT_JKS = SSL_DIR + CLIENT_ALIAS + ".jks";
-public static final String LOCALHOST_JKS = SSL_DIR + "localhost.jks";
-public static final String LOCALHOST_KEYPASS_JKS = SSL_DIR +
"localhost-copy1.jks";
+public static final String LOCALHOST_JKS = SSL_DIR + "localhost-rsa.jks";
+public static final String LOCALHOST_KEYPASS_JKS = SSL_DIR +
"localhost-rsa-copy1.jks";
public static final String JKS_PASS = "changeit";
public static final String JKS_KEY_PASS = "tomcatpass";
public static final String CA_CERT_PEM = SSL_DIR + CA_ALIAS + "-cert.pem";
Modified: tomcat/trunk/test/org/apache/tomcat/util/net/keystore-info.txt
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/tomcat/util/net/keystore-info.txt?rev=1854328&r1=1854327&r2=1854328&view=diff
==
--- tomcat/trunk/test/org/apache/tomcat/util/net/keystore-info.txt (original)
+++ tomcat/trunk/test/org/apache/tomcat/util/net/keystore-info.txt Mon Feb 25
17:59:13 2019
@@ -18,10 +18,10 @@
ca.jks (changeit)
caCN=Apache Tomcat Test CA
-localhost.jks (changeit)
+localhost-rsa.jks (changeit)
tomcatCN=localhost
-localhost-copy1.jks (changeit)
+localhost-rsa-copy1.jks (changeit)
tomcatCN=localhost (tomcatpass)
user1.jks (changeit)
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1854339 - in /tomcat/tc8.5.x/trunk: ./ test/org/apache/tomcat/util/net/
Author: markt Date: Mon Feb 25 21:00:44 2019 New Revision: 1854339 URL: http://svn.apache.org/viewvc?rev=1854339&view=rev Log: Rename keystore files in preparation for adding an EC keystore Added: tomcat/tc8.5.x/trunk/test/org/apache/tomcat/util/net/localhost-rsa-copy1.jks - copied unchanged from r1854328, tomcat/trunk/test/org/apache/tomcat/util/net/localhost-rsa-copy1.jks tomcat/tc8.5.x/trunk/test/org/apache/tomcat/util/net/localhost-rsa.jks - copied unchanged from r1854328, tomcat/trunk/test/org/apache/tomcat/util/net/localhost-rsa.jks Removed: tomcat/tc8.5.x/trunk/test/org/apache/tomcat/util/net/localhost-copy1.jks tomcat/tc8.5.x/trunk/test/org/apache/tomcat/util/net/localhost.jks Modified: tomcat/tc8.5.x/trunk/ (props changed) tomcat/tc8.5.x/trunk/test/org/apache/tomcat/util/net/TesterSupport.java tomcat/tc8.5.x/trunk/test/org/apache/tomcat/util/net/keystore-info.txt Propchange: tomcat/tc8.5.x/trunk/ -- --- svn:mergeinfo (original) +++ svn:mergeinfo Mon Feb 25 21:00:44 2019 @@ -1,2 +1,2 @@ /tomcat/tc8.0.x/trunk:1809644 -/tomcat/trunk:1734785,1734799,1734845,1734928,1735041,1735044,1735480,1735577,1735597,1735599-1735600,1735615,1736145,1736162,1736209,1736280,1736297,1736299,1736489,1736646,1736703,1736836,1736849,1737104-1737105,1737112,1737117,1737119-1737120,1737155,1737157,1737192,1737280,1737339,1737632,1737664,1737715,1737748,1737785,1737834,1737860,1737903,1737959,1738005,1738007,1738014-1738015,1738018,1738022,1738039,1738043,1738059-1738060,1738147,1738149,1738174-1738175,1738261,1738589,1738623-1738625,1738643,1738816,1738850,1738855,1738946-1738948,1738953-1738954,1738979,1738982,1739079-1739081,1739087,1739113,1739153,1739172,1739176,1739191,1739474,1739492,1739726,1739762,1739775,1739814,1739817-1739818,1739975,1740131,1740324,1740465,1740495,1740508-1740509,1740520,1740535,1740707,1740803,1740810,1740969,1740980,1740991,1740997,1741015,1741033,1741036,1741058,1741060,1741080,1741147,1741159,1741164,1741173,1741181,1741190,1741197,1741202,1741208,1741213,1741221,1741225,1741232,1741409 ,1741501,1741677,1741892,1741896,1741984,1742023,1742042,1742071,1742090,1742093,1742101,1742105,1742111,1742139,1742146,1742148,1742166,1742181,1742184,1742187,1742246,1742248-1742251,1742263-1742264,1742268,1742276,1742369,1742387,1742448,1742509-1742512,1742917,1742919,1742933,1742975-1742976,1742984,1742986,1743019,1743115,1743117,1743124-1743125,1743134,1743425,1743554,1743679,1743696-1743698,1743700-1743701,1744058,1744064-1744065,1744125,1744149,1744194,1744229,1744270,1744323,1744432,1744684,1744697,1744705,1744713,1744760,1744786,1745083,1745142-1745143,1745145,1745177,1745179-1745180,1745227,1745248,1745254,1745337,1745467,1745473,1745535,1745576,1745735,1745744,1746304,1746306-1746307,1746319,1746327,1746338,1746340-1746341,1746344,1746427,1746441,1746473,1746490,1746492,1746495-1746496,1746499-1746501,1746503-1746507,1746509,1746549,1746551,1746554,1746556,1746558,1746584,1746620,1746649,1746724,1746939,1746989,1747014,1747028,1747035,1747210,1747225,1747234,1747253,1747 404,1747506,1747536,1747924,1747980,1747993,1748001,1748253,1748452,1748547,1748629,1748676,1748715,1749287,1749296,1749328,1749373,1749465,1749506,1749508,1749665-1749666,1749763,1749865-1749866,1749898,1749978,1749980,1750011,1750015,1750056,1750480,1750617,1750634,1750692,1750697,1750700,1750703,1750707,1750714,1750718,1750723,1750774,1750899,1750975,1750995,1751061,1751097,1751173,1751438,1751447,1751463,1751702,1752212,1752737,1752745,1753078,1753080,1753358,1753363,1754111,1754140-1754141,1754281,1754310,1754445,1754467,1754494,1754496,1754528,1754532-1754533,1754613,1754714,1754874,1754941,1754944,1754950-1754951,1755005,1755007,1755009,1755132,1755180-1755181,1755185,1755190,1755204-1755206,1755208,1755214,1755224,1755227,1755230,1755629,1755646-1755647,1755650,1755653,1755675,1755680,1755683,1755693,1755717,1755731-1755737,1755812,1755828,1755884,1755890,1755918-1755919,1755942,1755958,1755960,1755970,1755993,1756013,1756019,1756039,1756056,1756083-1756114,1756175,1756288-1 756289,1756408-1756410,1756778,1756798,1756878,1756898,1756939,1757123-1757124,1757126,1757128,1757132-1757133,1757136,1757145,1757167-1757168,1757175,1757180,1757182,1757195,1757271,1757278,1757347,1757353-1757354,1757363,1757374,1757399,1757406,1757408,1757485,1757495,1757499,1757527,1757578,1757684,1757722,1757727,1757790,1757799,1757813,1757853,1757883,1757903,1757976,1757997,1758000,1758058,1758072-1758075,1758078-1758079,1758223,1758257,1758261,1758276,1758292,1758369,1758378-1758383,1758421,1758423,1758425-1758427,1758430,1758443,1758448,1758459,1758483,1758486-1758487,1758499,1758525,1758556,1758580,1758582,1758584,1758588,1758842,1759019,1759212,1759224,1759227,1759252,1759274,1759513-1759516,1759611,1759757,1759785-1759790,1760005,1760022,1760109-1760110,1760135,1760200-1760201,1760227,1760300,1760397,1760446,176
Re: [VOTE] Migrate to git
Vote is closed I'm just a lurker, but non-binding +1 from me :) Great to see this! -David > On Feb 21, 2019, at 8:13 AM, Mark Thomas wrote: > > This is a VOTE to migrate the primary source code repository for Apache > Tomcat 9.0.x, 8.5.x and 7.0.x from svn to git. > > The migration will be performed as per: > https://cwiki.apache.org/confluence/display/TOMCAT/Git+migration > > with the following changes: > - 8.0.x will not be migrated > - the tag name format will be changed from "TOMCAT_9_0_5" to "9.0.5" > - the branches will be named master, 8.5.x and 7.0.x > > The proposed date (subject to Infra agreement) for the migration is 26 > Feb 2018. > > The migration process will be: > - Make svn read only for trunk, 8.5.x and 7.0.x > - Turn off the svn->git replication for trunk, 8.5.x and 7.0.x > - Make git://git.apache.org/tomcat.git read/write for me only > - Perform the migration as set out in the wiki with the modifications > described above > - Check the migration > - Make git://git.apache.org/tomcat.git read/write for all committers > (Note: This automatically makes https://github.com/apache/tomcat > read/write as well) > > The critical work is done at this point. The following tasks are more > clean-up and may end up being spread over several days. > > - Confirm there are no open PRs for https://github.com/apache/tomcat85 > and then delete it and git://git.apache.org/tomcat85.git > - Confirm there are no open PRs for https://github.com/apache/tomcat70 > and then delete it and git://git.apache.org/tomcat70.git > - Update the CI systems to pull the source from git > - Create /source.html and replace /svn.html with a redirect to > /source.html > - Update migration guide to pull diffs from gitweb > - Update Tomcat Native to pull in source from git hash > - Fix anything else we have forgotten about. > > If anything goes wrong and we can't fix is easily, the fallback is to > make svn read-write and go back to using svn while we clean up the git > side of things, figure out what went wrong and come up with a better > migration plan. > > [ ] +1 Go ahead with the migration > [ ] -1 Postpone the migration because... > > The vote will be open for at least 72 hours. > > 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
[GUMP@vmgump-vm3]: Project taglibs-parent (in module tomcat-taglibs) failed
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project taglibs-parent has an issue affecting its community integration.
This issue affects 2 projects,
and has been outstanding for 8 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- taglibs-parent : Taglib Parent POM
- taglibs-standard-spec : JSP Taglibs
Full details are available at:
http://vmgump-vm3.apache.org/tomcat-taglibs/taglibs-parent/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-DEBUG- Sole pom output [pom.xml] identifier set to project name
-INFO- Optional dependency commons-io failed with reason build failed
-DEBUG- (Apache Gump generated) Apache Maven Settings in:
/srv/gump/public/workspace/tomcat-taglibs/taglibs-parent/gump_mvn_settings.xml
-INFO- Failed with reason build failed
-DEBUG- Maven POM in:
/srv/gump/public/workspace/tomcat-taglibs/taglibs-parent/pom.xml
-DEBUG- Extracted fallback artifacts from Gump Repository
The following work was performed:
http://vmgump-vm3.apache.org/tomcat-taglibs/taglibs-parent/gump_work/build_tomcat-taglibs_taglibs-parent.html
Work Name: build_tomcat-taglibs_taglibs-parent (Type: Build)
Work ended in a state of : Failed
Elapsed: 2 mins 2 secs
Command Line: /opt/maven3/bin/mvn --batch-mode --settings
/srv/gump/public/workspace/tomcat-taglibs/taglibs-parent/gump_mvn_settings.xml
install
[Working Directory: /srv/gump/public/workspace/tomcat-taglibs/taglibs-parent]
M2_HOME: /opt/maven3
-
[INFO] Scanning for projects...
[INFO] Downloading:
http://localhost:8192/maven2/org/apache/apache/13/apache-13.pom
Feb 26, 2019 1:39:49 AM
org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec
execute
INFO: I/O exception
(org.apache.maven.wagon.providers.http.httpclient.NoHttpResponseException)
caught when processing request to {}->http://localhost:8192: The target server
failed to respond
Feb 26, 2019 1:39:49 AM
org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec
execute
INFO: Retrying request to {}->http://localhost:8192
Feb 26, 2019 1:40:19 AM
org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec
execute
INFO: I/O exception
(org.apache.maven.wagon.providers.http.httpclient.NoHttpResponseException)
caught when processing request to {}->http://localhost:8192: The target server
failed to respond
Feb 26, 2019 1:40:19 AM
org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec
execute
INFO: Retrying request to {}->http://localhost:8192
Feb 26, 2019 1:40:49 AM
org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec
execute
INFO: I/O exception
(org.apache.maven.wagon.providers.http.httpclient.NoHttpResponseException)
caught when processing request to {}->http://localhost:8192: The target server
failed to respond
Feb 26, 2019 1:40:49 AM
org.apache.maven.wagon.providers.http.httpclient.impl.execchain.RetryExec
execute
INFO: Retrying request to {}->http://localhost:8192
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[WARNING] 'parent.relativePath' of POM
org.apache.taglibs:taglibs-parent:4-SNAPSHOT
(/srv/gump/public/workspace/tomcat-taglibs/taglibs-parent/pom.xml) points at
org.apache.tomcat.taglibs:taglibs-aggregator instead of org.apache:apache,
please verify your project structure @ line 20, column 11
[FATAL] Non-resolvable parent POM for
org.apache.taglibs:taglibs-parent:4-SNAPSHOT: Could not transfer artifact
org.apache:apache:pom:13 from/to gump-central (http://localhost:8192/maven2):
localhost:8192 failed to respond and 'parent.relativePath' points at wrong
local POM @ line 20, column 11
@
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR] The project org.apache.taglibs:taglibs-parent:4-SNAPSHOT
(/srv/gump/public/workspace/tomcat-taglibs/taglibs-parent/pom.xml) has 1 error
[ERROR] Non-resolvable parent POM for
org.apache.taglibs:taglibs-parent:4-SNAPSHOT: Could not transfer artifact
org.apache:apache:pom:13 from/to gump-central (http://localhost:8192/maven2):
localhost:8192 failed to respond and 'parent.relativePath' points at wrong
local POM @ line 20, column 11 -> [Help 2]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
[ERROR] [Help 2]
http://cwiki.apache.org/confluence/disp
[Bug 63210] Tomcat failing to shutdown if EvictionTimer thread is running
https://bz.apache.org/bugzilla/show_bug.cgi?id=63210 --- Comment #1 from k...@gameldar.com --- Created attachment 36464 --> https://bz.apache.org/bugzilla/attachment.cgi?id=36464&action=edit stacktrace showing servlet initialization in 9.0.16 -- 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 63210] Tomcat failing to shutdown if EvictionTimer thread is running
https://bz.apache.org/bugzilla/show_bug.cgi?id=63210 --- Comment #2 from k...@gameldar.com --- Created attachment 36465 --> https://bz.apache.org/bugzilla/attachment.cgi?id=36465&action=edit Thread dump after Tomcat fails to stop -- 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 63210] Tomcat failing to shutdown if EvictionTimer thread is running
https://bz.apache.org/bugzilla/show_bug.cgi?id=63210 --- Comment #3 from k...@gameldar.com --- Created attachment 36466 --> https://bz.apache.org/bugzilla/attachment.cgi?id=36466&action=edit Example servlet source to replicate the issue -- 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 63210] Tomcat failing to shutdown if EvictionTimer thread is running
https://bz.apache.org/bugzilla/show_bug.cgi?id=63210 --- Comment #4 from k...@gameldar.com --- Created attachment 36467 --> https://bz.apache.org/bugzilla/attachment.cgi?id=36467&action=edit Example war for the replication case -- 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 63210] Tomcat failing to shutdown if EvictionTimer thread is running
https://bz.apache.org/bugzilla/show_bug.cgi?id=63210 --- Comment #5 from k...@gameldar.com --- Created attachment 36468 --> https://bz.apache.org/bugzilla/attachment.cgi?id=36468&action=edit context configuration file for replication case -- 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 63210] Tomcat failing to shutdown if EvictionTimer thread is running
https://bz.apache.org/bugzilla/show_bug.cgi?id=63210 --- Comment #6 from k...@gameldar.com --- Created attachment 36469 --> https://bz.apache.org/bugzilla/attachment.cgi?id=36469&action=edit Patch that fixes this specific case with the EvictionTimer thread -- 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 63210] New: Tomcat failing to shutdown if EvictionTimer thread is running
https://bz.apache.org/bugzilla/show_bug.cgi?id=63210 Bug ID: 63210 Summary: Tomcat failing to shutdown if EvictionTimer thread is running Product: Tomcat 9 Version: 9.0.x Hardware: PC OS: Mac OS X 10.1 Status: NEW Severity: normal Priority: P2 Component: Catalina Assignee: dev@tomcat.apache.org Reporter: k...@gameldar.com Target Milestone: - Created attachment 36463 --> https://bz.apache.org/bugzilla/attachment.cgi?id=36463&action=edit stacktrace showing servlet initialization in 8.0.53 If a query is executed against a DataSource during the Servlet init phase when timeBetweenEvictionRunsMillis is defined on the DataSource when you try and shutdown Tomcat it will shutdown everything but the commons-pool-evictor-thread is left waiting and will not shut down (regardless of the value set in the timeBetweenEvictionRunsMillis). I found this issue as part of upgrading a webapp from working with Tomcat 8.0.53 to 9.0.16. It is caused by a change of behaviour between the two versions due to initialization of the Servlets happening in a different way between the two versions, namely that the Servlet initialization in Tomcat 8.0.53 happens in a separate thread, whereas with 9.0.x it happens on the main thread. This means that when the EvictionTimer thread is started it inherits the daemon flag from the parent thread (as it isn't explicitly set) which is false in 9.0.x and true in 8.0.53 and therefore when the main thread exits after shutdown in 9.0.x the common-pool-evictor-thread continues and stops termination of Tomcat. There is a workaround for this - by manually closing the underlying datasource during the Servlet destroy method. There are potentially two issues here: 1. The EvictionTimer thread should be marked as setDaemon after it is created (in the EvictorTimerFactory) this way it'll be killed when Tomcat is shutdown. See the attached diff which I've confirmed fixes the issue. 2. The resources are not actually being closed if they are loaded via a reference in the context. #2 here is perhaps the bigger issue - this may be an issue for more than just the EvictionTimer, but it was the one I hit. Full Replication steps: 1. Put the attached test.war into the base tomcat direct This war file was a simple webapp based upon: https://www.journaldev.com/2513/tomcat-datasource-jndi-example-java You'll need to create the database with the tables as described in that example. For reference I was using PostgreSQL. I've modified the source of the servlet however as attached (TestServlet.java) - namely it is now loading the JNDI DataSource during the Servlet.init() method and executing the same getEmployees query in the init method to ensure datasource pool initialized at that point. 2. create the context for the webapp - put the attached test.xml into conf/Catalina/localhost/test.xml. Note this is using a Resource for the DataSource and setting the timeBetweenEvictionRunsMillis="6". You'll need to change the database configuration (url, driverClassname) in the Resource to point to your database. 3. Create the database and populate the tables (see the attached link) 4. Start up Tomcat using bin/start.sh 5. Connect to http://localhost:8080/test/ to confirm the servlet is loaded and working 6. Shutdown Tomcat using bin/shutdown.sh It'll say it is shutdown - and to ensure that it isn't stuck in the eviction wait time wait at least 60 seconds - but if you look at your processes you'll see the Tomcat instance is still running with a similar list of threads as seen in the attached jstack.log. The Servlet is producing the stacktrace during the init that shows the difference between the 9.0.x startup and the 8.0.53 startup (full stack traces are attached). 8.0.53 startup looks like: 26-Feb-2019 10:26:18.071 INFO [localhost-startStop-1] org.apache.catalina.core.ApplicationContext.log java.lang.Exception at test.TestServlet.init(TestServlet.java:28) at javax.servlet.GenericServlet.init(GenericServlet.java:158) at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:118 // snip at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:834) Whereas the 9.0.16 stacktrace traces back to the Bootstrap main method: Feb. 26, 2019 8:42:08 AM org.apache.catalina.core.ApplicationContext log INFO: java.lang.Exception at test.TestServlet.init(TestServlet.java:28) at javax.servlet.GenericServlet.init(GenericServlet.java:158) at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1123) // snip at org.apache.catalina.startup.Bootstrap.start(Bootstrap.j
