[jira] [Commented] (LANG-1003) DurationFormatUtils are not able to handle negative durations/periods
[
https://issues.apache.org/jira/browse/LANG-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13988945#comment-13988945
]
Benedikt Ritter commented on LANG-1003:
---
Nice catch. Fixed in revision 1592324.
DurationFormatUtils are not able to handle negative durations/periods
-
Key: LANG-1003
URL: https://issues.apache.org/jira/browse/LANG-1003
Project: Commons Lang
Issue Type: Bug
Components: lang.text.*
Affects Versions: 3.3.2
Reporter: Michael Osipov
Assignee: Benedikt Ritter
Priority: Critical
Fix For: 3.4
It spits out complete garbage.
{code}
System.out.println(DurationFormatUtils.formatDurationHMS(-3454));
System.out.println(DurationFormatUtils.formatPeriodISO(4000, 3000));
{code}
{noformat}
0:00:-3.-454
P-1Y11M30DT23H59M59.000S
{noformat}
It should throw an {{IllegalArgumentException}} if duration is 0 or period
diff is 0.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (LANG-1003) DurationFormatUtils are not able to handle negative durations/periods
[
https://issues.apache.org/jira/browse/LANG-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter resolved LANG-1003.
---
Resolution: Fixed
DurationFormatUtils are not able to handle negative durations/periods
-
Key: LANG-1003
URL: https://issues.apache.org/jira/browse/LANG-1003
Project: Commons Lang
Issue Type: Bug
Components: lang.text.*
Affects Versions: 3.3.2
Reporter: Michael Osipov
Assignee: Benedikt Ritter
Priority: Critical
Fix For: 3.4
It spits out complete garbage.
{code}
System.out.println(DurationFormatUtils.formatDurationHMS(-3454));
System.out.println(DurationFormatUtils.formatPeriodISO(4000, 3000));
{code}
{noformat}
0:00:-3.-454
P-1Y11M30DT23H59M59.000S
{noformat}
It should throw an {{IllegalArgumentException}} if duration is 0 or period
diff is 0.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (LANG-1004) DurationFormatUtils#formatDurationHMS implementation does not correspond to Javadoc and vice versa
[
https://issues.apache.org/jira/browse/LANG-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13988950#comment-13988950
]
Benedikt Ritter commented on LANG-1004:
---
Hello Michael,
After applying your patch I get two test failures:
{code}
Failed tests:
StopWatchTest.testStopWatchSimpleGet:55 expected:0[]:00:00.000 but
was:0[0]:00:00.000
StopWatchTest.testStopWatchSplit:76 Formatted split string not the correct
length expected:12 but was:11
{code}
Those two test cases fail because StopWatch uses DurationFormatUtils
internally. You will have to update the tests as well ;)
TIA!
Benedikt
DurationFormatUtils#formatDurationHMS implementation does not correspond to
Javadoc and vice versa
--
Key: LANG-1004
URL: https://issues.apache.org/jira/browse/LANG-1004
Project: Commons Lang
Issue Type: Bug
Components: lang.text.*
Affects Versions: 3.3.2
Reporter: Michael Osipov
Fix For: Patch Needed
Attachments: LANG-1004.patch, LANG-1004_v2.patch
This method has several flaws:
1. Javadoc says: The format used is ISO8601-like: H:m:s.S. but the method
call supplies H:mm:ss.SSS
2. ISO time never omits leading zeros, so the proper pattern must be
HH:mm:ss.SSS
3. The method name says: HMS but includes the second fraction.
Since the use of fractions is optional, the method should use HH:mm:ss and
update the Javadoc as well.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (LANG-1004) DurationFormatUtils#formatDurationHMS implementation does not correspond to Javadoc and vice versa
[ https://issues.apache.org/jira/browse/LANG-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Osipov updated LANG-1004: - Attachment: (was: LANG-1004_v2.patch) DurationFormatUtils#formatDurationHMS implementation does not correspond to Javadoc and vice versa -- Key: LANG-1004 URL: https://issues.apache.org/jira/browse/LANG-1004 Project: Commons Lang Issue Type: Bug Components: lang.text.* Affects Versions: 3.3.2 Reporter: Michael Osipov Fix For: Patch Needed This method has several flaws: 1. Javadoc says: The format used is ISO8601-like: H:m:s.S. but the method call supplies H:mm:ss.SSS 2. ISO time never omits leading zeros, so the proper pattern must be HH:mm:ss.SSS 3. The method name says: HMS but includes the second fraction. Since the use of fractions is optional, the method should use HH:mm:ss and update the Javadoc as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (JCS-123) Memory Cache with no disk auxiliary: map size doesn't change after initial puts
Richard Eigenmann created JCS-123: - Summary: Memory Cache with no disk auxiliary: map size doesn't change after initial puts Key: JCS-123 URL: https://issues.apache.org/jira/browse/JCS-123 Project: Commons JCS Issue Type: Question Components: Composite Cache Affects Versions: jcs-2.0.0 Environment: Testing Reporter: Richard Eigenmann Priority: Minor Fix For: jcs-2.0.0 Curious how JCS handles different memory footprints under varying loads and configurations I built a trivial JFrame that allows me to load a specific number of objects into the cache and then randomly gets them on a timer every few hundred milliseconds. I print out the cache statistics (.getStats()) periodically. I observed if I add 10 objects to the cache through a for loop, the map size jumps from 0 to 10 and stabilises there (cache.ccf allows 1000). The 10 objects are in the cache and the timer thread gets them just fine when it asks for them. If I add another 10 objects these 10 objects do not get added to the cache and are not available for the timer thread to get them whilst the first 10 are good. If I start with say 1000 objects, the map size initialises at 1000 (assuming the ccf config allows 1000 objects). These 1000 initialise and stay and any additional ones don't. It looks like whatever number of objects come in first in rapid succession sets the size of the memory-only cache. Is this expected behaviour? I tried the other memory cache types too and seem to get the same reaction. Would this be different if I had a disk auxiliary? (I am caching jpg files from disk so loading them to a cache and writing them to disk auxiliary makes no real sense.) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (JCS-125) Make a jar with the 2.0 code available for download
Richard Eigenmann created JCS-125: - Summary: Make a jar with the 2.0 code available for download Key: JCS-125 URL: https://issues.apache.org/jira/browse/JCS-125 Project: Commons JCS Issue Type: Wish Components: Composite Cache Affects Versions: jcs-2.0.0 Environment: Testing Reporter: Richard Eigenmann Fix For: jcs-2.0.0 For those desiring to try out the 2.0 version it would be very helpful to have the 2.0 jars available for download under the download link on the JCS page. For the 1.3 users it would also be helpful to link to the repo where the concurrent jar can be downloaded. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (MATH-982) Improvements to the User Guide
[ https://issues.apache.org/jira/browse/MATH-982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Phil Steitz reopened MATH-982: -- Improvements to the User Guide -- Key: MATH-982 URL: https://issues.apache.org/jira/browse/MATH-982 Project: Commons Math Issue Type: Improvement Reporter: Thomas Neidhart -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (LANG-1004) DurationFormatUtils#formatDurationHMS implementation does not correspond to Javadoc and vice versa
[
https://issues.apache.org/jira/browse/LANG-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13989015#comment-13989015
]
Benedikt Ritter commented on LANG-1004:
---
{code}
bene@localhost:~/workspace/apache/commons/lang$ svn ci -m LANG-1004:
DurationFormatUtils#formatDurationHMS implementation does not correspond to
Javadoc and vice versa. Thanks to Michael Osipov
Sendingsrc/changes/changes.xml
Sending
src/main/java/org/apache/commons/lang3/time/DurationFormatUtils.java
Sending
src/test/java/org/apache/commons/lang3/time/DurationFormatUtilsTest.java
Sendingsrc/test/java/org/apache/commons/lang3/time/StopWatchTest.java
Transmitting file data
Committed revision 1592360.
{code}
Thanks for contributing!
DurationFormatUtils#formatDurationHMS implementation does not correspond to
Javadoc and vice versa
--
Key: LANG-1004
URL: https://issues.apache.org/jira/browse/LANG-1004
Project: Commons Lang
Issue Type: Bug
Components: lang.text.*
Affects Versions: 3.3.2
Reporter: Michael Osipov
Assignee: Benedikt Ritter
Fix For: 3.4
Attachments: LANG-1004.patch
This method has several flaws:
1. Javadoc says: The format used is ISO8601-like: H:m:s.S. but the method
call supplies H:mm:ss.SSS
2. ISO time never omits leading zeros, so the proper pattern must be
HH:mm:ss.SSS
3. The method name says: HMS but includes the second fraction.
Since the use of fractions is optional, the method should use HH:mm:ss and
update the Javadoc as well.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (LANG-1004) DurationFormatUtils#formatDurationHMS implementation does not correspond to Javadoc and vice versa
[ https://issues.apache.org/jira/browse/LANG-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated LANG-1004: -- Fix Version/s: (was: Patch Needed) 3.4 DurationFormatUtils#formatDurationHMS implementation does not correspond to Javadoc and vice versa -- Key: LANG-1004 URL: https://issues.apache.org/jira/browse/LANG-1004 Project: Commons Lang Issue Type: Bug Components: lang.text.* Affects Versions: 3.3.2 Reporter: Michael Osipov Assignee: Benedikt Ritter Fix For: 3.4 Attachments: LANG-1004.patch This method has several flaws: 1. Javadoc says: The format used is ISO8601-like: H:m:s.S. but the method call supplies H:mm:ss.SSS 2. ISO time never omits leading zeros, so the proper pattern must be HH:mm:ss.SSS 3. The method name says: HMS but includes the second fraction. Since the use of fractions is optional, the method should use HH:mm:ss and update the Javadoc as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CSV-110) Add ability to parse single lines
[
https://issues.apache.org/jira/browse/CSV-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated CSV-110:
Fix Version/s: 1.x
Add ability to parse single lines
-
Key: CSV-110
URL: https://issues.apache.org/jira/browse/CSV-110
Project: Commons CSV
Issue Type: New Feature
Reporter: Gabriel Reid
Fix For: 1.x
Attachments: CSV-110.patch
Due to the iterator-based API of CSVParser, there is currently no simple and
convenient way to parse single lines of CSV-formatted data. The intention of
this ticket is to add something along the lines of the following:
{code}
CSVLineParser lineParser = new CSVLineParser(csvFormat);
String singleLine = a,b,c;
CSVRecord singleRecord lineParser.parseLine(singleLine);
{code}
The use case of parsing single lines comes up very often in terms of
distributed batch processing scenarios (i.e. Hadoop jobs), and CSV-style
formats are also regularly used in such scenarios. Currently, projects are
often forced to build their own ad-hoc CSV parsing solutions, so adding the
ability to parse single lines to commons-csv would be very useful to these
projects, as well as anyone doing parsing based on input that isn't necessary
in the form of a single stream.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CSV-102) Commons CSV does not properly handle record separators
[ https://issues.apache.org/jira/browse/CSV-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benedikt Ritter updated CSV-102: Fix Version/s: 1.x Commons CSV does not properly handle record separators -- Key: CSV-102 URL: https://issues.apache.org/jira/browse/CSV-102 Project: Commons CSV Issue Type: Bug Affects Versions: 1.x Environment: ALL Reporter: Oliver Oyston Priority: Minor Fix For: 1.x Attachments: Changes.patch, nonstandard.patch Any specified record separator appear to be ignored and the code just assumes that standard line endings are the record delimiters. I have a patch to partly address the problems that 'falls back' to the current behavior. The patch only allow a maximum of a one character record separator. The approach needs verifying and also needs improving to be more generic. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CSV-112) HeaderMap inconsistent when duplicate columns names
[
https://issues.apache.org/jira/browse/CSV-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13989018#comment-13989018
]
Benedikt Ritter commented on CSV-112:
-
The problem is, that we provide a key based access to the values of a
{{CSVRecord}} using the {{get(String)}} method. How should that method behave
if there are duplicate column names?
HeaderMap inconsistent when duplicate columns names
---
Key: CSV-112
URL: https://issues.apache.org/jira/browse/CSV-112
Project: Commons CSV
Issue Type: Bug
Components: Parser
Affects Versions: 1.0
Reporter: Romain Gossé
Labels: headers, parsing
Given a parser format for csv files with a header line:
{code}
CSVFormat myFormat =
CSVFormat.RFC4180.withDelimiter(,).withQuoteChar('').withQuotePolicy(Quote.MINIMAL)
.withIgnoreSurroundingSpaces(true).withHeader().withSkipHeaderRecord(true);
{code}
And given a file with duplicate header names:
Col1,Col2,Col2,Col3,Col4
1,2,3,4,5
4,5,6,7,8
The HeaderMap returned by the parser misses an entry because of the Column
name being used as a key, leading to wrong behavior when we rely on it.
If this is not supposed to happen in the file regarding the CSV format, at
least this should raise an error. If not we should come up with a more clever
way to store and access the headers.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (CSV-112) HeaderMap inconsistent when duplicate columns names
[
https://issues.apache.org/jira/browse/CSV-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13989018#comment-13989018
]
Benedikt Ritter edited comment on CSV-112 at 5/4/14 3:53 PM:
-
The problem is, that we provide a key based access to the values of a
{{CSVRecord}} using the {{get(String)}} method. How should that method behave
if there are duplicate column names?
Throwing an exception seems reasonable here.
was (Author: britter):
The problem is, that we provide a key based access to the values of a
{{CSVRecord}} using the {{get(String)}} method. How should that method behave
if there are duplicate column names?
HeaderMap inconsistent when duplicate columns names
---
Key: CSV-112
URL: https://issues.apache.org/jira/browse/CSV-112
Project: Commons CSV
Issue Type: Bug
Components: Parser
Affects Versions: 1.0
Reporter: Romain Gossé
Labels: headers, parsing
Fix For: 1.0
Given a parser format for csv files with a header line:
{code}
CSVFormat myFormat =
CSVFormat.RFC4180.withDelimiter(,).withQuoteChar('').withQuotePolicy(Quote.MINIMAL)
.withIgnoreSurroundingSpaces(true).withHeader().withSkipHeaderRecord(true);
{code}
And given a file with duplicate header names:
Col1,Col2,Col2,Col3,Col4
1,2,3,4,5
4,5,6,7,8
The HeaderMap returned by the parser misses an entry because of the Column
name being used as a key, leading to wrong behavior when we rely on it.
If this is not supposed to happen in the file regarding the CSV format, at
least this should raise an error. If not we should come up with a more clever
way to store and access the headers.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CSV-112) HeaderMap inconsistent when duplicate columns names
[
https://issues.apache.org/jira/browse/CSV-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated CSV-112:
Fix Version/s: 1.0
HeaderMap inconsistent when duplicate columns names
---
Key: CSV-112
URL: https://issues.apache.org/jira/browse/CSV-112
Project: Commons CSV
Issue Type: Bug
Components: Parser
Affects Versions: 1.0
Reporter: Romain Gossé
Assignee: Benedikt Ritter
Labels: headers, parsing
Fix For: 1.0
Given a parser format for csv files with a header line:
{code}
CSVFormat myFormat =
CSVFormat.RFC4180.withDelimiter(,).withQuoteChar('').withQuotePolicy(Quote.MINIMAL)
.withIgnoreSurroundingSpaces(true).withHeader().withSkipHeaderRecord(true);
{code}
And given a file with duplicate header names:
Col1,Col2,Col2,Col3,Col4
1,2,3,4,5
4,5,6,7,8
The HeaderMap returned by the parser misses an entry because of the Column
name being used as a key, leading to wrong behavior when we rely on it.
If this is not supposed to happen in the file regarding the CSV format, at
least this should raise an error. If not we should come up with a more clever
way to store and access the headers.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CSV-112) HeaderMap inconsistent when duplicate columns names
[
https://issues.apache.org/jira/browse/CSV-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13989033#comment-13989033
]
Romain Gossé commented on CSV-112:
--
I guess handling this would imply too many changes in the API.
HeaderMap inconsistent when duplicate columns names
---
Key: CSV-112
URL: https://issues.apache.org/jira/browse/CSV-112
Project: Commons CSV
Issue Type: Bug
Components: Parser
Affects Versions: 1.0
Reporter: Romain Gossé
Assignee: Benedikt Ritter
Labels: headers, parsing
Fix For: 1.0
Given a parser format for csv files with a header line:
{code}
CSVFormat myFormat =
CSVFormat.RFC4180.withDelimiter(,).withQuoteChar('').withQuotePolicy(Quote.MINIMAL)
.withIgnoreSurroundingSpaces(true).withHeader().withSkipHeaderRecord(true);
{code}
And given a file with duplicate header names:
Col1,Col2,Col2,Col3,Col4
1,2,3,4,5
4,5,6,7,8
The HeaderMap returned by the parser misses an entry because of the Column
name being used as a key, leading to wrong behavior when we rely on it.
If this is not supposed to happen in the file regarding the CSV format, at
least this should raise an error. If not we should come up with a more clever
way to store and access the headers.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CSV-112) HeaderMap is inconsistent it is parsed from an input with duplicate columns names
[
https://issues.apache.org/jira/browse/CSV-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated CSV-112:
Summary: HeaderMap is inconsistent it is parsed from an input with
duplicate columns names (was: HeaderMap inconsistent when duplicate columns
names)
HeaderMap is inconsistent it is parsed from an input with duplicate columns
names
-
Key: CSV-112
URL: https://issues.apache.org/jira/browse/CSV-112
Project: Commons CSV
Issue Type: Bug
Components: Parser
Affects Versions: 1.0
Reporter: Romain Gossé
Assignee: Benedikt Ritter
Labels: headers, parsing
Fix For: 1.0
Given a parser format for csv files with a header line:
{code}
CSVFormat myFormat =
CSVFormat.RFC4180.withDelimiter(,).withQuoteChar('').withQuotePolicy(Quote.MINIMAL)
.withIgnoreSurroundingSpaces(true).withHeader().withSkipHeaderRecord(true);
{code}
And given a file with duplicate header names:
Col1,Col2,Col2,Col3,Col4
1,2,3,4,5
4,5,6,7,8
The HeaderMap returned by the parser misses an entry because of the Column
name being used as a key, leading to wrong behavior when we rely on it.
If this is not supposed to happen in the file regarding the CSV format, at
least this should raise an error. If not we should come up with a more clever
way to store and access the headers.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CSV-112) HeaderMap is inconsistent when it is parsed from an input with duplicate columns names
[
https://issues.apache.org/jira/browse/CSV-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter updated CSV-112:
Summary: HeaderMap is inconsistent when it is parsed from an input with
duplicate columns names (was: HeaderMap is inconsistent it is parsed from an
input with duplicate columns names)
HeaderMap is inconsistent when it is parsed from an input with duplicate
columns names
--
Key: CSV-112
URL: https://issues.apache.org/jira/browse/CSV-112
Project: Commons CSV
Issue Type: Bug
Components: Parser
Affects Versions: 1.0
Reporter: Romain Gossé
Assignee: Benedikt Ritter
Labels: headers, parsing
Fix For: 1.0
Given a parser format for csv files with a header line:
{code}
CSVFormat myFormat =
CSVFormat.RFC4180.withDelimiter(,).withQuoteChar('').withQuotePolicy(Quote.MINIMAL)
.withIgnoreSurroundingSpaces(true).withHeader().withSkipHeaderRecord(true);
{code}
And given a file with duplicate header names:
Col1,Col2,Col2,Col3,Col4
1,2,3,4,5
4,5,6,7,8
The HeaderMap returned by the parser misses an entry because of the Column
name being used as a key, leading to wrong behavior when we rely on it.
If this is not supposed to happen in the file regarding the CSV format, at
least this should raise an error. If not we should come up with a more clever
way to store and access the headers.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CSV-112) HeaderMap is inconsistent when it is parsed from an input with duplicate columns names
[
https://issues.apache.org/jira/browse/CSV-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13989034#comment-13989034
]
Benedikt Ritter commented on CSV-112:
-
Fixed in revision 1592371. An IllegalStateException is now thrown when an
inconsistent header is parsed from the input.
HeaderMap is inconsistent when it is parsed from an input with duplicate
columns names
--
Key: CSV-112
URL: https://issues.apache.org/jira/browse/CSV-112
Project: Commons CSV
Issue Type: Bug
Components: Parser
Affects Versions: 1.0
Reporter: Romain Gossé
Assignee: Benedikt Ritter
Labels: headers, parsing
Fix For: 1.0
Given a parser format for csv files with a header line:
{code}
CSVFormat myFormat =
CSVFormat.RFC4180.withDelimiter(,).withQuoteChar('').withQuotePolicy(Quote.MINIMAL)
.withIgnoreSurroundingSpaces(true).withHeader().withSkipHeaderRecord(true);
{code}
And given a file with duplicate header names:
Col1,Col2,Col2,Col3,Col4
1,2,3,4,5
4,5,6,7,8
The HeaderMap returned by the parser misses an entry because of the Column
name being used as a key, leading to wrong behavior when we rely on it.
If this is not supposed to happen in the file regarding the CSV format, at
least this should raise an error. If not we should come up with a more clever
way to store and access the headers.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (CSV-112) HeaderMap is inconsistent when it is parsed from an input with duplicate columns names
[
https://issues.apache.org/jira/browse/CSV-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benedikt Ritter resolved CSV-112.
-
Resolution: Fixed
HeaderMap is inconsistent when it is parsed from an input with duplicate
columns names
--
Key: CSV-112
URL: https://issues.apache.org/jira/browse/CSV-112
Project: Commons CSV
Issue Type: Bug
Components: Parser
Affects Versions: 1.0
Reporter: Romain Gossé
Assignee: Benedikt Ritter
Labels: headers, parsing
Fix For: 1.0
Given a parser format for csv files with a header line:
{code}
CSVFormat myFormat =
CSVFormat.RFC4180.withDelimiter(,).withQuoteChar('').withQuotePolicy(Quote.MINIMAL)
.withIgnoreSurroundingSpaces(true).withHeader().withSkipHeaderRecord(true);
{code}
And given a file with duplicate header names:
Col1,Col2,Col2,Col3,Col4
1,2,3,4,5
4,5,6,7,8
The HeaderMap returned by the parser misses an entry because of the Column
name being used as a key, leading to wrong behavior when we rely on it.
If this is not supposed to happen in the file regarding the CSV format, at
least this should raise an error. If not we should come up with a more clever
way to store and access the headers.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (JCS-123) Memory Cache with no disk auxiliary: map size doesn't change after initial puts
[ https://issues.apache.org/jira/browse/JCS-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13989037#comment-13989037 ] Richard Eigenmann commented on JCS-123: --- Made this into a little standalone Swing app: https://github.com/richardeigenmann/JCSExperiment Perhaps this is helpful? Memory Cache with no disk auxiliary: map size doesn't change after initial puts --- Key: JCS-123 URL: https://issues.apache.org/jira/browse/JCS-123 Project: Commons JCS Issue Type: Question Components: Composite Cache Affects Versions: jcs-2.0.0 Environment: Testing Reporter: Richard Eigenmann Priority: Minor Fix For: jcs-2.0.0 Curious how JCS handles different memory footprints under varying loads and configurations I built a trivial JFrame that allows me to load a specific number of objects into the cache and then randomly gets them on a timer every few hundred milliseconds. I print out the cache statistics (.getStats()) periodically. I observed if I add 10 objects to the cache through a for loop, the map size jumps from 0 to 10 and stabilises there (cache.ccf allows 1000). The 10 objects are in the cache and the timer thread gets them just fine when it asks for them. If I add another 10 objects these 10 objects do not get added to the cache and are not available for the timer thread to get them whilst the first 10 are good. If I start with say 1000 objects, the map size initialises at 1000 (assuming the ccf config allows 1000 objects). These 1000 initialise and stay and any additional ones don't. It looks like whatever number of objects come in first in rapid succession sets the size of the memory-only cache. Is this expected behaviour? I tried the other memory cache types too and seem to get the same reaction. Would this be different if I had a disk auxiliary? (I am caching jpg files from disk so loading them to a cache and writing them to disk auxiliary makes no real sense.) -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (LANG-1004) DurationFormatUtils#formatDurationHMS implementation does not correspond to Javadoc and vice versa
[ https://issues.apache.org/jira/browse/LANG-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13989081#comment-13989081 ] Michael Osipov commented on LANG-1004: -- With pleasure, being a Commons Lang user for several years and an Apache Maven committer, that DurationFormatUtils#formatDurationHMS implementation does not correspond to Javadoc and vice versa -- Key: LANG-1004 URL: https://issues.apache.org/jira/browse/LANG-1004 Project: Commons Lang Issue Type: Bug Components: lang.text.* Affects Versions: 3.3.2 Reporter: Michael Osipov Assignee: Benedikt Ritter Fix For: 3.4 Attachments: LANG-1004.patch This method has several flaws: 1. Javadoc says: The format used is ISO8601-like: H:m:s.S. but the method call supplies H:mm:ss.SSS 2. ISO time never omits leading zeros, so the proper pattern must be HH:mm:ss.SSS 3. The method name says: HMS but includes the second fraction. Since the use of fractions is optional, the method should use HH:mm:ss and update the Javadoc as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (LANG-1004) DurationFormatUtils#formatDurationHMS implementation does not correspond to Javadoc and vice versa
[ https://issues.apache.org/jira/browse/LANG-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13989081#comment-13989081 ] Michael Osipov edited comment on LANG-1004 at 5/4/14 6:27 PM: -- With pleasure, being a Commons Lang user for several years and an Apache Maven committer, that's the least I can do. was (Author: michael-o): With pleasure, being a Commons Lang user for several years and an Apache Maven committer, that DurationFormatUtils#formatDurationHMS implementation does not correspond to Javadoc and vice versa -- Key: LANG-1004 URL: https://issues.apache.org/jira/browse/LANG-1004 Project: Commons Lang Issue Type: Bug Components: lang.text.* Affects Versions: 3.3.2 Reporter: Michael Osipov Assignee: Benedikt Ritter Fix For: 3.4 Attachments: LANG-1004.patch This method has several flaws: 1. Javadoc says: The format used is ISO8601-like: H:m:s.S. but the method call supplies H:mm:ss.SSS 2. ISO time never omits leading zeros, so the proper pattern must be HH:mm:ss.SSS 3. The method name says: HMS but includes the second fraction. Since the use of fractions is optional, the method should use HH:mm:ss and update the Javadoc as well. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (COMPRESS-280) [COMPRESS] Change TarInputStream Skip Behavior
[
https://issues.apache.org/jira/browse/COMPRESS-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13989084#comment-13989084
]
BELUGA BEHR commented on COMPRESS-280:
--
Well, you're assuming that the stream underneath TarInputStream does the right
thing. As I just proved with this patch, you can't always rely on the author
of a stream to always do the right thing ;-)
[COMPRESS] Change TarInputStream Skip Behavior
--
Key: COMPRESS-280
URL: https://issues.apache.org/jira/browse/COMPRESS-280
Project: Commons Compress
Issue Type: Improvement
Components: Archivers
Affects Versions: 1.8
Reporter: BELUGA BEHR
Priority: Minor
Fix For: 1.9
Attachments: TarArchiveInputStream.java.patch
InputStream#skip declares:
{quote}
Skips over and discards n bytes of data from this input stream. The skip
method may, for a variety of reasons, end up skipping over some smaller
number of bytes, possibly 0. This may result from any of a number of
conditions; reaching end of file before n bytes have been skipped is only one
possibility. The actual number of bytes skipped is returned. If n is
negative, no bytes are skipped.
{quote}
I would recommend doing away with the call to the local IOUtils in the
Stream's skip method and just call skip directly on the underlying stream.
I'd also amend the JavaDoc to say end up skipping .. some smaller number of
bytes... reaching the end of the current entry. The stream is not required
to make any best-effort. For your example, there should be a
BufferedInputStream between the TarInputStream and the CipherInputStream.
This would put it more in line with all other InputStreams.
If a client wants to skip an entry manually, they would have to call
Commons-IO IOUtils#skipFully, IOUtils#skip, etc.
You would then have to modify getNextTarEntry() to call the IOUtils#skip
method.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (LANG-1005) Extend DurationFormatUtils#formatDurationISO default pattern to match #formatDurationHMS
[
https://issues.apache.org/jira/browse/LANG-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Osipov updated LANG-1005:
-
Attachment: LANG-1005.patch
Simple patch.
Extend DurationFormatUtils#formatDurationISO default pattern to match
#formatDurationHMS
Key: LANG-1005
URL: https://issues.apache.org/jira/browse/LANG-1005
Project: Commons Lang
Issue Type: Improvement
Components: lang.text.*
Affects Versions: 3.3.2
Reporter: Michael Osipov
Attachments: LANG-1005.patch
Currently, {{formatDuration}} will specify {{HH:mm:ss.SSS}} but
{{formatDurationISO}} specifies {{'P''Y'M'M'd'DT'H'H'm'M's.S'S'}}. Both
should have a uniform definition, i.e., it should be
{{'P''Y'M'M'd'DT'H'H'm'M's.SSS'S'}}.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (JCS-120) cleanup mvn deps + add missing headers
[ https://issues.apache.org/jira/browse/JCS-120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13989151#comment-13989151 ] Hudson commented on JCS-120: UNSTABLE: Integrated in commons-jcs #5 (See [https://builds.apache.org/job/commons-jcs/5/]) JCS-120 add CDI support and fix TCK (struberg: rev 4d561133ca105888da78c2c162745260b8c95a47) * commons-jcs-jcache/src/main/java/org/apache/commons/jcs/jcache/cdi/CacheInvocationParameterImpl.java * commons-jcs-jcache/src/main/java/org/apache/commons/jcs/jcache/cdi/CacheKeyInvocationContextImpl.java * commons-jcs-tck-tests/run-tck.sh * commons-jcs-jcache/src/main/java/org/apache/commons/jcs/jcache/cdi/CacheRemoveAllInterceptor.java * commons-jcs-jcache/src/main/java/org/apache/commons/jcs/jcache/cdi/CacheResolverFactoryImpl.java * commons-jcs-jcache/src/main/java/org/apache/commons/jcs/jcache/cdi/CachePutInterceptor.java * commons-jcs-jcache/pom.xml * commons-jcs-tck-tests/src/test/java/org/apache/commons/jcs/jcache/EnsureCDIIsTestedWhenTCKsRunTest.java * commons-jcs-jcache/src/main/java/org/apache/commons/jcs/jcache/JCSCachingManager.java * commons-jcs-jcache/src/main/java/org/apache/commons/jcs/jcache/cdi/CacheInvocationContextImpl.java * commons-jcs-jcache/src/main/java/org/apache/commons/jcs/jcache/cdi/CacheRemoveInterceptor.java * commons-jcs-jcache/src/main/java/org/apache/commons/jcs/jcache/cdi/GeneratedCacheKeyImpl.java * commons-jcs-jcache/src/main/java/org/apache/commons/jcs/jcache/cdi/CDIJCacheHelper.java * commons-jcs-jcache/src/main/java/org/apache/commons/jcs/jcache/cdi/CacheMethodDetailsImpl.java * commons-jcs-jcache/src/main/java/org/apache/commons/jcs/jcache/cdi/CacheResultInterceptor.java * commons-jcs-jcache/src/main/resources/META-INF/beans.xml * commons-jcs-jcache/src/main/java/org/apache/commons/jcs/jcache/cdi/CacheResolverImpl.java * commons-jcs-jcache/src/test/java/org/apache/commons/jcs/jcache/CacheTest.java * commons-jcs-jcache/src/main/java/org/apache/commons/jcs/jcache/cdi/CacheKeyGeneratorImpl.java * commons-jcs-tck-tests/src/test/java/org/apache/commons/jcs/jcache/OWBBeanProvider.java * commons-jcs-jcache/src/main/resources/META-INF/services/javax.enterprise.inject.spi.Extension cleanup mvn deps + add missing headers -- Key: JCS-120 URL: https://issues.apache.org/jira/browse/JCS-120 Project: Commons JCS Issue Type: Task Reporter: Romain Manni-Bucau Assignee: Thomas Vandahl Fix For: jcs-2.0.0 Attachments: JCS-fix.patch, JCS-withcdi.patch, JCS.patch, diff -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (LANG-1006) Add wrap (with String or char) to StringUtils. Fixing NumberUtils comments. Adding methods to NumberUtils
Thiago Andrade created LANG-1006: Summary: Add wrap (with String or char) to StringUtils. Fixing NumberUtils comments. Adding methods to NumberUtils Key: LANG-1006 URL: https://issues.apache.org/jira/browse/LANG-1006 Project: Commons Lang Issue Type: New Feature Components: lang.*, lang.math.* Reporter: Thiago Andrade Placeholder ticket for github PR 21: https://github.com/apache/commons-lang/pull/21 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (MATH-437) Kolmogorov Smirnov Distribution
[ https://issues.apache.org/jira/browse/MATH-437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13989195#comment-13989195 ] Phil Steitz commented on MATH-437: -- Updated user guide and TestUtils in r1592430. All that remains now is removing the deprecated classes in 4.0 Kolmogorov Smirnov Distribution --- Key: MATH-437 URL: https://issues.apache.org/jira/browse/MATH-437 Project: Commons Math Issue Type: New Feature Reporter: Mikkel Meyer Andersen Assignee: Phil Steitz Priority: Minor Fix For: 4.0 Attachments: MATH437-with-test-take-1, ks-distribution.patch Original Estimate: 0.25h Remaining Estimate: 0.25h Kolmogorov-Smirnov test (see [1]) is used to test if one sample against a known probability density functions or if two samples are from the same distribution. To evaluate the test statistic, the Kolmogorov-Smirnov distribution is used. Quite good asymptotics exist for the one-sided test, but it's more difficult for the two-sided test. [1]: http://en.wikipedia.org/wiki/Kolmogorov%E2%80%93Smirnov_test -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (VFS-453) [VFS] Set socket timeout for HTTP and WebDAV schemes
[ https://issues.apache.org/jira/browse/VFS-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bernd Eckenfels resolved VFS-453. - Resolution: Fixed Fix Version/s: 2.1 Assignee: Bernd Eckenfels I merged the patch and added a simple test case. http://svn.apache.org/viewvc?view=revisionrevision=1592435 [VFS] Set socket timeout for HTTP and WebDAV schemes Key: VFS-453 URL: https://issues.apache.org/jira/browse/VFS-453 Project: Commons VFS Issue Type: Improvement Affects Versions: 2.0 Reporter: Jean-Marc Borer Assignee: Bernd Eckenfels Priority: Critical Fix For: 2.1 There was already an entry related to that question: https://issues.apache.org/jira/browse/VFS-249 However it is not true that it is fixed: you cannot set http.socket.timeout in FileSystemOpions and it even you manage to set it, It will not be taken into account when creating the HTTPClient instance for HTTP and WebDAV connections. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (SANDBOX-476) [asm] IllegalStateException: Undefined label used with ASM 4.1
Alexandre Chatiron created SANDBOX-476:
--
Summary: [asm] IllegalStateException: Undefined label used with
ASM 4.1
Key: SANDBOX-476
URL: https://issues.apache.org/jira/browse/SANDBOX-476
Project: Commons Sandbox
Issue Type: Bug
Components: Javaflow
Affects Versions: Nightly Builds
Reporter: Alexandre Chatiron
I want to upgrade Commons Javaflow from ASM 4 to 5 (same problem with 4.1 )
and I get this exception:
{code}
java.lang.IllegalStateException: Undefined label used
at org.objectweb.asm.util.CheckMethodAdapter.visitMaxs(Unknown Source)
at
org.apache.commons.javaflow.bytecode.transformation.asm.ContinuationMethodAdapter.visitMaxs(ContinuationMethodAdapter.java:313)
at org.objectweb.asm.tree.MethodNode.accept(Unknown Source)
at
org.apache.commons.javaflow.bytecode.transformation.asm.ContinuationMethodAnalyzer.visitEnd(ContinuationMethodAnalyzer.java:140)
{code}
the code triggering this error is:
{code:java}
public void visitMaxs(int maxStack, int maxLocals) {
Label endLabel = new Label();
mv.visitLabel(endLabel);
mv.visitLocalVariable(__stackRecorder, L + STACK_RECORDER + ;,
null, startLabel, endLabel, stackRecorderVar);
mv.visitMaxs(0, 0);
}
{code}
Any idea how to fix that?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (COLLECTIONS-523) Removing unnecessary method
[
https://issues.apache.org/jira/browse/COLLECTIONS-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thiago Andrade updated COLLECTIONS-523:
---
Affects Version/s: 4.0
Removing unnecessary method
---
Key: COLLECTIONS-523
URL: https://issues.apache.org/jira/browse/COLLECTIONS-523
Project: Commons Collections
Issue Type: Improvement
Components: Map
Affects Versions: 4.0
Reporter: Thiago Andrade
Removing unnecessary method {{private V put(final K key, final V value, final
long now)}} once the final long now parameter was never used.
The param was confusing the logic of this method.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (COLLECTIONS-523) Removing unnecessary method
Thiago Andrade created COLLECTIONS-523:
--
Summary: Removing unnecessary method
Key: COLLECTIONS-523
URL: https://issues.apache.org/jira/browse/COLLECTIONS-523
Project: Commons Collections
Issue Type: Improvement
Components: Map
Reporter: Thiago Andrade
Removing unnecessary method {{private V put(final K key, final V value, final
long now)}} once the final long now parameter was never used.
The param was confusing the logic of this method.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (COLLECTIONS-523) Removing unnecessary method
[
https://issues.apache.org/jira/browse/COLLECTIONS-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thiago Andrade updated COLLECTIONS-523:
---
Description:
I suggest remmove unnecessary method {{private V put(final K key, final V
value, final long now)}} from the class {{PassiveExpiringMap}} once the {{final
long now}} parameter was never used. I've addapted the code to work properly.
The param was confusing the logic of this method.
Placeholder ticket for github PR 2:
https://github.com/apache/commons-collections/pull/2
was:
Removing unnecessary method {{private V put(final K key, final V value, final
long now)}} once the final long now parameter was never used.
The param was confusing the logic of this method.
Removing unnecessary method
---
Key: COLLECTIONS-523
URL: https://issues.apache.org/jira/browse/COLLECTIONS-523
Project: Commons Collections
Issue Type: Improvement
Components: Map
Affects Versions: 4.0
Reporter: Thiago Andrade
I suggest remmove unnecessary method {{private V put(final K key, final V
value, final long now)}} from the class {{PassiveExpiringMap}} once the
{{final long now}} parameter was never used. I've addapted the code to work
properly.
The param was confusing the logic of this method.
Placeholder ticket for github PR 2:
https://github.com/apache/commons-collections/pull/2
--
This message was sent by Atlassian JIRA
(v6.2#6252)
