[jira] [Commented] (LANG-1228) IllegalAccessException swallowed in indexOfThrowable and indexOfType
[
https://issues.apache.org/jira/browse/LANG-1228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15277567#comment-15277567
]
ASF GitHub Bot commented on LANG-1228:
--
Github user bdhess commented on the pull request:
https://github.com/apache/commons-lang/pull/139#issuecomment-218052683
For convenience: https://issues.apache.org/jira/browse/LANG-1228
> IllegalAccessException swallowed in indexOfThrowable and indexOfType
>
>
> Key: LANG-1228
> URL: https://issues.apache.org/jira/browse/LANG-1228
> Project: Commons Lang
> Issue Type: Bug
>Reporter: Bradley Hess
>Priority: Minor
>
> If {{ExceptionUtils.getCause}} is provided a throwable whose cause method
> cannot be interrogated by reflection due to an IllegalAccessError, the cause
> is not presented to the client.
> In principle this is to be expected from this legacy method. However,
> {{indexOfThrowable}} and {{indexOfType}} rely on {{getCause}}, and are not
> marked as deprecated.
> Now that {{Throwable.getCause}} has been in the language for quite some time,
> I'd like to propose that, until {{ExceptionUtils.getCause}} is actually
> removed, that its behavior be modified to first attempt to get the exception
> cause using normal invocation, falling back to reflection if no cause is
> found.
> I'll be pushing a GitHub PR to this effect.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] commons-lang pull request: [LANG-1228] Prefer Throwable.getCause()...
Github user bdhess commented on the pull request: https://github.com/apache/commons-lang/pull/139#issuecomment-218052683 For convenience: https://issues.apache.org/jira/browse/LANG-1228 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (LANG-1228) IllegalAccessException swallowed in indexOfThrowable and indexOfType
[
https://issues.apache.org/jira/browse/LANG-1228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15277564#comment-15277564
]
ASF GitHub Bot commented on LANG-1228:
--
GitHub user bdhess opened a pull request:
https://github.com/apache/commons-lang/pull/139
[LANG-1228] Prefer Throwable.getCause() in ExceptionUtils.getCause()
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/bdhess/commons-lang get-cause
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/commons-lang/pull/139.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 #139
commit 2644ee0afc6fbc36f4f00990e4bffc55ca588f3f
Author: Bradley Hess
Date: 2016-05-10T03:38:13Z
[LANG-1228] Prefer Throwable.getCause() in ExceptionUtils.getCause()
> IllegalAccessException swallowed in indexOfThrowable and indexOfType
>
>
> Key: LANG-1228
> URL: https://issues.apache.org/jira/browse/LANG-1228
> Project: Commons Lang
> Issue Type: Bug
>Reporter: Bradley Hess
>Priority: Minor
>
> If {{ExceptionUtils.getCause}} is provided a throwable whose cause method
> cannot be interrogated by reflection due to an IllegalAccessError, the cause
> is not presented to the client.
> In principle this is to be expected from this legacy method. However,
> {{indexOfThrowable}} and {{indexOfType}} rely on {{getCause}}, and are not
> marked as deprecated.
> Now that {{Throwable.getCause}} has been in the language for quite some time,
> I'd like to propose that, until {{ExceptionUtils.getCause}} is actually
> removed, that its behavior be modified to first attempt to get the exception
> cause using normal invocation, falling back to reflection if no cause is
> found.
> I'll be pushing a GitHub PR to this effect.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] commons-lang pull request: [LANG-1228] Prefer Throwable.getCause()...
GitHub user bdhess opened a pull request: https://github.com/apache/commons-lang/pull/139 [LANG-1228] Prefer Throwable.getCause() in ExceptionUtils.getCause() You can merge this pull request into a Git repository by running: $ git pull https://github.com/bdhess/commons-lang get-cause Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/139.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 #139 commit 2644ee0afc6fbc36f4f00990e4bffc55ca588f3f Author: Bradley Hess Date: 2016-05-10T03:38:13Z [LANG-1228] Prefer Throwable.getCause() in ExceptionUtils.getCause() --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Created] (LANG-1228) IllegalAccessException swallowed in indexOfThrowable and indexOfType
Bradley Hess created LANG-1228:
--
Summary: IllegalAccessException swallowed in indexOfThrowable and
indexOfType
Key: LANG-1228
URL: https://issues.apache.org/jira/browse/LANG-1228
Project: Commons Lang
Issue Type: Bug
Reporter: Bradley Hess
Priority: Minor
If {{ExceptionUtils.getCause}} is provided a throwable whose cause method
cannot be interrogated by reflection due to an IllegalAccessError, the cause is
not presented to the client.
In principle this is to be expected from this legacy method. However,
{{indexOfThrowable}} and {{indexOfType}} rely on {{getCause}}, and are not
marked as deprecated.
Now that {{Throwable.getCause}} has been in the language for quite some time,
I'd like to propose that, until {{ExceptionUtils.getCause}} is actually
removed, that its behavior be modified to first attempt to get the exception
cause using normal invocation, falling back to reflection if no cause is found.
I'll be pushing a GitHub PR to this effect.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CSV-182) Allow some printing operations directly from CSVFormat
[ https://issues.apache.org/jira/browse/CSV-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated CSV-182: - Attachment: commons-csv-182.diff > Allow some printing operations directly from CSVFormat > -- > > Key: CSV-182 > URL: https://issues.apache.org/jira/browse/CSV-182 > Project: Commons CSV > Issue Type: Improvement > Components: Printer >Affects Versions: 1.3 > Environment: Apache Maven 3.3.9 > (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00) > Maven home: E:\Java\apache-maven-3.3.9\bin\.. > Java version: 1.7.0_79, vendor: Oracle Corporation > Java home: C:\Program Files\Java\jdk1.7.0_79\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 1.4 > > Attachments: commons-csv-182.diff > > > Over in Apache Log4j-land, we are working on a GC-free logging epic. > We try hard to generate as few objects as possible. Right now, we create one > CSVPrinter per logging event to create a CSV line for that event. > In order to get the best memory profile and performance, this ticket proposes > to refactor the CSVPrinter and CSVFormat objects to allow a subset of print > operations directly from the CSVFormat object. > I tested this patch with the Log4j Git master and it works. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CSV-181) Make CSVPrinter.print(Object) GC-free
[ https://issues.apache.org/jira/browse/CSV-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated CSV-181: - Fix Version/s: 1.4 > Make CSVPrinter.print(Object) GC-free > - > > Key: CSV-181 > URL: https://issues.apache.org/jira/browse/CSV-181 > Project: Commons CSV > Issue Type: Improvement > Components: Printer >Affects Versions: 1.2, 1.3 > Environment: Apache Maven 3.3.9 > (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00) > Maven home: E:\Java\apache-maven-3.3.9\bin\.. > Java version: 1.8.0_91, vendor: Oracle Corporation > Java home: C:\Program Files\Java\jdk1.8.0_91\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos" >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 1.3.1, 1.4 > > Attachments: csv-181-gg.diff > > > Make CSVPrinter.print(Object) GC-free. > One of the goals for Apache Log4j 2.6 is GC-free use cases. Log4j uses > Commons CSV for its CSV layout. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CSV-182) Allow some printing operations directly from CSVFormat
Gary Gregory created CSV-182: Summary: Allow some printing operations directly from CSVFormat Key: CSV-182 URL: https://issues.apache.org/jira/browse/CSV-182 Project: Commons CSV Issue Type: Improvement Components: Printer Affects Versions: 1.3 Environment: Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00) Maven home: E:\Java\apache-maven-3.3.9\bin\.. Java version: 1.7.0_79, vendor: Oracle Corporation Java home: C:\Program Files\Java\jdk1.7.0_79\jre Default locale: en_US, platform encoding: Cp1252 OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" Reporter: Gary Gregory Assignee: Gary Gregory Over in Apache Log4j-land, we are working on a GC-free logging epic. We try hard to generate as few objects as possible. Right now, we create one CSVPrinter per logging event to create a CSV line for that event. In order to get the best memory profile and performance, this ticket proposes to refactor the CSVPrinter and CSVFormat objects to allow a subset of print operations directly from the CSVFormat object. I tested this patch with the Log4j Git master and it works. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CSV-182) Allow some printing operations directly from CSVFormat
[ https://issues.apache.org/jira/browse/CSV-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated CSV-182: - Fix Version/s: 1.4 > Allow some printing operations directly from CSVFormat > -- > > Key: CSV-182 > URL: https://issues.apache.org/jira/browse/CSV-182 > Project: Commons CSV > Issue Type: Improvement > Components: Printer >Affects Versions: 1.3 > Environment: Apache Maven 3.3.9 > (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00) > Maven home: E:\Java\apache-maven-3.3.9\bin\.. > Java version: 1.7.0_79, vendor: Oracle Corporation > Java home: C:\Program Files\Java\jdk1.7.0_79\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows" >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 1.4 > > > Over in Apache Log4j-land, we are working on a GC-free logging epic. > We try hard to generate as few objects as possible. Right now, we create one > CSVPrinter per logging event to create a CSV line for that event. > In order to get the best memory profile and performance, this ticket proposes > to refactor the CSVPrinter and CSVFormat objects to allow a subset of print > operations directly from the CSVFormat object. > I tested this patch with the Log4j Git master and it works. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CRYPTO-57) Fix build on Mac OS
[ https://issues.apache.org/jira/browse/CRYPTO-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated CRYPTO-57: -- Description: Fix build on Mac OS, by explicitly adding OpenSSL 101 libraries to Makefile.common. See https://github.com/apache/commons-crypto/pull/42 (was: Fix build on Mac OS, by explicitly adding OpenSSL 101 libraries to Makefile.common.) > Fix build on Mac OS > --- > > Key: CRYPTO-57 > URL: https://issues.apache.org/jira/browse/CRYPTO-57 > Project: Commons Crypto > Issue Type: Improvement > Components: Build >Affects Versions: 1.0.0 >Reporter: Benedikt Ritter > Fix For: 1.0.0 > > > Fix build on Mac OS, by explicitly adding OpenSSL 101 libraries to > Makefile.common. See https://github.com/apache/commons-crypto/pull/42 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CRYPTO-57) Fix build on Mac OS
Benedikt Ritter created CRYPTO-57: - Summary: Fix build on Mac OS Key: CRYPTO-57 URL: https://issues.apache.org/jira/browse/CRYPTO-57 Project: Commons Crypto Issue Type: Improvement Components: Build Affects Versions: 1.0.0 Reporter: Benedikt Ritter Fix For: 1.0.0 Fix build on Mac OS, by explicitly adding OpenSSL 101 libraries to Makefile.common. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (VFS-609) VFS SFTP doesn't support a private key as byte array
[ https://issues.apache.org/jira/browse/VFS-609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15276745#comment-15276745 ] stevezhuang edited comment on VFS-609 at 5/9/16 6:19 PM: - I've provided a patch to support so, please double check and consider adding into your source codes. Thanks! was (Author: stevezhuang): I've provided a patch to support so, please double view and consider adding into your source codes. Thanks! > VFS SFTP doesn't support a private key as byte array > > > Key: VFS-609 > URL: https://issues.apache.org/jira/browse/VFS-609 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 2.1 > Environment: Java client running on Windows 7 >Reporter: stevezhuang >Priority: Minor > Attachments: IdentityInfo.java, SftpClientFactory.java > > > Sometimes we would store the private key as a string\bytes in the remote > server site, and then access the SFTP functions, > The JSCH API already provides a possibility to add the private key as bytes, > while VFS doesn't support so, > JSch.java > public void addIdentity(String name, byte[] prvkey, byte[] pubkey, byte[] > passphrase) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (VFS-609) VFS SFTP doesn't support a private key as byte array
[ https://issues.apache.org/jira/browse/VFS-609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stevezhuang updated VFS-609: Attachment: SftpClientFactory.java IdentityInfo.java I've provided a patch to support so, please double view and consider adding into your source codes. Thanks! > VFS SFTP doesn't support a private key as byte array > > > Key: VFS-609 > URL: https://issues.apache.org/jira/browse/VFS-609 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 2.1 > Environment: Java client running on Windows 7 >Reporter: stevezhuang >Priority: Minor > Attachments: IdentityInfo.java, SftpClientFactory.java > > > Sometimes we would store the private key as a string\bytes in the remote > server site, and then access the SFTP functions, > The JSCH API already provides a possibility to add the private key as bytes, > while VFS doesn't support so, > JSch.java > public void addIdentity(String name, byte[] prvkey, byte[] pubkey, byte[] > passphrase) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (VFS-609) VFS SFTP doesn't support a private key as byte array
stevezhuang created VFS-609: --- Summary: VFS SFTP doesn't support a private key as byte array Key: VFS-609 URL: https://issues.apache.org/jira/browse/VFS-609 Project: Commons VFS Issue Type: Improvement Affects Versions: 2.1 Environment: Java client running on Windows 7 Reporter: stevezhuang Priority: Minor Sometimes we would store the private key as a string\bytes in the remote server site, and then access the SFTP functions, The JSCH API already provides a possibility to add the private key as bytes, while VFS doesn't support so, JSch.java public void addIdentity(String name, byte[] prvkey, byte[] pubkey, byte[] passphrase) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CSV-166) Read CSV file column by column
[ https://issues.apache.org/jira/browse/CSV-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated CSV-166: Fix Version/s: (was: Patch Needed) > Read CSV file column by column > -- > > Key: CSV-166 > URL: https://issues.apache.org/jira/browse/CSV-166 > Project: Commons CSV > Issue Type: Improvement >Reporter: Carlos Gavidia > Labels: csvparser > > It would be nice if the library enables reading the CSV files in a column per > column basis. Here's a very popular StackOverflow thread were the issue is > discussed: > http://stackoverflow.com/questions/12169038/read-csv-file-column-by-column -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CSV-166) Read CSV file column by column
[ https://issues.apache.org/jira/browse/CSV-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated CSV-166: Fix Version/s: Patch Needed > Read CSV file column by column > -- > > Key: CSV-166 > URL: https://issues.apache.org/jira/browse/CSV-166 > Project: Commons CSV > Issue Type: Improvement >Reporter: Carlos Gavidia > Labels: csvparser > Fix For: Patch Needed > > > It would be nice if the library enables reading the CSV files in a column per > column basis. Here's a very popular StackOverflow thread were the issue is > discussed: > http://stackoverflow.com/questions/12169038/read-csv-file-column-by-column -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CSV-153) CSVPrinter doesn't skip creation of header record if skipHeaderRecord is set to true
[ https://issues.apache.org/jira/browse/CSV-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter closed CSV-153. --- > CSVPrinter doesn't skip creation of header record if skipHeaderRecord is set > to true > > > Key: CSV-153 > URL: https://issues.apache.org/jira/browse/CSV-153 > Project: Commons CSV > Issue Type: Improvement > Components: Printer >Reporter: Wren >Assignee: Benedikt Ritter >Priority: Minor > Fix For: 1.3 > > > CSVParser uses CSVFormat.getSkipHeaderRecord to initialize index mapping and > skip the first record as well (initializeHeader method). It's inconsistent > that CSVPrinter doesn't skip creation of header record since the > skipHeaderRecord boolean should be applicable for reads/writes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CSV-177) Support trimming leading and trailing blanks
[ https://issues.apache.org/jira/browse/CSV-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter closed CSV-177. --- > Support trimming leading and trailing blanks > > > Key: CSV-177 > URL: https://issues.apache.org/jira/browse/CSV-177 > Project: Commons CSV > Issue Type: New Feature > Components: Parser, Printer >Affects Versions: 1.2 >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 1.3 > > > Support trimming leading and trailing blanks in the printer and parser. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CSV-179) Add shortcut method for using first record as header to CSVFormat
[
https://issues.apache.org/jira/browse/CSV-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter closed CSV-179.
---
> Add shortcut method for using first record as header to CSVFormat
> -
>
> Key: CSV-179
> URL: https://issues.apache.org/jira/browse/CSV-179
> Project: Commons CSV
> Issue Type: Improvement
> Components: Parser
>Reporter: Benedikt Ritter
>Assignee: Benedikt Ritter
> Fix For: 1.3
>
>
> As discussed on the dev ML:
> Instead of:
> {code:java}
> CSVFormat.RFC4180
>.withHeader() // use first row as header
>.withSkipHeaderRecord();
> {code}
> It would be useful to have a method that does this in one call:
> withFirstRecordAsHeader()
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (CSV-167) Comment line hides next record
[ https://issues.apache.org/jira/browse/CSV-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter closed CSV-167. --- > Comment line hides next record > -- > > Key: CSV-167 > URL: https://issues.apache.org/jira/browse/CSV-167 > Project: Commons CSV > Issue Type: Bug > Components: Parser >Affects Versions: 1.2 >Reporter: Rene > Fix For: 1.3 > > Attachments: CSVProcessor.java, sample1.csv > > > 1. First CSV record after the comment line is not processed at all (record #2 > and #7) > 2. Second/Third line after the first comment line are not recognized as > comment lines (record #5 and #6) > See attached example! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CSV-170) CSVFormat.MYSQL nullString should be "\N"
[
https://issues.apache.org/jira/browse/CSV-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter closed CSV-170.
---
> CSVFormat.MYSQL nullString should be "\N"
> -
>
> Key: CSV-170
> URL: https://issues.apache.org/jira/browse/CSV-170
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser, Printer
>Affects Versions: 1.2
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
> Maven home: E:\Java\apache-maven-3.3.9\bin\..
> Java version: 1.8.0_65, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_65\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 1.3
>
>
> {{CSVFormat.MYSQL}}'s {{nullString}} should be:
> {noformat}
> "\N"
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (CSV-180) Add withHeader(Class) to CSVFormat
[ https://issues.apache.org/jira/browse/CSV-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter closed CSV-180. --- > Add withHeader(Class) to CSVFormat > -- > > Key: CSV-180 > URL: https://issues.apache.org/jira/browse/CSV-180 > Project: Commons CSV > Issue Type: New Feature > Components: Parser >Reporter: Benedikt Ritter >Assignee: Benedikt Ritter > Fix For: 1.3 > > > As discussed on the ML, it would be useful if Enums could also be used to > specify a header. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CSV-178) Create default formats for Informix UNLOAD and UNLOAD CSV
[ https://issues.apache.org/jira/browse/CSV-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter closed CSV-178. --- > Create default formats for Informix UNLOAD and UNLOAD CSV > -- > > Key: CSV-178 > URL: https://issues.apache.org/jira/browse/CSV-178 > Project: Commons CSV > Issue Type: New Feature > Components: Parser, Printer >Affects Versions: 1.2 >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 1.3 > > > Create default formats for Informix UNLOAD and UNLOAD CSV. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (CSV-161) Fix Javadoc to say CSVFormat with() methods return a new CSVFormat
[ https://issues.apache.org/jira/browse/CSV-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter closed CSV-161. --- > Fix Javadoc to say CSVFormat with() methods return a new CSVFormat > -- > > Key: CSV-161 > URL: https://issues.apache.org/jira/browse/CSV-161 > Project: Commons CSV > Issue Type: Bug >Affects Versions: 1.2 > Environment: JDK 1.8 >Reporter: Kristof Meixner >Assignee: Gary Gregory > Fix For: 1.3 > > Attachments: VariousLibraryTests.java > > > The quoting mode depends on the order of format declaration. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CSV-181) Make CSVPrinter.print(Object) GC-free
[ https://issues.apache.org/jira/browse/CSV-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated CSV-181: Fix Version/s: 1.3.1 > Make CSVPrinter.print(Object) GC-free > - > > Key: CSV-181 > URL: https://issues.apache.org/jira/browse/CSV-181 > Project: Commons CSV > Issue Type: Improvement > Components: Printer >Affects Versions: 1.2, 1.3 > Environment: Apache Maven 3.3.9 > (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00) > Maven home: E:\Java\apache-maven-3.3.9\bin\.. > Java version: 1.8.0_91, vendor: Oracle Corporation > Java home: C:\Program Files\Java\jdk1.8.0_91\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos" >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 1.3.1 > > Attachments: csv-181-gg.diff > > > Make CSVPrinter.print(Object) GC-free. > One of the goals for Apache Log4j 2.6 is GC-free use cases. Log4j uses > Commons CSV for its CSV layout. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (VFS-180) Support HTTPS / SSL for Webdav
[ https://issues.apache.org/jira/browse/VFS-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jose Juan Montiel updated VFS-180: -- Comment: was deleted (was: +1 :_) thanks) > Support HTTPS / SSL for Webdav > -- > > Key: VFS-180 > URL: https://issues.apache.org/jira/browse/VFS-180 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 1.0, 1.1, 2.0 >Reporter: Werner Mueller > Labels: patch > Attachments: VFS-180.patch, VFS-180.patch, VFS-180.patch, > patch_180_vfs2.txt, patch_180_vfs2.txt > > > The Slide Webdav lib supports encrypted HTTPS connections. So it should be > possible to add https support to vfs too. currently the webdav provider > creates http urls (in WebdavClientFactory.java). > maybe some provider like 'webdavs' could be added to switch to HttpsUrl. > regards > werner -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (VFS-180) Support HTTPS / SSL for Webdav
[ https://issues.apache.org/jira/browse/VFS-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15276362#comment-15276362 ] Jose Juan Montiel commented on VFS-180: --- +1 :_) thanks > Support HTTPS / SSL for Webdav > -- > > Key: VFS-180 > URL: https://issues.apache.org/jira/browse/VFS-180 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 1.0, 1.1, 2.0 >Reporter: Werner Mueller > Labels: patch > Attachments: VFS-180.patch, VFS-180.patch, VFS-180.patch, > patch_180_vfs2.txt, patch_180_vfs2.txt > > > The Slide Webdav lib supports encrypted HTTPS connections. So it should be > possible to add https support to vfs too. currently the webdav provider > creates http urls (in WebdavClientFactory.java). > maybe some provider like 'webdavs' could be added to switch to HttpsUrl. > regards > werner -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (VFS-180) Support HTTPS / SSL for Webdav
[ https://issues.apache.org/jira/browse/VFS-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15276326#comment-15276326 ] Woonsan Ko edited comment on VFS-180 at 5/9/16 12:58 PM: - Hoping to help, I've just created a PR simply by slightly improving the latest patch, patch_180_vfs2.txt: trivial formatting, putting the new classes into the existing package instead of new package following Bernd's comment and trivial clean up. - https://github.com/apache/commons-vfs/pull/13 BTW, it seems reasonable to keep WebdavsFileNameParser.java because it's extending HttpsFileNameParser instead of HttpFileNameParser. Regards, Woonsan was (Author: woon_san): Hoping to help, I've just created a PR simply by slightly improving the latest patch, patch_180_vfs2.txt: trivial formatting, putting the new classes into the existing package instead of new package following Bernd's comment and trivial clean up. - https://github.com/apache/commons-vfs/pull/13 Regards, Woonsan > Support HTTPS / SSL for Webdav > -- > > Key: VFS-180 > URL: https://issues.apache.org/jira/browse/VFS-180 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 1.0, 1.1, 2.0 >Reporter: Werner Mueller > Labels: patch > Attachments: VFS-180.patch, VFS-180.patch, VFS-180.patch, > patch_180_vfs2.txt, patch_180_vfs2.txt > > > The Slide Webdav lib supports encrypted HTTPS connections. So it should be > possible to add https support to vfs too. currently the webdav provider > creates http urls (in WebdavClientFactory.java). > maybe some provider like 'webdavs' could be added to switch to HttpsUrl. > regards > werner -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (VFS-180) Support HTTPS / SSL for Webdav
[ https://issues.apache.org/jira/browse/VFS-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15276326#comment-15276326 ] Woonsan Ko commented on VFS-180: Hoping to help, I've just created a PR simply by slightly improving the latest patch, patch_180_vfs2.txt: trivial formatting, putting the new classes into the existing package instead of new package following Bernd's comment and trivial clean up. - https://github.com/apache/commons-vfs/pull/13 Regards, Woonsan > Support HTTPS / SSL for Webdav > -- > > Key: VFS-180 > URL: https://issues.apache.org/jira/browse/VFS-180 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 1.0, 1.1, 2.0 >Reporter: Werner Mueller > Labels: patch > Attachments: VFS-180.patch, VFS-180.patch, VFS-180.patch, > patch_180_vfs2.txt, patch_180_vfs2.txt > > > The Slide Webdav lib supports encrypted HTTPS connections. So it should be > possible to add https support to vfs too. currently the webdav provider > creates http urls (in WebdavClientFactory.java). > maybe some provider like 'webdavs' could be added to switch to HttpsUrl. > regards > werner -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1226) StringUtils#normalizeSpace does not trim the string anymore
[
https://issues.apache.org/jira/browse/LANG-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15276319#comment-15276319
]
Sebb commented on LANG-1226:
See LANG-1227 - any XML methods need to be sensitive to the XML spec version.
Maybe such methods belong in the XMLCharacter class.
StringUtils could have a wrapper that delegates to it.
e.g.
StringUtils.normalizeXmlSpace(String input, XMLCharacter#enum XML version) {
return XMLCharacter.getInstance(version).normalizeSpace(input);
}
> StringUtils#normalizeSpace does not trim the string anymore
> ---
>
> Key: LANG-1226
> URL: https://issues.apache.org/jira/browse/LANG-1226
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.4
>Reporter: Pascal Schumacher
>
> These work with 3.3.2, but fail with 3.4:
> {code}
> assertEquals("b", StringUtils.normalizeSpace("\ub"));
> assertEquals("b", StringUtils.normalizeSpace("b\u"));
> {code}
> Java doc still says "... Additionally #trim(String)} removes control
> characters (char <= 32) from both ends of this String."
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (LANG-1227) Add XMLCharacter class
[ https://issues.apache.org/jira/browse/LANG-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15276318#comment-15276318 ] Sebb commented on LANG-1227: Alternatively, maybe the constructor could require an argument to specify the version? However this would require the methods to be changed to instance methods. A version argument should probably be an enum, and there could be getInstance methods to return an appropriate static final instance. > Add XMLCharacter class > -- > > Key: LANG-1227 > URL: https://issues.apache.org/jira/browse/LANG-1227 > Project: Commons Lang > Issue Type: New Feature > Components: lang.* > Environment: Apache Maven 3.3.9 > (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00) > Maven home: E:\Java\apache-maven-3.3.9\bin\.. > Java version: 1.8.0_91, vendor: Oracle Corporation > Java home: C:\Program Files\Java\jdk1.8.0_91\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos" >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 3.5 > > > Add XMLCharacter class. Helps toward [LANG-1226]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (JCS-160) Not possible to deploy Java Caching System on WebSphere
[ https://issues.apache.org/jira/browse/JCS-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15276296#comment-15276296 ] Romain Manni-Bucau commented on JCS-160: Hi Urvish, all is correctly setup, please have a look to https://github.com/apache/commons-jcs/blob/trunk/commons-jcs-jcache/src/main/java/org/apache/commons/jcs/jcache/cdi/MakeJCacheCDIInterceptorFriendly.java#L83 Maybe websphere doesnt pick up correctly this extension or just has a old CDI implementation not supporting it. > Not possible to deploy Java Caching System on WebSphere > --- > > Key: JCS-160 > URL: https://issues.apache.org/jira/browse/JCS-160 > Project: Commons JCS > Issue Type: Bug >Affects Versions: jcs-2.0-beta-2 >Reporter: urvish >Assignee: Romain Manni-Bucau >Priority: Blocker > > Currently we are using JCS as implementation of JSR 107. When we deploy > application on WebSphere version 8.5 the following exception occurs. > commons-jcs-jcache-2.0-beta-1.jar!/META-INF/beans.xml is failed. Reason is : > Interceptor class : org.apache.commons.jcs.jcache.cdi.CachePutInterceptor > must have at least one @InterceptorBindingType > I think the cause is that there is no InterceptorBindingType in the > CachePutInterceptor as required by the specification and the CDI > implementation of the WebSphere (OpenWebBeans) does not accept Interceptors > without bindings. > I think InterceptorBindingType is missing on all Inceptors defined in Bean.xml > Can you please have look? > Kr, > Urvish -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (JCS-162) memory region properties documentation incorrect
[ https://issues.apache.org/jira/browse/JCS-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-162. Resolution: Fixed Assignee: Thomas Vandahl Fix Version/s: jcs-2.0-beta-2 Fixed (hopefully) all references in the docs > memory region properties documentation incorrect > > > Key: JCS-162 > URL: https://issues.apache.org/jira/browse/JCS-162 > Project: Commons JCS > Issue Type: Documentation > Components: Composite Cache >Affects Versions: jcs-2.0-beta-1 >Reporter: Ryan Fong >Assignee: Thomas Vandahl > Fix For: jcs-2.0-beta-2 > > > https://commons.apache.org/proper/commons-jcs/RegionProperties.html > This page lists incorrect property names for delays. > * "MaxMemoryIdleTime" should be "MaxMemoryIdleTimeSeconds". > * "ShrinkerInterval" should be "ShrinkerIntervalSeconds" > * The default shrinker interval should be 30 seconds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (JCS-161) dynamic regions leak memory upon dispose due to ShrinkerTask
[ https://issues.apache.org/jira/browse/JCS-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl resolved JCS-161. Resolution: Fixed Assignee: Thomas Vandahl Fix Version/s: jcs-2.0-beta-2 Fixed in SVN > dynamic regions leak memory upon dispose due to ShrinkerTask > > > Key: JCS-161 > URL: https://issues.apache.org/jira/browse/JCS-161 > Project: Commons JCS > Issue Type: Bug > Components: Composite Cache >Affects Versions: jcs-2.0-beta-1 >Reporter: Ryan Fong >Assignee: Thomas Vandahl >Priority: Critical > Fix For: jcs-2.0-beta-2 > > Attachments: commons-jcs-core.patch > > > Creating a dynamic region via JCS.defineRegion and then destroying it via > ComposeCacheManager.free does not fully reclaim all memory when the memory > shrinker is enabled. > When shrinking is enabled, the > org.apache.commons.jcs.engine.memory.shrinking.ShrinkerThread retains a > pointer to CompositeCache which is never reclaimed. > A simple solution would be to have > org.apache.commons.jcs.engine.control.CompositeCache.setScheduledExecutorService(ScheduledExecutorService) > retain the ScheduledFuture as a field. When CompositeCache.disposed is > called, we should call ScheduledFuture.cancel. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (JCS-160) Not possible to deploy Java Caching System on WebSphere
[ https://issues.apache.org/jira/browse/JCS-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Vandahl updated JCS-160: --- Assignee: Romain Manni-Bucau > Not possible to deploy Java Caching System on WebSphere > --- > > Key: JCS-160 > URL: https://issues.apache.org/jira/browse/JCS-160 > Project: Commons JCS > Issue Type: Bug >Affects Versions: jcs-2.0-beta-2 >Reporter: urvish >Assignee: Romain Manni-Bucau >Priority: Blocker > > Currently we are using JCS as implementation of JSR 107. When we deploy > application on WebSphere version 8.5 the following exception occurs. > commons-jcs-jcache-2.0-beta-1.jar!/META-INF/beans.xml is failed. Reason is : > Interceptor class : org.apache.commons.jcs.jcache.cdi.CachePutInterceptor > must have at least one @InterceptorBindingType > I think the cause is that there is no InterceptorBindingType in the > CachePutInterceptor as required by the specification and the CDI > implementation of the WebSphere (OpenWebBeans) does not accept Interceptors > without bindings. > I think InterceptorBindingType is missing on all Inceptors defined in Bean.xml > Can you please have look? > Kr, > Urvish -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CSV-181) Make CSVPrinter.print(Object) GC-free
[
https://issues.apache.org/jira/browse/CSV-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved CSV-181.
--
Resolution: Fixed
Code reviewed by [~rem...@yahoo.com].
{noformat}
commit -m "[CSV-181] Make CSVPrinter.print(Object) GC-free." -N
E:/vcs/svn/apache/commons/trunks-proper/csv/src/changes/changes.xml
E:/vcs/svn/apache/commons/trunks-proper/csv/src/main/java/org/apache/commons/csv/CSVPrinter.java
Sending
E:/vcs/svn/apache/commons/trunks-proper/csv/src/changes/changes.xml
Sending
E:/vcs/svn/apache/commons/trunks-proper/csv/src/main/java/org/apache/commons/csv/CSVPrinter.java
Transmitting file data ...
Committed revision 1742895.
{noformat}
> Make CSVPrinter.print(Object) GC-free
> -
>
> Key: CSV-181
> URL: https://issues.apache.org/jira/browse/CSV-181
> Project: Commons CSV
> Issue Type: Improvement
> Components: Printer
>Affects Versions: 1.2, 1.3
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
> Maven home: E:\Java\apache-maven-3.3.9\bin\..
> Java version: 1.8.0_91, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_91\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Attachments: csv-181-gg.diff
>
>
> Make CSVPrinter.print(Object) GC-free.
> One of the goals for Apache Log4j 2.6 is GC-free use cases. Log4j uses
> Commons CSV for its CSV layout.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CSV-181) Make CSVPrinter.print(Object) GC-free
[ https://issues.apache.org/jira/browse/CSV-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated CSV-181: - Affects Version/s: 1.3 > Make CSVPrinter.print(Object) GC-free > - > > Key: CSV-181 > URL: https://issues.apache.org/jira/browse/CSV-181 > Project: Commons CSV > Issue Type: Improvement > Components: Printer >Affects Versions: 1.2, 1.3 > Environment: Apache Maven 3.3.9 > (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00) > Maven home: E:\Java\apache-maven-3.3.9\bin\.. > Java version: 1.8.0_91, vendor: Oracle Corporation > Java home: C:\Program Files\Java\jdk1.8.0_91\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos" >Reporter: Gary Gregory >Assignee: Gary Gregory > Attachments: csv-181-gg.diff > > > Make CSVPrinter.print(Object) GC-free. > One of the goals for Apache Log4j 2.6 is GC-free use cases. Log4j uses > Commons CSV for its CSV layout. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1227) Add XMLCharacter class
[ https://issues.apache.org/jira/browse/LANG-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15276096#comment-15276096 ] Joerg Schaible commented on LANG-1227: -- Can we please use a name for the character class that reflects the specification version? Especially the allowed characters differ largely in XML 1.0 vs XML 1.1. Similar for the nromalizeXML methods. > Add XMLCharacter class > -- > > Key: LANG-1227 > URL: https://issues.apache.org/jira/browse/LANG-1227 > Project: Commons Lang > Issue Type: New Feature > Components: lang.* > Environment: Apache Maven 3.3.9 > (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00) > Maven home: E:\Java\apache-maven-3.3.9\bin\.. > Java version: 1.8.0_91, vendor: Oracle Corporation > Java home: C:\Program Files\Java\jdk1.8.0_91\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos" >Reporter: Gary Gregory >Assignee: Gary Gregory > Fix For: 3.5 > > > Add XMLCharacter class. Helps toward [LANG-1226]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1227) Add XMLCharacter class
[
https://issues.apache.org/jira/browse/LANG-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15276051#comment-15276051
]
Gary Gregory commented on LANG-1227:
For [LANG-1226], I think we should have both {{normalizeSpace()}} and
{{normalizeXmlSpace()}}. Then what about {{normalizeJsonSpace()}} and/or
{{normalizeHtmlSpace()}}?
> Add XMLCharacter class
> --
>
> Key: LANG-1227
> URL: https://issues.apache.org/jira/browse/LANG-1227
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.*
> Environment: Apache Maven 3.3.9
> (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00)
> Maven home: E:\Java\apache-maven-3.3.9\bin\..
> Java version: 1.8.0_91, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.8.0_91\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos"
>Reporter: Gary Gregory
>Assignee: Gary Gregory
> Fix For: 3.5
>
>
> Add XMLCharacter class. Helps toward [LANG-1226].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (LANG-1227) Add XMLCharacter class
Gary Gregory created LANG-1227: -- Summary: Add XMLCharacter class Key: LANG-1227 URL: https://issues.apache.org/jira/browse/LANG-1227 Project: Commons Lang Issue Type: New Feature Components: lang.* Environment: Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T08:41:47-08:00) Maven home: E:\Java\apache-maven-3.3.9\bin\.. Java version: 1.8.0_91, vendor: Oracle Corporation Java home: C:\Program Files\Java\jdk1.8.0_91\jre Default locale: en_US, platform encoding: Cp1252 OS name: "windows 7", version: "6.1", arch: "amd64", family: "dos" Reporter: Gary Gregory Assignee: Gary Gregory Fix For: 3.5 Add XMLCharacter class. Helps toward [LANG-1226]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Reopened] (VFS-500) VFSClassLoader.findResources missing
[ https://issues.apache.org/jira/browse/VFS-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schaible reopened VFS-500: The current fix does not work for the IBM JDKs, the test is failing. > VFSClassLoader.findResources missing > > > Key: VFS-500 > URL: https://issues.apache.org/jira/browse/VFS-500 > Project: Commons VFS > Issue Type: New Feature >Affects Versions: 2.0 >Reporter: Bernd Eckenfels >Assignee: Bernd Eckenfels >Priority: Minor > Fix For: 2.1 > > Attachments: vfs-500-gg.diff > > > the VFSClassLoader.findResources(String) method is a dummy implementation > returning an empty Enumeration. > I have a working implementation and will support the patch for it, this is > the JIRA to track it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IO-508) Veracode static scan still shows 1 very high OS Command injection in commons-io-2.4.jar
[ https://issues.apache.org/jira/browse/IO-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Schaible resolved IO-508. --- Resolution: Won't Fix Assignee: Joerg Schaible There is nothing to fix. This is a utility function and, yes, if an application uses it incorrectly it might be used for a malfunction, but it is in the responsibility of the application to guard the call. > Veracode static scan still shows 1 very high OS Command injection in > commons-io-2.4.jar > > > Key: IO-508 > URL: https://issues.apache.org/jira/browse/IO-508 > Project: Commons IO > Issue Type: Bug >Affects Versions: 2.4 > Environment: Windows >Reporter: I-Min Mau >Assignee: Joerg Schaible > > I cloned IO-474 because we specifically upgraded the commons-io jar in our > application recently to 2.4 jar and still sees, in the Veracode static scan > result this one instance: 17561 189 - commons-io-2.4.jar > org/.../io/FileSystemUtils.java 535 4/23/16 > Since this is going to be visible on our security reports including to > potential customers, please help us at least remediate or otherwise fix in a > higher version. Thanks! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
