[GitHub] Sam-Kruglov commented on issue #398: Add ComparableUtils

[GitBox]

Sam-Kruglov commented on issue #398: Add ComparableUtils
URL: https://github.com/apache/commons-lang/pull/398#issuecomment-455448673
 
 
   Good idea will add. But following that logic, the whole commons is just an 
overhead then.
   
   


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] MarkDacek commented on issue #398: Add ComparableUtils

[GitBox]

MarkDacek commented on issue #398: Add ComparableUtils
URL: https://github.com/apache/commons-lang/pull/398#issuecomment-455432213
 
 
   I think you'd have to add in null-safety to make this worthwhile. Without 
that, it's just overhead on top of `a.compareTo(b)`.
   


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

A Survey on The Usage of Sonar Cloud

[Edna Dias Canedo]

Dear all,

I am investigating how Apache development teams use static analysis tools
(in particular SonarQube). To this end, I kindly ask you to answer a small
survey on this topic. The survey is available at:

https://canedo.typeform.com/to/JxPfG6

All the best.

Professora Dra. Edna Dias Canedo
Department of Computer Science
University of Brasília (UnB), Campus Darcy Ribeiro

A Survey on The Usage of Sonar Cloud

[Edna Dias Canedo]

> Dear all,
>>
>>
>>
>> I am investigating how Apache development teams use static
>> analysis tools (in particular SonarQube). To this end, I kindly ask 
>> you to
>> answer a small survey on this topic. The survey is available at:
>>
>> [image:
>> https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif]
>>
>>
>>
>> *https://canedo.typeform.com/to/JxPfG6
>> *
>>
>>
>>
>> All the best
>>
> --
> Professora Dra. Edna Dias Canedo
> Department of Computer Science
> University of Brasília (UnB), Campus Darcy Ribeiro
>
>
>

-- 
Professora Dra. Edna Dias Canedo
Department of Computer Science
University of Brasília (UnB), Campus Darcy Ribeiro

[jira] [Resolved] (NUMBERS-79) Convert fraction addition from BigInteger-based to long-based

[Eric Barnhill (JIRA)]

 [ 
https://issues.apache.org/jira/browse/NUMBERS-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Barnhill resolved NUMBERS-79.
--
Resolution: Fixed

Fraction's long-based approach passes all tests

> Convert fraction addition from BigInteger-based to long-based
> -
>
> Key: NUMBERS-79
> URL: https://issues.apache.org/jira/browse/NUMBERS-79
> Project: Commons Numbers
>  Issue Type: Improvement
>Reporter: Eric Barnhill
>Assignee: Eric Barnhill
>Priority: Minor
>
> Current Fraction class uses BigInteger due to the fact that in extreme cases 
> adding and subtraction of fractions can require 65 bits of precision. However 
> this is very costly in terms of performance for all but the most extreme 
> cases. This ticket proposes using long-based arithmetic for Fraction addition 
> and subtraction, and recommending BigFraction if the operation may run very 
> large.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NUMBERS-74) Make "Fraction" a ValJO

[Eric Barnhill (JIRA)]

[ 
https://issues.apache.org/jira/browse/NUMBERS-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745664#comment-16745664
 ] 

Eric Barnhill commented on NUMBERS-74:
--

Converting factory constructors to "of" and "from" methods on this ticket

> Make "Fraction" a ValJO
> ---
>
> Key: NUMBERS-74
> URL: https://issues.apache.org/jira/browse/NUMBERS-74
> Project: Commons Numbers
>  Issue Type: Sub-task
>  Components: fraction
>Reporter: Gilles
>Priority: Major
>  Labels: API
> Fix For: 1.0
>
>
> [This ML post|https://markmail.org/message/fhrnyg3nfer7y2cy] makes 
> suggestions and points to potential issues with that class.
> A.o. things,
> * there seems to be some code overlap between the constructors and the 
> {{getReducedFraction}} method (and the latter should probably be private 
> anyways),
> * method {{percentageValue}} is not very useful,
> * a lot of constants should be removed,
> * {{serialVersionUID}} should be updated, and moved to the top of the 
> declaration list.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (VFS-645) VfsClassLoaderTests and JarProviderTestCase fails on Java 9 and up

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745583#comment-16745583
 ] 

Gary Gregory commented on VFS-645:
--

This ticket only addressed the two tests mentioned. There are indeed other 
failures on Java 11.

> VfsClassLoaderTests and JarProviderTestCase fails on Java 9 and up
> --
>
> Key: VFS-645
> URL: https://issues.apache.org/jira/browse/VFS-645
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: Nightly Builds, 2.1, 2.2
> Environment: Apache Maven 3.5.0 
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T13:39:06-06:00)
> Maven home: C:\Java\apache-maven-3.5.0\bin\..
> Java version: 9, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk-9
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 2.3
>
>
> Running the build with Oracle Java 9 on Windows 10 fails. The same failures 
> happen with version 2.1.
> {noformat}
> Tests run: 84, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 4.01 sec <<< 
> FAILURE! - in org.apache.commons.vfs2.provider.jar.test.NestedJarTestCase
> testSealing(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests)  Time 
> elapsed: 0 sec  <<< ERROR!
> java.lang.ClassNotFoundException: code.sealed.AnotherClass
> at 
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:152)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:563)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496)
> at 
> org.apache.commons.vfs2.impl.test.VfsClassLoaderTests.testSealing(VfsClassLoaderTests.java:88)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> at 
> org.apache.commons.vfs2.test.AbstractProviderTestCase.runTest(AbstractProviderTestCase.java:190)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
> at 
> org.apache.commons.vfs2.test.AbstractTestSuite$1.protect(AbstractTestSuite.java:132)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at 
> org.apache.commons.vfs2.test.AbstractTestSuite.run(AbstractTestSuite.java:137)
> at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: org.apache.commons.vfs2.FileSystemException: Could not retrieve 
> the certificates of 
> "jar:jar:file:///C:/vcs/svn/apache/commons/trunks-proper/vfs/commons-vfs2/target/test-classes/test-data/nested.jar!/test.jar!/code/sealed/AnotherClass.class".
> at 
> org.apache.commons.vfs2.provider.DefaultFileContent.getCertificates(DefaultFileContent.java:331)
> at 
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:180)
> at 
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> ... 27 more
> Caused by: java.lang.IllegalStateException: zip file closed
> at java.base/java.util.zip.ZipFile.ensureOpen(ZipFile.java:664)
> at java.base/java.util.zip.ZipFile.getInputStream(ZipFile.java:334)
> at java.base/java.util.jar.JarFile.getBytes(JarFile.java:761)
>

[jira] [Commented] (VFS-645) VfsClassLoaderTests and JarProviderTestCase fails on Java 9 and up

