[jira] [Commented] (VALIDATOR-430) Local domain TLDs should include "test"

2017-10-18 Thread Jason Klapste (JIRA) 

[ 
https://issues.apache.org/jira/browse/VALIDATOR-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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"

2017-10-18 Thread Sebb (JIRA) 

[ 
https://issues.apache.org/jira/browse/VALIDATOR-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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.

2017-10-18 Thread Gary Gregory (JIRA) 

 [ 
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{
FileSystem

[jira] [Comment Edited] (VALIDATOR-430) Local domain TLDs should include "test"

2017-10-18 Thread Jason Klapste (JIRA) 

[ 
https://issues.apache.org/jira/browse/VALIDATOR-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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"

2017-10-18 Thread Jason Klapste (JIRA) 

[ 
https://issues.apache.org/jira/browse/VALIDATOR-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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"

2017-10-18 Thread Sebb (JIRA) 

[ 
https://issues.apache.org/jira/browse/VALIDATOR-430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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"

2017-10-18 Thread Sebb (JIRA) 

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

2017-10-18 Thread Kenji (JIRA) 
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

[jira] [Created] (TEXT-104) Jaro Winkler Distance refers to similarity

2017-10-18 Thread Nikos Karagiannakis (JIRA) 
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

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

[ 
https://issues.apache.org/jira/browse/TEXT-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2017-10-18 Thread Don Jeba (JIRA) 

[ 
https://issues.apache.org/jira/browse/TEXT-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

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

[ 
https://issues.apache.org/jira/browse/TEXT-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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"

2017-10-18 Thread Jason Klapste (JIRA) 
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

2017-10-18 Thread Gary Gregory (JIRA) 

 [ 
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

2017-10-18 Thread Gary Gregory (JIRA) 
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

2017-10-18 Thread Jochen Wiedmann (JIRA) 

[ 
https://issues.apache.org/jira/browse/FILEUPLOAD-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2017-10-18 Thread Etienne Dethoor (JIRA) 

[ 
https://issues.apache.org/jira/browse/FILEUPLOAD-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

2017-10-18 Thread coveralls 
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

2017-10-18 Thread coveralls 
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

2017-10-18 Thread Jochen Wiedmann (JIRA) 

[ 
https://issues.apache.org/jira/browse/FILEUPLOAD-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)