date:20171106

[jira] [Updated] (COMPRESS-427) ZipFile.getEntries() returns WinZip entries separated by backslash

2017-11-06 Thread Yana Lebedeva (JIRA)


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

Yana Lebedeva updated COMPRESS-427:
---
Description: 
Archives created by WinZip on Windows 10 display recurring COMPRESS-176 
behaviour, with a new twist.

Attached example archive is created by latest WinZip version 22 build 12663.
It may have been experienced also for WinZip version 18 build 10661 on Windows 
10.

ZipFile.getEntries() for the attached example zip archive return the list of 
entries with the following ZipArchiveEntry.getName():
{noformat}
test/
test\\file — mdash.txt
test/ä.txt
test/sub/
test/sub\\file — mdash2.txt
test/sub\\ä2.txt
{noformat}
ZipArchiveEntry.getPlatform() was essential for the COMPRESS-176 workaround.
It returns 0 for all entries in the example archive, except for two entries 
containing mdash. Those return 11.

Tested with version 1.10 and updating to current 1.15.
The backslash names seem to originate in the Unicode extra fields.

  was:
Archives created by WinZip on Windows 10 display recurring COMPRESS-176 
behaviour, with a new twist.

Attached example archive is created by latest WinZip version 22 build 12663.
It may have been experienced also for WinZip version 18 build 10661 on Windows 
10.

ZipFile.getEntries() for the attached example zip archive return the list of 
entries with the following ZipArchiveEntry.getName():
{noformat}
test/
test\\file — mdash.txt
test/ä.txt
test/sub/
test/sub\\file — mdash2.txt
test/sub\\ä2.txt
{noformat}
ZipArchiveEntry.getPlatform() was essential for the COMPRESS-176 workaround.
It returns 0 for all entries in the example archive, except for two entries 
containing mdash. Those return 11.

Tested with version 1.10 and updating to current 1.15.


> ZipFile.getEntries() returns WinZip entries separated by backslash
> --
>
> Key: COMPRESS-427
> URL: https://issues.apache.org/jira/browse/COMPRESS-427
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Archivers
>Affects Versions: 1.10, 1.15
>Reporter: Yana Lebedeva
> Attachments: mdash-and-umlaut.zip
>
>
> Archives created by WinZip on Windows 10 display recurring COMPRESS-176 
> behaviour, with a new twist.
> Attached example archive is created by latest WinZip version 22 build 12663.
> It may have been experienced also for WinZip version 18 build 10661 on 
> Windows 10.
> ZipFile.getEntries() for the attached example zip archive return the list of 
> entries with the following ZipArchiveEntry.getName():
> {noformat}
> test/
> test\\file — mdash.txt
> test/ä.txt
> test/sub/
> test/sub\\file — mdash2.txt
> test/sub\\ä2.txt
> {noformat}
> ZipArchiveEntry.getPlatform() was essential for the COMPRESS-176 workaround.
> It returns 0 for all entries in the example archive, except for two entries 
> containing mdash. Those return 11.
> Tested with version 1.10 and updating to current 1.15.
> The backslash names seem to originate in the Unicode extra fields.



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

[jira] [Updated] (COMPRESS-427) ZipFile.getEntries() returns WinZip entries separated by backslash

2017-11-06 Thread Yana Lebedeva (JIRA)


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

Yana Lebedeva updated COMPRESS-427:
---
Description: 
Archives created by WinZip on Windows 10 display recurring COMPRESS-176 
behaviour, with a new twist.

Attached example archive is created by latest WinZip version 22 build 12663.
It may have been experienced also for WinZip version 18 build 10661 on Windows 
10.

ZipFile.getEntries() for the attached example zip archive return the list of 
entries with the following ZipArchiveEntry.getName():
{noformat}
test/
test\\file — mdash.txt
test/ä.txt
test/sub/
test/sub\\file — mdash2.txt
test/sub\\ä2.txt
{noformat}
ZipArchiveEntry.getPlatform() was essential for the COMPRESS-176 workaround.
It returns 0 for all entries in the example archive, except for two entries 
containing mdash. Those return 11.

Tested with version 1.10 and updating to current 1.15.

  was:
Archives created by WinZip on Windows 10 display recurring COMPRESS-176 
behaviour, with a new twist.

Attached example archive is created by latest WinZip version 22 build 12663.
It may have been experienced also for WinZip version 18 build 10661 on Windows 
10.

ZipFile.getEntries() for the attached example zip archive return the list of 
entries with the following ZipArchiveEntry.getName():
{noformat}
test/
test\\file — mdash.txt
test/ä.txt
test/sub/
test/sub\\file — mdash2.txt
test/sub\\ä2.txt
{noformat}
ZipArchiveEntry.getPlatform() was essential for the COMPRESS-176 workaround.
It returns 0 for all entries in the example archive, except for two entries 
containing mdash. Those return 11.

Tested with version 1.10 (in use) and updating to current 1.15.


> ZipFile.getEntries() returns WinZip entries separated by backslash
> --
>
> Key: COMPRESS-427
> URL: https://issues.apache.org/jira/browse/COMPRESS-427
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Archivers
>Affects Versions: 1.10, 1.15
>Reporter: Yana Lebedeva
> Attachments: mdash-and-umlaut.zip
>
>
> Archives created by WinZip on Windows 10 display recurring COMPRESS-176 
> behaviour, with a new twist.
> Attached example archive is created by latest WinZip version 22 build 12663.
> It may have been experienced also for WinZip version 18 build 10661 on 
> Windows 10.
> ZipFile.getEntries() for the attached example zip archive return the list of 
> entries with the following ZipArchiveEntry.getName():
> {noformat}
> test/
> test\\file — mdash.txt
> test/ä.txt
> test/sub/
> test/sub\\file — mdash2.txt
> test/sub\\ä2.txt
> {noformat}
> ZipArchiveEntry.getPlatform() was essential for the COMPRESS-176 workaround.
> It returns 0 for all entries in the example archive, except for two entries 
> containing mdash. Those return 11.
> Tested with version 1.10 and updating to current 1.15.



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

[jira] [Updated] (COMPRESS-427) ZipFile.getEntries() returns WinZip entries separated by backslash

2017-11-06 Thread Yana Lebedeva (JIRA)


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

Yana Lebedeva updated COMPRESS-427:
---
Description: 
Archives created by WinZip on Windows 10 display recurring COMPRESS-176 
behaviour, with a new twist.

Attached example archive is created by latest WinZip version 22 build 12663.
It may have been experienced also for WinZip version 18 build 10661 on Windows 
10.

ZipFile.getEntries() for the attached example zip archive return the list of 
entries with the following ZipArchiveEntry.getName():
{noformat}
test/
test\\file — mdash.txt
test/ä.txt
test/sub/
test/sub\\file — mdash2.txt
test/sub\\ä2.txt
{noformat}
ZipArchiveEntry.getPlatform() was essential for the COMPRESS-176 workaround.
It returns 0 for all entries in the example archive, except for two entries 
containing mdash. Those return 11.

Tested with version 1.10 (in use) and updating to current 1.15.

  was:
Archives created by WinZip on Windows 10 display recurring COMPRESS-176 
behaviour, with a new twist.

Attached example archive is created by latest WinZip version 22 build 12663.
It may have been experienced also for WinZip version 18 build 10661 on Windows 
10.

ZipFile.getEntries() for the attached example zip archive return the list of 
entries with the following ZipArchiveEntry.getName():
{noformat}
test/
test\\file — mdash.txt
test/ä.txt
test/sub/
test/sub\\file — mdash2.txt
test/sub\\ä2.txt
{noformat}
ZipArchiveEntry.getPlatform() was essential for the COMPRESS-176 workaround.
It returns 0 for all entries in the example archive, except for two entries 
containing mdash. Those return 11.


