[jira] [Commented] (CODEC-280) Base32/64 to allow optional strict/lenient decoding
[
https://issues.apache.org/jira/browse/CODEC-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17101134#comment-17101134
]
Jason commented on CODEC-280:
-
Could you please add an option for strict/lenient encoding for
Base64InputStream and Base64OutputStream?
> Base32/64 to allow optional strict/lenient decoding
> ---
>
> Key: CODEC-280
> URL: https://issues.apache.org/jira/browse/CODEC-280
> Project: Commons Codec
> Issue Type: Improvement
>Affects Versions: 1.14
>Reporter: Alex Herbert
>Assignee: Alex Herbert
>Priority: Minor
> Fix For: 1.15
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Base32 decodes blocks of 8 characters.
> Base64 decodes blocks of 4 characters.
> At the end of decoding some extra characters may be left. They are decoded
> using the appropriate bits. The bits that do not sum to form a byte (i.e.
> less than 8 bits) are discarded.
> Currently if there are more than 8 bits left then the available bytes are
> extracted and the left over bits are validated to check they are zeros. If
> they are not zeros then an exception is raised. This functionality was added
> to ensure that a byte array that is decoded will be re-encoded to the exact
> same byte array (ignoring input padding).
> There are two issues:
> # If the leftover bits are less than 8 then no attempt can be made to obtain
> the last bytes. However an exception is not raised indicating that the
> encoding was invalid (no left-over bits should be unaccounted for).
> # This raising of exceptions for leftover bits is causing reports from users
> that codec is not working as it used to. This is true but only because the
> user has some badly encoded bytes they want to decode. Since other libraries
> allow this then it seems that two options for decoding are required.
> I suggest fixing the encoding so that it operates in two modes: strict and
> lenient.
> * Strict will throw an exception whenever there are unaccounted for bits.
> * Lenient will just discard the extra bits that cannot be used.
> Lenient is the default for backward compatibility restoring functionality of
> the class to versions prior to 1.13.
> Strict is enabled using a method:
> {code:java}
> Base64 codec = new Base64();
> byte[] bytes = new byte{ 'E' };
> Assertions.assertArrayEquals(new byte[0] () -> codec.decode(bytes));
> codec.setStrictDecoding(true);
> Assertions.assertThrows(IllegalArgumentException.class, () -> codec.decode());
> {code}
> Using strict encoding should ensure that a round trip returns the same bytes:
> {code:java}
> byte[] bytes = ...; // Some valid encoding with no padding characters
> Base64 codec = new Base64();
> codec.setStrictDecoding(true);
> Assertions.assertArrayEquals(bytes, codec.encode(codec.decode(bytes)));
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (LANG-861) RBD (ceph) setup
[ https://issues.apache.org/jira/browse/LANG-861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jason closed LANG-861. -- . > RBD (ceph) setup > > > Key: LANG-861 > URL: https://issues.apache.org/jira/browse/LANG-861 > Project: Commons Lang > Issue Type: Bug > Components: General >Affects Versions: 4.0 > Environment: Ubuntu 12.4 >Reporter: jason > Labels: newbie > > help setting up RBD, I have a running Ceph Cluster. but cannot add rbd, i > thing libvirt version is wrong (current 0.9.8) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (LANG-861) RBD (ceph) setup
[ https://issues.apache.org/jira/browse/LANG-861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jason reopened LANG-861: > RBD (ceph) setup > > > Key: LANG-861 > URL: https://issues.apache.org/jira/browse/LANG-861 > Project: Commons Lang > Issue Type: Bug > Components: General >Affects Versions: 4.0 > Environment: Ubuntu 12.4 >Reporter: jason > Labels: newbie > > help setting up RBD, I have a running Ceph Cluster. but cannot add rbd, i > thing libvirt version is wrong (current 0.9.8) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-861) RBD (ceph) setup
[ https://issues.apache.org/jira/browse/LANG-861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508244#comment-13508244 ] jason commented on LANG-861: Cloudstack 4.0 said it supports RBD (ceph Storage). I have a running cloudstack 4.0 but i cannot add RBD storage. On google this i found the RBD needs libvirt 0.10.0 with RBD enabled, cloudstack 4.0 is currently running libvirt 0.9.8. I have have tied many ways to install libvirt 0.10.0 and 1.0.0 but this stops cloud-agent from running. If cloudstack supports RBD why doesnt it install the correct libvirt version when install the cloud-agent. > RBD (ceph) setup > > > Key: LANG-861 > URL: https://issues.apache.org/jira/browse/LANG-861 > Project: Commons Lang > Issue Type: Bug > Components: General >Affects Versions: 4.0 > Environment: Ubuntu 12.4 >Reporter: jason > Labels: newbie > > help setting up RBD, I have a running Ceph Cluster. but cannot add rbd, i > thing libvirt version is wrong (current 0.9.8) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-861) RBD (ceph) setup
[ https://issues.apache.org/jira/browse/LANG-861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508076#comment-13508076 ] jason commented on LANG-861: you have lost me now ! > RBD (ceph) setup > > > Key: LANG-861 > URL: https://issues.apache.org/jira/browse/LANG-861 > Project: Commons Lang > Issue Type: Bug > Components: General >Affects Versions: 4.0 > Environment: Ubuntu 12.4 >Reporter: jason > Labels: newbie > > help setting up RBD, I have a running Ceph Cluster. but cannot add rbd, i > thing libvirt version is wrong (current 0.9.8) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LANG-861) RBD (ceph) setup
jason created LANG-861: -- Summary: RBD (ceph) setup Key: LANG-861 URL: https://issues.apache.org/jira/browse/LANG-861 Project: Commons Lang Issue Type: Bug Components: General Affects Versions: 4.0 Environment: Ubuntu 12.4 Reporter: jason help setting up RBD, I have a running Ceph Cluster. but cannot add rbd, i thing libvirt version is wrong (current 0.9.8) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VFS-437) [FTP] Program crashes when StackOverFlow Exception happens from pulling a softlinked directory that link to the directory that has the same name one level above
[
https://issues.apache.org/jira/browse/VFS-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13459111#comment-13459111
]
Jason commented on VFS-437:
---
On the remote ftp server (I used CentOs distribution)
1. Create a Voll directory under file system so the path is "/Vol"
2. Create a Vol1 directory under the user's home directory so the path is
"/user/Vol1"
3. Make the Vol1 under step two soft link to the Vol1 in step one, so "ls -al"
would show the following
"lrwxrwxrwx 1 root root 5 Oct 5 2007 Vol1 -> /Vol1"
I used the test case you've written, I can actually reproduce the exception
also. The only difference is my ftp server is not a localhost.
@Test
public void test() throws FileSystemException
{
FileSystemOptions opts = new FileSystemOptions();
FtpFileSystemConfigBuilder.getInstance().setUserDirIsRoot(opts, true);
final FileObject file =
VFS.getManager().resolveFile("ftp://test1:test1@remoteIp/Vol1";, opts);
System.out.println(file);
for (FileObject child : file.getChildren())
{
System.out.println(child);
for (FileObject child2 : child.getChildren())
{
System.out.println(child2);
}
}
}
I reproduce this issue with scenario of Windows 7 and Linux(Centos) trying to
access a Linux ftp remote server.
> [FTP] Program crashes when StackOverFlow Exception happens from pulling a
> softlinked directory that link to the directory that has the same name one
> level above
> -
>
> Key: VFS-437
> URL: https://issues.apache.org/jira/browse/VFS-437
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: java version "1.7.0_02"
> Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode)
> Linux version 2.6.18-238.el5 (mockbu...@builder10.centos.org) (gcc version
> 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Thu Jan 13 15:51:15 EST 2011
>Reporter: Jason
>Priority: Blocker
> Fix For: 2.1
>
>
> With the setting below, StackOverFlow exceptions occur and server crashes
> set the builder.setUserDirlsRoot (opt, true)
> Attept to pull with:
> ftp://root:password@ip:/Vol1
> Vol directory has the following info
> lrwxrwxrwx 1 root root5 Oct 5 2007 Vol1 -> /Vol1
> When it tries to look for the parent of the Vol1, it goes back to the same
> Vol1, which causes a infinite loop that eventually creates stackoverflow
> exception.
> The problem is inside the doGetType() method in FtpFileObject
> @Override
> protected FileType doGetType()
> throws Exception
> {
> // VFS-210
> synchronized (getFileSystem())
> {
> if (this.fileInfo == null)
> {
> getInfo(false);
> }
> if (this.fileInfo == UNKNOWN)
> {
> return FileType.IMAGINARY;
> }
> else if (this.fileInfo.isDirectory())
> {
> return FileType.FOLDER;
> }
> else if (this.fileInfo.isFile())
> {
> return FileType.FILE;
> }
> else if (this.fileInfo.isSymbolicLink())
> {
> return getLinkDestination().getType();
> }
> }
> throw new FileSystemException("vfs.provider.ftp/get-type.error",
> getName());
> }
> It will keep hitting the "else if (this.fileinfo.isSymbolicLink())" condition
> and the fileinfo displayed is always the Vol1 under root directory.
> Exception is shown below
> java.lang.StackOverflowError
> at org.apache.commons.net.ftp.FTPFile.isDirectory(FTPFile.java:116)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:334)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
>
[jira] [Commented] (VFS-437) [FTP] Program crashes when StackOverFlow Exception happens from pulling a softlinked directory that link to the directory that has the same name one level above
[
https://issues.apache.org/jira/browse/VFS-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13458342#comment-13458342
]
Jason commented on VFS-437:
---
The ftp server should be linux system
> [FTP] Program crashes when StackOverFlow Exception happens from pulling a
> softlinked directory that link to the directory that has the same name one
> level above
> -
>
> Key: VFS-437
> URL: https://issues.apache.org/jira/browse/VFS-437
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: java version "1.7.0_02"
> Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode)
> Linux version 2.6.18-238.el5 (mockbu...@builder10.centos.org) (gcc version
> 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Thu Jan 13 15:51:15 EST 2011
>Reporter: Jason
>Priority: Blocker
> Fix For: 2.1
>
>
> With the setting below, StackOverFlow exceptions occur and server crashes
> set the builder.setUserDirlsRoot (opt, true)
> Attept to pull with:
> ftp://root:password@ip:/Vol1
> Vol directory has the following info
> lrwxrwxrwx 1 root root5 Oct 5 2007 Vol1 -> /Vol1
> When it tries to look for the parent of the Vol1, it goes back to the same
> Vol1, which causes a infinite loop that eventually creates stackoverflow
> exception.
> The problem is inside the doGetType() method in FtpFileObject
> @Override
> protected FileType doGetType()
> throws Exception
> {
> // VFS-210
> synchronized (getFileSystem())
> {
> if (this.fileInfo == null)
> {
> getInfo(false);
> }
> if (this.fileInfo == UNKNOWN)
> {
> return FileType.IMAGINARY;
> }
> else if (this.fileInfo.isDirectory())
> {
> return FileType.FOLDER;
> }
> else if (this.fileInfo.isFile())
> {
> return FileType.FILE;
> }
> else if (this.fileInfo.isSymbolicLink())
> {
> return getLinkDestination().getType();
> }
> }
> throw new FileSystemException("vfs.provider.ftp/get-type.error",
> getName());
> }
> It will keep hitting the "else if (this.fileinfo.isSymbolicLink())" condition
> and the fileinfo displayed is always the Vol1 under root directory.
> Exception is shown below
> java.lang.StackOverflowError
> at org.apache.commons.net.ftp.FTPFile.isDirectory(FTPFile.java:116)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:334)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(Ftp
[jira] [Updated] (VFS-437) Program crashes when StackOverFlow Exception happens from pulling a softlinked directory that link to the directory that has the same name one level above
[
https://issues.apache.org/jira/browse/VFS-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason updated VFS-437:
--
Description:
With the setting below, StackOverFlow exceptions occur and server crashes
set the builder.setUserDirlsRoot (opt, true)
Attept to pull with:
ftp://root:password@ip:/Vol1
Vol directory has the following info
lrwxrwxrwx 1 root root5 Oct 5 2007 Vol1 -> /Vol1
When it tries to look for the parent of the Vol1, it goes back to the same
Vol1, which causes a infinite loop that eventually creates stackoverflow
exception.
The problem is inside the doGetType() method in FtpFileObject
@Override
protected FileType doGetType()
throws Exception
{
// VFS-210
synchronized (getFileSystem())
{
if (this.fileInfo == null)
{
getInfo(false);
}
if (this.fileInfo == UNKNOWN)
{
return FileType.IMAGINARY;
}
else if (this.fileInfo.isDirectory())
{
return FileType.FOLDER;
}
else if (this.fileInfo.isFile())
{
return FileType.FILE;
}
else if (this.fileInfo.isSymbolicLink())
{
return getLinkDestination().getType();
}
}
throw new FileSystemException("vfs.provider.ftp/get-type.error",
getName());
}
It will keep hitting the "else if (this.fileinfo.isSymbolicLink())" condition
and the fileinfo displayed is always the Vol1 under root directory.
Exception is shown below
java.lang.StackOverflowError
at org.apache.commons.net.ftp.FTPFile.isDirectory(FTPFile.java:116)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:334)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
at
org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344)
was:
With the setting below, StackOverFlow exceptions occur and server crashes
set the builder.setUserDirlsRoot (opt, true)
Attept to pull with:
ftp://root:password@ip:/Vol1
Vol directory has the following info
lrwxrwxrwx 1 root root5 Oct 5 2007 Vol1 -> /Vol1
When it tries to look for the parent of the Vol1, it goes back to the same
Vol1, which causes a infinite loop that eventually creates stackoverflow
exception.
Exception is shown below
java.lang.StackOverflowError
at org.apache.commons.net.ftp.FTPFile.isDirectory(FTPFile.java:116)
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:334)
at
org.apache.commons.vfs2.provider.AbstractFileObject
[jira] [Commented] (VFS-436) VFS doesn't pull correctly with FTP protocol when pulling a directory that's symbolic linked
[
https://issues.apache.org/jira/browse/VFS-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13458264#comment-13458264
]
Jason commented on VFS-436:
---
Yes, ran all the general test cases and the FtpProviderTestCase. Everything
passed
> VFS doesn't pull correctly with FTP protocol when pulling a directory that's
> symbolic linked
>
>
> Key: VFS-436
> URL: https://issues.apache.org/jira/browse/VFS-436
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: java version "1.7.0_02"
> Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode)
> Linux version 2.6.18-238.el5 (mockbu...@builder10.centos.org) (gcc version
> 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Thu Jan 13 15:51:15 EST 2011
>Reporter: Jason
>Priority: Blocker
>
> With the setting below, VFS doesn't pull the ftp directory successfully.
> Attempt to pull with
> ftp://root:password@ip:/softLinkTest/yes
> yes directory has the following info
> lrwxrwxrwx 1 root root 10 Sep 13 13:35 yes -> /root/tmp/
> I set builder.setUserDirIsRoot( opts, true ). It works fine when it sets it
> to false.
> When it runs through the getType() method after knowing it is a symbolic
> link, it tries to find the real directory's children but will return an empty
> array even though there's files listed under.
> I debugged through the source code, the reason is caused by the fix to 307 in
> FTPClientWrapper line 134
> // VFS-307: no check if we can simply list the files, this might fail
> if there are spaces in the path
> files = getFtpClient().listFiles(relPath);
> if (FTPReply.isPositiveCompletion(getFtpClient().getReplyCode()))
> {
> return files;
> }
> If those lines are removed, it will work successfully.
> Recommend to remove those lines
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (VFS-437) Program crashes when StackOverFlow Exception happens from pulling a softlinked directory that link to the directory that has the same name one level above
[ https://issues.apache.org/jira/browse/VFS-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason updated VFS-437: -- Description: With the setting below, StackOverFlow exceptions occur and server crashes set the builder.setUserDirlsRoot (opt, true) Attept to pull with: ftp://root:password@ip:/Vol1 Vol directory has the following info lrwxrwxrwx 1 root root5 Oct 5 2007 Vol1 -> /Vol1 When it tries to look for the parent of the Vol1, it goes back to the same Vol1, which causes a infinite loop that eventually creates stackoverflow exception. Exception is shown below java.lang.StackOverflowError at org.apache.commons.net.ftp.FTPFile.isDirectory(FTPFile.java:116) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:334) at org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) at org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) at org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) at org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) at org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) at org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) at org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) at org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) at org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) at org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) at org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) at org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) was: With the setting below, StackOverFlow exceptions occur and server crashes Attept to pull with: ftp://root:password@ip:/Vol1 Vol directory has the following info lrwxrwxrwx 1 root root5 Oct 5 2007 Vol1 -> /Vol1 set the builder.setUserDirlsRoot (opt, true) When it tries to look for the parent of the Vol1, it goes back to the same Vol1, which causes a infinite loop that eventually creates stackoverflow exception. Exception is shown below java.lang.StackOverflowError at org.apache.commons.net.ftp.FTPFile.isDirectory(FTPFile.java:116) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:334) at org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) at org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) at org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) at org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) at org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) at org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) at o
[jira] [Created] (VFS-437) Program crashes when StackOverFlow Exception happens from pulling a softlinked directory that link to the directory that has the same name one level above
Jason created VFS-437: - Summary: Program crashes when StackOverFlow Exception happens from pulling a softlinked directory that link to the directory that has the same name one level above Key: VFS-437 URL: https://issues.apache.org/jira/browse/VFS-437 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Environment: java version "1.7.0_02" Java(TM) SE Runtime Environment (build 1.7.0_02-b13) Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode) Linux version 2.6.18-238.el5 (mockbu...@builder10.centos.org) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Thu Jan 13 15:51:15 EST 2011 Reporter: Jason Priority: Blocker Fix For: 2.1 With the setting below, StackOverFlow exceptions occur and server crashes Attept to pull with: ftp://root:password@ip:/Vol1 Vol directory has the following info lrwxrwxrwx 1 root root5 Oct 5 2007 Vol1 -> /Vol1 set the builder.setUserDirlsRoot (opt, true) When it tries to look for the parent of the Vol1, it goes back to the same Vol1, which causes a infinite loop that eventually creates stackoverflow exception. Exception is shown below java.lang.StackOverflowError at org.apache.commons.net.ftp.FTPFile.isDirectory(FTPFile.java:116) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:334) at org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) at org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) at org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) at org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) at org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) at org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) at org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) at org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) at org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) at org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) at org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) at org.apache.commons.vfs2.provider.AbstractFileObject.getType(AbstractFileObject.java:496) at org.apache.commons.vfs2.provider.ftp.FtpFileObject.doGetType(FtpFileObject.java:344) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (VFS-436) VFS doesn't pull correctly with FTP protocol when pulling a directory that's symbolic linked
[
https://issues.apache.org/jira/browse/VFS-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason updated VFS-436:
--
Description:
With the setting below, VFS doesn't pull the ftp directory successfully.
Attempt to pull with
ftp://root:password@ip:/softLinkTest/yes
yes directory has the following info
lrwxrwxrwx 1 root root 10 Sep 13 13:35 yes -> /root/tmp/
I set builder.setUserDirIsRoot( opts, true ). It works fine when it sets it to
false.
When it runs through the getType() method after knowing it is a symbolic link,
it tries to find the real directory's children but will return an empty array
even though there's files listed under.
I debugged through the source code, the reason is caused by the fix to 307 in
FTPClientWrapper line 134
// VFS-307: no check if we can simply list the files, this might fail
if there are spaces in the path
files = getFtpClient().listFiles(relPath);
if (FTPReply.isPositiveCompletion(getFtpClient().getReplyCode()))
{
return files;
}
If those lines are removed, it will work successfully.
Recommend to remove those lines
was:
With the setting below, VFS doesn't pull the ftp directory successfully.
Attempt to pull with
ftp://root:password@ip:/softLinkTest/yes
yes directory has the following info
lrwxrwxrwx 1 root root 10 Sep 13 13:35 yes -> /root/tmp/
When it runs through the getType() method after knowing it is a symbolic link,
it tries to find the real directory's children but will return an empty array
even though there's files listed under.
I debugged through the source code, the reason is caused by the fix to 307 in
FTPClientWrapper line 134
// VFS-307: no check if we can simply list the files, this might fail
if there are spaces in the path
files = getFtpClient().listFiles(relPath);
if (FTPReply.isPositiveCompletion(getFtpClient().getReplyCode()))
{
return files;
}
If those lines are removed, it will work successfully.
The issue occurs when I set builder.setUserDirIsRoot( opts, true ). It works
fine when it sets it to false.
Recommend to remove those lines
> VFS doesn't pull correctly with FTP protocol when pulling a directory that's
> symbolic linked
>
>
> Key: VFS-436
> URL: https://issues.apache.org/jira/browse/VFS-436
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: java version "1.7.0_02"
> Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode)
> Linux version 2.6.18-238.el5 (mockbu...@builder10.centos.org) (gcc version
> 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Thu Jan 13 15:51:15 EST 2011
>Reporter: Jason
>Priority: Blocker
>
> With the setting below, VFS doesn't pull the ftp directory successfully.
> Attempt to pull with
> ftp://root:password@ip:/softLinkTest/yes
> yes directory has the following info
> lrwxrwxrwx 1 root root 10 Sep 13 13:35 yes -> /root/tmp/
> I set builder.setUserDirIsRoot( opts, true ). It works fine when it sets it
> to false.
> When it runs through the getType() method after knowing it is a symbolic
> link, it tries to find the real directory's children but will return an empty
> array even though there's files listed under.
> I debugged through the source code, the reason is caused by the fix to 307 in
> FTPClientWrapper line 134
> // VFS-307: no check if we can simply list the files, this might fail
> if there are spaces in the path
> files = getFtpClient().listFiles(relPath);
> if (FTPReply.isPositiveCompletion(getFtpClient().getReplyCode()))
> {
> return files;
> }
> If those lines are removed, it will work successfully.
> Recommend to remove those lines
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (VFS-436) VFS doesn't pull correctly with FTP protocol when pulling a directory that's symbolic linked
[
https://issues.apache.org/jira/browse/VFS-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason updated VFS-436:
--
Description:
With the setting below, VFS doesn't pull the ftp directory successfully.
Attempt to pull with
ftp://root:password@ip:/softLinkTest/yes
yes directory has the following info
lrwxrwxrwx 1 root root 10 Sep 13 13:35 yes -> /root/tmp/
When it runs through the getType() method after knowing it is a symbolic link,
it tries to find the real directory's children but will return an empty array
even though there's files listed under.
I debugged through the source code, the reason is caused by the fix to 307 in
FTPClientWrapper line 134
// VFS-307: no check if we can simply list the files, this might fail
if there are spaces in the path
files = getFtpClient().listFiles(relPath);
if (FTPReply.isPositiveCompletion(getFtpClient().getReplyCode()))
{
return files;
}
If those lines are removed, it will work successfully.
The issue occurs when I set builder.setUserDirIsRoot( opts, true ). It works
fine when it sets it to false.
Recommend to remove those lines
was:
With the setting below, VFS doesn't pull the ftp directory successfully.
Attempt to pull with
ftp://root:password@ip:/softLinkTest/yes
yes directory has the following info
lrwxrwxrwx 1 root root 10 Sep 13 13:35 yes -> /root/tmp/
When it runs through the getType() method after knowing it is a symbolic link,
it tries to find the real directory's children but will return an empty array
even though there's files listed under.
I debugged through the source code, the reason is caused by the fix to 307 in
FTPClientWrapper line 134
// VFS-307: no check if we can simply list the files, this might fail
if there are spaces in the path
files = getFtpClient().listFiles(relPath);
if (FTPReply.isPositiveCompletion(getFtpClient().getReplyCode()))
{
return files;
}
If those lines are removed, it will work successfully.
Recommend to remove those lines
> VFS doesn't pull correctly with FTP protocol when pulling a directory that's
> symbolic linked
>
>
> Key: VFS-436
> URL: https://issues.apache.org/jira/browse/VFS-436
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: java version "1.7.0_02"
> Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode)
> Linux version 2.6.18-238.el5 (mockbu...@builder10.centos.org) (gcc version
> 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Thu Jan 13 15:51:15 EST 2011
>Reporter: Jason
>Priority: Blocker
>
> With the setting below, VFS doesn't pull the ftp directory successfully.
> Attempt to pull with
> ftp://root:password@ip:/softLinkTest/yes
> yes directory has the following info
> lrwxrwxrwx 1 root root 10 Sep 13 13:35 yes -> /root/tmp/
> When it runs through the getType() method after knowing it is a symbolic
> link, it tries to find the real directory's children but will return an empty
> array even though there's files listed under.
> I debugged through the source code, the reason is caused by the fix to 307 in
> FTPClientWrapper line 134
> // VFS-307: no check if we can simply list the files, this might fail
> if there are spaces in the path
> files = getFtpClient().listFiles(relPath);
> if (FTPReply.isPositiveCompletion(getFtpClient().getReplyCode()))
> {
> return files;
> }
> If those lines are removed, it will work successfully.
> The issue occurs when I set builder.setUserDirIsRoot( opts, true ). It works
> fine when it sets it to false.
> Recommend to remove those lines
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (VFS-436) VFS doesn't pull correctly with FTP protocol when pulling a directory that's symbolic linked
[
https://issues.apache.org/jira/browse/VFS-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason updated VFS-436:
--
Priority: Blocker (was: Critical)
> VFS doesn't pull correctly with FTP protocol when pulling a directory that's
> symbolic linked
>
>
> Key: VFS-436
> URL: https://issues.apache.org/jira/browse/VFS-436
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.0
> Environment: java version "1.7.0_02"
> Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode)
> Linux version 2.6.18-238.el5 (mockbu...@builder10.centos.org) (gcc version
> 4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Thu Jan 13 15:51:15 EST 2011
>Reporter: Jason
>Priority: Blocker
>
> With the setting below, VFS doesn't pull the ftp directory successfully.
> Attempt to pull with
> ftp://root:password@ip:/softLinkTest/yes
> yes directory has the following info
> lrwxrwxrwx 1 root root 10 Sep 13 13:35 yes -> /root/tmp/
> When it runs through the getType() method after knowing it is a symbolic
> link, it tries to find the real directory's children but will return an empty
> array even though there's files listed under.
> I debugged through the source code, the reason is caused by the fix to 307 in
> FTPClientWrapper line 134
> // VFS-307: no check if we can simply list the files, this might fail
> if there are spaces in the path
> files = getFtpClient().listFiles(relPath);
> if (FTPReply.isPositiveCompletion(getFtpClient().getReplyCode()))
> {
> return files;
> }
> If those lines are removed, it will work successfully.
> Recommend to remove those lines
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (VFS-436) VFS doesn't pull correctly with FTP protocol when pulling a directory that's symbolic linked
Jason created VFS-436:
-
Summary: VFS doesn't pull correctly with FTP protocol when pulling
a directory that's symbolic linked
Key: VFS-436
URL: https://issues.apache.org/jira/browse/VFS-436
Project: Commons VFS
Issue Type: Bug
Affects Versions: 2.0
Environment: java version "1.7.0_02"
Java(TM) SE Runtime Environment (build 1.7.0_02-b13)
Java HotSpot(TM) 64-Bit Server VM (build 22.0-b10, mixed mode)
Linux version 2.6.18-238.el5 (mockbu...@builder10.centos.org) (gcc version
4.1.2 20080704 (Red Hat 4.1.2-48)) #1 SMP Thu Jan 13 15:51:15 EST 2011
Reporter: Jason
Priority: Critical
With the setting below, VFS doesn't pull the ftp directory successfully.
Attempt to pull with
ftp://root:password@ip:/softLinkTest/yes
yes directory has the following info
lrwxrwxrwx 1 root root 10 Sep 13 13:35 yes -> /root/tmp/
When it runs through the getType() method after knowing it is a symbolic link,
it tries to find the real directory's children but will return an empty array
even though there's files listed under.
I debugged through the source code, the reason is caused by the fix to 307 in
FTPClientWrapper line 134
// VFS-307: no check if we can simply list the files, this might fail
if there are spaces in the path
files = getFtpClient().listFiles(relPath);
if (FTPReply.isPositiveCompletion(getFtpClient().getReplyCode()))
{
return files;
}
If those lines are removed, it will work successfully.
Recommend to remove those lines
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (VFS-423) FileSystemException for invalid URI path doesn't hide the password
[ https://issues.apache.org/jira/browse/VFS-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason resolved VFS-423. --- Resolution: Not A Problem False alarm. Reconstructed url with user name and password whereas I should have just used FileSystemOptions for it. > FileSystemException for invalid URI path doesn't hide the password > -- > > Key: VFS-423 > URL: https://issues.apache.org/jira/browse/VFS-423 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Jason >Priority: Critical > > While trying to access a remote server through FTP Connection, with an > invalid password, it will throw a FileSystemException for invalid URI path > and show the complete URI path without the password being encrypted. > Code: > FileSystemManager fsManager = VFS.getManager(); > rfConfig.setPassword( "ABCDEFG/ABCDEFG" ); > FileSystemOptions opts = factory.getFileSystemOptions( rfConfig.getUrl(), > rfConfig.getUserName(), rfConfig.getPassword() ); > > FileObject sourceDir = fsManager.resolveFile( completeUrl( rfConfig ), opts > ); > Exception shown in Console: > org.apache.commons.vfs2.FileSystemException: Invalid absolute URI > "ftp://root:ABCDEFG/ABCDEFG@10.20.25.11/Vol1/a.txt";. > at > org.apache.commons.vfs2.provider.AbstractOriginatingFileProvider.findFile(AbstractOriginatingFileProvider.java:61) > at > org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:693) > at > org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:621) > Let me know if more details is needed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (VFS-423) FileSystemException for invalid URI path doesn't hide the password
Jason created VFS-423: - Summary: FileSystemException for invalid URI path doesn't hide the password Key: VFS-423 URL: https://issues.apache.org/jira/browse/VFS-423 Project: Commons VFS Issue Type: Bug Affects Versions: 2.0 Reporter: Jason Priority: Critical While trying to access a remote server through FTP Connection, with an invalid password, it will throw a FileSystemException for invalid URI path and show the complete URI path without the password being encrypted. Code: FileSystemManager fsManager = VFS.getManager(); rfConfig.setPassword( "ABCDEFG/ABCDEFG" ); FileSystemOptions opts = factory.getFileSystemOptions( rfConfig.getUrl(), rfConfig.getUserName(), rfConfig.getPassword() ); FileObject sourceDir = fsManager.resolveFile( completeUrl( rfConfig ), opts ); Exception shown in Console: org.apache.commons.vfs2.FileSystemException: Invalid absolute URI "ftp://root:ABCDEFG/ABCDEFG@10.20.25.11/Vol1/a.txt";. at org.apache.commons.vfs2.provider.AbstractOriginatingFileProvider.findFile(AbstractOriginatingFileProvider.java:61) at org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:693) at org.apache.commons.vfs2.impl.DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:621) Let me know if more details is needed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MATH-212) Provide a way to copy all instances of StorelessUnivariateStatistic (e.g. Mean, Variance, Max, Kurtoise, etc), perhaps via a copy-constructor
Provide a way to copy all instances of StorelessUnivariateStatistic (e.g. Mean,
Variance, Max, Kurtoise, etc), perhaps via a copy-constructor
-
Key: MATH-212
URL: https://issues.apache.org/jira/browse/MATH-212
Project: Commons Math
Issue Type: Improvement
Environment: N/A
Reporter: jason
Priority: Minor
Attachments: copy_constructor.patch
Below is the conversation related to this topic that was posted to the Commons
Users group. As soon as I figure out how, I'll attach my patch that adds copy
constructors to all intended classes exception GeometricMean and
SummaryStatistic, which both allow the user to specify arbitrary
implementations and thus cannot be copied. See below for details.
Phil,
Well, that was easy in some cases and I'm not sure how it went in others and
could use help. I had issue with creating a copy constructor for GeometricMean
and SummaryStatistic. Both of these classes allow the user to, via the API, set
a StorelessUnivariateStatistic as the implementation. For instance take the
following method in Geometric mean:
public void setSumLogImpl(
StorelessUnivariateStatistic sumLogImpl) {
checkEmpty();
this.sumOfLogs = sumLogImpl;
}
There is no way to create a true deep copy of sumLogImpl, as we only know it to
be an instance of StorelessUnivariateStatistic. I think the solution is to
allow the copy constructors for the below classes into the baseline, but not
provide a copy constructor for GeometricMean or SummaryStatistic unless you
want to (1) deprecate the implementation business or (2) create a abstract copy
method in StorelessUnivariateStatistic forcing all implementations to be
'copyable'.
The following classes were able to be given copy constructors without issue:
Max
SumOfSquares
Sum
Product
FirstMoment
SecondMoment
ThirdMoment
FourthMoment
Median
Min
SumOfLogs
Percentile
Skewness
Variance
Mean
Kurtois
StandardDeviation
Phil Steitz wrote:
> Jason C. HandUber wrote:
>> Hello,
>>
>> I'm writing an evolutionary algorithm in which each individual contains
>> StandardDeviations and Means. From time to time I need a deep copy / clone
>> of an individual. Thus far I've actually had to keep a list of all data and,
>> when cloning, generate a new statistic and increment it with all that data.
>> Now that I'm moving to production level, turns out I'm running out of memory
>> (no huge surprise). I'm going to extend Mean, Variance, StandardDeviation,
>> FirstMoment, and SecondMoment for my application to provide a copy
>> constructor (which, according to Item 10, page 51 of Bloch's effective java,
>> beats out clone, and I buy that) for each. Anyway, I think that addition
>> would be easy and general enough to introduce into the trunk. Any thoughts?
> +1 on this enhancement, also for SummaryStatistics, implemented as you
> describe.
>
> Please follow instructions here
> to create a patch against
> either trunk or the 2.0 development branch (/branches/MATH_2_0) and attach it
> to a JIRA ticket.
>
> Thanks!
>
> Phil
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MATH-212) Provide a way to copy all instances of StorelessUnivariateStatistic (e.g. Mean, Variance, Max, Kurtoise, etc), perhaps via a copy-constructor
[
https://issues.apache.org/jira/browse/MATH-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jason updated MATH-212:
---
Attachment: copy_constructor.patch
Adds copy constructors to:
Max
SumOfSquares
Sum
Product
FirstMoment
SecondMoment
ThirdMoment
FourthMoment
Median
Min
SumOfLogs
Percentile
Skewness
Variance
Mean
Kurtois
StandardDeviation
> Provide a way to copy all instances of StorelessUnivariateStatistic (e.g.
> Mean, Variance, Max, Kurtoise, etc), perhaps via a copy-constructor
> -
>
> Key: MATH-212
> URL: https://issues.apache.org/jira/browse/MATH-212
> Project: Commons Math
> Issue Type: Improvement
> Environment: N/A
>Reporter: jason
>Priority: Minor
> Attachments: copy_constructor.patch
>
>
> Below is the conversation related to this topic that was posted to the
> Commons Users group. As soon as I figure out how, I'll attach my patch that
> adds copy constructors to all intended classes exception GeometricMean and
> SummaryStatistic, which both allow the user to specify arbitrary
> implementations and thus cannot be copied. See below for details.
> Phil,
> Well, that was easy in some cases and I'm not sure how it went in others and
> could use help. I had issue with creating a copy constructor for
> GeometricMean and SummaryStatistic. Both of these classes allow the user to,
> via the API, set a StorelessUnivariateStatistic as the implementation. For
> instance take the following method in Geometric mean:
>public void setSumLogImpl(
>StorelessUnivariateStatistic sumLogImpl) {
>checkEmpty();
>this.sumOfLogs = sumLogImpl;
>}
> There is no way to create a true deep copy of sumLogImpl, as we only know it
> to be an instance of StorelessUnivariateStatistic. I think the solution is to
> allow the copy constructors for the below classes into the baseline, but not
> provide a copy constructor for GeometricMean or SummaryStatistic unless you
> want to (1) deprecate the implementation business or (2) create a abstract
> copy method in StorelessUnivariateStatistic forcing all implementations to be
> 'copyable'.
> The following classes were able to be given copy constructors without issue:
> Max
> SumOfSquares
> Sum
> Product
> FirstMoment
> SecondMoment
> ThirdMoment
> FourthMoment
> Median
> Min
> SumOfLogs
> Percentile
> Skewness
> Variance
> Mean
> Kurtois
> StandardDeviation
> Phil Steitz wrote:
> > Jason C. HandUber wrote:
> >> Hello,
> >>
> >> I'm writing an evolutionary algorithm in which each individual contains
> >> StandardDeviations and Means. From time to time I need a deep copy / clone
> >> of an individual. Thus far I've actually had to keep a list of all data
> >> and, when cloning, generate a new statistic and increment it with all that
> >> data. Now that I'm moving to production level, turns out I'm running out
> >> of memory (no huge surprise). I'm going to extend Mean, Variance,
> >> StandardDeviation, FirstMoment, and SecondMoment for my application to
> >> provide a copy constructor (which, according to Item 10, page 51 of
> >> Bloch's effective java, beats out clone, and I buy that) for each. Anyway,
> >> I think that addition would be easy and general enough to introduce into
> >> the trunk. Any thoughts?
> > +1 on this enhancement, also for SummaryStatistics, implemented as you
> > describe.
> >
> > Please follow instructions here
> > to create a patch against
> > either trunk or the 2.0 development branch (/branches/MATH_2_0) and attach
> > it to a JIRA ticket.
> >
> > Thanks!
> >
> > Phil
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
