[jira] [Created] (LANG-1037) Join list of objects with different end separator
Duncan Jones created LANG-1037:
--
Summary: Join list of objects with different end separator
Key: LANG-1037
URL: https://issues.apache.org/jira/browse/LANG-1037
Project: Commons Lang
Issue Type: New Feature
Components: lang.*
Reporter: Duncan Jones
Assignee: Duncan Jones
Priority: Minor
Fix For: Discussion
A common programming challenge is joining a list with a different separator
between the final two items. For example, joining a list with {{,}} as the
primary separator but {{and}} as the final separator.
I propose that we extend {{StringUtils}} with three additional methods:
{code:java}
public static String join(Iterable? iterable, String separator, String
endSeparator)
public static String join(Object[] array, String separator, String endSeparator)
public static String join(Object[] array, String separator, String
endSeparator, int startIndex, int endIndex)
{code}
This could also be added to the other {{join}} methods for primitives, but I
suspect the primary use case will be strings and I don't suggest we pollute the
class any further.
Below shows the expected pseudo output using {{,}} and {{and}}:
{code}
join(a) == a
join(a,b) == a and b
join(a,b,c) == a, b and c
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LANG-1037) Join list of objects with different end separator
[
https://issues.apache.org/jira/browse/LANG-1037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones updated LANG-1037:
---
Description:
A common programming challenge is joining a list with a different separator
between the final two items. For example, joining a list with {{,}} as the
primary separator but {{and}} as the final separator.
I propose that we extend {{StringUtils}} with three additional methods:
{code:java}
public static String join(Iterable? iterable, String separator, String
endSeparator)
public static String join(Object[] array, String separator, String endSeparator)
public static String join(Object[] array, String separator, String
endSeparator, int startIndex, int endIndex)
{code}
This could also be added to the other {{join}} methods for primitives, but I
suspect the primary use case will be strings and I don't suggest we pollute the
class any further.
Below shows the expected pseudo output using {{,}} and {{and}}:
{code}
join(a) == a
join(a,b) == a and b
join(a,b,c) == a, b and c
{code}
Take a look at [this Stack Overflow
question|http://stackoverflow.com/q/8255077/474189] to see just how awkward the
current solutions are:
was:
A common programming challenge is joining a list with a different separator
between the final two items. For example, joining a list with {{,}} as the
primary separator but {{and}} as the final separator.
I propose that we extend {{StringUtils}} with three additional methods:
{code:java}
public static String join(Iterable? iterable, String separator, String
endSeparator)
public static String join(Object[] array, String separator, String endSeparator)
public static String join(Object[] array, String separator, String
endSeparator, int startIndex, int endIndex)
{code}
This could also be added to the other {{join}} methods for primitives, but I
suspect the primary use case will be strings and I don't suggest we pollute the
class any further.
Below shows the expected pseudo output using {{,}} and {{and}}:
{code}
join(a) == a
join(a,b) == a and b
join(a,b,c) == a, b and c
{code}
Join list of objects with different end separator
-
Key: LANG-1037
URL: https://issues.apache.org/jira/browse/LANG-1037
Project: Commons Lang
Issue Type: New Feature
Components: lang.*
Reporter: Duncan Jones
Assignee: Duncan Jones
Priority: Minor
Fix For: Discussion
A common programming challenge is joining a list with a different separator
between the final two items. For example, joining a list with {{,}} as the
primary separator but {{and}} as the final separator.
I propose that we extend {{StringUtils}} with three additional methods:
{code:java}
public static String join(Iterable? iterable, String separator, String
endSeparator)
public static String join(Object[] array, String separator, String
endSeparator)
public static String join(Object[] array, String separator, String
endSeparator, int startIndex, int endIndex)
{code}
This could also be added to the other {{join}} methods for primitives, but I
suspect the primary use case will be strings and I don't suggest we pollute
the class any further.
Below shows the expected pseudo output using {{,}} and {{and}}:
{code}
join(a) == a
join(a,b) == a and b
join(a,b,c) == a, b and c
{code}
Take a look at [this Stack Overflow
question|http://stackoverflow.com/q/8255077/474189] to see just how awkward
the current solutions are:
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LANG-1037) Join list of objects with different end separator
[
https://issues.apache.org/jira/browse/LANG-1037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones updated LANG-1037:
---
Description:
A common programming challenge is joining a list with a different separator
between the final two items. For example, joining a list with {{,}} as the
primary separator but {{and}} as the final separator. Take a look at [this
Stack Overflow question|http://stackoverflow.com/q/8255077/474189] to see just
how awkward the current solutions are.
I propose that we extend {{StringUtils}} with three additional methods:
{code:java}
public static String join(Iterable? iterable, String separator, String
endSeparator)
public static String join(Object[] array, String separator, String endSeparator)
public static String join(Object[] array, String separator, String
endSeparator, int startIndex, int endIndex)
{code}
This could also be added to the other {{join}} methods for primitives, but I
suspect the primary use case will be strings and I don't suggest we pollute the
class any further.
Below shows the expected pseudo output using {{,}} and {{and}}:
{code}
join(a) == a
join(a,b) == a and b
join(a,b,c) == a, b and c
{code}
was:
A common programming challenge is joining a list with a different separator
between the final two items. For example, joining a list with {{,}} as the
primary separator but {{and}} as the final separator.
I propose that we extend {{StringUtils}} with three additional methods:
{code:java}
public static String join(Iterable? iterable, String separator, String
endSeparator)
public static String join(Object[] array, String separator, String endSeparator)
public static String join(Object[] array, String separator, String
endSeparator, int startIndex, int endIndex)
{code}
This could also be added to the other {{join}} methods for primitives, but I
suspect the primary use case will be strings and I don't suggest we pollute the
class any further.
Below shows the expected pseudo output using {{,}} and {{and}}:
{code}
join(a) == a
join(a,b) == a and b
join(a,b,c) == a, b and c
{code}
Take a look at [this Stack Overflow
question|http://stackoverflow.com/q/8255077/474189] to see just how awkward the
current solutions are:
Join list of objects with different end separator
-
Key: LANG-1037
URL: https://issues.apache.org/jira/browse/LANG-1037
Project: Commons Lang
Issue Type: New Feature
Components: lang.*
Reporter: Duncan Jones
Assignee: Duncan Jones
Priority: Minor
Fix For: Discussion
A common programming challenge is joining a list with a different separator
between the final two items. For example, joining a list with {{,}} as the
primary separator but {{and}} as the final separator. Take a look at [this
Stack Overflow question|http://stackoverflow.com/q/8255077/474189] to see
just how awkward the current solutions are.
I propose that we extend {{StringUtils}} with three additional methods:
{code:java}
public static String join(Iterable? iterable, String separator, String
endSeparator)
public static String join(Object[] array, String separator, String
endSeparator)
public static String join(Object[] array, String separator, String
endSeparator, int startIndex, int endIndex)
{code}
This could also be added to the other {{join}} methods for primitives, but I
suspect the primary use case will be strings and I don't suggest we pollute
the class any further.
Below shows the expected pseudo output using {{,}} and {{and}}:
{code}
join(a) == a
join(a,b) == a and b
join(a,b,c) == a, b and c
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (LANG-1037) Join list of objects with different end separator
[
https://issues.apache.org/jira/browse/LANG-1037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones updated LANG-1037:
---
Description:
A common programming challenge is joining a list with a different separator
between the final two items. For example, joining a list with {{, }} as the
primary separator but {{ and }} as the final separator. Take a look at [this
Stack Overflow question|http://stackoverflow.com/q/8255077/474189] to see just
how awkward the current solutions are.
I propose that we extend {{StringUtils}} with three additional methods:
{code:java}
public static String join(Iterable? iterable, String separator, String
endSeparator)
public static String join(Object[] array, String separator, String endSeparator)
public static String join(Object[] array, String separator, String
endSeparator, int startIndex, int endIndex)
{code}
This could also be added to the other {{join}} methods for primitives, but I
suspect the primary use case will be strings and I don't suggest we pollute the
class any further.
Below shows the expected pseudo output using {{, }} and {{ and }}:
{code}
join(a) == a
join(a,b) == a and b
join(a,b,c) == a, b and c
{code}
was:
A common programming challenge is joining a list with a different separator
between the final two items. For example, joining a list with {{,}} as the
primary separator but {{and}} as the final separator. Take a look at [this
Stack Overflow question|http://stackoverflow.com/q/8255077/474189] to see just
how awkward the current solutions are.
I propose that we extend {{StringUtils}} with three additional methods:
{code:java}
public static String join(Iterable? iterable, String separator, String
endSeparator)
public static String join(Object[] array, String separator, String endSeparator)
public static String join(Object[] array, String separator, String
endSeparator, int startIndex, int endIndex)
{code}
This could also be added to the other {{join}} methods for primitives, but I
suspect the primary use case will be strings and I don't suggest we pollute the
class any further.
Below shows the expected pseudo output using {{,}} and {{and}}:
{code}
join(a) == a
join(a,b) == a and b
join(a,b,c) == a, b and c
{code}
Join list of objects with different end separator
-
Key: LANG-1037
URL: https://issues.apache.org/jira/browse/LANG-1037
Project: Commons Lang
Issue Type: New Feature
Components: lang.*
Reporter: Duncan Jones
Assignee: Duncan Jones
Priority: Minor
Fix For: Discussion
A common programming challenge is joining a list with a different separator
between the final two items. For example, joining a list with {{, }} as the
primary separator but {{ and }} as the final separator. Take a look at
[this Stack Overflow question|http://stackoverflow.com/q/8255077/474189] to
see just how awkward the current solutions are.
I propose that we extend {{StringUtils}} with three additional methods:
{code:java}
public static String join(Iterable? iterable, String separator, String
endSeparator)
public static String join(Object[] array, String separator, String
endSeparator)
public static String join(Object[] array, String separator, String
endSeparator, int startIndex, int endIndex)
{code}
This could also be added to the other {{join}} methods for primitives, but I
suspect the primary use case will be strings and I don't suggest we pollute
the class any further.
Below shows the expected pseudo output using {{, }} and {{ and }}:
{code}
join(a) == a
join(a,b) == a and b
join(a,b,c) == a, b and c
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CSV-132) inconsistent Javadoc for org.apache.commons.csv.CSVFormat
Sascha Szott created CSV-132: Summary: inconsistent Javadoc for org.apache.commons.csv.CSVFormat Key: CSV-132 URL: https://issues.apache.org/jira/browse/CSV-132 Project: Commons CSV Issue Type: Bug Components: Documentation Affects Versions: 1.0 Reporter: Sascha Szott Priority: Trivial Hi folks, the Javadoc for org.apache.commons.csv.CSVFormat seems to be inconsistent since there are some references to a non-existing method *withQuoteChar*. The method name should be replaced by *withQuote*. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CSV-132) Incorrect Javadoc for org.apache.commons.csv.CSVFormat withQuote()
[ https://issues.apache.org/jira/browse/CSV-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated CSV-132: - Summary: Incorrect Javadoc for org.apache.commons.csv.CSVFormat withQuote() (was: Incorrect Javadoc for org.apache.commons.csv.CSVFormat) Incorrect Javadoc for org.apache.commons.csv.CSVFormat withQuote() -- Key: CSV-132 URL: https://issues.apache.org/jira/browse/CSV-132 Project: Commons CSV Issue Type: Bug Components: Documentation Affects Versions: 1.0 Reporter: Sascha Szott Priority: Trivial Hi folks, the Javadoc for org.apache.commons.csv.CSVFormat seems to be inconsistent since there are some references to a non-existing method *withQuoteChar*. The method name should be replaced by *withQuote*. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CSV-132) Incorrect Javadoc for org.apache.commons.csv.CSVFormat
[ https://issues.apache.org/jira/browse/CSV-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated CSV-132: - Summary: Incorrect Javadoc for org.apache.commons.csv.CSVFormat (was: inconsistent Javadoc for org.apache.commons.csv.CSVFormat) Incorrect Javadoc for org.apache.commons.csv.CSVFormat -- Key: CSV-132 URL: https://issues.apache.org/jira/browse/CSV-132 Project: Commons CSV Issue Type: Bug Components: Documentation Affects Versions: 1.0 Reporter: Sascha Szott Priority: Trivial Hi folks, the Javadoc for org.apache.commons.csv.CSVFormat seems to be inconsistent since there are some references to a non-existing method *withQuoteChar*. The method name should be replaced by *withQuote*. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CSV-132) Incorrect Javadoc referencing org.apache.commons.csv.CSVFormat withQuote()
[ https://issues.apache.org/jira/browse/CSV-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated CSV-132: - Summary: Incorrect Javadoc referencing org.apache.commons.csv.CSVFormat withQuote() (was: Incorrect Javadoc for org.apache.commons.csv.CSVFormat withQuote()) Incorrect Javadoc referencing org.apache.commons.csv.CSVFormat withQuote() -- Key: CSV-132 URL: https://issues.apache.org/jira/browse/CSV-132 Project: Commons CSV Issue Type: Bug Components: Documentation Affects Versions: 1.0 Reporter: Sascha Szott Priority: Trivial Hi folks, the Javadoc for org.apache.commons.csv.CSVFormat seems to be inconsistent since there are some references to a non-existing method *withQuoteChar*. The method name should be replaced by *withQuote*. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (LANG-1035) Javadoc for EqualsBuilder.reflectionEquals() is unclear
[
https://issues.apache.org/jira/browse/LANG-1035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Duncan Jones resolved LANG-1035.
Resolution: Fixed
Fix Version/s: (was: Patch Needed)
3.4
Author: djones
Date: Wed Sep 10 11:32:53 2014
New Revision: 1623970
URL: http://svn.apache.org/r1623970
Log:
Fix for LANG-1035: Javadoc for EqualsBuilder.reflectionEquals() is unclear
Modified:
commons/proper/lang/trunk/src/changes/changes.xml
commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/builder/EqualsBuilder.java
Javadoc for EqualsBuilder.reflectionEquals() is unclear
---
Key: LANG-1035
URL: https://issues.apache.org/jira/browse/LANG-1035
Project: Commons Lang
Issue Type: Bug
Components: lang.builder.*
Affects Versions: 3.3.2
Reporter: Duncan Jones
Assignee: Duncan Jones
Fix For: 3.4
The Javadoc for {{EqualsBuilder.reflectionEquals()}} doesn't explain that
{{.equals()}} is used to compare non-primitive fields in the class.
Consequently, readers may assume the method recursively builds {{.equals()}}
for all fields. We should clarify this.
Related: LANG-1034
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CSV-132) Incorrect Javadoc referencing org.apache.commons.csv.CSVFormat withQuote()
[
https://issues.apache.org/jira/browse/CSV-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved CSV-132.
--
Resolution: Fixed
Fix Version/s: 1.1
Thank you for the report. Keep them coming!
Fixed in svn:
{noformat}
commit -m [CSV-132] Incorrect Javadoc referencing
org.apache.commons.csv.CSVFormat withQuote()
C:/vcs/svn/apache/commons/trunks-proper/csv/src/main/java/org/apache/commons/csv/CSVFormat.java
C:/vcs/svn/apache/commons/trunks-proper/csv/src/changes/changes.xml
Sending
C:/vcs/svn/apache/commons/trunks-proper/csv/src/changes/changes.xml
Sending
C:/vcs/svn/apache/commons/trunks-proper/csv/src/main/java/org/apache/commons/csv/CSVFormat.java
Transmitting file data ...
Committed revision 1623971.
{noformat}
Incorrect Javadoc referencing org.apache.commons.csv.CSVFormat withQuote()
--
Key: CSV-132
URL: https://issues.apache.org/jira/browse/CSV-132
Project: Commons CSV
Issue Type: Bug
Components: Documentation
Affects Versions: 1.0
Reporter: Sascha Szott
Priority: Trivial
Fix For: 1.1
Hi folks,
the Javadoc for org.apache.commons.csv.CSVFormat seems to be inconsistent
since there are some references to a non-existing method *withQuoteChar*. The
method name should be replaced by *withQuote*.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CSV-130) CSVFormat#withHeader doesn't work well with #printComment
[
https://issues.apache.org/jira/browse/CSV-130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128397#comment-14128397
]
Gary Gregory commented on CSV-130:
--
Since this is a one-off per file, I think adding a format field
{{withHeaderComment(String...)}} is better.
CSVFormat#withHeader doesn't work well with #printComment
-
Key: CSV-130
URL: https://issues.apache.org/jira/browse/CSV-130
Project: Commons CSV
Issue Type: Improvement
Components: Printer
Affects Versions: 1.0
Reporter: Sergei Lebedev
Priority: Minor
For some applications it might be useful to add a top comment to the CSV file
being printed. However, this isn't possible with #120 implemented the way it
is. Here's an example:
{code}
public class Example {
public static void main(final String[] args) throws IOException {
final CSVPrinter csvPrinter = CSVFormat.TDF
.withCommentMarker('#')
.withHeader(foo, bar)
.print(System.out);
csvPrinter.printComment(generated by yada v1.0);
csvPrinter.printComment(foo some description);
csvPrinter.printComment(bar more here);
csvPrinter.printRecord(42, 24);
csvPrinter.printRecord(24, 42);
}
}
// Outputs:
// foobar
// # generated by yada v1.0
// # foo some description
// # bar more here
// 42 24
// 24 42
{code}
Obviously, there's a way to fix this: output the header in the first call
to `#printRecord`, but it just doesn't feel right. What to do you think?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CSV-130) CSVFormat#withHeader doesn't work well with #printComment, add withHeaderComments(String...)
[
https://issues.apache.org/jira/browse/CSV-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated CSV-130:
-
Summary: CSVFormat#withHeader doesn't work well with #printComment, add
withHeaderComments(String...) (was: CSVFormat#withHeader doesn't work well
with #printComment)
CSVFormat#withHeader doesn't work well with #printComment, add
withHeaderComments(String...)
Key: CSV-130
URL: https://issues.apache.org/jira/browse/CSV-130
Project: Commons CSV
Issue Type: Improvement
Components: Printer
Affects Versions: 1.0
Reporter: Sergei Lebedev
Priority: Minor
For some applications it might be useful to add a top comment to the CSV file
being printed. However, this isn't possible with #120 implemented the way it
is. Here's an example:
{code}
public class Example {
public static void main(final String[] args) throws IOException {
final CSVPrinter csvPrinter = CSVFormat.TDF
.withCommentMarker('#')
.withHeader(foo, bar)
.print(System.out);
csvPrinter.printComment(generated by yada v1.0);
csvPrinter.printComment(foo some description);
csvPrinter.printComment(bar more here);
csvPrinter.printRecord(42, 24);
csvPrinter.printRecord(24, 42);
}
}
// Outputs:
// foobar
// # generated by yada v1.0
// # foo some description
// # bar more here
// 42 24
// 24 42
{code}
Obviously, there's a way to fix this: output the header in the first call
to `#printRecord`, but it just doesn't feel right. What to do you think?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CSV-130) CSVFormat#withHeader doesn't work well with #printComment, add withHeaderComments(String...)
[
https://issues.apache.org/jira/browse/CSV-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved CSV-130.
--
Resolution: Fixed
Fix Version/s: 1.1
Please review the code in trunk.
{noformat}
commit -m [CSV-130] CSVFormat#withHeader doesn't work well with #printComment,
add withHeaderComments(String...)
C:/vcs/svn/apache/commons/trunks-proper/csv/src/main/java/org/apache/commons/csv/CSVFormat.java
C:/vcs/svn/apache/commons/trunks-proper/csv/src/main/java/org/apache/commons/csv/CSVPrinter.java
C:/vcs/svn/apache/commons/trunks-proper/csv/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
C:/vcs/svn/apache/commons/trunks-proper/csv/src/changes/changes.xml
Sending
C:/vcs/svn/apache/commons/trunks-proper/csv/src/changes/changes.xml
Sending
C:/vcs/svn/apache/commons/trunks-proper/csv/src/main/java/org/apache/commons/csv/CSVFormat.java
Sending
C:/vcs/svn/apache/commons/trunks-proper/csv/src/main/java/org/apache/commons/csv/CSVPrinter.java
Sending
C:/vcs/svn/apache/commons/trunks-proper/csv/src/test/java/org/apache/commons/csv/CSVPrinterTest.java
Transmitting file data ...
Committed revision 1623984.
{noformat}
CSVFormat#withHeader doesn't work well with #printComment, add
withHeaderComments(String...)
Key: CSV-130
URL: https://issues.apache.org/jira/browse/CSV-130
Project: Commons CSV
Issue Type: Improvement
Components: Printer
Affects Versions: 1.0
Reporter: Sergei Lebedev
Priority: Minor
Fix For: 1.1
For some applications it might be useful to add a top comment to the CSV file
being printed. However, this isn't possible with #120 implemented the way it
is. Here's an example:
{code}
public class Example {
public static void main(final String[] args) throws IOException {
final CSVPrinter csvPrinter = CSVFormat.TDF
.withCommentMarker('#')
.withHeader(foo, bar)
.print(System.out);
csvPrinter.printComment(generated by yada v1.0);
csvPrinter.printComment(foo some description);
csvPrinter.printComment(bar more here);
csvPrinter.printRecord(42, 24);
csvPrinter.printRecord(24, 42);
}
}
// Outputs:
// foobar
// # generated by yada v1.0
// # foo some description
// # bar more here
// 42 24
// 24 42
{code}
Obviously, there's a way to fix this: output the header in the first call
to `#printRecord`, but it just doesn't feel right. What to do you think?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CSV-131) save positions of records to enable random access
[
https://issues.apache.org/jira/browse/CSV-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128432#comment-14128432
]
Gary Gregory commented on CSV-131:
--
Thank you for your interest in Apache Commons CSV and your patch.
I looked at the patch briefly. Before I look further, I'd like to see a better
patch with tests that prove that the changes work as intended.
As it is now, the patch does not show your changes in action ;-)
Thank you,
Gary
save positions of records to enable random access
-
Key: CSV-131
URL: https://issues.apache.org/jira/browse/CSV-131
Project: Commons CSV
Issue Type: Improvement
Components: Parser
Affects Versions: 1.1
Reporter: Holger Stratmann
Priority: Minor
Attachments: PositionTracking_20140907.patch
Original Estimate: 1h
Remaining Estimate: 1h
It would be good to have {{CSVRecord}} save its position in the source stream.
Reason: Knowing the position of the records would enable random access to
retrieve records from the source (after reading it once to build an index) if
the file is too large to be read into memory (or if we don't want to read the
full file to access a record in the middle).
Additional info: I have created a random access csv reader and a csv
viewer (Swing) for arbitrarily large CSV files. It requires one additional
scan of the file to build an index (multi-byte charsets supported). The index
can be saved to a file so it only needs to be built once. Because the lexer
uses a BufferedReader, we need internal information to know where each
record starts.
The change to core is minor: one field in {{CSVRecord}}s and some
associated methods to store the position.
Patch will be attached.
Code for random access (both UI and non-UI) will be proposed (and possibly
submitted) as a separate issue. It could also be an independent add-on but
requires this one little change to Commons CSV.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (CONFIGURATION-582) PropertiesConfigurationLayout.getCanonicalComment throws StringIndexOutOfBoundsException when line before property has a single space
[
https://issues.apache.org/jira/browse/CONFIGURATION-582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Heger resolved CONFIGURATION-582.
Resolution: Fixed
Fix Version/s: 2.0
Fixed in SVN in revision 1623874.
PropertiesConfigurationLayout.getCanonicalComment throws
StringIndexOutOfBoundsException when line before property has a single space
-
Key: CONFIGURATION-582
URL: https://issues.apache.org/jira/browse/CONFIGURATION-582
Project: Commons Configuration
Issue Type: Bug
Affects Versions: 1.10
Reporter: Jonathan wu
Priority: Minor
Fix For: 2.0
When a properties file has a line with a single space in it, calling
getCanonicalComment(propertyKey, false) on the
PropertiesConfigurationLayout will throw a StringIndexOutOfBoundsException.
Below is the stack trace:
{code}
java.lang.StringIndexOutOfBoundsException: String index out of range: 1
at java.lang.String.charAt(String.java:686)
at
org.apache.commons.configuration.PropertiesConfigurationLayout.stripCommentChar(PropertiesConfigurationLayout.java:768)
at
org.apache.commons.configuration.PropertiesConfigurationLayout.trimComment(PropertiesConfigurationLayout.java:741)
at
org.apache.commons.configuration.PropertiesConfigurationLayout.constructCanonicalComment(PropertiesConfigurationLayout.java:900)
at
org.apache.commons.configuration.PropertiesConfigurationLayout.getCanonicalComment(PropertiesConfigurationLayout.java:212)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CSV-124) Improve toString() implementation of CSVRecord
[ https://issues.apache.org/jira/browse/CSV-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden updated CSV-124: - Fix Version/s: (was: Patch Needed) Improve toString() implementation of CSVRecord -- Key: CSV-124 URL: https://issues.apache.org/jira/browse/CSV-124 Project: Commons CSV Issue Type: Improvement Reporter: Benedikt Ritter Assignee: Brent Worden Fix For: 1.x Attachments: patch_CSV-124.diff Currently we only print out the values using Arrays.toString(). The comment, record number and header are missing from the output. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (CSV-124) Improve toString() implementation of CSVRecord
[ https://issues.apache.org/jira/browse/CSV-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brent Worden resolved CSV-124. -- Resolution: Fixed Fix Version/s: (was: 1.x) 1.1 Improve toString() implementation of CSVRecord -- Key: CSV-124 URL: https://issues.apache.org/jira/browse/CSV-124 Project: Commons CSV Issue Type: Improvement Reporter: Benedikt Ritter Assignee: Brent Worden Fix For: 1.1 Attachments: patch_CSV-124.diff Currently we only print out the values using Arrays.toString(). The comment, record number and header are missing from the output. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (VFS-180) Support HTTPS / SSL for Webdav
[ https://issues.apache.org/jira/browse/VFS-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128700#comment-14128700 ] Aleksei Kovura commented on VFS-180: Any idea on when this will be merged? Support HTTPS / SSL for Webdav -- Key: VFS-180 URL: https://issues.apache.org/jira/browse/VFS-180 Project: Commons VFS Issue Type: New Feature Affects Versions: 1.0, 1.1 Reporter: Werner Mueller Attachments: VFS-180.patch, VFS-180.patch, VFS-180.patch, patch_180_vfs2.txt, patch_180_vfs2.txt The Slide Webdav lib supports encrypted HTTPS connections. So it should be possible to add https support to vfs too. currently the webdav provider creates http urls (in WebdavClientFactory.java). maybe some provider like 'webdavs' could be added to switch to HttpsUrl. regards werner -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DAEMON-322) Missing Windows 2012 R2 support
[ https://issues.apache.org/jira/browse/DAEMON-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128706#comment-14128706 ] Sebb commented on DAEMON-322: - Thanks very much. Seems a very fragile way of obtaining such basic information about the OS. Looks like every binary that uses GetVersion will have to be updated for every new release. So much for upwards compatibility. Unless DAEMON actually needs to display the version, it could just use the feature support API instead. And/or maybe it can use the Java binary implementation somehow. Missing Windows 2012 R2 support --- Key: DAEMON-322 URL: https://issues.apache.org/jira/browse/DAEMON-322 Project: Commons Daemon Issue Type: Bug Components: Procrun Affects Versions: 1.0.15 Environment: Windows 2012 R2 Tomcat 7.0.55 Java 7u67 Reporter: Bernd Ernesti Tomcat uses Procrun to install a Windows service. I opened a bug at the tomcat tracker (https://issues.apache.org/bugzilla/show_bug.cgi?id=56929) and was pointed out to open it here. Windows 8.1 is probably also affected too. Here is the Tomcat bug: The server information while running as a Windows service on 2012 R2 is wrong. The system is identified as: OS Name: Windows Server 2012 OS Version: 6.2 It is correct when starting tomcat with startup.bat: OS Name: Windows Server 2012 R2 OS Version: 6.3 How to reproduce: 1. Install the Windows service from apache-tomcat-7.0.55\bin service.bat install Test 2. Activate the configuration for the /manager/ access in conf\tomcat-users.xml 3. Start the service 4. Navigate to the /manager/status page 5. The Server Information contains the wrong OS Version 6. Stop the Windows service 7. Start the tomcat with the startup.bat script 8. Check the /manager/status page again which now contains the correct version The issue could be related due too the service binary which needs to be recompiled for: http://msdn.microsoft.com/en-us/library/windows/desktop/ms724832%28v=vs.85%29.aspx and the link inside it for: http://msdn.microsoft.com/en-us/library/windows/desktop/dn481241%28v=vs.85%29.aspx -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (DAEMON-322) Missing Windows 2012 R2 support
[ https://issues.apache.org/jira/browse/DAEMON-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128750#comment-14128750 ] Bernd Eckenfels commented on DAEMON-322: BTW: it looks like in the openjdk tracker is also a case where JVM itself calculates the wrong os properties based on the launcher used. So I am not sure what this bug is talking about, but if it is the calculation of system properties it could actually be the very same bug: https://bugs.openjdk.java.net/browse/JDK-8057122 There it looks like there is a combination of upstream(backported) fixes and a correct manifest needed to make the custom launcher work. Missing Windows 2012 R2 support --- Key: DAEMON-322 URL: https://issues.apache.org/jira/browse/DAEMON-322 Project: Commons Daemon Issue Type: Bug Components: Procrun Affects Versions: 1.0.15 Environment: Windows 2012 R2 Tomcat 7.0.55 Java 7u67 Reporter: Bernd Ernesti Tomcat uses Procrun to install a Windows service. I opened a bug at the tomcat tracker (https://issues.apache.org/bugzilla/show_bug.cgi?id=56929) and was pointed out to open it here. Windows 8.1 is probably also affected too. Here is the Tomcat bug: The server information while running as a Windows service on 2012 R2 is wrong. The system is identified as: OS Name: Windows Server 2012 OS Version: 6.2 It is correct when starting tomcat with startup.bat: OS Name: Windows Server 2012 R2 OS Version: 6.3 How to reproduce: 1. Install the Windows service from apache-tomcat-7.0.55\bin service.bat install Test 2. Activate the configuration for the /manager/ access in conf\tomcat-users.xml 3. Start the service 4. Navigate to the /manager/status page 5. The Server Information contains the wrong OS Version 6. Stop the Windows service 7. Start the tomcat with the startup.bat script 8. Check the /manager/status page again which now contains the correct version The issue could be related due too the service binary which needs to be recompiled for: http://msdn.microsoft.com/en-us/library/windows/desktop/ms724832%28v=vs.85%29.aspx and the link inside it for: http://msdn.microsoft.com/en-us/library/windows/desktop/dn481241%28v=vs.85%29.aspx -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (DAEMON-322) Missing Windows 2012 R2 support
[ https://issues.apache.org/jira/browse/DAEMON-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14128750#comment-14128750 ] Bernd Eckenfels edited comment on DAEMON-322 at 9/10/14 5:18 PM: - BTW: it looks like in the openjdk tracker contains also a case where JVM itself calculates the wrong os properties when jvm.dll and custom launchers are used. So I am not sure what this bug is talking about, but if it is the calculation of system properties it could actually be the very same bug: https://bugs.openjdk.java.net/browse/JDK-8057122 There it looks like there is a combination of upstream(backported) fixes and a correct manifest needed to make the custom launcher work. I am afraid this is needed to fix JVM behavior, so we should allign the manifests of the daemons launcher with jdk launcher. was (Author: b.eckenfels): BTW: it looks like in the openjdk tracker is also a case where JVM itself calculates the wrong os properties based on the launcher used. So I am not sure what this bug is talking about, but if it is the calculation of system properties it could actually be the very same bug: https://bugs.openjdk.java.net/browse/JDK-8057122 There it looks like there is a combination of upstream(backported) fixes and a correct manifest needed to make the custom launcher work. Missing Windows 2012 R2 support --- Key: DAEMON-322 URL: https://issues.apache.org/jira/browse/DAEMON-322 Project: Commons Daemon Issue Type: Bug Components: Procrun Affects Versions: 1.0.15 Environment: Windows 2012 R2 Tomcat 7.0.55 Java 7u67 Reporter: Bernd Ernesti Tomcat uses Procrun to install a Windows service. I opened a bug at the tomcat tracker (https://issues.apache.org/bugzilla/show_bug.cgi?id=56929) and was pointed out to open it here. Windows 8.1 is probably also affected too. Here is the Tomcat bug: The server information while running as a Windows service on 2012 R2 is wrong. The system is identified as: OS Name: Windows Server 2012 OS Version: 6.2 It is correct when starting tomcat with startup.bat: OS Name: Windows Server 2012 R2 OS Version: 6.3 How to reproduce: 1. Install the Windows service from apache-tomcat-7.0.55\bin service.bat install Test 2. Activate the configuration for the /manager/ access in conf\tomcat-users.xml 3. Start the service 4. Navigate to the /manager/status page 5. The Server Information contains the wrong OS Version 6. Stop the Windows service 7. Start the tomcat with the startup.bat script 8. Check the /manager/status page again which now contains the correct version The issue could be related due too the service binary which needs to be recompiled for: http://msdn.microsoft.com/en-us/library/windows/desktop/ms724832%28v=vs.85%29.aspx and the link inside it for: http://msdn.microsoft.com/en-us/library/windows/desktop/dn481241%28v=vs.85%29.aspx -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CSV-131) save positions of records to enable random access
[
https://issues.apache.org/jira/browse/CSV-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14129051#comment-14129051
]
Holger Stratmann commented on CSV-131:
--
Agreed. I had realized I forgot to supply proper tests for core (I do have
tests in my code using these changes, but those are in different (new)
packages). I had planned to add tests this weekend, but while I have your
attention, let's go. I added a new patch that contains the updated testcase.
As you see I had added the method setNextRecordNumber so records get the
correct numbers even if we start reading at some random record.
I'm wondering if I / we should also add setCharacterPosition (I don't like
that name, it sounds like it does seeking - better ideas?) to tell the parser
at which position in the original source we are when we start reading. Right
now, when I skip to some record and start reading, the returned record will get
characterPosition == 0. I guess it would be nicer if the records were
completely identical no matter where we started reading them...
save positions of records to enable random access
-
Key: CSV-131
URL: https://issues.apache.org/jira/browse/CSV-131
Project: Commons CSV
Issue Type: Improvement
Components: Parser
Affects Versions: 1.1
Reporter: Holger Stratmann
Priority: Minor
Attachments: PositionTracking_20140907.patch
Original Estimate: 1h
Remaining Estimate: 1h
It would be good to have {{CSVRecord}} save its position in the source stream.
Reason: Knowing the position of the records would enable random access to
retrieve records from the source (after reading it once to build an index) if
the file is too large to be read into memory (or if we don't want to read the
full file to access a record in the middle).
Additional info: I have created a random access csv reader and a csv
viewer (Swing) for arbitrarily large CSV files. It requires one additional
scan of the file to build an index (multi-byte charsets supported). The index
can be saved to a file so it only needs to be built once. Because the lexer
uses a BufferedReader, we need internal information to know where each
record starts.
The change to core is minor: one field in {{CSVRecord}}s and some
associated methods to store the position.
Patch will be attached.
Code for random access (both UI and non-UI) will be proposed (and possibly
submitted) as a separate issue. It could also be an independent add-on but
requires this one little change to Commons CSV.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CSV-131) save positions of records to enable random access
[
https://issues.apache.org/jira/browse/CSV-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Holger Stratmann updated CSV-131:
-
Attachment: PositionTrackingTest_20140907.patch
save positions of records to enable random access
-
Key: CSV-131
URL: https://issues.apache.org/jira/browse/CSV-131
Project: Commons CSV
Issue Type: Improvement
Components: Parser
Affects Versions: 1.1
Reporter: Holger Stratmann
Priority: Minor
Attachments: PositionTrackingTest_20140907.patch,
PositionTracking_20140907.patch
Original Estimate: 1h
Remaining Estimate: 1h
It would be good to have {{CSVRecord}} save its position in the source stream.
Reason: Knowing the position of the records would enable random access to
retrieve records from the source (after reading it once to build an index) if
the file is too large to be read into memory (or if we don't want to read the
full file to access a record in the middle).
Additional info: I have created a random access csv reader and a csv
viewer (Swing) for arbitrarily large CSV files. It requires one additional
scan of the file to build an index (multi-byte charsets supported). The index
can be saved to a file so it only needs to be built once. Because the lexer
uses a BufferedReader, we need internal information to know where each
record starts.
The change to core is minor: one field in {{CSVRecord}}s and some
associated methods to store the position.
Patch will be attached.
Code for random access (both UI and non-UI) will be proposed (and possibly
submitted) as a separate issue. It could also be an independent add-on but
requires this one little change to Commons CSV.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (CSV-131) save positions of records to enable random access
[
https://issues.apache.org/jira/browse/CSV-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Holger Stratmann updated CSV-131:
-
Attachment: PositionTrackingFull_v101_20140910.patch
I convinced myself and created a new patch (containing patch and tests) that
includes a way to set the character position in the parser. The returned
records are now identical to the ones we get when we start reading at the
beginning.
Take a look and let me know which one you like better.
save positions of records to enable random access
-
Key: CSV-131
URL: https://issues.apache.org/jira/browse/CSV-131
Project: Commons CSV
Issue Type: Improvement
Components: Parser
Affects Versions: 1.1
Reporter: Holger Stratmann
Priority: Minor
Attachments: PositionTrackingFull_v101_20140910.patch,
PositionTrackingTest_20140907.patch, PositionTracking_20140907.patch
Original Estimate: 1h
Remaining Estimate: 1h
It would be good to have {{CSVRecord}} save its position in the source stream.
Reason: Knowing the position of the records would enable random access to
retrieve records from the source (after reading it once to build an index) if
the file is too large to be read into memory (or if we don't want to read the
full file to access a record in the middle).
Additional info: I have created a random access csv reader and a csv
viewer (Swing) for arbitrarily large CSV files. It requires one additional
scan of the file to build an index (multi-byte charsets supported). The index
can be saved to a file so it only needs to be built once. Because the lexer
uses a BufferedReader, we need internal information to know where each
record starts.
The change to core is minor: one field in {{CSVRecord}}s and some
associated methods to store the position.
Patch will be attached.
Code for random access (both UI and non-UI) will be proposed (and possibly
submitted) as a separate issue. It could also be an independent add-on but
requires this one little change to Commons CSV.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DBUTILS-50) Support CallableStatement out parameters
[
https://issues.apache.org/jira/browse/DBUTILS-50?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raymond DeCampo updated DBUTILS-50:
---
Attachment: DBUTILS-50.patch
Implementation of the desired functionality which (I hope) stays true to the
dbutils project as much as possible. Essentially adds a class representing OUT
parameters allowing users to intermix them with the list of parameters for the
SQL statement. Added execute() methods to QueryRunner, which use
CallableStatements and handle the OUT parameters; one flavor for procedures
returning one or more result sets and one for procedures returning update
counts. Unit tests are included.
Support CallableStatement out parameters
--
Key: DBUTILS-50
URL: https://issues.apache.org/jira/browse/DBUTILS-50
Project: Commons DbUtils
Issue Type: New Feature
Reporter: Dan Fabulich
Attachments: DBUTILS-50.patch
Using fillStatement and the new fillStatementWithBean, you can use a
CallableStatement like a PreparedStatement, retrieve its ResultSet and handle
it with a ResultSetHandler. But we don't yet support registering out
parameters on the CallableStatement in a convenient way and retrieving them
back into an object.
DBUTILS-28 requests stored procedure support and provides a patch, but I
don't like the patch. Regardless, we really should support a few helpers
like:
{code}
void registerOutParameters(CallableStatement stmt, int... sqlTypes)
Object[] getOutParameters(CallableStatement stmt)
void registerOutParameters(CallableStatement stmt, Class? beanClass)
T T getOutParameters(CallableStatement stmt, ClassT beanClass)
{code}
You should be able to write code like this:
{code}
CallableStatement stmt = runner.prepareCall(myString);
helper.registerOutParameters(stmt, MyBean.class);
queryRunner.fillStatement(stmt, foo, bar, baz);
stmt.executeUpdate();
MyBean bean = helper.getOutParameters(stmt, MyBean.class);
{code}
Or like this:
{code}
CallableStatement stmt = runner.prepareCall(myString);
helper.registerOutParameters(stmt, TINYINT, DECIMAL);
queryRunner.fillStatement(stmt, foo, bar, baz);
stmt.executeUpdate();
Object[] result = helper.getOutParameters(stmt);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CSV-131) save positions of records to enable random access
[
https://issues.apache.org/jira/browse/CSV-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14129466#comment-14129466
]
Gary Gregory commented on CSV-131:
--
Which patch is which for tests? Both new patches contain changes to the same
test class. Thanks.
save positions of records to enable random access
-
Key: CSV-131
URL: https://issues.apache.org/jira/browse/CSV-131
Project: Commons CSV
Issue Type: Improvement
Components: Parser
Affects Versions: 1.1
Reporter: Holger Stratmann
Priority: Minor
Attachments: PositionTrackingFull_v101_20140910.patch,
PositionTrackingTest_20140907.patch, PositionTracking_20140907.patch
Original Estimate: 1h
Remaining Estimate: 1h
It would be good to have {{CSVRecord}} save its position in the source stream.
Reason: Knowing the position of the records would enable random access to
retrieve records from the source (after reading it once to build an index) if
the file is too large to be read into memory (or if we don't want to read the
full file to access a record in the middle).
Additional info: I have created a random access csv reader and a csv
viewer (Swing) for arbitrarily large CSV files. It requires one additional
scan of the file to build an index (multi-byte charsets supported). The index
can be saved to a file so it only needs to be built once. Because the lexer
uses a BufferedReader, we need internal information to know where each
record starts.
The change to core is minor: one field in {{CSVRecord}}s and some
associated methods to store the position.
Patch will be attached.
Code for random access (both UI and non-UI) will be proposed (and possibly
submitted) as a separate issue. It could also be an independent add-on but
requires this one little change to Commons CSV.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CSV-131) save positions of records to enable random access
[
https://issues.apache.org/jira/browse/CSV-131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14129499#comment-14129499
]
Holger Stratmann commented on CSV-131:
--
The PositionTrackingTest_20140907 is just a test for the initial patch with
no changes to the other (non-test) classes. This is non-overlapping with the
initial patch.
PositionTrackingFull_v101_20140910 contains a new full version of the main
classes with an additional change as described in my last comment and the tests
that go along with that. If you use this file, you can disregard the others.
Sorry for the confusion.
save positions of records to enable random access
-
Key: CSV-131
URL: https://issues.apache.org/jira/browse/CSV-131
Project: Commons CSV
Issue Type: Improvement
Components: Parser
Affects Versions: 1.1
Reporter: Holger Stratmann
Priority: Minor
Attachments: PositionTrackingFull_v101_20140910.patch,
PositionTrackingTest_20140907.patch, PositionTracking_20140907.patch
Original Estimate: 1h
Remaining Estimate: 1h
It would be good to have {{CSVRecord}} save its position in the source stream.
Reason: Knowing the position of the records would enable random access to
retrieve records from the source (after reading it once to build an index) if
the file is too large to be read into memory (or if we don't want to read the
full file to access a record in the middle).
Additional info: I have created a random access csv reader and a csv
viewer (Swing) for arbitrarily large CSV files. It requires one additional
scan of the file to build an index (multi-byte charsets supported). The index
can be saved to a file so it only needs to be built once. Because the lexer
uses a BufferedReader, we need internal information to know where each
record starts.
The change to core is minor: one field in {{CSVRecord}}s and some
associated methods to store the position.
Patch will be attached.
Code for random access (both UI and non-UI) will be proposed (and possibly
submitted) as a separate issue. It could also be an independent add-on but
requires this one little change to Commons CSV.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
