[jira] [Commented] (FILEUPLOAD-286) default charset override

2017-10-06 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/FILEUPLOAD-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16195326#comment-16195326
 ] 

ASF GitHub Bot commented on FILEUPLOAD-286:
---

Github user maxxedev closed the pull request at:

https://github.com/apache/commons-fileupload/pull/10


> default charset override
> 
>
> Key: FILEUPLOAD-286
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-286
> Project: Commons FileUpload
>  Issue Type: Improvement
>Reporter: maxxedev
>
> If charset is not specified, ISO charset is chosen as default.
> Allow that default charset to be overridden.
> useful in cases where form-data is utf-8 encoded but not encoding is not 
> explicitly specified



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (FILEUPLOAD-286) default charset override

2017-10-06 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/FILEUPLOAD-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16195325#comment-16195325
 ] 

ASF GitHub Bot commented on FILEUPLOAD-286:
---

Github user maxxedev commented on the issue:

https://github.com/apache/commons-fileupload/pull/10
  
thanks for quck response and merge.

not sure what's going to what's going with builds for jdk6/7.

closing pull request anyways


> default charset override
> 
>
> Key: FILEUPLOAD-286
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-286
> Project: Commons FileUpload
>  Issue Type: Improvement
>Reporter: maxxedev
>
> If charset is not specified, ISO charset is chosen as default.
> Allow that default charset to be overridden.
> useful in cases where form-data is utf-8 encoded but not encoding is not 
> explicitly specified



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (FILEUPLOAD-286) default charset override

2017-10-06 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/FILEUPLOAD-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16195201#comment-16195201
 ] 

ASF GitHub Bot commented on FILEUPLOAD-286:
---

Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-fileupload/pull/10
  
@maxxedev Thanks for the pull request! It would be nice if you could close 
it, now that @jochenw has merged it. Thanks!


> default charset override
> 
>
> Key: FILEUPLOAD-286
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-286
> Project: Commons FileUpload
>  Issue Type: Improvement
>Reporter: maxxedev
>
> If charset is not specified, ISO charset is chosen as default.
> Allow that default charset to be overridden.
> useful in cases where form-data is utf-8 encoded but not encoding is not 
> explicitly specified



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (FILEUPLOAD-286) default charset override

2017-10-06 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/FILEUPLOAD-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16195155#comment-16195155
 ] 

ASF GitHub Bot commented on FILEUPLOAD-286:
---

Github user jochenw commented on the issue:

https://github.com/apache/commons-fileupload/pull/10
  
Applied.



> default charset override
> 
>
> Key: FILEUPLOAD-286
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-286
> Project: Commons FileUpload
>  Issue Type: Improvement
>Reporter: maxxedev
>
> If charset is not specified, ISO charset is chosen as default.
> Allow that default charset to be overridden.
> useful in cases where form-data is utf-8 encoded but not encoding is not 
> explicitly specified



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (FILEUPLOAD-286) default charset override

2017-10-06 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/FILEUPLOAD-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16195156#comment-16195156
 ] 

ASF GitHub Bot commented on FILEUPLOAD-286:
---

Github user jochenw commented on the issue:

https://github.com/apache/commons-fileupload/pull/10
  
Applied, thank you!



> default charset override
> 
>
> Key: FILEUPLOAD-286
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-286
> Project: Commons FileUpload
>  Issue Type: Improvement
>Reporter: maxxedev
>
> If charset is not specified, ISO charset is chosen as default.
> Allow that default charset to be overridden.
> useful in cases where form-data is utf-8 encoded but not encoding is not 
> explicitly specified



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (VFS-613) doIsWriteable() is not implemented for FtpFileObject

2017-10-06 Thread Gary Gregory (JIRA) 

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

Gary Gregory updated VFS-613:
-
Fix Version/s: (was: 2.2)
   2.2.1

