[jira] [Updated] (COMPRESS-424) [bzip2] Multiple ArrayIndexOutOfBoundsException(s) when decompressing malformed input
[ https://issues.apache.org/jira/browse/COMPRESS-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohan Padhye updated COMPRESS-424: -- Attachment: bad1.bz2 bad2.bz2 bad3.bz2 > [bzip2] Multiple ArrayIndexOutOfBoundsException(s) when decompressing > malformed input > - > > Key: COMPRESS-424 > URL: https://issues.apache.org/jira/browse/COMPRESS-424 > Project: Commons Compress > Issue Type: Bug > Components: Compressors >Affects Versions: 1.14, 1.15 >Reporter: Rohan Padhye >Priority: Minor > Attachments: bad1.bz2, bad2.bz2, bad3.bz2 > > > Encountered multiple unchecked exceptions thrown from > {{BZip2CompressorInputStream.}} when parsing malformed files. > {{ArrayIndexOutOfBoundsException}} is an unchecked exception that is not > documented in this API; therefore, such exceptions can cause stability issues > in applications that are not expecting them. Instead, an {{IOException}} > should be thrown indicating that the input stream contains malformed data. > Stack traces for three distinct (but possibly related) sources of exceptions > follow: > {noformat} > java.lang.ArrayIndexOutOfBoundsException: 65536 > at > org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.hbCreateDecodeTables(BZip2CompressorInputStream.java:422) > at > org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.createHuffmanDecodingTables(BZip2CompressorInputStream.java:546) > at > org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.recvDecodingTables(BZip2CompressorInputStream.java:518) > at > org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.getAndMoveToFrontDecode(BZip2CompressorInputStream.java:555) > at > org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.initBlock(BZip2CompressorInputStream.java:324) > at > org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:135) > at > org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:112) > {noformat} > {noformat} > java.lang.ArrayIndexOutOfBoundsException: 6 > at > org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.recvDecodingTables(BZip2CompressorInputStream.java:493) > at > org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.getAndMoveToFrontDecode(BZip2CompressorInputStream.java:555) > at > org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.initBlock(BZip2CompressorInputStream.java:324) > at > org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:135) > at > org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:112) > {noformat} > {noformat} > java.lang.ArrayIndexOutOfBoundsException: 18002 > at > org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.getAndMoveToFrontDecode(BZip2CompressorInputStream.java:605) > at > org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.initBlock(BZip2CompressorInputStream.java:324) > at > org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:135) > at > org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:112) > {noformat} > The inputs were found by mutating random bytes in a simple well-formed file > (a compressed string of zeros). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (COMPRESS-424) [bzip2] Multiple ArrayIndexOutOfBoundsException(s) when decompressing malformed input
Rohan Padhye created COMPRESS-424: - Summary: [bzip2] Multiple ArrayIndexOutOfBoundsException(s) when decompressing malformed input Key: COMPRESS-424 URL: https://issues.apache.org/jira/browse/COMPRESS-424 Project: Commons Compress Issue Type: Bug Components: Compressors Affects Versions: 1.15, 1.14 Reporter: Rohan Padhye Priority: Minor Encountered multiple unchecked exceptions thrown from {{BZip2CompressorInputStream.}} when parsing malformed files. {{ArrayIndexOutOfBoundsException}} is an unchecked exception that is not documented in this API; therefore, such exceptions can cause stability issues in applications that are not expecting them. Instead, an {{IOException}} should be thrown indicating that the input stream contains malformed data. Stack traces for three distinct (but possibly related) sources of exceptions follow: {noformat} java.lang.ArrayIndexOutOfBoundsException: 65536 at org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.hbCreateDecodeTables(BZip2CompressorInputStream.java:422) at org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.createHuffmanDecodingTables(BZip2CompressorInputStream.java:546) at org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.recvDecodingTables(BZip2CompressorInputStream.java:518) at org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.getAndMoveToFrontDecode(BZip2CompressorInputStream.java:555) at org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.initBlock(BZip2CompressorInputStream.java:324) at org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:135) at org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:112) {noformat} {noformat} java.lang.ArrayIndexOutOfBoundsException: 6 at org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.recvDecodingTables(BZip2CompressorInputStream.java:493) at org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.getAndMoveToFrontDecode(BZip2CompressorInputStream.java:555) at org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.initBlock(BZip2CompressorInputStream.java:324) at org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:135) at org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:112) {noformat} {noformat} java.lang.ArrayIndexOutOfBoundsException: 18002 at org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.getAndMoveToFrontDecode(BZip2CompressorInputStream.java:605) at org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.initBlock(BZip2CompressorInputStream.java:324) at org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:135) at org.apache.commons.compress.compressors.bzip2.BZip2CompressorInputStream.(BZip2CompressorInputStream.java:112) {noformat} The inputs were found by mutating random bytes in a simple well-formed file (a compressed string of zeros). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (VALIDATOR-430) Local domain TLDs should include "test"
[ https://issues.apache.org/jira/browse/VALIDATOR-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210454#comment-16210454 ] Jason Klapste commented on VALIDATOR-430: - We are using: * DomainValidator.getInstance(true).isValid(plainDomain) It doesn't matter to me where .test is added ;) I would assume though that a user that is calling getInstance(false) because they want to validate a domain has a valid TLD would not expect/want .test to return true given that it is not a valid TLD. I read "local" to mean around me, not specifically localhost, ie localization, my local bar, etc hence the idea of adding to LOCAL_TLDS. INFRASTRUCTURE_TLDS, GENERIC_TLDS, etc don't seem to be the right place given that not all use cases would allow for them to be verified as valid. I guess you could also question where .example could be added as technically that also should be considered valid in some cases? I do know about updateTLDOverride() but that method is not available to us given that it can only be used before the first call to getInstance(). The application we are working on is multi-threaded and I only have access to my thread logic; I don't have access to change the app start up logic and there is no guarantee that by the time my thread is called someone hasn't already called getInstance(). I would prefer to use my own DomainValidator instance but that would obviously require a large number of changes given everything is static :) > Local domain TLDs should include "test" > --- > > Key: VALIDATOR-430 > URL: https://issues.apache.org/jira/browse/VALIDATOR-430 > Project: Commons Validator > Issue Type: Improvement > Components: Routines >Affects Versions: 1.6 >Reporter: Jason Klapste > > In addition to "localhost" and "localdomain", it would be helpful if "test" > was added to the list of allowed local domains: > * https://en.wikipedia.org/wiki/.test -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (VALIDATOR-430) Local domain TLDs should include "test"
[ https://issues.apache.org/jira/browse/VALIDATOR-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16210286#comment-16210286 ] Sebb commented on VALIDATOR-430: bq. the server/IP the .test name points to is not always on the local host My point exactly. I don't think it makes sense for isValidLocalTld("test") to return true. Note that you can provide your own overrides using the updateTLDOverride() method. You haven't said what method(s) your code is using. > Local domain TLDs should include "test" > --- > > Key: VALIDATOR-430 > URL: https://issues.apache.org/jira/browse/VALIDATOR-430 > Project: Commons Validator > Issue Type: Improvement > Components: Routines >Affects Versions: 1.6 >Reporter: Jason Klapste > > In addition to "localhost" and "localdomain", it would be helpful if "test" > was added to the list of allowed local domains: > * https://en.wikipedia.org/wiki/.test -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (VFS-647) calling findFiles() causes copyFrom() to fail with a partially downloaded file.
[ https://issues.apache.org/jira/browse/VFS-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated VFS-647: - Description: When using FileObject.copyFrom(remote, new AllFileSelector()) to download file from remote to local directory. If SftpFileObject.findFiles(new FileDepthSelector(1,1)) is called and finished, then the copyFrom will get interrupted with error pipe closed. Below are test codes and stack trace error. In real scenario, this all happens within 1 or 2 second time frame. However, with test scenario, I wasn't able to reproduce it easily therefore I had to choose a file that takes around 10 seconds to download and have Thread.sleep(5000) after findFiles() call. Only tested jsch-0.1.52, jsch-0.1.54, commons-vfs2-2.0 and commons-vfs2-2.2. {code:java} public class FtpClient { public static void main(String[] args) { if (args.length < 5) { throw new RuntimeException("args: host user pass local remote"); } String hostname = args[0]; String username = args[1]; String password = args[2]; int port = 22; String local = args[3]; String remote = args[4]; final String remoteDir = remote.substring(0, Math.max(0, remote.lastIndexOf("/"))); Thread t0 = new Thread() { public void run() { try (Ftp ftp = new Ftp(hostname, port)) { ftp.login(username, password); ftp.list(remoteDir); System.out.println("findFiles() completed."); } catch (Exception e) { e.printStackTrace(); } } }; Thread ti = new Thread() { public void run() { try (Ftp ftp = new Ftp(hostname, port)) { ftp.login(username, password); ftp.download(local, remote); } catch (Exception e) { e.printStackTrace(); } } }; t0.start(); ti.start(); } } public class Ftp implements AutoCloseable { private int timeout = 0; private StaticUserAuthenticator userAuth; private FileSystemOptions fileSysOpts; private FileObject scr = null; private FileSystemManager fsm = null; private String hostName; private int port = 0; public Ftp(String remoteHost, int controlPort) throws FileSystemException { hostName = remoteHost; port = controlPort; fsm = VFS.getManager(); } //login into a server with a valid account public void login(String user, String password) throws IOException { userAuth = new StaticUserAuthenticator(null, user, password); fileSysOpts = new FileSystemOptions(); DefaultFileSystemConfigBuilder.getInstance().setUserAuthenticator(fileSysOpts, userAuth); SftpFileSystemConfigBuilder.getInstance().setStrictHostKeyChecking(fileSysOpts, "no"); SftpFileSystemConfigBuilder.getInstance().setTimeout(fileSysOpts, timeout); SftpFileSystemConfigBuilder.getInstance().setUserDirIsRoot(fileSysOpts, false); scr = (FileObject)fsm.resolveFile("sftp://"; + hostName, fileSysOpts); System.out.println("login successfully."); } public void list(String dirName) throws Exception { SftpFileObject RemoteFo = (SftpFileObject)fsm.resolveFile("sftp://"; + hostName + dirName, fileSysOpts); FileObject[] afo = RemoteFo.findFiles(new FileDepthSelector(1,1)); Thread.sleep(5000); //key. this must be here (or some other processing that takes time) for error to reproduce consistently. } public void download(String localPath, String remoteFile) throws FileSystemException { SftpFileSystemConfigBuilder.getInstance().setStrictHostKeyChecking(fileSysOpts, "no"); SftpFileObject RemoteFo = (SftpFileObject)fsm.resolveFile("sftp://"; + hostName + remoteFile ,fileSysOpts); scr = fsm.resolveFile("file:" + localPath); scr.copyFrom(RemoteFo, new AllFileSelector()); } @Override public void close() { try{ FileSyst
[jira] [Comment Edited] (VALIDATOR-430) Local domain TLDs should include "test"
[ https://issues.apache.org/jira/browse/VALIDATOR-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16209882#comment-16209882 ] Jason Klapste edited comment on VALIDATOR-430 at 10/18/17 7:54 PM: --- It's not allowed as a top-level, it's only usable in local scenarios (either specific to a host or within a private DNS zone) hence why I'm suggesting it be classified as local. As mentioned on the wiki page: {quote}This allows the use of these names for either documentation purposes or in *local testing scenarios.*{quote} Specifically for our scenario-- we use .test domains (say site1.test, site2.test, etc) for testing locally in development environments and on our CI servers. They are most often set up via /etc/hosts. As the server/IP the .test name points to is not always on the local host we prefer not to use local* to define it. was (Author: jklap): It's not allowed as a top-level, it's only usable in local scenarios (either specific to a host or within a private DNS zone) hence why I'm suggesting it be classified as local. As mentioned on the wiki page: {quote}This allows the use of these names for either documentation purposes or in *local testing scenarios.*{quote} Specifically for our scenario-- we use *.test domains (say site1.test, site2.test, etc) for testing locally in development environments and on our CI servers. They are most often set up via /etc/hosts. As the server/IP the *.test name points to is not always on the local host we prefer not to use local* to define it. > Local domain TLDs should include "test" > --- > > Key: VALIDATOR-430 > URL: https://issues.apache.org/jira/browse/VALIDATOR-430 > Project: Commons Validator > Issue Type: Improvement > Components: Routines >Affects Versions: 1.6 >Reporter: Jason Klapste > > In addition to "localhost" and "localdomain", it would be helpful if "test" > was added to the list of allowed local domains: > * https://en.wikipedia.org/wiki/.test -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (VALIDATOR-430) Local domain TLDs should include "test"
[ https://issues.apache.org/jira/browse/VALIDATOR-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16209882#comment-16209882 ] Jason Klapste commented on VALIDATOR-430: - It's not allowed as a top-level, it's only usable in local scenarios (either specific to a host or within a private DNS zone) hence why I'm suggesting it be classified as local. As mentioned on the wiki page: {quote}This allows the use of these names for either documentation purposes or in *local testing scenarios.*{quote} Specifically for our scenario-- we use *.test domains (say site1.test, site2.test, etc) for testing locally in development environments and on our CI servers. They are most often set up via /etc/hosts. As the server/IP the *.test name points to is not always on the local host we prefer not to use local* to define it. > Local domain TLDs should include "test" > --- > > Key: VALIDATOR-430 > URL: https://issues.apache.org/jira/browse/VALIDATOR-430 > Project: Commons Validator > Issue Type: Improvement > Components: Routines >Affects Versions: 1.6 >Reporter: Jason Klapste > > In addition to "localhost" and "localdomain", it would be helpful if "test" > was added to the list of allowed local domains: > * https://en.wikipedia.org/wiki/.test -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (VALIDATOR-430) Local domain TLDs should include "test"
[ https://issues.apache.org/jira/browse/VALIDATOR-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16209781#comment-16209781 ] Sebb commented on VALIDATOR-430: test is *not* a local domain. What is the use case for allowing it as such? > Local domain TLDs should include "test" > --- > > Key: VALIDATOR-430 > URL: https://issues.apache.org/jira/browse/VALIDATOR-430 > Project: Commons Validator > Issue Type: Improvement > Components: Routines >Affects Versions: 1.6 >Reporter: Jason Klapste > > In addition to "localhost" and "localdomain", it would be helpful if "test" > was added to the list of allowed local domains: > * https://en.wikipedia.org/wiki/.test -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (VALIDATOR-430) Local domain TLDs should include "test"
[ https://issues.apache.org/jira/browse/VALIDATOR-430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb updated VALIDATOR-430: --- Priority: Major (was: Critical) > Local domain TLDs should include "test" > --- > > Key: VALIDATOR-430 > URL: https://issues.apache.org/jira/browse/VALIDATOR-430 > Project: Commons Validator > Issue Type: Improvement > Components: Routines >Affects Versions: 1.6 >Reporter: Jason Klapste > > In addition to "localhost" and "localdomain", it would be helpful if "test" > was added to the list of allowed local domains: > * https://en.wikipedia.org/wiki/.test -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (VFS-647) calling findFiles() causes copyFrom() to fail with a partially downloaded file.
Kenji created VFS-647: - Summary: calling findFiles() causes copyFrom() to fail with a partially downloaded file. Key: VFS-647 URL: https://issues.apache.org/jira/browse/VFS-647 Project: Commons VFS Issue Type: Bug Affects Versions: 2.2, 2.0 Environment: Windows 7 and Linux Red Hat. Reporter: Kenji Priority: Minor When using FileObject.copyFrom(remote, new AllFileSelector()) to download file from remote to local directory. If SftpFileObject.findFiles(new FileDepthSelector(1,1)) is called and finished, then the copyFrom will get interrupted with error pipe closed. Below are test codes and stack trace error. In real scenario, this all happens within 1 or 2 second time frame. However, with test scenario, I wasn't able to reproduce it easily therefore I had to choose a file that takes around 10 seconds to download and have Thread.sleep(5000) after findFiles() call. Only tested jsch-0.1.52, jsch-0.1.54, commons-vfs2-2.0 and commons-vfs2-2.2. {code:java} public class FtpClient { public static void main(String[] args) { if (args.length < 5) { throw new RuntimeException("args: host user pass local remote"); } String hostname = args[0]; String username = args[1]; String password = args[2]; int port = 22; String local = args[3]; String remote = args[4]; final String remoteDir = remote.substring(0, Math.max(0, remote.lastIndexOf("/"))); Thread t0 = new Thread() { public void run() { try (Ftp ftp = new Ftp(hostname, port)) { ftp.login(username, password); ftp.list(remoteDir); System.out.println("findFiles() completed."); } catch (Exception e) { e.printStackTrace(); } } }; Thread ti = new Thread() { public void run() { try (Ftp ftp = new Ftp(hostname, port)) { ftp.login(username, password); ftp.download(local, remote); } catch (Exception e) { e.printStackTrace(); } } }; t0.start(); ti.start(); } } public class Ftp implements AutoCloseable { private int timeout = 0; private StaticUserAuthenticator userAuth; private FileSystemOptions fileSysOpts; private FileObject scr = null; private FileSystemManager fsm = null; private String hostName; private int port = 0; public Ftp(String remoteHost, int controlPort) throws FileSystemException { hostName = remoteHost; port = controlPort; fsm = VFS.getManager(); } //login into a server with a valid account public void login(String user, String password) throws IOException { userAuth = new StaticUserAuthenticator(null, user, password); fileSysOpts = new FileSystemOptions(); DefaultFileSystemConfigBuilder.getInstance().setUserAuthenticator(fileSysOpts, userAuth); SftpFileSystemConfigBuilder.getInstance().setStrictHostKeyChecking(fileSysOpts, "no"); SftpFileSystemConfigBuilder.getInstance().setTimeout(fileSysOpts, timeout); SftpFileSystemConfigBuilder.getInstance().setUserDirIsRoot(fileSysOpts, false); scr = (FileObject)fsm.resolveFile("sftp://"; + hostName, fileSysOpts); System.out.println("login successfully."); } public void list(String dirName) throws Exception { SftpFileObject RemoteFo = (SftpFileObject)fsm.resolveFile("sftp://"; + hostName + dirName, fileSysOpts); FileObject[] afo = RemoteFo.findFiles(new FileDepthSelector(1,1)); Thread.sleep(5000); //key. this must be here (or some other processing that takes time) for error to reproduce consistently. } public void download(String localPath, String remoteFile) throws FileSystemException { SftpFileSystemConfigBuilder.getInstance().setStrictHostKeyChecking(fileSysOpts, "no"); SftpFileObject RemoteFo = (SftpFileObject)fsm.resolveFile("sftp://"; + hostName + remoteFile ,fileSysOp
[jira] [Created] (TEXT-104) Jaro Winkler Distance refers to similarity
Nikos Karagiannakis created TEXT-104: Summary: Jaro Winkler Distance refers to similarity Key: TEXT-104 URL: https://issues.apache.org/jira/browse/TEXT-104 Project: Commons Text Issue Type: Improvement Affects Versions: 1.1 Reporter: Nikos Karagiannakis Priority: Trivial The 'apply' method returns the similarity score instead of the distance score as implied from the class name. It is stated in the javadoc, but it is not aligned with the approach of the rest similarity scores in the same package (e.g LevenshteinDetailedDistance). Maybe a rename of the class or the method to avoid confusion? -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TEXT-100) StringEscapeUtils#UnEscapeJson doesn't recognize escape signs correctly
[ https://issues.apache.org/jira/browse/TEXT-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16209631#comment-16209631 ] ASF GitHub Bot commented on TEXT-100: - Github user coveralls commented on the issue: https://github.com/apache/commons-text/pull/72 [![Coverage Status](https://coveralls.io/builds/13776755/badge)](https://coveralls.io/builds/13776755) Coverage remained the same at 98.238% when pulling **390e16b6b62561ae1de3d3918175ea04a037ec2a on drajakumar:master** into **8f7d0494d19a54b1606d0d7779ff4754c3d66b23 on apache:master**. > StringEscapeUtils#UnEscapeJson doesn't recognize escape signs correctly > --- > > Key: TEXT-100 > URL: https://issues.apache.org/jira/browse/TEXT-100 > Project: Commons Text > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Michael Hausegger > > As shown in > org.apache.commons.text.StringEscapeUtils#testUnescapeJsonFoundBug JSON > escape signs do not get treated correctly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TEXT-100) StringEscapeUtils#UnEscapeJson doesn't recognize escape signs correctly
[ https://issues.apache.org/jira/browse/TEXT-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16209627#comment-16209627 ] Don Jeba commented on TEXT-100: --- Hello, Provided a fix for this issue, kindly review/comment/merge https://github.com/apache/commons-text/pull/72 Thank you, Regards, Don Jeba. > StringEscapeUtils#UnEscapeJson doesn't recognize escape signs correctly > --- > > Key: TEXT-100 > URL: https://issues.apache.org/jira/browse/TEXT-100 > Project: Commons Text > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Michael Hausegger > > As shown in > org.apache.commons.text.StringEscapeUtils#testUnescapeJsonFoundBug JSON > escape signs do not get treated correctly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (TEXT-100) StringEscapeUtils#UnEscapeJson doesn't recognize escape signs correctly
[ https://issues.apache.org/jira/browse/TEXT-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16209624#comment-16209624 ] ASF GitHub Bot commented on TEXT-100: - GitHub user drajakumar opened a pull request: https://github.com/apache/commons-text/pull/72 fix for TEXT-100 You can merge this pull request into a Git repository by running: $ git pull https://github.com/drajakumar/commons-text master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-text/pull/72.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 #72 commit 390e16b6b62561ae1de3d3918175ea04a037ec2a Author: drajakumar Date: 2017-10-18T16:14:46Z fix for TEXT-100 > StringEscapeUtils#UnEscapeJson doesn't recognize escape signs correctly > --- > > Key: TEXT-100 > URL: https://issues.apache.org/jira/browse/TEXT-100 > Project: Commons Text > Issue Type: Bug >Affects Versions: 1.1 >Reporter: Michael Hausegger > > As shown in > org.apache.commons.text.StringEscapeUtils#testUnescapeJsonFoundBug JSON > escape signs do not get treated correctly. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (VALIDATOR-430) Local domain TLDs should include "test"
Jason Klapste created VALIDATOR-430: --- Summary: Local domain TLDs should include "test" Key: VALIDATOR-430 URL: https://issues.apache.org/jira/browse/VALIDATOR-430 Project: Commons Validator Issue Type: Improvement Components: Routines Affects Versions: 1.6 Reporter: Jason Klapste Priority: Critical In addition to "localhost" and "localdomain", it would be helpful if "test" was added to the list of allowed local domains: * https://en.wikipedia.org/wiki/.test -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Closed] (VFS-646) Update Apache Commons Compress from 1.14 to 1.15
[ https://issues.apache.org/jira/browse/VFS-646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed VFS-646. Resolution: Fixed Fix Version/s: 2.2.1 In svn trunk. > Update Apache Commons Compress from 1.14 to 1.15 > - > > Key: VFS-646 > URL: https://issues.apache.org/jira/browse/VFS-646 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 2.2.1 > > > Update Apache Commons Compress from 1.14 to 1.15. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (VFS-646) Update Apache Commons Compress from 1.14 to 1.15
Gary Gregory created VFS-646: Summary: Update Apache Commons Compress from 1.14 to 1.15 Key: VFS-646 URL: https://issues.apache.org/jira/browse/VFS-646 Project: Commons VFS Issue Type: Improvement Affects Versions: 2.2 Reporter: Gary Gregory Assignee: Gary Gregory Update Apache Commons Compress from 1.14 to 1.15. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (FILEUPLOAD-287) Multipart/mixed parts not handled correctly
[ https://issues.apache.org/jira/browse/FILEUPLOAD-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16209310#comment-16209310 ] Jochen Wiedmann commented on FILEUPLOAD-287: Thanks very much, I'll be looking into that. > Multipart/mixed parts not handled correctly > --- > > Key: FILEUPLOAD-287 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-287 > Project: Commons FileUpload > Issue Type: Bug >Affects Versions: 1.3.3 >Reporter: Etienne Dethoor >Priority: Critical > > If i submit a request with global header > {{Content-Type="multipart/mixed;boundary="uuid:5985c43c-16a5-483a-88ff-64602f2a2f3f";charset=UTF-8"}} > data to a servlet with : > {code:xml} > --uuid:5985c43c-16a5-483a-88ff-64602f2a2f3f > Content-Type: text/plain > Content-Transfer-Encoding: binary > Content-ID: myFile > My_Content_Here > --uuid:5985c43c-16a5-483a-88ff-64602f2a2f3f > Content-Type: application/xml > Content-Transfer-Encoding: binary > Content-ID: myOtherFileHere > M_Other_Content_Here > {code} > The differents parts are not recognized because of > {{FileUploadBase.getFieldName()}} method who want a {{Content-Disposition}} > header for each part of the request. > The [rfc|https://tools.ietf.org/html/rfc7578#section-4.2] specified that this > header is mandatory for the {{multipart/form-data}} content-type. > For the {{multipart/mixed}}, if i well understand, the rfc doesn't say this > header is mandatory for each parts of the request. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (FILEUPLOAD-287) Multipart/mixed parts not handled correctly
[ https://issues.apache.org/jira/browse/FILEUPLOAD-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16209265#comment-16209265 ] Etienne Dethoor commented on FILEUPLOAD-287: Hello, I've forked [the github repo|https://github.com/edethoor/commons-fileupload/blob/TestMultipartMixed/src/test/java/org/apache/commons/fileupload/servlet/ServletFileUploadMultiPartMixedTest.java] and i've added a {{ServletFileUploadMultiPartMixedTest.java}} test file in the TestMultipartMixed branch. > Multipart/mixed parts not handled correctly > --- > > Key: FILEUPLOAD-287 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-287 > Project: Commons FileUpload > Issue Type: Bug >Affects Versions: 1.3.3 >Reporter: Etienne Dethoor >Priority: Critical > > If i submit a request with global header > {{Content-Type="multipart/mixed;boundary="uuid:5985c43c-16a5-483a-88ff-64602f2a2f3f";charset=UTF-8"}} > data to a servlet with : > {code:xml} > --uuid:5985c43c-16a5-483a-88ff-64602f2a2f3f > Content-Type: text/plain > Content-Transfer-Encoding: binary > Content-ID: myFile > My_Content_Here > --uuid:5985c43c-16a5-483a-88ff-64602f2a2f3f > Content-Type: application/xml > Content-Transfer-Encoding: binary > Content-ID: myOtherFileHere > M_Other_Content_Here > {code} > The differents parts are not recognized because of > {{FileUploadBase.getFieldName()}} method who want a {{Content-Disposition}} > header for each part of the request. > The [rfc|https://tools.ietf.org/html/rfc7578#section-4.2] specified that this > header is mandatory for the {{multipart/form-data}} content-type. > For the {{multipart/mixed}}, if i well understand, the rfc doesn't say this > header is mandatory for each parts of the request. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] commons-lang issue #299: Add module-info for Java 9
Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/299 [![Coverage Status](https://coveralls.io/builds/13771842/badge)](https://coveralls.io/builds/13771842) Coverage increased (+0.01%) to 95.199% when pulling **886b26aa09efc1a4bfca3470e33b952399f18f6d on jodastephen:module-info** into **1f0dfc31b51a445eb2cfbee5321800cf51e10b67 on apache:master**. ---
[GitHub] commons-lang issue #299: Add module-info for Java 9
Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/299 [![Coverage Status](https://coveralls.io/builds/13771246/badge)](https://coveralls.io/builds/13771246) Coverage increased (+0.01%) to 95.199% when pulling **07c0c408e72836231ef262f565761778e3e9e103 on jodastephen:module-info** into **1f0dfc31b51a445eb2cfbee5321800cf51e10b67 on apache:master**. ---
[jira] [Commented] (FILEUPLOAD-287) Multipart/mixed parts not handled correctly
[ https://issues.apache.org/jira/browse/FILEUPLOAD-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16209134#comment-16209134 ] Jochen Wiedmann commented on FILEUPLOAD-287: Would you be able to provide a unit test? Thanks, Jochen > Multipart/mixed parts not handled correctly > --- > > Key: FILEUPLOAD-287 > URL: https://issues.apache.org/jira/browse/FILEUPLOAD-287 > Project: Commons FileUpload > Issue Type: Bug >Affects Versions: 1.3.3 >Reporter: Etienne Dethoor >Priority: Critical > > If i submit a request with global header > {{Content-Type="multipart/mixed;boundary="uuid:5985c43c-16a5-483a-88ff-64602f2a2f3f";charset=UTF-8"}} > data to a servlet with : > {code:xml} > --uuid:5985c43c-16a5-483a-88ff-64602f2a2f3f > Content-Type: text/plain > Content-Transfer-Encoding: binary > Content-ID: myFile > My_Content_Here > --uuid:5985c43c-16a5-483a-88ff-64602f2a2f3f > Content-Type: application/xml > Content-Transfer-Encoding: binary > Content-ID: myOtherFileHere > M_Other_Content_Here > {code} > The differents parts are not recognized because of > {{FileUploadBase.getFieldName()}} method who want a {{Content-Disposition}} > header for each part of the request. > The [rfc|https://tools.ietf.org/html/rfc7578#section-4.2] specified that this > header is mandatory for the {{multipart/form-data}} content-type. > For the {{multipart/mixed}}, if i well understand, the rfc doesn't say this > header is mandatory for each parts of the request. -- This message was sent by Atlassian JIRA (v6.4.14#64029)