[Otto Fowler (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745563#comment-16745563
 ] 

Otto Fowler commented on VFS-645:
-

I apologize.  Please ignore.  I believe that the additional failures are java 
11 only.

Even though I had set my env to java 9, my $JAVA_HOME was still 11.

Sorry

> VfsClassLoaderTests and JarProviderTestCase fails on Java 9 and up
> --
>
> Key: VFS-645
> URL: https://issues.apache.org/jira/browse/VFS-645
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: Nightly Builds, 2.1, 2.2
> Environment: Apache Maven 3.5.0 
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T13:39:06-06:00)
> Maven home: C:\Java\apache-maven-3.5.0\bin\..
> Java version: 9, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk-9
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 2.3
>
>
> Running the build with Oracle Java 9 on Windows 10 fails. The same failures 
> happen with version 2.1.
> {noformat}
> Tests run: 84, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 4.01 sec <<< 
> FAILURE! - in org.apache.commons.vfs2.provider.jar.test.NestedJarTestCase
> testSealing(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests)  Time 
> elapsed: 0 sec  <<< ERROR!
> java.lang.ClassNotFoundException: code.sealed.AnotherClass
> at 
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:152)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:563)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496)
> at 
> org.apache.commons.vfs2.impl.test.VfsClassLoaderTests.testSealing(VfsClassLoaderTests.java:88)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> at 
> org.apache.commons.vfs2.test.AbstractProviderTestCase.runTest(AbstractProviderTestCase.java:190)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
> at 
> org.apache.commons.vfs2.test.AbstractTestSuite$1.protect(AbstractTestSuite.java:132)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at 
> org.apache.commons.vfs2.test.AbstractTestSuite.run(AbstractTestSuite.java:137)
> at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: org.apache.commons.vfs2.FileSystemException: Could not retrieve 
> the certificates of 
> "jar:jar:file:///C:/vcs/svn/apache/commons/trunks-proper/vfs/commons-vfs2/target/test-classes/test-data/nested.jar!/test.jar!/code/sealed/AnotherClass.class".
> at 
> org.apache.commons.vfs2.provider.DefaultFileContent.getCertificates(DefaultFileContent.java:331)
> at 
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:180)
> at 
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> ... 27 more
> Caused by: java.lang.IllegalStateException: zip file closed
> at java.base/java.util.zip.ZipFile.ensureOpen(ZipFile.java:664)
> at java.base/java.util.zip.ZipFile.getInputStream(ZipFile.java:334)
> 

[jira] [Comment Edited] (NUMBERS-92) Rename AbstractFormat to AbstractFractionFormat

[Eric Barnhill (JIRA)]

[ 
https://issues.apache.org/jira/browse/NUMBERS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745545#comment-16745545
 ] 

Eric Barnhill edited comment on NUMBERS-92 at 1/17/19 9:53 PM:
---

FractionFormat and BigFractionFormat classes are not called from within the 
Fraction and BigFraction classes. They do a few things. When passed a fraction, 
they return a string representation of that fraction in locale-specific proper 
and improper forms (what is locale specific about fractions, I haven't a clue. 
Maybe it handles interchange between commas and decimals?). They also contain 
the functionality for parse() . I think these two use cases are surely their 
main ones, and I can see why this functionality is given its own class rather 
than encapsulated within Fraction() and BigFraction(), as their looks to be 
sufficient complexity around this issue to warrant a class devoted to it.

They do have some additional functionality I would not have thought of myself. 
For example, if a double is send to format, it will return a fraction of that 
double. I think that's a little strange but maybe there was a use case for it 
that came up in the old days.


was (Author: ericbarnhill):
FractionFormat and BigFraction format classes are not called from within the 
Fraction and BigFraction classes. They do a few things. When passed a fraction, 
they return a string representation of that fraction in locale-specific proper 
and improper forms (what is locale specific about fractions, I haven't a clue. 
Maybe it handles interchange between commas and decimals?). They also contain 
the functionality for parse() . I think these two use cases are surely their 
main ones, and I can see why this functionality is given its own class rather 
than encapsulated within Fraction() and BigFraction(), as their looks to be 
sufficient complexity around this issue to warrant a class devoted to it.

They do have some additional functionality I would not have thought of myself. 
For example, if a double is send to format, it will return a fraction of that 
double. I think that's a little strange but maybe there was a use case for it 
that came up in the old days.

> Rename AbstractFormat to AbstractFractionFormat
> ---
>
> Key: NUMBERS-92
> URL: https://issues.apache.org/jira/browse/NUMBERS-92
> Project: Commons Numbers
>  Issue Type: Improvement
>Reporter: Eric Barnhill
>Assignee: Eric Barnhill
>Priority: Minor
>
> FractionFormat and BigFractionFormat have an abstract class. It is named 
> AbstractFormat which is too general. Better to call it AbstractFractionFormat 
> I think.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (NUMBERS-92) Rename AbstractFormat to AbstractFractionFormat

[Eric Barnhill (JIRA)]

[ 
https://issues.apache.org/jira/browse/NUMBERS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745545#comment-16745545
 ] 

Eric Barnhill edited comment on NUMBERS-92 at 1/17/19 9:54 PM:
---

FractionFormat and BigFractionFormat classes are not called from within the 
Fraction and BigFraction classes. They do a few things. When passed a fraction, 
they return a string representation of that fraction in locale-specific proper 
and improper forms (what is locale specific about fractions, I haven't a clue. 
Maybe it handles interchange between commas and decimals?). They also contain 
the functionality for parse() . I think these two use cases are surely their 
main ones, and I can see why this functionality is given its own class rather 
than encapsulated within Fraction() and BigFraction(), as there looks to be 
sufficient complexity around this issue to warrant a class devoted to it.

They do have some additional functionality I would not have thought of myself. 
For example, if a double is send to the workhorse format() method, it will 
return a fraction constructed out of that double. I think that's a little 
strange but maybe there was a use case for it that came up in the old days.


was (Author: ericbarnhill):
FractionFormat and BigFractionFormat classes are not called from within the 
Fraction and BigFraction classes. They do a few things. When passed a fraction, 
they return a string representation of that fraction in locale-specific proper 
and improper forms (what is locale specific about fractions, I haven't a clue. 
Maybe it handles interchange between commas and decimals?). They also contain 
the functionality for parse() . I think these two use cases are surely their 
main ones, and I can see why this functionality is given its own class rather 
than encapsulated within Fraction() and BigFraction(), as their looks to be 
sufficient complexity around this issue to warrant a class devoted to it.

They do have some additional functionality I would not have thought of myself. 
For example, if a double is send to format, it will return a fraction of that 
double. I think that's a little strange but maybe there was a use case for it 
that came up in the old days.

> Rename AbstractFormat to AbstractFractionFormat
> ---
>
> Key: NUMBERS-92
> URL: https://issues.apache.org/jira/browse/NUMBERS-92
> Project: Commons Numbers
>  Issue Type: Improvement
>Reporter: Eric Barnhill
>Assignee: Eric Barnhill
>Priority: Minor
>
> FractionFormat and BigFractionFormat have an abstract class. It is named 
> AbstractFormat which is too general. Better to call it AbstractFractionFormat 
> I think.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (NUMBERS-92) Rename AbstractFormat to AbstractFractionFormat

[Eric Barnhill (JIRA)]

[ 
https://issues.apache.org/jira/browse/NUMBERS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745545#comment-16745545
 ] 

Eric Barnhill edited comment on NUMBERS-92 at 1/17/19 9:54 PM:
---

FractionFormat and BigFractionFormat classes are not called from within the 
Fraction and BigFraction classes. Rather, when passed a fraction, they return a 
string representation of that fraction in locale-specific proper and improper 
forms (what is locale specific about fractions, I haven't a clue. Maybe it 
handles interchange between commas and decimals?). They also contain the 
functionality for parse() . I think these two use cases are surely their main 
ones, and I can see why this functionality is given its own class rather than 
encapsulated within Fraction() and BigFraction(), as there looks to be 
sufficient complexity around this issue to warrant a class devoted to it.

They do have some additional functionality I would not have thought of myself. 
For example, if a double is send to the workhorse format() method, it will 
return a fraction constructed out of that double. I think that's a little 
strange but maybe there was a use case for it that came up in the old days.


was (Author: ericbarnhill):
FractionFormat and BigFractionFormat classes are not called from within the 
Fraction and BigFraction classes. They do a few things. When passed a fraction, 
they return a string representation of that fraction in locale-specific proper 
and improper forms (what is locale specific about fractions, I haven't a clue. 
Maybe it handles interchange between commas and decimals?). They also contain 
the functionality for parse() . I think these two use cases are surely their 
main ones, and I can see why this functionality is given its own class rather 
than encapsulated within Fraction() and BigFraction(), as there looks to be 
sufficient complexity around this issue to warrant a class devoted to it.

They do have some additional functionality I would not have thought of myself. 
For example, if a double is send to the workhorse format() method, it will 
return a fraction constructed out of that double. I think that's a little 
strange but maybe there was a use case for it that came up in the old days.