> ZipFile.getEntries() returns WinZip entries separated by backslash
> --
>
> Key: COMPRESS-427
> URL: https://issues.apache.org/jira/browse/COMPRESS-427
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Archivers
>Affects Versions: 1.10, 1.15
>Reporter: Yana Lebedeva
> Attachments: mdash-and-umlaut.zip
>
>
> Archives created by WinZip on Windows 10 display recurring COMPRESS-176 
> behaviour, with a new twist.
> Attached example archive is created by latest WinZip version 22 build 12663.
> It may have been experienced also for WinZip version 18 build 10661 on 
> Windows 10.
> ZipFile.getEntries() for the attached example zip archive return the list of 
> entries with the following ZipArchiveEntry.getName():
> {noformat}
> test/
> test\\file — mdash.txt
> test/ä.txt
> test/sub/
> test/sub\\file — mdash2.txt
> test/sub\\ä2.txt
> {noformat}
> ZipArchiveEntry.getPlatform() was essential for the COMPRESS-176 workaround.
> It returns 0 for all entries in the example archive, except for two entries 
> containing mdash. Those return 11.
> Tested with version 1.10 (in use) and updating to current 1.15.



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

[jira] [Updated] (COMPRESS-427) ZipFile.getEntries() returns WinZip entries separated by backslash

2017-11-06 Thread Yana Lebedeva (JIRA)


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

Yana Lebedeva updated COMPRESS-427:
---
Affects Version/s: 1.15

> ZipFile.getEntries() returns WinZip entries separated by backslash
> --
>
> Key: COMPRESS-427
> URL: https://issues.apache.org/jira/browse/COMPRESS-427
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Archivers
>Affects Versions: 1.10, 1.15
>Reporter: Yana Lebedeva
> Attachments: mdash-and-umlaut.zip
>
>
> Archives created by WinZip on Windows 10 display recurring COMPRESS-176 
> behaviour, with a new twist.
> Attached example archive is created by latest WinZip version 22 build 12663.
> It may have been experienced also for WinZip version 18 build 10661 on 
> Windows 10.
> ZipFile.getEntries() for the attached example zip archive return the list of 
> entries with the following ZipArchiveEntry.getName():
> {noformat}
> test/
> test\\file — mdash.txt
> test/ä.txt
> test/sub/
> test/sub\\file — mdash2.txt
> test/sub\\ä2.txt
> {noformat}
> ZipArchiveEntry.getPlatform() was essential for the COMPRESS-176 workaround.
> It returns 0 for all entries in the example archive, except for two entries 
> containing mdash. Those return 11.



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

[jira] [Updated] (COMPRESS-427) ZipFile.getEntries() returns WinZip entries separated by backslash

2017-11-06 Thread Yana Lebedeva (JIRA)


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

Yana Lebedeva updated COMPRESS-427:
---
Description: 
Archives created by WinZip on Windows 10 display recurring COMPRESS-176 
behaviour, with a new twist.

Attached example archive is created by latest WinZip version 22 build 12663.
It may have been experienced also for WinZip version 18 build 10661 on Windows 
10.

ZipFile.getEntries() for the attached example zip archive return the list of 
entries with the following ZipArchiveEntry.getName():
{noformat}
test/
test\\file — mdash.txt
test/ä.txt
test/sub/
test/sub\\file — mdash2.txt
test/sub\\ä2.txt
{noformat}
ZipArchiveEntry.getPlatform() was essential for the 
https://issues.apache.org/jira/browse/COMPRESS-176 workaround.
It returns 0 for all entries in the example archive, except for two entries 
containing mdash. Those return 11.

  was:
Archives created by WinZip on Windows 10 display recurring 
https://issues.apache.org/jira/browse/COMPRESS-176 behaviour, with a new twist.

Attached example archive is created by latest WinZip version 22 build 12663.
It may have been experienced also for WinZip version 18 build 10661 on Windows 
10.

ZipFile.getEntries() for the attached example zip archive return the list of 
entries with the following ZipArchiveEntry.getName():
{noformat}
test/
test\\file — mdash.txt
test/ä.txt
test/sub/
test/sub\\file — mdash2.txt
test/sub\\ä2.txt
{noformat}
ZipArchiveEntry.getPlatform() was essential for the 
https://issues.apache.org/jira/browse/COMPRESS-176 workaround.
It returns 0 for all entries in the example archive, except for two entries 
containing mdash. Those return 11.


> ZipFile.getEntries() returns WinZip entries separated by backslash
> --
>
> Key: COMPRESS-427
> URL: https://issues.apache.org/jira/browse/COMPRESS-427
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Archivers
>Affects Versions: 1.10
>Reporter: Yana Lebedeva
> Attachments: mdash-and-umlaut.zip
>
>
> Archives created by WinZip on Windows 10 display recurring COMPRESS-176 
> behaviour, with a new twist.
> Attached example archive is created by latest WinZip version 22 build 12663.
> It may have been experienced also for WinZip version 18 build 10661 on 
> Windows 10.
> ZipFile.getEntries() for the attached example zip archive return the list of 
> entries with the following ZipArchiveEntry.getName():
> {noformat}
> test/
> test\\file — mdash.txt
> test/ä.txt
> test/sub/
> test/sub\\file — mdash2.txt
> test/sub\\ä2.txt
> {noformat}
> ZipArchiveEntry.getPlatform() was essential for the 
> https://issues.apache.org/jira/browse/COMPRESS-176 workaround.
> It returns 0 for all entries in the example archive, except for two entries 
> containing mdash. Those return 11.



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

[jira] [Updated] (COMPRESS-427) ZipFile.getEntries() returns WinZip entries separated by backslash

2017-11-06 Thread Yana Lebedeva (JIRA)


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

Yana Lebedeva updated COMPRESS-427:
---
Description: 
Archives created by WinZip on Windows 10 display recurring COMPRESS-176 
behaviour, with a new twist.

Attached example archive is created by latest WinZip version 22 build 12663.
It may have been experienced also for WinZip version 18 build 10661 on Windows 
10.

ZipFile.getEntries() for the attached example zip archive return the list of 
entries with the following ZipArchiveEntry.getName():
{noformat}
test/
test\\file — mdash.txt
test/ä.txt
test/sub/
test/sub\\file — mdash2.txt
test/sub\\ä2.txt
{noformat}
ZipArchiveEntry.getPlatform() was essential for the COMPRESS-176 workaround.
It returns 0 for all entries in the example archive, except for two entries 
containing mdash. Those return 11.

  was:
Archives created by WinZip on Windows 10 display recurring COMPRESS-176 
behaviour, with a new twist.

Attached example archive is created by latest WinZip version 22 build 12663.
It may have been experienced also for WinZip version 18 build 10661 on Windows 
10.

ZipFile.getEntries() for the attached example zip archive return the list of 
entries with the following ZipArchiveEntry.getName():
{noformat}
test/
test\\file — mdash.txt
test/ä.txt
test/sub/
test/sub\\file — mdash2.txt
test/sub\\ä2.txt
{noformat}
ZipArchiveEntry.getPlatform() was essential for the 
https://issues.apache.org/jira/browse/COMPRESS-176 workaround.
It returns 0 for all entries in the example archive, except for two entries 
containing mdash. Those return 11.


> ZipFile.getEntries() returns WinZip entries separated by backslash
> --
>
> Key: COMPRESS-427
> URL: https://issues.apache.org/jira/browse/COMPRESS-427
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Archivers
>Affects Versions: 1.10
>Reporter: Yana Lebedeva
> Attachments: mdash-and-umlaut.zip
>
>
> Archives created by WinZip on Windows 10 display recurring COMPRESS-176 
> behaviour, with a new twist.
> Attached example archive is created by latest WinZip version 22 build 12663.
> It may have been experienced also for WinZip version 18 build 10661 on 
> Windows 10.
> ZipFile.getEntries() for the attached example zip archive return the list of 
> entries with the following ZipArchiveEntry.getName():
> {noformat}
> test/
> test\\file — mdash.txt
> test/ä.txt
> test/sub/
> test/sub\\file — mdash2.txt
> test/sub\\ä2.txt
> {noformat}
> ZipArchiveEntry.getPlatform() was essential for the COMPRESS-176 workaround.
> It returns 0 for all entries in the example archive, except for two entries 
> containing mdash. Those return 11.



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

