[jira] [Resolved] (CSV-44) Merging OpenCSV
[ https://issues.apache.org/jira/browse/CSV-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg resolved CSV-44. --- Resolution: Later > Merging OpenCSV > > > Key: CSV-44 > URL: https://issues.apache.org/jira/browse/CSV-44 > Project: Commons CSV > Issue Type: Improvement >Reporter: Alexander Chmyr > Attachments: merged-opencsv-diff.tar.gz > > > Add header support and bean instantiation for CSV row. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CSV-62) Should CSVFormat.lineSeparator default to "\r\n" even on Unix systems?
[ https://issues.apache.org/jira/browse/CSV-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg resolved CSV-62. --- Resolution: Won't Fix > Should CSVFormat.lineSeparator default to "\r\n" even on Unix systems? > -- > > Key: CSV-62 > URL: https://issues.apache.org/jira/browse/CSV-62 > Project: Commons CSV > Issue Type: Bug >Reporter: Sebb > > The CSVFormat lineSeparator field defaults to "\r\n" which is OK for Windows, > but probably not suitable for Un*x systems. > It should probably default to the local line separator. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CSV-59) Is CharBuffer really needed, now that StringBuilder is available?
[ https://issues.apache.org/jira/browse/CSV-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg resolved CSV-59. --- Resolution: Fixed > Is CharBuffer really needed, now that StringBuilder is available? > - > > Key: CSV-59 > URL: https://issues.apache.org/jira/browse/CSV-59 > Project: Commons CSV > Issue Type: Improvement >Reporter: Sebb > Fix For: 1.0 > > > Seems to me that StringBuilder could be used instead of CharBuffer. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CSV-55) Replace while(true)-loop in CSVParser.getRecord() with do-while-loop
[
https://issues.apache.org/jira/browse/CSV-55?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Bourg resolved CSV-55.
---
Resolution: Fixed
Fix Version/s: 1.0
Thank you, that's fixed on the trunk.
> Replace while(true)-loop in CSVParser.getRecord() with do-while-loop
>
>
> Key: CSV-55
> URL: https://issues.apache.org/jira/browse/CSV-55
> Project: Commons CSV
> Issue Type: Improvement
> Components: Parser
>Affects Versions: 1.0
>Reporter: Benedikt Ritter
>Priority: Trivial
> Fix For: 1.0
>
> Attachments: CSV-55.txt
>
>
> The current implementation of {{getRecords()}} uses a while(true) loop, that
> gets canceled by an if statement:
> {code:java}
> while (true) {
> reusableToken.reset();
> lexer.nextToken(reusableToken);
> // omitted
> if(reusableToken.type != TOKEN) {
> break;
> }
> }
> {code}
> This should be replaced by a do-while-loop:
> {code:java}
> do {
> reusableToken.reset();
> lexer.nextToken(reusableToken);
> // omitted
> } while (reusableToken.type == TOKEN);
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANDBOX-408) CSVFormat describes itself as immutable, but it is not - in particular it is not thread-safe
[ https://issues.apache.org/jira/browse/SANDBOX-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg resolved SANDBOX-408. Resolution: Fixed Fix Version/s: CSV 1.0 > CSVFormat describes itself as immutable, but it is not - in particular it is > not thread-safe > > > Key: SANDBOX-408 > URL: https://issues.apache.org/jira/browse/SANDBOX-408 > Project: Commons Sandbox > Issue Type: Bug > Components: CSV >Reporter: Sebb > Fix For: CSV 1.0 > > Attachments: CSVFormat.java > > > CSVFormat describes itself as immutable, but it is not @Immutable - the class > fields are all mutable. > The methods that change the fields do so by creating a clone, and returning > the changed clone. > So in a sense the class is immutable. > However, the normal expectation is that @Immutable classes are @ThreadSafe. > CSVFormat is not thread-safe, because the fields are not volatile, and the > fields are not written & read using a common lock. > The comment needs to be clarified or removed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANDBOX-410) Predefined format for MYSQL
[ https://issues.apache.org/jira/browse/SANDBOX-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg resolved SANDBOX-410. Resolution: Fixed > Predefined format for MYSQL > --- > > Key: SANDBOX-410 > URL: https://issues.apache.org/jira/browse/SANDBOX-410 > Project: Commons Sandbox > Issue Type: Improvement > Components: CSV >Reporter: Emmanuel Bourg >Priority: Minor > Fix For: CSV 1.0 > > > MYSQL is able to import/export data in the CSV format. Commons CSV should > have a predefined format for the default CSV format used by MYSQL: > http://dev.mysql.com/doc/refman/5.1/en/load-data.html > The specifications of this format is: > - Field separator: \t > - Record separator: \n > - No quoted values > - Field and record separators in field values are escaped with '\' > - Field values are not trimmed > - No header -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANDBOX-407) Reduce visibility of methods in internal classes
[ https://issues.apache.org/jira/browse/SANDBOX-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg resolved SANDBOX-407. Resolution: Fixed Fix Version/s: CSV 1.0 Done, unfortunately I had to leave toString() public ;) > Reduce visibility of methods in internal classes > > > Key: SANDBOX-407 > URL: https://issues.apache.org/jira/browse/SANDBOX-407 > Project: Commons Sandbox > Issue Type: Improvement > Components: CSV >Reporter: Sebb > Fix For: CSV 1.0 > > > At present the CharBuffer and ExtendedBufferedReader classes are package > protected, but have public methods. > Maybe worth making the methods package-protected as well? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANDBOX-263) Excel strategy uses wrong separator
[
https://issues.apache.org/jira/browse/SANDBOX-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Bourg resolved SANDBOX-263.
Resolution: Fixed
I added a note in the Javadoc explaining that the list separator is specific to
the locale. CSVFormat.EXCEL must be constant so it's not possible to guess the
separator here.
> Excel strategy uses wrong separator
> ---
>
> Key: SANDBOX-263
> URL: https://issues.apache.org/jira/browse/SANDBOX-263
> Project: Commons Sandbox
> Issue Type: Bug
> Components: CSV
>Reporter: Gunnar Wagenknecht
>
> The Excel strategy is defined as follows.
> {code}
> public static CSVStrategy EXCEL_STRATEGY = new CSVStrategy(',', '"',
> COMMENTS_DISABLED, ESCAPE_DISABLED, false,
> false,
> false, false);
> {code}
> However, when I do a "Save as" in Excel the separator used is actually
> {{';'}}. Thus, parsing the CSV file as suggested in the JavaDoc of
> {{CSVParser}} fails.
> {code}
> String[][] data =
>(new CSVParser(new StringReader("a;b\nc;d"),
> CSVStrategy.EXCEL_STRATEGY)).getAllValues();
> {code}
> Simple test to reproduce:
> {code}
> import java.io.IOException;
> import java.io.StringReader;
> import org.apache.commons.csv.CSVParser;
> import org.apache.commons.csv.CSVStrategy;
> public class CSVExcelStrategyBug {
> public static void main(final String[] args) {
> try {
> System.out.println("Using ;");
> parse("a;b\nc;d");
> System.out.println();
> System.out.println("Using ,");
> parse("a,b\nc,d");
> } catch (final IOException e) {
> e.printStackTrace();
> }
> }
> private static void parse(final String input) throws IOException {
> final String[][] data = (new CSVParser(new StringReader(input),
> CSVStrategy.EXCEL_STRATEGY)).getAllValues();
> for (final String[] row : data) {
> System.out.print("[");
> for (final String cell : row) {
> System.out.print("(" + cell + ")");
> }
> System.out.println("]");
> }
> }
> }
> {code}
> Actual output:
> {noformat}
> Using ;
> [(a;b)]
> [(c;d)]
> Using ,
> [(a)(b)]
> [(c)(d)]
> {noformat}
> Expected output:
> {noformat}
> Using ;
> [(a)(b)]
> [(c)(d)]
> Using ,
> [(a,b)]
> [(c,d)]
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANDBOX-216) CSVWriter does not escape commas and quotes
[ https://issues.apache.org/jira/browse/SANDBOX-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg resolved SANDBOX-216. Resolution: Won't Fix The CSVWriter class and its package have been removed from Commons CSV. CSVPrinter should be used instead. > CSVWriter does not escape commas and quotes > --- > > Key: SANDBOX-216 > URL: https://issues.apache.org/jira/browse/SANDBOX-216 > Project: Commons Sandbox > Issue Type: Bug > Components: CSV >Reporter: David Wallace Croft > Fix For: CSV 1.0 > > Original Estimate: 3h > Remaining Estimate: 3h > > When CSVWriter is provided a field value of "Hello, \"Bob\"!", it writes it > out directly instead of wrapping it in quotes and escaping the internal > quotes. See the Wikipedia entry on CSV: > http://en.wikipedia.org/wiki/Comma-separated_values -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANDBOX-324) CSVWriter ignores fieldHeader setting from CSVConfig
[ https://issues.apache.org/jira/browse/SANDBOX-324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg resolved SANDBOX-324. Resolution: Won't Fix The CSVWriter class and its package have been removed from Commons CSV. CSVPrinter should be used instead. > CSVWriter ignores fieldHeader setting from CSVConfig > > > Key: SANDBOX-324 > URL: https://issues.apache.org/jira/browse/SANDBOX-324 > Project: Commons Sandbox > Issue Type: Bug > Components: CSV >Reporter: Rafal N > > Setting fieldHeader to true has no impact on CSVWriter - it just never > generates headers. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANDBOX-269) Decide whether to keep the csv.writer subpackage
[ https://issues.apache.org/jira/browse/SANDBOX-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg resolved SANDBOX-269. Resolution: Fixed The package has been removed. > Decide whether to keep the csv.writer subpackage > > > Key: SANDBOX-269 > URL: https://issues.apache.org/jira/browse/SANDBOX-269 > Project: Commons Sandbox > Issue Type: Task > Components: CSV >Reporter: Henri Yandell > Fix For: CSV 1.0 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANDBOX-283) CSVParser.nextValue() does not handle a CSV file with a single value correctly
[ https://issues.apache.org/jira/browse/SANDBOX-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg resolved SANDBOX-283. Resolution: Won't Fix CSVParser.nextValue() has been dropped following SANDBOX-220 discussions. > CSVParser.nextValue() does not handle a CSV file with a single value correctly > -- > > Key: SANDBOX-283 > URL: https://issues.apache.org/jira/browse/SANDBOX-283 > Project: Commons Sandbox > Issue Type: Bug > Components: CSV >Affects Versions: Nightly Builds >Reporter: Bob Smith >Priority: Minor > Attachments: CSVParser_SingleValueFix.patch > > > For a CSV file with a single value in it (like if your entire file is just > "test"), CSVParser.nextValue() returns null the first time it is called > instead of the value. > CSVParser.getLine() and CSVParser.getAllValues() do not value this problem. > The problem seems to be that getLine() has special handling for the "TT_EOF" > tokens that nextValue() does not have. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANDBOX-209) NullPointerException in CSVPrinter.print()/println()
[ https://issues.apache.org/jira/browse/SANDBOX-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg resolved SANDBOX-209. Resolution: Fixed I changed CSVPrinter.print() to handle null values as empty strings. I also removed the print method in CSVUtils that was writing the "null" string on null values. > NullPointerException in CSVPrinter.print()/println() > > > Key: SANDBOX-209 > URL: https://issues.apache.org/jira/browse/SANDBOX-209 > Project: Commons Sandbox > Issue Type: Bug > Components: CSV >Affects Versions: Nightly Builds >Reporter: Andriy Sholokh > Fix For: CSV 1.0 > > > If > public void print(String value) method of CSVPrinter class gets null > parameter it throws NullPointerException. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANDBOX-406) CSV Parser loops inifinitely if last line starts with a comment char
[
https://issues.apache.org/jira/browse/SANDBOX-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Bourg resolved SANDBOX-406.
Resolution: Duplicate
> CSV Parser loops inifinitely if last line starts with a comment char
>
>
> Key: SANDBOX-406
> URL: https://issues.apache.org/jira/browse/SANDBOX-406
> Project: Commons Sandbox
> Issue Type: Bug
> Components: CSV
>Reporter: Edgar Philipp
>
> Behaviour:
> Whenever the last non-empty line of the CSV file starts with a comment, the
> CSVParser loops infinitely!
> Examplary CSV file:
> {code}
> some
> # comment OK
> line
> # comment OK
> value
> # problematic comment
> {code}
> Excerpt of Java code:
> {code:java}
>private static final char COMMENT = '#';
>private static final char QUOTE = '"';
>private static final char SEPARATOR = ';';
>CSVStrategy csvStrategy = new CSVStrategy(SEPARATOR, QUOTE, COMMENT);
>CSVParser parser = new CSVParser(reader, csvStrategy);
>String[] line = parser.getLine();
>while (line != null) {
> Log.debug("Line: " + line[0]);
> // Do something
> line = parser.getLine();
>}
> {code}
> Used Maven Dependency:
> {code:xml}
>
> org.apache.solr
> solr-commons-csv
> 1.4.0
>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANDBOX-357) in CSVPrinter a null check is missing
[
https://issues.apache.org/jira/browse/SANDBOX-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Bourg resolved SANDBOX-357.
Resolution: Duplicate
> in CSVPrinter a null check is missing
> -
>
> Key: SANDBOX-357
> URL: https://issues.apache.org/jira/browse/SANDBOX-357
> Project: Commons Sandbox
> Issue Type: Bug
> Components: CSV
>Reporter: Odelya
>
> In CSVPrinter, there is the print method:
> public void print(String value) {
> boolean quote = false;
> if (value.length() > 0) {
> char c = value.charAt(0);
> if (newLine
> && (c < '0'
> you should do null check as well before the if (value.length)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANSELAN-40) Improve ICO file support
[ https://issues.apache.org/jira/browse/SANSELAN-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg resolved SANSELAN-40. Resolution: Fixed Fix Version/s: 1.0 > Improve ICO file support > > > Key: SANSELAN-40 > URL: https://issues.apache.org/jira/browse/SANSELAN-40 > Project: Commons Sanselan > Issue Type: Improvement > Environment: Sanselan, Java on any OS >Reporter: Damjan Jovanovic >Priority: Minor > Fix For: 1.0 > > Attachments: sanselan-better-ico.patch, sanselan-ico.patch > > Original Estimate: 0h > Remaining Estimate: 0h > > I am submitting a patch that improves Sanselan's ICO format support. It adds: > 1. Support for Windows Vista ICO files with embedded PNGs > 2. Support for 256x256 icons (reported as 0x0) > 3. Support for top-down and bottom-up bitmaps -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANSELAN-23) NullPointerException(Sanselan.java:323)
[ https://issues.apache.org/jira/browse/SANSELAN-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg resolved SANSELAN-23. Resolution: Fixed Fix Version/s: 1.0 > NullPointerException(Sanselan.java:323) > --- > > Key: SANSELAN-23 > URL: https://issues.apache.org/jira/browse/SANSELAN-23 > Project: Commons Sanselan > Issue Type: Bug >Reporter: Jon Weygandt > Fix For: 1.0 > > > Static code analysis reveals that IccProfileParser.getICCProfileInfo can > return a null value. > Sanselan.getICCProfile(line 323) uses info, which can be null, without > checking for the value. > There is a test case in Shindig, JPEGOptimizerTest.testBadICC4, where the ICC > count is too large. On some JVMs (like Sun) you get an OutOfMemory error, on > other like IBM null is returned from getICCProfileInfo, resulting in a NPE. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANSELAN-1) Initial code drop
[ https://issues.apache.org/jira/browse/SANSELAN-1?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg resolved SANSELAN-1. --- Resolution: Fixed Fix Version/s: 0.97 > Initial code drop > - > > Key: SANSELAN-1 > URL: https://issues.apache.org/jira/browse/SANSELAN-1 > Project: Commons Sanselan > Issue Type: New Feature >Reporter: Craig L Russell >Assignee: Carsten Ziegeler > Fix For: 0.97 > > Attachments: patch_init.zip > > > This issue is to discuss the initial code drop into the project. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANSELAN-39) Sanselan can be made to crash with an image with wrong data in EXIF header
[ https://issues.apache.org/jira/browse/SANSELAN-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg resolved SANSELAN-39. Resolution: Fixed Fix Version/s: 1.0 > Sanselan can be made to crash with an image with wrong data in EXIF header > -- > > Key: SANSELAN-39 > URL: https://issues.apache.org/jira/browse/SANSELAN-39 > Project: Commons Sanselan > Issue Type: Bug >Reporter: Jacobo Tarrio > Fix For: 1.0 > > > Investigating a query of death, I found an image that had an EXIF tag that > specified start=1342195485 and length=974913536. > When ByteSourceArray.getBlock(start,length) was called, it passed the test > "if (start + length > bytes.length)", as start+length is a negative number. > This caused the server to try to allocate a buffer 950 MB big and then save > it in "bytes" starting at position 1.3G. This produces either a heap space > exhaustion or an array out of bounds error. > The fix would consist of replacing the condition with one like the following: > if (start < 0 || length < 0 || start + length < 0 || start + length > > bytes.length) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANSELAN-24) ArrayIndexOutOfBoundsException with GIF
[
https://issues.apache.org/jira/browse/SANSELAN-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Bourg resolved SANSELAN-24.
Resolution: Fixed
Fix Version/s: 1.0
> ArrayIndexOutOfBoundsException with GIF
> ---
>
> Key: SANSELAN-24
> URL: https://issues.apache.org/jira/browse/SANSELAN-24
> Project: Commons Sanselan
> Issue Type: Bug
>Reporter: Holger Veltrup
> Fix For: 1.0
>
> Attachments: test.gif
>
>
> I try to get a BufferedImage:
> import java.io.File;
> import java.awt.image.BufferedImage;
> import org.apache.sanselan.Sanselan;
> public class BufferedImageTest {
> public static void main(String[] args) throws Exception {
> BufferedImage img = Sanselan.getBufferedImage(new File(args[0]));
> }
> }
> This throw a ArrayIndexOutOfBoundsException if I use a special gif (test.gif
> is attached)
> This GIF was created by PowerPoint
> Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 96000
>at
> org.apache.sanselan.formats.gif.GifImageParser.getBufferedImage(GifImageParser.java:795)
>at org.apache.sanselan.Sanselan.getBufferedImage(Sanselan.java:1264)
>at org.apache.sanselan.Sanselan.getBufferedImage(Sanselan.java:1231)
>at BufferedImageTest.main(BufferedImageTest.java:6)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANSELAN-34) FieldTypeASCII does not conform to the EXIF specification.
[ https://issues.apache.org/jira/browse/SANSELAN-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg resolved SANSELAN-34. Resolution: Fixed Fix Version/s: 1.0 > FieldTypeASCII does not conform to the EXIF specification. > -- > > Key: SANSELAN-34 > URL: https://issues.apache.org/jira/browse/SANSELAN-34 > Project: Commons Sanselan > Issue Type: Bug >Reporter: Libor Nenadál > Fix For: 1.0 > > > According to EXIF specification "2 = ASCII An 8-bit byte containing one 7-bit > ASCII code. The final byte is terminated with NULL." > Nevertheless the method FieldTypeASCII.getSimpleValue(TiffField entry) > returns the string that contains NULL character in the end which is wrong. > The NULL should not be included. For example try tag > TiffConstants.TIFF_TAG_DATE_TIME. > Found in Sanselan 0.97. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANDBOX-242) Encapsulated csv line strategy
[
https://issues.apache.org/jira/browse/SANDBOX-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Bourg resolved SANDBOX-242.
Resolution: Not A Problem
Fix Version/s: (was: CSV 1.x)
CSV 1.0
> Encapsulated csv line strategy
> --
>
> Key: SANDBOX-242
> URL: https://issues.apache.org/jira/browse/SANDBOX-242
> Project: Commons Sandbox
> Issue Type: Improvement
> Components: CSV
>Reporter: marc schipperheyn
>Priority: Minor
> Fix For: CSV 1.0
>
>
> I ran into this csv file :
> {code}
> ",""AD"",""ALV"",""Andorra la Vella"",""Andorra la
> Vella"",,""--34-6--"",""AI"",""0601"",,""4230N 00131E"","
> {code}
> It basically and weirdly encapsulates an entire line in " as a sort of record
> identifier and has double "" to identify values
> I'm having difficulty finding a tool that can parse this easily.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANDBOX-268) Offical Release
[ https://issues.apache.org/jira/browse/SANDBOX-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg resolved SANDBOX-268. Resolution: Not A Problem Closing this issue since releases can't be cut if issues are still open, and this issue can't be closed until the release is cut ;) Snapshots are available in the Apache repository, feel free to give it a try, your feedback can be valuable. https://repository.apache.org/content/groups/snapshots/org/apache/commons/commons-csv/ > Offical Release > --- > > Key: SANDBOX-268 > URL: https://issues.apache.org/jira/browse/SANDBOX-268 > Project: Commons Sandbox > Issue Type: Wish > Components: CSV >Reporter: Gunnar Wagenknecht > Fix For: CSV 1.0 > > > We want to consume Apache Commons CSV in [an Eclipse > project|http://www.eclipse.org/cloudfree]. In order to get approval for a > public 1.0 release we need official releases of all our dependencies. It > doesn't need to be a 1.0 release, though. > Anyway, our 1.0 release is not planned anytime soon. However, I want to reach > out to the CSV committers to get feedback on the project status and to offer > my help in support for an official CSV release. I'd also like to know if > there is a roadmap for CSV? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANDBOX-163) Create Strategy for RFC4180
[ https://issues.apache.org/jira/browse/SANDBOX-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg resolved SANDBOX-163. Resolution: Fixed Fix Version/s: (was: CSV 1.x) CSV 1.0 > Create Strategy for RFC4180 > --- > > Key: SANDBOX-163 > URL: https://issues.apache.org/jira/browse/SANDBOX-163 > Project: Commons Sandbox > Issue Type: Task > Components: CSV >Reporter: Henri Yandell > Fix For: CSV 1.0 > > Attachments: CSVescape.java > > > Support the CSV rfc: http://tools.ietf.org/html/rfc4180 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANDBOX-250) add a getter for input reader
[ https://issues.apache.org/jira/browse/SANDBOX-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg resolved SANDBOX-250. Resolution: Not A Problem Fix Version/s: (was: CSV 1.0) > add a getter for input reader > - > > Key: SANDBOX-250 > URL: https://issues.apache.org/jira/browse/SANDBOX-250 > Project: Commons Sandbox > Issue Type: Improvement > Components: CSV >Reporter: Chai Ang >Priority: Minor > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > I dont see a getter for the reader which is passed into the constructor. > I think it's needed for the ability to close the reader. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANDBOX-330) CSVParser hangs (goes into infinite loop) on getLine() if it's a "comment" line that doesn't contain a delimiter
[
https://issues.apache.org/jira/browse/SANDBOX-330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Bourg resolved SANDBOX-330.
Resolution: Cannot Reproduce
Fix Version/s: CSV 1.0
Thank you for the detailed report Toli. I ran your example against the current
trunk and it worked fine. Could you give it another try and reopen this issue
if it's not working for you?
> CSVParser hangs (goes into infinite loop) on getLine() if it's a "comment"
> line that doesn't contain a delimiter
>
>
> Key: SANDBOX-330
> URL: https://issues.apache.org/jira/browse/SANDBOX-330
> Project: Commons Sandbox
> Issue Type: Bug
> Components: CSV
>Affects Versions: Nightly Builds
>Reporter: Toli Kuznets
> Fix For: CSV 1.0
>
>
> if you call CSVParser.getLine() or nextToken() with a line that is a comment
> as defined by the CSVStrategy but it doesn't contain the delimiter character,
> the call hangs in an infinite loop
> This code will hang:
> {code}
> parser = new CSVParser(new StringReader("# abc\n"), new
> CSVStrategy('\t', '\'', '#'));
> tokens = parser.getLine();
> {code}
> However, if you insert a delimiter char into the incoming string, it'll come
> through and return an empty string as a result:
> {code}
> CSVParser parser = new CSVParser(new StringReader("#\tabc"), new
> CSVStrategy('\t', '\'', '#'));
> String[] tokens = parser.getLine();
> System.out.println("result: "+Arrays.toString(tokens));
> {code}
> It gets stuck in an infinite loop in CSVParser.nextToken() in the loop around
> line 347
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANDBOX-279) CSVStrategy has modifiable public static variables
[ https://issues.apache.org/jira/browse/SANDBOX-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg resolved SANDBOX-279. Resolution: Fixed Fix Version/s: CSV 1.0 The static fields are now final and the class is immutable. I followed the suggestion of Stephen Colebourne to use chained withXXX setters cloning the instance on the fly. > CSVStrategy has modifiable public static variables > -- > > Key: SANDBOX-279 > URL: https://issues.apache.org/jira/browse/SANDBOX-279 > Project: Commons Sandbox > Issue Type: Improvement > Components: CSV >Affects Versions: Nightly Builds >Reporter: Bob Smith >Priority: Minor > Fix For: CSV 1.0 > > Attachments: CSVStrategyAndTests.patch, CSVStrategy_Immutable.patch > > > The public static variables in CSVStrategy are not final and > DEFAULT_STRATEGY, EXCEL_STRATEGY, and TDF_STRATEGY can be modified using > setter methods. I would recommend making them all final and using an > unmodifiable subclass for the CSVStrategy variables. > For this change to work, the main CSVStrategy constructor would have to be > changed to set the class fields directly instead of using the setters since > the unmodifiable subclass will have overwritten all of the setters to thrown > UnsupportedOperationExceptions. And I think a copy constructor would also be > a good addition to allow easily copying one of these (or any) CSVStrategy > objects if any modifications have to be made to them (as an alternative to > the clone method). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SANDBOX-220) CSVParser.nextValue() seems pointless
[ https://issues.apache.org/jira/browse/SANDBOX-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg resolved SANDBOX-220. Resolution: Fixed > CSVParser.nextValue() seems pointless > - > > Key: SANDBOX-220 > URL: https://issues.apache.org/jira/browse/SANDBOX-220 > Project: Commons Sandbox > Issue Type: Bug > Components: CSV >Reporter: Henri Yandell > Fix For: CSV 1.0 > > > The nextValue method really doesn't seem very useful. There's no concept of > end of line, so your csv file could be 1xn or nx1 and you wouldn't know. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CONFIGURATION-467) Unable to persist CombinedConfiguration changes to the Filesystem.
[
https://issues.apache.org/jira/browse/CONFIGURATION-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Bourg resolved CONFIGURATION-467.
--
Resolution: Duplicate
> Unable to persist CombinedConfiguration changes to the Filesystem.
> --
>
> Key: CONFIGURATION-467
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-467
> Project: Commons Configuration
> Issue Type: Improvement
> Components: File reloading
>Affects Versions: 1.6
> Environment: Linux java
>Reporter: raghutpk
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> I use a config.xml file to load multiple Configuration Sources
> Ex:
> {code:xml}
>
>
>
>
>
>
>
>
>
> {code}
> I load the config.xml and subsequently all the properties in my app to a
> CombinedConfiguration Object as follows :
> {code:java}
> DefaultConfigurationBuilder builder = new DefaultConfigurationBuilder();
> builder.setFile(new File("config.xml"));
> CombinedConfiguration combinedConfig = builder.getConfiguration(true);
> {code}
> Now I am trying to expose all the properties from all configuration sources
> using a mbean and at runtime trying to update the Properties. I wouldn't know
> though, from which source the properties came from as the
> CombinedConfiguration takes care of that abstraction, but when I do the
> following it doesn't change the persistance store(in this case the files on
> the Filesystem).
> /*combinedConfig.setProperty(Key, updatedValue);*/
> There is no save method on the combinedConfiguration class so that the
> persistance store gets updated.
> There is a save method in PropertiesConfiguration class or XMLConfiguration
> class, but I wouldn't know at runtime or inside the code which file or
> configuration source the Key belongs to, so even If I add a config-name to
> each source there is no use.
> SO wouldn't the setProperty help me update the value of the Configuration and
> persist it back to the original file. I don't know it is a bug or a feature
> it doesn't support or there is a workaround in such scenarios.
> Please advice.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CONFIGURATION-466) Binary literals
[ https://issues.apache.org/jira/browse/CONFIGURATION-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg resolved CONFIGURATION-466. -- Resolution: Fixed > Binary literals > --- > > Key: CONFIGURATION-466 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-466 > Project: Commons Configuration > Issue Type: Improvement > Components: Type conversion >Reporter: Emmanuel Bourg >Assignee: Emmanuel Bourg >Priority: Minor > Fix For: 1.8 > > > Commons Configuration already knows how to read hexadecimal numbers starting > with 0x. It could also read binary numbers starting with 0b as introduced in > Java 7. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PROXY-16) (PROXY-15) mod_proxy in Apache HTTP 2.2 FIN_WAIT2 in server side, it leaves as CLOSE_WAIT for a long time in mod_proxy side.
[ https://issues.apache.org/jira/browse/PROXY-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg resolved PROXY-16. - Resolution: Invalid Still not the right place for this report ;) Please see : http://httpd.apache.org/bug_report.html > (PROXY-15) mod_proxy in Apache HTTP 2.2 FIN_WAIT2 in server side, it leaves > as CLOSE_WAIT for a long time in mod_proxy side. > > > Key: PROXY-16 > URL: https://issues.apache.org/jira/browse/PROXY-16 > Project: Commons Proxy > Issue Type: Bug >Reporter: Wendell L. Hatcher > > if mod_proxy, but during being FIN_WAIT2 in server side, it leaves as > CLOSE_WAIT for a long time in mod_proxy side. > This might be only a small bad effect for this phenomenon, but we think this > occurs because of not preferred implementation of Apache httpd mod_proxy. > Specifically, mod_prxoy sends FIN by KeepAliveTimeout from backend server > side. When it gets it, it returns using FIN and ACK, then wants to release > ports that is in use. > This is because of the following reasons: > *Keeping unnecessary resource for a long time, this might occur some > unexpected bugs in the future. > *If CLOSE_WAIT condition continues for a long time and then there is Firewall > between mod_proxy_http and backend, then you have to keep unnecessary session > and this might affect communication session. > *If there is FIN and ACK that after there is a long time gap, then it would > already be after Firewall destroys that session and Firewall might show > warning messages. > Also in mod_proxy in Apache 2.0, if client doesn't use KeepAlive, the > connection between mod_proxy and backend server ends, and confirms that > CLOSE_WAIT doesn't stays. In short, Apache 2.2 doesn't behave good than > Apache 2.0. > When we compare Apache 2.2 and 2.0 source, in Apache 2.0 mod_proxy, client > side TCP session extension of the ending process, it closes TCP session > between backend server using apr_socket_close() function. However, in Apache > 2.2 mod_proxy_http, it changes as to call connection_clceanup() or > socket_cleanup(), and we thiknk this is because it doesn't do > apr_socket_close() in the function. In short, 2.2 doesn't close the session > that is immediately close when KeepAlive is invalid. We assume that this is a > simple bug that forgets to close when mod_proxy's refactoring. > (1) Client is HTTP/1.0 and KeepAlive is none, so every time the connection > ends by FIN. > (2) mod_proxy_http doesn't disconnect after receiving the result of backend > server request. > (3) Backend server though FIN at 30.007sec by KeepAliveTimeout. > mod_proxy_http doesn't return FIN for this. > Port 47875 of mod_proxy_http becomes CLOSE_WAIT after this. > (4) New request reaches mod_proxy_http at 41.547sec and creating a different > new TCP section at 41.546sec. This is also throwing FIN and then > disconnecting it, but it's NOT disconnecting in the backend server side. > However, it's disconnecting from backend server side at 71,545, but > mod_proxy_http doesn't return FIN. After this, Port 47486 of mod_proxy_http > becomes CLOSE_WAI.T > (5) Client throws a new request to mod_proxy_http at 77.157sec. At this time, > at 77.159sec, mod_proxy_http thows FIN and ACK from the above # (3), port > 47485, then the first time that (3) session ends here. It took 47 seconds > until here, and if we compare it with KeepAliveTimeout that is set at the > backend server, there is a big gap. > We have done it a few times and found out the following: > a) mod_proxy_http uses KeepAlive between backend, although client doesn't use > KeepAlive. > b) Even if Backend send FIN by KeepAliveTimeout, mod_proxy_http doesn't > response and become CLOSE_WAIT. > c) mod_proxy_http becomes CLOSE_WAIT when a new request recives. > d) However, if a new request doesn't come then it never sends FIN to an old > connection and stays as CLOSE_WAIT forever. > We assume that b) and d) are not good behaviors for TCP/IP connections. > Already connection to client is disconnected; it doesn't depend on client's > KeepAlive behavior. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (PROXY-15) mod_proxy in Apache HTTP 2.2 FIN_WAIT2 in server side, it leaves as CLOSE_WAIT for a long time in mod_proxy side.
[ https://issues.apache.org/jira/browse/PROXY-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Emmanuel Bourg resolved PROXY-15. - Resolution: Invalid > mod_proxy in Apache HTTP 2.2 FIN_WAIT2 in server side, it leaves as > CLOSE_WAIT for a long time in mod_proxy side. > -- > > Key: PROXY-15 > URL: https://issues.apache.org/jira/browse/PROXY-15 > Project: Commons Proxy > Issue Type: Bug > Environment: Environment: > + ReverseProxy Server(proxy.example.jp) > - RedHat Enterprise Linux 5 (Occurred in HP-UX 11iV1) > - Apache HTTP server 2.0.63, 2.0.64(both are the same) > - httpd.conf related configuration > >Reporter: Wendell L. Hatcher >Priority: Minor > Labels: patch > > if mod_proxy, but during being FIN_WAIT2 in server side, it leaves as > CLOSE_WAIT for a long time in mod_proxy side. > This might be only a small bad effect for this phenomenon, but we think this > occurs because of not preferred implementation of Apache httpd mod_proxy. > Specifically, mod_prxoy sends FIN by KeepAliveTimeout from backend server > side. When it gets it, it returns using FIN and ACK, then wants to release > ports that is in use. > > This is because of the following reasons: > *Keeping unnecessary resource for a long time, this might occur some > unexpected bugs in the future. > *If CLOSE_WAIT condition continues for a long time and then there is Firewall > between mod_proxy_http and backend, then you have to keep unnecessary session > and this might affect communication session. > *If there is FIN and ACK that after there is a long time gap, then it would > already be after Firewall destroys that session and Firewall might show > warning messages. > > Also in mod_proxy in Apache 2.0, if client doesn't use KeepAlive, the > connection between mod_proxy and backend server ends, and confirms that > CLOSE_WAIT doesn't stays. In short, Apache 2.2 doesn't behave good than > Apache 2.0. > When we compare Apache 2.2 and 2.0 source, in Apache 2.0 mod_proxy, client > side TCP session extension of the ending process, it closes TCP session > between backend server using apr_socket_close() function. However, in Apache > 2.2 mod_proxy_http, it changes as to call connection_clceanup() or > socket_cleanup(), and we thiknk this is because it doesn't do > apr_socket_close() in the function. In short, 2.2 doesn't close the session > that is immediately close when KeepAlive is invalid. We assume that this is a > simple bug that forgets to close when mod_proxy's refactoring. > (1) Client is HTTP/1.0 and KeepAlive is none, so every time the connection > ends by FIN. > (2) mod_proxy_http doesn't disconnect after receiving the result of backend > server request. > (3) Backend server though FIN at 30.007sec by KeepAliveTimeout. > mod_proxy_http doesn't return FIN for this. > Port 47875 of mod_proxy_http becomes CLOSE_WAIT after this. > (4) New request reaches mod_proxy_http at 41.547sec and creating a different > new TCP section at 41.546sec. This is also throwing FIN and then > disconnecting it, but it's NOT disconnecting in the backend server side. > However, it's disconnecting from backend server side at 71,545, but > mod_proxy_http doesn't return FIN. After this, Port 47486 of mod_proxy_http > becomes CLOSE_WAI.T > (5) Client throws a new request to mod_proxy_http at 77.157sec. At this time, > at 77.159sec, mod_proxy_http thows FIN and ACK from the above # (3), port > 47485, then the first time that (3) session ends here. It took 47 seconds > until here, and if we compare it with KeepAliveTimeout that is set at the > backend server, there is a big gap. > > We have done it a few times and found out the following: > a) mod_proxy_http uses KeepAlive between backend, although client doesn't use > KeepAlive. > b) Even if Backend send FIN by KeepAliveTimeout, mod_proxy_http doesn't > response and become CLOSE_WAIT. > c) mod_proxy_http becomes CLOSE_WAIT when a new request recives. > d) However, if a new request doesn't come then it never sends FIN to an old > connection and stays as CLOSE_WAIT forever. > > We assume that b) and d) are not good behaviors for TCP/IP connections. > Already connection to client is disconnected; it doesn't depend on client's > KeepAlive behavior. > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