> Rename AbstractFormat to AbstractFractionFormat
> ---
>
> Key: NUMBERS-92
> URL: https://issues.apache.org/jira/browse/NUMBERS-92
> Project: Commons Numbers
>  Issue Type: Improvement
>Reporter: Eric Barnhill
>Assignee: Eric Barnhill
>Priority: Minor
>
> FractionFormat and BigFractionFormat have an abstract class. It is named 
> AbstractFormat which is too general. Better to call it AbstractFractionFormat 
> I think.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (NUMBERS-92) Rename AbstractFormat to AbstractFractionFormat

[Eric Barnhill (JIRA)]

[ 
https://issues.apache.org/jira/browse/NUMBERS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745545#comment-16745545
 ] 

Eric Barnhill edited comment on NUMBERS-92 at 1/17/19 9:53 PM:
---

FractionFormat and BigFraction format classes are not called from within the 
Fraction and BigFraction classes. They do a few things. When passed a fraction, 
they return a string representation of that fraction in locale-specific proper 
and improper forms (what is locale specific about fractions, I haven't a clue. 
Maybe it handles interchange between commas and decimals?). They also contain 
the functionality for parse() . I think these two use cases are surely their 
main ones, and I can see why this functionality is given its own class rather 
than encapsulated within Fraction() and BigFraction(), as their looks to be 
sufficient complexity around this issue to warrant a class devoted to it.

They do have some additional functionality I would not have thought of myself. 
For example, if a double is send to format, it will return a fraction of that 
double. I think that's a little strange but maybe there was a use case for it 
that came up in the old days.


was (Author: ericbarnhill):
FractionFormat and BigFraction format classes are not called from within the 
Fraction and BigFraction classes. They do a few things. When passed a fraction, 
they return a string representation of that fraction in locale-specific proper 
and improper forms (what is locale specific about fractions, I haven't a clue. 
Maybe it handles interchange between commas and decimals?). They also contain 
the functionality for parse() . I think these two use cases are surely their 
main ones, and I can see why they were spun out of the objects, as they are 
complicated enough to be their own classes.

They do have some additional functionality I would not have thought of myself. 
For example, if a double is send to format, it will return a fraction of that 
double. I think that's a little strange but maybe there was a use case for it 
that came up in the old days.

> Rename AbstractFormat to AbstractFractionFormat
> ---
>
> Key: NUMBERS-92
> URL: https://issues.apache.org/jira/browse/NUMBERS-92
> Project: Commons Numbers
>  Issue Type: Improvement
>Reporter: Eric Barnhill
>Assignee: Eric Barnhill
>Priority: Minor
>
> FractionFormat and BigFractionFormat have an abstract class. It is named 
> AbstractFormat which is too general. Better to call it AbstractFractionFormat 
> I think.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (NUMBERS-92) Rename AbstractFormat to AbstractFractionFormat

[Eric Barnhill (JIRA)]

[ 
https://issues.apache.org/jira/browse/NUMBERS-92?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745545#comment-16745545
 ] 

Eric Barnhill commented on NUMBERS-92:
--

FractionFormat and BigFraction format classes are not called from within the 
Fraction and BigFraction classes. They do a few things. When passed a fraction, 
they return a string representation of that fraction in locale-specific proper 
and improper forms (what is locale specific about fractions, I haven't a clue. 
Maybe it handles interchange between commas and decimals?). They also contain 
the functionality for parse() . I think these two use cases are surely their 
main ones, and I can see why they were spun out of the objects, as they are 
complicated enough to be their own classes.

They do have some additional functionality I would not have thought of myself. 
For example, if a double is send to format, it will return a fraction of that 
double. I think that's a little strange but maybe there was a use case for it 
that came up in the old days.

> Rename AbstractFormat to AbstractFractionFormat
> ---
>
> Key: NUMBERS-92
> URL: https://issues.apache.org/jira/browse/NUMBERS-92
> Project: Commons Numbers
>  Issue Type: Improvement
>Reporter: Eric Barnhill
>Assignee: Eric Barnhill
>Priority: Minor
>
> FractionFormat and BigFractionFormat have an abstract class. It is named 
> AbstractFormat which is too general. Better to call it AbstractFractionFormat 
> I think.



--
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

[Otto Fowler (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745463#comment-16745463
 ] 

Otto Fowler commented on VFS-398:
-

There is a new test in the URIParserTestCase for the issue reported.  What 
tests do you mean?

> 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)

A Survey on The Usage of Sonar Cloud

[Edna Dias Canedo]

>
> dear all,
>
>
>
> I am investigating how Apache development teams use static
> analysis tools (in particular SonarQube). To this end, I kindly ask 
> you to
> answer a small survey on this topic. The survey is available at:
>
> [image:
> https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif]
>
>
>
> *https://canedo.typeform.com/to/JxPfG6
> *
>
>
>
> All the best.
>
>
>
 --
> Professora Dra. Edna Dias Canedo
> Department of Computer Science
> University of Brasília (UnB), Campus Darcy Ribeiro
>
>
>

-- 
Professora Dra. Edna Dias Canedo
Department of Computer Science
University of Brasília (UnB), Campus Darcy Ribeiro

[jira] [Comment Edited] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745377#comment-16745377
 ] 

Gary Gregory edited comment on VFS-398 at 1/17/19 6:44 PM:
---