[jira] [Updated] (COMPRESS-427) ZipFile.getEntries() returns WinZip entries separated by backslash

2017-11-06 Thread Yana Lebedeva (JIRA)


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

Yana Lebedeva updated COMPRESS-427:
---
Attachment: mdash-and-umlaut.zip

> ZipFile.getEntries() returns WinZip entries separated by backslash
> --
>
> Key: COMPRESS-427
> URL: https://issues.apache.org/jira/browse/COMPRESS-427
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Archivers
>Affects Versions: 1.10
>Reporter: Yana Lebedeva
> Attachments: mdash-and-umlaut.zip
>
>
> Archives created by WinZip on Windows 10 display recurring 
> https://issues.apache.org/jira/browse/COMPRESS-176 behaviour, with a new 
> twist.
> Attached example archive is created by latest WinZip version 22 build 12663.
> It may have been experienced also for WinZip version 18 build 10661 on 
> Windows 10.
> ZipFile.getEntries() for the attached example zip archive return the list of 
> entries with the following ZipArchiveEntry.getName():
> {noformat}
> test/
> test\\file — mdash.txt
> test/ä.txt
> test/sub/
> test/sub\\file — mdash2.txt
> test/sub\\ä2.txt
> {noformat}
> ZipArchiveEntry.getPlatform() was essential for the 
> https://issues.apache.org/jira/browse/COMPRESS-176 workaround.
> It returns 0 for all entries in the example archive, except for two entries 
> containing mdash. Those return 11 (sic!).



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

[jira] [Updated] (COMPRESS-427) ZipFile.getEntries() returns WinZip entries separated by backslash

2017-11-06 Thread Yana Lebedeva (JIRA)


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

Yana Lebedeva updated COMPRESS-427:
---
Description: 
Archives created by WinZip on Windows 10 display recurring 
https://issues.apache.org/jira/browse/COMPRESS-176 behaviour, with a new twist.

Attached example archive is created by latest WinZip version 22 build 12663.
It may have been experienced also for WinZip version 18 build 10661 on Windows 
10.

ZipFile.getEntries() for the attached example zip archive return the list of 
entries with the following ZipArchiveEntry.getName():
{noformat}
test/
test\\file — mdash.txt
test/ä.txt
test/sub/
test/sub\\file — mdash2.txt
test/sub\\ä2.txt
{noformat}
ZipArchiveEntry.getPlatform() was essential for the 
https://issues.apache.org/jira/browse/COMPRESS-176 workaround.
It returns 0 for all entries in the example archive, except for two entries 
containing mdash. Those return 11.

  was:
Archives created by WinZip on Windows 10 display recurring 
https://issues.apache.org/jira/browse/COMPRESS-176 behaviour, with a new twist.

Attached example archive is created by latest WinZip version 22 build 12663.
It may have been experienced also for WinZip version 18 build 10661 on Windows 
10.

ZipFile.getEntries() for the attached example zip archive return the list of 
entries with the following ZipArchiveEntry.getName():
{noformat}
test/
test\\file — mdash.txt
test/ä.txt
test/sub/
test/sub\\file — mdash2.txt
test/sub\\ä2.txt
{noformat}
ZipArchiveEntry.getPlatform() was essential for the 
https://issues.apache.org/jira/browse/COMPRESS-176 workaround.
It returns 0 for all entries in the example archive, except for two entries 
containing mdash. Those return 11 (sic!).


> ZipFile.getEntries() returns WinZip entries separated by backslash
> --
>
> Key: COMPRESS-427
> URL: https://issues.apache.org/jira/browse/COMPRESS-427
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Archivers
>Affects Versions: 1.10
>Reporter: Yana Lebedeva
> Attachments: mdash-and-umlaut.zip
>
>
> Archives created by WinZip on Windows 10 display recurring 
> https://issues.apache.org/jira/browse/COMPRESS-176 behaviour, with a new 
> twist.
> Attached example archive is created by latest WinZip version 22 build 12663.
> It may have been experienced also for WinZip version 18 build 10661 on 
> Windows 10.
> ZipFile.getEntries() for the attached example zip archive return the list of 
> entries with the following ZipArchiveEntry.getName():
> {noformat}
> test/
> test\\file — mdash.txt
> test/ä.txt
> test/sub/
> test/sub\\file — mdash2.txt
> test/sub\\ä2.txt
> {noformat}
> ZipArchiveEntry.getPlatform() was essential for the 
> https://issues.apache.org/jira/browse/COMPRESS-176 workaround.
> It returns 0 for all entries in the example archive, except for two entries 
> containing mdash. Those return 11.



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

[jira] [Updated] (COMPRESS-427) ZipFile.getEntries() returns WinZip entries separated by backslash

2017-11-06 Thread Yana Lebedeva (JIRA)


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

Yana Lebedeva updated COMPRESS-427:
---
Description: 
Archives created by WinZip on Windows 10 display recurring 
https://issues.apache.org/jira/browse/COMPRESS-176 behaviour, with a new twist.

Attached example archive is created by latest WinZip version 22 build 12663.
It may have been experienced also for WinZip version 18 build 10661 on Windows 
10.

ZipFile.getEntries() for the attached example zip archive return the list of 
entries with the following ZipArchiveEntry.getName():
{noformat}
test/
test\\file — mdash.txt
test/ä.txt
test/sub/
test/sub\\file — mdash2.txt
test/sub\\ä2.txt
{noformat}
ZipArchiveEntry.getPlatform() was essential for the 
https://issues.apache.org/jira/browse/COMPRESS-176 workaround.
It returns 0 for all entries in the example archive, except for two entries 
containing mdash. Those return 11 (sic!).

  was:
Archives created by WinZip on Windows 10 display recurring 
https://issues.apache.org/jira/browse/COMPRESS-176 behaviour, with a new twist.

Attached example archive is created by latest WinZip version 22 build 12663.
It may have been experienced also for WinZip version 18 build 10661 on Windows 
10.

ZipFile.getEntries() for the attached example zip archive return the list of 
entries with the following ZipArchiveEntry.getName():
* "test/"
* "test\\file — mdash.txt"
* "test/ä.txt"
* "test/sub/"
* "test/sub\\file — mdash2.txt"
* "test/sub\\ä2.txt"
ZipArchiveEntry.getPlatform() was essential for the 
https://issues.apache.org/jira/browse/COMPRESS-176 workaround.
It returns 0 for all entries in the example archive, except for two entries 
containing mdash. Those return 11 (sic!).


> ZipFile.getEntries() returns WinZip entries separated by backslash
> --
>
> Key: COMPRESS-427
> URL: https://issues.apache.org/jira/browse/COMPRESS-427
> Project: Commons Compress
>  Issue Type: Bug
>  Components: Archivers
>Affects Versions: 1.10
>Reporter: Yana Lebedeva
>
> Archives created by WinZip on Windows 10 display recurring 
> https://issues.apache.org/jira/browse/COMPRESS-176 behaviour, with a new 
> twist.
> Attached example archive is created by latest WinZip version 22 build 12663.
> It may have been experienced also for WinZip version 18 build 10661 on 
> Windows 10.
> ZipFile.getEntries() for the attached example zip archive return the list of 
> entries with the following ZipArchiveEntry.getName():
> {noformat}
> test/
> test\\file — mdash.txt
> test/ä.txt
> test/sub/
> test/sub\\file — mdash2.txt
> test/sub\\ä2.txt
> {noformat}
> ZipArchiveEntry.getPlatform() was essential for the 
> https://issues.apache.org/jira/browse/COMPRESS-176 workaround.
> It returns 0 for all entries in the example archive, except for two entries 
> containing mdash. Those return 11 (sic!).



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

[jira] [Created] (COMPRESS-427) ZipFile.getEntries() returns WinZip entries separated by backslash

2017-11-06 Thread Yana Lebedeva (JIRA)

Yana Lebedeva created COMPRESS-427:
--

 Summary: ZipFile.getEntries() returns WinZip entries separated by 
