[jira] [Commented] (POOL-337) EvictionTimer does not remove cancelled tasks from the executor, leading to an IllegalStateException when the evictor attempts to evict
[
https://issues.apache.org/jira/browse/POOL-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426485#comment-16426485
]
ASF GitHub Bot commented on POOL-337:
-
Github user garydgregory commented on the issue:
https://github.com/apache/commons-pool/pull/4
I should be able to take a look tomorrow or the next day.
> EvictionTimer does not remove cancelled tasks from the executor, leading to
> an IllegalStateException when the evictor attempts to evict
> ---
>
> Key: POOL-337
> URL: https://issues.apache.org/jira/browse/POOL-337
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 2.5.0
>Reporter: Reinald Verheij
>Priority: Major
> Attachments: EvictionTimer.java,
> EvictionTimer.java.original-from-2.5.0.java
>
>
> EvictionTimer does not remove cancelled tasks from the executor, leading to
> an IllegalStateException when the evictor attempts to evict.
>
> EvictionTimer::schedule() adds eviction tasks to the executor, but the cancel
> does not remove it. This is asymmetric and leads to the following exception:
> {noformat}
> java.lang.IllegalStateException: Pool not open
> at
> org.apache.commons.pool2.impl.BaseGenericObjectPool.assertOpen(BaseGenericObjectPool.java:713)
> at
> org.apache.commons.pool2.impl.GenericObjectPool.evict(GenericObjectPool.java:721)
> at
> org.apache.commons.pool2.impl.BaseGenericObjectPool$Evictor.run(BaseGenericObjectPool.java:1077)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748){noformat}
> I think the cancel would need to remember the future which returned from
> {{executor::scheduleWithFixedDelay()}} in {{schedule()}} and then do
> something like this (see [^EvictionTimer.java] compared to original
> [^EvictionTimer.java.original-from-2.5.0.java] )
> {code:java}
> if (futures.containsKey(task)) {
> futures.remove(task).cancel(false);
> executor.purge();
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (POOL-338) GenericObjectPool constructor throws an exception
[
https://issues.apache.org/jira/browse/POOL-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426123#comment-16426123
]
Gary Gregory commented on POOL-338:
---
I wonder if this is a class loader issue. Can you describe your environment?
> GenericObjectPool constructor throws an exception
> -
>
> Key: POOL-338
> URL: https://issues.apache.org/jira/browse/POOL-338
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 2.4.2, 2.4.3, 2.5.0
> Environment: Java 8
>Reporter: Michael C
>Priority: Major
>
> Version 2.4.3 GenericObjectPool constructor throws this exception:
> {{java.lang.IllegalArgumentException:
> [org.apache.commons.pool2.impl.DefaultEvictionPolicy] does not implement
> EvictionPolicy}}
> {{ at
> org.apache.commons.pool2.impl.BaseGenericObjectPool.setEvictionPolicyClassName(BaseGenericObjectPool.java:618)}}
> {{ at
> org.apache.commons.pool2.impl.GenericObjectPool.setConfig(GenericObjectPool.java:318)}}
> {{ at
> org.apache.commons.pool2.impl.GenericObjectPool.(GenericObjectPool.java:115)}}
> {{ at
> org.apache.commons.pool2.impl.GenericObjectPool.(GenericObjectPool.java:88)}}
>
> Version 2.5.0 throws the same exception. Version 2.4.2 or older's
> setEvictionPolicyClassName method fail silently for the same reason. This
> line in BaseGenericObjectPool evaluates to false for all versions:
> {{ if (policy instanceof EvictionPolicy) {}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (POOL-338) GenericObjectPool constructor throws an exception
[
https://issues.apache.org/jira/browse/POOL-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael C updated POOL-338:
---
Environment: Java 8
> GenericObjectPool constructor throws an exception
> -
>
> Key: POOL-338
> URL: https://issues.apache.org/jira/browse/POOL-338
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 2.4.2, 2.4.3, 2.5.0
> Environment: Java 8
>Reporter: Michael C
>Priority: Major
>
> Version 2.4.3 GenericObjectPool constructor throws this exception:
> {{java.lang.IllegalArgumentException:
> [org.apache.commons.pool2.impl.DefaultEvictionPolicy] does not implement
> EvictionPolicy}}
> {{ at
> org.apache.commons.pool2.impl.BaseGenericObjectPool.setEvictionPolicyClassName(BaseGenericObjectPool.java:618)}}
> {{ at
> org.apache.commons.pool2.impl.GenericObjectPool.setConfig(GenericObjectPool.java:318)}}
> {{ at
> org.apache.commons.pool2.impl.GenericObjectPool.(GenericObjectPool.java:115)}}
> {{ at
> org.apache.commons.pool2.impl.GenericObjectPool.(GenericObjectPool.java:88)}}
>
> Version 2.5.0 throws the same exception. Version 2.4.2 or older's
> setEvictionPolicyClassName method fail silently for the same reason. This
> line in BaseGenericObjectPool evaluates to false for all versions:
> {{ if (policy instanceof EvictionPolicy) {}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (POOL-338) GenericObjectPool constructor throws an exception
Michael C created POOL-338:
--
Summary: GenericObjectPool constructor throws an exception
Key: POOL-338
URL: https://issues.apache.org/jira/browse/POOL-338
Project: Commons Pool
Issue Type: Bug
Affects Versions: 2.5.0, 2.4.3, 2.4.2
Reporter: Michael C
Version 2.4.3 GenericObjectPool constructor throws this exception:
{{java.lang.IllegalArgumentException:
[org.apache.commons.pool2.impl.DefaultEvictionPolicy] does not implement
EvictionPolicy}}
{{ at
org.apache.commons.pool2.impl.BaseGenericObjectPool.setEvictionPolicyClassName(BaseGenericObjectPool.java:618)}}
{{ at
org.apache.commons.pool2.impl.GenericObjectPool.setConfig(GenericObjectPool.java:318)}}
{{ at
org.apache.commons.pool2.impl.GenericObjectPool.(GenericObjectPool.java:115)}}
{{ at
org.apache.commons.pool2.impl.GenericObjectPool.(GenericObjectPool.java:88)}}
Version 2.5.0 throws the same exception. Version 2.4.2 or older's
setEvictionPolicyClassName method fail silently for the same reason. This line
in BaseGenericObjectPool evaluates to false for all versions:
{{ if (policy instanceof EvictionPolicy) {}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (SCXML-280) Dividing the library into two parts api and impl.
[ https://issues.apache.org/jira/browse/SCXML-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Waldemar Kłaczyński updated SCXML-280: -- Description: I integrate jsf with a common scxml. [https://github.com/wklaczynski/state-flow-faces] Is it possible to divide a library into a part of api and impl? In the api part there should be only elements: model, semantics, simple. "EvaluatorFactory" and "ContentParser" load using ServiceLoader.load (... Introduction of save and restore state to ececutor. This is necessary for a distribuable session. A simple way to transfer data between servers without using serialization if it is not necessary. [https://github.com/wklaczynski/state-flow-faces/blob/master/state-flow-fases-api/src/main/java/org/apache/common/scxml/SCXMLExecutor.java] I have now isolated part of your library, and I have made changes. My proposition changes are visible in the api of my version library for jsf and state chat integration: [https://github.com/wklaczynski/state-flow-faces/tree/master/state-flow-fases-api/src/main/java/org/apache/common/scxml] Is it possible to make similar changes to the project so that it can be used directly from your library in my integration with jsf? was: I integrate jsf with a common scxml. [https://github.com/wklaczynski/state-flow-faces] Is it possible to divide a library into a part of api and impl? In the api part there should be only elements: model, semantics, simple. "EvaluatorFactory" and "ContentParser" load using ServiceLoader.load (... Introduction of save and restore state to ececutor. This is necessary for a distribuable session. A simple way to transfer data between servers without using serialization if it is not necessary. [https://github.com/wklaczynski/state-flow-faces/blob/master/state-flow-fases-api/src/main/java/org/apache/common/scxml/SCXMLExecutor.java] I have now isolated part of your library, and I have made changes. My proposition changes are visible in the api of my version library for jsf and state chat integration: [https://github.com/wklaczynski/state-flow-faces/tree/master/state-flow-fases-api/src/main/java/org/apache/common/scxml] Is it possible to make similar changes to your project so that you can use your library in my integration with jsf? > Dividing the library into two parts api and impl. > - > > Key: SCXML-280 > URL: https://issues.apache.org/jira/browse/SCXML-280 > Project: Commons SCXML > Issue Type: New Feature >Affects Versions: 2.0 >Reporter: Waldemar Kłaczyński >Priority: Major > Fix For: 2.0 > > > I integrate jsf with a common scxml. > [https://github.com/wklaczynski/state-flow-faces] > Is it possible to divide a library into a part of api and impl? > In the api part there should be only elements: model, semantics, simple. > "EvaluatorFactory" and "ContentParser" load using ServiceLoader.load (... > > Introduction of save and restore state to ececutor. This is necessary for a > distribuable session. A simple way to transfer data between servers without > using serialization if it is not necessary. > [https://github.com/wklaczynski/state-flow-faces/blob/master/state-flow-fases-api/src/main/java/org/apache/common/scxml/SCXMLExecutor.java] > I have now isolated part of your library, and I have made changes. My > proposition changes are visible in the api of my version library for jsf and > state chat integration: > [https://github.com/wklaczynski/state-flow-faces/tree/master/state-flow-fases-api/src/main/java/org/apache/common/scxml] > Is it possible to make similar changes to the project so that it can be used > directly from your library in my integration with jsf? > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SCXML-280) Dividing the library into two parts api and impl.
[ https://issues.apache.org/jira/browse/SCXML-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Waldemar Kłaczyński updated SCXML-280: -- Description: I integrate jsf with a common scxml. [https://github.com/wklaczynski/state-flow-faces] Is it possible to divide a library into a part of api and impl? In the api part there should be only elements: model, semantics, simple. "EvaluatorFactory" and "ContentParser" load using ServiceLoader.load (... Introduction of save and restore state to ececutor. This is necessary for a distribuable session. A simple way to transfer data between servers without using serialization if it is not necessary. [https://github.com/wklaczynski/state-flow-faces/blob/master/state-flow-fases-api/src/main/java/org/apache/common/scxml/SCXMLExecutor.java] I have now isolated part of your library, and I have made changes. My proposition changes are visible in the api of my version library for jsf and state chat integration: [https://github.com/wklaczynski/state-flow-faces/tree/master/state-flow-fases-api/src/main/java/org/apache/common/scxml] Is it possible to make similar changes to your project so that you can use your library in my integration with jsf? was: I integrate jsf with a common scxml. [https://github.com/wklaczynski/state-flow-faces] Is it possible to divide a library into a part of api and impl? In the api part there should be only elements: model, semantics, simple. "EvaluatorFactory" and "ContentParser" load using ServiceLoader.load (... Introduction of save and restore state to ececutor. This is necessary for a distribuable session. A simple way to transfer data between servers without using serialization if it is not necessary. [https://github.com/wklaczynski/state-flow-faces/blob/master/state-flow-fases-api/src/main/java/org/apache/common/scxml/SCXMLExecutor.java] I have now isolated part of your library, and I have made changes. Changes are visible in the api of my copy version library: [https://github.com/wklaczynski/state-flow-faces/tree/master/state-flow-fases-api/src/main/java/org/apache/common/scxml] Is it possible to make similar changes to your project so that you can use your library in my integration with jsf? > Dividing the library into two parts api and impl. > - > > Key: SCXML-280 > URL: https://issues.apache.org/jira/browse/SCXML-280 > Project: Commons SCXML > Issue Type: New Feature >Affects Versions: 2.0 >Reporter: Waldemar Kłaczyński >Priority: Major > Fix For: 2.0 > > > I integrate jsf with a common scxml. > [https://github.com/wklaczynski/state-flow-faces] > Is it possible to divide a library into a part of api and impl? > In the api part there should be only elements: model, semantics, simple. > "EvaluatorFactory" and "ContentParser" load using ServiceLoader.load (... > > Introduction of save and restore state to ececutor. This is necessary for a > distribuable session. A simple way to transfer data between servers without > using serialization if it is not necessary. > [https://github.com/wklaczynski/state-flow-faces/blob/master/state-flow-fases-api/src/main/java/org/apache/common/scxml/SCXMLExecutor.java] > I have now isolated part of your library, and I have made changes. My > proposition changes are visible in the api of my version library for jsf and > state chat integration: > [https://github.com/wklaczynski/state-flow-faces/tree/master/state-flow-fases-api/src/main/java/org/apache/common/scxml] > Is it possible to make similar changes to your project so that you can use > your library in my integration with jsf? > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (SCXML-280) Dividing the library into two parts api and impl.
[ https://issues.apache.org/jira/browse/SCXML-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Waldemar Kłaczyński updated SCXML-280: -- Description: I integrate jsf with a common scxml. [https://github.com/wklaczynski/state-flow-faces] Is it possible to divide a library into a part of api and impl? In the api part there should be only elements: model, semantics, simple. "EvaluatorFactory" and "ContentParser" load using ServiceLoader.load (... Introduction of save and restore state to ececutor. This is necessary for a distribuable session. A simple way to transfer data between servers without using serialization if it is not necessary. [https://github.com/wklaczynski/state-flow-faces/blob/master/state-flow-fases-api/src/main/java/org/apache/common/scxml/SCXMLExecutor.java] I have now isolated part of your library, and I have made changes. Changes are visible in the api of my copy version library: [https://github.com/wklaczynski/state-flow-faces/tree/master/state-flow-fases-api/src/main/java/org/apache/common/scxml] Is it possible to make similar changes to your project so that you can use your library in my integration with jsf? was: I integrate jsf with a common scxml. [https://github.com/wklaczynski/state-flow-faces] Is it possible to divide a library into a part of api and impl? In the api part there should be only elements: model, semantics, simple. "EvaluatorFactory" and "ContentParser" load using ServiceLoader.load (... Introduction of save and restore state to ececutor. This is necessary for a distribuable session. A simple way to transfer data between servers without using serialization if it is not necessary. https://github.com/wklaczynski/state-flow-faces/blob/master/state-flow-fases-api/src/main/java/org/apache/common/scxml/SCXMLExecutor.java I have now isolated part of your library, and I have made changes. Changes are visible in the api of my library: https://github.com/wklaczynski/state-flow-faces/tree/master/state-flow-fases-api/src/main/java/org/apache/common/scxml Is it possible to make similar changes to your project so that you can use your library in my integration with jsf? > Dividing the library into two parts api and impl. > - > > Key: SCXML-280 > URL: https://issues.apache.org/jira/browse/SCXML-280 > Project: Commons SCXML > Issue Type: New Feature >Affects Versions: 2.0 >Reporter: Waldemar Kłaczyński >Priority: Major > Fix For: 2.0 > > > I integrate jsf with a common scxml. > [https://github.com/wklaczynski/state-flow-faces] > Is it possible to divide a library into a part of api and impl? > In the api part there should be only elements: model, semantics, simple. > "EvaluatorFactory" and "ContentParser" load using ServiceLoader.load (... > > Introduction of save and restore state to ececutor. This is necessary for a > distribuable session. A simple way to transfer data between servers without > using serialization if it is not necessary. > [https://github.com/wklaczynski/state-flow-faces/blob/master/state-flow-fases-api/src/main/java/org/apache/common/scxml/SCXMLExecutor.java] > I have now isolated part of your library, and I have made changes. Changes > are visible in the api of my copy version library: > [https://github.com/wklaczynski/state-flow-faces/tree/master/state-flow-fases-api/src/main/java/org/apache/common/scxml] > Is it possible to make similar changes to your project so that you can use > your library in my integration with jsf? > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (SCXML-280) Dividing the library into two parts api and impl.
Waldemar Kłaczyński created SCXML-280: - Summary: Dividing the library into two parts api and impl. Key: SCXML-280 URL: https://issues.apache.org/jira/browse/SCXML-280 Project: Commons SCXML Issue Type: New Feature Affects Versions: 2.0 Reporter: Waldemar Kłaczyński Fix For: 2.0 I integrate jsf with a common scxml. [https://github.com/wklaczynski/state-flow-faces] Is it possible to divide a library into a part of api and impl? In the api part there should be only elements: model, semantics, simple. "EvaluatorFactory" and "ContentParser" load using ServiceLoader.load (... Introduction of save and restore state to ececutor. This is necessary for a distribuable session. A simple way to transfer data between servers without using serialization if it is not necessary. https://github.com/wklaczynski/state-flow-faces/blob/master/state-flow-fases-api/src/main/java/org/apache/common/scxml/SCXMLExecutor.java I have now isolated part of your library, and I have made changes. Changes are visible in the api of my library: https://github.com/wklaczynski/state-flow-faces/tree/master/state-flow-fases-api/src/main/java/org/apache/common/scxml Is it possible to make similar changes to your project so that you can use your library in my integration with jsf? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (TEXT-121) Update Java requirement from version 7 to 8.
[ https://issues.apache.org/jira/browse/TEXT-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed TEXT-121. - Resolution: Fixed Assignee: Gary Gregory In git master. > Update Java requirement from version 7 to 8. > > > Key: TEXT-121 > URL: https://issues.apache.org/jira/browse/TEXT-121 > Project: Commons Text > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Gary Gregory >Assignee: Gary Gregory >Priority: Major > Fix For: 1.4 > > > Update Java requirement from version 7 to 8. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TEXT-121) Update Java requirement from version 7 to 8.
Gary Gregory created TEXT-121: - Summary: Update Java requirement from version 7 to 8. Key: TEXT-121 URL: https://issues.apache.org/jira/browse/TEXT-121 Project: Commons Text Issue Type: Improvement Affects Versions: 1.3 Reporter: Gary Gregory Fix For: 1.4 Update Java requirement from version 7 to 8. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CSV-222) invalid char between encapsulated token and delimiter
[
https://issues.apache.org/jira/browse/CSV-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425803#comment-16425803
]
Patrick Gäckle commented on CSV-222:
Ah sure. I see what I can do about that.
> invalid char between encapsulated token and delimiter
> -
>
> Key: CSV-222
> URL: https://issues.apache.org/jira/browse/CSV-222
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.4
>Reporter: Patrick Gäckle
>Priority: Major
> Attachments: faulty.csv, faulty2.csv
>
>
> When trying to read the file [^faulty.csv] and parse it I get the following
> error:
> {code}
> java.io.IOException: (line 1) invalid char between encapsulated token and
> delimiter
> at org.apache.commons.csv.Lexer.parseEncapsulatedToken(Lexer.java:275)
> at org.apache.commons.csv.Lexer.nextToken(Lexer.java:152)
> at org.apache.commons.csv.CSVParser.nextRecord(CSVParser.java:500)
> at org.apache.commons.csv.CSVParser.initializeHeader(CSVParser.java:389)
> at org.apache.commons.csv.CSVParser.(CSVParser.java:284)
> at org.apache.commons.csv.CSVParser.(CSVParser.java:252)
> at org.apache.commons.csv.CSVFormat.parse(CSVFormat.java:846)
> {code}
> The line of code is the parsing part returning the iterator of it:
> {code:java}
> csvFormat =
> CSVFormat.DEFAULT.withHeader().withDelimiter(';').withIgnoreHeaderCase();
> iterator = csvFormat.parse(reader).iterator();
> {code}
> The invalid char is the contained SOH and STX non printable characters at the
> end of line.
> I debugged through the source of this and ran into the Exception in the Lexer
> not handling these special characters
> Unfortunately I'm not able to provide some hints on fixing this as I'm not
> familiar with these type of characters and what behaviour they should have.
> Sincerely
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COLLECTIONS-679) MultiValuedMap JavaDoc Typo
[ https://issues.apache.org/jira/browse/COLLECTIONS-679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425801#comment-16425801 ] Gary Gregory commented on COLLECTIONS-679: -- Please feel free to provide a PR on GitHub: https://github.com/apache/commons-collections > MultiValuedMap JavaDoc Typo > --- > > Key: COLLECTIONS-679 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-679 > Project: Commons Collections > Issue Type: Bug >Reporter: BELUGA BEHR >Priority: Trivial > > https://github.com/apache/commons-collections/blob/36d33722c37417b2fba57106fee185a5e422ee47/src/main/java/org/apache/commons/collections4/MultiValuedMap.java#L35 > The example code provided refers to a class called _MultiValuedHashMap_. > There is no such class in Commons Collection4. Perhaps > _ArrayListValuedHashMap_ is a better example. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (CSV-222) invalid char between encapsulated token and delimiter
[
https://issues.apache.org/jira/browse/CSV-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Gäckle updated CSV-222:
---
Comment: was deleted
(was: Sorry I don't know what PR means.)
> invalid char between encapsulated token and delimiter
> -
>
> Key: CSV-222
> URL: https://issues.apache.org/jira/browse/CSV-222
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.4
>Reporter: Patrick Gäckle
>Priority: Major
> Attachments: faulty.csv, faulty2.csv
>
>
> When trying to read the file [^faulty.csv] and parse it I get the following
> error:
> {code}
> java.io.IOException: (line 1) invalid char between encapsulated token and
> delimiter
> at org.apache.commons.csv.Lexer.parseEncapsulatedToken(Lexer.java:275)
> at org.apache.commons.csv.Lexer.nextToken(Lexer.java:152)
> at org.apache.commons.csv.CSVParser.nextRecord(CSVParser.java:500)
> at org.apache.commons.csv.CSVParser.initializeHeader(CSVParser.java:389)
> at org.apache.commons.csv.CSVParser.(CSVParser.java:284)
> at org.apache.commons.csv.CSVParser.(CSVParser.java:252)
> at org.apache.commons.csv.CSVFormat.parse(CSVFormat.java:846)
> {code}
> The line of code is the parsing part returning the iterator of it:
> {code:java}
> csvFormat =
> CSVFormat.DEFAULT.withHeader().withDelimiter(';').withIgnoreHeaderCase();
> iterator = csvFormat.parse(reader).iterator();
> {code}
> The invalid char is the contained SOH and STX non printable characters at the
> end of line.
> I debugged through the source of this and ran into the Exception in the Lexer
> not handling these special characters
> Unfortunately I'm not able to provide some hints on fixing this as I'm not
> familiar with these type of characters and what behaviour they should have.
> Sincerely
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CSV-222) invalid char between encapsulated token and delimiter
[
https://issues.apache.org/jira/browse/CSV-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425799#comment-16425799
]
Gary Gregory commented on CSV-222:
--
That would be a "Pull Request" on GitHub: https://github.com/apache/commons-csv
> invalid char between encapsulated token and delimiter
> -
>
> Key: CSV-222
> URL: https://issues.apache.org/jira/browse/CSV-222
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.4
>Reporter: Patrick Gäckle
>Priority: Major
> Attachments: faulty.csv, faulty2.csv
>
>
> When trying to read the file [^faulty.csv] and parse it I get the following
> error:
> {code}
> java.io.IOException: (line 1) invalid char between encapsulated token and
> delimiter
> at org.apache.commons.csv.Lexer.parseEncapsulatedToken(Lexer.java:275)
> at org.apache.commons.csv.Lexer.nextToken(Lexer.java:152)
> at org.apache.commons.csv.CSVParser.nextRecord(CSVParser.java:500)
> at org.apache.commons.csv.CSVParser.initializeHeader(CSVParser.java:389)
> at org.apache.commons.csv.CSVParser.(CSVParser.java:284)
> at org.apache.commons.csv.CSVParser.(CSVParser.java:252)
> at org.apache.commons.csv.CSVFormat.parse(CSVFormat.java:846)
> {code}
> The line of code is the parsing part returning the iterator of it:
> {code:java}
> csvFormat =
> CSVFormat.DEFAULT.withHeader().withDelimiter(';').withIgnoreHeaderCase();
> iterator = csvFormat.parse(reader).iterator();
> {code}
> The invalid char is the contained SOH and STX non printable characters at the
> end of line.
> I debugged through the source of this and ran into the Exception in the Lexer
> not handling these special characters
> Unfortunately I'm not able to provide some hints on fixing this as I'm not
> familiar with these type of characters and what behaviour they should have.
> Sincerely
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CSV-222) invalid char between encapsulated token and delimiter
[
https://issues.apache.org/jira/browse/CSV-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425794#comment-16425794
]
Patrick Gäckle commented on CSV-222:
Sorry I don't know what PR means.
> invalid char between encapsulated token and delimiter
> -
>
> Key: CSV-222
> URL: https://issues.apache.org/jira/browse/CSV-222
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.4
>Reporter: Patrick Gäckle
>Priority: Major
> Attachments: faulty.csv, faulty2.csv
>
>
> When trying to read the file [^faulty.csv] and parse it I get the following
> error:
> {code}
> java.io.IOException: (line 1) invalid char between encapsulated token and
> delimiter
> at org.apache.commons.csv.Lexer.parseEncapsulatedToken(Lexer.java:275)
> at org.apache.commons.csv.Lexer.nextToken(Lexer.java:152)
> at org.apache.commons.csv.CSVParser.nextRecord(CSVParser.java:500)
> at org.apache.commons.csv.CSVParser.initializeHeader(CSVParser.java:389)
> at org.apache.commons.csv.CSVParser.(CSVParser.java:284)
> at org.apache.commons.csv.CSVParser.(CSVParser.java:252)
> at org.apache.commons.csv.CSVFormat.parse(CSVFormat.java:846)
> {code}
> The line of code is the parsing part returning the iterator of it:
> {code:java}
> csvFormat =
> CSVFormat.DEFAULT.withHeader().withDelimiter(';').withIgnoreHeaderCase();
> iterator = csvFormat.parse(reader).iterator();
> {code}
> The invalid char is the contained SOH and STX non printable characters at the
> end of line.
> I debugged through the source of this and ran into the Exception in the Lexer
> not handling these special characters
> Unfortunately I'm not able to provide some hints on fixing this as I'm not
> familiar with these type of characters and what behaviour they should have.
> Sincerely
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CSV-222) invalid char between encapsulated token and delimiter
[
https://issues.apache.org/jira/browse/CSV-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425725#comment-16425725
]
Gary Gregory commented on CSV-222:
--
In faulty2.csv, you have SOH+STX between headers and in record separators.
As of now, you need to filters these characters before they get to Commons CSV.
We would need a new features that completely ignores a given set of characters
between tokens.
Do you want to provide a PR for that?
> invalid char between encapsulated token and delimiter
> -
>
> Key: CSV-222
> URL: https://issues.apache.org/jira/browse/CSV-222
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.4
>Reporter: Patrick Gäckle
>Priority: Major
> Attachments: faulty.csv, faulty2.csv
>
>
> When trying to read the file [^faulty.csv] and parse it I get the following
> error:
> {code}
> java.io.IOException: (line 1) invalid char between encapsulated token and
> delimiter
> at org.apache.commons.csv.Lexer.parseEncapsulatedToken(Lexer.java:275)
> at org.apache.commons.csv.Lexer.nextToken(Lexer.java:152)
> at org.apache.commons.csv.CSVParser.nextRecord(CSVParser.java:500)
> at org.apache.commons.csv.CSVParser.initializeHeader(CSVParser.java:389)
> at org.apache.commons.csv.CSVParser.(CSVParser.java:284)
> at org.apache.commons.csv.CSVParser.(CSVParser.java:252)
> at org.apache.commons.csv.CSVFormat.parse(CSVFormat.java:846)
> {code}
> The line of code is the parsing part returning the iterator of it:
> {code:java}
> csvFormat =
> CSVFormat.DEFAULT.withHeader().withDelimiter(';').withIgnoreHeaderCase();
> iterator = csvFormat.parse(reader).iterator();
> {code}
> The invalid char is the contained SOH and STX non printable characters at the
> end of line.
> I debugged through the source of this and ran into the Exception in the Lexer
> not handling these special characters
> Unfortunately I'm not able to provide some hints on fixing this as I'm not
> familiar with these type of characters and what behaviour they should have.
> Sincerely
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CSV-222) invalid char between encapsulated token and delimiter
[
https://issues.apache.org/jira/browse/CSV-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425645#comment-16425645
]
Patrick Gäckle commented on CSV-222:
You slightly missunderstood me or I was not precise enough.
I attached [^faulty2.csv] where you can see in header row there is also an SOH
and STX in column1 before the columns separator.
This is currently no problem but it is for the last column in a row.
Hope I could decribe this a bit better now.
> invalid char between encapsulated token and delimiter
> -
>
> Key: CSV-222
> URL: https://issues.apache.org/jira/browse/CSV-222
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.4
>Reporter: Patrick Gäckle
>Priority: Major
> Attachments: faulty.csv, faulty2.csv
>
>
> When trying to read the file [^faulty.csv] and parse it I get the following
> error:
> {code}
> java.io.IOException: (line 1) invalid char between encapsulated token and
> delimiter
> at org.apache.commons.csv.Lexer.parseEncapsulatedToken(Lexer.java:275)
> at org.apache.commons.csv.Lexer.nextToken(Lexer.java:152)
> at org.apache.commons.csv.CSVParser.nextRecord(CSVParser.java:500)
> at org.apache.commons.csv.CSVParser.initializeHeader(CSVParser.java:389)
> at org.apache.commons.csv.CSVParser.(CSVParser.java:284)
> at org.apache.commons.csv.CSVParser.(CSVParser.java:252)
> at org.apache.commons.csv.CSVFormat.parse(CSVFormat.java:846)
> {code}
> The line of code is the parsing part returning the iterator of it:
> {code:java}
> csvFormat =
> CSVFormat.DEFAULT.withHeader().withDelimiter(';').withIgnoreHeaderCase();
> iterator = csvFormat.parse(reader).iterator();
> {code}
> The invalid char is the contained SOH and STX non printable characters at the
> end of line.
> I debugged through the source of this and ran into the Exception in the Lexer
> not handling these special characters
> Unfortunately I'm not able to provide some hints on fixing this as I'm not
> familiar with these type of characters and what behaviour they should have.
> Sincerely
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CSV-222) invalid char between encapsulated token and delimiter
[
https://issues.apache.org/jira/browse/CSV-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Gäckle updated CSV-222:
---
Attachment: faulty2.csv
> invalid char between encapsulated token and delimiter
> -
>
> Key: CSV-222
> URL: https://issues.apache.org/jira/browse/CSV-222
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.4
>Reporter: Patrick Gäckle
>Priority: Major
> Attachments: faulty.csv, faulty2.csv
>
>
> When trying to read the file [^faulty.csv] and parse it I get the following
> error:
> {code}
> java.io.IOException: (line 1) invalid char between encapsulated token and
> delimiter
> at org.apache.commons.csv.Lexer.parseEncapsulatedToken(Lexer.java:275)
> at org.apache.commons.csv.Lexer.nextToken(Lexer.java:152)
> at org.apache.commons.csv.CSVParser.nextRecord(CSVParser.java:500)
> at org.apache.commons.csv.CSVParser.initializeHeader(CSVParser.java:389)
> at org.apache.commons.csv.CSVParser.(CSVParser.java:284)
> at org.apache.commons.csv.CSVParser.(CSVParser.java:252)
> at org.apache.commons.csv.CSVFormat.parse(CSVFormat.java:846)
> {code}
> The line of code is the parsing part returning the iterator of it:
> {code:java}
> csvFormat =
> CSVFormat.DEFAULT.withHeader().withDelimiter(';').withIgnoreHeaderCase();
> iterator = csvFormat.parse(reader).iterator();
> {code}
> The invalid char is the contained SOH and STX non printable characters at the
> end of line.
> I debugged through the source of this and ran into the Exception in the Lexer
> not handling these special characters
> Unfortunately I'm not able to provide some hints on fixing this as I'm not
> familiar with these type of characters and what behaviour they should have.
> Sincerely
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CSV-222) invalid char between encapsulated token and delimiter
[
https://issues.apache.org/jira/browse/CSV-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425629#comment-16425629
]
Gary Gregory commented on CSV-222:
--
The issue you initially described talked about special characters in the record
separator, not the column delimiter.
The column delimiter is currently limited to a single character. There is a
separate ticket to enhance the column delimiter to a String instead of a char.
> invalid char between encapsulated token and delimiter
> -
>
> Key: CSV-222
> URL: https://issues.apache.org/jira/browse/CSV-222
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.4
>Reporter: Patrick Gäckle
>Priority: Major
> Attachments: faulty.csv
>
>
> When trying to read the file [^faulty.csv] and parse it I get the following
> error:
> {code}
> java.io.IOException: (line 1) invalid char between encapsulated token and
> delimiter
> at org.apache.commons.csv.Lexer.parseEncapsulatedToken(Lexer.java:275)
> at org.apache.commons.csv.Lexer.nextToken(Lexer.java:152)
> at org.apache.commons.csv.CSVParser.nextRecord(CSVParser.java:500)
> at org.apache.commons.csv.CSVParser.initializeHeader(CSVParser.java:389)
> at org.apache.commons.csv.CSVParser.(CSVParser.java:284)
> at org.apache.commons.csv.CSVParser.(CSVParser.java:252)
> at org.apache.commons.csv.CSVFormat.parse(CSVFormat.java:846)
> {code}
> The line of code is the parsing part returning the iterator of it:
> {code:java}
> csvFormat =
> CSVFormat.DEFAULT.withHeader().withDelimiter(';').withIgnoreHeaderCase();
> iterator = csvFormat.parse(reader).iterator();
> {code}
> The invalid char is the contained SOH and STX non printable characters at the
> end of line.
> I debugged through the source of this and ran into the Exception in the Lexer
> not handling these special characters
> Unfortunately I'm not able to provide some hints on fixing this as I'm not
> familiar with these type of characters and what behaviour they should have.
> Sincerely
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (CSV-223) Inconsistency between Javadoc of CSVFormat DEFAULT EXCEL
[
https://issues.apache.org/jira/browse/CSV-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Samuel Martin closed CSV-223.
-
> Inconsistency between Javadoc of CSVFormat DEFAULT EXCEL
> -
>
> Key: CSV-223
> URL: https://issues.apache.org/jira/browse/CSV-223
> Project: Commons CSV
> Issue Type: Bug
> Components: Documentation
>Reporter: Samuel Martin
>Assignee: Gary Gregory
>Priority: Minor
> Fix For: 1.6
>
>
> According to the [Javadoc of
> CSVFormat|https://commons.apache.org/proper/commons-csv/archives/1.5/apidocs/index.html]
>
> * {{CSVFormat.DEFAULT}} includes among its settings
> {{withIgnoreEmptyLines(true)}}
> * {{CSVFormat.EXCEL}} includes among its settings
> {{withIgnoreEmptyLines(false)}}
> * Then, the same documentation of {{CSVFormat.EXCEL}} reads that
> {quote}Note: this is currently like RFC4180 plus
> withAllowMissingColumnNames(true).{quote}
> One of these three must be wrong (both ignore empty lines, or neither ignores
> empty lines, or there is another difference that needs to be mentioned).
> Edit: after checking the source code, I conclude that the latest sentence is
> incomplete, and should also mention {{withIgnoreEmptyLines(false)}} as a
> difference with {{DEFAULT}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TEXT-119) StringEscapeUtils dropped SQL support but it is not clear if this is intentional or not
[ https://issues.apache.org/jira/browse/TEXT-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425354#comment-16425354 ] Pascal Schumacher commented on TEXT-119: Thanks for reporting! As far as I know neither commons-lang3 nor commons-text never supported SQL escaping. Commons-lang 2.x supported SQL escaping, but this was dropped in 3.0, see https://commons.apache.org/proper/commons-lang/article3_0.html for details. I'm not aware of any other Java ASF project is providing this functionally, but there are a lot of projects so I may miss something. I have removed the mention of SQL escaping from the commons-text userguide. > StringEscapeUtils dropped SQL support but it is not clear if this is > intentional or not > --- > > Key: TEXT-119 > URL: https://issues.apache.org/jira/browse/TEXT-119 > Project: Commons Text > Issue Type: Bug >Affects Versions: 1.2 >Reporter: Scott Markwell >Priority: Major > Labels: docuentation, roadmap > Fix For: 1.4 > > > The Commons Text user guide indicates StringEscapeUtils supposed SQL as an > escape > [http://commons.apache.org/proper/commons-text/userguide.html] > Commons Lang3 indicates the functionality of > org.apache.commons.lang3.StringEscapeUtils was moved to Commons Text (which > does include SQL escape) and deprecates it's own implementation. > [http://commons.apache.org/proper/commons-text/changes-report.html] Provides > no insight on the lack of SQL support > > I'm not sure the correct path forward, as project intentions aren't clear. > If the project has no intention of supporting SQL, the user-guide should be > updated and notes about migrating from commons-lang3 should note that stance. > Additionally if another Java ASF project is providing that functionality it > should be indicated. If this is an oversight on inclusion in the Commons > Text project, then I guess this is a missing feature request. > Thanks for all the great work > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (TEXT-119) StringEscapeUtils dropped SQL support but it is not clear if this is intentional or not
[ https://issues.apache.org/jira/browse/TEXT-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher resolved TEXT-119. Resolution: Fixed Assignee: Pascal Schumacher Fix Version/s: 1.4 > StringEscapeUtils dropped SQL support but it is not clear if this is > intentional or not > --- > > Key: TEXT-119 > URL: https://issues.apache.org/jira/browse/TEXT-119 > Project: Commons Text > Issue Type: Bug >Affects Versions: 1.2 >Reporter: Scott Markwell >Assignee: Pascal Schumacher >Priority: Major > Labels: docuentation, roadmap > Fix For: 1.4 > > > The Commons Text user guide indicates StringEscapeUtils supposed SQL as an > escape > [http://commons.apache.org/proper/commons-text/userguide.html] > Commons Lang3 indicates the functionality of > org.apache.commons.lang3.StringEscapeUtils was moved to Commons Text (which > does include SQL escape) and deprecates it's own implementation. > [http://commons.apache.org/proper/commons-text/changes-report.html] Provides > no insight on the lack of SQL support > > I'm not sure the correct path forward, as project intentions aren't clear. > If the project has no intention of supporting SQL, the user-guide should be > updated and notes about migrating from commons-lang3 should note that stance. > Additionally if another Java ASF project is providing that functionality it > should be indicated. If this is an oversight on inclusion in the Commons > Text project, then I guess this is a missing feature request. > Thanks for all the great work > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CSV-222) invalid char between encapsulated token and delimiter
[
https://issues.apache.org/jira/browse/CSV-222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425139#comment-16425139
]
Patrick Gäckle commented on CSV-222:
Thanks [~garydgregory]. Haven't thought of this solution.
Anyways I still thinnk it is a bug as when placing these characters in betweens
column 1 and column 2 nothing happens. Only when it is the last character read
as possible "line end".
For myself the solution of this is using a FilterReader that throws away all
non printable characters as it happend to have a lot more in this file I need
to process.
Thanks
> invalid char between encapsulated token and delimiter
> -
>
> Key: CSV-222
> URL: https://issues.apache.org/jira/browse/CSV-222
> Project: Commons CSV
> Issue Type: Bug
> Components: Parser
>Affects Versions: 1.4
>Reporter: Patrick Gäckle
>Priority: Major
> Attachments: faulty.csv
>
>
> When trying to read the file [^faulty.csv] and parse it I get the following
> error:
> {code}
> java.io.IOException: (line 1) invalid char between encapsulated token and
> delimiter
> at org.apache.commons.csv.Lexer.parseEncapsulatedToken(Lexer.java:275)
> at org.apache.commons.csv.Lexer.nextToken(Lexer.java:152)
> at org.apache.commons.csv.CSVParser.nextRecord(CSVParser.java:500)
> at org.apache.commons.csv.CSVParser.initializeHeader(CSVParser.java:389)
> at org.apache.commons.csv.CSVParser.(CSVParser.java:284)
> at org.apache.commons.csv.CSVParser.(CSVParser.java:252)
> at org.apache.commons.csv.CSVFormat.parse(CSVFormat.java:846)
> {code}
> The line of code is the parsing part returning the iterator of it:
> {code:java}
> csvFormat =
> CSVFormat.DEFAULT.withHeader().withDelimiter(';').withIgnoreHeaderCase();
> iterator = csvFormat.parse(reader).iterator();
> {code}
> The invalid char is the contained SOH and STX non printable characters at the
> end of line.
> I debugged through the source of this and ran into the Exception in the Lexer
> not handling these special characters
> Unfortunately I'm not able to provide some hints on fixing this as I'm not
> familiar with these type of characters and what behaviour they should have.
> Sincerely
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] commons-lang pull request #321: SerializationUtilsTest cleanup
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/321 ---
[GitHub] commons-lang issue #321: SerializationUtilsTest cleanup
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/321 Thanks! ð ---
[jira] [Closed] (VFS-657) FileSelector implementations like FileDepthSelector should throw Exception
[
https://issues.apache.org/jira/browse/VFS-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Elias Putz closed VFS-657.
--
> FileSelector implementations like FileDepthSelector should throw Exception
> --
>
> Key: VFS-657
> URL: https://issues.apache.org/jira/browse/VFS-657
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Elias Putz
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 2.2.1
>
>
> {{org.apache.commons.vfs2.FileDepthSelector}} should throw an {{Exception}}
> as stated in the interface {{org.apache.commons.vfs2.FileSelector}},
> otherwise if you try to extend it the child class cannot throw an exception.
> I tried to create a class combining the functionality of the
> {{FileDepthSelector}} and {{FileTypeSelector}} but couldn't because checking
> the file type throws an exception.
> Another issue: Why is the depth of {{FileFilterSelector}} hard coded?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-657) FileSelector implementations like FileDepthSelector should throw Exception
[
https://issues.apache.org/jira/browse/VFS-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425128#comment-16425128
]
Elias Putz commented on VFS-657:
I could close the PR and will close this issue as well, thanks!
> FileSelector implementations like FileDepthSelector should throw Exception
> --
>
> Key: VFS-657
> URL: https://issues.apache.org/jira/browse/VFS-657
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Elias Putz
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 2.2.1
>
>
> {{org.apache.commons.vfs2.FileDepthSelector}} should throw an {{Exception}}
> as stated in the interface {{org.apache.commons.vfs2.FileSelector}},
> otherwise if you try to extend it the child class cannot throw an exception.
> I tried to create a class combining the functionality of the
> {{FileDepthSelector}} and {{FileTypeSelector}} but couldn't because checking
> the file type throws an exception.
> Another issue: Why is the depth of {{FileFilterSelector}} hard coded?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