Looking at [https://github.com/apache/commons-vfs/pull/29/files], I see no new 
tests :(


was (Author: garydgregory):
Looking at [https://github.com/apache/commons-vfs/pull/29/files], I see no 
tests :(

> 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] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745377#comment-16745377
 ] 

Gary Gregory commented on VFS-398:
--

Looking at [https://github.com/apache/commons-vfs/pull/29/files], I see no 
tests :(

> 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] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name

[Otto Fowler (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745296#comment-16745296
 ] 

Otto Fowler commented on VFS-398:
-

[~garydgregory] :

[https://github.com/apache/commons-vfs/pull/29/commits/c7f5944f5c6d7b3e9bba49344bf5389346982f47]

 

> 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] [Commented] (VFS-645) VfsClassLoaderTests and JarProviderTestCase fails on Java 9 and up

[Otto Fowler (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745287#comment-16745287
 ] 

Otto Fowler commented on VFS-645:
-

OK, I managed to get java9 from AdoptOpenJDK installed, and testing fails there 
too:

Tests in error:
 
AbstractFtpsProviderTestCase$FtpProviderTestSuite>AbstractTestSuite.run:137->setUp:153->AbstractTestSuite.setUp:166
 » FileSystem
 
AbstractFtpsProviderTestCase$FtpProviderTestSuite>AbstractTestSuite.run:137->setUp:153->AbstractTestSuite.setUp:166
 » FileSystem
 MultipleConnectionTestCase.testConnectRoot:55->resolveRoot:49 » FileSystem 
Cou...
 MultipleConnectionTestCase.testUnderlyingConnect:65 » SSL Unsupported or 
unrec...
org.apache.commons.vfs2.provider.hdfs.test.HdfsFileProviderTest.org.apache.commons.vfs2.provider.hdfs.test.HdfsFileProviderTest
 Run 1: HdfsFileProviderTest.setUp:91 » NoClassDefFound Could not initialize 
class org...
 Run 2: HdfsFileProviderTest.tearDown:135 NullPointer

HdfsFileProviderTestCase$HdfsProviderTestSuite>AbstractTestSuite.run:137->setUp:98
 » ExceptionInInitializer

Tests run: 2177, Failures: 0, Errors: 6, Skipped: 4

 

sample:

Running org.apache.commons.vfs2.provider.hdfs.test.HdfsFileProviderTestCase
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.22 sec <<< 
FAILURE! - in 
org.apache.commons.vfs2.provider.hdfs.test.HdfsFileProviderTestCase
junit.framework.TestSuite@51ec2856(org.apache.commons.vfs2.provider.hdfs.test.HdfsFileProviderTestCase$HdfsProviderTestSuite)
 Time elapsed: 0.22 sec <<< ERROR!
java.lang.ExceptionInInitializerError
 at org.apache.hadoop.util.StringUtils.(StringUtils.java:79)
 at 
org.apache.hadoop.conf.Configuration.getTrimmedStringCollection(Configuration.java:1747)
 at 
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getStorageDirs(FSNamesystem.java:1407)
 at 
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getNamespaceDirs(FSNamesystem.java:1388)
 at 
org.apache.hadoop.hdfs.MiniDFSCluster.createNameNodesAndSetConf(MiniDFSCluster.java:931)
 at 
org.apache.hadoop.hdfs.MiniDFSCluster.initMiniDFSCluster(MiniDFSCluster.java:807)
 at org.apache.hadoop.hdfs.MiniDFSCluster.(MiniDFSCluster.java:738)
 at 
org.apache.commons.vfs2.provider.hdfs.test.HdfsFileProviderTestCase$HdfsProviderTestSuite.setUp(HdfsFileProviderTestCase.java:98)
 at 
org.apache.commons.vfs2.test.AbstractTestSuite$1.protect(AbstractTestSuite.java:131)
 at junit.framework.TestResult.runProtected(TestResult.java:142)
 at 
org.apache.commons.vfs2.test.AbstractTestSuite.run(AbstractTestSuite.java:137)
 at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
 at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
 at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
 at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
 at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
 at 
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
 at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
 at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
Caused by: java.lang.StringIndexOutOfBoundsException: begin 0, end 3, length 2
 at java.base/java.lang.String.checkBoundsBeginEnd(String.java:3319)
 at java.base/java.lang.String.substring(String.java:1874)
 at org.apache.hadoop.util.Shell.(Shell.java:49)
 ... 19 more

Running org.apache.commons.vfs2.provider.hdfs.test.HdfsFileProviderTest
Tests run: 2, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 0.03 sec <<< 
FAILURE! - in org.apache.commons.vfs2.provider.hdfs.test.HdfsFileProviderTest
org.apache.commons.vfs2.provider.hdfs.test.HdfsFileProviderTest Time elapsed: 
0.03 sec <<< ERROR!
java.lang.NoClassDefFoundError: Could not initialize class 
org.apache.hadoop.util.StringUtils
 at 
org.apache.hadoop.conf.Configuration.getTrimmedStringCollection(Configuration.java:1747)
 at 
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getStorageDirs(FSNamesystem.java:1407)
 at 
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getNamespaceDirs(FSNamesystem.java:1388)
 at 
org.apache.hadoop.hdfs.MiniDFSCluster.createNameNodesAndSetConf(MiniDFSCluster.java:931)
 at 
org.apache.hadoop.hdfs.MiniDFSCluster.initMiniDFSCluster(MiniDFSCluster.java:807)
 at org.apache.hadoop.hdfs.MiniDFSCluster.(MiniDFSCluster.java:738)
 at 
org.apache.commons.vfs2.provider.hdfs.test.HdfsFileProviderTest.setUp(HdfsFileProviderTest.java:91)
 at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
 at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
 at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at 

[jira] [Commented] (VFS-645) VfsClassLoaderTests and JarProviderTestCase fails on Java 9 and up

[Otto Fowler (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745288#comment-16745288
 ] 

Otto Fowler commented on VFS-645:
-

java -version
openjdk version "9"
OpenJDK Runtime Environment (build 9+181)
OpenJDK 64-Bit Server VM (build 9+181, mixed mode)

> VfsClassLoaderTests and JarProviderTestCase fails on Java 9 and up
> --
>
> Key: VFS-645
> URL: https://issues.apache.org/jira/browse/VFS-645
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: Nightly Builds, 2.1, 2.2
> Environment: Apache Maven 3.5.0 
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T13:39:06-06:00)
> Maven home: C:\Java\apache-maven-3.5.0\bin\..
> Java version: 9, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk-9
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 2.3
>
>
> Running the build with Oracle Java 9 on Windows 10 fails. The same failures 
> happen with version 2.1.
> {noformat}
> Tests run: 84, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 4.01 sec <<< 
> FAILURE! - in org.apache.commons.vfs2.provider.jar.test.NestedJarTestCase
> testSealing(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests)  Time 
> elapsed: 0 sec  <<< ERROR!
> java.lang.ClassNotFoundException: code.sealed.AnotherClass
> at 
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:152)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:563)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496)
> at 
> org.apache.commons.vfs2.impl.test.VfsClassLoaderTests.testSealing(VfsClassLoaderTests.java:88)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> at 
> org.apache.commons.vfs2.test.AbstractProviderTestCase.runTest(AbstractProviderTestCase.java:190)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
> at 
> org.apache.commons.vfs2.test.AbstractTestSuite$1.protect(AbstractTestSuite.java:132)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at 
> org.apache.commons.vfs2.test.AbstractTestSuite.run(AbstractTestSuite.java:137)
> at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: org.apache.commons.vfs2.FileSystemException: Could not retrieve 
> the certificates of 
> "jar:jar:file:///C:/vcs/svn/apache/commons/trunks-proper/vfs/commons-vfs2/target/test-classes/test-data/nested.jar!/test.jar!/code/sealed/AnotherClass.class".
> at 
> org.apache.commons.vfs2.provider.DefaultFileContent.getCertificates(DefaultFileContent.java:331)
> at 
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:180)
> at 
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> ... 27 more
> Caused by: java.lang.IllegalStateException: zip file closed
> at java.base/java.util.zip.ZipFile.ensureOpen(ZipFile.java:664)
> at java.base/java.util.zip.ZipFile.getInputStream(ZipFile.java:334)
> at 

[jira] [Commented] (VFS-398) FtpFileObject.getChildren() fails when a folder contains a file with a colon in the name

[Gary Gregory (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745277#comment-16745277
 ] 

Gary Gregory commented on VFS-398:
--

Hi [~ottobackwards]:

I'm back with a new laptop. What is the state of the patch? I see my version of 
your patch attached to this ticket. How about my comments in 
https://issues.apache.org/jira/browse/VFS-398?focusedCommentId=16712066=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16712066
 ?

Gary

> 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] [Commented] (VFS-645) VfsClassLoaderTests and JarProviderTestCase fails on Java 9 and up

[Otto Fowler (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745258#comment-16745258
 ] 

Otto Fowler commented on VFS-645:
-

[~garydgregory] I was going to test this, but found I could not install java9 
and had to use java11.

With java 11 after these fixes there are still errors.  Should I open up 
another jira?

> VfsClassLoaderTests and JarProviderTestCase fails on Java 9 and up
> --
>
> Key: VFS-645
> URL: https://issues.apache.org/jira/browse/VFS-645
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: Nightly Builds, 2.1, 2.2
> Environment: Apache Maven 3.5.0 
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T13:39:06-06:00)
> Maven home: C:\Java\apache-maven-3.5.0\bin\..
> Java version: 9, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk-9
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 2.3
>
>
> Running the build with Oracle Java 9 on Windows 10 fails. The same failures 
> happen with version 2.1.
> {noformat}
> Tests run: 84, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 4.01 sec <<< 
> FAILURE! - in org.apache.commons.vfs2.provider.jar.test.NestedJarTestCase
> testSealing(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests)  Time 
> elapsed: 0 sec  <<< ERROR!
> java.lang.ClassNotFoundException: code.sealed.AnotherClass
> at 
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:152)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:563)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496)
> at 
> org.apache.commons.vfs2.impl.test.VfsClassLoaderTests.testSealing(VfsClassLoaderTests.java:88)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> at 
> org.apache.commons.vfs2.test.AbstractProviderTestCase.runTest(AbstractProviderTestCase.java:190)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
> at 
> org.apache.commons.vfs2.test.AbstractTestSuite$1.protect(AbstractTestSuite.java:132)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at 
> org.apache.commons.vfs2.test.AbstractTestSuite.run(AbstractTestSuite.java:137)
> at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: org.apache.commons.vfs2.FileSystemException: Could not retrieve 
> the certificates of 
> "jar:jar:file:///C:/vcs/svn/apache/commons/trunks-proper/vfs/commons-vfs2/target/test-classes/test-data/nested.jar!/test.jar!/code/sealed/AnotherClass.class".
> at 
> org.apache.commons.vfs2.provider.DefaultFileContent.getCertificates(DefaultFileContent.java:331)
> at 
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:180)
> at 
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> ... 27 more
> Caused by: java.lang.IllegalStateException: zip file closed
> at java.base/java.util.zip.ZipFile.ensureOpen(ZipFile.java:664)
> at 