backslash
 Key: COMPRESS-427
 URL: https://issues.apache.org/jira/browse/COMPRESS-427
 Project: Commons Compress
  Issue Type: Bug
  Components: Archivers
Affects Versions: 1.10
Reporter: Yana Lebedeva


Archives created by WinZip on Windows 10 display recurring 
https://issues.apache.org/jira/browse/COMPRESS-176 behaviour, with a new twist.

Attached example archive is created by latest WinZip version 22 build 12663.
It may have been experienced also for WinZip version 18 build 10661 on Windows 
10.

ZipFile.getEntries() for the attached example zip archive return the list of 
entries with the following ZipArchiveEntry.getName():
* "test/"
* "test\\file — mdash.txt"
* "test/ä.txt"
* "test/sub/"
* "test/sub\\file — mdash2.txt"
* "test/sub\\ä2.txt"
ZipArchiveEntry.getPlatform() was essential for the 
https://issues.apache.org/jira/browse/COMPRESS-176 workaround.
It returns 0 for all entries in the example archive, except for two entries 
containing mdash. Those return 11 (sic!).



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

[jira] [Commented] (COLLECTIONS-599) HashEntry array object naming data initialized with double the size during deserialization

2017-11-06 Thread mingleizhang (JIRA)


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16241348#comment-16241348
 ] 

mingleizhang commented on COLLECTIONS-599:
--

I suspect that whether this issue belongs to a bug, instead, I think it should 
be a performance issue.

> HashEntry array object naming data initialized with double the size during 
> deserialization
> --
>
> Key: COLLECTIONS-599
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-599
> Project: Commons Collections
>  Issue Type: Bug
>  Components: Collection, Map
>Affects Versions: 3.1
>Reporter: Tejas Patel
>Priority: Critical
> Fix For: 4.1
>
>
> Common collections 3.1 and 3.2 are used at many places and frameworks 
> including struts2. 
> Supose a LinkedMap object it is created and have size greater than zero is 
> serialized. While deserializing this object , array of HashEntry naming data 
> delacred in AbstractHashedMap always initialises with a new capacity of 
> double its double of the serialized object. 
> Please see the below API declared in AbstractHashedMap class :
> {code:java}
> protected void checkCapacity()
>   {
> if (this.size >= this.threshold)
> {
>   int newCapacity = this.data.length * 2;
>   if (newCapacity <= 1073741824) {
> ensureCapacity(newCapacity);
>   }
> }
>   }
> {code}



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

[jira] [Commented] (COLLECTIONS-599) HashEntry array object naming data initialized with double the size during deserialization

2017-11-06 Thread mingleizhang (JIRA)


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16241347#comment-16241347
 ] 

mingleizhang commented on COLLECTIONS-599:
--

I suspect that whether this issue belongs to a bug, instead, I think it should 
be a performance issue.

> HashEntry array object naming data initialized with double the size during 
> deserialization
> --
>
> Key: COLLECTIONS-599
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-599
> Project: Commons Collections
>  Issue Type: Bug
>  Components: Collection, Map
>Affects Versions: 3.1
>Reporter: Tejas Patel
>Priority: Critical
> Fix For: 4.1
>
>
> Common collections 3.1 and 3.2 are used at many places and frameworks 
> including struts2. 
> Supose a LinkedMap object it is created and have size greater than zero is 
> serialized. While deserializing this object , array of HashEntry naming data 
> delacred in AbstractHashedMap always initialises with a new capacity of 
> double its double of the serialized object. 
> Please see the below API declared in AbstractHashedMap class :
> {code:java}
> protected void checkCapacity()
>   {
> if (this.size >= this.threshold)
> {
>   int newCapacity = this.data.length * 2;
>   if (newCapacity <= 1073741824) {
> ensureCapacity(newCapacity);
>   }
> }
>   }
> {code}



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

[jira] [Commented] (COLLECTIONS-599) HashEntry array object naming data initialized with double the size during deserialization

2017-11-06 Thread mingleizhang (JIRA)


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16241304#comment-16241304
 ] 

mingleizhang commented on COLLECTIONS-599:
--

Hi, [~garydgregory] I would think this change should be in 3.X, then 4.X master 
branches can rebase code from 3.X. As I found its affects versions is 3.1.

> HashEntry array object naming data initialized with double the size during 
> deserialization
> --
>
> Key: COLLECTIONS-599
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-599
> Project: Commons Collections
>  Issue Type: Bug
>  Components: Collection, Map
>Affects Versions: 3.1
>Reporter: Tejas Patel
>Priority: Critical
> Fix For: 4.1
>
>
> Common collections 3.1 and 3.2 are used at many places and frameworks 
> including struts2. 
> Supose a LinkedMap object it is created and have size greater than zero is 
> serialized. While deserializing this object , array of HashEntry naming data 
> delacred in AbstractHashedMap always initialises with a new capacity of 
> double its double of the serialized object. 
> Please see the below API declared in AbstractHashedMap class :
> {code:java}
> protected void checkCapacity()
>   {
> if (this.size >= this.threshold)
> {
>   int newCapacity = this.data.length * 2;
>   if (newCapacity <= 1073741824) {
> ensureCapacity(newCapacity);
>   }
> }
>   }
> {code}



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

[jira] [Created] (MATH-1434) FisherTransform and InverseFisherTransform

2017-11-06 Thread nimo mayr (JIRA)

nimo mayr created MATH-1434:
---

 Summary: FisherTransform and InverseFisherTransform
 Key: MATH-1434
 URL: https://issues.apache.org/jira/browse/MATH-1434
 Project: Commons Math
  Issue Type: New Feature
Affects Versions: 3.6.1
 Environment: Please provide the *"Fisher equation" ("Fisher 
transform") and its reverse*.

Thanks.
Reporter: nimo mayr






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

[jira] [Commented] (VFS-635) can't access SMBv2

2017-11-06 Thread JIRA


[ 
https://issues.apache.org/jira/browse/VFS-635?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240535#comment-16240535
 ] 

André Hauenstein commented on VFS-635:
--

I've put some work into it and created a new fork here : 
[https://github.com/ahbonsu/commons-vfs|https://github.com/ahbonsu/commons-vfs]
I'll create a Pull Request when the JUnint tests are in place.


> can't access SMBv2
> --
>
> Key: VFS-635
> URL: https://issues.apache.org/jira/browse/VFS-635
> Project: Commons VFS
>  Issue Type: Wish
>Affects Versions: 2.0, 2.1
>Reporter: Michael
>
> After Disabling SMBV1 in windows I can't access into the filesystem.
> This code works when SMB1 is enabled, but sops to work once disabled.
> {code}
> @Test
> public void testConnection() throws FileSystemException {
>   String login = "admin";
>   String password = "password"; 
>   String domain = "";
>   String folder = "//10.0.0.0/smb";
>   folder = folder.replaceAll("", "/");
>   StringBuilder builder = new 
> StringBuilder(128).append("smb").append(':').append(folder);
>   String fileURI = builder.toString();
>   FileSystemOptions fsOptions = null;
>   StaticUserAuthenticator auth = new 
> StaticUserAuthenticator(domain, login, password);
>   fsOptions = new FileSystemOptions();
>   
> DefaultFileSystemConfigBuilder.getInstance().setUserAuthenticator(fsOptions, 
> auth);
>   FileSystemManager manager = VFS.getManager();
>   FileSystemManager fileSystemManager = manager;
>   FileObject fileObject = fileSystemManager.resolveFile(fileURI, 
> fsOptions);
>   boolean result = fileObject.isReadable();
> System.out.println(fileURI +" " + result);
> }
> {code}
> this is how I disabled smb v1
> Set-ItemProperty -Path 
> "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" SMB1 -Type 
> DWORD -Value 0 -Force
> How I enabled SMBV2
> Set-ItemProperty -Path 
> "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" SMB2 -Type 
> DWORD -Value 1 -Force
> https://support.microsoft.com/en-us/help/2696547/how-to-enable-and-disable-smbv1-smbv2-and-smbv3-in-windows-and-windows-server
> [TRACE]
> {code}
> org.apache.commons.vfs2.FileSystemException: Could not determine if file 
> "smb://10.0.0.0/smb/" is readable.
> at 
> org.apache.commons.vfs2.provider.AbstractFileObject.isReadable(AbstractFileObject.java:1761)
> at com.pa.util.files.FileUtilsTest.testConnection(FileUtilsTest.java:109)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at 
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at 
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at 
> org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at 
> org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:678)
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
> at 
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
> Caused by: org.apache.commons.vfs2.FileSystemException: Could not determine 
> the type

[jira] [Commented] (COLLECTIONS-599) HashEntry array object naming data initialized with double the size during deserialization

2017-11-06 Thread Gary Gregory (JIRA)


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240470#comment-16240470
 ] 

