[jira] [Commented] (GEOMETRY-38) Check unit test - line intersecting cube
[
https://issues.apache.org/jira/browse/GEOMETRY-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16751821#comment-16751821
]
Matt Juntunen commented on GEOMETRY-38:
---
Hi. Thanks for your interest in commons-geometry!
In response to your question on your PR, you are indeed using the library
correctly. This is a bona fide bug. The intersection logic in
{{PolyhedronSet.boundaryFacet()}} was only returning the facet if the
intersection point was on the inside of the facet. Thus, if the point was on
the boundary, it would not be returned. I've fixed this in the PR below and add
a unit test based on what you had.
On a side note, if you're interested in commons-geometry, we are currently in
the process of rewriting large chunks of it. There are Jira issues for most of
the major updates that we'd like to make, but feel free to add an issue if you
think something is missing. There are also plenty of things that need doing if
you'd like to go so far as contribute.
Thanks again!
Pull request: https://github.com/apache/commons-geometry/pull/21
> Check unit test - line intersecting cube
>
>
> Key: GEOMETRY-38
> URL: https://issues.apache.org/jira/browse/GEOMETRY-38
> Project: Apache Commons Geometry
> Issue Type: Task
> Components: Euclidean 3D
>Reporter: Sven Rathgeber
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Intersecting a cube (PolyhedronsSet) with a Line diagonally results in null.
> Please check the pull request:
> https://github.com/apache/commons-geometry/pull/19
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEOMETRY-39) Remove Unneeded PlaneAngleRadians Normalize Checks
[
https://issues.apache.org/jira/browse/GEOMETRY-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEOMETRY-39:
---
Labels: pull-request-available (was: )
> Remove Unneeded PlaneAngleRadians Normalize Checks
> ---
>
> Key: GEOMETRY-39
> URL: https://issues.apache.org/jira/browse/GEOMETRY-39
> Project: Apache Commons Geometry
> Issue Type: Task
>Reporter: Matt Juntunen
>Priority: Trivial
> Labels: pull-request-available
>
> Remove unneeded sections in the code where we check to ensure that the angle
> returned by one of the {{PlaneAngleRadians}} normalize methods is not equal
> to the upper bound. The upper bound for these methods is actually exclusive.
> See NUMBERS-93.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEOMETRY-39) Remove Unneeded PlaneAngleRadians Normalize Checks
Matt Juntunen created GEOMETRY-39:
-
Summary: Remove Unneeded PlaneAngleRadians Normalize Checks
Key: GEOMETRY-39
URL: https://issues.apache.org/jira/browse/GEOMETRY-39
Project: Apache Commons Geometry
Issue Type: Task
Reporter: Matt Juntunen
Remove unneeded sections in the code where we check to ensure that the angle
returned by one of the {{PlaneAngleRadians}} normalize methods is not equal to
the upper bound. The upper bound for these methods is actually exclusive. See
NUMBERS-93.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-656) Allow to support Explicit key exchange algorithm SFTP with SftpFileSystemConfigBuilder
[
https://issues.apache.org/jira/browse/VFS-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16751727#comment-16751727
]
Gary Gregory commented on VFS-656:
--
Patches on GitHub are welcome, as usual :)
> Allow to support Explicit key exchange algorithm SFTP with
> SftpFileSystemConfigBuilder
> --
>
> Key: VFS-656
> URL: https://issues.apache.org/jira/browse/VFS-656
> Project: Commons VFS
> Issue Type: Bug
>Reporter: Barak Kedem
>Priority: Major
>
> I'm working with SFTP and SftpFileSystemConfigBuilder
> While I would like to set specific Key exchange algorithm - but it's not
> possible due to protected/private access.
>
> I think you should have a method for
> {code}
> public void setKeyExchangeAlgorithm(FileSystemOptions opts, String
> keyExchangeAlgoritm) throws FileSystemException
> {
> setParam(opts, "kex", keyExchangeAlgoritm);
> }
> {code}
>
> Just like you have a method you already have. setStrictHostKeyChecking
>
> [https://github.com/EsupPortail/commons-vfs2-project-2.0/compare/master...KedemBarak:master]
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (VFS-670) DefaultFileSystemManager should implement AutoCloseable
[ https://issues.apache.org/jira/browse/VFS-670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved VFS-670. -- Resolution: Fixed Fix Version/s: 2.3 In svn trunk. Please verify and close. > DefaultFileSystemManager should implement AutoCloseable > --- > > Key: VFS-670 > URL: https://issues.apache.org/jira/browse/VFS-670 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Daniel Banks >Priority: Trivial > Fix For: 2.3 > > > DefaultFileSystemManager should implement Closeable or AutoCloseable to allow > use of try-with-resources. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (VFS-670) DefaultFileSystemManager should implement AutoCloseable
[ https://issues.apache.org/jira/browse/VFS-670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated VFS-670: - Summary: DefaultFileSystemManager should implement AutoCloseable (was: DefaultFileSystemManager should implement Closeable) > DefaultFileSystemManager should implement AutoCloseable > --- > > Key: VFS-670 > URL: https://issues.apache.org/jira/browse/VFS-670 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Daniel Banks >Priority: Trivial > > DefaultFileSystemManager should implement Closeable or AutoCloseable to allow > use of try-with-resources. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (VFS-673) Support com.jcraft.jsch.ConfigRepository (~/.ssh/config) with SftpFileSystemConfigBuilder and flag to load OpenSSHConfig
[ https://issues.apache.org/jira/browse/VFS-673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved VFS-673. -- Resolution: Fixed Fix Version/s: 2.3 In svn trunk. Please verify and close. > Support com.jcraft.jsch.ConfigRepository (~/.ssh/config) with > SftpFileSystemConfigBuilder and flag to load OpenSSHConfig > > > Key: VFS-673 > URL: https://issues.apache.org/jira/browse/VFS-673 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Oleksandr Lykhonosov >Priority: Major > Fix For: 2.3 > > > Allow to set *com.jcraft.jsch.ConfigRepository* explicitly and flag to load > *OpenSSHConfig* if the ConfigRepository was not provided. > [JSch-Examples-OpenSSHConfig|http://www.jcraft.com/jsch/examples/OpenSSHConfig.java.html] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (VFS-677) [SFTP] Add support for append mode.
[
https://issues.apache.org/jira/browse/VFS-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated VFS-677:
-
Summary: [SFTP] Add support for append mode. (was: [SFTP] The file type
does not support append mode.)
> [SFTP] Add support for append mode.
> ---
>
> Key: VFS-677
> URL: https://issues.apache.org/jira/browse/VFS-677
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: {code:java}
>
> org.apache.commons
> commons-vfs2
> 2.2
>
> {code}
>Reporter: dingxbcn
>Priority: Minor
> Attachments: image-2018-10-25-11-10-10-799.png,
> image-2018-10-25-13-48-58-673.png, image-2018-10-25-13-49-13-334.png
>
>
> I am trying to append content to a sftp file. but vfs seems not supports that.
>
> My test code:
> {code:java}
> FileObject file =
> fsManager.resolveFile("sftp://root:xxx@192.168.1.1:22/sftpappend.txt; );
> if (!file.exists()) {
> file.createFile();
> }
> FileContent content = file.getContent();
> OutputStream outputStream = content.getOutputStream(true);
> {code}
>
> Error info :
> {code:java}
> org.apache.commons.vfs2.FileSystemException: The file type does not support
> append mode.
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getOutputStream(AbstractFileObject.java:1180)
> at
> org.apache.commons.vfs2.provider.DefaultFileContent.getOutputStream(DefaultFileContent.java:413)
> {code}
> I checked the source code. seems its easy to support APPEND option in sftp.
> {color:#FF}Why commons-vfs doesn't do that?{color}
> org.apache.commons.vfs2.provider.sftp.SftpFileObject#doGetOutputStream
> !image-2018-10-25-11-10-10-799.png!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (VFS-677) [SFTP] Add support for append mode.
[
https://issues.apache.org/jira/browse/VFS-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved VFS-677.
--
Resolution: Fixed
Fix Version/s: 2.3
In svn trunk. Please verify and close.
> [SFTP] Add support for append mode.
> ---
>
> Key: VFS-677
> URL: https://issues.apache.org/jira/browse/VFS-677
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: {code:java}
>
> org.apache.commons
> commons-vfs2
> 2.2
>
> {code}
>Reporter: dingxbcn
>Priority: Minor
> Fix For: 2.3
>
> Attachments: image-2018-10-25-11-10-10-799.png,
> image-2018-10-25-13-48-58-673.png, image-2018-10-25-13-49-13-334.png
>
>
> I am trying to append content to a sftp file. but vfs seems not supports that.
>
> My test code:
> {code:java}
> FileObject file =
> fsManager.resolveFile("sftp://root:xxx@192.168.1.1:22/sftpappend.txt; );
> if (!file.exists()) {
> file.createFile();
> }
> FileContent content = file.getContent();
> OutputStream outputStream = content.getOutputStream(true);
> {code}
>
> Error info :
> {code:java}
> org.apache.commons.vfs2.FileSystemException: The file type does not support
> append mode.
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getOutputStream(AbstractFileObject.java:1180)
> at
> org.apache.commons.vfs2.provider.DefaultFileContent.getOutputStream(DefaultFileContent.java:413)
> {code}
> I checked the source code. seems its easy to support APPEND option in sftp.
> {color:#FF}Why commons-vfs doesn't do that?{color}
> org.apache.commons.vfs2.provider.sftp.SftpFileObject#doGetOutputStream
> !image-2018-10-25-11-10-10-799.png!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (VFS-677) [SFTP] The file type does not support append mode.
[
https://issues.apache.org/jira/browse/VFS-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated VFS-677:
-
Summary: [SFTP] The file type does not support append mode. (was: [VFS]
[sftp] The file type does not support append mode.)
> [SFTP] The file type does not support append mode.
> --
>
> Key: VFS-677
> URL: https://issues.apache.org/jira/browse/VFS-677
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: {code:java}
>
> org.apache.commons
> commons-vfs2
> 2.2
>
> {code}
>Reporter: dingxbcn
>Priority: Minor
> Attachments: image-2018-10-25-11-10-10-799.png,
> image-2018-10-25-13-48-58-673.png, image-2018-10-25-13-49-13-334.png
>
>
> I am trying to append content to a sftp file. but vfs seems not supports that.
>
> My test code:
> {code:java}
> FileObject file =
> fsManager.resolveFile("sftp://root:xxx@192.168.1.1:22/sftpappend.txt; );
> if (!file.exists()) {
> file.createFile();
> }
> FileContent content = file.getContent();
> OutputStream outputStream = content.getOutputStream(true);
> {code}
>
> Error info :
> {code:java}
> org.apache.commons.vfs2.FileSystemException: The file type does not support
> append mode.
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getOutputStream(AbstractFileObject.java:1180)
> at
> org.apache.commons.vfs2.provider.DefaultFileContent.getOutputStream(DefaultFileContent.java:413)
> {code}
> I checked the source code. seems its easy to support APPEND option in sftp.
> {color:#FF}Why commons-vfs doesn't do that?{color}
> org.apache.commons.vfs2.provider.sftp.SftpFileObject#doGetOutputStream
> !image-2018-10-25-11-10-10-799.png!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (VFS-677) [VFS] [sftp] The file type does not support append mode.
[
https://issues.apache.org/jira/browse/VFS-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated VFS-677:
-
External issue URL: https://github.com/apache/commons-vfs/pull/42
External issue ID: 42
> [VFS] [sftp] The file type does not support append mode.
>
>
> Key: VFS-677
> URL: https://issues.apache.org/jira/browse/VFS-677
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: {code:java}
>
> org.apache.commons
> commons-vfs2
> 2.2
>
> {code}
>Reporter: dingxbcn
>Priority: Minor
> Attachments: image-2018-10-25-11-10-10-799.png,
> image-2018-10-25-13-48-58-673.png, image-2018-10-25-13-49-13-334.png
>
>
> I am trying to append content to a sftp file. but vfs seems not supports that.
>
> My test code:
> {code:java}
> FileObject file =
> fsManager.resolveFile("sftp://root:xxx@192.168.1.1:22/sftpappend.txt; );
> if (!file.exists()) {
> file.createFile();
> }
> FileContent content = file.getContent();
> OutputStream outputStream = content.getOutputStream(true);
> {code}
>
> Error info :
> {code:java}
> org.apache.commons.vfs2.FileSystemException: The file type does not support
> append mode.
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getOutputStream(AbstractFileObject.java:1180)
> at
> org.apache.commons.vfs2.provider.DefaultFileContent.getOutputStream(DefaultFileContent.java:413)
> {code}
> I checked the source code. seems its easy to support APPEND option in sftp.
> {color:#FF}Why commons-vfs doesn't do that?{color}
> org.apache.commons.vfs2.provider.sftp.SftpFileObject#doGetOutputStream
> !image-2018-10-25-11-10-10-799.png!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (VFS-688) [SFTP] Update jsch from 0.1.54 to 0.1.55
[ https://issues.apache.org/jira/browse/VFS-688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed VFS-688. Resolution: Fixed Fix Version/s: 2.3 In svn trunk. > [SFTP] Update jsch from 0.1.54 to 0.1.55 > > > Key: VFS-688 > URL: https://issues.apache.org/jira/browse/VFS-688 > Project: Commons VFS > Issue Type: Improvement >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: 2.3 > > > [SFTP] Update jsch from 0.1.54 to 0.1.55 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (VFS-688) [SFTP] Update jsch from 0.1.54 to 0.1.55
Gary Gregory created VFS-688: Summary: [SFTP] Update jsch from 0.1.54 to 0.1.55 Key: VFS-688 URL: https://issues.apache.org/jira/browse/VFS-688 Project: Commons VFS Issue Type: Improvement Reporter: Gary Gregory Assignee: Gary Gregory [SFTP] Update jsch from 0.1.54 to 0.1.55 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (VFS-625) FileObject method moveTo throws NullPointerException on ram
[
https://issues.apache.org/jira/browse/VFS-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed VFS-625.
Resolution: Cannot Reproduce
See new test
{{org.apache.commons.vfs2.provider.ram.test.CustomRamProviderTest.testMoveFile()}}.
> FileObject method moveTo throws NullPointerException on ram
>
>
> Key: VFS-625
> URL: https://issues.apache.org/jira/browse/VFS-625
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: Windows 10, Intellij IDEA 2016.6.2.5
>Reporter: Michele Scarpenti
>Priority: Blocker
>
> My simple code:
> {code:title=SimpleMethod.java|borderStyle=solid}
> private void moveFile(String source, String dest) throws
> FileSystemException {
> FileObject fileSource = fsManager.resolveFile("ram://virtual/" +
> source);
> FileObject fileDest = fsManager.resolveFile("ram://virtual/" + dest);
> if (fileSource.canRenameTo(fileDest))
> fileSource.moveTo(fileDest);
> }
> {code}
> fileSource exist and canRenameTo return true, destination does'nt exist, and
> parenth folder doesn't exist too, when i try to "moveTo" it throws
> NullPointerException:
> {quote}
> java.lang.NullPointerException
> at
> org.apache.commons.vfs2.provider.ram.RamFileSystem.save(RamFileSystem.java:172)
> at
> org.apache.commons.vfs2.provider.ram.RamFileSystem.rename(RamFileSystem.java:204)
> at
> org.apache.commons.vfs2.provider.ram.RamFileObject.doRename(RamFileObject.java:188)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1887)
> at
> biz.iconsulting.lago.working.wrappers.IrionInputFileHandler.moveFile(IrionInputFileHandler.java:149)
> at
> biz.iconsulting.lago.working.wrappers.IrionInputFileHandler.moveFilesToWorkingFolder(IrionInputFileHandler.java:110)
> at
> biz.iconsulting.lago.working.tests.wrappers.IrionInputFileHandlerTest.irionFileMoveTest(IrionInputFileHandlerTest.java:67)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:117)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:42)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:262)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:84)
> {quote}
> News:
> If I create the dest parent folder, the Exception is not thrown.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16751666#comment-16751666
]
Gary Gregory commented on VFS-398:
--
In svn trunk. Please verify and close.
{noformat}
commit -m "[VFS-398] FtpFileObject.getChildren() fails when a folder contains a
file with a colon in the name" -N (14 paths specified)
Sending
C:/svn/apache/commons-vfs2/commons-vfs2/src/main/java/org/apache/commons/vfs2/impl/DefaultFileSystemManager.java
Sending
C:/svn/apache/commons-vfs2/commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/AbstractFileObject.java
Sending
C:/svn/apache/commons-vfs2/commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/CompositeFileProvider.java
Sending
C:/svn/apache/commons-vfs2/commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/DefaultURLStreamHandler.java
Sending
C:/svn/apache/commons-vfs2/commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/HostFileNameParser.java
Sending
C:/svn/apache/commons-vfs2/commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/LayeredFileNameParser.java
Sending
C:/svn/apache/commons-vfs2/commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/UriParser.java
Sending
C:/svn/apache/commons-vfs2/commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/local/LocalFileNameParser.java
Sending
C:/svn/apache/commons-vfs2/commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/res/ResourceFileProvider.java
Sending
C:/svn/apache/commons-vfs2/commons-vfs2/src/main/java/org/apache/commons/vfs2/provider/temp/TemporaryFileProvider.java
Sending
C:/svn/apache/commons-vfs2/commons-vfs2/src/test/java/org/apache/commons/vfs2/provider/UriParserTestCase.java
Sending
C:/svn/apache/commons-vfs2/commons-vfs2/src/test/java/org/apache/commons/vfs2/provider/local/test/FileNameTests.java
SendingC:/svn/apache/commons-vfs2/pom.xml
SendingC:/svn/apache/commons-vfs2/src/changes/changes.xml
Transmitting file data ...
Unknown action received: commit finalizing
Committed revision 1852077.
{noformat}
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Assignee: Otto Fowler
>Priority: Blocker
> Attachments: VFS-398-gg-00.patch
>
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file;);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved VFS-398.
--
Resolution: Fixed
Fix Version/s: 2.3
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Assignee: Otto Fowler
>Priority: Blocker
> Fix For: 2.3
>
> Attachments: VFS-398-gg-00.patch
>
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file;);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name
[
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated VFS-398:
-
External issue URL: https://github.com/apache/commons-vfs/pull/29
External issue ID: 29
> FtpFileObject.getChildren() fails when a folder contains a file with a colon
> in the name
>
>
> Key: VFS-398
> URL: https://issues.apache.org/jira/browse/VFS-398
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: Connecting via FTP to a host running SunOS 5.10
>Reporter: Mark Leonard
>Assignee: Otto Fowler
>Priority: Blocker
> Attachments: VFS-398-gg-00.patch
>
>
> In line 767 of DefaultFileSystemManager.java the UriParser's extractScheme()
> method is called:
> String scheme = UriParser.extractScheme(buffer.toString());
> This code was added in revision 780730
> http://svn.apache.org/viewvc?view=revision=780730
> It is not clear to me why this change was made.
> For the FTP provider, buffer contains a plain file name (i.e. without a path
> and definitely not in URI form)
> A colon is a valid character for a file name.
> However a colon will be interpreted as a URI scheme name.
> This causes an exception when the resolved path is checked using
> AbstractFileName.checkName()
> Sample code:
> FileObject fo =
> VFS.getManager().resolveFile("ftp://user:pass@host/some/path/some.file;);
> fo.getParent().getChildren();
> If /some/path/ contains a child such as PREFIX:SUFFIX then an exception is
> thrown:
> Exception in thread "main" org.apache.commons.vfs2.FileSystemException:
> Invalid descendent file name "PREFIX:SUFFIX".
> at
> org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveName(DefaultFileSystemManager.java:791)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getChildren(AbstractFileObject.java:710)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.getChildren(FtpFileObject.java:420)
> Therefore calling code is unable to list the children of the specified folder.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (CRYPTO-143) Release a new version to maven central
Chris created CRYPTO-143: Summary: Release a new version to maven central Key: CRYPTO-143 URL: https://issues.apache.org/jira/browse/CRYPTO-143 Project: Commons Crypto Issue Type: Task Reporter: Chris I've been maintaining my own fork of commons-crypto for over 2 years, shortly after forking someone merged the change I wanted into the master branch. It would be nice to no longer have to maintain or build my fork, or even build the master branch myself. There have been a number of fixes and enhancements in the last 2 years... Could we get a 1.01 release to maven central? Thanks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CRYPTO-143) Release a new version to maven central
[ https://issues.apache.org/jira/browse/CRYPTO-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris updated CRYPTO-143: - Description: I've been maintaining my own fork of commons-crypto for over 2 years, shortly after forking someone merged the change I wanted into the master branch. It would be nice to no longer have to maintain or build my fork, or even build the master branch myself. There have been a number of fixes and enhancements in the last 2 years... Could we get a 1.0.1 release to maven central? Thanks. was: I've been maintaining my own fork of commons-crypto for over 2 years, shortly after forking someone merged the change I wanted into the master branch. It would be nice to no longer have to maintain or build my fork, or even build the master branch myself. There have been a number of fixes and enhancements in the last 2 years... Could we get a 1.01 release to maven central? Thanks. > Release a new version to maven central > -- > > Key: CRYPTO-143 > URL: https://issues.apache.org/jira/browse/CRYPTO-143 > Project: Commons Crypto > Issue Type: Task >Reporter: Chris >Priority: Major > > I've been maintaining my own fork of commons-crypto for over 2 years, shortly > after forking someone merged the change I wanted into the master branch. > > It would be nice to no longer have to maintain or build my fork, or even > build the master branch myself. There have been a number of fixes and > enhancements in the last 2 years... Could we get a 1.0.1 release to maven > central? > > Thanks. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (NUMBERS-93) PlaneAngle normalize() Upper Bound is Exclusive
[
https://issues.apache.org/jira/browse/NUMBERS-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles resolved NUMBERS-93.
---
Resolution: Fixed
Fix Version/s: 1.0
Commit 463183281c06a2398a70a00651fbb5feab5b0413 ("master" branch).
> PlaneAngle normalize() Upper Bound is Exclusive
> ---
>
> Key: NUMBERS-93
> URL: https://issues.apache.org/jira/browse/NUMBERS-93
> Project: Commons Numbers
> Issue Type: Bug
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 1.0
>
>
> The {{PlaneAngle#normalize()}} documentation states that it normalizes an
> angle to be between -0.5 turns and +0.5 turns inclusive of the given center
> angle. However, the upper bound is actually exclusive. The documentation
> should be updated to reflect this and unit tests added.
> Pull request: https://github.com/apache/commons-numbers/pull/29
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
