[jira] [Updated] (VALIDATOR-466) An update is needed of generic TLDS in DomainValidator
[ https://issues.apache.org/jira/browse/VALIDATOR-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chengzhen Pan updated VALIDATOR-466: Description: I have been using UrlValidator to check some urls and recently have some problem with some domains with new gTLDs such as ".inc" which would be determined as invalid. I noticed that there was a commit to it which contains ".inc" already, so maybe all I need is a release? [https://github.com/apache/commons-validator/commit/c53e5639b7e149e2ea9efe78a9217afdcf3bbcbd] Please let me know if I misunderstand something. Thanks in advance. was: I am using UrlValidator to check some urls and recently have some problem with some domains with new gTLDs such as ".inc" which would be determined as invalid. I noticed that there was a commit to it which contains ".inc" already, so maybe all I need is a release? [https://github.com/apache/commons-validator/commit/c53e5639b7e149e2ea9efe78a9217afdcf3bbcbd] Please let me know if I misunderstand something. Thanks in advance. > An update is needed of generic TLDS in DomainValidator > -- > > Key: VALIDATOR-466 > URL: https://issues.apache.org/jira/browse/VALIDATOR-466 > Project: Commons Validator > Issue Type: Bug >Affects Versions: 1.6 >Reporter: Chengzhen Pan >Priority: Major > > I have been using UrlValidator to check some urls and recently have some > problem with some domains with new gTLDs such as ".inc" which would be > determined as invalid. > > I noticed that there was a commit to it which contains ".inc" already, so > maybe all I need is a release? > [https://github.com/apache/commons-validator/commit/c53e5639b7e149e2ea9efe78a9217afdcf3bbcbd] > > Please let me know if I misunderstand something. > > Thanks in advance. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (VALIDATOR-466) An update is needed of generic TLDS in DomainValidator
[ https://issues.apache.org/jira/browse/VALIDATOR-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chengzhen Pan updated VALIDATOR-466: Description: I have been using UrlValidator to check some urls and recently have some problems with some domains with new gTLDs such as ".inc" which would be determined as invalid. I noticed that there was a commit to it which contains ".inc" already, so maybe all I need is a release? [https://github.com/apache/commons-validator/commit/c53e5639b7e149e2ea9efe78a9217afdcf3bbcbd] Please let me know if I misunderstand something. Thanks in advance. was: I have been using UrlValidator to check some urls and recently have some problem with some domains with new gTLDs such as ".inc" which would be determined as invalid. I noticed that there was a commit to it which contains ".inc" already, so maybe all I need is a release? [https://github.com/apache/commons-validator/commit/c53e5639b7e149e2ea9efe78a9217afdcf3bbcbd] Please let me know if I misunderstand something. Thanks in advance. > An update is needed of generic TLDS in DomainValidator > -- > > Key: VALIDATOR-466 > URL: https://issues.apache.org/jira/browse/VALIDATOR-466 > Project: Commons Validator > Issue Type: Bug >Affects Versions: 1.6 >Reporter: Chengzhen Pan >Priority: Major > > I have been using UrlValidator to check some urls and recently have some > problems with some domains with new gTLDs such as ".inc" which would be > determined as invalid. > > I noticed that there was a commit to it which contains ".inc" already, so > maybe all I need is a release? > [https://github.com/apache/commons-validator/commit/c53e5639b7e149e2ea9efe78a9217afdcf3bbcbd] > > Please let me know if I misunderstand something. > > Thanks in advance. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (VALIDATOR-466) An update is needed of generic TLDS in DomainValidator
Chengzhen Pan created VALIDATOR-466: --- Summary: An update is needed of generic TLDS in DomainValidator Key: VALIDATOR-466 URL: https://issues.apache.org/jira/browse/VALIDATOR-466 Project: Commons Validator Issue Type: Bug Affects Versions: 1.6 Reporter: Chengzhen Pan I am using UrlValidator to check some urls and recently have some problem with some domains with new gTLDs such as ".inc" which would be determined as invalid. I have been noticed that there was a commit to it which contains ".inc" already, so maybe all I need is a release? [https://github.com/apache/commons-validator/commit/c53e5639b7e149e2ea9efe78a9217afdcf3bbcbd] Please let me know if I misunderstand something. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (VALIDATOR-466) An update is needed of generic TLDS in DomainValidator
[ https://issues.apache.org/jira/browse/VALIDATOR-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chengzhen Pan updated VALIDATOR-466: Description: I am using UrlValidator to check some urls and recently have some problem with some domains with new gTLDs such as ".inc" which would be determined as invalid. I noticed that there was a commit to it which contains ".inc" already, so maybe all I need is a release? [https://github.com/apache/commons-validator/commit/c53e5639b7e149e2ea9efe78a9217afdcf3bbcbd] Please let me know if I misunderstand something. Thanks in advance. was: I am using UrlValidator to check some urls and recently have some problem with some domains with new gTLDs such as ".inc" which would be determined as invalid. I have been noticed that there was a commit to it which contains ".inc" already, so maybe all I need is a release? [https://github.com/apache/commons-validator/commit/c53e5639b7e149e2ea9efe78a9217afdcf3bbcbd] Please let me know if I misunderstand something. Thanks in advance. > An update is needed of generic TLDS in DomainValidator > -- > > Key: VALIDATOR-466 > URL: https://issues.apache.org/jira/browse/VALIDATOR-466 > Project: Commons Validator > Issue Type: Bug >Affects Versions: 1.6 >Reporter: Chengzhen Pan >Priority: Major > > I am using UrlValidator to check some urls and recently have some problem > with some domains with new gTLDs such as ".inc" which would be determined as > invalid. > > I noticed that there was a commit to it which contains ".inc" already, so > maybe all I need is a release? > [https://github.com/apache/commons-validator/commit/c53e5639b7e149e2ea9efe78a9217afdcf3bbcbd] > > Please let me know if I misunderstand something. > > Thanks in advance. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (VALIDATOR-466) An update is needed of generic TLDS in DomainValidator
[ https://issues.apache.org/jira/browse/VALIDATOR-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chengzhen Pan updated VALIDATOR-466: Description: I am using UrlValidator to check some urls and recently have some problem with some domains with new gTLDs such as ".inc" which would be determined as invalid. I have been noticed that there was a commit to it which contains ".inc" already, so maybe all I need is a release? [https://github.com/apache/commons-validator/commit/c53e5639b7e149e2ea9efe78a9217afdcf3bbcbd] Please let me know if I misunderstand something. Thanks in advance. was: I am using UrlValidator to check some urls and recently have some problem with some domains with new gTLDs such as ".inc" which would be determined as invalid. I have been noticed that there was a commit to it which contains ".inc" already, so maybe all I need is a release? [https://github.com/apache/commons-validator/commit/c53e5639b7e149e2ea9efe78a9217afdcf3bbcbd] Please let me know if I misunderstand something. > An update is needed of generic TLDS in DomainValidator > -- > > Key: VALIDATOR-466 > URL: https://issues.apache.org/jira/browse/VALIDATOR-466 > Project: Commons Validator > Issue Type: Bug >Affects Versions: 1.6 >Reporter: Chengzhen Pan >Priority: Major > > I am using UrlValidator to check some urls and recently have some problem > with some domains with new gTLDs such as ".inc" which would be determined as > invalid. > > I have been noticed that there was a commit to it which contains ".inc" > already, so maybe all I need is a release? > [https://github.com/apache/commons-validator/commit/c53e5639b7e149e2ea9efe78a9217afdcf3bbcbd] > > Please let me know if I misunderstand something. > > Thanks in advance. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (JEXL-249) Java 1.8 as minimum supported version
[
https://issues.apache.org/jira/browse/JEXL-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro reopened JEXL-249:
2 years later, consensus changed.
> Java 1.8 as minimum supported version
> -
>
> Key: JEXL-249
> URL: https://issues.apache.org/jira/browse/JEXL-249
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
>
> From one of the latest commits I can see we have started using {{Map}}
> interface methods that were introduced in Java 1.8, {{Map.putIfAbsent()}} to
> speak directly. Can we expect that from the 3.2 release anytime soon, we can
> rely on Java 8 to be minimum supported version?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-compress] PeterAlfredLee merged pull request #102: Compress-515: Add fileName/path info to ZipFile constructor IOException
PeterAlfredLee merged pull request #102: URL: https://github.com/apache/commons-compress/pull/102 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (COMPRESS-524) Mailing list addresses are out of date
Elliotte Rusty Harold created COMPRESS-524: -- Summary: Mailing list addresses are out of date Key: COMPRESS-524 URL: https://issues.apache.org/jira/browse/COMPRESS-524 Project: Commons Compress Issue Type: Bug Reporter: Elliotte Rusty Harold Spot checking it looks like the links on [https://commons.apache.org/proper/commons-compress/mailing-lists.html] are all 404 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-compress] ian-lavallee commented on pull request #102: Compress-515: Add fileName/path info to ZipFile constructor IOException
ian-lavallee commented on pull request #102: URL: https://github.com/apache/commons-compress/pull/102#issuecomment-632344890 @bodewig This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (JEXL-331) Please document \uXXXX escape sequence
David Costanzo created JEXL-331:
---
Summary: Please document \u escape sequence
Key: JEXL-331
URL: https://issues.apache.org/jira/browse/JEXL-331
Project: Commons JEXL
Issue Type: Bug
Affects Versions: 3.1
Environment: N/A
Reporter: David Costanzo
One of my JEXL programmers discovered an undocumented feature of JEXL that they
could use the Java-style {{\u}} escape sequence in string literals (this
might be JEXL-22). This is useful enough to be worth documenting.
It's not clear to me if the {{\u}} sequences can only be used within string
literals (as in C) or anywhere in a JEXL script (as in Java). I tried creating
a JEXL string literal that used \u0027 instead of a single quote as its
delimiter, but it didn't work, so I suspect this is just for string literals.
For reference, the escape sequences are documented under "String literals" in
syntax.xml like this:
{quote}The escape character is \ (backslash); it only escapes
the string delimiter
{quote}
By the way, the second clause is not strictly true, since (experimentally) the
escape character can also be escaped (this might be JEXL-98). This might be
obvious enough that it doesn't need to be documented, though.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COMPRESS-514) SevenZFile fails with encoded header over 2GiB
[
https://issues.apache.org/jira/browse/COMPRESS-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17113466#comment-17113466
]
A Kelday commented on COMPRESS-514:
---
After digging in a bit more this takes me back to the same CRC problem as
before, but with some new info after looking at the 7zip source.
It looks like 7zip does nearly the same as the current Commons Compress; read
the whole header buffer into ram and CRC before parsing. The difference is
that's an unsigned int, so maximum 4GiB (above that is unsupported). Indeed
7zip uses over 5GiB ram simply to show the files list of this 1.2TB archive.
That leads to at least three options:
# 7zip method: read all into ram (with multiple buffers up to 4G) for CRC and
parse
# Read the header twice if necessary: once streamed for CRC, the next using a
small buffer to parse. If the header fits in our small buffer entirely no extra
read is required.
# Read the header and compute CRC at the same time (bad because you don't find
out the data is wrong until it's too late)
It would be great to have some opinion here, because this is more than I'd
hoped it would require to fix. There's always the choice to just not support
over 2G...
> SevenZFile fails with encoded header over 2GiB
> --
>
> Key: COMPRESS-514
> URL: https://issues.apache.org/jira/browse/COMPRESS-514
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.20
>Reporter: A Kelday
>Priority: Minor
> Attachments: HeaderChannelBuffer.java
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> When reading what some may call a large encrypted 7zip file (1.2TB with 22
> million files), the read fails at the header stage with the trace below. Is
> this within the spec? I've written some code to handle it, because I did
> actually need to extract the file in java. If that's of any use I can provide
> it (it's a naive wrapper that just pages in a buffer at a time).
>
> {code:java}
> Exception in thread "main" java.io.IOException: Cannot handle
> unpackSize241696
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.assertFitsIntoInt(SevenZFile.java:1523)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.readEncodedHeader(SevenZFile.java:622)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.initializeArchive(SevenZFile.java:532)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.readHeaders(SevenZFile.java:468)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.(SevenZFile.java:337)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.(SevenZFile.java:129)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.(SevenZFile.java:116)
> {code}
> 7zip itself can also open it (and display/extract etc.), here are the stats:
>
>
> {code:java}
> Size: 2 489 903 580 875
> Packed Size: 1 349 110 308 832
> Folders: 40 005
> Files: 22 073 957
> CRC: E26F6A96
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (COMPRESS-514) SevenZFile fails with encoded header over 2GiB
[
https://issues.apache.org/jira/browse/COMPRESS-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17113466#comment-17113466
]
A Kelday edited comment on COMPRESS-514 at 5/21/20, 6:54 PM:
-
After digging in a bit more this takes me back to the same CRC problem as
before, but with some new info after looking at the 7zip source.
It looks like 7zip does nearly the same as the current Commons Compress; read
the whole header buffer into ram and CRC before parsing. The difference is
that's an unsigned int, so maximum 4GiB (above that is unsupported). Indeed
7zip uses over 5GiB ram simply to show the files list of this 1.2TB archive.
That leads to at least three options:
# 7zip method: read all into ram (with multiple buffers up to 4G) for CRC and
parse
# Read the header twice if necessary: once streamed for CRC, the next using a
small buffer to parse. If the header fits in our small buffer entirely no extra
read is required.
# Read/parse the header and compute CRC at the same time (bad because you
don't find out the data is wrong until it's too late)
It would be great to have some opinion here, because this is more than I'd
hoped it would require to fix. There's always the choice to just not support
over 2G...
was (Author: akelday):
After digging in a bit more this takes me back to the same CRC problem as
before, but with some new info after looking at the 7zip source.
It looks like 7zip does nearly the same as the current Commons Compress; read
the whole header buffer into ram and CRC before parsing. The difference is
that's an unsigned int, so maximum 4GiB (above that is unsupported). Indeed
7zip uses over 5GiB ram simply to show the files list of this 1.2TB archive.
That leads to at least three options:
# 7zip method: read all into ram (with multiple buffers up to 4G) for CRC and
parse
# Read the header twice if necessary: once streamed for CRC, the next using a
small buffer to parse. If the header fits in our small buffer entirely no extra
read is required.
# Read the header and compute CRC at the same time (bad because you don't find
out the data is wrong until it's too late)
It would be great to have some opinion here, because this is more than I'd
hoped it would require to fix. There's always the choice to just not support
over 2G...
> SevenZFile fails with encoded header over 2GiB
> --
>
> Key: COMPRESS-514
> URL: https://issues.apache.org/jira/browse/COMPRESS-514
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.20
>Reporter: A Kelday
>Priority: Minor
> Attachments: HeaderChannelBuffer.java
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> When reading what some may call a large encrypted 7zip file (1.2TB with 22
> million files), the read fails at the header stage with the trace below. Is
> this within the spec? I've written some code to handle it, because I did
> actually need to extract the file in java. If that's of any use I can provide
> it (it's a naive wrapper that just pages in a buffer at a time).
>
> {code:java}
> Exception in thread "main" java.io.IOException: Cannot handle
> unpackSize241696
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.assertFitsIntoInt(SevenZFile.java:1523)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.readEncodedHeader(SevenZFile.java:622)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.initializeArchive(SevenZFile.java:532)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.readHeaders(SevenZFile.java:468)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.(SevenZFile.java:337)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.(SevenZFile.java:129)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.(SevenZFile.java:116)
> {code}
> 7zip itself can also open it (and display/extract etc.), here are the stats:
>
>
> {code:java}
> Size: 2 489 903 580 875
> Packed Size: 1 349 110 308 832
> Folders: 40 005
> Files: 22 073 957
> CRC: E26F6A96
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-collections] dota17 commented on pull request #159: Updated the fail() exceptions with Junit5.
dota17 commented on pull request #159: URL: https://github.com/apache/commons-collections/pull/159#issuecomment-632060510 > @dota17 The title says "WIP". Are you still working on it? Yes, I am. If anyone has time to review, it would be really nice. ;-) Thanks This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (DAEMON-418) Need for better error/troubleshooting in commons-daemon.log
Harry L. Hoots, III created DAEMON-418: -- Summary: Need for better error/troubleshooting in commons-daemon.log Key: DAEMON-418 URL: https://issues.apache.org/jira/browse/DAEMON-418 Project: Commons Daemon Issue Type: Improvement Components: prunsrv Affects Versions: 1.2.2, 1.2.1, 1.2.0 Environment: Windows server 2016 / Windows 10 Enterprise Reporter: Harry L. Hoots, III Fix For: 1.2.3 Greetings-- I would like to request better error/troubleshooting logging in the commons-daemon..log. Recently we upgraded our version of prunsrv.exe to 1.2.0, and our application would not start as it had on the previous version. We encountered this error in the logs: [2020-05-07 16:12:53] [info] [ 4808] Apache Commons Daemon procrun (1.2.0.0 32-bit) started. [2020-05-07 16:12:53] [info] [ 4808] Starting service 'myService'... [2020-05-07 16:12:54] [error] [ 4808] apxServiceControl(): dwState(4) != dwCurrentState(1); dwWin32ExitCode = 1066, dwWaitHint = 0, dwServiceSpecificExitCode = 1 [2020-05-07 16:12:54] [error] [ 4808] apxServiceControl(): returning FALSE [2020-05-07 16:12:54] [error] [ 4808] Failed to start service 'myService'. [2020-05-07 16:12:54] [info] [ 4808] Finished starting service 'myService', returning 0. [2020-05-07 16:12:54] [error] [ 4808] Apache Commons Daemon procrun failed with exit value: 5 (failed to start service). After much digging and troubleshooting we found that the default service user had been changed: Procrun. Change the default service user from LocalSystem to 'NT Authority\LocalService'. https://commons.apache.org/proper/commons-daemon/changes-report.html#a1.2.0 After setting the parameter --ServiceUser=LocalSystem everything started working again as it had in the past. Thus this request is add better logging around these attributes, which are hard to interpret: apxServiceControl(): dwState(4) != dwCurrentState(1); dwWin32ExitCode = 1066, dwWaitHint = 0, dwServiceSpecificExitCode = 1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-collections] garydgregory commented on pull request #159: Updated the fail() exceptions with Junit5.
garydgregory commented on pull request #159: URL: https://github.com/apache/commons-collections/pull/159#issuecomment-632113164 > > @dota17 The title says "WIP". Are you still working on it? > > Yes, I am. > If anyone has time to review, it would be really nice. ;-) > > Thanks Hi @dota17 This PR currently touches **124** files, which is a lot to review. Personally, for me to review this, I'd want to know the PR is as best as you can make it, because, as you can imagine, I really do not want to do it twice! ;-) So either it's WIP or it is as good as it is going to get from your POV at least. Please let us know... This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (VFS-773) Could not find file with URI "sftp://max_s_maeder@35.232.72.5:22/hi.html" because it is a relative path, and no base URI was provided.
[
https://issues.apache.org/jira/browse/VFS-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17113221#comment-17113221
]
Gary D. Gregory commented on VFS-773:
-
[~MaxTheGinus]
What happens if you provide both a user name and a password instead of just a
user name?
> Could not find file with URI "sftp://max_s_maeder@35.232.72.5:22/hi.html;
> because it is a relative path, and no base URI was provided.
> --
>
> Key: VFS-773
> URL: https://issues.apache.org/jira/browse/VFS-773
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.6.0
> Environment: Google Cloud Engine instance with default firewall
> settings
>Reporter: Max Maeder
>Priority: Major
> Original Estimate: 2m
> Remaining Estimate: 2m
>
> I've been pulling my hair out over this issue, I've searched the interwebs
> and this issue tracker for someone having a similar issue, but to no avail.
> Every time I run the following code, I get this error:
>
> {code:java}
> org.apache.commons.vfs2.FileSystemException: Could not find file with URI
> "sftp://max_s_maeder@35.232.72.5:22/hi.html; because it is a relative path,
> and no base URI was provided.
> [01:58:12] [Thread-14/WARN]:at
> org.apache.commons.vfs2.FileSystemException.requireNonNull(FileSystemException.java:87)
> [01:58:12] [Thread-14/WARN]:at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:734)
> [01:58:12] [Thread-14/WARN]:at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:683)
> [01:58:12] [Thread-14/WARN]:at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:638)
> [01:58:12] [Thread-14/WARN]:at
> ratismal.drivebackup.ftp.SFTPUploader.uploadFile(SFTPUploader.java:55)
> [01:58:12] [Thread-14/WARN]:at
> ratismal.drivebackup.ftp.FTPUploader.uploadFile(FTPUploader.java:37)
> [01:58:12] [Thread-14/WARN]:at
> ratismal.drivebackup.UploadThread.run(UploadThread.java:96)
> [01:58:12] [Thread-14/WARN]:at
> java.base/java.lang.Thread.run(Thread.java:834)
> {code}
>
>
> {code:java}
> package ratismal.drivebackup.ftp;
> import org.apache.commons.vfs2.FileObject;import
> org.apache.commons.vfs2.FileSystemManager;import org.apache.commons.vfs2.VFS;
> import ratismal.drivebackup.config.Config;import
> ratismal.drivebackup.util.MessageUtil;
> import java.io.File;import java.util.*;
> public class SFTPUploader {
> public static void uploadFile() throws Exception {FileSystemManager
> manager = VFS.getManager();
> FileObject remoteFolder =
> manager.resolveFile("sftp://max_s_maeder@35.232.72.5:22/hi.html;);
> remoteFolder.close(); }}
> {code}
> I'm sorry if this is the wrong place to ask.
> Also, the credentials above aren't going to get you into my server ;)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-dbcp] garydgregory commented on a change in pull request #40: Add Evictor threads test code.
garydgregory commented on a change in pull request #40:
URL: https://github.com/apache/commons-dbcp/pull/40#discussion_r428679539
##
File path: src/test/java/org/apache/commons/dbcp2/TestBasicDataSource.java
##
@@ -916,6 +917,34 @@ public void testCreateConnectionFactory() throws Exception
{
conn.close();
ds.close();
}
+
+@Test
+public void testEvict() throws Exception {
+ds.setInitialSize(10);
+ds.setMaxIdle(10);
+ds.setMaxTotal(10);
+ds.setMinIdle(5);
+ds.setNumTestsPerEvictionRun(3);
+ds.setMinEvictableIdleTimeMillis(100);
+ds.setTimeBetweenEvictionRunsMillis(1000);
+ds.setPoolPreparedStatements(true);
+
+Connection conn = ds.getConnection();
+conn.close();
+
+ThreadMXBean threadBean = ManagementFactory.getThreadMXBean();
+while
(Arrays.stream(threadBean.getThreadInfo(threadBean.getAllThreadIds()))
+.anyMatch(t ->
t.getThreadName().equals("commons-pool-evictor-thread"))) {
+if (ds.getNumIdle() <= ds.getMinIdle()) {
+break;
+}
+Thread.sleep(1000);
Review comment:
If this `1000` matches the one above in the call to
`setTimeBetweenEvictionRunsMillis`, it would make sense to refactor the value
in a local variable to make obvious that these must indeed match.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