Gary Gregory commented on COLLECTIONS-599:
--

Hi [~mingleizhang],

Please feel free to provide a pull request on GitHub with a unit test.

https://github.com/apache/commons-collections

Are you expecting that such a change would be in the 3.x AND 4.x (master) 
branches?

Gary

> HashEntry array object naming data initialized with double the size during 
> deserialization
> --
>
> Key: COLLECTIONS-599
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-599
> Project: Commons Collections
>  Issue Type: Bug
>  Components: Collection, Map
>Affects Versions: 3.1
>Reporter: Tejas Patel
>Priority: Critical
> Fix For: 4.1
>
>
> Common collections 3.1 and 3.2 are used at many places and frameworks 
> including struts2. 
> Supose a LinkedMap object it is created and have size greater than zero is 
> serialized. While deserializing this object , array of HashEntry naming data 
> delacred in AbstractHashedMap always initialises with a new capacity of 
> double its double of the serialized object. 
> Please see the below API declared in AbstractHashedMap class :
> {code:java}
> protected void checkCapacity()
>   {
> if (this.size >= this.threshold)
> {
>   int newCapacity = this.data.length * 2;
>   if (newCapacity <= 1073741824) {
> ensureCapacity(newCapacity);
>   }
> }
>   }
> {code}



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

[jira] [Comment Edited] (COLLECTIONS-599) HashEntry array object naming data initialized with double the size during deserialization

2017-11-06 Thread Gary Gregory (JIRA)


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15714952#comment-15714952
 ] 

Gary Gregory edited comment on COLLECTIONS-599 at 11/6/17 3:52 PM:
---

Possible fix would be calculating threshold before putting the data in 
doReadObject API. 
Calculating threshold would not initialize the array by double.
Please find the code below : 

{code:java}
protected void doReadObject(ObjectInputStream in)
throws IOException, ClassNotFoundException
  {
this.loadFactor = in.readFloat();
int capacity = in.readInt();
int size = in.readInt();
init();
this.data = new HashEntry[capacity];
this.threshold = calculateThreshold(this.data.length, this.loadFactor);
for (int i = 0; i < size; i++)
{
  Object key = in.readObject();
  Object value = in.readObject();
  put(key, value);
}

  }
{code}

Why these is critical because this version of jar are been used by struts 2 . 
I saw these been changed in version 4.1 , but if you classes in 4.1 are 
declared in different package.
We should have provide fix for these version as we cant change jars which is 
internally using these stuff. 




was (Author: tejast5):
Possible fix would be calculating threshold before putting the data in 
doReadObject API. 
Calculating threshold would not initialize the array by double.
Please find the code below : 

protected void doReadObject(ObjectInputStream in)
throws IOException, ClassNotFoundException
  {
this.loadFactor = in.readFloat();
int capacity = in.readInt();
int size = in.readInt();
init();
this.data = new HashEntry[capacity];
this.threshold = calculateThreshold(this.data.length, this.loadFactor);
for (int i = 0; i < size; i++)
{
  Object key = in.readObject();
  Object value = in.readObject();
  put(key, value);
}

  }

Why these is critical because this version of jar are been used by struts 2 . 
I saw these been changed in version 4.1 , but if you classes in 4.1 are 
declared in different package.
We should have provide fix for these version as we cant change jars which is 
internally using these stuff. 



> HashEntry array object naming data initialized with double the size during 
> deserialization
> --
>
> Key: COLLECTIONS-599
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-599
> Project: Commons Collections
>  Issue Type: Bug
>  Components: Collection, Map
>Affects Versions: 3.1
>Reporter: Tejas Patel
>Priority: Critical
> Fix For: 4.1
>
>
> Common collections 3.1 and 3.2 are used at many places and frameworks 
> including struts2. 
> Supose a LinkedMap object it is created and have size greater than zero is 
> serialized. While deserializing this object , array of HashEntry naming data 
> delacred in AbstractHashedMap always initialises with a new capacity of 
> double its double of the serialized object. 
> Please see the below API declared in AbstractHashedMap class :
> {code:java}
> protected void checkCapacity()
>   {
> if (this.size >= this.threshold)
> {
>   int newCapacity = this.data.length * 2;
>   if (newCapacity <= 1073741824) {
> ensureCapacity(newCapacity);
>   }
> }
>   }
> {code}



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

[jira] [Updated] (COLLECTIONS-599) HashEntry array object naming data initialized with double the size during deserialization

2017-11-06 Thread Gary Gregory (JIRA)


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

Gary Gregory updated COLLECTIONS-599:
-
Description: 
Common collections 3.1 and 3.2 are used at many places and frameworks including 
struts2. 
Supose a LinkedMap object it is created and have size greater than zero is 
serialized. While deserializing this object , array of HashEntry naming data 
delacred in AbstractHashedMap always initialises with a new capacity of double 
its double of the serialized object. 

Please see the below API declared in AbstractHashedMap class :

{code:java}
protected void checkCapacity()
  {
if (this.size >= this.threshold)
{
  int newCapacity = this.data.length * 2;
  if (newCapacity <= 1073741824) {
ensureCapacity(newCapacity);
  }
}
  }
{code}

  was:
Common collections 3.1 and 3.2 are used at many places and frameworks including 
struts2. 
Supose a LinkedMap object it is created and have size greater than zero is 
serialized. While deserializing this object , array of HashEntry naming data 
delacred in AbstractHashedMap always initialises with a new capacity of double 
its double of the serialized object. 

Please see the below API declared in AbstractHashedMap class :

protected void checkCapacity()
  {
if (this.size >= this.threshold)
{
  int newCapacity = this.data.length * 2;
  if (newCapacity <= 1073741824) {
ensureCapacity(newCapacity);
  }
}
  }


> HashEntry array object naming data initialized with double the size during 
> deserialization
> --
>
> Key: COLLECTIONS-599
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-599
> Project: Commons Collections
>  Issue Type: Bug
>  Components: Collection, Map
>Affects Versions: 3.1
>Reporter: Tejas Patel
>Priority: Critical
> Fix For: 4.1
>
>
> Common collections 3.1 and 3.2 are used at many places and frameworks 
> including struts2. 
> Supose a LinkedMap object it is created and have size greater than zero is 
> serialized. While deserializing this object , array of HashEntry naming data 
> delacred in AbstractHashedMap always initialises with a new capacity of 
> double its double of the serialized object. 
> Please see the below API declared in AbstractHashedMap class :
> {code:java}
> protected void checkCapacity()
>   {
> if (this.size >= this.threshold)
> {
>   int newCapacity = this.data.length * 2;
>   if (newCapacity <= 1073741824) {
> ensureCapacity(newCapacity);
>   }
> }
>   }
> {code}



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

[jira] [Resolved] (JEXL-244) Webapp classloader memory leaks

2017-11-06 Thread Henri Biestro (JIRA)


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

Henri Biestro resolved JEXL-244.

   Resolution: Fixed
Fix Version/s: 3.2

I'm respectfully skeptical that the leak you are reporting originates from a 
static inner class definition. I've been unable to find another occurence of 
such a problem (stack overflow, Google...).
Nevertheless, long standing working relationship grants benefits. :-)
Please report if this fixes things on your end.