> doIsWriteable() is not implemented for FtpFileObject
> 
>
> Key: VFS-613
> URL: https://issues.apache.org/jira/browse/VFS-613
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Johannes Wollnik
> Fix For: 2.2.1
>
>
> The doIsWriteable() method is not implemented for FtpFileObject and so the 
> isWritable() method returns always true no matter of the actual permissions.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (VFS-500) VFSClassLoader.findResources missing

2017-10-06 Thread Gary Gregory (JIRA) 

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

Gary Gregory updated VFS-500:
-
Fix Version/s: (was: 2.2)
   2.2.1

> VFSClassLoader.findResources missing
> 
>
> Key: VFS-500
> URL: https://issues.apache.org/jira/browse/VFS-500
> Project: Commons VFS
>  Issue Type: New Feature
>Affects Versions: 2.0
>Reporter: Bernd Eckenfels
>Assignee: Bernd Eckenfels
>Priority: Minor
> Fix For: 2.2.1
>
> Attachments: vfs-500-gg.diff
>
>
> the VFSClassLoader.findResources(String) method is a dummy implementation 
> returning an empty Enumeration.
> I have a working implementation and will support the patch for it, this is 
> the JIRA to track it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (VFS-298) FTP: Exception is thrown when renaming a file

2017-10-06 Thread Gary Gregory (JIRA) 

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

Gary Gregory updated VFS-298:
-
Fix Version/s: (was: 2.2)
   2.2.1

> FTP: Exception is thrown when renaming a file
> -
>
> Key: VFS-298
> URL: https://issues.apache.org/jira/browse/VFS-298
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: Nightly Builds
>Reporter: Kirill Safonov
>  Labels: PatchAvailable
> Fix For: 2.2.1
>
> Attachments: VFS-298-patch.txt
>
>
> java.lang.UnsupportedOperationException
>   at java.util.Collections$UnmodifiableMap.remove(Collections.java:1289)
>   at 
> org.apache.commons.vfs.provider.ftp.FtpFileObject.onChildrenChanged(FtpFileObject.java:288)
>   at 
> org.apache.commons.vfs.provider.AbstractFileObject.childrenChanged(AbstractFileObject.java:1612)
>   at 
> org.apache.commons.vfs.provider.AbstractFileObject.notifyParent(AbstractFileObject.java:1633)
>   at 
> org.apache.commons.vfs.provider.AbstractFileObject.handleDelete(AbstractFileObject.java:1558)
>   at 
> org.apache.commons.vfs.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1078)
> FtpFileObject.children may be an EMPTY_FTP_FILE_MAP if the last ls() returned 
> empty collection. This is the case for the move 
> untitled36/src/com/test/Base.as -> untitled36/src/Base.as:
> > CWD /opt/lampp/htdocs/ftp_root
> 250 Directory successfully changed.
> > RNFR untitled36/src/com/test/Base.as
> 350 Ready for RNTO.
> > RNTO untitled36/src/Base.as
> 250 Rename successful.
> > PWD
> 257 "/opt/lampp/htdocs/ftp_root"
> > CWD untitled36/src/com/test
> 250 Directory successfully changed.
> > PORT 192,168,0,112,51,217
> 200 PORT command successful. Consider using PASV.
> > LIST
> 150 Here comes the directory listing.
> 226 Directory send OK.
> (LIST returned no children)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (VFS-586) Add more ways to specify alternate HDFS configuration information

2017-10-06 Thread Gary Gregory (JIRA) 

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

Gary Gregory updated VFS-586:
-
Fix Version/s: (was: 2.2)
   2.2.1

> Add more ways to specify alternate HDFS configuration information
> -
>
> Key: VFS-586
> URL: https://issues.apache.org/jira/browse/VFS-586
> Project: Commons VFS
>  Issue Type: Improvement
>Affects Versions: 2.1
> Environment: All
>Reporter: Roger Whitcomb
>Priority: Minor
> Fix For: 2.2.1
>
> Attachments: hdfs-config-2.diffs
>
>
> In trying to resolve some customer issues we were experiencing, it was 
> necessary to specify some alternate HDFS configuration information from some 
> places other than resources in the current classpath, plus needing to specify 
> multiple configurations (such as a local copy of "core-site.xml" and 
> "hdfs-site.xml").  To accomplish this I have proposed some changes to 
> HdfsFileSystemConfigBuilder.java and HdfsFileSystem.java to be able to 
> specify alternate configurations from all the possible sources (as defined in 
> org.apache.hadoop.fs.Configuration), namely from a named resource, from a 
> local file Path, from an InputStream and from another Configuration object.  
> For resource names and local files, multiple entries are allowed so that 
> multiple configuration files can be specified as needed.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (VFS-524) The uri include ipv6 address can't be parsed out correctly

