[jira] [Commented] (VFS-807) LocalFile migration to NIO is not done correctly
[
https://issues.apache.org/jira/browse/VFS-807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17449396#comment-17449396
]
L commented on VFS-807:
---
[~ggregory] : yes, it can be closed.
> LocalFile migration to NIO is not done correctly
>
>
> Key: VFS-807
> URL: https://issues.apache.org/jira/browse/VFS-807
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.9.0
>Reporter: L
>Priority: Blocker
> Fix For: 2.9.1
>
> Attachments: TestJdkWriteFile.java, vfs-807.diff
>
>
> According to release notes
> ([https://archive.apache.org/dist/commons/vfs/RELEASE-NOTES.txt),] version
> 2.9.0 includes the following change:
> Replace construction of FileInputStream and FileOutputStream objects with
> Files NIO APIs. #164. Thanks to Arturo Bernal.
> Strangely, it was not completed: LocalFlie.java has the following now, even
> in master:
> {code:java}
> /**
> * Creates an input stream to read the content from.
> */
> @Override
> protected InputStream doGetInputStream(final int bufferSize) throws
> Exception {
> return new FileInputStream(file);
> }
> {code}
>
> But what is worse, doGetOutputStream is *completely* broken:
> {code:java}
> /**
> * Creates an output stream to write the file content to.
> */
> @Override
> protected OutputStream doGetOutputStream(final boolean bAppend) throws
> Exception {
> return Files.newOutputStream(file.toPath(), bAppend ?
> StandardOpenOption.APPEND : StandardOpenOption.CREATE);
> } {code}
>
> This can be demonstrated with a small java program, see attachment. The
> program just tries to write to a local file (into the same directory), using
> different ways to do it:
> # Java IO, how it was done before VFS 2.9.0
> # Java NIO the way VFS 2.9.0 does it
> # Java NIO the way it must be done
> What is important, the program also verifies the result.
> VFS 2.9.0 fails in 2 cases:
> # When the file does not exist and append must be performed:
> java.nio.file.NoSuchFileException is thrown in this case.
> # When the file exists and no append must be performed: the file is not
> truncated, so whatever is written overwrites the beginning of the file,
> keeping the rest.
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (JEXL-354) #pragma does not handle negative integer or real literals
William Price created JEXL-354:
--
Summary: #pragma does not handle negative integer or real literals
Key: JEXL-354
URL: https://issues.apache.org/jira/browse/JEXL-354
Project: Commons JEXL
Issue Type: Bug
Affects Versions: 3.2.1
Reporter: William Price
Using 3.2.1, I get a parse exception on the simple JEXL script:
{code}
#pragma myInt -1
{code}
Throws:
{noformat}
org.apache.commons.jexl3.JexlException$Parsing:
com.example.Test.testMethod:54@1:15 parsing error in '-'
at
app//org.apache.commons.jexl3.JexlEngine.createScript(JexlEngine.java:375)
{noformat}
And similar, also for negative real literals such as {{-1.0}}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [commons-release-plugin] dependabot[bot] closed pull request #82: Bump maven.dependency.version from 3.8.1 to 3.8.3
dependabot[bot] closed pull request #82: URL: https://github.com/apache/commons-release-plugin/pull/82 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-release-plugin] dependabot[bot] commented on pull request #82: Bump maven.dependency.version from 3.8.1 to 3.8.3
dependabot[bot] commented on pull request #82: URL: https://github.com/apache/commons-release-plugin/pull/82#issuecomment-979468488 Looks like these dependencies are up-to-date now, so this is no longer needed. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-release-plugin] kinow commented on pull request #82: Bump maven.dependency.version from 3.8.1 to 3.8.3
kinow commented on pull request #82: URL: https://github.com/apache/commons-release-plugin/pull/82#issuecomment-979467029 @dependabot recreate. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-release-plugin] dependabot[bot] commented on pull request #82: Bump maven.dependency.version from 3.8.1 to 3.8.3
dependabot[bot] commented on pull request #82: URL: https://github.com/apache/commons-release-plugin/pull/82#issuecomment-979466131 Looks like this PR has been edited by someone other than Dependabot. That means Dependabot can't rebase it - sorry! If you're happy for Dependabot to recreate it from scratch, overwriting any edits, you can request `@dependabot recreate`. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-release-plugin] kinow commented on pull request #82: Bump maven.dependency.version from 3.8.1 to 3.8.3
kinow commented on pull request #82: URL: https://github.com/apache/commons-release-plugin/pull/82#issuecomment-979466122 @dependabot rebase -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-release-plugin] kinow merged pull request #87: Bump actions/cache from 2.1.6 to 2.1.7
kinow merged pull request #87: URL: https://github.com/apache/commons-release-plugin/pull/87 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-release-plugin] kinow merged pull request #88: Bump spotbugs-maven-plugin from 4.4.2.2 to 4.5.0.0
kinow merged pull request #88: URL: https://github.com/apache/commons-release-plugin/pull/88 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-vfs] garydgregory commented on pull request #85: VFS-760 Zkprovider
garydgregory commented on pull request #85: URL: https://github.com/apache/commons-vfs/pull/85#issuecomment-979425327 @ottobackwards May you rebase on git master to see if we can get a green build? -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (VFS-772) SFTP resolveFile() can freeze while testing if the server disabled the exec channel
[
https://issues.apache.org/jira/browse/VFS-772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17449294#comment-17449294
]
Gary D. Gregory commented on VFS-772:
-
[~remi.ville]
Ping?
> SFTP resolveFile() can freeze while testing if the server disabled the exec
> channel
> ---
>
> Key: VFS-772
> URL: https://issues.apache.org/jira/browse/VFS-772
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Rémi Villé
>Priority: Major
>
> Since 2.5.0 (VFS-590) the SftpFileSystem constructor checks if it can execute
> commands by testing "id -u" (see SftpFileSystem#detectExecDisabled()), but
> with some servers the call stay blocked in SftpFileSystem#executeCommand("id
> -u", output).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (VFS-775) SFTP Uplaod is successfull but getting Exceptions
[ https://issues.apache.org/jira/browse/VFS-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17449292#comment-17449292 ] Gary D. Gregory commented on VFS-775: - Hi [~akhil_surapuram], I'm not sure how we can help unless you can provide a reproducer... in the form of a unit test, or standalone Maven project. Whatever works for you. TY. > SFTP Uplaod is successfull but getting Exceptions > - > > Key: VFS-775 > URL: https://issues.apache.org/jira/browse/VFS-775 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.4 >Reporter: Akhil Surapuram >Priority: Major > > ache.commons.vfs2.FileSystemException: Could not determine the type of file > "sftp://;. at > org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:1347) > at > org.apache.commons.vfs2.provider.AbstractFileObject.exists(AbstractFileObject.java:945) > at > org.apache.commons.vfs2.util.FileObjectUtils.exists(FileObjectUtils.java:45) > at > org.apache.commons.vfs2.provider.AbstractFileObject.copyFrom(AbstractFileObject.java:285) > Caused by: org.apache.commons.vfs2.FileSystemException: Could not connect to > SFTP server at "sftp://259874_U:***@sftp.cdslindia.com/;. > at > org.apache.commons.vfs2.provider.sftp.SftpFileSystem.getChannel(SftpFileSystem.java:151) > at > org.apache.commons.vfs2.provider.sftp.SftpFileObject.statSelf(SftpFileObject.java:114) > at > org.apache.commons.vfs2.provider.sftp.SftpFileObject.doGetType(SftpFileObject.java:76) > at > org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:1341) > ... 40 common frames omitted > Caused by: com.jcraft.jsch.JSchException: session is down > at com.jcraft.jsch.Session.openChannel(Session.java:861) > at > org.apache.commons.vfs2.provider.sftp.SftpFileSystem.getChannel(SftpFileSystem.java:124) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (VFS-774) There are missing dependecies on UrlFileObject
[ https://issues.apache.org/jira/browse/VFS-774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory closed VFS-774. --- Resolution: Cannot Reproduce > There are missing dependecies on UrlFileObject > -- > > Key: VFS-774 > URL: https://issues.apache.org/jira/browse/VFS-774 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 2.6.0 >Reporter: Menuka Singappuli Hewage >Priority: Major > > When I read through the codebase, I noticed that UrlFileObject class has > missing dependencies. > class: > UrlFileObject > import org.apache.commons.httpclient.URIException; > > class: URLFileName class: > import org.apache.commons.httpclient.URIException; > import org.apache.commons.httpclient.util.URIUtil; > > I think httpclient needs to be upgraded. > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (VFS-776) Random Times i am receiving file not found error
[ https://issues.apache.org/jira/browse/VFS-776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17449291#comment-17449291 ] Gary D. Gregory commented on VFS-776: - Hi [~akhil_surapuram] I'm not sure how we can help unless you can provide a reproducer... in the form of a unit test, or standalone Maven project. Whatever works for you. > Random Times i am receiving file not found error > > > Key: VFS-776 > URL: https://issues.apache.org/jira/browse/VFS-776 > Project: Commons VFS > Issue Type: Bug >Reporter: Akhil Surapuram >Priority: Major > > Note removed sensitve information and replaced with (...) > Caused by: org.apache.commons.vfs2.FileSystemException: Could not copy > "file:///(...)" to "sftp://(...)". > at > org.apache.commons.vfs2.provider.AbstractFileObject.copyFrom(AbstractFileObject.java:300) > Caused by: org.apache.commons.vfs2.FileSystemException: Could not write to > "sftp://(...)". > at > org.apache.commons.vfs2.provider.AbstractFileObject.getOutputStream(AbstractFileObject.java:1243) > at > org.apache.commons.vfs2.provider.DefaultFileContent.buildOutputStream(DefaultFileContent.java:518) > at > org.apache.commons.vfs2.provider.DefaultFileContent.getOutputStream(DefaultFileContent.java:404) > at > org.apache.commons.vfs2.provider.DefaultFileContent.getOutputStream(DefaultFileContent.java:392) > at > org.apache.commons.vfs2.provider.DefaultFileContent.write(DefaultFileContent.java:753) > at > org.apache.commons.vfs2.provider.DefaultFileContent.write(DefaultFileContent.java:771) > at org.apache.commons.vfs2.FileUtil.copyContent(FileUtil.java:37) > at > org.apache.commons.vfs2.provider.AbstractFileObject.copyFrom(AbstractFileObject.java:295) > ... 37 common frames omitted > Caused by: com.jcraft.jsch.SftpException: No such file > at com.jcraft.jsch.ChannelSftp.throwStatusError(ChannelSftp.java:2873) > at com.jcraft.jsch.ChannelSftp.put(ChannelSftp.java:768) > at com.jcraft.jsch.ChannelSftp.put(ChannelSftp.java:709) > at com.jcraft.jsch.ChannelSftp.put(ChannelSftp.java:706) > at > org.apache.commons.vfs2.provider.sftp.SftpFileObject.doGetOutputStream(SftpFileObject.java:475) > at > org.apache.commons.vfs2.provider.AbstractFileObject.getOutputStream(AbstractFileObject.java:1239) > ... 44 common frames omitted -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (VFS-776) Random Times i am receiving file not found error
[ https://issues.apache.org/jira/browse/VFS-776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17449291#comment-17449291 ] Gary D. Gregory edited comment on VFS-776 at 11/25/21, 6:54 PM: Hi [~akhil_surapuram] I'm not sure how we can help unless you can provide a reproducer... in the form of a unit test, or standalone Maven project. Whatever works for you. TY. was (Author: garydgregory): Hi [~akhil_surapuram] I'm not sure how we can help unless you can provide a reproducer... in the form of a unit test, or standalone Maven project. Whatever works for you. > Random Times i am receiving file not found error > > > Key: VFS-776 > URL: https://issues.apache.org/jira/browse/VFS-776 > Project: Commons VFS > Issue Type: Bug >Reporter: Akhil Surapuram >Priority: Major > > Note removed sensitve information and replaced with (...) > Caused by: org.apache.commons.vfs2.FileSystemException: Could not copy > "file:///(...)" to "sftp://(...)". > at > org.apache.commons.vfs2.provider.AbstractFileObject.copyFrom(AbstractFileObject.java:300) > Caused by: org.apache.commons.vfs2.FileSystemException: Could not write to > "sftp://(...)". > at > org.apache.commons.vfs2.provider.AbstractFileObject.getOutputStream(AbstractFileObject.java:1243) > at > org.apache.commons.vfs2.provider.DefaultFileContent.buildOutputStream(DefaultFileContent.java:518) > at > org.apache.commons.vfs2.provider.DefaultFileContent.getOutputStream(DefaultFileContent.java:404) > at > org.apache.commons.vfs2.provider.DefaultFileContent.getOutputStream(DefaultFileContent.java:392) > at > org.apache.commons.vfs2.provider.DefaultFileContent.write(DefaultFileContent.java:753) > at > org.apache.commons.vfs2.provider.DefaultFileContent.write(DefaultFileContent.java:771) > at org.apache.commons.vfs2.FileUtil.copyContent(FileUtil.java:37) > at > org.apache.commons.vfs2.provider.AbstractFileObject.copyFrom(AbstractFileObject.java:295) > ... 37 common frames omitted > Caused by: com.jcraft.jsch.SftpException: No such file > at com.jcraft.jsch.ChannelSftp.throwStatusError(ChannelSftp.java:2873) > at com.jcraft.jsch.ChannelSftp.put(ChannelSftp.java:768) > at com.jcraft.jsch.ChannelSftp.put(ChannelSftp.java:709) > at com.jcraft.jsch.ChannelSftp.put(ChannelSftp.java:706) > at > org.apache.commons.vfs2.provider.sftp.SftpFileObject.doGetOutputStream(SftpFileObject.java:475) > at > org.apache.commons.vfs2.provider.AbstractFileObject.getOutputStream(AbstractFileObject.java:1239) > ... 44 common frames omitted -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (VFS-778) SftpFileSystem returning null channel
[
https://issues.apache.org/jira/browse/VFS-778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17449289#comment-17449289
]
Gary D. Gregory commented on VFS-778:
-
I'm not sure where we are with this issue. May someone check 2.9.0 or/and git
master?
> SftpFileSystem returning null channel
> -
>
> Key: VFS-778
> URL: https://issues.apache.org/jira/browse/VFS-778
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.4.1, 2.5.0, 2.6.0
>Reporter: Manish Bansal
>Priority: Major
> Labels: pull-request-available
>
> I tested v2.4.1 jar with 8 threads. The purpose was to upload 1.3TB of data
> on FTP via sftp protocol. There were 850 folders with varying sizes from 10
> MB to 25GB. After the job was finished, It was observed that 50 folders
> failed to upload due to null pointer exception as below.
> {code:java}
> java.lang.NullPointerException: null
> at
> org.apache.commons.vfs2.provider.sftp.SftpFileObject.doGetOutputStream(SftpFileObject.java:475)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getOutputStream(AbstractFileObject.java:1239)
> at
> org.apache.commons.vfs2.provider.DefaultFileContent.buildOutputStream(DefaultFileContent.java:518)
> at
> org.apache.commons.vfs2.provider.DefaultFileContent.getOutputStream(DefaultFileContent.java:404)
> at
> org.apache.commons.vfs2.provider.DefaultFileContent.getOutputStream(DefaultFileContent.java:392)
> at
> org.apache.commons.vfs2.provider.DefaultFileContent.write(DefaultFileContent.java:753)
> at
> org.apache.commons.vfs2.provider.DefaultFileContent.write(DefaultFileContent.java:771)
> at org.apache.commons.vfs2.FileUtil.copyContent(FileUtil.java:37)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.copyFrom(AbstractFileObject.java:295)
> at com.infy.task.helper.FTPUploader.uploadToFTP(FTPUploader.java:173)
> at com.infy.task.helper.FTPUploader.upload(FTPUploader.java:90)
> at
> com.infy.task.AssetDownloadAndUploadTask.run(AssetDownloadAndUploadTask.java:57)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Further, I have analysed the code, it is very highly likely that it will
> return null due to below piece of code.
> {code:java}
> protected ChannelSftp getChannel() throws IOException {
> try {
> // Use the pooled channel, or create a new one
> ChannelSftp channel = null;
> if (idleChannel != null) {
> synchronized (this) {
> // What will happen if my code comes here and idleChannel is null
> if (idleChannel != null) {
> channel = idleChannel;
> idleChannel = null;
> }
> }
> } else {
> channel= .. //create channel
> }
> // some more code
> return channel;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (VFS-793) GenericFileName.getURI() returns invalid URI.
[
https://issues.apache.org/jira/browse/VFS-793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory resolved VFS-793.
-
Fix Version/s: 2.9.1
Resolution: Fixed
> GenericFileName.getURI() returns invalid URI.
> -
>
> Key: VFS-793
> URL: https://issues.apache.org/jira/browse/VFS-793
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.7.0
>Reporter: Vitali Nashkevich
>Priority: Minor
> Fix For: 2.9.1
>
>
> The following test case demonstrates the problem
> {code:java}
> @Test
> public void testGenericFileName()
> throws Exception
> {
> {
> final String uri =
> "ftp://blanks:blanks@localhost/path/file_b%20lanks;;
> final FileName n =
> FtpFileNameParser.getInstance().parseUri(null, null, uri);
> assert n instanceof GenericFileName;
> final String genericUri = n.getURI();
> assert genericUri.equals(uri.toString());
> }
>
> {
> final String uri =
> "ftp://b%20lanks:b%20lanks@localhost/path/file;;
> final FileName n =
> FtpFileNameParser.getInstance().parseUri(null, null, uri);
> assert n instanceof GenericFileName;
> final String genericUri = n.getURI();
> assert genericUri.equals(uri.toString());
> }
> }
> {code}
> The blanks in authority are not properly encoded.
> As a result the following fragment does not work either
> {code:java}
> final URI uri = new URI("ftp://b%20lanks:b%20lanks@localhost:21/path/file;);
> try ( final FileSystemManager m = VFS.getManager() )
> {
> try ( final FileObject f = m.resolveFile(uri) )
> {
> assert f instanceof FtpFileObject;
> final URI vfsUri = f.getURI();
> assert uri.equals(vfsUri);
> }
> }
> {code}
>
> The call {code:java}f.getURI();{code}
> throws exception
> {noformat}
> java.lang.IllegalArgumentException: Illegal character in authority at index
> 6: ftp://b lanks:b lanks@localhost/path/file
> at java.net.URI.create(Unknown Source)
> at org.apache.commons.vfs2.FileObject.getURI(FileObject.java:303)
> at GetUriTest.testGetUri_ftp(GetUriTest.java:30)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
> at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
> at
> org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
> at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
> at
> org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
> at
> org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
> at
> org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
> at java.util.ArrayList.forEach(Unknown Source)
> at org.testng.TestRunner.privateRun(TestRunner.java:764)
> at org.testng.TestRunner.run(TestRunner.java:585)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
> at org.testng.SuiteRunner.run(SuiteRunner.java:286)
> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
> at org.testng.TestNG.runSuites(TestNG.java:1069)
> at org.testng.TestNG.run(TestNG.java:1037)
> at
> org.testng.remote.AbstractRemoteTestNG.run(AbstractRemoteTestNG.java:115)
> at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:251)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:77)
> Caused by: java.net.URISyntaxException: Illegal character in authority at
> index 6: ftp://b lanks:b lanks@localhost/path/file
> at java.net.URI$Parser.fail(Unknown Source)
> at java.net.URI$Parser.parseAuthority(Unknown Source)
> at java.net.URI$Parser.parseHierarchical(Unknown Source)
> at java.net.URI$Parser.parse(Unknown Source)
> at java.net.URI.(Unknown Source)
> ... 31 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (VFS-793) GenericFileName.getURI() returns invalid URI.
[
https://issues.apache.org/jira/browse/VFS-793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17449287#comment-17449287
]
Gary D. Gregory commented on VFS-793:
-
[~vnashkev] & [~woonsan],
I addressed this in VFS-810. See also the new test
{{{}org.apache.commons.vfs2.provider.ftp.FtpFileNameParserTestCase{}}}.
May you please verify and close if appropriate?
TY!
> GenericFileName.getURI() returns invalid URI.
> -
>
> Key: VFS-793
> URL: https://issues.apache.org/jira/browse/VFS-793
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.7.0
>Reporter: Vitali Nashkevich
>Priority: Minor
>
> The following test case demonstrates the problem
> {code:java}
> @Test
> public void testGenericFileName()
> throws Exception
> {
> {
> final String uri =
> "ftp://blanks:blanks@localhost/path/file_b%20lanks;;
> final FileName n =
> FtpFileNameParser.getInstance().parseUri(null, null, uri);
> assert n instanceof GenericFileName;
> final String genericUri = n.getURI();
> assert genericUri.equals(uri.toString());
> }
>
> {
> final String uri =
> "ftp://b%20lanks:b%20lanks@localhost/path/file;;
> final FileName n =
> FtpFileNameParser.getInstance().parseUri(null, null, uri);
> assert n instanceof GenericFileName;
> final String genericUri = n.getURI();
> assert genericUri.equals(uri.toString());
> }
> }
> {code}
> The blanks in authority are not properly encoded.
> As a result the following fragment does not work either
> {code:java}
> final URI uri = new URI("ftp://b%20lanks:b%20lanks@localhost:21/path/file;);
> try ( final FileSystemManager m = VFS.getManager() )
> {
> try ( final FileObject f = m.resolveFile(uri) )
> {
> assert f instanceof FtpFileObject;
> final URI vfsUri = f.getURI();
> assert uri.equals(vfsUri);
> }
> }
> {code}
>
> The call {code:java}f.getURI();{code}
> throws exception
> {noformat}
> java.lang.IllegalArgumentException: Illegal character in authority at index
> 6: ftp://b lanks:b lanks@localhost/path/file
> at java.net.URI.create(Unknown Source)
> at org.apache.commons.vfs2.FileObject.getURI(FileObject.java:303)
> at GetUriTest.testGetUri_ftp(GetUriTest.java:30)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
> at java.lang.reflect.Method.invoke(Unknown Source)
> at
> org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
> at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
> at
> org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
> at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
> at
> org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
> at
> org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
> at
> org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
> at java.util.ArrayList.forEach(Unknown Source)
> at org.testng.TestRunner.privateRun(TestRunner.java:764)
> at org.testng.TestRunner.run(TestRunner.java:585)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
> at org.testng.SuiteRunner.run(SuiteRunner.java:286)
> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
> at org.testng.TestNG.runSuites(TestNG.java:1069)
> at org.testng.TestNG.run(TestNG.java:1037)
> at
> org.testng.remote.AbstractRemoteTestNG.run(AbstractRemoteTestNG.java:115)
> at org.testng.remote.RemoteTestNG.initAndRun(RemoteTestNG.java:251)
> at org.testng.remote.RemoteTestNG.main(RemoteTestNG.java:77)
> Caused by: java.net.URISyntaxException: Illegal character in authority at
> index 6: ftp://b lanks:b lanks@localhost/path/file
> at java.net.URI$Parser.fail(Unknown Source)
> at java.net.URI$Parser.parseAuthority(Unknown Source)
> at java.net.URI$Parser.parseHierarchical(Unknown Source)
> at java.net.URI$Parser.parse(Unknown Source)
> at
[jira] [Commented] (VFS-797) JIRA Fix VFS-741 is causing an error in reading the files from azure host using azsb protocol. Error is: org.apache.commons.vfs2.FileSystemException: Invalid descen
[ https://issues.apache.org/jira/browse/VFS-797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17449286#comment-17449286 ] Gary D. Gregory commented on VFS-797: - Hello [~alir3], Do you have an update on this issue? Note that our current release is 2.9.0. > JIRA Fix VFS-741 is causing an error in reading the files from azure host > using azsb protocol.Error is: > org.apache.commons.vfs2.FileSystemException: Invalid descendent file name > ".//devexports/AgreementPrice/ECPServiceConfig.txt" > - > > Key: VFS-797 > URL: https://issues.apache.org/jira/browse/VFS-797 > Project: Commons VFS > Issue Type: Bug >Reporter: Raghib Ali >Assignee: Gary D. Gregory >Priority: Blocker > > I have updated the VFS version to from 2.2 to 2.7.0. Since then I have been > getting an error for my application in reading the files from azure host > using 'azsb' protocol. By default, it adds the prefix ./ in the filename > which is throwing an exception in resolving the filename. > > The error that is thrown is as below: > Caused by: org.apache.commons.vfs2.FileSystemException: Could not find files > in > "azsb://usw2bscssisdumps.core.windows.net/devexports/AgreementPrice".Caused > by: org.apache.commons.vfs2.FileSystemException: Could not find files in > "azsb://usw2bscssisdumps.core.windows.net/devexports/AgreementPrice". at > org.apache.commons.vfs2.provider.AbstractFileObject.findFiles(AbstractFileObject.java:1015) > at > org.apache.commons.vfs2.provider.AbstractFileObject.listFiles(AbstractFileObject.java:1663) > at > org.apache.commons.vfs2.provider.AbstractFileObject.findFiles(AbstractFileObject.java:990) > at > com.bsc.intg.svcs.core.vfs.BSCVFSProvider.listFiles(BSCVFSProvider.java:234) > at > com.bsc.intg.svcs.core.vfs.BSCVFSListenerContainer.process(BSCVFSListenerContainer.java:142) > ... 3 common frames omitted > > Caused by: org.apache.commons.vfs2.FileSystemException: Invalid descendent > file name ".//devexports/AgreementPrice/ECPServiceConfig.txt". at > org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:806) > at > org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:1116) > at > org.apache.commons.vfs2.provider.AbstractFileObject.traverse(AbstractFileObject.java:93) > at > org.apache.commons.vfs2.provider.AbstractFileObject.findFiles(AbstractFileObject.java:1012) > ... 7 common frames omitted > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (VFS-807) LocalFile migration to NIO is not done correctly
[
https://issues.apache.org/jira/browse/VFS-807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17449284#comment-17449284
]
Gary D. Gregory commented on VFS-807:
-
[~klv_m72]
Can this ticket be closed?
> LocalFile migration to NIO is not done correctly
>
>
> Key: VFS-807
> URL: https://issues.apache.org/jira/browse/VFS-807
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.9.0
>Reporter: L
>Priority: Blocker
> Fix For: 2.9.1
>
> Attachments: TestJdkWriteFile.java, vfs-807.diff
>
>
> According to release notes
> ([https://archive.apache.org/dist/commons/vfs/RELEASE-NOTES.txt),] version
> 2.9.0 includes the following change:
> Replace construction of FileInputStream and FileOutputStream objects with
> Files NIO APIs. #164. Thanks to Arturo Bernal.
> Strangely, it was not completed: LocalFlie.java has the following now, even
> in master:
> {code:java}
> /**
> * Creates an input stream to read the content from.
> */
> @Override
> protected InputStream doGetInputStream(final int bufferSize) throws
> Exception {
> return new FileInputStream(file);
> }
> {code}
>
> But what is worse, doGetOutputStream is *completely* broken:
> {code:java}
> /**
> * Creates an output stream to write the file content to.
> */
> @Override
> protected OutputStream doGetOutputStream(final boolean bAppend) throws
> Exception {
> return Files.newOutputStream(file.toPath(), bAppend ?
> StandardOpenOption.APPEND : StandardOpenOption.CREATE);
> } {code}
>
> This can be demonstrated with a small java program, see attachment. The
> program just tries to write to a local file (into the same directory), using
> different ways to do it:
> # Java IO, how it was done before VFS 2.9.0
> # Java NIO the way VFS 2.9.0 does it
> # Java NIO the way it must be done
> What is important, the program also verifies the result.
> VFS 2.9.0 fails in 2 cases:
> # When the file does not exist and append must be performed:
> java.nio.file.NoSuchFileException is thrown in this case.
> # When the file exists and no append must be performed: the file is not
> truncated, so whatever is written overwrites the beginning of the file,
> keeping the rest.
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (VFS-810) Percent encoded backslashes in authority of URLs aren't allowed for WebDav
[ https://issues.apache.org/jira/browse/VFS-810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved VFS-810. - Fix Version/s: 2.9.1 Resolution: Fixed Hi [~Jan_], Thank you for your report and efforts with PR 222. I think I've been able to solve this for all providers instead of a select few, in git master. Please git it a try and close this PR if your use case works. TY! > Percent encoded backslashes in authority of URLs aren't allowed for WebDav > -- > > Key: VFS-810 > URL: https://issues.apache.org/jira/browse/VFS-810 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.8.0 >Reporter: Jan Aelbrecht >Priority: Major > Fix For: 2.9.1 > > Original Estimate: 1h > Remaining Estimate: 1h > > The following urls fail to resolve due to illegal character "\" in the > authority > webdav://test%5Calice:sec...@example.com:80 > [https://test%5Calice:sec...@example.com:80|https://testalice:sec...@example.com:80/] > > This can be resolved by using a different URI parser instead of the default > URI.create(...) > > > Created a PR on GitHub > [https://github.com/apache/commons-vfs/pull/222] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (VFS-810) Percent encoded Backslashes in authority of URLs aren't allowed for WebDav
[ https://issues.apache.org/jira/browse/VFS-810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated VFS-810: Summary: Percent encoded Backslashes in authority of URLs aren't allowed for WebDav (was: Backslashes in authority of URLs aren't allowed for WebDav) > Percent encoded Backslashes in authority of URLs aren't allowed for WebDav > -- > > Key: VFS-810 > URL: https://issues.apache.org/jira/browse/VFS-810 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.8.0 >Reporter: Jan Aelbrecht >Priority: Major > Original Estimate: 1h > Remaining Estimate: 1h > > The following urls fail to resolve due to illegal character "\" in the > authority > webdav://test%5Calice:sec...@example.com:80 > [https://test%5Calice:sec...@example.com:80|https://testalice:sec...@example.com:80/] > > This can be resolved by using a different URI parser instead of the default > URI.create(...) > > > Created a PR on GitHub > [https://github.com/apache/commons-vfs/pull/222] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (VFS-810) Percent encoded backslashes in authority of URLs aren't allowed for WebDav
[ https://issues.apache.org/jira/browse/VFS-810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated VFS-810: Summary: Percent encoded backslashes in authority of URLs aren't allowed for WebDav (was: Percent encoded Backslashes in authority of URLs aren't allowed for WebDav) > Percent encoded backslashes in authority of URLs aren't allowed for WebDav > -- > > Key: VFS-810 > URL: https://issues.apache.org/jira/browse/VFS-810 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.8.0 >Reporter: Jan Aelbrecht >Priority: Major > Original Estimate: 1h > Remaining Estimate: 1h > > The following urls fail to resolve due to illegal character "\" in the > authority > webdav://test%5Calice:sec...@example.com:80 > [https://test%5Calice:sec...@example.com:80|https://testalice:sec...@example.com:80/] > > This can be resolved by using a different URI parser instead of the default > URI.create(...) > > > Created a PR on GitHub > [https://github.com/apache/commons-vfs/pull/222] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (VFS-810) Backslashes in authority of URLs aren't allowed for WebDav
[ https://issues.apache.org/jira/browse/VFS-810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated VFS-810: Summary: Backslashes in authority of URLs aren't allowed for WebDav (was: Backslashes in authority of urls aren't allowed for WebDav) > Backslashes in authority of URLs aren't allowed for WebDav > -- > > Key: VFS-810 > URL: https://issues.apache.org/jira/browse/VFS-810 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.8.0 >Reporter: Jan Aelbrecht >Priority: Major > Original Estimate: 1h > Remaining Estimate: 1h > > The following urls fail to resolve due to illegal character "\" in the > authority > webdav://test%5Calice:sec...@example.com:80 > [https://test%5Calice:sec...@example.com:80|https://testalice:sec...@example.com:80/] > > This can be resolved by using a different URI parser instead of the default > URI.create(...) > > > Created a PR on GitHub > [https://github.com/apache/commons-vfs/pull/222] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [commons-collections] coveralls edited a comment on pull request #258: Simplify bloom filters
coveralls edited a comment on pull request #258: URL: https://github.com/apache/commons-collections/pull/258#issuecomment-976841734 [](https://coveralls.io/builds/44549616) Coverage decreased (-0.1%) to 90.003% when pulling **f2bc6987d8439e33f020ee927f72e9641f708c54 on Claudenw:simplify_bloom_filters** into **23f2d363c5935cac57b6b41938dc662ad9f3463c on apache:master**. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-vfs] garydgregory merged pull request #220: Bump actions/checkout from 2.3.5 to 2.4.0
garydgregory merged pull request #220: URL: https://github.com/apache/commons-vfs/pull/220 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-vfs] garydgregory commented on pull request #222: VFS-810: Use different UriBuilder for Http4FileSystem
garydgregory commented on pull request #222: URL: https://github.com/apache/commons-vfs/pull/222#issuecomment-979380307 I have a possible fix in the guts of VFS, stay tuned... This PR is still not the best path IMO because it only deals with a single provider, does not solve the general problem, and adds a dependency on yet another library which happens to be used to test Hadoop. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-vfs] garydgregory merged pull request #219: Bump jackrabbit2.version from 2.21.7 to 2.21.8
garydgregory merged pull request #219: URL: https://github.com/apache/commons-vfs/pull/219 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-vfs] garydgregory commented on pull request #219: Bump jackrabbit2.version from 2.21.7 to 2.21.8
garydgregory commented on pull request #219: URL: https://github.com/apache/commons-vfs/pull/219#issuecomment-979362846 Known random test fail. Will merge... -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-vfs] garydgregory commented on pull request #221: Bump actions/cache from 2.1.6 to 2.1.7
garydgregory commented on pull request #221: URL: https://github.com/apache/commons-vfs/pull/221#issuecomment-979361602 Known random failures unfortunately. Will merge... -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-vfs] garydgregory merged pull request #221: Bump actions/cache from 2.1.6 to 2.1.7
garydgregory merged pull request #221: URL: https://github.com/apache/commons-vfs/pull/221 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (VFS-810) Backslashes in authority of urls aren't allowed for WebDav
[ https://issues.apache.org/jira/browse/VFS-810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Aelbrecht updated VFS-810: -- Description: The following urls fail to resolve due to illegal character "\" in the authority webdav://test%5Calice:sec...@example.com:80 [https://test%5Calice:sec...@example.com:80|https://testalice:sec...@example.com:80/] This can be resolved by using a different URI parser instead of the default URI.create(...) Created a PR on GitHub [https://github.com/apache/commons-vfs/pull/222] was: The following urls fail to resolve due to illegal character "\" in the authority webdav://test\alice:sec...@example.com:80 [https://test\alice:sec...@example.com:80|https://testalice:sec...@example.com:80/] This can be resolved by using a different URI parser instead of the default URI.create(...) Created a PR on GitHub [https://github.com/apache/commons-vfs/pull/222] > Backslashes in authority of urls aren't allowed for WebDav > -- > > Key: VFS-810 > URL: https://issues.apache.org/jira/browse/VFS-810 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.8.0 >Reporter: Jan Aelbrecht >Priority: Major > Original Estimate: 1h > Remaining Estimate: 1h > > The following urls fail to resolve due to illegal character "\" in the > authority > webdav://test%5Calice:sec...@example.com:80 > [https://test%5Calice:sec...@example.com:80|https://testalice:sec...@example.com:80/] > > This can be resolved by using a different URI parser instead of the default > URI.create(...) > > > Created a PR on GitHub > [https://github.com/apache/commons-vfs/pull/222] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [commons-vfs] JanAelb commented on pull request #222: VFS-810: Use different UriBuilder for Http4FileSystem
JanAelb commented on pull request #222: URL: https://github.com/apache/commons-vfs/pull/222#issuecomment-979346404 Thank you for the quick response. Passing `"http4://alice%5C1234:secret@localhost:80"` is indeed the problem I want to handle. I updated the tests. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (VFS-810) Backslashes in authority of urls aren't allowed for WebDav
[ https://issues.apache.org/jira/browse/VFS-810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated VFS-810: Fix Version/s: (was: 2.9.1) > Backslashes in authority of urls aren't allowed for WebDav > -- > > Key: VFS-810 > URL: https://issues.apache.org/jira/browse/VFS-810 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.8.0 >Reporter: Jan Aelbrecht >Priority: Major > Original Estimate: 1h > Remaining Estimate: 1h > > The following urls fail to resolve due to illegal character "\" in the > authority > webdav://test\alice:sec...@example.com:80 > [https://test\alice:sec...@example.com:80|https://testalice:sec...@example.com:80/] > > This can be resolved by using a different URI parser instead of the default > URI.create(...) > > > Created a PR on GitHub > [https://github.com/apache/commons-vfs/pull/222] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Work logged] (POOL-402) Check blockWhenExhausted in hasBorrowWaiters
[ https://issues.apache.org/jira/browse/POOL-402?focusedWorklogId=686557=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-686557 ] ASF GitHub Bot logged work on POOL-402: --- Author: ASF GitHub Bot Created on: 25/Nov/21 16:08 Start Date: 25/Nov/21 16:08 Worklog Time Spent: 10m Work Description: garydgregory commented on pull request #116: URL: https://github.com/apache/commons-pool/pull/116#issuecomment-979330169 I'll take a look over this long weekend (which is now in the US for me). TY for your patience . -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 686557) Time Spent: 1h (was: 50m) > Check blockWhenExhausted in hasBorrowWaiters > > > Key: POOL-402 > URL: https://issues.apache.org/jira/browse/POOL-402 > Project: Commons Pool > Issue Type: Improvement >Affects Versions: 2.11.1 >Reporter: Bruno P. Kinoshita >Priority: Major > Fix For: 2.12.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Placeholder for https://github.com/apache/commons-pool/pull/116 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [commons-pool] garydgregory commented on pull request #116: [POOL-402] Check blockWhenExhausted in hasBorrowWaiters
garydgregory commented on pull request #116: URL: https://github.com/apache/commons-pool/pull/116#issuecomment-979330169 I'll take a look over this long weekend (which is now in the US for me). TY for your patience . -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-collections] Claudenw commented on pull request #258: Simplify bloom filters
Claudenw commented on pull request #258: URL: https://github.com/apache/commons-collections/pull/258#issuecomment-979311488 Travis appears to be complaining about code that is not changed by this pull request. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (COLLECTIONS-801) Simplify Bloom filter implementation
Claude Warren created COLLECTIONS-801: - Summary: Simplify Bloom filter implementation Key: COLLECTIONS-801 URL: https://issues.apache.org/jira/browse/COLLECTIONS-801 Project: Commons Collections Issue Type: Improvement Affects Versions: 4.5 Reporter: Claude Warren The initial Bloom filter implementation has a number of issues arising from attempting to verify that filters were built the same way (ie. same number of bits, number of functions, hashing algorithm, etc.) The net result is that there is significant overhead in the processing of the filters. For a structure that is intended to speed up decisions this is a fault. There are also issues with implementation hiding in the current code. The issue calls for: * The removal of the hashing tracking, all the registration and verification that the hashes are the same. This becomes an operational issue for the developer using the library. In most cases this is a trivial problem. * Removal of all methods that assume an implementation detail of the Bloom filter. Rather than getting a list of indices or a list of bitmap longs (or bytes) the classes will implement a "Producer" style that uses IntConsumer, LongConsumer, etc to receive the indices or bit maps. This pattern to carry forward to specialized filters like counting Bloom filters that will accept a BitCountConsumer to receive the counts for each bit. * There are cases where Bloom filters need to be updated and cases where they do not. The change should include merge() methods to produce new Bloom filters and mergeInPlace() methods to update the Bloom filters. * There are issues with some assumptions in the Hasher implementations wherein the static hasher does not function as described. Part of the goal of this change is to simplify the mechanism to pass the internal state of one bloom filter to another without either knowing the implementation of that state in the other. This will be done via the "Producer" interface described above. Hashers will be able to create IndexProducers that will produce the indices for a Bloom filter shape. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [commons-vfs] garydgregory commented on pull request #222: VFS-810: Use different UriBuilder for Http4FileSystem
garydgregory commented on pull request #222: URL: https://github.com/apache/commons-vfs/pull/222#issuecomment-979263867 -1 as the string in the example `"http4://alice\\1234:secret@localhost:80"` is not an RFC compliant URI, neither in [RFC 2396](https://datatracker.ietf.org/doc/html/rfc2396) or [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986). The problem is two-fold though, the above, plus the fact that there is a long-standing issue within VFS where we incorrectly handle percent-encoded values. If in the above you meant to escape the a single `\` character then then URL should be `"http4://alice%5C1234:secret@localhost:80"`; but, that seems to cause problems within VFS, so that's what needs to be fixed. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (GEOMETRY-142) Point Set/Map
[ https://issues.apache.org/jira/browse/GEOMETRY-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17449200#comment-17449200 ] Matt Juntunen commented on GEOMETRY-142: Welcome, [~kinow]! The more, the merrier :-) > Point Set/Map > - > > Key: GEOMETRY-142 > URL: https://issues.apache.org/jira/browse/GEOMETRY-142 > Project: Apache Commons Geometry > Issue Type: New Feature >Reporter: Matt Juntunen >Priority: Major > > It would be very useful to have set and map implementations that accepts > points and vectors as keys and use "fuzzy" look up logic, where values are > compared using a precision context. This would have uses in a number of > situations, including the implementation of GEOMETRY-110. > Options for the implementation of such classes include > * BSP trees (as already implemented) > * k-d trees > * quadtrees/octrees > * r-trees -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (VFS-810) Backslashes in authority of urls aren't allowed for WebDav
[ https://issues.apache.org/jira/browse/VFS-810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Aelbrecht updated VFS-810: -- Description: The following urls fail to resolve due to illegal character "\" in the authority webdav://test\alice:sec...@example.com:80 [https://test\alice:sec...@example.com:80|https://testalice:sec...@example.com:80/] This can be resolved by using a different URI parser instead of the default URI.create(...) Created a PR on GitHub [https://github.com/apache/commons-vfs/pull/222] was: The following urls fail to resolve due to illegal character "\" in the authority webdav://test\alice:sec...@example.com:80 https://test\alice:sec...@example.com:80 This can be resolved by using a different URI parser instead of the default URI.create(...) > Backslashes in authority of urls aren't allowed for WebDav > -- > > Key: VFS-810 > URL: https://issues.apache.org/jira/browse/VFS-810 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.8.0 >Reporter: Jan Aelbrecht >Priority: Major > Fix For: 2.9.1 > > Original Estimate: 1h > Remaining Estimate: 1h > > The following urls fail to resolve due to illegal character "\" in the > authority > webdav://test\alice:sec...@example.com:80 > [https://test\alice:sec...@example.com:80|https://testalice:sec...@example.com:80/] > > This can be resolved by using a different URI parser instead of the default > URI.create(...) > > > Created a PR on GitHub > [https://github.com/apache/commons-vfs/pull/222] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [commons-vfs] JanAelb opened a new pull request #222: VFS-810: Use different UriBuilder for Http4FileSystem
JanAelb opened a new pull request #222: URL: https://github.com/apache/commons-vfs/pull/222 There is an issue when parsing urls containing backslashes in Http4FileSystem and derived classes. https://issues.apache.org/jira/browse/VFS-810 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (VFS-810) Backslashes in authority of urls aren't allowed for WebDav
[ https://issues.apache.org/jira/browse/VFS-810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Aelbrecht updated VFS-810: -- Affects Version/s: 2.8.0 (was: 2.9.0) > Backslashes in authority of urls aren't allowed for WebDav > -- > > Key: VFS-810 > URL: https://issues.apache.org/jira/browse/VFS-810 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.8.0 >Reporter: Jan Aelbrecht >Priority: Major > Fix For: 2.9.1 > > Original Estimate: 1h > Remaining Estimate: 1h > > The following urls fail to resolve due to illegal character "\" in the > authority > webdav://test\alice:sec...@example.com:80 > https://test\alice:sec...@example.com:80 > > This can be resolved by using a different URI parser instead of the default > URI.create(...) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [commons-collections] coveralls edited a comment on pull request #258: WIP: Simplify bloom filters
coveralls edited a comment on pull request #258: URL: https://github.com/apache/commons-collections/pull/258#issuecomment-976841734 [](https://coveralls.io/builds/44537360) Coverage decreased (-0.1%) to 90.033% when pulling **285b3038a17c819b93c0870519f7466b5bdcac8e on Claudenw:simplify_bloom_filters** into **23f2d363c5935cac57b6b41938dc662ad9f3463c on apache:master**. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (VFS-810) Backslashes in authority of urls aren't allowed for WebDav
Jan Aelbrecht created VFS-810: - Summary: Backslashes in authority of urls aren't allowed for WebDav Key: VFS-810 URL: https://issues.apache.org/jira/browse/VFS-810 Project: Commons VFS Issue Type: Bug Affects Versions: 2.9.0 Reporter: Jan Aelbrecht Fix For: 2.9.1 The following urls fail to resolve due to illegal character "\" in the authority webdav://test\alice:sec...@example.com:80 https://test\alice:sec...@example.com:80 This can be resolved by using a different URI parser instead of the default URI.create(...) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (NUMBERS-174) Update Gamma functions using the Boost implementation
[
https://issues.apache.org/jira/browse/NUMBERS-174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17449039#comment-17449039
]
Alex Herbert commented on NUMBERS-174:
--
New code for review in [PR
110|https://github.com/apache/commons-numbers/pull/110]
Note: Currently the Travis CI integration with Github is not working for PRs.
Travis will build master but does not pick up PRs. So this should be verified
locally.
I tried changing .travis.yml to update the JDK environment from openjdk9 to
openjdk11 but this was not the cause since the master branch builds but not the
PR branch. No other changes to the .travis.yml have been done since the last PR
build 1 month ago ([Travis Commons Numbers
PRs|https://app.travis-ci.com/github/apache/commons-numbers/pull_requests]).
> Update Gamma functions using the Boost implementation
> -
>
> Key: NUMBERS-174
> URL: https://issues.apache.org/jira/browse/NUMBERS-174
> Project: Commons Numbers
> Issue Type: Improvement
> Components: gamma
>Affects Versions: 1.0
>Reporter: Alex Herbert
>Assignee: Alex Herbert
>Priority: Major
> Fix For: 1.1
>
>
> The current regularised incomplete gamma functions for P and Q compute using
> a series representation for all input. This method is not robust to extreme
> arguments.
> The Gamma functions are used in Commons Statistics in the Gamma and Poisson
> distributions.
> Large values of the mean in the Poisson distribution have low
> precision for the CDF. The distribution also has a configurable
> threshold for convergence of the gamma function evaluation
> (STATISTICS-38). Ideally this implementation detail should be
> removed from the API.
> The Gamma distribution has a function switch based on a threshold to
> compute the PDF. This threshold results in incorrect values for
> certain parameters (STATISTICS-39).
> The function switch in the Gamma distribution is based on the
> documentation for the Boost gamma functions [1]. However it does not
> implement all the suggested optimisations detailed in the most recent
> Boost documentation. This includes avoiding using the converging
> series of the gamma function when the convergence is slow or unstable,
> i.e. addresses the need for a configurable convergence threshold in
> the Poisson distribution.
> One part of the evaluation of the incomplete gamma functions require
> accuracy in the leading term:
> {noformat}
> x^a exp(-x) / gamma(a) = exp(a log(x) - x - loggamma(a){noformat}
> When x and a are large then using logs to compute this leads to
> cancellation. Use of logs to compute this term is done in the current
> implementation in numbers for RegularizedGamma P and Q. It is the
> source of low precision for the CDF for the Poisson distribution when
> the mean is large.
> I propose to port the Boost gamma functions to numbers. This will be a
> process similar to the recent port of the error functions to the same
> package in numbers. These functions improved both accuracy and
> speed over the existing implementation. Once the gamma functions are
> ported a comparison can be made between the existing and new
> implementations.
> [1]
> [https://www.boost.org/doc/libs/1_77_0/libs/math/doc/html/math_toolkit/sf_gamma/igamma.html]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [commons-release-plugin] dependabot[bot] opened a new pull request #88: Bump spotbugs-maven-plugin from 4.4.2.2 to 4.5.0.0
dependabot[bot] opened a new pull request #88: URL: https://github.com/apache/commons-release-plugin/pull/88 Bumps [spotbugs-maven-plugin](https://github.com/spotbugs/spotbugs-maven-plugin) from 4.4.2.2 to 4.5.0.0. Release notes Sourced from https://github.com/spotbugs/spotbugs-maven-plugin/releases;>spotbugs-maven-plugin's releases. Spotbugs-maven-plugin 4.5.0.0 support for spotbugs 4.5.0 Commits https://github.com/spotbugs/spotbugs-maven-plugin/commit/e6f455711fa5d823ca67bbdabd51cd2cd9fe7858;>e6f4557 [maven-release-plugin] prepare release spotbugs-maven-plugin-4.5.0.0 https://github.com/spotbugs/spotbugs-maven-plugin/commit/66857ad3847c11999c9b802b475b7f8ac15d9e0b;>66857ad [pom] Drop slf4j to 1.7.32 https://github.com/spotbugs/spotbugs-maven-plugin/commit/fa72729a632810eb24998decb707487af7623b30;>fa72729 [pom] Bump remainder of spotbugs to 4.5.0 and plugin to 4.5.0.0 snapshot https://github.com/spotbugs/spotbugs-maven-plugin/commit/1f30c3919eb7d13d4a73eff3505c74a52e502246;>1f30c39 Merge pull request https://github-redirect.dependabot.com/spotbugs/spotbugs-maven-plugin/issues/368;>#368 from spotbugs/dependabot/maven/com.github.spotbugs-sp... https://github.com/spotbugs/spotbugs-maven-plugin/commit/967ce4e4f53570ccff2e75214627826c932f685a;>967ce4e Bump spotbugs from 4.4.2 to 4.5.0 https://github.com/spotbugs/spotbugs-maven-plugin/commit/ac416fe31ec0f0f7118f8f9022e120c55b6b2279;>ac416fe [maven-release-plugin] prepare for next development iteration See full diff in https://github.com/spotbugs/spotbugs-maven-plugin/compare/spotbugs-maven-plugin-4.4.2.2...spotbugs-maven-plugin-4.5.0.0;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (POOL-402) Check blockWhenExhausted in hasBorrowWaiters
[ https://issues.apache.org/jira/browse/POOL-402?focusedWorklogId=686281=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-686281 ] ASF GitHub Bot logged work on POOL-402: --- Author: ASF GitHub Bot Created on: 25/Nov/21 08:15 Start Date: 25/Nov/21 08:15 Worklog Time Spent: 10m Work Description: Cp-John commented on pull request #116: URL: https://github.com/apache/commons-pool/pull/116#issuecomment-978936107 Hi~ @psteitz @kinow Can someone help to merge this PR if there are no other problems. 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 686281) Time Spent: 50m (was: 40m) > Check blockWhenExhausted in hasBorrowWaiters > > > Key: POOL-402 > URL: https://issues.apache.org/jira/browse/POOL-402 > Project: Commons Pool > Issue Type: Improvement >Affects Versions: 2.11.1 >Reporter: Bruno P. Kinoshita >Priority: Major > Fix For: 2.12.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Placeholder for https://github.com/apache/commons-pool/pull/116 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [commons-pool] Cp-John commented on pull request #116: [POOL-402] Check blockWhenExhausted in hasBorrowWaiters
Cp-John commented on pull request #116: URL: https://github.com/apache/commons-pool/pull/116#issuecomment-978936107 Hi~ @psteitz @kinow Can someone help to merge this PR if there are no other problems. 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