Committed revision 1814413.
trunk/RELEASE-NOTES.txt
trunk/src/main/java/org/apache/commons/jexl3/JexlEngine.java
trunk/src/site/xdoc/changes.xml

> Webapp classloader memory leaks
> ---
>
> Key: JEXL-244
> URL: https://issues.apache.org/jira/browse/JEXL-244
> Project: Commons JEXL
>  Issue Type: Bug
>Affects Versions: 3.1
> Environment: Inside J2EE container when Jexl library is included in 
> the deployed .war file
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
> Fix For: 3.2
>
>
> I have spotted that the following constructions, like for example in 
> JexlEngine.java
> {code}
> public static final Object TRY_FAILED = new Object() {
> @Override
> public String toString() {
> return "tryExecute failed";
> }
> };
> {code}
> are not garbage collected when web-app is reloaded and its classloader is 
> released. This is because circular references are created when static class 
> members are initialized with non-static inner/anonymous classes, which are 
> holding implicit references to its enclosing class and thus to its static 
> class type. There are other such examples in JexlEngine.java like
> {code}
> protected static final java.lang.ThreadLocal 
> CONTEXT = new java.lang.ThreadLocal() {..
> protected static final java.lang.ThreadLocal ENGINE =
> new java.lang.ThreadLocal() {...
> {code}
> The issue is easily resolved if for example the following pattern is followed
> {code}
> public static class FailObject extends Object {
> @Override
> public String toString() {
> return "tryExecute failed";
> }
> }
> public static final Object TRY_FAILED = new FailObject();
> {code}



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

[jira] [Updated] (JEXL-244) Webapp classloader memory leaks

2017-11-06 Thread Henri Biestro (JIRA)


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

Henri Biestro updated JEXL-244:
---
Assignee: Henri Biestro

> Webapp classloader memory leaks
> ---
>
> Key: JEXL-244
> URL: https://issues.apache.org/jira/browse/JEXL-244
> Project: Commons JEXL
>  Issue Type: Bug
>Affects Versions: 3.1
> Environment: Inside J2EE container when Jexl library is included in 
> the deployed .war file
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>
> I have spotted that the following constructions, like for example in 
> JexlEngine.java
> {code}
> public static final Object TRY_FAILED = new Object() {
> @Override
> public String toString() {
> return "tryExecute failed";
> }
> };
> {code}
> are not garbage collected when web-app is reloaded and its classloader is 
> released. This is because circular references are created when static class 
> members are initialized with non-static inner/anonymous classes, which are 
> holding implicit references to its enclosing class and thus to its static 
> class type. There are other such examples in JexlEngine.java like
> {code}
> protected static final java.lang.ThreadLocal 
> CONTEXT = new java.lang.ThreadLocal() {..
> protected static final java.lang.ThreadLocal ENGINE =
> new java.lang.ThreadLocal() {...
> {code}
> The issue is easily resolved if for example the following pattern is followed
> {code}
> public static class FailObject extends Object {
> @Override
> public String toString() {
> return "tryExecute failed";
> }
> }
> public static final Object TRY_FAILED = new FailObject();
> {code}



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

[jira] [Commented] (CODEC-240) Support Percent-Encoding (described in RFC3986 and RFC7578)

2017-11-06 Thread Ioannis Sermetziadis (JIRA)


[ 
https://issues.apache.org/jira/browse/CODEC-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240223#comment-16240223
 ] 

Ioannis Sermetziadis commented on CODEC-240:


Could someone review this pull-request? Thank you.

> Support Percent-Encoding (described in RFC3986 and RFC7578)
> ---
>
> Key: CODEC-240
> URL: https://issues.apache.org/jira/browse/CODEC-240
> Project: Commons Codec
>  Issue Type: New Feature
>Reporter: Ioannis Sermetziadis
>Priority: Minor
>
> Similar but more generic than the URLCodec.



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

[jira] [Created] (EMAIL-175) MimeMessageParser should throw more specific exceptions

2017-11-06 Thread Dave Kimber (JIRA)

Dave Kimber created EMAIL-175:
-

 Summary: MimeMessageParser should throw more specific exceptions
 Key: EMAIL-175
 URL: https://issues.apache.org/jira/browse/EMAIL-175
 Project: Commons Email
  Issue Type: Improvement
Affects Versions: 1.5
Reporter: Dave Kimber
Priority: Minor


The following methods on MimeMessageParser all throw Exception:
{code}
parse() throws Exception
getTo() throws Exception
getCc() throws Exception
getBcc() throws Exception
getFrom() throws Exception
getReplyTo() throws Exception
getSubject() throws Exception
{code}

They can all throw more specific exception types:
{code}
parse() throws MessagingException, IOException
getTo() throws MessagingException
getCc() throws MessagingException
getBcc() throws MessagingException
getFrom() throws MessagingException
getReplyTo() throws MessagingException
getSubject() throws MessagingException
{code}



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

[jira] [Commented] (COLLECTIONS-664) Add class FileProperties to load file name directly

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


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240171#comment-16240171
 ] 

ASF GitHub Bot commented on COLLECTIONS-664:


Github user zhangminglei commented on the issue:

https://github.com/apache/commons-collections/pull/33
  
Thanks @kinow . I would move this PR to Commons/Configuration. I just not 
sure which component is the best to put it.


> Add class FileProperties to load file name directly
> ---
>
> Key: COLLECTIONS-664
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-664
> Project: Commons Collections
>  Issue Type: New Feature
>Reporter: mingleizhang
>
> For example, In some interface, needs we have a {{java.util.Properties}} as a 
> parameter. In common case, we have different profiles in maven under 
> different environments that we can random selection. And use the current 
> classloader, usually belongs to AppclassLoader to get it's inputstream. I 
> propose we should add a functionality that can directly read a file name and 
> return a {{java.util.Properties}} as a return value. 



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

[jira] [Commented] (COLLECTIONS-664) Add class FileProperties to load file name directly

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


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240124#comment-16240124
 ] 

ASF GitHub Bot commented on COLLECTIONS-664:


Github user kinow commented on the issue:

https://github.com/apache/commons-collections/pull/33
  
Thanks for the clear response Minglei! And thanks for your contribution. 
Let's see what others think :+1: 


> Add class FileProperties to load file name directly
> ---
>
> Key: COLLECTIONS-664
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-664
> Project: Commons Collections
>  Issue Type: New Feature
>Reporter: mingleizhang
>
> For example, In some interface, needs we have a {{java.util.Properties}} as a 
> parameter. In common case, we have different profiles in maven under 
> different environments that we can random selection. And use the current 
> classloader, usually belongs to AppclassLoader to get it's inputstream. I 
> propose we should add a functionality that can directly read a file name and 
> return a {{java.util.Properties}} as a return value. 



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

[jira] [Issue Comment Deleted] (CONFIGURATION-674) Add class FileProperties to load file name directly

2017-11-06 Thread mingleizhang (JIRA)


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

mingleizhang updated CONFIGURATION-674:
---
Comment: was deleted

(was: I think it is not suitable to put this jira here. So, change it to 
Commons Collections. )

> Add class FileProperties to load file name directly
> ---
>
> Key: CONFIGURATION-674
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-674
> Project: Commons Configuration
>  Issue Type: New Feature
>  Components: File reloading
>Reporter: mingleizhang
>
> For example, In some interface, needs we have a {{java.util.Properties}} as a 
> parameter. In common case, we have different profiles in maven under 
> different environments that we can random selection. And use the current 
> classloader, usually belongs to AppclassLoader to get it's inputstream. I 
> propose we should add a functionality that can directly read a file name and 
> return a {{java.util.Properties}} as a return value. 



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

[jira] [Commented] (COLLECTIONS-664) Add class FileProperties to load file name directly

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


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240122#comment-16240122
 ] 

ASF GitHub Bot commented on COLLECTIONS-664:


Github user zhangminglei commented on the issue:

https://github.com/apache/commons-collections/pull/33
  
Hello, @kinow  Thanks for your reply! 

- Why Commons Collections?. I am not sure which is the best address I 
should put it. At the beginning, I created the JIRA under Commons 
Configuration, like you said at the second point. Then I changed my mind.

- As refers to the file name, yea. I think I should give an appropriate 
name for it, instead of FileProperties.

- I agree with you at this point, before I did this, I searched for a long 
time for this functionality in Commons Configuration. But I could not find it. 

Yes. I will send a message to dev mail list.

Thanks
Minglei


> Add class FileProperties to load file name directly
> ---
>
> Key: COLLECTIONS-664
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-664
> Project: Commons Collections
>  Issue Type: New Feature
>Reporter: mingleizhang
>
> For example, In some interface, needs we have a {{java.util.Properties}} as a 
> parameter. In common case, we have different profiles in maven under 
> different environments that we can random selection. And use the current 
> classloader, usually belongs to AppclassLoader to get it's inputstream. I 
> propose we should add a functionality that can directly read a file name and 
> return a {{java.util.Properties}} as a return value. 



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

[jira] [Commented] (COLLECTIONS-664) Add class FileProperties to load file name directly

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


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240097#comment-16240097
 ] 

