[jira] [Updated] (IO-783) Fetching file extension using FilenameUtils.getExtension method throws error in windows machine
[
https://issues.apache.org/jira/browse/IO-783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Samraj updated IO-783:
--
Description:
Hi Team,
I am using FilenameUtils.getExtension method to get the file extension from the
file path ( Available as string). Due to one of the bug fix happen after 2.7
breaks the code.
Run the below line of code in windows environment.
String fileName = FilenameUtils.getExtension("Top of Information Store\\Archive
Informational-severity alert: eDiscovery search started or exported.msg");
System.out.println(fileName);
We are getting the error,
Exception in thread "main" java.lang.IllegalArgumentException: NTFS ADS
separator (':') in file name is forbidden.
at
org.apache.commons.io.FilenameUtils.indexOfExtension(FilenameUtils.java:737)
at org.apache.commons.io.FilenameUtils.getExtension(FilenameUtils.java:1057)
was:
Hi Team,
I am using FilenameUtils.getExtension method to get the file extension from the
file path ( Available as string). Due to one of the bug fix happen after 2.7
breaks the code.
> Fetching file extension using FilenameUtils.getExtension method throws error
> in windows machine
> ---
>
> Key: IO-783
> URL: https://issues.apache.org/jira/browse/IO-783
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.7, 2.8.0, 2.9.0, 2.10.0, 2.11.0
> Environment: Run the below line of code in windows environment.
> String fileName = FilenameUtils.getExtension("Top of Information
> Store\\Archive\\Informational-severity alert: eDiscovery search started or
> exported.msg");
> System.out.println(fileName);
>
> We are getting the error,
> Exception in thread "main" java.lang.IllegalArgumentException: NTFS ADS
> separator (':') in file name is forbidden.
> at
> org.apache.commons.io.FilenameUtils.indexOfExtension(FilenameUtils.java:737)
> at
> org.apache.commons.io.FilenameUtils.getExtension(FilenameUtils.java:1057)
>Reporter: Samraj
>Priority: Blocker
>
> Hi Team,
> I am using FilenameUtils.getExtension method to get the file extension from
> the file path ( Available as string). Due to one of the bug fix happen after
> 2.7 breaks the code.
> Run the below line of code in windows environment.
> String fileName = FilenameUtils.getExtension("Top of Information
> Store\\Archive
> Informational-severity alert: eDiscovery search started or exported.msg");
> System.out.println(fileName);
>
> We are getting the error,
> Exception in thread "main" java.lang.IllegalArgumentException: NTFS ADS
> separator (':') in file name is forbidden.
> at
> org.apache.commons.io.FilenameUtils.indexOfExtension(FilenameUtils.java:737)
> at
> org.apache.commons.io.FilenameUtils.getExtension(FilenameUtils.java:1057)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (CSV-296) Delimiter followed by Whitespace then by Quotes Failing with setTrim(true)
[
https://issues.apache.org/jira/browse/CSV-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory closed CSV-296.
---
Fix Version/s: 1.9.0
Resolution: Fixed
> Delimiter followed by Whitespace then by Quotes Failing with setTrim(true)
> --
>
> Key: CSV-296
> URL: https://issues.apache.org/jira/browse/CSV-296
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.8
> Environment: +{*}macOS{*}:+
> {code:java}
> > uname -a
> Darwin Senzing-MacBook-Pro.local 21.4.0 Darwin Kernel Version 21.4.0: Fri Mar
> 18 00:45:05 PDT 2022; root:xnu-8020.101.4~15/RELEASE_X86_64 x86_64 {code}
> {code:java}
> > java -version
> openjdk version "11.0.14" 2022-01-18
> OpenJDK Runtime Environment Temurin-11.0.14+9 (build 11.0.14+9)
> OpenJDK 64-Bit Server VM Temurin-11.0.14+9 (build 11.0.14+9, mixed mode)
> {code}
> {+}*Linux*{+}:
> {code:java}
> > uname -a
> Linux lnxdev 5.4.0-109-generic #123-Ubuntu SMP Fri Apr 8 09:10:54 UTC 2022
> x86_64 x86_64 x86_64 GNU/Linux {code}
> {code:java}
> > java -version
> openjdk version "11.0.11" 2021-04-20
> OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
> OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed
> mode){code}
>Reporter: Barry M. Caceres
>Priority: Major
> Fix For: 1.9.0
>
> Attachments: csvfail.zip
>
>
> I have my CSVFormat initialized such that *{{withTrim(true)}}* has been set
> {_}(see attached ZIP file){_}:
> {code:java}
> CSVFormat csvFormat = CSVFormat.DEFAULT.withFirstRecordAsHeader()
> .withIgnoreEmptyLines(true).withTrim(true);{code}
>
> However, a quoted string that begins after a delimiter followed by preceding
> whitespace is not properly parsed. For example:
> {code:java}
> GIVEN_NAME,SURNAME,ADDRESS,PHONE_NUMBER
> "Joe", "Schmoe","101 Main Street; Las Vegas, NV 89101","702-555-1212"
> "John","Doe", "201 First Street; Las Vegas, NV 89102", "702-555-1313"
> "Jane","Doe","301 Second Street; Las Vegas, NV 89103","702-555-1414"
> {code}
>
> * Notice the whitespace preceding {color:#0747a6}*{{"Schmoe"}}*{color} on
> the first record? This leads to the actual value containing the quotation
> marks instead of them being stripped off.
> * The whitespace preceding {color:#0747a6}*{{"201 First Street; Las Vegas,
> NV 89102"}}*{color} on the second record leads to it to being parsed as two
> values: {color:#0747a6}*{{"201 First Street; Las Vegas}}*{color} and {*}{{NV
> 89102"}}{*}.
> * The third record is the only one that parses as expected.
> I believe that this is because the trimming is done *after* the value is
> being parsed rather than consuming the whitespace following the delimiter
> during parsing. Either that, or the check for a quoted string is occurring
> *before* the whitespace is being consumed.
>
> *NOTE:* I have attached a ZIP file that easily reproduces the problem with
> the CSV file given above.
> To build the attached project use Apache Maven and then execute using using
> Java 11:
> {code:java}
> > unzip csvfail.zip
> > cd csvfail
> > mvn package
> > java -jar target/csv-fail-1.0-SNAPSHOT.jar{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (CSV-296) Delimiter followed by Whitespace then by Quotes Failing with setTrim(true)
[
https://issues.apache.org/jira/browse/CSV-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory reopened CSV-296:
-
> Delimiter followed by Whitespace then by Quotes Failing with setTrim(true)
> --
>
> Key: CSV-296
> URL: https://issues.apache.org/jira/browse/CSV-296
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.8
> Environment: +{*}macOS{*}:+
> {code:java}
> > uname -a
> Darwin Senzing-MacBook-Pro.local 21.4.0 Darwin Kernel Version 21.4.0: Fri Mar
> 18 00:45:05 PDT 2022; root:xnu-8020.101.4~15/RELEASE_X86_64 x86_64 {code}
> {code:java}
> > java -version
> openjdk version "11.0.14" 2022-01-18
> OpenJDK Runtime Environment Temurin-11.0.14+9 (build 11.0.14+9)
> OpenJDK 64-Bit Server VM Temurin-11.0.14+9 (build 11.0.14+9, mixed mode)
> {code}
> {+}*Linux*{+}:
> {code:java}
> > uname -a
> Linux lnxdev 5.4.0-109-generic #123-Ubuntu SMP Fri Apr 8 09:10:54 UTC 2022
> x86_64 x86_64 x86_64 GNU/Linux {code}
> {code:java}
> > java -version
> openjdk version "11.0.11" 2021-04-20
> OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
> OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed
> mode){code}
>Reporter: Barry M. Caceres
>Priority: Major
> Attachments: csvfail.zip
>
>
> I have my CSVFormat initialized such that *{{withTrim(true)}}* has been set
> {_}(see attached ZIP file){_}:
> {code:java}
> CSVFormat csvFormat = CSVFormat.DEFAULT.withFirstRecordAsHeader()
> .withIgnoreEmptyLines(true).withTrim(true);{code}
>
> However, a quoted string that begins after a delimiter followed by preceding
> whitespace is not properly parsed. For example:
> {code:java}
> GIVEN_NAME,SURNAME,ADDRESS,PHONE_NUMBER
> "Joe", "Schmoe","101 Main Street; Las Vegas, NV 89101","702-555-1212"
> "John","Doe", "201 First Street; Las Vegas, NV 89102", "702-555-1313"
> "Jane","Doe","301 Second Street; Las Vegas, NV 89103","702-555-1414"
> {code}
>
> * Notice the whitespace preceding {color:#0747a6}*{{"Schmoe"}}*{color} on
> the first record? This leads to the actual value containing the quotation
> marks instead of them being stripped off.
> * The whitespace preceding {color:#0747a6}*{{"201 First Street; Las Vegas,
> NV 89102"}}*{color} on the second record leads to it to being parsed as two
> values: {color:#0747a6}*{{"201 First Street; Las Vegas}}*{color} and {*}{{NV
> 89102"}}{*}.
> * The third record is the only one that parses as expected.
> I believe that this is because the trimming is done *after* the value is
> being parsed rather than consuming the whitespace following the delimiter
> during parsing. Either that, or the check for a quoted string is occurring
> *before* the whitespace is being consumed.
>
> *NOTE:* I have attached a ZIP file that easily reproduces the problem with
> the CSV file given above.
> To build the attached project use Apache Maven and then execute using using
> Java 11:
> {code:java}
> > unzip csvfail.zip
> > cd csvfail
> > mvn package
> > java -jar target/csv-fail-1.0-SNAPSHOT.jar{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (CSV-296) Delimiter followed by Whitespace then by Quotes Failing with setTrim(true)
[
https://issues.apache.org/jira/browse/CSV-296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary D. Gregory updated CSV-296:
Affects Version/s: (was: 1.9.0)
> Delimiter followed by Whitespace then by Quotes Failing with setTrim(true)
> --
>
> Key: CSV-296
> URL: https://issues.apache.org/jira/browse/CSV-296
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.8
> Environment: +{*}macOS{*}:+
> {code:java}
> > uname -a
> Darwin Senzing-MacBook-Pro.local 21.4.0 Darwin Kernel Version 21.4.0: Fri Mar
> 18 00:45:05 PDT 2022; root:xnu-8020.101.4~15/RELEASE_X86_64 x86_64 {code}
> {code:java}
> > java -version
> openjdk version "11.0.14" 2022-01-18
> OpenJDK Runtime Environment Temurin-11.0.14+9 (build 11.0.14+9)
> OpenJDK 64-Bit Server VM Temurin-11.0.14+9 (build 11.0.14+9, mixed mode)
> {code}
> {+}*Linux*{+}:
> {code:java}
> > uname -a
> Linux lnxdev 5.4.0-109-generic #123-Ubuntu SMP Fri Apr 8 09:10:54 UTC 2022
> x86_64 x86_64 x86_64 GNU/Linux {code}
> {code:java}
> > java -version
> openjdk version "11.0.11" 2021-04-20
> OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
> OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed
> mode){code}
>Reporter: Barry M. Caceres
>Priority: Major
> Attachments: csvfail.zip
>
>
> I have my CSVFormat initialized such that *{{withTrim(true)}}* has been set
> {_}(see attached ZIP file){_}:
> {code:java}
> CSVFormat csvFormat = CSVFormat.DEFAULT.withFirstRecordAsHeader()
> .withIgnoreEmptyLines(true).withTrim(true);{code}
>
> However, a quoted string that begins after a delimiter followed by preceding
> whitespace is not properly parsed. For example:
> {code:java}
> GIVEN_NAME,SURNAME,ADDRESS,PHONE_NUMBER
> "Joe", "Schmoe","101 Main Street; Las Vegas, NV 89101","702-555-1212"
> "John","Doe", "201 First Street; Las Vegas, NV 89102", "702-555-1313"
> "Jane","Doe","301 Second Street; Las Vegas, NV 89103","702-555-1414"
> {code}
>
> * Notice the whitespace preceding {color:#0747a6}*{{"Schmoe"}}*{color} on
> the first record? This leads to the actual value containing the quotation
> marks instead of them being stripped off.
> * The whitespace preceding {color:#0747a6}*{{"201 First Street; Las Vegas,
> NV 89102"}}*{color} on the second record leads to it to being parsed as two
> values: {color:#0747a6}*{{"201 First Street; Las Vegas}}*{color} and {*}{{NV
> 89102"}}{*}.
> * The third record is the only one that parses as expected.
> I believe that this is because the trimming is done *after* the value is
> being parsed rather than consuming the whitespace following the delimiter
> during parsing. Either that, or the check for a quoted string is occurring
> *before* the whitespace is being consumed.
>
> *NOTE:* I have attached a ZIP file that easily reproduces the problem with
> the CSV file given above.
> To build the attached project use Apache Maven and then execute using using
> Java 11:
> {code:java}
> > unzip csvfail.zip
> > cd csvfail
> > mvn package
> > java -jar target/csv-fail-1.0-SNAPSHOT.jar{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CSV-296) Delimiter followed by Whitespace then by Quotes Failing with setTrim(true)
[
https://issues.apache.org/jira/browse/CSV-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627358#comment-17627358
]
Barry M. Caceres commented on CSV-296:
--
Once I made sure I was using the correct version of my library and upgraded to
version v1.9.0 of Commons CSV, your suggestion worked as expected.
> Delimiter followed by Whitespace then by Quotes Failing with setTrim(true)
> --
>
> Key: CSV-296
> URL: https://issues.apache.org/jira/browse/CSV-296
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.8, 1.9.0
> Environment: +{*}macOS{*}:+
> {code:java}
> > uname -a
> Darwin Senzing-MacBook-Pro.local 21.4.0 Darwin Kernel Version 21.4.0: Fri Mar
> 18 00:45:05 PDT 2022; root:xnu-8020.101.4~15/RELEASE_X86_64 x86_64 {code}
> {code:java}
> > java -version
> openjdk version "11.0.14" 2022-01-18
> OpenJDK Runtime Environment Temurin-11.0.14+9 (build 11.0.14+9)
> OpenJDK 64-Bit Server VM Temurin-11.0.14+9 (build 11.0.14+9, mixed mode)
> {code}
> {+}*Linux*{+}:
> {code:java}
> > uname -a
> Linux lnxdev 5.4.0-109-generic #123-Ubuntu SMP Fri Apr 8 09:10:54 UTC 2022
> x86_64 x86_64 x86_64 GNU/Linux {code}
> {code:java}
> > java -version
> openjdk version "11.0.11" 2021-04-20
> OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
> OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed
> mode){code}
>Reporter: Barry M. Caceres
>Priority: Major
> Attachments: csvfail.zip
>
>
> I have my CSVFormat initialized such that *{{withTrim(true)}}* has been set
> {_}(see attached ZIP file){_}:
> {code:java}
> CSVFormat csvFormat = CSVFormat.DEFAULT.withFirstRecordAsHeader()
> .withIgnoreEmptyLines(true).withTrim(true);{code}
>
> However, a quoted string that begins after a delimiter followed by preceding
> whitespace is not properly parsed. For example:
> {code:java}
> GIVEN_NAME,SURNAME,ADDRESS,PHONE_NUMBER
> "Joe", "Schmoe","101 Main Street; Las Vegas, NV 89101","702-555-1212"
> "John","Doe", "201 First Street; Las Vegas, NV 89102", "702-555-1313"
> "Jane","Doe","301 Second Street; Las Vegas, NV 89103","702-555-1414"
> {code}
>
> * Notice the whitespace preceding {color:#0747a6}*{{"Schmoe"}}*{color} on
> the first record? This leads to the actual value containing the quotation
> marks instead of them being stripped off.
> * The whitespace preceding {color:#0747a6}*{{"201 First Street; Las Vegas,
> NV 89102"}}*{color} on the second record leads to it to being parsed as two
> values: {color:#0747a6}*{{"201 First Street; Las Vegas}}*{color} and {*}{{NV
> 89102"}}{*}.
> * The third record is the only one that parses as expected.
> I believe that this is because the trimming is done *after* the value is
> being parsed rather than consuming the whitespace following the delimiter
> during parsing. Either that, or the check for a quoted string is occurring
> *before* the whitespace is being consumed.
>
> *NOTE:* I have attached a ZIP file that easily reproduces the problem with
> the CSV file given above.
> To build the attached project use Apache Maven and then execute using using
> Java 11:
> {code:java}
> > unzip csvfail.zip
> > cd csvfail
> > mvn package
> > java -jar target/csv-fail-1.0-SNAPSHOT.jar{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (CSV-296) Delimiter followed by Whitespace then by Quotes Failing with setTrim(true)
[ https://issues.apache.org/jira/browse/CSV-296 ]
Barry M. Caceres deleted comment on CSV-296:
--
was (Author: JIRAUSER289277):
{{setIgnoreSurroundingSpaces(true) only kinda works If the text is quoted
it maintains the quotes as part of the text, whereas if the quotes immediately
follow the comma (or other separator) then the text is processed as a CSV
quoted string and the value does not have the quotes. But if any spaces follow
the comma before the first quote then the quotes are included as part of the
value and the text is taken literally.}}
> Delimiter followed by Whitespace then by Quotes Failing with setTrim(true)
> --
>
> Key: CSV-296
> URL: https://issues.apache.org/jira/browse/CSV-296
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.8, 1.9.0
> Environment: +{*}macOS{*}:+
> {code:java}
> > uname -a
> Darwin Senzing-MacBook-Pro.local 21.4.0 Darwin Kernel Version 21.4.0: Fri Mar
> 18 00:45:05 PDT 2022; root:xnu-8020.101.4~15/RELEASE_X86_64 x86_64 {code}
> {code:java}
> > java -version
> openjdk version "11.0.14" 2022-01-18
> OpenJDK Runtime Environment Temurin-11.0.14+9 (build 11.0.14+9)
> OpenJDK 64-Bit Server VM Temurin-11.0.14+9 (build 11.0.14+9, mixed mode)
> {code}
> {+}*Linux*{+}:
> {code:java}
> > uname -a
> Linux lnxdev 5.4.0-109-generic #123-Ubuntu SMP Fri Apr 8 09:10:54 UTC 2022
> x86_64 x86_64 x86_64 GNU/Linux {code}
> {code:java}
> > java -version
> openjdk version "11.0.11" 2021-04-20
> OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
> OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed
> mode){code}
>Reporter: Barry M. Caceres
>Priority: Major
> Attachments: csvfail.zip
>
>
> I have my CSVFormat initialized such that *{{withTrim(true)}}* has been set
> {_}(see attached ZIP file){_}:
> {code:java}
> CSVFormat csvFormat = CSVFormat.DEFAULT.withFirstRecordAsHeader()
> .withIgnoreEmptyLines(true).withTrim(true);{code}
>
> However, a quoted string that begins after a delimiter followed by preceding
> whitespace is not properly parsed. For example:
> {code:java}
> GIVEN_NAME,SURNAME,ADDRESS,PHONE_NUMBER
> "Joe", "Schmoe","101 Main Street; Las Vegas, NV 89101","702-555-1212"
> "John","Doe", "201 First Street; Las Vegas, NV 89102", "702-555-1313"
> "Jane","Doe","301 Second Street; Las Vegas, NV 89103","702-555-1414"
> {code}
>
> * Notice the whitespace preceding {color:#0747a6}*{{"Schmoe"}}*{color} on
> the first record? This leads to the actual value containing the quotation
> marks instead of them being stripped off.
> * The whitespace preceding {color:#0747a6}*{{"201 First Street; Las Vegas,
> NV 89102"}}*{color} on the second record leads to it to being parsed as two
> values: {color:#0747a6}*{{"201 First Street; Las Vegas}}*{color} and {*}{{NV
> 89102"}}{*}.
> * The third record is the only one that parses as expected.
> I believe that this is because the trimming is done *after* the value is
> being parsed rather than consuming the whitespace following the delimiter
> during parsing. Either that, or the check for a quoted string is occurring
> *before* the whitespace is being consumed.
>
> *NOTE:* I have attached a ZIP file that easily reproduces the problem with
> the CSV file given above.
> To build the attached project use Apache Maven and then execute using using
> Java 11:
> {code:java}
> > unzip csvfail.zip
> > cd csvfail
> > mvn package
> > java -jar target/csv-fail-1.0-SNAPSHOT.jar{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CSV-296) Delimiter followed by Whitespace then by Quotes Failing with setTrim(true)
[
https://issues.apache.org/jira/browse/CSV-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627302#comment-17627302
]
Barry M. Caceres edited comment on CSV-296 at 11/1/22 7:35 PM:
---
{{setIgnoreSurroundingSpaces(true) only kinda works If the text is quoted
it maintains the quotes as part of the text, whereas if the quotes immediately
follow the comma (or other separator) then the text is processed as a CSV
quoted string and the value does not have the quotes. But if any spaces follow
the comma before the first quote then the quotes are included as part of the
value and the text is taken literally.}}
was (Author: JIRAUSER289277):
{{setIgnoreSurroundingSpaces(true) only kinda works I the text is quoted it
maintains the quotes as part of the text, whereas if the quotes immediately
follow the comma (or other separator) then the text is processed as a CSV
quoted string and the value does not have the quotes. But if any spaces follow
the comma before the first quote then the quotes are included as part of the
value and the text is taken literally.}}
> Delimiter followed by Whitespace then by Quotes Failing with setTrim(true)
> --
>
> Key: CSV-296
> URL: https://issues.apache.org/jira/browse/CSV-296
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.8, 1.9.0
> Environment: +{*}macOS{*}:+
> {code:java}
> > uname -a
> Darwin Senzing-MacBook-Pro.local 21.4.0 Darwin Kernel Version 21.4.0: Fri Mar
> 18 00:45:05 PDT 2022; root:xnu-8020.101.4~15/RELEASE_X86_64 x86_64 {code}
> {code:java}
> > java -version
> openjdk version "11.0.14" 2022-01-18
> OpenJDK Runtime Environment Temurin-11.0.14+9 (build 11.0.14+9)
> OpenJDK 64-Bit Server VM Temurin-11.0.14+9 (build 11.0.14+9, mixed mode)
> {code}
> {+}*Linux*{+}:
> {code:java}
> > uname -a
> Linux lnxdev 5.4.0-109-generic #123-Ubuntu SMP Fri Apr 8 09:10:54 UTC 2022
> x86_64 x86_64 x86_64 GNU/Linux {code}
> {code:java}
> > java -version
> openjdk version "11.0.11" 2021-04-20
> OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
> OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed
> mode){code}
>Reporter: Barry M. Caceres
>Priority: Major
> Attachments: csvfail.zip
>
>
> I have my CSVFormat initialized such that *{{withTrim(true)}}* has been set
> {_}(see attached ZIP file){_}:
> {code:java}
> CSVFormat csvFormat = CSVFormat.DEFAULT.withFirstRecordAsHeader()
> .withIgnoreEmptyLines(true).withTrim(true);{code}
>
> However, a quoted string that begins after a delimiter followed by preceding
> whitespace is not properly parsed. For example:
> {code:java}
> GIVEN_NAME,SURNAME,ADDRESS,PHONE_NUMBER
> "Joe", "Schmoe","101 Main Street; Las Vegas, NV 89101","702-555-1212"
> "John","Doe", "201 First Street; Las Vegas, NV 89102", "702-555-1313"
> "Jane","Doe","301 Second Street; Las Vegas, NV 89103","702-555-1414"
> {code}
>
> * Notice the whitespace preceding {color:#0747a6}*{{"Schmoe"}}*{color} on
> the first record? This leads to the actual value containing the quotation
> marks instead of them being stripped off.
> * The whitespace preceding {color:#0747a6}*{{"201 First Street; Las Vegas,
> NV 89102"}}*{color} on the second record leads to it to being parsed as two
> values: {color:#0747a6}*{{"201 First Street; Las Vegas}}*{color} and {*}{{NV
> 89102"}}{*}.
> * The third record is the only one that parses as expected.
> I believe that this is because the trimming is done *after* the value is
> being parsed rather than consuming the whitespace following the delimiter
> during parsing. Either that, or the check for a quoted string is occurring
> *before* the whitespace is being consumed.
>
> *NOTE:* I have attached a ZIP file that easily reproduces the problem with
> the CSV file given above.
> To build the attached project use Apache Maven and then execute using using
> Java 11:
> {code:java}
> > unzip csvfail.zip
> > cd csvfail
> > mvn package
> > java -jar target/csv-fail-1.0-SNAPSHOT.jar{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CSV-296) Delimiter followed by Whitespace then by Quotes Failing with setTrim(true)
[
https://issues.apache.org/jira/browse/CSV-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627302#comment-17627302
]
Barry M. Caceres edited comment on CSV-296 at 11/1/22 7:27 PM:
---
{{setIgnoreSurroundingSpaces(true) only kinda works I the text is quoted it
maintains the quotes as part of the text, whereas if the quotes immediately
follow the comma (or other separator) then the text is processed as a CSV
quoted string and the value does not have the quotes. But if any spaces follow
the comma before the first quote then the quotes are included as part of the
value and the text is taken literally.}}
was (Author: JIRAUSER289277):
{{setIgnoreSurroundingSpaces(true) only kinda works I the text is quoted it
maintains the quotes as part of the text, whereas if the quotes immediately
follow the comma (or other separator) then the text is processed as a CSV
quoted string and the value does not have the quotes. But if any spaces follow
the comma before the first quote then the quotes are included as part of the
value and the text is taken literally.}}
> Delimiter followed by Whitespace then by Quotes Failing with setTrim(true)
> --
>
> Key: CSV-296
> URL: https://issues.apache.org/jira/browse/CSV-296
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.8, 1.9.0
> Environment: +{*}macOS{*}:+
> {code:java}
> > uname -a
> Darwin Senzing-MacBook-Pro.local 21.4.0 Darwin Kernel Version 21.4.0: Fri Mar
> 18 00:45:05 PDT 2022; root:xnu-8020.101.4~15/RELEASE_X86_64 x86_64 {code}
> {code:java}
> > java -version
> openjdk version "11.0.14" 2022-01-18
> OpenJDK Runtime Environment Temurin-11.0.14+9 (build 11.0.14+9)
> OpenJDK 64-Bit Server VM Temurin-11.0.14+9 (build 11.0.14+9, mixed mode)
> {code}
> {+}*Linux*{+}:
> {code:java}
> > uname -a
> Linux lnxdev 5.4.0-109-generic #123-Ubuntu SMP Fri Apr 8 09:10:54 UTC 2022
> x86_64 x86_64 x86_64 GNU/Linux {code}
> {code:java}
> > java -version
> openjdk version "11.0.11" 2021-04-20
> OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
> OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed
> mode){code}
>Reporter: Barry M. Caceres
>Priority: Major
> Attachments: csvfail.zip
>
>
> I have my CSVFormat initialized such that *{{withTrim(true)}}* has been set
> {_}(see attached ZIP file){_}:
> {code:java}
> CSVFormat csvFormat = CSVFormat.DEFAULT.withFirstRecordAsHeader()
> .withIgnoreEmptyLines(true).withTrim(true);{code}
>
> However, a quoted string that begins after a delimiter followed by preceding
> whitespace is not properly parsed. For example:
> {code:java}
> GIVEN_NAME,SURNAME,ADDRESS,PHONE_NUMBER
> "Joe", "Schmoe","101 Main Street; Las Vegas, NV 89101","702-555-1212"
> "John","Doe", "201 First Street; Las Vegas, NV 89102", "702-555-1313"
> "Jane","Doe","301 Second Street; Las Vegas, NV 89103","702-555-1414"
> {code}
>
> * Notice the whitespace preceding {color:#0747a6}*{{"Schmoe"}}*{color} on
> the first record? This leads to the actual value containing the quotation
> marks instead of them being stripped off.
> * The whitespace preceding {color:#0747a6}*{{"201 First Street; Las Vegas,
> NV 89102"}}*{color} on the second record leads to it to being parsed as two
> values: {color:#0747a6}*{{"201 First Street; Las Vegas}}*{color} and {*}{{NV
> 89102"}}{*}.
> * The third record is the only one that parses as expected.
> I believe that this is because the trimming is done *after* the value is
> being parsed rather than consuming the whitespace following the delimiter
> during parsing. Either that, or the check for a quoted string is occurring
> *before* the whitespace is being consumed.
>
> *NOTE:* I have attached a ZIP file that easily reproduces the problem with
> the CSV file given above.
> To build the attached project use Apache Maven and then execute using using
> Java 11:
> {code:java}
> > unzip csvfail.zip
> > cd csvfail
> > mvn package
> > java -jar target/csv-fail-1.0-SNAPSHOT.jar{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (CSV-296) Delimiter followed by Whitespace then by Quotes Failing with setTrim(true)
[
https://issues.apache.org/jira/browse/CSV-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627302#comment-17627302
]
Barry M. Caceres edited comment on CSV-296 at 11/1/22 7:27 PM:
---
{{setIgnoreSurroundingSpaces(true) only kinda works I the text is quoted it
maintains the quotes as part of the text, whereas if the quotes immediately
follow the comma (or other separator) then the text is processed as a CSV
quoted string and the value does not have the quotes. But if any spaces follow
the comma before the first quote then the quotes are included as part of the
value and the text is taken literally.}}
was (Author: JIRAUSER289277):
setIgnoreSurroundingSpaces(true) only kinda works I the text is quoted it
maintains the quotes as part of the text, whereas if the quotes immediately
follow the comma (or other separator) then the text is processed as a CSV
quoted string and the value does not have the quotes. But if any spaces follow
the comma before the first quote then the quotes are included as part of the
value and the text is taken literally.
> Delimiter followed by Whitespace then by Quotes Failing with setTrim(true)
> --
>
> Key: CSV-296
> URL: https://issues.apache.org/jira/browse/CSV-296
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.8, 1.9.0
> Environment: +{*}macOS{*}:+
> {code:java}
> > uname -a
> Darwin Senzing-MacBook-Pro.local 21.4.0 Darwin Kernel Version 21.4.0: Fri Mar
> 18 00:45:05 PDT 2022; root:xnu-8020.101.4~15/RELEASE_X86_64 x86_64 {code}
> {code:java}
> > java -version
> openjdk version "11.0.14" 2022-01-18
> OpenJDK Runtime Environment Temurin-11.0.14+9 (build 11.0.14+9)
> OpenJDK 64-Bit Server VM Temurin-11.0.14+9 (build 11.0.14+9, mixed mode)
> {code}
> {+}*Linux*{+}:
> {code:java}
> > uname -a
> Linux lnxdev 5.4.0-109-generic #123-Ubuntu SMP Fri Apr 8 09:10:54 UTC 2022
> x86_64 x86_64 x86_64 GNU/Linux {code}
> {code:java}
> > java -version
> openjdk version "11.0.11" 2021-04-20
> OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
> OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed
> mode){code}
>Reporter: Barry M. Caceres
>Priority: Major
> Attachments: csvfail.zip
>
>
> I have my CSVFormat initialized such that *{{withTrim(true)}}* has been set
> {_}(see attached ZIP file){_}:
> {code:java}
> CSVFormat csvFormat = CSVFormat.DEFAULT.withFirstRecordAsHeader()
> .withIgnoreEmptyLines(true).withTrim(true);{code}
>
> However, a quoted string that begins after a delimiter followed by preceding
> whitespace is not properly parsed. For example:
> {code:java}
> GIVEN_NAME,SURNAME,ADDRESS,PHONE_NUMBER
> "Joe", "Schmoe","101 Main Street; Las Vegas, NV 89101","702-555-1212"
> "John","Doe", "201 First Street; Las Vegas, NV 89102", "702-555-1313"
> "Jane","Doe","301 Second Street; Las Vegas, NV 89103","702-555-1414"
> {code}
>
> * Notice the whitespace preceding {color:#0747a6}*{{"Schmoe"}}*{color} on
> the first record? This leads to the actual value containing the quotation
> marks instead of them being stripped off.
> * The whitespace preceding {color:#0747a6}*{{"201 First Street; Las Vegas,
> NV 89102"}}*{color} on the second record leads to it to being parsed as two
> values: {color:#0747a6}*{{"201 First Street; Las Vegas}}*{color} and {*}{{NV
> 89102"}}{*}.
> * The third record is the only one that parses as expected.
> I believe that this is because the trimming is done *after* the value is
> being parsed rather than consuming the whitespace following the delimiter
> during parsing. Either that, or the check for a quoted string is occurring
> *before* the whitespace is being consumed.
>
> *NOTE:* I have attached a ZIP file that easily reproduces the problem with
> the CSV file given above.
> To build the attached project use Apache Maven and then execute using using
> Java 11:
> {code:java}
> > unzip csvfail.zip
> > cd csvfail
> > mvn package
> > java -jar target/csv-fail-1.0-SNAPSHOT.jar{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (CSV-296) Delimiter followed by Whitespace then by Quotes Failing with setTrim(true)
[
https://issues.apache.org/jira/browse/CSV-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627302#comment-17627302
]
Barry M. Caceres commented on CSV-296:
--
setIgnoreSurroundingSpaces(true) only kinda works I the text is quoted it
maintains the quotes as part of the text, whereas if the quotes immediately
follow the comma (or other separator) then the text is processed as a CSV
quoted string and the value does not have the quotes. But if any spaces follow
the comma before the first quote then the quotes are included as part of the
value and the text is taken literally.
> Delimiter followed by Whitespace then by Quotes Failing with setTrim(true)
> --
>
> Key: CSV-296
> URL: https://issues.apache.org/jira/browse/CSV-296
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.8, 1.9.0
> Environment: +{*}macOS{*}:+
> {code:java}
> > uname -a
> Darwin Senzing-MacBook-Pro.local 21.4.0 Darwin Kernel Version 21.4.0: Fri Mar
> 18 00:45:05 PDT 2022; root:xnu-8020.101.4~15/RELEASE_X86_64 x86_64 {code}
> {code:java}
> > java -version
> openjdk version "11.0.14" 2022-01-18
> OpenJDK Runtime Environment Temurin-11.0.14+9 (build 11.0.14+9)
> OpenJDK 64-Bit Server VM Temurin-11.0.14+9 (build 11.0.14+9, mixed mode)
> {code}
> {+}*Linux*{+}:
> {code:java}
> > uname -a
> Linux lnxdev 5.4.0-109-generic #123-Ubuntu SMP Fri Apr 8 09:10:54 UTC 2022
> x86_64 x86_64 x86_64 GNU/Linux {code}
> {code:java}
> > java -version
> openjdk version "11.0.11" 2021-04-20
> OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9)
> OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed
> mode){code}
>Reporter: Barry M. Caceres
>Priority: Major
> Attachments: csvfail.zip
>
>
> I have my CSVFormat initialized such that *{{withTrim(true)}}* has been set
> {_}(see attached ZIP file){_}:
> {code:java}
> CSVFormat csvFormat = CSVFormat.DEFAULT.withFirstRecordAsHeader()
> .withIgnoreEmptyLines(true).withTrim(true);{code}
>
> However, a quoted string that begins after a delimiter followed by preceding
> whitespace is not properly parsed. For example:
> {code:java}
> GIVEN_NAME,SURNAME,ADDRESS,PHONE_NUMBER
> "Joe", "Schmoe","101 Main Street; Las Vegas, NV 89101","702-555-1212"
> "John","Doe", "201 First Street; Las Vegas, NV 89102", "702-555-1313"
> "Jane","Doe","301 Second Street; Las Vegas, NV 89103","702-555-1414"
> {code}
>
> * Notice the whitespace preceding {color:#0747a6}*{{"Schmoe"}}*{color} on
> the first record? This leads to the actual value containing the quotation
> marks instead of them being stripped off.
> * The whitespace preceding {color:#0747a6}*{{"201 First Street; Las Vegas,
> NV 89102"}}*{color} on the second record leads to it to being parsed as two
> values: {color:#0747a6}*{{"201 First Street; Las Vegas}}*{color} and {*}{{NV
> 89102"}}{*}.
> * The third record is the only one that parses as expected.
> I believe that this is because the trimming is done *after* the value is
> being parsed rather than consuming the whitespace following the delimiter
> during parsing. Either that, or the check for a quoted string is occurring
> *before* the whitespace is being consumed.
>
> *NOTE:* I have attached a ZIP file that easily reproduces the problem with
> the CSV file given above.
> To build the attached project use Apache Maven and then execute using using
> Java 11:
> {code:java}
> > unzip csvfail.zip
> > cd csvfail
> > mvn package
> > java -jar target/csv-fail-1.0-SNAPSHOT.jar{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [commons-collections] garydgregory merged pull request #354: Bump actions/upload-artifact from 3.1.0 to 3.1.1
garydgregory merged PR #354: URL: https://github.com/apache/commons-collections/pull/354 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-bcel] garydgregory commented on a diff in pull request #162: improve test coverage to bcel/generic and UtilityTest
garydgregory commented on code in PR #162:
URL: https://github.com/apache/commons-bcel/pull/162#discussion_r1010768596
##
src/test/java/org/apache/bcel/generic/BREAKPOINTTest.java:
##
@@ -0,0 +1,31 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.bcel.generic;
+
+import org.junit.jupiter.api.Test;
+
+import static org.junit.jupiter.api.Assertions.*;
+
+class BREAKPOINTTest {
+@Test
+public void accept() {
+CountVisitor countVisitor = new CountVisitor();
+BREAKPOINT breakpoint = new BREAKPOINT();
+breakpoint.accept(countVisitor);
+assertEquals(1, countVisitor.getVisitBREAKPOINTCount());
+}
+}
Review Comment:
Files should end in a new line. Check all new files.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-bcel] codecov-commenter commented on pull request #162: improve test coverage to bcel/generic and UtilityTest
codecov-commenter commented on PR #162: URL: https://github.com/apache/commons-bcel/pull/162#issuecomment-1298848173 # [Codecov](https://codecov.io/gh/apache/commons-bcel/pull/162?src=pr=h1_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) Report > Merging [#162](https://codecov.io/gh/apache/commons-bcel/pull/162?src=pr=desc_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) (e3655a8) into [master](https://codecov.io/gh/apache/commons-bcel/commit/587c9869e2dd9abc5dae70457c44f1ddabd0ef00?el=desc_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) (587c986) will **increase** coverage by `0.19%`. > The diff coverage is `n/a`. ```diff @@ Coverage Diff @@ ## master #162 +/- ## + Coverage 44.92% 45.12% +0.19% - Complexity 2516 2536 +20 Files 362 362 Lines 1556715567 Branches 1920 1920 + Hits 6994 7025 +31 + Misses 7891 7867 -24 + Partials682 675 -7 ``` | [Impacted Files](https://codecov.io/gh/apache/commons-bcel/pull/162?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) | Coverage Δ | | |---|---|---| | [...c/main/java/org/apache/bcel/classfile/Utility.java](https://codecov.io/gh/apache/commons-bcel/pull/162/diff?src=pr=tree_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation#diff-c3JjL21haW4vamF2YS9vcmcvYXBhY2hlL2JjZWwvY2xhc3NmaWxlL1V0aWxpdHkuamF2YQ==) | `71.28% <0.00%> (+5.17%)` | :arrow_up: | :mega: We’re building smart automated test selection to slash your CI/CD build times. [Learn more](https://about.codecov.io/iterative-testing/?utm_medium=referral_source=github_content=comment_campaign=pr+comments_term=The+Apache+Software+Foundation) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (BCEL-365) Improve Test Coverage on org.apache.bcel.generic
[ https://issues.apache.org/jira/browse/BCEL-365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627255#comment-17627255 ] Gary D. Gregory commented on BCEL-365: -- Feel free to provide a PR on GitHub ;) > Improve Test Coverage on org.apache.bcel.generic > > > Key: BCEL-365 > URL: https://issues.apache.org/jira/browse/BCEL-365 > Project: Commons BCEL > Issue Type: Improvement >Reporter: Ng Tsz Sum >Priority: Major > > The coverage is low BCEL in general. > https://app.codecov.io/gh/apache/commons-bcel > Good start with package org.apache.bcel.generic -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [commons-bcel] samabcde opened a new pull request, #162: improve test coverage to bcel/generic and UtilityTest
samabcde opened a new pull request, #162: URL: https://github.com/apache/commons-bcel/pull/162 For test class in `org.apache.bcel.generic`, basically just test the `accept` method as it is not covered for quite a lot of classes according to coverage report. If this approach looks fine, I can help to add similar test for remaining class in `org.apache.bcel.generic` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (IO-783) Fetching file extension using FilenameUtils.getExtension method throws error in windows machine
Samraj created IO-783:
-
Summary: Fetching file extension using FilenameUtils.getExtension
method throws error in windows machine
Key: IO-783
URL: https://issues.apache.org/jira/browse/IO-783
Project: Commons IO
Issue Type: Bug
Components: Utilities
Affects Versions: 2.11.0, 2.10.0, 2.9.0, 2.8.0, 2.7
Environment: Run the below line of code in windows environment.
String fileName = FilenameUtils.getExtension("Top of Information
Store\\Archive\\Informational-severity alert: eDiscovery search started or
exported.msg");
System.out.println(fileName);
We are getting the error,
Exception in thread "main" java.lang.IllegalArgumentException: NTFS ADS
separator (':') in file name is forbidden.
at
org.apache.commons.io.FilenameUtils.indexOfExtension(FilenameUtils.java:737)
at org.apache.commons.io.FilenameUtils.getExtension(FilenameUtils.java:1057)
Reporter: Samraj
Hi Team,
I am using FilenameUtils.getExtension method to get the file extension from the
file path ( Available as string). Due to one of the bug fix happen after 2.7
breaks the code.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (BCEL-365) Improve Test Coverage on org.apache.bcel.generic
Ng Tsz Sum created BCEL-365: --- Summary: Improve Test Coverage on org.apache.bcel.generic Key: BCEL-365 URL: https://issues.apache.org/jira/browse/BCEL-365 Project: Commons BCEL Issue Type: Improvement Reporter: Ng Tsz Sum The coverage is low BCEL in general. https://app.codecov.io/gh/apache/commons-bcel Good start with package org.apache.bcel.generic -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NUMBERS-29) Move combinatorics utilities from "Commons Math"
[
https://issues.apache.org/jira/browse/NUMBERS-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627239#comment-17627239
]
Alex Herbert commented on NUMBERS-29:
-
{quote} In which other cases, do we add the Numbers suffix?
{quote}
None. I've updated to Stirling.
I have made a port of this method into the combinatorics module. I updated the
recursion algorithm to perform a forward computation from the largest easily
computed number. This solves the issue with stack overflow in the S(n, n-3)
case. Using backward recursion can result in a call stack of 2738 for S(2762,
2759). Using forward recursion has a maximum depth of 2 for this case. The
largest call stack in the test data is for S(33, 23) with a depth of 10.
Typically bad cases will raise an arithmetic exception due to overflow of the
sum before the recursion depth is too high.
PR is here for review [PR
126|https://github.com/apache/commons-numbers/pull/126].
> Move combinatorics utilities from "Commons Math"
>
>
> Key: NUMBERS-29
> URL: https://issues.apache.org/jira/browse/NUMBERS-29
> Project: Commons Numbers
> Issue Type: Task
> Components: combinatorics
>Reporter: Gilles Sadowski
>Priority: Minor
> Labels: module, move
> Fix For: 1.2
>
>
> Create a new {{commons-numbers-combinatorics}} module to contain the code in
> classes {{CombinatoricsUtils}} and {{Combinations}} (located in package
> {{o.a.c.math4.util}}).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [commons-compress] garydgregory merged pull request #327: Bump actions/upload-artifact from 3.1.0 to 3.1.1
garydgregory merged PR #327: URL: https://github.com/apache/commons-compress/pull/327 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-pool] garydgregory merged pull request #188: Bump actions/upload-artifact from 3.1.0 to 3.1.1
garydgregory merged PR #188: URL: https://github.com/apache/commons-pool/pull/188 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-cli] garydgregory commented on pull request #141: JUnit5 assertThrows TypeHandlerTest
garydgregory commented on PR #141: URL: https://github.com/apache/commons-cli/pull/141#issuecomment-1298765785 @nhojpatrick ping -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-exec] garydgregory commented on a diff in pull request #73: JUnit5 assertThrows Exec65Test
garydgregory commented on code in PR #73:
URL: https://github.com/apache/commons-exec/pull/73#discussion_r1010613270
##
src/test/java/org/apache/commons/exec/issues/Exec65Test.java:
##
@@ -51,7 +53,8 @@ public void testExec65WitSleepUsingSleepCommandDirectly()
throws Exception {
executor.setStreamHandler(new PumpStreamHandler(System.out,
System.err));
executor.setWatchdog(watchdog);
-executor.execute(command);
+final Executable testMethod = () -> executor.execute(command);
Review Comment:
@nhojpatrick ping
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-exec] garydgregory commented on a diff in pull request #73: JUnit5 assertThrows Exec65Test
garydgregory commented on code in PR #73:
URL: https://github.com/apache/commons-exec/pull/73#discussion_r1010612960
##
src/test/java/org/apache/commons/exec/issues/Exec65Test.java:
##
@@ -51,7 +53,8 @@ public void testExec65WitSleepUsingSleepCommandDirectly()
throws Exception {
executor.setStreamHandler(new PumpStreamHandler(System.out,
System.err));
executor.setWatchdog(watchdog);
-executor.execute(command);
+final Executable testMethod = () -> executor.execute(command);
Review Comment:
@nhojpatrick ping
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-exec] garydgregory merged pull request #74: Bump actions/upload-artifact from 3.1.0 to 3.1.1
garydgregory merged PR #74: URL: https://github.com/apache/commons-exec/pull/74 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-logging] garydgregory merged pull request #116: Bump actions/upload-artifact from 3.1.0 to 3.1.1
garydgregory merged PR #116: URL: https://github.com/apache/commons-logging/pull/116 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (CONFIGURATION-823) Update Apache Commons Text from 1.9 to 1.10.0
[ https://issues.apache.org/jira/browse/CONFIGURATION-823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627207#comment-17627207 ] Gary D. Gregory commented on CONFIGURATION-823: --- As I already explained in the GitHub PR: Apache Commons Text 1.10.0 is already released, you can use it from you applications. There is no schedule as of yet for the next release of Commons Configuration. We do not create a release just to update a dependency since an app can do that on it's own. Note that we are volunteering our time. > Update Apache Commons Text from 1.9 to 1.10.0 > - > > Key: CONFIGURATION-823 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-823 > Project: Commons Configuration > Issue Type: Improvement >Affects Versions: 2.8.0 >Reporter: MOREAU >Priority: Critical > Fix For: 2.9.0 > > > There is a GHSL-2022-018 / CVE-2022-42889 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (CONFIGURATION-823) Update Apache Commons Text from 1.9 to 1.10.0
[ https://issues.apache.org/jira/browse/CONFIGURATION-823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved CONFIGURATION-823. --- Fix Version/s: 2.9.0 Resolution: Fixed > Update Apache Commons Text from 1.9 to 1.10.0 > - > > Key: CONFIGURATION-823 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-823 > Project: Commons Configuration > Issue Type: Improvement >Affects Versions: 2.8.0 >Reporter: MOREAU >Priority: Critical > Fix For: 2.9.0 > > > There is a GHSL-2022-018 / CVE-2022-42889 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (CONFIGURATION-823) Update Apache Commons Text from 1.9 to 1.10.0
[ https://issues.apache.org/jira/browse/CONFIGURATION-823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627205#comment-17627205 ] Moh Ryan Alfa Maulana commented on CONFIGURATION-823: - would you mind to help to release new version of commons-configuration as soon as possible? thank you. > Update Apache Commons Text from 1.9 to 1.10.0 > - > > Key: CONFIGURATION-823 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-823 > Project: Commons Configuration > Issue Type: Improvement >Affects Versions: 2.8.0 >Reporter: MOREAU >Priority: Critical > > There is a GHSL-2022-018 / CVE-2022-42889 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [commons-configuration] mohammadmaulana commented on pull request #221: Bump commons-text from 1.9 to 1.10.0
mohammadmaulana commented on PR #221: URL: https://github.com/apache/commons-configuration/pull/221#issuecomment-1298640321 got it, thanks, i may continue the conversation on this jira ticket https://issues.apache.org/jira/browse/CONFIGURATION-823 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (MATH-1650) Add clamped spline interpolation
[
https://issues.apache.org/jira/browse/MATH-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627196#comment-17627196
]
Gilles Sadowski commented on MATH-1650:
---
Thanks for the patch, and sorry for the delay in starting the review.
It's great that it compiles fine, but... there are no unit tests for this new
class!
Trivial (e.g. precondition) tests are necessary to ensure early failure with an
appropriate diagnostics.
Functionality tests are required to ensure expected behaviour and prevent
inadvertent code changes.
At least, the new {{interpolate}} method should have 100% coverage and several
use-cases (functions).
I guess that you could use {{SplineInterpolatorTest}} as a starting point.
> Add clamped spline interpolation
>
>
> Key: MATH-1650
> URL: https://issues.apache.org/jira/browse/MATH-1650
> Project: Commons Math
> Issue Type: New Feature
>Affects Versions: 4.X
>Reporter: Michael Scholz
>Priority: Minor
> Labels: Polynomials, interpolation, spline
> Attachments: 2022-10-05_ClampedSplineInterpolator.patch
>
>
> We would like to contribute a new _clamped_ spline interpolation function in
> addition to the already available unclamped spline function. Our new
> {{ClampedSplineInterpolator}} is based on the same textbook as the original
> {{{}SplineInterpolator{}}}. The clamped spline offers additional
> parameterisation of starting and ending slopes (1st derivatives) as boundary
> conditions in order to provide more flexibility in spline creation.
> In this patch we follow the approach of subclassing the original
> {{SplineInterpolator}} and simply overloading it's {{interpolate()}} function
> by these two additional parameters. Is this an acceptable way or does the
> community recommend a different design approach?
> After clarifying the basic implementation approach we could also supply
> necessary tests etc. and finally contribute everything via ordinary GitHub
> pull request.
> Refer to our post on the dev mailing list:
> https://lists.apache.org/thread/34qnx4tgjbyv345lgmd57g0bnlnwdzc8
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [commons-text] arturobernalg commented on pull request #375: Use java8 Stream.
arturobernalg commented on PR #375: URL: https://github.com/apache/commons-text/pull/375#issuecomment-1298512665 > @arturobernalg there is nothing to review until the builds are green ;-) Hey @garydgregory Yep. looks green now. TY -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (NUMBERS-29) Move combinatorics utilities from "Commons Math"
[
https://issues.apache.org/jira/browse/NUMBERS-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627146#comment-17627146
]
Gilles Sadowski commented on NUMBERS-29:
In which other cases, do we add the {{Numbers}} suffix?
[In this case, it seems quite redundant (unless we plan to add, to this
component, other Stirling's contributions to mathematics that would need to be
disambiguated).]
> Move combinatorics utilities from "Commons Math"
>
>
> Key: NUMBERS-29
> URL: https://issues.apache.org/jira/browse/NUMBERS-29
> Project: Commons Numbers
> Issue Type: Task
> Components: combinatorics
>Reporter: Gilles Sadowski
>Priority: Minor
> Labels: module, move
> Fix For: 1.2
>
>
> Create a new {{commons-numbers-combinatorics}} module to contain the code in
> classes {{CombinatoricsUtils}} and {{Combinations}} (located in package
> {{o.a.c.math4.util}}).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [commons-text] garydgregory commented on pull request #375: Use java8 Stream.
garydgregory commented on PR #375: URL: https://github.com/apache/commons-text/pull/375#issuecomment-1298364555 @arturobernalg there is nothing to review until the builds are green ;-) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Closed] (NUMBERS-162) Use "of" as method name
[
https://issues.apache.org/jira/browse/NUMBERS-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Herbert closed NUMBERS-162.
> Use "of" as method name
> ---
>
> Key: NUMBERS-162
> URL: https://issues.apache.org/jira/browse/NUMBERS-162
> Project: Commons Numbers
> Issue Type: Wish
>Reporter: Gilles Sadowski
>Priority: Trivial
>
> Whenever it improves readability, prefer {{of}} as a method name.
> Examples:
> {code:java}
> final double r = LinearCombination.of(a, b, c, d);
> final double s = Summation.of(a, c);
> {code}
> instead of
> {code:java}
> final double r = LinearCombination.value(a, b, c, d);
> final double s = Summation.value(a, c);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (JEXL-381) Change default JEXL configuration to a more security-friendly behaviour
[ https://issues.apache.org/jira/browse/JEXL-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627053#comment-17627053 ] Henri Biestro edited comment on JEXL-381 at 11/1/22 9:52 AM: - [~dmitri_blinov] The cost of the @NoJexl annotation - and permission - check is only incurred once during method discovery whilst populating the class cache so I doubt you are saving much. As for private method, IMO these should remain hidden from JEXL... (java17 is stricter on what can be called from where). I'm quite interested in your Sandbox/security configuration; at quick glance, this did not seem to be in your repo/unit tests but I may have missed it. Care to share ? Thanks :-) was (Author: henrib): [~dmitri_blinov] The cost of the @NoJexl annotation check is only incurred once during method discovery whilst populating the class cache so I doubt you are saving much. As for private method, IMO these should remain hidden from JEXL... (java17 is stricter on what can be called from where). I'm quite interested in your Sandbox/security configuration; at quick glance, this did not seem to be in your repo/unit tests but I may have missed it. Care to share ? Thank :-) > Change default JEXL configuration to a more security-friendly behaviour > > > Key: JEXL-381 > URL: https://issues.apache.org/jira/browse/JEXL-381 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > WHAT: > JEXL's default builder allows accessing and calling any public method, field > or constructor of any public class. This might not be desirable since a quick > exploration of JEXL will quickly conclude the library allows arbitrary > execution through commands (ProcessBuilder) or getting to the file-system > through URL or File. This improvement goal is to change JEXL's permeability > as an explicit option and user decision, not a default behaviour. > HOW: > By changing the current JexlBuilder to use a restricted set of permissions > whilst instantiating the Uberspect, we can ensure a minimal useful set of > classes can be accessed and only those by default. By removing access to > almost all classes that interact with the JVM host and file-system, we ensure > a default isolation that would significantly reduce the ability to use JEXL > as an attack vector. > CAVEAT: > This change will likely break many scripts that were dependant upon the > default permeability. > [~ggregory], [~dmitri_blinov] your opinions are welcome :-) > https://lists.apache.org/thread/kgh0kfkcvllp5mj7kwnpdqrbrfcyyopd -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (JEXL-381) Change default JEXL configuration to a more security-friendly behaviour
[ https://issues.apache.org/jira/browse/JEXL-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627053#comment-17627053 ] Henri Biestro edited comment on JEXL-381 at 11/1/22 9:49 AM: - [~dmitri_blinov] The cost of the @NoJexl annotation check is only incurred once during method discovery whilst populating the class cache so I doubt you are saving much. As for private method, IMO these should remain hidden from JEXL... (java17 is stricter on what can be called from where). I'm quite interested in your Sandbox/security configuration; at quick glance, this did not seem to be in your repo/unit tests but I may have missed it. Care to share ? Thank :-) was (Author: henrib): [~dmitri_blinov] The cost of the @NoJexl annotation check is only incurred once during method discovery whilst populating the class cache so I doubt you are saving much. As for private method, IMO these should remain hidden from JEXL... I'm quite interested in your Sandbox/security configuration; at quick glance, this did not seem to be in your repo/unit tests but I may have missed it. Care to share ? Thank :-) > Change default JEXL configuration to a more security-friendly behaviour > > > Key: JEXL-381 > URL: https://issues.apache.org/jira/browse/JEXL-381 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > WHAT: > JEXL's default builder allows accessing and calling any public method, field > or constructor of any public class. This might not be desirable since a quick > exploration of JEXL will quickly conclude the library allows arbitrary > execution through commands (ProcessBuilder) or getting to the file-system > through URL or File. This improvement goal is to change JEXL's permeability > as an explicit option and user decision, not a default behaviour. > HOW: > By changing the current JexlBuilder to use a restricted set of permissions > whilst instantiating the Uberspect, we can ensure a minimal useful set of > classes can be accessed and only those by default. By removing access to > almost all classes that interact with the JVM host and file-system, we ensure > a default isolation that would significantly reduce the ability to use JEXL > as an attack vector. > CAVEAT: > This change will likely break many scripts that were dependant upon the > default permeability. > [~ggregory], [~dmitri_blinov] your opinions are welcome :-) > https://lists.apache.org/thread/kgh0kfkcvllp5mj7kwnpdqrbrfcyyopd -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (JEXL-381) Change default JEXL configuration to a more security-friendly behaviour
[ https://issues.apache.org/jira/browse/JEXL-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17627053#comment-17627053 ] Henri Biestro commented on JEXL-381: [~dmitri_blinov] The cost of the @NoJexl annotation check is only incurred once during method discovery whilst populating the class cache so I doubt you are saving much. As for private method, IMO these should remain hidden from JEXL... I'm quite interested in your Sandbox/security configuration; at quick glance, this did not seem to be in your repo/unit tests but I may have missed it. Care to share ? Thank :-) > Change default JEXL configuration to a more security-friendly behaviour > > > Key: JEXL-381 > URL: https://issues.apache.org/jira/browse/JEXL-381 > Project: Commons JEXL > Issue Type: Improvement >Affects Versions: 3.2.1 >Reporter: Henri Biestro >Assignee: Henri Biestro >Priority: Major > Fix For: 3.3 > > > WHAT: > JEXL's default builder allows accessing and calling any public method, field > or constructor of any public class. This might not be desirable since a quick > exploration of JEXL will quickly conclude the library allows arbitrary > execution through commands (ProcessBuilder) or getting to the file-system > through URL or File. This improvement goal is to change JEXL's permeability > as an explicit option and user decision, not a default behaviour. > HOW: > By changing the current JexlBuilder to use a restricted set of permissions > whilst instantiating the Uberspect, we can ensure a minimal useful set of > classes can be accessed and only those by default. By removing access to > almost all classes that interact with the JVM host and file-system, we ensure > a default isolation that would significantly reduce the ability to use JEXL > as an attack vector. > CAVEAT: > This change will likely break many scripts that were dependant upon the > default permeability. > [~ggregory], [~dmitri_blinov] your opinions are welcome :-) > https://lists.apache.org/thread/kgh0kfkcvllp5mj7kwnpdqrbrfcyyopd -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TEXT-221) Incompatible OSGI Bundle-SymbolicName since parent version 47
Remco Riswick created TEXT-221:
--
Summary: Incompatible OSGI Bundle-SymbolicName since parent
version 47
Key: TEXT-221
URL: https://issues.apache.org/jira/browse/TEXT-221
Project: Commons Text
Issue Type: Bug
Affects Versions: 1.10.0, 1.9, 1.8, 1.7, 1.6, 1.5
Reporter: Remco Riswick
Since the change in parent version 47 of the property
commons.osgi.symbolicName. The Bundle-SymbolicName of commons-text has changed
and is now incompatible with previous versions.
Parent version 46 and before:
{code:java}
org.apache.commons.${commons.componentid}{code}
Bundle-SymbolicName becomes
{code:java}
org.apache.commons.text {code}
>From parent version 47 and onwards
{code:java}
org.apache.commons.${commons.packageId}{code}
Bundle-SymbolicName becomes
{code:java}
org.apache.commons.commons-text {code}
This bug was already reported in the commons parent project as COMMONSSITE-125.
And a similar bug was fixed for the commons-lang project LANG-1419.
The fix there was to add the commons.packageId to the pom.xml
{code:java}
text{code}
This will fix the problem and restore the original Bundle-SymbolicName
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