2017-10-06 Thread Gary Gregory (JIRA) 

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

Gary Gregory updated VFS-524:
-
Fix Version/s: (was: 2.2)
   2.2.1

> The uri include ipv6 address can't be parsed out correctly
> --
>
> Key: VFS-524
> URL: https://issues.apache.org/jira/browse/VFS-524
> Project: Commons VFS
>  Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Alex
> Fix For: 2.2.1
>
> Attachments: VFS-524-v2.patch, VFS-524-v3.patch
>
>
> I am using apache commons vfs2 to read and download file in ipv6 enviroment, 
> but it seems can't parse out ipv6 address correctly
> The URI is just like:
> ftp://[2002:9ba:b4e:6:a052:5792:c0c9:2330]/test
> The error message:
> Invalid absolute URI "ftp://[2002:9ba:b4e:6:a052:5792:c0c9:2330]/test;.
> Caused by : Expecting / to follow the hostname in URI 
> "ftp://[2002:9ba:b4e:6:a052:5792:c0c9:2330]/test;.
> Deep into the code, I found the root cause is that HostFileNameParser's 
> extractHostName can't parse out the host name correctly
> {noformat}
> /**
>  * Extracts the hostname from a URI.  The scheme://userinfo@ part has
>  * been removed.
>  */
> protected String extractHostName(final StringBuilder name)
> {
> final int maxlen = name.length();
> int pos = 0;
> for (; pos < maxlen; pos++)
> {
> final char ch = name.charAt(pos);
> if (ch == '/' || ch == ';' || ch == '?' || ch == ':'
> || ch == '@' || ch == '&' || ch == '=' || ch == '+'
> || ch == '$' || ch == ',')
> {
> break;
> }
> }
> if (pos == 0)
> {
> return null;
> }
> final String hostname = name.substring(0, pos);
> name.delete(0, pos);
> return hostname;
> }
> {noformat}
> From the code, we are able to know it will  parse out the host name by colon, 
> but for ipv6, it will get a wrong host name
> There is the same problem with the other protocol like sftp and cifs



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (VFS-600) HttpProviderTestCase#testHttp405 is repeatedly failling

2017-10-06 Thread Gary Gregory (JIRA) 

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

Gary Gregory updated VFS-600:
-
Fix Version/s: (was: 2.2)
   2.2.1

> HttpProviderTestCase#testHttp405 is repeatedly failling 
> 
>
> Key: VFS-600
> URL: https://issues.apache.org/jira/browse/VFS-600
> Project: Commons VFS
>  Issue Type: Task
>Affects Versions: 2.1
>Reporter: Josh Elser
>Priority: Minor
> Fix For: 2.2.1
>
>
> testHttp405 is repeatedly failing with the below message:
> {noformat}
> testHttp405(org.apache.commons.vfs2.provider.http.test.HttpProviderTestCase)  
> Time elapsed: 0.558 sec  <<< ERROR!
> org.apache.commons.vfs2.FileSystemException: Could not determine the size of 
> "http://www.w3schools.com/webservices/tempconvert.asmx?action=WSDL; because 
> it is not a file.
>   at 
> org.apache.commons.vfs2.provider.DefaultFileContent.getSize(DefaultFileContent.java:135)
>   at 
> org.apache.commons.vfs2.provider.http.test.HttpProviderTestCase.testHttp405(HttpProviderTestCase.java:208)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:597)
>   at 
> org.apache.commons.vfs2.test.AbstractProviderTestCase.runTest(AbstractProviderTestCase.java:218)
>   at junit.framework.TestCase.runBare(TestCase.java:141)
>   at junit.framework.TestResult$1.protect(TestResult.java:122)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at junit.framework.TestResult.run(TestResult.java:125)
>   at junit.framework.TestCase.run(TestCase.java:129)
>   at junit.framework.TestSuite.runTest(TestSuite.java:252)
>   at junit.framework.TestSuite.run(TestSuite.java:247)
>   at junit.extensions.TestDecorator.basicRun(TestDecorator.java:23)
>   at 
> org.apache.commons.vfs2.test.AbstractTestSuite$1.protect(AbstractTestSuite.java:149)
>   at junit.framework.TestResult.runProtected(TestResult.java:142)
>   at 
> org.apache.commons.vfs2.test.AbstractTestSuite.run(AbstractTestSuite.java:154)
>   at 
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {noformat}
> It seems like that URL is now throwing an HTTP 404?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (VFS-596) Add User and Password to Socks 5 Proxy Configuration

