[jira] [Comment Edited] (NET-405) Support for IPv6 in SubnetUtils
[ https://issues.apache.org/jira/browse/NET-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15906982#comment-15906982 ] Makoto Sakaguchi edited comment on NET-405 at 3/20/17 5:11 AM: --- It was ready for supporting IPv6. https://github.com/apache/commons-net/pull/18 was (Author: umoxfo): It was ready for supporting IPv6. https://github.com/apache/commons-net/pull/18 But, it does not work the existing test cases. > Support for IPv6 in SubnetUtils > --- > > Key: NET-405 > URL: https://issues.apache.org/jira/browse/NET-405 > Project: Commons Net > Issue Type: Improvement >Reporter: Marc Lefrancois > > Currently, we cannot use org.apache.commons.net.util.SubnetUtils with IPv6 > addresses. This class will become less and less useful as more internet > device are only assigned IPv6 addresses since all available IPv4 address > blocks have now been attributed. > http://en.wikipedia.org/wiki/IPv4_address_exhaustion -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (MATH-1405) Kolmogorov-Smirnov fixTies can set minDelta too small for jiggler to have significant effect
[ https://issues.apache.org/jira/browse/MATH-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved MATH-1405. -- Resolution: Fixed > Kolmogorov-Smirnov fixTies can set minDelta too small for jiggler to have > significant effect > > > Key: MATH-1405 > URL: https://issues.apache.org/jira/browse/MATH-1405 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.6.1 >Reporter: Daniil Finkel > > For samples that do not exceed LARGE_SAMPLE_PRODUCT with their product and > relatively large values, a minDelta can be calculated in fixTies() that is > too small to have any effect on the "tied" values. This results in a > MathInternalError, as the jiggling with the ineffective minDelta fails to fix > the ties. > The following arrays exhibit this behavior when run with > kolmogorovSmirnovTest(x, y) in 3.6.1 > x = [1.3750969645841487, 1.0845460746754014, 1.3693352427126644, > 1.329688765445783, 1.3392109491039106, 1.3532766470312723, > 1.3187287426697727, 1.386273031970554, 1.3416950149276097, > 1.0510872606482404, 1.3532766470312723, 1.3075923871137798, > 1.3862730319705543, 1.3814421433922548, 1.0527927570919202, > 1.3847314864464313, 1.319362658529506, 1.3579238253227275, > 1.2455452272301641, 1.329688765445783, 1.3827781646781876, > 1.0755168081687903, 1.2566273460024566, 1.3099622795250825, > 1.357440924560318, 1.3519397370266515, 1.0927347979524134, > 1.3566357346921618, 1.238800036669969, 1.2931730628634528, 1.048463407884969, > 1.3779471642491719, 1.2978533797116658, 1.376230881554943, 1.166901202345226, > 1.3690425182006263, 1.166901202345226, 1.2953476417603207, > 1.0827945761165951, 1.2942406680885112, 1.224414840377028, > 1.3910905417259205, 1.303231085263425, 1.348635183816037, 1.3750969645841487, > 1.049648651501274, 1.3119534979602083, 1.0446033225080773, > 1.0494686631294756, 1.3862026705844126, 1.2719496963348844, > 1.3489938748102903, 1.3780468374004164, 1.3884878389662338, > 1.3352682241994538, 1.3348722240568909, 1.3921944407986777, > 1.0476833161122294, 1.0845460746754008, 1.344165352323966, 1.298548179079665, > 1.1979240079667628, 1.3539078973394736, 1.3187287426697725, > 1.082794576116595, 1.3779471642491719, 1.3771347858434184, > 1.3921944407986777, 1.193793081523992, 1.362050393265006, 1.076638744462226, > 1.3551174562135766, 1.3393693468578751, 1.2470361076952952, > 1.3696023478216113, 1.3750969645841487, 1.2964734722088322, > 1.2953476417603207, 1.2470361076952952, 1.382661263313539, > 1.3862026705844126, 1.3771240109822156, 1.25443884328785, 1.3136690818105938, > 1.3853832858443051, 1.3486351838160378, 1.348026557887345, > 1.0604869883721861, 1.3352682241994536, 1.3480480718535308, > 1.3363233390543028, 1.154658436584056, 1.3921944407986775, > 1.1979240079667626, 1.3620503932650059, 1.0881358731694244, > 1.369042518200626, 1.3532766470312723, 1.2890012831575908, 1.3735565244300663] > and > y = [1.1262991662205104, 1.3136690818105938, 1.0446033225080773, > 1.3551174562135764, 1.3032310852634252, 1.3806258468851462, > 1.227061245983, 1.2719496963348844, 1.3601566259413194, > 1.3756888280688913, 1.3475322202511097, 1.1937930815239919, > 1.0510872606482404, 1.3441653523239654, 1.359738761905118, > 1.3382152957887032, 1.0766387444622263, 1.1937930815239919, > 1.0820779503060238, 1.1448104521200428, 1.3853832858443051, 1.28757746537949, > 1.298548179079665, 1.067255392172351, 1.3168701741293156, 1.3910905417259205, > 1.2908594990421354, 1.3750969645841487, 1.329688765445783, 1.386649365275275, > 1.285486511663053, 1.2566273460024566, 1.323664826995234, 1.3862730319705538, > 1.049346328049449] > which produce minDelta = 1.11022302462516E-016 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (MATH-1402) Incorrect calculation at BigFraction's doubleValue and floatValue
[
https://issues.apache.org/jira/browse/MATH-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles resolved MATH-1402.
--
Resolution: Won't Fix
Code is deprecated (to be replaced by module {{commons-numbers-fraction}} in
new "Commons Numbers" project.
Issue has been [duplicated|https://issues.apache.org/jira/browse/NUMBERS-15]
and fixed there.
> Incorrect calculation at BigFraction's doubleValue and floatValue
> -
>
> Key: MATH-1402
> URL: https://issues.apache.org/jira/browse/MATH-1402
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 4.0, 3.6.1
>Reporter: Sergey Ushakov
>
> h1. Problem
> * BigFraction#doubleValue produces incorrect result "Infinity" when
> numerator's value exceeds primitive double capacity, but denominator not
> * Same relates to floatValue
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (NUMBERS-15) Copy of MATH-1402
[ https://issues.apache.org/jira/browse/NUMBERS-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved NUMBERS-15. --- Resolution: Fixed Commit b37c9f195f28f897eadadaf1f2df86bca0b8ce7c > Copy of MATH-1402 > - > > Key: NUMBERS-15 > URL: https://issues.apache.org/jira/browse/NUMBERS-15 > Project: Commons Numbers > Issue Type: Bug >Reporter: Gilles >Assignee: Gilles >Priority: Minor > Fix For: 1.0 > > > Cf. MATH-1402 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (NUMBERS-15) Copy of MATH-1402
Gilles created NUMBERS-15: - Summary: Copy of MATH-1402 Key: NUMBERS-15 URL: https://issues.apache.org/jira/browse/NUMBERS-15 Project: Commons Numbers Issue Type: Bug Reporter: Gilles Assignee: Gilles Priority: Minor Fix For: 1.0 Cf. MATH-1402 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (TEXT-75) StrTokenizer needs to support access to the token separators
[ https://issues.apache.org/jira/browse/TEXT-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15931796#comment-15931796 ] Pascal Schumacher commented on TEXT-75: --- Issue moved from commons-lang to commons-text because StrTokenizer is deprecated in commons-lang and was moved to commons-text. > StrTokenizer needs to support access to the token separators > > > Key: TEXT-75 > URL: https://issues.apache.org/jira/browse/TEXT-75 > Project: Commons Text > Issue Type: Improvement >Reporter: Stephen Colebourne >Priority: Minor > > With StrTokenizer at present you cannot extract the separators between the > tokens, a feature which is possible with StringTokenizer. > Thus tokenizing "a.b@c.d" using ".@" would return a,b,c,d but you wouldn't > know where the @ was. > This could probably best be part of the API as a lastSeparator() method that > can only be called after next(), returning the separator(s) between that > token and the previous token. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Moved] (TEXT-75) StrTokenizer needs to support access to the token separators
[ https://issues.apache.org/jira/browse/TEXT-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher moved LANG-288 to TEXT-75: Fix Version/s: (was: Patch Needed) Component/s: (was: lang.text.*) Workflow: jira (was: Default workflow, editable Closed status) Key: TEXT-75 (was: LANG-288) Project: Commons Text (was: Commons Lang) > StrTokenizer needs to support access to the token separators > > > Key: TEXT-75 > URL: https://issues.apache.org/jira/browse/TEXT-75 > Project: Commons Text > Issue Type: Improvement >Reporter: Stephen Colebourne >Priority: Minor > > With StrTokenizer at present you cannot extract the separators between the > tokens, a feature which is possible with StringTokenizer. > Thus tokenizing "a.b@c.d" using ".@" would return a,b,c,d but you wouldn't > know where the @ was. > This could probably best be part of the API as a lastSeparator() method that > can only be called after next(), returning the separator(s) between that > token and the previous token. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Moved] (TEXT-74) StrSubstitutor: Ability to turn off substitution in values
[
https://issues.apache.org/jira/browse/TEXT-74?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Schumacher moved LANG-867 to TEXT-74:
Fix Version/s: (was: Patch Needed)
Component/s: (was: lang.text.*)
Workflow: jira (was: Default workflow, editable Closed status)
Key: TEXT-74 (was: LANG-867)
Project: Commons Text (was: Commons Lang)
> StrSubstitutor: Ability to turn off substitution in values
> --
>
> Key: TEXT-74
> URL: https://issues.apache.org/jira/browse/TEXT-74
> Project: Commons Text
> Issue Type: Improvement
>Reporter: Arend v. Reinersdorff
>Priority: Minor
> Labels: features
>
> In StrSubstitutor variable replacement works in a recursive way. And
> currently there's no way to turn this off.
> Why turn it off: I want to replace some variables in a simple template. Some
> of the replacemnt values are arbitrary user input.
> At the moment I escape all dollar signs in the replacement values with "$$".
> This is annoying. Especially as I use one template with variables as a value
> for another variable. Here I have to escape twice.
> Here's some example code. At the moment it prints "Hello world". The
> commented line is my suggestion for this feature. If it works, it should
> print "Hello ${key2}":
> Map valueMap = new HashMap<>();
> valueMap.put("key", "$${key2}");
> valueMap.put("key2", "world");
> String source = "Hello ${key}";
> StrSubstitutor strSubstitutor = new StrSubstitutor(valueMap);
> // strSubstitutor.setEnableSubstitutionInValues(false);
> System.out.println(strSubstitutor.replace(source));
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TEXT-74) StrSubstitutor: Ability to turn off substitution in values
[
https://issues.apache.org/jira/browse/TEXT-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15931793#comment-15931793
]
Pascal Schumacher commented on TEXT-74:
---
Issue moved from commons-lang to commons-text because StrSubstitutor is
deprecated in commons-lang and was moved to commons-text.
> StrSubstitutor: Ability to turn off substitution in values
> --
>
> Key: TEXT-74
> URL: https://issues.apache.org/jira/browse/TEXT-74
> Project: Commons Text
> Issue Type: Improvement
>Reporter: Arend v. Reinersdorff
>Priority: Minor
> Labels: features
>
> In StrSubstitutor variable replacement works in a recursive way. And
> currently there's no way to turn this off.
> Why turn it off: I want to replace some variables in a simple template. Some
> of the replacemnt values are arbitrary user input.
> At the moment I escape all dollar signs in the replacement values with "$$".
> This is annoying. Especially as I use one template with variables as a value
> for another variable. Here I have to escape twice.
> Here's some example code. At the moment it prints "Hello world". The
> commented line is my suggestion for this feature. If it works, it should
> print "Hello ${key2}":
> Map valueMap = new HashMap<>();
> valueMap.put("key", "$${key2}");
> valueMap.put("key2", "world");
> String source = "Hello ${key}";
> StrSubstitutor strSubstitutor = new StrSubstitutor(valueMap);
> // strSubstitutor.setEnableSubstitutionInValues(false);
> System.out.println(strSubstitutor.replace(source));
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TEXT-73) Add Properties support to StrLookup
[
https://issues.apache.org/jira/browse/TEXT-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15931792#comment-15931792
]
Pascal Schumacher commented on TEXT-73:
---
Issue moved from commons-lang to commons-text because StrLoockup is deprecated
in commons-lang and was moved to commons-text.
> Add Properties support to StrLookup
> ---
>
> Key: TEXT-73
> URL: https://issues.apache.org/jira/browse/TEXT-73
> Project: Commons Text
> Issue Type: Improvement
>Reporter: Anthony Whitford
>Priority: Minor
> Attachments: StrLookup.patch, StrLookup.patch
>
>
> Sadly,
> [Properties|http://docs.oracle.com/javase/7/docs/api/java/util/Properties.html]
> implements {{Map}} instead of {{Map}}, so one
> can not use the {{MapStrLookup}}.
> I propose adding a Properties variant. Patch attached.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Moved] (TEXT-73) Add Properties support to StrLookup
[
https://issues.apache.org/jira/browse/TEXT-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Schumacher moved LANG-1179 to TEXT-73:
-
Affects Version/s: (was: 3.4)
Component/s: (was: lang.text.*)
Workflow: jira (was: Default workflow, editable Closed status)
Key: TEXT-73 (was: LANG-1179)
Project: Commons Text (was: Commons Lang)
> Add Properties support to StrLookup
> ---
>
> Key: TEXT-73
> URL: https://issues.apache.org/jira/browse/TEXT-73
> Project: Commons Text
> Issue Type: Improvement
>Reporter: Anthony Whitford
>Priority: Minor
> Attachments: StrLookup.patch, StrLookup.patch
>
>
> Sadly,
> [Properties|http://docs.oracle.com/javase/7/docs/api/java/util/Properties.html]
> implements {{Map}} instead of {{Map}}, so one
> can not use the {{MapStrLookup}}.
> I propose adding a Properties variant. Patch attached.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (LANG-1310) MethodUtils.invokeMethod throws ArrayStoreException if using varargs arguments and smaller types than the method defines
[
https://issues.apache.org/jira/browse/LANG-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Schumacher resolved LANG-1310.
-
Resolution: Fixed
Assignee: Pascal Schumacher
Fix Version/s: 3.6
Thanks for reporting and thanks for the pull request!
> MethodUtils.invokeMethod throws ArrayStoreException if using varargs
> arguments and smaller types than the method defines
>
>
> Key: LANG-1310
> URL: https://issues.apache.org/jira/browse/LANG-1310
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.reflect.*
>Affects Versions: 3.5
>Reporter: Eickvonder
>Assignee: Pascal Schumacher
> Fix For: 3.6
>
>
> Since release 3.5 and due to the changes of LANG-1115 an ArrayStoreException
> occurs on MethodUtils.invokeMethod if using varargs arguments and smaller
> types than the method defines (e.g. int vs long).
> {code}
> @Test
> public void testMethodUtilsInvokeMethodVarArgs () throws Exception {
> MyObject object = new MyObject ();
> MethodUtils.invokeMethod (object, "doSomething", 1);
> }
> public static class MyObject {
> public void doSomething (long... args) {
> System.out.println ("doSomething");
> }
> }
> {code}
> throws
> {code}
> java.lang.ArrayStoreException
> at java.lang.System.arraycopy(Native Method)
> at
> org.apache.commons.lang3.reflect.MethodUtils.getVarArgs(MethodUtils.java:497)
> at
> org.apache.commons.lang3.reflect.MethodUtils.toVarArgs(MethodUtils.java:463)
> at
> org.apache.commons.lang3.reflect.MethodUtils.invokeMethod(MethodUtils.java:234)
> at
> org.apache.commons.lang3.reflect.MethodUtils.invokeMethod(MethodUtils.java:270)
> at
> org.apache.commons.lang3.reflect.MethodUtils.invokeMethod(MethodUtils.java:147)
> {code}
> In 3.4. a NoSuchMethodException had been thrown, but in 3.5 the code now
> finds the matching method but fails then with above exception.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (LANG-1310) MethodUtils.invokeMethod throws ArrayStoreException if using varargs arguments and smaller types than the method defines
[
https://issues.apache.org/jira/browse/LANG-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15931782#comment-15931782
]
ASF GitHub Bot commented on LANG-1310:
--
Github user asfgit closed the pull request at:
https://github.com/apache/commons-lang/pull/256
> MethodUtils.invokeMethod throws ArrayStoreException if using varargs
> arguments and smaller types than the method defines
>
>
> Key: LANG-1310
> URL: https://issues.apache.org/jira/browse/LANG-1310
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.reflect.*
>Affects Versions: 3.5
>Reporter: Eickvonder
>
> Since release 3.5 and due to the changes of LANG-1115 an ArrayStoreException
> occurs on MethodUtils.invokeMethod if using varargs arguments and smaller
> types than the method defines (e.g. int vs long).
> {code}
> @Test
> public void testMethodUtilsInvokeMethodVarArgs () throws Exception {
> MyObject object = new MyObject ();
> MethodUtils.invokeMethod (object, "doSomething", 1);
> }
> public static class MyObject {
> public void doSomething (long... args) {
> System.out.println ("doSomething");
> }
> }
> {code}
> throws
> {code}
> java.lang.ArrayStoreException
> at java.lang.System.arraycopy(Native Method)
> at
> org.apache.commons.lang3.reflect.MethodUtils.getVarArgs(MethodUtils.java:497)
> at
> org.apache.commons.lang3.reflect.MethodUtils.toVarArgs(MethodUtils.java:463)
> at
> org.apache.commons.lang3.reflect.MethodUtils.invokeMethod(MethodUtils.java:234)
> at
> org.apache.commons.lang3.reflect.MethodUtils.invokeMethod(MethodUtils.java:270)
> at
> org.apache.commons.lang3.reflect.MethodUtils.invokeMethod(MethodUtils.java:147)
> {code}
> In 3.4. a NoSuchMethodException had been thrown, but in 3.5 the code now
> finds the matching method but fails then with above exception.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (LANG-1310) MethodUtils.invokeMethod throws ArrayStoreException if using varargs arguments and smaller types than the method defines
[
https://issues.apache.org/jira/browse/LANG-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15931783#comment-15931783
]
ASF GitHub Bot commented on LANG-1310:
--
Github user PascalSchumacher commented on the issue:
https://github.com/apache/commons-lang/pull/256
Thanks! :+1:
> MethodUtils.invokeMethod throws ArrayStoreException if using varargs
> arguments and smaller types than the method defines
>
>
> Key: LANG-1310
> URL: https://issues.apache.org/jira/browse/LANG-1310
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.reflect.*
>Affects Versions: 3.5
>Reporter: Eickvonder
>
> Since release 3.5 and due to the changes of LANG-1115 an ArrayStoreException
> occurs on MethodUtils.invokeMethod if using varargs arguments and smaller
> types than the method defines (e.g. int vs long).
> {code}
> @Test
> public void testMethodUtilsInvokeMethodVarArgs () throws Exception {
> MyObject object = new MyObject ();
> MethodUtils.invokeMethod (object, "doSomething", 1);
> }
> public static class MyObject {
> public void doSomething (long... args) {
> System.out.println ("doSomething");
> }
> }
> {code}
> throws
> {code}
> java.lang.ArrayStoreException
> at java.lang.System.arraycopy(Native Method)
> at
> org.apache.commons.lang3.reflect.MethodUtils.getVarArgs(MethodUtils.java:497)
> at
> org.apache.commons.lang3.reflect.MethodUtils.toVarArgs(MethodUtils.java:463)
> at
> org.apache.commons.lang3.reflect.MethodUtils.invokeMethod(MethodUtils.java:234)
> at
> org.apache.commons.lang3.reflect.MethodUtils.invokeMethod(MethodUtils.java:270)
> at
> org.apache.commons.lang3.reflect.MethodUtils.invokeMethod(MethodUtils.java:147)
> {code}
> In 3.4. a NoSuchMethodException had been thrown, but in 3.5 the code now
> finds the matching method but fails then with above exception.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] commons-lang issue #256: fix for LANG-1310
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/256 Thanks! :+1: --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang pull request #256: fix for LANG-1310
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/256 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Updated] (LANG-1310) MethodUtils.invokeMethod throws ArrayStoreException if using varargs arguments and smaller types than the method defines
[
https://issues.apache.org/jira/browse/LANG-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Schumacher updated LANG-1310:
Summary: MethodUtils.invokeMethod throws ArrayStoreException if using
varargs arguments and smaller types than the method defines (was:
MethodUtils.invokeMethod throws ArrayStoreException)
> MethodUtils.invokeMethod throws ArrayStoreException if using varargs
> arguments and smaller types than the method defines
>
>
> Key: LANG-1310
> URL: https://issues.apache.org/jira/browse/LANG-1310
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.reflect.*
>Affects Versions: 3.5
>Reporter: Eickvonder
>
> Since release 3.5 and due to the changes of LANG-1115 an ArrayStoreException
> occurs on MethodUtils.invokeMethod if using varargs arguments and smaller
> types than the method defines (e.g. int vs long).
> {code}
> @Test
> public void testMethodUtilsInvokeMethodVarArgs () throws Exception {
> MyObject object = new MyObject ();
> MethodUtils.invokeMethod (object, "doSomething", 1);
> }
> public static class MyObject {
> public void doSomething (long... args) {
> System.out.println ("doSomething");
> }
> }
> {code}
> throws
> {code}
> java.lang.ArrayStoreException
> at java.lang.System.arraycopy(Native Method)
> at
> org.apache.commons.lang3.reflect.MethodUtils.getVarArgs(MethodUtils.java:497)
> at
> org.apache.commons.lang3.reflect.MethodUtils.toVarArgs(MethodUtils.java:463)
> at
> org.apache.commons.lang3.reflect.MethodUtils.invokeMethod(MethodUtils.java:234)
> at
> org.apache.commons.lang3.reflect.MethodUtils.invokeMethod(MethodUtils.java:270)
> at
> org.apache.commons.lang3.reflect.MethodUtils.invokeMethod(MethodUtils.java:147)
> {code}
> In 3.4. a NoSuchMethodException had been thrown, but in 3.5 the code now
> finds the matching method but fails then with above exception.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CSV-203) withNullString value is printed without quotes when QuoteMode.ALL is specified
[
https://issues.apache.org/jira/browse/CSV-203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15931720#comment-15931720
]
Kai Paroth commented on CSV-203:
My Pull-Request: https://github.com/apache/commons-csv/pull/17
> withNullString value is printed without quotes when QuoteMode.ALL is specified
> --
>
> Key: CSV-203
> URL: https://issues.apache.org/jira/browse/CSV-203
> Project: Commons CSV
> Issue Type: Bug
> Components: Printer
>Affects Versions: 1.3, 1.4
>Reporter: Richard Wheeldon
> Labels: regression
>
> When setting QuoteMode.ALL is set we expect all values to be quoted, even
> those set as a default. This works in Commons 1.2 but doesn't in 1.4.
> Consider the following program:
> {code}
> import org.apache.commons.csv.QuoteMode;
> import org.apache.commons.csv.CSVFormat;
> import org.apache.commons.csv.CSVPrinter;
> public class CommonsCsvIsSlightlyBroken {
>
> public static void main(String[] args) throws Exception {
> CSVFormat format = CSVFormat.EXCEL
> .withNullString("N/A")
> .withIgnoreSurroundingSpaces(true)
> .withQuoteMode(QuoteMode.ALL);
> CSVPrinter printer = new CSVPrinter(System.out, format);
> printer.printRecord(new Object[] { null, "Hello", null, "World" });
> }
> }
> {code}
> For 1.2 we get quoted output:
> {code}
> richard@kichemaru:~/$ java -cp
> ~/.m2/repository/org/apache/commons/commons-csv/1.2/commons-csv-1.2.jar:.
> CommonsCsvIsSlightlyBroken
> "N/A","Hello","N/A","World"
> {code}
> When run with 1.4 we get unquoted output for default fields:
> {code}
> richard@kichemaru:~/$ java -cp
> ~/.m2/repository/org/apache/commons/commons-csv/1.4/commons-csv-1.4.jar:.
> CommonsCsvIsSlightlyBroken
> N/A,"Hello",N/A,"World"
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (LANG-1269) Wrong name or result of StringUtils::getJaroWinklerDistance
[
https://issues.apache.org/jira/browse/LANG-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Schumacher closed LANG-1269.
---
Resolution: Won't Fix
I reverted the addition of StringUtils#getJaroWinklerSimilarity in
https://github.com/apache/commons-lang/commit/f4ee399e31eb61741f5f2167d6af8f49c0e991b6
because all string distance methods of commons-lang are now deprecated in
favor of commons-text.
> Wrong name or result of StringUtils::getJaroWinklerDistance
> ---
>
> Key: LANG-1269
> URL: https://issues.apache.org/jira/browse/LANG-1269
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.3, 3.4, 3.5
>Reporter: Jan Martin Keil
>Assignee: Pascal Schumacher
>Priority: Minor
>
> The name of the method StringUtils::getJaroWinklerDistance is misleading.
> Currently for equal strings {{1}} is returned, for completely different
> strings {{0}} is returned. That is a measure of similarity, not of a
> distance. A distance must be {{0}} for equal strings. I read on the issues
> LANG-591 and LANG-944, that it was decided to have a similar name to
> StringUtils::getLevenshteinDistance, but that requires also the change of the
> methods result.
> Could you please (1) rename the method to
> StringUtils::getJaroWinklerSimilarity or (2) change the method to return {{1
> - currentResult}}?
> First option has the disadvantage to lose the similar naming of the similar
> methods, second option implies the risk to unnoticed introduce bugs in
> depending code. So I think it is preferable to use the first option.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (LANG-1269) Wrong name or result of StringUtils::getJaroWinklerDistance
[
https://issues.apache.org/jira/browse/LANG-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Schumacher updated LANG-1269:
Fix Version/s: (was: 3.6)
> Wrong name or result of StringUtils::getJaroWinklerDistance
> ---
>
> Key: LANG-1269
> URL: https://issues.apache.org/jira/browse/LANG-1269
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.3, 3.4, 3.5
>Reporter: Jan Martin Keil
>Assignee: Pascal Schumacher
>Priority: Minor
>
> The name of the method StringUtils::getJaroWinklerDistance is misleading.
> Currently for equal strings {{1}} is returned, for completely different
> strings {{0}} is returned. That is a measure of similarity, not of a
> distance. A distance must be {{0}} for equal strings. I read on the issues
> LANG-591 and LANG-944, that it was decided to have a similar name to
> StringUtils::getLevenshteinDistance, but that requires also the change of the
> methods result.
> Could you please (1) rename the method to
> StringUtils::getJaroWinklerSimilarity or (2) change the method to return {{1
> - currentResult}}?
> First option has the disadvantage to lose the similar naming of the similar
> methods, second option implies the risk to unnoticed introduce bugs in
> depending code. So I think it is preferable to use the first option.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (LANG-1269) Wrong name or result of StringUtils::getJaroWinklerDistance
[
https://issues.apache.org/jira/browse/LANG-1269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Schumacher reopened LANG-1269:
-
> Wrong name or result of StringUtils::getJaroWinklerDistance
> ---
>
> Key: LANG-1269
> URL: https://issues.apache.org/jira/browse/LANG-1269
> Project: Commons Lang
> Issue Type: Bug
>Affects Versions: 3.3, 3.4, 3.5
>Reporter: Jan Martin Keil
>Assignee: Pascal Schumacher
>Priority: Minor
> Fix For: 3.6
>
>
> The name of the method StringUtils::getJaroWinklerDistance is misleading.
> Currently for equal strings {{1}} is returned, for completely different
> strings {{0}} is returned. That is a measure of similarity, not of a
> distance. A distance must be {{0}} for equal strings. I read on the issues
> LANG-591 and LANG-944, that it was decided to have a similar name to
> StringUtils::getLevenshteinDistance, but that requires also the change of the
> methods result.
> Could you please (1) rename the method to
> StringUtils::getJaroWinklerSimilarity or (2) change the method to return {{1
> - currentResult}}?
> First option has the disadvantage to lose the similar naming of the similar
> methods, second option implies the risk to unnoticed introduce bugs in
> depending code. So I think it is preferable to use the first option.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (TEXT-22) LevenshteinDistance reduce memory consumption
[ https://issues.apache.org/jira/browse/TEXT-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher closed TEXT-22. - Resolution: Fixed > LevenshteinDistance reduce memory consumption > - > > Key: TEXT-22 > URL: https://issues.apache.org/jira/browse/TEXT-22 > Project: Commons Text > Issue Type: Improvement >Reporter: Pascal Schumacher >Assignee: Rob Tompkins > Fix For: 1.0 > > > Reduce the memory consumption LevenshteinDistance by adopting this change: > https://github.com/apache/commons-lang/commit/103b64a373256feae6ca85f2bf220e7694e48fa4 > done for [LANG-1277]. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (TEXT-22) LevenshteinDistance reduce memory consumption
[ https://issues.apache.org/jira/browse/TEXT-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher updated TEXT-22: -- Fix Version/s: (was: 1.x) 1.0 > LevenshteinDistance reduce memory consumption > - > > Key: TEXT-22 > URL: https://issues.apache.org/jira/browse/TEXT-22 > Project: Commons Text > Issue Type: Improvement >Reporter: Pascal Schumacher >Assignee: Rob Tompkins > Fix For: 1.0 > > > Reduce the memory consumption LevenshteinDistance by adopting this change: > https://github.com/apache/commons-lang/commit/103b64a373256feae6ca85f2bf220e7694e48fa4 > done for [LANG-1277]. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (TEXT-22) LevenshteinDistance reduce memory consumption
[ https://issues.apache.org/jira/browse/TEXT-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher reopened TEXT-22: --- > LevenshteinDistance reduce memory consumption > - > > Key: TEXT-22 > URL: https://issues.apache.org/jira/browse/TEXT-22 > Project: Commons Text > Issue Type: Improvement >Reporter: Pascal Schumacher >Assignee: Rob Tompkins > Fix For: 1.0 > > > Reduce the memory consumption LevenshteinDistance by adopting this change: > https://github.com/apache/commons-lang/commit/103b64a373256feae6ca85f2bf220e7694e48fa4 > done for [LANG-1277]. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (LANG-1301) Moving apache-rat-plugin configuration into pluginManagement
[
https://issues.apache.org/jira/browse/LANG-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Schumacher resolved LANG-1301.
-
Resolution: Fixed
> Moving apache-rat-plugin configuration into pluginManagement
>
>
> Key: LANG-1301
> URL: https://issues.apache.org/jira/browse/LANG-1301
> Project: Commons Lang
> Issue Type: Improvement
> Components: General
>Affects Versions: 3.5
>Reporter: Karl Heinz Marbaise
>Assignee: Pascal Schumacher
>Priority: Minor
> Fix For: 3.6
>
> Attachments: apache-rat.patch
>
>
> Currently the configuration for the {{apache-rat-plugin}} is done in the
> reporting area which results in not being taken if you call {{mvn
> apache-rat:check}}. This can simply being solved by moving this into a
> {{pluginManagement}} area which will be used for both command line calling a
> goal or running during the life cycle.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (LANG-1316) Deprecate classes/methods moved to commons-text
[ https://issues.apache.org/jira/browse/LANG-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher resolved LANG-1316. - Resolution: Fixed > Deprecate classes/methods moved to commons-text > --- > > Key: LANG-1316 > URL: https://issues.apache.org/jira/browse/LANG-1316 > Project: Commons Lang > Issue Type: Task >Reporter: Pascal Schumacher >Assignee: Pascal Schumacher > Fix For: 3.6 > > > Deprecate classes/methods moved to commons-text: > * org.apache.commons.lang3.text.translate - every class > * org.apache.commons.lang3.text - every class beside WordUtils (WordUtils is > not in commons-text 1.0) > * StringEscapeUtils - whole class > * StringUtils: getLevenshteinDistance, getFuzzyDistance and > getJaroWinklerSimilarity methods > * ObjectUtils: identityToString(final StrBuilder builder, final Object > object) method (StrBuilder was moved to commons-text) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (LANG-1316) Deprecate classes/methods moved to commons-text
[ https://issues.apache.org/jira/browse/LANG-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15931661#comment-15931661 ] ASF GitHub Bot commented on LANG-1316: -- Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/255 > Deprecate classes/methods moved to commons-text > --- > > Key: LANG-1316 > URL: https://issues.apache.org/jira/browse/LANG-1316 > Project: Commons Lang > Issue Type: Task >Reporter: Pascal Schumacher >Assignee: Pascal Schumacher > Fix For: 3.6 > > > Deprecate classes/methods moved to commons-text: > * org.apache.commons.lang3.text.translate - every class > * org.apache.commons.lang3.text - every class beside WordUtils (WordUtils is > not in commons-text 1.0) > * StringEscapeUtils - whole class > * StringUtils: getLevenshteinDistance, getFuzzyDistance and > getJaroWinklerSimilarity methods > * ObjectUtils: identityToString(final StrBuilder builder, final Object > object) method (StrBuilder was moved to commons-text) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] commons-lang pull request #255: LANG-1316: Deprecate classes/methods moved t...
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/255 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (LANG-1316) Deprecate classes/methods moved to commons-text
[ https://issues.apache.org/jira/browse/LANG-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15931654#comment-15931654 ] ASF GitHub Bot commented on LANG-1316: -- Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/255 [](https://coveralls.io/builds/10666891) Coverage remained the same at 94.548% when pulling **88a8f9727f04469f9a4426e814393592c6b5119d on PascalSchumacher:deprecated_classes_methods_move_to_commons_text** into **9aea44aceaada5ac9fb1b1c774e8f56a6f815f2c on apache:master**. > Deprecate classes/methods moved to commons-text > --- > > Key: LANG-1316 > URL: https://issues.apache.org/jira/browse/LANG-1316 > Project: Commons Lang > Issue Type: Task >Reporter: Pascal Schumacher >Assignee: Pascal Schumacher > Fix For: 3.6 > > > Deprecate classes/methods moved to commons-text: > * org.apache.commons.lang3.text.translate - every class > * org.apache.commons.lang3.text - every class beside WordUtils (WordUtils is > not in commons-text 1.0) > * StringEscapeUtils - whole class > * StringUtils: getLevenshteinDistance, getFuzzyDistance and > getJaroWinklerSimilarity methods > * ObjectUtils: identityToString(final StrBuilder builder, final Object > object) method (StrBuilder was moved to commons-text) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (LANG-1316) Deprecate classes/methods moved to commons-text
[ https://issues.apache.org/jira/browse/LANG-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15931655#comment-15931655 ] ASF GitHub Bot commented on LANG-1316: -- Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/255 [](https://coveralls.io/builds/10666891) Coverage remained the same at 94.548% when pulling **88a8f9727f04469f9a4426e814393592c6b5119d on PascalSchumacher:deprecated_classes_methods_move_to_commons_text** into **9aea44aceaada5ac9fb1b1c774e8f56a6f815f2c on apache:master**. > Deprecate classes/methods moved to commons-text > --- > > Key: LANG-1316 > URL: https://issues.apache.org/jira/browse/LANG-1316 > Project: Commons Lang > Issue Type: Task >Reporter: Pascal Schumacher >Assignee: Pascal Schumacher > Fix For: 3.6 > > > Deprecate classes/methods moved to commons-text: > * org.apache.commons.lang3.text.translate - every class > * org.apache.commons.lang3.text - every class beside WordUtils (WordUtils is > not in commons-text 1.0) > * StringEscapeUtils - whole class > * StringUtils: getLevenshteinDistance, getFuzzyDistance and > getJaroWinklerSimilarity methods > * ObjectUtils: identityToString(final StrBuilder builder, final Object > object) method (StrBuilder was moved to commons-text) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] commons-lang issue #255: LANG-1316: Deprecate classes/methods moved to commo...
Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/255 [](https://coveralls.io/builds/10666891) Coverage remained the same at 94.548% when pulling **88a8f9727f04469f9a4426e814393592c6b5119d on PascalSchumacher:deprecated_classes_methods_move_to_commons_text** into **9aea44aceaada5ac9fb1b1c774e8f56a6f815f2c on apache:master**. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang issue #255: LANG-1316: Deprecate classes/methods moved to commo...
Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/255 [](https://coveralls.io/builds/10666891) Coverage remained the same at 94.548% when pulling **88a8f9727f04469f9a4426e814393592c6b5119d on PascalSchumacher:deprecated_classes_methods_move_to_commons_text** into **9aea44aceaada5ac9fb1b1c774e8f56a6f815f2c on apache:master**. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (VFS-630) Sftp code assumes that exec channels are available and *nix server
[ https://issues.apache.org/jira/browse/VFS-630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15931624#comment-15931624 ] Gary Gregory commented on VFS-630: -- Patches welcome! > Sftp code assumes that exec channels are available and *nix server > -- > > Key: VFS-630 > URL: https://issues.apache.org/jira/browse/VFS-630 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.1 > Environment: Any client running VFS 2.1/JSch 1.51 and later using > remote sftp server that's locked down or not *nix based. >Reporter: Will Wood >Priority: Minor > > In working with VFS using SFTP there's an assumption in the code that creates > a problem if the remote server is locked down or it's not *nix based. I hit > this when working with a server that had exec commands disabled and > attempting to do a moveTo command on a remote file object renaming it to the > same server as a remote file object. At one point the VFS code attempts to > execute an "id -G" command on a JSch "exec" channel. Since the remote server > disallows the exec command the subsequent read from the input stream blocks > until the O/S default socket timeout occurs, it basically hangs. > I tested this same scenario against a Linux server, it worked fine. I also > tested a Windows server which doesn't have an id command, it failed. > Since JSch deals with this natively, I would recommend getting rid of the > exec commands altogether and letting the client deal with those issues > outside of the framework, i.e., moveTo in this case doesn't need to worry > about permissions but rather throws the underlying exceptions from JSch. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] commons-lang pull request #257: Apply checkstyle to test sources
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/257 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang issue #257: Apply checkstyle to test sources
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/257 Required changes seem reasonable. I think we should give this a try. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Closed] (VFS-632) Update from JCraft jsch for SFTP/SSH from 0.1.53 to 0.1.54
[
https://issues.apache.org/jira/browse/VFS-632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed VFS-632.
Resolution: Fixed
In SVN trunk.
{noformat}
commit -m "[VFS-632] Update from JCraft jsch for SFTP/SSH from 0.1.53 to
0.1.54. Local build OK (mvn clean install)" -N
C:/vcs/svn/apache/commons/trunks-proper/vfs/src/changes/changes.xml
C:/vcs/svn/apache/commons/trunks-proper/vfs/pom.xml
SendingC:/vcs/svn/apache/commons/trunks-proper/vfs/pom.xml
Sending
C:/vcs/svn/apache/commons/trunks-proper/vfs/src/changes/changes.xml
Transmitting file data ...
Unknown action received: commit finalizing
Committed revision 1787596.
{noformat}
> Update from JCraft jsch for SFTP/SSH from 0.1.53 to 0.1.54
> --
>
> Key: VFS-632
> URL: https://issues.apache.org/jira/browse/VFS-632
> Project: Commons VFS
> Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>
> Update from JCraft jsch for SSH from 0.1.53 to 0.1.54
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (VFS-632) Update from JCraft jsch for SFTP/SSH from 0.1.53 to 0.1.54
[ https://issues.apache.org/jira/browse/VFS-632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated VFS-632: - Summary: Update from JCraft jsch for SFTP/SSH from 0.1.53 to 0.1.54 (was: Update from JCraft jsch for SSH from 0.1.53 to 0.1.54) > Update from JCraft jsch for SFTP/SSH from 0.1.53 to 0.1.54 > -- > > Key: VFS-632 > URL: https://issues.apache.org/jira/browse/VFS-632 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Gary Gregory >Assignee: Gary Gregory > > Update from JCraft jsch for SSH from 0.1.53 to 0.1.54 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (VFS-632) Update from JCraft jsch for SSH from 0.1.53 to 0.1.54
Gary Gregory created VFS-632: Summary: Update from JCraft jsch for SSH from 0.1.53 to 0.1.54 Key: VFS-632 URL: https://issues.apache.org/jira/browse/VFS-632 Project: Commons VFS Issue Type: Improvement Affects Versions: 2.1 Reporter: Gary Gregory Assignee: Gary Gregory Update from JCraft jsch for SSH from 0.1.53 to 0.1.54 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (VFS-631) Update from Apache Commons Net 3.5 to 3.6
[ https://issues.apache.org/jira/browse/VFS-631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed VFS-631. Resolution: Fixed In Svn trunk. > Update from Apache Commons Net 3.5 to 3.6 > - > > Key: VFS-631 > URL: https://issues.apache.org/jira/browse/VFS-631 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Gary Gregory >Assignee: Gary Gregory > > Update from Apache Commons Net 3.5 to 3.6. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (VFS-631) Update from Apache Commons Net 3.5 to 3.6
Gary Gregory created VFS-631: Summary: Update from Apache Commons Net 3.5 to 3.6 Key: VFS-631 URL: https://issues.apache.org/jira/browse/VFS-631 Project: Commons VFS Issue Type: Improvement Affects Versions: 2.1 Reporter: Gary Gregory Assignee: Gary Gregory Update from Apache Commons Net 3.5 to 3.6. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (VFS-620) FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP
[
https://issues.apache.org/jira/browse/VFS-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved VFS-620.
--
Resolution: Fixed
Fix Version/s: 2.2
Please verify and close.
{noformat}
commit -m "[VFS-620] FileObject.moveTo(FileObject) API doesn't work well for a
Linux FTP." -N
C:/vcs/svn/apache/commons/trunks-proper/vfs/core/src/main/java/org/apache/commons/vfs2/provider/ftp/FtpFileObject.java
C:/vcs/svn/apache/commons/trunks-proper/vfs/src/changes/changes.xml
C:/vcs/svn/apache/commons/trunks-proper/vfs/core/src/test/java/org/apache/commons/vfs2/provider/ftp/test/FtpProviderTestCase.java
C:/vcs/svn/apache/commons/trunks-proper/vfs/core/src/test/java/org/apache/commons/vfs2/provider/ftp/test/FtpProviderUserDirTestCase.java
C:/vcs/svn/apache/commons/trunks-proper/vfs/core/src/test/java/org/apache/commons/vfs2/provider/ftp/test/MultipleConnectionTestCase.java
Sending
C:/vcs/svn/apache/commons/trunks-proper/vfs/core/src/main/java/org/apache/commons/vfs2/provider/ftp/FtpFileObject.java
Sending
C:/vcs/svn/apache/commons/trunks-proper/vfs/core/src/test/java/org/apache/commons/vfs2/provider/ftp/test/FtpProviderTestCase.java
Adding
C:/vcs/svn/apache/commons/trunks-proper/vfs/core/src/test/java/org/apache/commons/vfs2/provider/ftp/test/FtpProviderUserDirTestCase.java
Sending
C:/vcs/svn/apache/commons/trunks-proper/vfs/core/src/test/java/org/apache/commons/vfs2/provider/ftp/test/MultipleConnectionTestCase.java
Sending
C:/vcs/svn/apache/commons/trunks-proper/vfs/src/changes/changes.xml
Transmitting file data ...
Unknown action received: commit finalizing
Committed revision 1787594.
{noformat}
I applied the patch with one small change to formatting.
> FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP
> ---
>
> Key: VFS-620
> URL: https://issues.apache.org/jira/browse/VFS-620
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: ubuntu vsftpd
>Reporter: stevezhuang
> Fix For: 2.2
>
> Attachments: VFS-620c.patch
>
>
> FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP,
> especially for setting a user directory as its root directory case,
> For example, for a ubuntu vsftpd, which is having "/home/user1" as its root
> directory, when renaming "/test/test.txt" to "/test1/test1.txt", it will
> throw an exception.
> In this case, it should consider the workingDirectory(would be "/home/user1")
> together and append it to the from/to path to make the API work.
> Sample codes,
> {code:java}
> FileObject fileObject = null;
> FileObject toFileObject = null;
> try {
> StandardFileSystemManager fsManager = new
> StandardFileSystemManager();
> fsManager.init();
> FileSystemOptions fsOpts = new FileSystemOptions();
> FtpFileSystemConfigBuilder.getInstance().setPassiveMode(fsOpts,
> true);
> FtpFileSystemConfigBuilder.getInstance().setUserDirIsRoot(fsOpts,
> true);
> UserAuthenticator auth = new StaticUserAuthenticator(null,
> "", "");
>
> DefaultFileSystemConfigBuilder.getInstance().setUserAuthenticator(fsOpts,
> auth);
> fileObject = fsManager.resolveFile("ftp:// address>/test/test.txt", fsOpts);
> System.out.println("File exists:" + fileObject.exists());
> toFileObject = fsManager.resolveFile("ftp:// address>/test1/test1.txt", fsOpts);
> System.out.println("File exists:" + toFileObject.exists());
> if (!toFileObject.exists()) {
> toFileObject.createFile();
> }
> fileObject.moveTo(toFileObject);
> } catch (FileSystemException ex) {
> ex.printStackTrace();
> } finally {
> if (fileObject != null) {
> try {
> fileObject.close();
> } catch (FileSystemException ex) {
> }
> }
> if (toFileObject != null) {
> try {
> toFileObject.close();
> } catch (FileSystemException ex) {
> }
> }
> }
> {code}
> And the output,
> {noformat}
> File exists:true
> File exists:false
> org.apache.commons.vfs2.FileSystemException: Could not rename
> "ftp:///test/test.txt" to "ftp:// address>/test1/test1.txt".
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1902)
> at TestFTP.main(TestFTP.java:59)
> Caused by: org.apache.commons.vfs2.FileSystemException: Could not rename FTP
> file "ftp:///test/test.txt" to "ftp:// address>/test1/test1.txt".
> at
>
[jira] [Updated] (VFS-620) FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP
[
https://issues.apache.org/jira/browse/VFS-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated VFS-620:
-
Description:
FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP, especially
for setting a user directory as its root directory case,
For example, for a ubuntu vsftpd, which is having "/home/user1" as its root
directory, when renaming "/test/test.txt" to "/test1/test1.txt", it will throw
an exception.
In this case, it should consider the workingDirectory(would be "/home/user1")
together and append it to the from/to path to make the API work.
Sample codes,
{code:java}
FileObject fileObject = null;
FileObject toFileObject = null;
try {
StandardFileSystemManager fsManager = new
StandardFileSystemManager();
fsManager.init();
FileSystemOptions fsOpts = new FileSystemOptions();
FtpFileSystemConfigBuilder.getInstance().setPassiveMode(fsOpts,
true);
FtpFileSystemConfigBuilder.getInstance().setUserDirIsRoot(fsOpts,
true);
UserAuthenticator auth = new StaticUserAuthenticator(null,
"", "");
DefaultFileSystemConfigBuilder.getInstance().setUserAuthenticator(fsOpts, auth);
fileObject = fsManager.resolveFile("ftp:///test/test.txt", fsOpts);
System.out.println("File exists:" + fileObject.exists());
toFileObject = fsManager.resolveFile("ftp:///test1/test1.txt", fsOpts);
System.out.println("File exists:" + toFileObject.exists());
if (!toFileObject.exists()) {
toFileObject.createFile();
}
fileObject.moveTo(toFileObject);
} catch (FileSystemException ex) {
ex.printStackTrace();
} finally {
if (fileObject != null) {
try {
fileObject.close();
} catch (FileSystemException ex) {
}
}
if (toFileObject != null) {
try {
toFileObject.close();
} catch (FileSystemException ex) {
}
}
}
{code}
And the output,
{noformat}
File exists:true
File exists:false
org.apache.commons.vfs2.FileSystemException: Could not rename "ftp:///test/test.txt" to "ftp:///test1/test1.txt".
at
org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1902)
at TestFTP.main(TestFTP.java:59)
Caused by: org.apache.commons.vfs2.FileSystemException: Could not rename FTP
file "ftp:///test/test.txt" to "ftp:///test1/test1.txt".
at
org.apache.commons.vfs2.provider.ftp.FtpFileObject.doRename(FtpFileObject.java:524)
at
org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1887)
{noformat}
was:
FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP, especially
for setting a user directory as its root directory case,
For example, for a ubuntu vsftpd, which is having "/home/user1" as its root
directory, when renaming "/test/test.txt" to "/test1/test1.txt", it will throw
an exception.
In this case, it should consider the workingDirectory(would be "/home/user1")
together and append it to the from/to path to make the API work.
Sample codes,
FileObject fileObject = null;
FileObject toFileObject = null;
try {
StandardFileSystemManager fsManager = new
StandardFileSystemManager();
fsManager.init();
FileSystemOptions fsOpts = new FileSystemOptions();
FtpFileSystemConfigBuilder.getInstance().setPassiveMode(fsOpts,
true);
FtpFileSystemConfigBuilder.getInstance().setUserDirIsRoot(fsOpts,
true);
UserAuthenticator auth = new StaticUserAuthenticator(null,
"", "");
DefaultFileSystemConfigBuilder.getInstance().setUserAuthenticator(fsOpts, auth);
fileObject = fsManager.resolveFile("ftp:///test/test.txt", fsOpts);
System.out.println("File exists:" + fileObject.exists());
toFileObject = fsManager.resolveFile("ftp:///test1/test1.txt", fsOpts);
System.out.println("File exists:" + toFileObject.exists());
if (!toFileObject.exists()) {
toFileObject.createFile();
}
fileObject.moveTo(toFileObject);
} catch (FileSystemException ex) {
ex.printStackTrace();
} finally {
if (fileObject != null) {
try {
fileObject.close();
} catch (FileSystemException ex) {
}
}
if (toFileObject != null) {
try {
toFileObject.close();
} catch (FileSystemException ex) {
}
}
}
And the output,
File exists:true
File exists:false
org.apache.commons.vfs2.FileSystemException:
