[GitHub] GedMarc commented on issue #398: Add ComparableUtils
GedMarc commented on issue #398: Add ComparableUtils URL: https://github.com/apache/commons-lang/pull/398#issuecomment-455463754 @MarkDacek compareTo() is null safe by default, that's the difference vs compare(T a1,T a2)? So adding in null checks into compareTo() seems likes a waste of overhead? Not sure if i'm misunderstanding this - http://www.javapractices.com/topic/TopicAction.do?Id=10 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] Sam-Kruglov commented on issue #398: Add ComparableUtils
Sam-Kruglov commented on issue #398: Add ComparableUtils URL: https://github.com/apache/commons-lang/pull/398#issuecomment-455475212 @MarkDacek @GedMarc actually that's correct, compareTo is null safe, here is a piece of its javadoc: `@throws NullPointerException if the specified object is null` This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[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&focusedCommentId=16746265#comment-16746265
]
Gary Gregory commented on VFS-398:
--
Apologies, I was looking the wrong PR!
> 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&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] [Comment Edited] (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&focusedCommentId=16746274#comment-16746274
]
Gary Gregory edited comment on VFS-398 at 1/18/19 1:20 PM:
---
The main PR applies cleanly and build is OK. I might not have the time to
review today. A second set of eyes would help as this is a large-ish patch. I
had to hand edit the test case class.
was (Author: garydgregory):
PR applies cleanly and build is OK. I might not have the time to review today.
A second set of eyes would help as this is a large-ish patch.
> 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&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] [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&focusedCommentId=16746274#comment-16746274
]
Gary Gregory commented on VFS-398:
--
PR applies cleanly and build is OK. I might not have the time to review today.
A second set of eyes would help as this is a large-ish patch.
> 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&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] [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&focusedCommentId=16746328#comment-16746328
]
Otto Fowler commented on VFS-398:
-
maybe [~b.eckenfels]?
> 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&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] [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&focusedCommentId=16746342#comment-16746342
]
Bernd Eckenfels commented on VFS-398:
-
I think the overall idea of checking for known schemes is an option to solve
this dilemma (unclear when URI and when file names are used), but I am not sure
about the implementation details: the change seems to use getScheme() very
often and this method constructs a new response object every time, that might
be performance critical (I havent measured it yet, but in the past I say a lot
of resolves in normal operations).
Also changing the sequence of cleanup when closing the manager was very tricky
in the past, so hopefully providers.clear() is ok in the new patch.
> 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&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] [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&focusedCommentId=16746347#comment-16746347
]
Otto Fowler commented on VFS-398:
-
The point about getSchemes is a good one. I was more concerned with 'how to
get the schemes correctly' than that issue. Let me think about that and see if
I can make it better.
> 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&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] (MATH-1460) IntegerSequence.Incrementor should fail earlier
[
https://issues.apache.org/jira/browse/MATH-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles resolved MATH-1460.
--
Resolution: Fixed
> IntegerSequence.Incrementor should fail earlier
> ---
>
> Key: MATH-1460
> URL: https://issues.apache.org/jira/browse/MATH-1460
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Gilles
>Assignee: Gilles
>Priority: Minor
> Fix For: 4.0
>
>
> Method {{increment(int nTimes)}} allows increment beyond the maximal value.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (MATH-1458) Simpson Integrator computes incorrect value at minimum iterations=1 and wastes an iteration
[
https://issues.apache.org/jira/browse/MATH-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles resolved MATH-1458.
--
Resolution: Fixed
> Simpson Integrator computes incorrect value at minimum iterations=1 and
> wastes an iteration
> ---
>
> Key: MATH-1458
> URL: https://issues.apache.org/jira/browse/MATH-1458
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
> Environment: openjdk version "1.8.0_162"
>
> OpenJDK Runtime Environment (build 1.8.0_162-8u162-b12-0ubuntu0.16.04.2-b12)
>
> OpenJDK 64-Bit Server VM (build 25.162-b12, mixed mode)
>Reporter: Alex D Herbert
>Priority: Minor
> Labels: documentation, easyfix, newbie, patch
>
> org.apache.commons.math3.analysis.integration.SimpsonIntergrator
> When used with minimalIterationCount == 1 the integrator computes the wrong
> value due to the inlining of computation of stage 1 and stage 0 of the
> TrapezoidIntegrator. Each stage is successive since it relies on the result
> of the previous stage. So stage 0 must be computed first. This inlining
> causes stage 1 to be computed before stage 0:
> {code:java}
> return (4 * qtrap.stage(this, 1) - qtrap.stage(this, 0)) / 3.0;
> {code}
> This can be fixed using:
> {code:java}
> final double s0 = qtrap.stage(this, 0);
> return (4 * qtrap.stage(this, 1) - s0) / 3.0;{code}
> What is not clear is why setting minimum iterations to 1 results in no
> iteration. This is not documented. I would expect setting it to 1 would
> compute the first Simpson sum and then perform 1 refinement. This would make
> it functionality equivalent to the other Integrator classes which compute two
> sums for the first iteration and allow them to be compared if minimum
> iterations = 1. If convergence fails then each additional iteration computes
> an additional sum.
> Note when used with minimalIterationCount > 1 the SimpsonIntegrator wastes a
> stage since it computes the following stages: 0, 0, 1, 2, 3. i.e. stage 0 is
> computed twice. This is because the iteration is incremented after the stage
> is computed:
> {code:java}
> final double t = qtrap.stage(this, getIterations());
> incrementCount();
> {code}
> This should be:
> {code:java}
> incrementCount();
> final double t = qtrap.stage(this, getIterations());
> {code}
> On the first iteration it thus computes the trapezoid sum and compares it to
> zero. This would result in a bad computation if integrating a function whose
> trapezoid sum is zero (e.g. y=x^3 in the range -1 to 1). However since
> iteration only occurs for minimalIterationCount>1 no termination comparison
> is made on the first loop. The first termination comparison can be made at
> iteration=2 where the comparison will be between the Trapezoid sum and the
> first Simpson sum. This is a bug.
> However I do not want to submit a formal patch as there is a lack of
> consistency across all the integrators in their doIntegrate() method with the
> use of incrementCount() and what the iteration number should be at the start
> of the while (true) loop:
> * IterativeLegendreGauss integrator uses getIterations()+1 to mark the
> current iteration inside the loop and calls incrementCount() at the end.
> * TrapezoidIntegrator calls incrementCount() outside the loop, uses
> getIterations() to mark the current iteration and calls incrementCount() at
> the end.
> * The MidpointIntegrator calls incrementCount() at the start of the loop and
> uses getIterations() to mark the current iteration.
> * The RombergIntegrator calls incrementCount() outside the loop, uses
> getIterations() to mark the current iteration and calls incrementCount() in
> the middle of the loop before termination conditions have been checked. This
> allows it to fail when the iterations are equal to the maximum iterations
> even if convergence has been achieved (see Note*).
> * The SimpsonIntegrator uses getIterations() to mark the current iteration
> and calls incrementCount() immediately after.
> Note*: This may not be discovered in a unit test since the incrementCount()
> uses a backing Incrementor where the Incrementor.increment() method calls
> Incrementor.increment(1) which ends up calling canIncrement(0) \{ instead of
> canIncrement(nTimes) } to check if the maxCountCallback should be triggered.
> I expect that all uses of the Incrementor actually trigger the
> maxCountCallback when the count has actually exceeded the maximalCount. I
> don't want to get into debugging that class since it also has an iterator
> using hasNext() with a call to canIncrement(0) and I do not know the