ASF GitHub Bot commented on COLLECTIONS-664:


Github user kinow commented on the issue:

https://github.com/apache/commons-collections/pull/33
  
Hi @zhangminglei !

Sure. Few questions from reviewing the JIRA ticket and the pull request.

* Why Commons Collections? The SortedProperties uses Java collection 
classes to sort its keys. But FileProperties doesn't seem to have much to do 
with Java collections.
* The name of the class doesn't really suggest what it does. Unless there 
are other use cases, we could be more specific about the class name.
* However, I suspect this code belongs more to the user code, and not 
really to the low level library. Might be better to update the ticket to 
Commons Configuration maybe (?), and send a message to the development mailing 
list in case you don't hear back within some days.

The code is well written, and with tests :-) we just need to review the use 
case, and which component could host it.

Hope it helps
Bruno


> Add class FileProperties to load file name directly
> ---
>
> Key: COLLECTIONS-664
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-664
> Project: Commons Collections
>  Issue Type: New Feature
>Reporter: mingleizhang
>
> For example, In some interface, needs we have a {{java.util.Properties}} as a 
> parameter. In common case, we have different profiles in maven under 
> different environments that we can random selection. And use the current 
> classloader, usually belongs to AppclassLoader to get it's inputstream. I 
> propose we should add a functionality that can directly read a file name and 
> return a {{java.util.Properties}} as a return value. 



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

[jira] [Commented] (COLLECTIONS-664) Add class FileProperties to load file name directly

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


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240085#comment-16240085
 ] 

ASF GitHub Bot commented on COLLECTIONS-664:


Github user zhangminglei commented on the issue:

https://github.com/apache/commons-collections/pull/33
  
The CI error seems does not relevant to this PR.


> Add class FileProperties to load file name directly
> ---
>
> Key: COLLECTIONS-664
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-664
> Project: Commons Collections
>  Issue Type: New Feature
>Reporter: mingleizhang
>
> For example, In some interface, needs we have a {{java.util.Properties}} as a 
> parameter. In common case, we have different profiles in maven under 
> different environments that we can random selection. And use the current 
> classloader, usually belongs to AppclassLoader to get it's inputstream. I 
> propose we should add a functionality that can directly read a file name and 
> return a {{java.util.Properties}} as a return value. 



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

[jira] [Commented] (COLLECTIONS-664) Add class FileProperties to load file name directly

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


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240074#comment-16240074
 ] 

ASF GitHub Bot commented on COLLECTIONS-664:


Github user zhangminglei commented on the issue:

https://github.com/apache/commons-collections/pull/33
  
Hello, @kinow, Could you please take a look on this PR? Thanks!


> Add class FileProperties to load file name directly
> ---
>
> Key: COLLECTIONS-664
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-664
> Project: Commons Collections
>  Issue Type: New Feature
>Reporter: mingleizhang
>
> For example, In some interface, needs we have a {{java.util.Properties}} as a 
> parameter. In common case, we have different profiles in maven under 
> different environments that we can random selection. And use the current 
> classloader, usually belongs to AppclassLoader to get it's inputstream. I 
> propose we should add a functionality that can directly read a file name and 
> return a {{java.util.Properties}} as a return value. 



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

[jira] [Commented] (COLLECTIONS-664) Add class FileProperties to load file name directly

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


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240047#comment-16240047
 ] 

ASF GitHub Bot commented on COLLECTIONS-664:


Github user coveralls commented on the issue:

https://github.com/apache/commons-collections/pull/33
  

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

Coverage increased (+0.006%) to 86.622% when pulling 
**3ee56fdce999bcf5164c0339601546c2b9b2cd70 on zhangminglei:COLLECTIONS-664** 
into **0b1460dadb5934ebeb0c1c6ef79992606cdb91f0 on apache:master**.



> Add class FileProperties to load file name directly
> ---
>
> Key: COLLECTIONS-664
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-664
> Project: Commons Collections
>  Issue Type: New Feature
>Reporter: mingleizhang
>
> For example, In some interface, needs we have a {{java.util.Properties}} as a 
> parameter. In common case, we have different profiles in maven under 
> different environments that we can random selection. And use the current 
> classloader, usually belongs to AppclassLoader to get it's inputstream. I 
> propose we should add a functionality that can directly read a file name and 
> return a {{java.util.Properties}} as a return value. 



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

[jira] [Commented] (COLLECTIONS-664) Add class FileProperties to load file name directly

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


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240043#comment-16240043
 ] 

ASF GitHub Bot commented on COLLECTIONS-664:


GitHub user zhangminglei opened a pull request:

https://github.com/apache/commons-collections/pull/33

[COLLECTIONS-664] Add a class that extend a load method which accept …

…a filename.

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

$ git pull https://github.com/zhangminglei/commons-collections 
COLLECTIONS-664

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

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


commit 3ee56fdce999bcf5164c0339601546c2b9b2cd70
Author: zhangminglei 
Date:   2017-11-06T09:06:47Z

[COLLECTIONS-664] Add a class that extend a load method which accept a 
filename.




> Add class FileProperties to load file name directly
> ---
>
> Key: COLLECTIONS-664
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-664
> Project: Commons Collections
>  Issue Type: New Feature
>Reporter: mingleizhang
>
> For example, In some interface, needs we have a {{java.util.Properties}} as a 
> parameter. In common case, we have different profiles in maven under 
> different environments that we can random selection. And use the current 
> classloader, usually belongs to AppclassLoader to get it's inputstream. I 
> propose we should add a functionality that can directly read a file name and 
> return a {{java.util.Properties}} as a return value. 



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

[jira] [Commented] (COLLECTIONS-664) Add class FileProperties to load file name directly

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


[ 
https://issues.apache.org/jira/browse/COLLECTIONS-664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240044#comment-16240044
 ] 

ASF GitHub Bot commented on COLLECTIONS-664:


GitHub user zhangminglei opened a pull request:

https://github.com/apache/commons-collections/pull/33

[COLLECTIONS-664] Add a class that extend a load method which accept …

…a filename.

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

$ git pull https://github.com/zhangminglei/commons-collections 
COLLECTIONS-664

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

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


commit 3ee56fdce999bcf5164c0339601546c2b9b2cd70
Author: zhangminglei 
Date:   2017-11-06T09:06:47Z

[COLLECTIONS-664] Add a class that extend a load method which accept a 
filename.




> Add class FileProperties to load file name directly
> ---
>
> Key: COLLECTIONS-664
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-664
> Project: Commons Collections
>  Issue Type: New Feature
>Reporter: mingleizhang
>
> For example, In some interface, needs we have a {{java.util.Properties}} as a 
> parameter. In common case, we have different profiles in maven under 
> different environments that we can random selection. And use the current 
> classloader, usually belongs to AppclassLoader to get it's inputstream. I 
> propose we should add a functionality that can directly read a file name and 
> return a {{java.util.Properties}} as a return value. 



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

[jira] [Updated] (COLLECTIONS-664) Add class FileProperties to load file name directly