2017-10-06 Thread Gary Gregory (JIRA) 

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

Gary Gregory updated VFS-596:
-
Fix Version/s: (was: 2.2)
   2.2.1

> Add User and Password to Socks 5 Proxy Configuration
> 
>
> Key: VFS-596
> URL: https://issues.apache.org/jira/browse/VFS-596
> Project: Commons VFS
>  Issue Type: Improvement
>Affects Versions: 2.1
>Reporter: Simon Eiersbrock
> Fix For: 2.2.1
>
> Attachments: COMMONSVFS-21-AddUserAndPasswordToSocks5Proxy.patch
>
>
> The library jcraft.jsch can handle a socks 5 proxy with user and password, 
> but the Commons VFS2 API does not route the user and password to this 
> library. 
> I created a patch to enable Commons VFS to use a socks 5 proxy with user and 
> password. It is attached to this issue.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (FILEUPLOAD-286) default charset override

2017-10-06 Thread maxxedev (JIRA) 

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

maxxedev updated FILEUPLOAD-286:

Description: 
If charset is not specified, ISO charset is chosen as default.

Allow that default charset to be overridden.

useful in cases where form-data is utf-8 encoded but not encoding is not 
explicitly specified

  was:
If charset is not specified, ISO charset is chosen as default.

Allow that default charset to be overridden 


> default charset override
> 
>
> Key: FILEUPLOAD-286
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-286
> Project: Commons FileUpload
>  Issue Type: Improvement
>Reporter: maxxedev
>
> If charset is not specified, ISO charset is chosen as default.
> Allow that default charset to be overridden.
> useful in cases where form-data is utf-8 encoded but not encoding is not 
> explicitly specified



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (FILEUPLOAD-286) default charset override

2017-10-06 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/FILEUPLOAD-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16195033#comment-16195033
 ] 

ASF GitHub Bot commented on FILEUPLOAD-286:
---

GitHub user maxxedev opened a pull request:

https://github.com/apache/commons-fileupload/pull/10

FILEUPLOAD-286: allow default charset to be overridden.

useful in cases where form-data is utf-8 encoded but
not encoding is not explicitly specified

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/maxxedev/commons-fileupload master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-fileupload/pull/10.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 #10


commit 6b3ac5aea05876e355ed3a0ecc60ab685b5d2810
Author: maxxedev 
Date:   2017-10-06T18:35:34Z

FILEUPLOAD-286: allow default charset to be overridden.

useful in cases where form-data is utf-8 encoded but
not encoding is not explicitly specified




> default charset override
> 
>
> Key: FILEUPLOAD-286
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-286
> Project: Commons FileUpload
>  Issue Type: Improvement
>Reporter: maxxedev
>
> If charset is not specified, ISO charset is chosen as default.
> Allow that default charset to be overridden.
> useful in cases where form-data is utf-8 encoded but not encoding is not 
> explicitly specified



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (FILEUPLOAD-286) default charset override

2017-10-06 Thread maxxedev (JIRA) 