[jira] [Commented] (VFS-645) VfsClassLoaderTests and JarProviderTestCase fails on Java 9 and up

[Otto Fowler (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745259#comment-16745259
 ] 

Otto Fowler commented on VFS-645:
-

note they are not the same errors

> VfsClassLoaderTests and JarProviderTestCase fails on Java 9 and up
> --
>
> Key: VFS-645
> URL: https://issues.apache.org/jira/browse/VFS-645
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: Nightly Builds, 2.1, 2.2
> Environment: Apache Maven 3.5.0 
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T13:39:06-06:00)
> Maven home: C:\Java\apache-maven-3.5.0\bin\..
> Java version: 9, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk-9
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 2.3
>
>
> Running the build with Oracle Java 9 on Windows 10 fails. The same failures 
> happen with version 2.1.
> {noformat}
> Tests run: 84, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 4.01 sec <<< 
> FAILURE! - in org.apache.commons.vfs2.provider.jar.test.NestedJarTestCase
> testSealing(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests)  Time 
> elapsed: 0 sec  <<< ERROR!
> java.lang.ClassNotFoundException: code.sealed.AnotherClass
> at 
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:152)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:563)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496)
> at 
> org.apache.commons.vfs2.impl.test.VfsClassLoaderTests.testSealing(VfsClassLoaderTests.java:88)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> at 
> org.apache.commons.vfs2.test.AbstractProviderTestCase.runTest(AbstractProviderTestCase.java:190)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
> at 
> org.apache.commons.vfs2.test.AbstractTestSuite$1.protect(AbstractTestSuite.java:132)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at 
> org.apache.commons.vfs2.test.AbstractTestSuite.run(AbstractTestSuite.java:137)
> at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: org.apache.commons.vfs2.FileSystemException: Could not retrieve 
> the certificates of 
> "jar:jar:file:///C:/vcs/svn/apache/commons/trunks-proper/vfs/commons-vfs2/target/test-classes/test-data/nested.jar!/test.jar!/code/sealed/AnotherClass.class".
> at 
> org.apache.commons.vfs2.provider.DefaultFileContent.getCertificates(DefaultFileContent.java:331)
> at 
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:180)
> at 
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> ... 27 more
> Caused by: java.lang.IllegalStateException: zip file closed
> at java.base/java.util.zip.ZipFile.ensureOpen(ZipFile.java:664)
> at java.base/java.util.zip.ZipFile.getInputStream(ZipFile.java:334)
> at java.base/java.util.jar.JarFile.getBytes(JarFile.java:761)
> at 
> 

[jira] [Resolved] (JEXL-287) Wrong resolution of local variables