2017-11-06 Thread mingleizhang (JIRA)


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

mingleizhang updated COLLECTIONS-664:
-
Description: For example, In some interface, needs we have a 
{{java.util.Properties}} as a parameter. In common case, we have different 
profiles in maven under different environments that we can random selection. 
And use the current classloader, usually belongs to AppclassLoader to get it's 
inputstream. I propose we should add a functionality that can directly read a 
file name and return a {{java.util.Properties}} as a return value. 

> Add class FileProperties to load file name directly
> ---
>
> Key: COLLECTIONS-664
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-664
> Project: Commons Collections
>  Issue Type: New Feature
>Reporter: mingleizhang
>
> For example, In some interface, needs we have a {{java.util.Properties}} as a 
> parameter. In common case, we have different profiles in maven under 
> different environments that we can random selection. And use the current 
> classloader, usually belongs to AppclassLoader to get it's inputstream. I 
> propose we should add a functionality that can directly read a file name and 
> return a {{java.util.Properties}} as a return value. 



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

[jira] [Created] (COLLECTIONS-664) Add class FileProperties to load file name directly

2017-11-06 Thread mingleizhang (JIRA)

mingleizhang created COLLECTIONS-664:


 Summary: Add class FileProperties to load file name directly
 Key: COLLECTIONS-664
 URL: https://issues.apache.org/jira/browse/COLLECTIONS-664
 Project: Commons Collections
  Issue Type: New Feature
Reporter: mingleizhang






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

[jira] [Commented] (IO-554) FileUtils.copyToFile(InputStream source, File destination) closes input stream

2017-11-06 Thread Bernd Eckenfels (JIRA)


[ 
https://issues.apache.org/jira/browse/IO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240022#comment-16240022
 ] 

Bernd Eckenfels commented on IO-554:


2.5 and before did not close the file. So this is a change which violates the 
Javadoc spec and was introduced in 2.6, this is IMHO enough justification to 
revert to the documented behavior. Of course the releasenotes for 2.7 should 
have a fat warning about this.

> FileUtils.copyToFile(InputStream source, File destination) closes input stream
> --
>
> Key: IO-554
> URL: https://issues.apache.org/jira/browse/IO-554
> Project: Commons IO
>  Issue Type: Bug
>  Components: Streams/Writers
>Affects Versions: 2.6
>Reporter: Michele Mariotti
>Assignee: Bruno P. Kinoshita
>Priority: Blocker
>  Labels: regression
> Fix For: 2.7
>
>
> In 2.6 this method is closing the input stream, while the javadoc states the 
> opposite.
> The correct behavior is to leave the stream open, as stated in the javadoc.
> I assigned a high priority because this incorrect behavior breaks existing 
> code, especially when used in combination with ZipInputStream.
> {code:java}
> /**
>  * Copies bytes from an {@link InputStream} source to a file
>  * destination. The directories up to destination
>  * will be created if they don't already exist. destination
>  * will be overwritten if it already exists.
>  * The {@code source} stream is left open, e.g. for use with {@link 
> java.util.zip.ZipInputStream ZipInputStream}.
>  * See {@link #copyInputStreamToFile(InputStream, File)} for a method that 
> closes the input stream.
>  *
>  * @param source  the InputStream to copy bytes from, must 
> not be {@code null}
>  * @param destination the non-directory File to write bytes to
>  *(possibly overwriting), must not be {@code null}
>  * @throws IOException if destination is a directory
>  * @throws IOException if destination cannot be written
>  * @throws IOException if destination needs creating but can't be
>  * @throws IOException if an IO error occurs during copying
>  * @since 2.5
>  */
> public static void copyToFile(final InputStream source, final File 
> destination) throws IOException {
>   try (InputStream in = source;
>OutputStream out = openOutputStream(destination)) {
>   IOUtils.copy(in, out);
>   }
> }
> {code}
> instead it should be:
> {code:java}
> public static void copyToFile(final InputStream source, final File 
> destination) throws IOException {
>   try (OutputStream out = openOutputStream(destination)) {
>   IOUtils.copy(source, out);
>   }
> }{code}



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

[jira] [Commented] (CONFIGURATION-674) Add class FileProperties to load file name directly

2017-11-06 Thread mingleizhang (JIRA)


[ 
https://issues.apache.org/jira/browse/CONFIGURATION-674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240020#comment-16240020
 ] 

mingleizhang commented on CONFIGURATION-674:


I think it is not suitable to put this jira here. So, change it to Commons 
Collections. 

> Add class FileProperties to load file name directly
> ---
>
> Key: CONFIGURATION-674
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-674
> Project: Commons Configuration
>  Issue Type: New Feature
>  Components: File reloading
>Reporter: mingleizhang
>
> For example, In some interface, needs we have a {{java.util.Properties}} as a 
> parameter. In common case, we have different profiles in maven under 
> different environments that we can random selection. And use the current 
> classloader, usually belongs to AppclassLoader to get it's inputstream. I 
> propose we should add a functionality that can directly read a file name and 
> return a {{java.util.Properties}} as a return value. 



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

[jira] [Commented] (IO-554) FileUtils.copyToFile(InputStream source, File destination) closes input stream

2017-11-06 Thread Bruno P. Kinoshita (JIRA)


[ 
https://issues.apache.org/jira/browse/IO-554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16240019#comment-16240019
 ] 

Bruno P. Kinoshita commented on IO-554:
---

>Fact is, if we pull that one in, then the next version will behave different, 
>which makes it binary incompatible.

I **think** it would be behavioural imcompatible per [1] and [2]. But I may be 
wrong.

>Perhaps, a discussion on devs@commons is in order.

+1, others would be able to clear up any confusion and having a consensus on 
this now would be better than waiting to discuss it during a release vote. 
Shall I start the thread?

[1] https://docs.oracle.com/javase/specs/jls/se7/html/jls-13.html#jls-13.2
[2] 
https://blogs.oracle.com/darcy/kinds-of-compatibility:-source,-binary,-and-behavioral

> FileUtils.copyToFile(InputStream source, File destination) closes input stream
> --
>
> Key: IO-554
> URL: https://issues.apache.org/jira/browse/IO-554
> Project: Commons IO
>  Issue Type: Bug
>  Components: Streams/Writers
>Affects Versions: 2.6
>Reporter: Michele Mariotti
>Assignee: Bruno P. Kinoshita
>Priority: Blocker
>  Labels: regression
> Fix For: 2.7
>
>
> In 2.6 this method is closing the input stream, while the javadoc states the 
> opposite.
> The correct behavior is to leave the stream open, as stated in the javadoc.
> I assigned a high priority because this incorrect behavior breaks existing 
> code, especially when used in combination with ZipInputStream.
> {code:java}
> /**
>  * Copies bytes from an {@link InputStream} source to a file
>  * destination. The directories up to destination
>  * will be created if they don't already exist. destination
>  * will be overwritten if it already exists.
>  * The {@code source} stream is left open, e.g. for use with {@link 
> java.util.zip.ZipInputStream ZipInputStream}.
>  * See {@link #copyInputStreamToFile(InputStream, File)} for a method that 
> closes the input stream.
>  *
>  * @param source  the InputStream to copy bytes from, must 
> not be {@code null}
>  * @param destination the non-directory File to write bytes to
>  *(possibly overwriting), must not be {@code null}
>  * @throws IOException if destination is a directory
>  * @throws IOException if destination cannot be written
>  * @throws IOException if destination needs creating but can't be
>  * @throws IOException if an IO error occurs during copying
>  * @since 2.5
>  */
> public static void copyToFile(final InputStream source, final File 
> destination) throws IOException {
>   try (InputStream in = source;
>OutputStream out = openOutputStream(destination)) {
>   IOUtils.copy(in, out);
>   }
> }
> {code}
> instead it should be:
> {code:java}
> public static void copyToFile(final InputStream source, final File 
> destination) throws IOException {
>   try (OutputStream out = openOutputStream(destination)) {
>   IOUtils.copy(source, out);
>   }
> }{code}



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

37 matches

Mail list logo