[GitHub] commons-lang issue #251: LANG-1300: Change CharSequenceUtils to support supp...
Github user MarkDacek commented on the issue: https://github.com/apache/commons-lang/pull/251 Chiming in here. I'd recommend using code units so that it's compatible with the other operations like substring. Of course, this would still break if you called substring(index+1) since you'd be taking the second byte of a supplementary character, but I'd still argue that this is the path to take. --- 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-1300) Clarify or improve behaviour of int-based methods in StringUtils
[
https://issues.apache.org/jira/browse/LANG-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15925396#comment-15925396
]
ASF GitHub Bot commented on LANG-1300:
--
Github user MarkDacek commented on the issue:
https://github.com/apache/commons-lang/pull/251
Chiming in here. I'd recommend using code units so that it's compatible
with the other operations like substring. Of course, this would still break if
you called substring(index+1) since you'd be taking the second byte of a
supplementary character, but I'd still argue that this is the path to take.
> Clarify or improve behaviour of int-based methods in StringUtils
>
>
> Key: LANG-1300
> URL: https://issues.apache.org/jira/browse/LANG-1300
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.5
>Reporter: Duncan Jones
>Priority: Minor
> Fix For: Discussion
>
>
> The following methods use an {{int}} to represent a search character:
> {code:java}
> boolean contains(final CharSequence seq, final int searchChar)
> int indexOf(final CharSequence seq, final int searchChar)
> int indexOf(final CharSequence seq, final int searchChar, final int startPos)
> int lastIndexOf(final CharSequence seq, final int searchChar)
> int lastIndexOf(final CharSequence seq, final int searchChar, final int
> startPos)
> {code}
> When I see an {{int}} representing a character, I tend to assume the method
> can handle supplementary characters. However, the current behaviour of these
> methods depends upon whether the {{CharSequence}} is a {{String}} or not.
> {code:java}
> StringBuilder builder = new StringBuilder();
> builder.appendCodePoint(0x2070E);
> System.out.println(StringUtils.lastIndexOf(builder, 0x2070E)); // -1
> System.out.println(StringUtils.lastIndexOf(builder.toString(), 0x2070E)); // 0
> {code}
> The Javadoc for these methods are ambiguous on this point, stating:
> {quote}
> This method uses {{String.lastIndexOf(int)}} if possible.
> {quote}
> I think we should consider updating the {{CharSequenceUtils}} methods used by
> this class to convert all {{CharSequence}} parameters to strings, enabling
> full code point support. The docs could be updated to make this crystal clear.
> There is a question of whether this breaks backwards compatibility.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CODEC-228) URLCodec.decode does not throw DecoderException with invalid UTF-8
Andrew Gaul created CODEC-228:
-
Summary: URLCodec.decode does not throw DecoderException with
invalid UTF-8
Key: CODEC-228
URL: https://issues.apache.org/jira/browse/CODEC-228
Project: Commons Codec
Issue Type: Bug
Affects Versions: 1.10
Reporter: Andrew Gaul
I expect the following to throw {{DecoderException}}:
{code:java}
new URLCodec().decode("%AE%8A-", "UTF-8");
{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (CSV-186) SIte archives archive links don't work
[ https://issues.apache.org/jira/browse/CSV-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb closed CSV-186. > SIte archives archive links don't work > -- > > Key: CSV-186 > URL: https://issues.apache.org/jira/browse/CSV-186 > Project: Commons CSV > Issue Type: Bug >Reporter: Sebb > > The site has links to archives of previous sites which are stored under > archives/1.x > These in turn have links to earlier archives; however these are relative > links so they don't work. > Maybe there is a way to redirect the links to avoid having to edit the pages. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (CSV-186) SIte archives archive links don't work
[ https://issues.apache.org/jira/browse/CSV-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CSV-186. -- Resolution: Fixed URL: http://svn.apache.org/viewvc?rev=1786966=rev Log: CSV-186 - Fix broken relative links for archive sites Modified: commons/cms-site/trunk/content/resources/.htaccess > SIte archives archive links don't work > -- > > Key: CSV-186 > URL: https://issues.apache.org/jira/browse/CSV-186 > Project: Commons CSV > Issue Type: Bug >Reporter: Sebb > > The site has links to archives of previous sites which are stored under > archives/1.x > These in turn have links to earlier archives; however these are relative > links so they don't work. > Maybe there is a way to redirect the links to avoid having to edit the pages. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (LANG-1310) MethodUtils.invokeMethod throws ArrayStoreException
[
https://issues.apache.org/jira/browse/LANG-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15925014#comment-15925014
]
ASF GitHub Bot commented on LANG-1310:
--
Github user Abrasha commented on a diff in the pull request:
https://github.com/apache/commons-lang/pull/256#discussion_r106028522
--- Diff:
src/test/java/org/apache/commons/lang3/reflect/MethodUtilsTest.java ---
@@ -357,16 +369,23 @@ public void testInvokeMethod() throws Exception {
assertEquals("foo(int)", MethodUtils.invokeMethod(testBean, "foo",
NumberUtils.BYTE_ONE));
assertEquals("foo(double)", MethodUtils.invokeMethod(testBean,
"foo",
-NumberUtils.LONG_ONE));
-assertEquals("foo(double)", MethodUtils.invokeMethod(testBean,
"foo",
NumberUtils.DOUBLE_ONE));
assertEquals("foo(String...)", MethodUtils.invokeMethod(testBean,
"foo",
"a", "b", "c"));
assertEquals("foo(String...)", MethodUtils.invokeMethod(testBean,
"foo",
"a", "b", "c"));
assertEquals("foo(int, String...)",
MethodUtils.invokeMethod(testBean, "foo",
5, "a", "b", "c"));
-
+assertEquals("foo(long...)", MethodUtils.invokeMethod(testBean,
"foo",
+1L, 2L));
+
+try {
+MethodUtils.invokeMethod(testBean, "foo",
+1, 2);
+fail("should throw NoSuchMethodException");
+} catch (final NoSuchMethodException e) {
--- End diff --
@PascalSchumacher what do you think about refactoring existing tests? Or it
is fine to community? I can take care about it
> MethodUtils.invokeMethod throws ArrayStoreException
> ---
>
> 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 pull request #256: fix for LANG-1310
Github user Abrasha commented on a diff in the pull request:
https://github.com/apache/commons-lang/pull/256#discussion_r106028522
--- Diff:
src/test/java/org/apache/commons/lang3/reflect/MethodUtilsTest.java ---
@@ -357,16 +369,23 @@ public void testInvokeMethod() throws Exception {
assertEquals("foo(int)", MethodUtils.invokeMethod(testBean, "foo",
NumberUtils.BYTE_ONE));
assertEquals("foo(double)", MethodUtils.invokeMethod(testBean,
"foo",
-NumberUtils.LONG_ONE));
-assertEquals("foo(double)", MethodUtils.invokeMethod(testBean,
"foo",
NumberUtils.DOUBLE_ONE));
assertEquals("foo(String...)", MethodUtils.invokeMethod(testBean,
"foo",
"a", "b", "c"));
assertEquals("foo(String...)", MethodUtils.invokeMethod(testBean,
"foo",
"a", "b", "c"));
assertEquals("foo(int, String...)",
MethodUtils.invokeMethod(testBean, "foo",
5, "a", "b", "c"));
-
+assertEquals("foo(long...)", MethodUtils.invokeMethod(testBean,
"foo",
+1L, 2L));
+
+try {
+MethodUtils.invokeMethod(testBean, "foo",
+1, 2);
+fail("should throw NoSuchMethodException");
+} catch (final NoSuchMethodException e) {
--- End diff --
@PascalSchumacher what do you think about refactoring existing tests? Or it
is fine to community? I can take care about it
---
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-1310) MethodUtils.invokeMethod throws ArrayStoreException
[
https://issues.apache.org/jira/browse/LANG-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15924972#comment-15924972
]
ASF GitHub Bot commented on LANG-1310:
--
Github user PascalSchumacher commented on a diff in the pull request:
https://github.com/apache/commons-lang/pull/256#discussion_r106023700
--- Diff:
src/test/java/org/apache/commons/lang3/reflect/MethodUtilsTest.java ---
@@ -357,16 +369,23 @@ public void testInvokeMethod() throws Exception {
assertEquals("foo(int)", MethodUtils.invokeMethod(testBean, "foo",
NumberUtils.BYTE_ONE));
assertEquals("foo(double)", MethodUtils.invokeMethod(testBean,
"foo",
-NumberUtils.LONG_ONE));
-assertEquals("foo(double)", MethodUtils.invokeMethod(testBean,
"foo",
NumberUtils.DOUBLE_ONE));
assertEquals("foo(String...)", MethodUtils.invokeMethod(testBean,
"foo",
"a", "b", "c"));
assertEquals("foo(String...)", MethodUtils.invokeMethod(testBean,
"foo",
"a", "b", "c"));
assertEquals("foo(int, String...)",
MethodUtils.invokeMethod(testBean, "foo",
5, "a", "b", "c"));
-
+assertEquals("foo(long...)", MethodUtils.invokeMethod(testBean,
"foo",
+1L, 2L));
+
+try {
+MethodUtils.invokeMethod(testBean, "foo",
+1, 2);
+fail("should throw NoSuchMethodException");
+} catch (final NoSuchMethodException e) {
--- End diff --
In general I agree, but commons lang has a lot similar tests, so it's
o.k/more consistent with existing code.
> MethodUtils.invokeMethod throws ArrayStoreException
> ---
>
> 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 pull request #256: fix for LANG-1310
Github user PascalSchumacher commented on a diff in the pull request:
https://github.com/apache/commons-lang/pull/256#discussion_r106023700
--- Diff:
src/test/java/org/apache/commons/lang3/reflect/MethodUtilsTest.java ---
@@ -357,16 +369,23 @@ public void testInvokeMethod() throws Exception {
assertEquals("foo(int)", MethodUtils.invokeMethod(testBean, "foo",
NumberUtils.BYTE_ONE));
assertEquals("foo(double)", MethodUtils.invokeMethod(testBean,
"foo",
-NumberUtils.LONG_ONE));
-assertEquals("foo(double)", MethodUtils.invokeMethod(testBean,
"foo",
NumberUtils.DOUBLE_ONE));
assertEquals("foo(String...)", MethodUtils.invokeMethod(testBean,
"foo",
"a", "b", "c"));
assertEquals("foo(String...)", MethodUtils.invokeMethod(testBean,
"foo",
"a", "b", "c"));
assertEquals("foo(int, String...)",
MethodUtils.invokeMethod(testBean, "foo",
5, "a", "b", "c"));
-
+assertEquals("foo(long...)", MethodUtils.invokeMethod(testBean,
"foo",
+1L, 2L));
+
+try {
+MethodUtils.invokeMethod(testBean, "foo",
+1, 2);
+fail("should throw NoSuchMethodException");
+} catch (final NoSuchMethodException e) {
--- End diff --
In general I agree, but commons lang has a lot similar tests, so it's
o.k/more consistent with existing code.
---
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-1310) MethodUtils.invokeMethod throws ArrayStoreException
[
https://issues.apache.org/jira/browse/LANG-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15924967#comment-15924967
]
ASF GitHub Bot commented on LANG-1310:
--
Github user PascalSchumacher commented on the issue:
https://github.com/apache/commons-lang/pull/256
@drajakumar It's really great to get a pull request for this. :+1:
I took a look at this issue some time ago, but gave up trying to solve it.
Sadly I'm too tired for a review at the moment. I will get back to you in a few
days, if nobody has reviewed/merged the pull request already.
> MethodUtils.invokeMethod throws ArrayStoreException
> ---
>
> 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 @drajakumar It's really great to get a pull request for this. :+1: I took a look at this issue some time ago, but gave up trying to solve it. Sadly I'm too tired for a review at the moment. I will get back to you in a few days, if nobody has reviewed/merged the pull request already. --- 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-1310) MethodUtils.invokeMethod throws ArrayStoreException
[
https://issues.apache.org/jira/browse/LANG-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15924933#comment-15924933
]
ASF GitHub Bot commented on LANG-1310:
--
Github user Abrasha commented on a diff in the pull request:
https://github.com/apache/commons-lang/pull/256#discussion_r106018789
--- Diff:
src/test/java/org/apache/commons/lang3/reflect/MethodUtilsTest.java ---
@@ -357,16 +369,23 @@ public void testInvokeMethod() throws Exception {
assertEquals("foo(int)", MethodUtils.invokeMethod(testBean, "foo",
NumberUtils.BYTE_ONE));
assertEquals("foo(double)", MethodUtils.invokeMethod(testBean,
"foo",
-NumberUtils.LONG_ONE));
-assertEquals("foo(double)", MethodUtils.invokeMethod(testBean,
"foo",
NumberUtils.DOUBLE_ONE));
assertEquals("foo(String...)", MethodUtils.invokeMethod(testBean,
"foo",
"a", "b", "c"));
assertEquals("foo(String...)", MethodUtils.invokeMethod(testBean,
"foo",
"a", "b", "c"));
assertEquals("foo(int, String...)",
MethodUtils.invokeMethod(testBean, "foo",
5, "a", "b", "c"));
-
+assertEquals("foo(long...)", MethodUtils.invokeMethod(testBean,
"foo",
+1L, 2L));
+
+try {
+MethodUtils.invokeMethod(testBean, "foo",
+1, 2);
+fail("should throw NoSuchMethodException");
+} catch (final NoSuchMethodException e) {
--- End diff --
Maybe it will be better to extract it to another test method with expected
exception?
```
@Test(expected = NoSuchMethodException.class)
public void methodName(){
}
```
> MethodUtils.invokeMethod throws ArrayStoreException
> ---
>
> 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 pull request #256: fix for LANG-1310
Github user Abrasha commented on a diff in the pull request:
https://github.com/apache/commons-lang/pull/256#discussion_r106018789
--- Diff:
src/test/java/org/apache/commons/lang3/reflect/MethodUtilsTest.java ---
@@ -357,16 +369,23 @@ public void testInvokeMethod() throws Exception {
assertEquals("foo(int)", MethodUtils.invokeMethod(testBean, "foo",
NumberUtils.BYTE_ONE));
assertEquals("foo(double)", MethodUtils.invokeMethod(testBean,
"foo",
-NumberUtils.LONG_ONE));
-assertEquals("foo(double)", MethodUtils.invokeMethod(testBean,
"foo",
NumberUtils.DOUBLE_ONE));
assertEquals("foo(String...)", MethodUtils.invokeMethod(testBean,
"foo",
"a", "b", "c"));
assertEquals("foo(String...)", MethodUtils.invokeMethod(testBean,
"foo",
"a", "b", "c"));
assertEquals("foo(int, String...)",
MethodUtils.invokeMethod(testBean, "foo",
5, "a", "b", "c"));
-
+assertEquals("foo(long...)", MethodUtils.invokeMethod(testBean,
"foo",
+1L, 2L));
+
+try {
+MethodUtils.invokeMethod(testBean, "foo",
+1, 2);
+fail("should throw NoSuchMethodException");
+} catch (final NoSuchMethodException e) {
--- End diff --
Maybe it will be better to extract it to another test method with expected
exception?
```
@Test(expected = NoSuchMethodException.class)
public void methodName(){
}
```
---
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] [Comment Edited] (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:comment-tabpanel=15924521#comment-15924521
]
Shon Vella edited comment on VFS-620 at 3/14/17 4:36 PM:
-
Updated patch.
Sorry about that. My original version of the added tests were failing without
the update to the provider, but then before I submitted, I refactored the tests
to minimize the changes and forgot to retest the original failure with the new
tests and it turns out that I missed a few things in the refactored tests that
were causing it to run the tests without the userDirIsRoot flag set.
was (Author: svella):
Updated patch
> 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
> Attachments: VFS-620.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,
> 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) {
> }
> }
> }
> And the output,
> 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
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doRename(FtpFileObject.java:524)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1887)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[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
]
Shon Vella updated VFS-620:
---
Attachment: (was: VFS-620.patch)
> 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
> Attachments: VFS-620.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,
> 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) {
> }
> }
> }
> And the output,
> 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
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doRename(FtpFileObject.java:524)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1887)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[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
]
Shon Vella updated VFS-620:
---
Attachment: VFS-620.patch
Updated patch
> 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
> Attachments: VFS-620.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,
> 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) {
> }
> }
> }
> And the output,
> 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
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doRename(FtpFileObject.java:524)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1887)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] commons-lang pull request #256: fix for LANG-1310
Github user jvz commented on a diff in the pull request:
https://github.com/apache/commons-lang/pull/256#discussion_r105941464
--- Diff:
src/test/java/org/apache/commons/lang3/reflect/MethodUtilsTest.java ---
@@ -110,32 +114,32 @@ private void privateStuff() {
@SuppressWarnings("unused")
private String privateStringStuff() {
- return "privateStringStuff()";
+ return "privateStringStuff()";
--- End diff --
Think you could fix the formatting here?
---
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-1310) MethodUtils.invokeMethod throws ArrayStoreException
[
https://issues.apache.org/jira/browse/LANG-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15924418#comment-15924418
]
ASF GitHub Bot commented on LANG-1310:
--
Github user jvz commented on a diff in the pull request:
https://github.com/apache/commons-lang/pull/256#discussion_r105941464
--- Diff:
src/test/java/org/apache/commons/lang3/reflect/MethodUtilsTest.java ---
@@ -110,32 +114,32 @@ private void privateStuff() {
@SuppressWarnings("unused")
private String privateStringStuff() {
- return "privateStringStuff()";
+ return "privateStringStuff()";
--- End diff --
Think you could fix the formatting here?
> MethodUtils.invokeMethod throws ArrayStoreException
> ---
>
> 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] [Updated] (JEXL-220) Release 3.1 to Maven Repository
[ https://issues.apache.org/jira/browse/JEXL-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-220: --- Fix Version/s: 3.1 > Release 3.1 to Maven Repository > --- > > Key: JEXL-220 > URL: https://issues.apache.org/jira/browse/JEXL-220 > Project: Commons JEXL > Issue Type: Wish >Affects Versions: 3.1 >Reporter: Doug Whitehead >Priority: Minor > Fix For: 3.1 > > > Any chance version 3.1 is scheduled for a release to the Maven Repository any > time soon? Seems like there are plenty of improvements and bug fixes to > warrant a release, and also -- last release was a year go at this point :) > https://mvnrepository.com/artifact/org.apache.commons/commons-jexl3 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (JEXL-222) The ability to declare indexed property getter/setter in customised JexlArithmetic implementation
[
https://issues.apache.org/jira/browse/JEXL-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-222.
Resolution: Fixed
Fix Version/s: 3.1
The current overload code already allows this. To help ensure that the overload
is applied to the desired containers, IndexedType.IndexedContainer exposes new
methods exposing the name & class.
One can thus implement the following in a derived JexlArithmetic:
{code}
...public Object propertySet(IndexedType.IndexedContainer map, String
key, Integer value) {
if (map.getContainerClass().equals(PropertyContainer.class)
&& map.getContainerName().equals("property")) {
try {
map.set(key, value.toString());
} catch (Exception xany) {
throw new JexlException.Operator(null, key + "." +
value.toString(), xany);
}
return null;
}
return JexlEngine.TRY_FAILED;
}
...
{code}
src/main/java/org/apache/commons/jexl3/internal/introspection/IndexedType.java
src/test/java/org/apache/commons/jexl3/PropertyAccessTest.java
Committed revision 1786904.
> The ability to declare indexed property getter/setter in customised
> JexlArithmetic implementation
> -
>
> Key: JEXL-222
> URL: https://issues.apache.org/jira/browse/JEXL-222
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.1
>
>
> At the moment we have the ability to declare a specific getter/setter method
> in customized JexlArithmetic class that will be used by Jexl engine when
> engine tries to get access to a property of some object. This is great
> extension point of the Jexl but I have come to a situation where I need the
> same technics to be applied to indexed properties. For example I'm scripting
> org.w3c.dom.Element object by setting its attributes via its
> {code}Element.setAttribute(java.lang.String name, java.lang.String value)
> {code} method. In Jexl I use standard indexed property access syntax like the
> following: {code} node.attribute.id = "12345"; {code} The problem lies with
> the last argument of the setAttribute method which is of String class. And
> for Jexl standard indexed property setter to work I should always remember
> that in script I need to cast specified property value to a string, which is
> error-prone and lacks, in my understanding, scripting easiness. I see the
> solution as to introduce custom indexed property setter in more generalized
> form, accepting Object type as a value so it could cast a value to String
> before calling {{Element.setAttribute}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] commons-lang issue #257: Apply checkstyle to test sources
Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/257 [](https://coveralls.io/builds/10583740) Coverage increased (+0.04%) to 94.565% when pulling **7374d709125edc736b6fea6ada59789b808399df on mureinik:test-checkstyle** into **39a2a6fa38c5e4d1293e00f98a89698a962d6775 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 #257: Apply checkstyle to test sources
Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/257 [](https://coveralls.io/builds/10583740) Coverage increased (+0.04%) to 94.565% when pulling **7374d709125edc736b6fea6ada59789b808399df on mureinik:test-checkstyle** into **39a2a6fa38c5e4d1293e00f98a89698a962d6775 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 #257: Apply checkstyle to test sources
Github user mureinik commented on the issue: https://github.com/apache/commons-lang/pull/257 Updated `checkstyle-suppressions.xml` with the missing license that caused rat to fail in the CI. --- 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-1310) MethodUtils.invokeMethod throws ArrayStoreException
[
https://issues.apache.org/jira/browse/LANG-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15924195#comment-15924195
]
ASF GitHub Bot commented on LANG-1310:
--
Github user coveralls commented on the issue:
https://github.com/apache/commons-lang/pull/256
[](https://coveralls.io/builds/10583606)
Coverage increased (+0.06%) to 94.588% when pulling
**6daa417fe9826d0bfa9c2366fc520a1519e8579f on drajakumar:master** into
**39a2a6fa38c5e4d1293e00f98a89698a962d6775 on apache:master**.
> MethodUtils.invokeMethod throws ArrayStoreException
> ---
>
> 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 coveralls commented on the issue: https://github.com/apache/commons-lang/pull/256 [](https://coveralls.io/builds/10583606) Coverage increased (+0.06%) to 94.588% when pulling **6daa417fe9826d0bfa9c2366fc520a1519e8579f on drajakumar:master** into **39a2a6fa38c5e4d1293e00f98a89698a962d6775 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] (LANG-1300) Clarify or improve behaviour of int-based methods in StringUtils
[
https://issues.apache.org/jira/browse/LANG-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15924100#comment-15924100
]
ASF GitHub Bot commented on LANG-1300:
--
Github user chtompki commented on the issue:
https://github.com/apache/commons-lang/pull/251
Okay. It seems that we'll want some clearer documentation. Note that the
javadoc on `indexOf` in the jdk follows:
```java
/**
* Returns the index within this string of the first occurrence of the
* specified character, starting the search at the specified index.
*
* If a character with value ch occurs in the
* character sequence represented by this String
* object at an index no smaller than fromIndex, then
* the index of the first such occurrence is returned. For values
* of ch in the range from 0 to 0x (inclusive),
* this is the smallest value k such that:
*
* (this.charAt(k) == ch) && (k = fromIndex)
*
* is true. For other values of ch, it is the
* smallest value k such that:
*
* (this.codePointAt(k) == ch) && (k = fromIndex)
*
* is true. In either case, if no such character occurs in this
* string at or after position fromIndex, then
* -1 is returned.
*
*
* There is no restriction on the value of fromIndex. If it
* is negative, it has the same effect as if it were zero: this entire
* string may be searched. If it is greater than the length of this
* string, it has the same effect as if it were equal to the length of
* this string: -1 is returned.
*
* All indices are specified in char values
* (Unicode code units).
*
* @param ch a character (Unicode code point).
* @param fromIndex the index to start the search from.
* @return the index of the first occurrence of the character in the
* character sequence represented by this object that is
greater
* than or equal to fromIndex, or -1
* if the character does not occur.
*/
```
Let's see if we can get something along these lines on both
CharSequenceUtils as well as StringUtils. Furthermore, I think we should stick
as closely to the implementation in `String` as possible simply generalizing to
`CharSequence`'s.
> Clarify or improve behaviour of int-based methods in StringUtils
>
>
> Key: LANG-1300
> URL: https://issues.apache.org/jira/browse/LANG-1300
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.5
>Reporter: Duncan Jones
>Priority: Minor
> Fix For: Discussion
>
>
> The following methods use an {{int}} to represent a search character:
> {code:java}
> boolean contains(final CharSequence seq, final int searchChar)
> int indexOf(final CharSequence seq, final int searchChar)
> int indexOf(final CharSequence seq, final int searchChar, final int startPos)
> int lastIndexOf(final CharSequence seq, final int searchChar)
> int lastIndexOf(final CharSequence seq, final int searchChar, final int
> startPos)
> {code}
> When I see an {{int}} representing a character, I tend to assume the method
> can handle supplementary characters. However, the current behaviour of these
> methods depends upon whether the {{CharSequence}} is a {{String}} or not.
> {code:java}
> StringBuilder builder = new StringBuilder();
> builder.appendCodePoint(0x2070E);
> System.out.println(StringUtils.lastIndexOf(builder, 0x2070E)); // -1
> System.out.println(StringUtils.lastIndexOf(builder.toString(), 0x2070E)); // 0
> {code}
> The Javadoc for these methods are ambiguous on this point, stating:
> {quote}
> This method uses {{String.lastIndexOf(int)}} if possible.
> {quote}
> I think we should consider updating the {{CharSequenceUtils}} methods used by
> this class to convert all {{CharSequence}} parameters to strings, enabling
> full code point support. The docs could be updated to make this crystal clear.
> There is a question of whether this breaks backwards compatibility.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] commons-lang issue #251: LANG-1300: Change CharSequenceUtils to support supp...
Github user chtompki commented on the issue: https://github.com/apache/commons-lang/pull/251 Okay. It seems that we'll want some clearer documentation. Note that the javadoc on `indexOf` in the jdk follows: ```java /** * Returns the index within this string of the first occurrence of the * specified character, starting the search at the specified index. * * If a character with value ch occurs in the * character sequence represented by this String * object at an index no smaller than fromIndex, then * the index of the first such occurrence is returned. For values * of ch in the range from 0 to 0x (inclusive), * this is the smallest value k such that: * * (this.charAt(k) == ch) && (k = fromIndex) * * is true. For other values of ch, it is the * smallest value k such that: * * (this.codePointAt(k) == ch) && (k = fromIndex) * * is true. In either case, if no such character occurs in this * string at or after position fromIndex, then * -1 is returned. * * * There is no restriction on the value of fromIndex. If it * is negative, it has the same effect as if it were zero: this entire * string may be searched. If it is greater than the length of this * string, it has the same effect as if it were equal to the length of * this string: -1 is returned. * * All indices are specified in char values * (Unicode code units). * * @param ch a character (Unicode code point). * @param fromIndex the index to start the search from. * @return the index of the first occurrence of the character in the * character sequence represented by this object that is greater * than or equal to fromIndex, or -1 * if the character does not occur. */ ``` Let's see if we can get something along these lines on both CharSequenceUtils as well as StringUtils. Furthermore, I think we should stick as closely to the implementation in `String` as possible simply generalizing to `CharSequence`'s. --- 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] (JEXL-222) The ability to declare indexed property getter/setter in customised JexlArithmetic implementation
[
https://issues.apache.org/jira/browse/JEXL-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated JEXL-222:
---
Assignee: Henri Biestro
> The ability to declare indexed property getter/setter in customised
> JexlArithmetic implementation
> -
>
> Key: JEXL-222
> URL: https://issues.apache.org/jira/browse/JEXL-222
> Project: Commons JEXL
> Issue Type: Improvement
>Affects Versions: 3.0
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
>
> At the moment we have the ability to declare a specific getter/setter method
> in customized JexlArithmetic class that will be used by Jexl engine when
> engine tries to get access to a property of some object. This is great
> extension point of the Jexl but I have come to a situation where I need the
> same technics to be applied to indexed properties. For example I'm scripting
> org.w3c.dom.Element object by setting its attributes via its
> {code}Element.setAttribute(java.lang.String name, java.lang.String value)
> {code} method. In Jexl I use standard indexed property access syntax like the
> following: {code} node.attribute.id = "12345"; {code} The problem lies with
> the last argument of the setAttribute method which is of String class. And
> for Jexl standard indexed property setter to work I should always remember
> that in script I need to cast specified property value to a string, which is
> error-prone and lacks, in my understanding, scripting easiness. I see the
> solution as to introduce custom indexed property setter in more generalized
> form, accepting Object type as a value so it could cast a value to String
> before calling {{Element.setAttribute}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] commons-lang issue #257: Apply checkstyle to test sources
Github user kinow commented on the issue: https://github.com/apache/commons-lang/pull/257 Checked pull request locally, build passes OK. The master branch checkstyle report has 0 errors, in 154 files. This PR branch checkstyle report has 0 errors, in 331 files. --- 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 kinow commented on the issue: https://github.com/apache/commons-lang/pull/257 Not sure about applying that to test sources. It's normal to apply it to sources, but I must confess I'm less strict about issues in the tests. Normally quite happy about having the tests. As long as the tests are clear and easy to understand, I'm happy to manually fix a few tabs, add some extra classes or annotations, instead of block a commit to ask a contributor to fix the tests. +0 --- 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 #257: Apply checkstyle to test sources
GitHub user mureinik opened a pull request: https://github.com/apache/commons-lang/pull/257 Apply checkstyle to test sources This enforces the code style defined by the checkstyle checks to the test sources too. This PR contains a series of patches that fix checkstyle violations, and a final patch the enables checkstyle checks on the test sources. In the cases where it would just add robustness and not improve the code's readability and maintainability (specifically - the javadoc checks), those checks are explicitly suppressed. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mureinik/commons-lang test-checkstyle Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/257.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #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. ---