[Henri Biestro (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JEXL-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Henri Biestro resolved JEXL-287.

Resolution: Fixed

A cross between JEXL-287 and safe navigation.
In this case, the local variable is declared, not defined, there is no global 
of that name, the var is undefined; this was detected but not protected by the 
'safe' navigation (aka behave like 3.1).

https://github.com/apache/commons-jexl/commit/d23fc99a99ac44f2a4352899e2a6d12d26a74503

> Wrong resolution of local variables
> ---
>
> Key: JEXL-287
> URL: https://issues.apache.org/jira/browse/JEXL-287
> Project: Commons JEXL
>  Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Major
>
> Consider the following example
> {code:java}
> x = 1; if (false) var x = 2; x
> {code}
> In this example the {{null}} is returned, which is the value of uninitialized 
> local variable {{x}}. The expected behaviour is to return {{1.}}
> The reason is the variable declaration is a *statement*, so one can expect 
> that, as a statement, it should be evaluated according to its position within 
> the script structure. 
> The suggestion is to move the {{Scope.declareVariable()}} call from parse 
> time to interpretation time. Also, the resolution whether an identifier 
> inside the script referes to the local variable or to the contextual variable 
> should be moved from parse time to the interpretation time. 
> I think we can also reconsider the variable resolution during a variable 
> initialization:
> {code:java}
> sum = 0; var sum = sum + 1{code}
> As of now, Jexl evaluates the local variable {{sum}} as {{1}}, as it 
> considers the {{sum+1}} an expression referencing the local variable {{sum}}, 
> which is, sort of, pointless. We can change this to referencing a contextual 
> variable instead, so that the result would be {{2}}. It can be useful in 
> plain-vanilla Jexl (without an access differentiator between local and 
> contextual variables) to allow one to initialize a local variable {{foo}} 
> with the value of contextual variable {{foo}} without using temporary 
> variable.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Reopened] (JEXL-287) Wrong resolution of local variables

[Henri Biestro (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JEXL-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Henri Biestro reopened JEXL-287:


Found regression case related to safe navigation.

> Wrong resolution of local variables
> ---
>
> Key: JEXL-287
> URL: https://issues.apache.org/jira/browse/JEXL-287
> Project: Commons JEXL
>  Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Major
>
> Consider the following example
> {code:java}
> x = 1; if (false) var x = 2; x
> {code}
> In this example the {{null}} is returned, which is the value of uninitialized 
> local variable {{x}}. The expected behaviour is to return {{1.}}
> The reason is the variable declaration is a *statement*, so one can expect 
> that, as a statement, it should be evaluated according to its position within 
> the script structure. 
> The suggestion is to move the {{Scope.declareVariable()}} call from parse 
> time to interpretation time. Also, the resolution whether an identifier 
> inside the script referes to the local variable or to the contextual variable 
> should be moved from parse time to the interpretation time. 
> I think we can also reconsider the variable resolution during a variable 
> initialization:
> {code:java}
> sum = 0; var sum = sum + 1{code}
> As of now, Jexl evaluates the local variable {{sum}} as {{1}}, as it 
> considers the {{sum+1}} an expression referencing the local variable {{sum}}, 
> which is, sort of, pointless. We can change this to referencing a contextual 
> variable instead, so that the result would be {{2}}. It can be useful in 
> plain-vanilla Jexl (without an access differentiator between local and 
> contextual variables) to allow one to initialize a local variable {{foo}} 
> with the value of contextual variable {{foo}} without using temporary 
> variable.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (LANG-1431) ComparableUtils

[Sam Kruglov (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sam Kruglov updated LANG-1431:
--
External issue URL: https://github.com/apache/commons-lang/pull/398

> ComparableUtils
> ---
>
> Key: LANG-1431
> URL: https://issues.apache.org/jira/browse/LANG-1431
> Project: Commons Lang
>  Issue Type: New Feature
>  Components: lang.*
>Affects Versions: 3.8.1
>Reporter: Sam Kruglov
>Priority: Minor
>  Labels: newbie, pull-request-available
>
> I have turned {{feeAmount.compareTo(BigDecimal.ZERO) > 0}} into 
> {{is(feeAmount).greaterThan(BigDecimal.ZERO)}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (VFS-645) VfsClassLoaderTests and JarProviderTestCase fails on Java 9 and up

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/VFS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated VFS-645:
-
Summary: VfsClassLoaderTests and JarProviderTestCase fails on Java 9 and up 
 (was: VfsClassLoaderTests and JarProviderTestCase fails on Java 9)

> VfsClassLoaderTests and JarProviderTestCase fails on Java 9 and up
> --
>
> Key: VFS-645
> URL: https://issues.apache.org/jira/browse/VFS-645
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: Nightly Builds, 2.1, 2.2
> Environment: Apache Maven 3.5.0 
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T13:39:06-06:00)
> Maven home: C:\Java\apache-maven-3.5.0\bin\..
> Java version: 9, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk-9
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
>Priority: Major
>
> Running the build with Oracle Java 9 on Windows 10 fails. The same failures 
> happen with version 2.1.
> {noformat}
> Tests run: 84, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 4.01 sec <<< 
> FAILURE! - in org.apache.commons.vfs2.provider.jar.test.NestedJarTestCase
> testSealing(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests)  Time 
> elapsed: 0 sec  <<< ERROR!
> java.lang.ClassNotFoundException: code.sealed.AnotherClass
> at 
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:152)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:563)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496)
> at 
> org.apache.commons.vfs2.impl.test.VfsClassLoaderTests.testSealing(VfsClassLoaderTests.java:88)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> at 
> org.apache.commons.vfs2.test.AbstractProviderTestCase.runTest(AbstractProviderTestCase.java:190)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
> at 
> org.apache.commons.vfs2.test.AbstractTestSuite$1.protect(AbstractTestSuite.java:132)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at 
> org.apache.commons.vfs2.test.AbstractTestSuite.run(AbstractTestSuite.java:137)
> at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: org.apache.commons.vfs2.FileSystemException: Could not retrieve 
> the certificates of 
> "jar:jar:file:///C:/vcs/svn/apache/commons/trunks-proper/vfs/commons-vfs2/target/test-classes/test-data/nested.jar!/test.jar!/code/sealed/AnotherClass.class".
> at 
> org.apache.commons.vfs2.provider.DefaultFileContent.getCertificates(DefaultFileContent.java:331)
> at 
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:180)
> at 
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> ... 27 more
> Caused by: java.lang.IllegalStateException: zip file closed
> at java.base/java.util.zip.ZipFile.ensureOpen(ZipFile.java:664)
> at java.base/java.util.zip.ZipFile.getInputStream(ZipFile.java:334)
> at java.base/java.util.jar.JarFile.getBytes(JarFile.java:761)
> at 
> 

[GitHub] coveralls commented on issue #398: Add ComparableUtils

[GitBox]

coveralls commented on issue #398: Add ComparableUtils
URL: https://github.com/apache/commons-lang/pull/398#issuecomment-455218326
 
 
   
   [![Coverage 
Status](https://coveralls.io/builds/21131417/badge)](https://coveralls.io/builds/21131417)
   
   Coverage decreased (-0.003%) to 95.27% when pulling 
**cf07c2b29d3c27bead181b4433fa499fe5ed885a on 
Sam-Kruglov:LANG-1431-ComparableUtils** into 
**b00e65686eb1b11c0b814c4aa0d6a22c03be958c on apache:master**.
   


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] [Closed] (VFS-645) VfsClassLoaderTests and JarProviderTestCase fails on Java 9 and up

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/VFS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory closed VFS-645.

   Resolution: Fixed
 Assignee: Gary Gregory
Fix Version/s: 2.3

In svn trunk.

> VfsClassLoaderTests and JarProviderTestCase fails on Java 9 and up
> --
>
> Key: VFS-645
> URL: https://issues.apache.org/jira/browse/VFS-645
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: Nightly Builds, 2.1, 2.2
> Environment: Apache Maven 3.5.0 
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T13:39:06-06:00)
> Maven home: C:\Java\apache-maven-3.5.0\bin\..
> Java version: 9, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk-9
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 2.3
>
>
> Running the build with Oracle Java 9 on Windows 10 fails. The same failures 
> happen with version 2.1.
> {noformat}
> Tests run: 84, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 4.01 sec <<< 
> FAILURE! - in org.apache.commons.vfs2.provider.jar.test.NestedJarTestCase
> testSealing(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests)  Time 
> elapsed: 0 sec  <<< ERROR!
> java.lang.ClassNotFoundException: code.sealed.AnotherClass
> at 
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:152)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:563)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496)
> at 
> org.apache.commons.vfs2.impl.test.VfsClassLoaderTests.testSealing(VfsClassLoaderTests.java:88)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> at 
> org.apache.commons.vfs2.test.AbstractProviderTestCase.runTest(AbstractProviderTestCase.java:190)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
> at 
> org.apache.commons.vfs2.test.AbstractTestSuite$1.protect(AbstractTestSuite.java:132)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at 
> org.apache.commons.vfs2.test.AbstractTestSuite.run(AbstractTestSuite.java:137)
> at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: org.apache.commons.vfs2.FileSystemException: Could not retrieve 
> the certificates of 
> "jar:jar:file:///C:/vcs/svn/apache/commons/trunks-proper/vfs/commons-vfs2/target/test-classes/test-data/nested.jar!/test.jar!/code/sealed/AnotherClass.class".
> at 
> org.apache.commons.vfs2.provider.DefaultFileContent.getCertificates(DefaultFileContent.java:331)
> at 
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:180)
> at 
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> ... 27 more
> Caused by: java.lang.IllegalStateException: zip file closed
> at java.base/java.util.zip.ZipFile.ensureOpen(ZipFile.java:664)
> at java.base/java.util.zip.ZipFile.getInputStream(ZipFile.java:334)
> at java.base/java.util.jar.JarFile.getBytes(JarFile.java:761)
> at 
> 

[jira] [Updated] (VFS-645) VfsClassLoaderTests and JarProviderTestCase fails on Java 9

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/VFS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated VFS-645:
-
Description: 
Running the build with Oracle Java 9 on Windows 10 fails. The same failures 
happen with version 2.1.

{noformat}
Tests run: 84, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 4.01 sec <<< 
FAILURE! - in org.apache.commons.vfs2.provider.jar.test.NestedJarTestCase
testSealing(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests)  Time 
elapsed: 0 sec  <<< ERROR!
java.lang.ClassNotFoundException: code.sealed.AnotherClass
at 
org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:152)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:563)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496)
at 
org.apache.commons.vfs2.impl.test.VfsClassLoaderTests.testSealing(VfsClassLoaderTests.java:88)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:564)
at 
org.apache.commons.vfs2.test.AbstractProviderTestCase.runTest(AbstractProviderTestCase.java:190)
at junit.framework.TestCase.runBare(TestCase.java:141)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at junit.framework.TestSuite.runTest(TestSuite.java:252)
at junit.framework.TestSuite.run(TestSuite.java:247)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
at 
org.apache.commons.vfs2.test.AbstractTestSuite$1.protect(AbstractTestSuite.java:132)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at 
org.apache.commons.vfs2.test.AbstractTestSuite.run(AbstractTestSuite.java:137)
at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at 
org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
at 
org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
at 
org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
at 
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
Caused by: org.apache.commons.vfs2.FileSystemException: Could not retrieve the 
certificates of 
"jar:jar:file:///C:/vcs/svn/apache/commons/trunks-proper/vfs/commons-vfs2/target/test-classes/test-data/nested.jar!/test.jar!/code/sealed/AnotherClass.class".
at 
org.apache.commons.vfs2.provider.DefaultFileContent.getCertificates(DefaultFileContent.java:331)
at 
org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:180)
at 
org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
... 27 more
Caused by: java.lang.IllegalStateException: zip file closed
at java.base/java.util.zip.ZipFile.ensureOpen(ZipFile.java:664)
at java.base/java.util.zip.ZipFile.getInputStream(ZipFile.java:334)
at java.base/java.util.jar.JarFile.getBytes(JarFile.java:761)
at 
java.base/java.util.jar.JarFile.checkForSpecialAttributes(JarFile.java:970)
at java.base/java.util.jar.JarFile.isMultiRelease(JarFile.java:366)
at 
java.base/java.util.jar.JarFile$JarFileEntry.realEntry(JarFile.java:642)
at 
java.base/java.util.jar.JarFile$JarFileEntry.getCertificates(JarFile.java:626)
at 
org.apache.commons.vfs2.provider.jar.JarFileObject.doGetCertificates(JarFileObject.java:120)
at 
org.apache.commons.vfs2.provider.DefaultFileContent.getCertificates(DefaultFileContent.java:325)
... 29 more