[ 
https://issues.apache.org/jira/browse/FILEUPLOAD-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16195034#comment-16195034
 ] 

maxxedev commented on FILEUPLOAD-286:
-

https://github.com/apache/commons-fileupload/pull/10

> default charset override
> 
>
> Key: FILEUPLOAD-286
> URL: https://issues.apache.org/jira/browse/FILEUPLOAD-286
> Project: Commons FileUpload
>  Issue Type: Improvement
>Reporter: maxxedev
>
> If charset is not specified, ISO charset is chosen as default.
> Allow that default charset to be overridden.
> useful in cases where form-data is utf-8 encoded but not encoding is not 
> explicitly specified



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (FILEUPLOAD-286) default charset override

2017-10-06 Thread maxxedev (JIRA) 
maxxedev created FILEUPLOAD-286:
---

 Summary: default charset override
 Key: FILEUPLOAD-286
 URL: https://issues.apache.org/jira/browse/FILEUPLOAD-286
 Project: Commons FileUpload
  Issue Type: Improvement
Reporter: maxxedev


If charset is not specified, ISO charset is chosen as default.

Allow that default charset to be overridden 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] commons-lang issue #295: ExtendedMessageFormatTest integers

2017-10-06 Thread coveralls 
Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/295
  

[![Coverage 
Status](https://coveralls.io/builds/13607404/badge)](https://coveralls.io/builds/13607404)

Coverage remained the same at 95.201% when pulling 
**e6b773af09df4f8300653cda13120a55b9056ca9 on 
mureinik:ExtendedMessageFormatTest** into 
**cc748d35e50cc290ffbecd287e04bec9db906a76 on apache:master**.



---

[GitHub] commons-lang issue #295: ExtendedMessageFormatTest integers

2017-10-06 Thread coveralls 
Github user coveralls commented on the issue:

https://github.com/apache/commons-lang/pull/295
  

[![Coverage 
Status](https://coveralls.io/builds/13607404/badge)](https://coveralls.io/builds/13607404)

Coverage remained the same at 95.201% when pulling 
**e6b773af09df4f8300653cda13120a55b9056ca9 on 
mureinik:ExtendedMessageFormatTest** into 
**cc748d35e50cc290ffbecd287e04bec9db906a76 on apache:master**.



---

[GitHub] commons-lang pull request #295: ExtendedMessageFormatTest integers

2017-10-06 Thread mureinik 
GitHub user mureinik opened a pull request:

https://github.com/apache/commons-lang/pull/295

ExtendedMessageFormatTest integers

Use the decimal "5" instead of the octal notation "05" to make the
code more straight forward and easier to read.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mureinik/commons-lang 
ExtendedMessageFormatTest

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-lang/pull/295.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 #295


commit e6b773af09df4f8300653cda13120a55b9056ca9
Author: Allon Mureinik 
Date:   2017-10-05T18:46:26Z

ExtendedMessageFormatTest integers

Use the decimal "5" instead of the octal notation "05" to make the
code more straight forward and easier to read.




---

[jira] [Resolved] (COMPRESS-421) TarUtils.parseName does not follow the spec

2017-10-06 Thread Stefan Bodewig (JIRA) 

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

Stefan Bodewig resolved COMPRESS-421.
-
   Resolution: Fixed
Fix Version/s: 1.15

Pull Request merged, many thanks!

> TarUtils.parseName does not follow the spec
> ---
>
> Key: COMPRESS-421
> URL: https://issues.apache.org/jira/browse/COMPRESS-421
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Archivers
>Affects Versions: 1.4, 1.14
>Reporter: Roel Spilker
>Priority: Minor
> Fix For: 1.15
>
> Attachments: foo.tar.gz
>
>
> TarUtils.parseName does not stop at the first NUL byte, resulting in 
> non-empty strings where they should be empty.
> This manifests if the tar file contains a star_header struct instead of a 
> posix_header as defined in 
> https://www.gnu.org/software/tar/manual/html_node/Standard.html
> The javadoc on parseName states "Parse an entry name from a buffer. Parsing 
> stops when a NUL is found or the buffer length is reached."
> However, the implementation starts at the end of the buffer and stops when 
> the first non-NUL is found.
> The solution is to replace:
> {code:java}
>   int len = length;
>   for (; len > 0; len--) {
> if (buffer[offset + len - 1] != 0) {
>   break;
> }
>   }
> {code}
> by
> {code:java}
>   int len = 0;
>   for (int i = offset; len < length && buffer[i] != 0; i++, len++);
> {code}
> This has been introduce in commit 
> https://git-wip-us.apache.org/repos/asf?p=commons-compress.git;a=commitdiff;h=69ceb4e14feb6273c06c1e35ba116b6783bb3278
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (COMPRESS-421) TarUtils.parseName does not follow the spec

2017-10-06 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/COMPRESS-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16194875#comment-16194875
 ] 

ASF GitHub Bot commented on COMPRESS-421:
-

Github user asfgit closed the pull request at:

https://github.com/apache/commons-compress/pull/54


> TarUtils.parseName does not follow the spec
> ---
>
> Key: COMPRESS-421
> URL: https://issues.apache.org/jira/browse/COMPRESS-421
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Archivers
>Affects Versions: 1.4, 1.14
>Reporter: Roel Spilker
>Priority: Minor
> Fix For: 1.15
>
> Attachments: foo.tar.gz
>
>
> TarUtils.parseName does not stop at the first NUL byte, resulting in 
> non-empty strings where they should be empty.
> This manifests if the tar file contains a star_header struct instead of a 
> posix_header as defined in 
> https://www.gnu.org/software/tar/manual/html_node/Standard.html
> The javadoc on parseName states "Parse an entry name from a buffer. Parsing 
> stops when a NUL is found or the buffer length is reached."
> However, the implementation starts at the end of the buffer and stops when 
> the first non-NUL is found.
> The solution is to replace:
> {code:java}
>   int len = length;
>   for (; len > 0; len--) {
> if (buffer[offset + len - 1] != 0) {
>   break;
> }
>   }
> {code}
> by
> {code:java}
>   int len = 0;
>   for (int i = offset; len < length && buffer[i] != 0; i++, len++);
> {code}
> This has been introduce in commit 
> https://git-wip-us.apache.org/repos/asf?p=commons-compress.git;a=commitdiff;h=69ceb4e14feb6273c06c1e35ba116b6783bb3278
>  



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (JEXL-238) Restrict getLiteralClass to a Number for NumberLiterals

2017-10-06 Thread Henri Biestro (JIRA) 

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

Henri Biestro resolved JEXL-238.

   Resolution: Fixed
 Assignee: Henri Biestro
Fix Version/s: 3.2

src/main/java/org/apache/commons/jexl3/parser/ASTNumberLiteral.java
src/main/java/org/apache/commons/jexl3/parser/NumberParser.java

Committed revision 1811339.

> Restrict getLiteralClass to a Number for NumberLiterals
> ---
>
> Key: JEXL-238
> URL: https://issues.apache.org/jira/browse/JEXL-238
> Project: Commons JEXL
>  Issue Type: Improvement
>Affects Versions: 3.1
>Reporter: Cameron Samak
>Assignee: Henri Biestro
>Priority: Trivial
> Fix For: 3.2
>
> Attachments: patch0.patch
>
>
> getLiteralClass in ASTNumberLiteral returns Class when it could return 
> Class
> I'd like to extend this to JexlArithmetic.narrowNumber, but that's a 
> (trivial) breaking change so I left it out.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (JEXL-239) Add NPE check to property for MapGetExecutor

2017-10-06 Thread Henri Biestro (JIRA) 

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

Henri Biestro resolved JEXL-239.

Resolution: Fixed

Per last commit.

> Add NPE check to property for MapGetExecutor
> 
>
> Key: JEXL-239
> URL: https://issues.apache.org/jira/browse/JEXL-239
> Project: Commons JEXL
>  Issue Type: Improvement
>Affects Versions: 2.1.1
>Reporter: Bruno P. Kinoshita
>Assignee: Henri Biestro
>Priority: Minor
>
> From GitHub pull request #2 https://github.com/apache/commons-jexl/pull/2
> {quote}
> When the MapGetExecutor is init by the key null, the property of 
> MapGetExecutor will be null.
> If the MapGetExecutor is cached and the key is changed (like map[index]), 
> there will throw an NPE.
> I think the intention for the condition is to compare the class 
> compatibility, so I add the NPE check here.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (JEXL-239) Add NPE check to property for MapGetExecutor

2017-10-06 Thread Henri Biestro (JIRA) 

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

Henri Biestro updated JEXL-239:
---
Assignee: Henri Biestro

> Add NPE check to property for MapGetExecutor
> 
>
> Key: JEXL-239
> URL: https://issues.apache.org/jira/browse/JEXL-239
> Project: Commons JEXL
>  Issue Type: Improvement
>Affects Versions: 2.1.1
>Reporter: Bruno P. Kinoshita
>Assignee: Henri Biestro
>Priority: Minor
>
> From GitHub pull request #2 https://github.com/apache/commons-jexl/pull/2
> {quote}
> When the MapGetExecutor is init by the key null, the property of 
> MapGetExecutor will be null.
> If the MapGetExecutor is cached and the key is changed (like map[index]), 
> there will throw an NPE.
> I think the intention for the condition is to compare the class 
> compatibility, so I add the NPE check here.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (JEXL-240) Unable to invoke a call operator using antish style variable resoltion

2017-10-06 Thread Henri Biestro (JIRA) 

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

Henri Biestro resolved JEXL-240.

   Resolution: Fixed
Fix Version/s: 3.2

Expose the Jexl engine evaluating a script/expression as a thread local;
Make classes functors, ie class(arg) will attempt to call a ctor, a simpler 
version of new(class, arg);
Fix antish variable resolution when used as method/function call; 

src/main/java/org/apache/commons/jexl3/JexlEngine.java
src/main/java/org/apache/commons/jexl3/internal/Engine.java
src/main/java/org/apache/commons/jexl3/internal/Interpreter.java
src/test/java/org/apache/commons/jexl3/AntishCallTest.java

Committed revision 1811336.

> Unable to invoke a call operator using antish style variable resoltion
> --
>
> Key: JEXL-240
> URL: https://issues.apache.org/jira/browse/JEXL-240
> Project: Commons JEXL
>  Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
> Fix For: 3.2
>
> Attachments: AntishCallTest.java
>
>
> Suppose I have declared an antish style context variable under the name 
> {{java.math.BigDecimal}} of the {{Class}} type.
> To test that it works correctly I use the following script
> {code}var x = java.math.BigDecimal; x("1234"){code} which returns correct 
> value.
> Now I want to invoke an overloaded call operator directly for this variable 
> using {code}java.math.BigDecimal("1234"){code} 
> which returns an error 
> {panel}
> undefined variable java.math
> {panel}
> The expected behaviour is to return the same value as in the first script.
> I have created a test case for this, please have a look.
> Thanks!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] commons-lang pull request #294: Added indexesOf method

2017-10-06 Thread Abrasha 
Github user Abrasha commented on a diff in the pull request:

https://github.com/apache/commons-lang/pull/294#discussion_r143189192
  
--- Diff: src/main/java/org/apache/commons/lang3/StringUtils.java ---
@@ -9245,25 +9245,28 @@ public static String unwrap(final String str, final 
char wrapChar) {
 index += Character.charCount(result[i]);
 }
 return result;
-}
+}
 
 /**
  * Finds index of all the occurences of given search key found in 
source string.
  * 
- * @param source
- * @param searchKey
+ * @param source 
+ *   input string to find indexes
+ * @param searchKey 
+ *   search character
  * @return list of integer of indexes.
  */
 public static List indexesOf(final CharSequence source, final 
Character searchKey) {
if(isEmpty(source) || searchKey == null ) {
-   return null;
-   }
+   return null;
+   }
--- End diff --

Can you fix the formatting, please?


---