testLoadClass(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests)  Time 
elapsed: 0 sec  <<< ERROR!
java.lang.ClassNotFoundException: code.ClassToLoad
at 
org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:152)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:563)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496)
at 
org.apache.commons.vfs2.impl.test.VfsClassLoaderTests.testLoadClass(VfsClassLoaderTests.java:61)
at 

[jira] [Updated] (VFS-645) VfsClassLoaderTests and JarProviderTestCase fails on Java 9

[Gary Gregory (JIRA)]

 [ 
https://issues.apache.org/jira/browse/VFS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory updated VFS-645:
-
Summary: VfsClassLoaderTests and JarProviderTestCase fails on Java 9  (was: 
VfsClassLoaderTests fails on Java 9)

> VfsClassLoaderTests and JarProviderTestCase fails on Java 9
> ---
>
> Key: VFS-645
> URL: https://issues.apache.org/jira/browse/VFS-645
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: Nightly Builds, 2.1, 2.2
> Environment: Apache Maven 3.5.0 
> (ff8f5e7444045639af65f6095c62210b5713f426; 2017-04-03T13:39:06-06:00)
> Maven home: C:\Java\apache-maven-3.5.0\bin\..
> Java version: 9, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk-9
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows"
>Reporter: Gary Gregory
>Priority: Major
>
> Running the build with Oracle Java 9 on Windows 10 fails. The same failures 
> happen with version 2.1.
> {noformat}
> Tests run: 84, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 4.01 sec <<< 
> FAILURE! - in org.apache.commons.vfs2.provider.jar.test.NestedJarTestCase
> testSealing(org.apache.commons.vfs2.impl.test.VfsClassLoaderTests)  Time 
> elapsed: 0 sec  <<< ERROR!
> java.lang.ClassNotFoundException: code.sealed.AnotherClass
> at 
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:152)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:563)
> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:496)
> at 
> org.apache.commons.vfs2.impl.test.VfsClassLoaderTests.testSealing(VfsClassLoaderTests.java:88)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> at 
> org.apache.commons.vfs2.test.AbstractProviderTestCase.runTest(AbstractProviderTestCase.java:190)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
> at 
> org.apache.commons.vfs2.test.AbstractTestSuite$1.protect(AbstractTestSuite.java:132)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at 
> org.apache.commons.vfs2.test.AbstractTestSuite.run(AbstractTestSuite.java:137)
> at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: org.apache.commons.vfs2.FileSystemException: Could not retrieve 
> the certificates of 
> "jar:jar:file:///C:/vcs/svn/apache/commons/trunks-proper/vfs/commons-vfs2/target/test-classes/test-data/nested.jar!/test.jar!/code/sealed/AnotherClass.class".
> at 
> org.apache.commons.vfs2.provider.DefaultFileContent.getCertificates(DefaultFileContent.java:331)
> at 
> org.apache.commons.vfs2.impl.VFSClassLoader.defineClass(VFSClassLoader.java:180)
> at 
> org.apache.commons.vfs2.impl.VFSClassLoader.findClass(VFSClassLoader.java:150)
> ... 27 more
> Caused by: java.lang.IllegalStateException: zip file closed
> at java.base/java.util.zip.ZipFile.ensureOpen(ZipFile.java:664)
> at java.base/java.util.zip.ZipFile.getInputStream(ZipFile.java:334)
> at java.base/java.util.jar.JarFile.getBytes(JarFile.java:761)
> at 
> java.base/java.util.jar.JarFile.checkForSpecialAttributes(JarFile.java:970)
> 

[GitHub] Sam-Kruglov opened a new pull request #398: Add ComparableUtils

[GitBox]

Sam-Kruglov opened a new pull request #398: Add ComparableUtils
URL: https://github.com/apache/commons-lang/pull/398
 
 
   I have turned `feeAmount.compareTo(BigDecimal.ZERO) > 0` into 
`is(feeAmount).greaterThan(BigDecimal.ZERO)` and decided to share.
   
   


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] [Created] (LANG-1431) ComparableUtils

[Sam Kruglov (JIRA)]

Sam Kruglov created LANG-1431:
-

 Summary: ComparableUtils
 Key: LANG-1431
 URL: https://issues.apache.org/jira/browse/LANG-1431
 Project: Commons Lang
  Issue Type: New Feature
  Components: lang.*
Affects Versions: 3.8.1
Reporter: Sam Kruglov


I have turned {{feeAmount.compareTo(BigDecimal.ZERO) > 0}} into 
{{is(feeAmount).greaterThan(BigDecimal.ZERO)}}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (LANG-1430) ExceptionUtils#getRootCause(Throwable t) does not work as documented in javadoc

[Frans Verhoef (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745107#comment-16745107
 ] 

Frans Verhoef commented on LANG-1430:
-

Cause me some work to figure out, as suddenly with version 3.8.1 our code was 
not working anymore, as the contract had changed.

> ExceptionUtils#getRootCause(Throwable t)  does not work as documented in 
> javadoc
> 
>
> Key: LANG-1430
> URL: https://issues.apache.org/jira/browse/LANG-1430
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.exception.*
>Affects Versions: 3.8, 3.8.1
>Reporter: Frans Verhoef
>Priority: Minor
>
> In version 3.8 the following bugfix was introduced:
> LANG-1364: ExceptionUtils#getRootCause(Throwable t) should return t if no 
> lower level cause exists Thanks to Zheng Xie.
> In general I agree with the consistency it brings, but now the javadocs is 
> not agreeing with the way it actually works.
>  
>  
> {code:java}
> /**
> 168 * Introspects the Throwable to obtain the root cause.
> 169 *
> 170 * This method walks through the exception chain to the last element,
> 171 * "root" of the tree, using {@link Throwable#getCause()}, and
> 172 * returns that exception.
> 173 *
> 174 * From version 2.2, this method handles recursive cause structures
> 175 * that might otherwise cause infinite loops. If the throwable parameter
> 176 * has a cause of itself, then null will be returned. If the throwable
> 177 * parameter cause chain loops, the last element in the chain before the
> 178 * loop is returned.
> 179 *
> 180 * @param throwable the throwable to get the root cause for, may be null
> 181 * @return the root cause of the Throwable,
> 182 * null if null throwable input
> 183 */
> {code}
>  
>  
> The sentence at line 175/176 should be something like:
> {code:java}
> If the throwable parameter has a cause of itself, then itself will be 
> returned.{code}
> As the method will not return null, but itself instead, as of the fix 
> LANG-1364



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (LANG-1430) ExceptionUtils#getRootCause(Throwable t) does not work as documented in javadoc

[Frans Verhoef (JIRA)]

[ 
https://issues.apache.org/jira/browse/LANG-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745107#comment-16745107
 ] 

Frans Verhoef edited comment on LANG-1430 at 1/17/19 2:26 PM:
--

Caused me some work to figure out, as suddenly with version 3.8.1 our code was 
not working anymore, as the contract had changed.


was (Author: fverhoef):
Cause me some work to figure out, as suddenly with version 3.8.1 our code was 
not working anymore, as the contract had changed.

> ExceptionUtils#getRootCause(Throwable t)  does not work as documented in 
> javadoc
> 
>
> Key: LANG-1430
> URL: https://issues.apache.org/jira/browse/LANG-1430
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.exception.*
>Affects Versions: 3.8, 3.8.1
>Reporter: Frans Verhoef
>Priority: Minor
>
> In version 3.8 the following bugfix was introduced:
> LANG-1364: ExceptionUtils#getRootCause(Throwable t) should return t if no 
> lower level cause exists Thanks to Zheng Xie.
> In general I agree with the consistency it brings, but now the javadocs is 
> not agreeing with the way it actually works.
>  
>  
> {code:java}
> /**
> 168 * Introspects the Throwable to obtain the root cause.
> 169 *
> 170 * This method walks through the exception chain to the last element,
> 171 * "root" of the tree, using {@link Throwable#getCause()}, and
> 172 * returns that exception.
> 173 *
> 174 * From version 2.2, this method handles recursive cause structures
> 175 * that might otherwise cause infinite loops. If the throwable parameter
> 176 * has a cause of itself, then null will be returned. If the throwable
> 177 * parameter cause chain loops, the last element in the chain before the
> 178 * loop is returned.
> 179 *
> 180 * @param throwable the throwable to get the root cause for, may be null
> 181 * @return the root cause of the Throwable,
> 182 * null if null throwable input
> 183 */
> {code}
>  
>  
> The sentence at line 175/176 should be something like:
> {code:java}
> If the throwable parameter has a cause of itself, then itself will be 
> returned.{code}
> As the method will not return null, but itself instead, as of the fix 
> LANG-1364



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (LANG-1430) ExceptionUtils#getRootCause(Throwable t) does not work as documented in javadoc

[Frans Verhoef (JIRA)]

 [ 
https://issues.apache.org/jira/browse/LANG-1430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Frans Verhoef updated LANG-1430:

Description: 
In version 3.8 the following bugfix was introduced:

LANG-1364: ExceptionUtils#getRootCause(Throwable t) should return t if no lower 
level cause exists Thanks to Zheng Xie.

In general I agree with the consistency it brings, but now the javadocs is not 
agreeing with the way it actually works.

 

 
{code:java}
/**
168 * Introspects the Throwable to obtain the root cause.
169 *
170 * This method walks through the exception chain to the last element,
171 * "root" of the tree, using {@link Throwable#getCause()}, and
172 * returns that exception.
173 *
174 * From version 2.2, this method handles recursive cause structures
175 * that might otherwise cause infinite loops. If the throwable parameter
176 * has a cause of itself, then null will be returned. If the throwable
177 * parameter cause chain loops, the last element in the chain before the
178 * loop is returned.
179 *
180 * @param throwable the throwable to get the root cause for, may be null
181 * @return the root cause of the Throwable,
182 * null if null throwable input
183 */

{code}
 

 

The sentence at line 175/176 should be something like:
{code:java}
If the throwable parameter has a cause of itself, then itself will be 
returned.{code}
As the method will not return null, but itself instead, as of the fix LANG-1364

  was:
In version 3.8 the following bugfix was introduced:

LANG-1364: ExceptionUtils#getRootCause(Throwable t) should return t if no lower 
level cause exists Thanks to Zheng Xie.

In general I agree with the consistency it brings, but now the javadocs is not 
agreeing with the way it actually works.

 

 
{code:java}
/**
168 * Introspects the Throwable to obtain the root cause.
169 *
170 * This method walks through the exception chain to the last element,
171 * "root" of the tree, using {@link Throwable#getCause()}, and
172 * returns that exception.
173 *
174 * From version 2.2, this method handles recursive cause structures
175 * that might otherwise cause infinite loops. If the throwable parameter
176 * has a cause of itself, then null will be returned. If the throwable
177 * parameter cause chain loops, the last element in the chain before the
178 * loop is returned.
179 *
180 * @param throwable the throwable to get the root cause for, may be null
181 * @return the root cause of the Throwable,
182 * null if null throwable input
183 */

{code}
 

 

The sentence in red should be something like:
{code:java}
If the throwable parameter has a cause of itself, then itself will be 
returned.{code}
As the method will not return null, but itself instead, as of the fix LANG-1364


> ExceptionUtils#getRootCause(Throwable t)  does not work as documented in 
> javadoc
> 
>
> Key: LANG-1430
> URL: https://issues.apache.org/jira/browse/LANG-1430
> Project: Commons Lang
>  Issue Type: Bug
>  Components: lang.exception.*
>Affects Versions: 3.8, 3.8.1
>Reporter: Frans Verhoef
>Priority: Minor
>
> In version 3.8 the following bugfix was introduced:
> LANG-1364: ExceptionUtils#getRootCause(Throwable t) should return t if no 
> lower level cause exists Thanks to Zheng Xie.
> In general I agree with the consistency it brings, but now the javadocs is 
> not agreeing with the way it actually works.
>  
>  
> {code:java}
> /**
> 168 * Introspects the Throwable to obtain the root cause.
> 169 *
> 170 * This method walks through the exception chain to the last element,
> 171 * "root" of the tree, using {@link Throwable#getCause()}, and
> 172 * returns that exception.
> 173 *
> 174 * From version 2.2, this method handles recursive cause structures
> 175 * that might otherwise cause infinite loops. If the throwable parameter
> 176 * has a cause of itself, then null will be returned. If the throwable
> 177 * parameter cause chain loops, the last element in the chain before the
> 178 * loop is returned.
> 179 *
> 180 * @param throwable the throwable to get the root cause for, may be null
> 181 * @return the root cause of the Throwable,
> 182 * null if null throwable input
> 183 */
> {code}
>  
>  
> The sentence at line 175/176 should be something like:
> {code:java}
> If the throwable parameter has a cause of itself, then itself will be 
> returned.{code}
> As the method will not return null, but itself instead, as of the fix 
> LANG-1364



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (LANG-1430) ExceptionUtils#getRootCause(Throwable t) does not work as documented in javadoc

[Frans Verhoef (JIRA)]

Frans Verhoef created LANG-1430:
---

 Summary: ExceptionUtils#getRootCause(Throwable t)  does not work 
as documented in javadoc
 Key: LANG-1430
 URL: https://issues.apache.org/jira/browse/LANG-1430
 Project: Commons Lang
  Issue Type: Bug
  Components: lang.exception.*
Affects Versions: 3.8.1, 3.8
Reporter: Frans Verhoef


In version 3.8 the following bugfix was introduced:

LANG-1364: ExceptionUtils#getRootCause(Throwable t) should return t if no lower 
level cause exists Thanks to Zheng Xie.

In general I agree with the consistency it brings, but now the javadocs is not 
agreeing with the way it actually works.

 

 
{code:java}
/**
168 * Introspects the Throwable to obtain the root cause.
169 *
170 * This method walks through the exception chain to the last element,
171 * "root" of the tree, using {@link Throwable#getCause()}, and
172 * returns that exception.
173 *
174 * From version 2.2, this method handles recursive cause structures
175 * that might otherwise cause infinite loops. If the throwable parameter
176 * has a cause of itself, then null will be returned. If the throwable
177 * parameter cause chain loops, the last element in the chain before the
178 * loop is returned.
179 *
180 * @param throwable the throwable to get the root cause for, may be null
181 * @return the root cause of the Throwable,
182 * null if null throwable input
183 */

{code}
 

 

The sentence in red should be something like:
{code:java}
If the throwable parameter has a cause of itself, then itself will be 
returned.{code}
As the method will not return null, but itself instead, as of the fix LANG-1364



--
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

[Otto Fowler (JIRA)]

[ 
https://issues.apache.org/jira/browse/VFS-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16745066#comment-16745066
 ] 

Otto Fowler commented on VFS-398:
-

[~garydgregory] I would like to get this in, and possibly we can talk about a 
release, or other things that we want to land pursuant to a release.  What do 
you think?

> 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)