Activity for Andrew Rucker Jones
-
Andrew Rucker Jones posted a comment on ticket #124
No, BeanVerifier is not meant to support multiple errors in the same row. As far as the implementation goes, BeanVerifier throws an exception if anything is wrong, which interrupts the normal flow of the program. It would be difficult to make that work for multiple errors in one row. Conceptually, I decided not to provide for the case of multiple errors per row because I figured if there was one error, it might create other errors by its mere existence. I'm thinking of programming in compiled languages...
-
Print header separately
-
Nope. I went back and checked the code, or rather my javadoc, to refresh my memory. The reason an actual bean is necessary is because of the joining and splitting functionality we added a few years ago. Any fields joined on reading and split on writing are represented as a MultiValuedMap, with the exact column names in the index of the map. These names, as in the documented example, might be "Track1," "Track2," "Track3," and so on. These column names do not exist in the class. They only exist in...
-
Automaticaly sorting columns on HeaderColumnNameMappingStrategy
-
I just had a chance to read this. I had only half-understood it while scanning over the ticket early in the morning when I got up two weeks ago. I agree with Scott; this is a pretty good solution, and I can't think of a better way to do this with the built-in functionality of opencsv if you are determined to keep ordering information solely in the annotations. Well done.
-
CsvNumber - rounding mode
-
Version 5.9 has been released with this feature.
-
Spaces in Header and CsvBindByName.required
-
Recording input CSV record line number in the mapped bean
-
Caching and reusing HeaderColumnNameMappingStrategy instances
-
required column names
-
Closed for lack of activity.
-
What would you suggest we update to? 4.4 is still the newest version. I'm also familiar with security problems with 4.3, but not 4.4.
-
Has this change been released?
-
This ticket can be closed, can it not? The changes are not listed on the project wiki's "What's new" page, but we have released since this was done.
-
@sconway This one is really directed at you. The all-caps thing was there when I arrived, and I recall you having a reason for it.
-
Error message don't use errorLocale
-
This fix was released with version 5.8 in July. Sorry I didn't update the ticket.
-
CsvNumber - rounding mode
-
This is implemented and will go out with the next release.
-
What's new
-
Support request #122: support for specifying the rounding strategy when formatting decimals.
-
Updated dependencies.
-
I think both of my questions might be irrelevant. I simply pass the rounding mode to DecimalFormat, and what it uses that for isn't that important to me. I've written a test for writing BigDecimals to a CSV output to make certain the rounding mode arrives where it's supposed to be and is applied as advertised, and that test passes.
-
And one more little question: we're only talkig about BigDecimal, right? I don't see RoundingMode being used anywhere else.
-
Actually, it's not hard at all, I think. I'm working on it. Quick question, though, since I have rarely had the pleasure of rounding numbers: are we talking about while reading or writing CSV files?
-
Eh, not exactly. If you want, you can instantiate a mapping strategy yourself, pass it in to CsvToBeanBuilder.withMappingStrategy(), and keep a reference to it. Theoretically, you could use it again, though I don't think it's made for doing that. We haven't tested reuse for reading. (Writing works fine because writing is rather a different beast anyway.) If nothing else, I'm sure the line numbers will be all off in any error messages you get. It wouldn't surprise me if other things break as well....
-
I'm the guy who wrote this code, but I'm no longer really with the project. I wanted to provide my thoughts. The project lead, Scott Conway, will have to work through the possibilities. Naturally, if the machine is so swamped it shows no signs of life, that's a problem. In no way do I wish to deny or trivialize that issue. My first thought is that there is nothing unique about a process that takes all available CPU time. Really, there's almost nothing wrong with it, either: a computer's resources...
-
I have tested opencsv with Java 8 through 19. No problems.
-
Nested bean returned with null values for all the fields if the input csv does not have values for nested bean
-
This is by design. Just as you receive an empty bean at the top level if you input an empty line to a bean with entirely optional fields, you received empty sub-beans if all of the fields that are supposed to fill the bean are empty. https://sourceforge.net/p/opencsv/support-requests/110/
-
Please read the Javadoc for CsvNumber. There are only four parameters, and they all relate to this question.
-
Parsing numbers with @CsvNumber
-
This is as expected: 1. Your format string is incorrect. Try something like "#,##0.##" 2. java.text.DecimalFormat, which opencsv uses for parsing numbers, does not throw an exception. It simply stops parsing as soon as it hits a character it does not understand.
-
I admit, when I was recently adjusting the opencsv tests to work with Java 17, this information would have been helpful, yet somehow, I failed to see that. It would not make sense to put the column number in CsvException. Too many usages and subclasses of CsvException would never use it. Something farther down, such as CsvFieldAssignmentException or perhaps a new intermediate class in the hierarchy, would provide more fine-tuned use of the field for only the situations that need it. I am no longer...
-
Cell Number in CsvException
-
Cell Number in CsvException
-
What do you consider to be the cell number? Do you mean the column number?
-
Please read the discussion from October 27, 2020. This solution does not respect the difference between a line and a record.
-
Update commons-collections
-
Updated dependencies.
-
Use @CsvBindByName and @CsvCustomBindByName simultaniously
-
Closed for lack of activity.
-
Closed for lack of activity.
-
Value BigDecimal
-
Do we need to keep this open? We update to the latest version of all libraries we use ahead of every release anyway.
-
I'm simply delighted about that, and I merged your changes instantly (and gave you credit on our "What's New?" page, of course!). The fixes will be released with the next version of opencsv.
-
What's new
-
Thanks so much, Pierrick!
-
Fix French translations
-
Scott's been doing a great job of helping you so far, but I wanted to add a little something about the reasoning for doing it the way we did it. It's essentially for the same reason we return an empty bean for an empty line. The line is there, just without data. The bean is nothing more than a vessel. If you want to know about the data, you will have to check the bean fields. Similar to the way some programmers treat getters that return a List: if the field is null, an empty List is created for the...
-
You were on the right track with the profiles. I would suggest adding a member field for every different possibility and annotating them separately, such as: @CsvBindByName(column = "Language", profiles = "Source2") private int languageId; @CsvBindByName(column = "idLanguage", profiles = "Source1") private String language; That way, opencsv still does all of the parsing and converting. Then, add whatever you need to the setters, such as: public void setLanguageId(int languageId) { this.language =...
-
One csv column into multiple bean fields with custom converter
-
I'm delighted to know that helped. Should I close this ticket, or do you need more assistance?
-
One csv column into multiple bean fields with custom converter
-
I'm not trying to be a jerk, but I truly don't understand what you're trying to do, so it's hard to answer your question. Based on the subject line, I might ask if you've considered adding code to the setter for the ID field that does the work of distributing the information throughout the bean as necessary.
-
Use @CsvBindByName and @CsvCustomBindByName simultaniously
-
You can't. I'm unclear on what you're trying to accomplish. What is your use case?
-
Updates to tests and dependencies for Java 18 and 19.
-
Thanks, but I really meant the entire set of language resource files. It's fine if you're not willing to do that. It just sounded like you might already have it.
-
What's new
-
Error message don't use errorLocale
-
Thanks for spotting this. I've fixed it in the repository, and the fix will be in the next release. Incidentally, if you have a translation you're willing to donate, we'd love to have it.
-
Bug #237: errorLocale not used in ConverterEnum and ConverterCurrency.
-
Value BigDecimal
-
This is neither an error, nor is it rounding. To demonstrate the last: if you change the input string to "81A88.32" you will get 81 as the parsing result. As for it not being an error, this is simply how the JDK's NumberFormat/DecimalFormat classes work. The JDK documentation is less than exemplary in making this clear; they state only (multiple times) that not all of the input string is necessarily consummed during parsing and that parsing only uses all digits recognized as such by Unicode and the...
-
Does not translate message correctly when field is Date
-
I'm glad you were able to find a solution to your problem!
-
Does not translate message correctly when field is Date
-
First of all, let me just say I'm terribly pleased you're using the translated error messages. I was the one who programmed them (I feel it's only right, and I needed translations for a project I was working on), but I've always felt I'm the only one with any interest in them. As to your specific problem, there is nothing we can do about that. That error message comes from the JDK, not us, and as far as I know, the JDK does not provide translations of its error messages. If I'm wrong about that,...
-
OpenCsv column size validation
-
It looks as though you're picking up the wrong constructor. There is: CsvConstraintViolationException(Object) and CsvConstraintViolationException(String) You want the second, but you seem to be getting the first. Try casting: new CsvConstraintViolationException((String) "Your error message here.") If I were you, I would use the double-argument constructor: new CsvConstraintViolationException(inputText, "Your error message here.") It is intended to be the most helpful for debugging anyway.
-
OpenCsv column size validation
-
Please look at the Javadoc for: CsvCustomBindByName or CsvCustomBindByPosition and AbstractBeanField You would override AbstractBeanField.convert() and throw a CsvConstraintViolationException if the string is longer than 100 characters.
-
apache commons dependency security bug
-
We just released version 5.7.1 to address the Commons Text vulnerability. As for the Commons Collections vulnerability, we use Commons Collections 4.4 and have for a long time. The problem is BeanUtils, which still has not upgraded from Commons Collections 3. Our code does not use the vulnerable Commons Collections. See https://sourceforge.net/p/opencsv/feature-requests/154/
-
I am no longer actively developing in the project.
-
How to apply custom converter when you can't annotate the bean?
-
I am no longer actively developing in the project.
-
Allow annotations to be used on methods (getters?)
-
I am now longer actively developing in the project.
-
Open CSV 4.1 EOL/EOS Dates
-
We only ever support the most recent version. We are a very small project with no resources to support multiple versions. The latest version should work fine with Java 17. Earlier versions have.
-
Upgrade org.apache.commons:commons-text to v1.10.0
-
See source merge request #34.
-
Don't have a schedule yet. Please note: opencsv does not use the vulnerable code. A release that includes the newer version of Commons Text is only so static vulnerability scanners stop throwing false positives.
-
Update commons-text to 1.10.0 to fix CVE-2022-42889
-
Closed as a duplicate. Please see source merge request #34.
-
Upgrade apache commons-text to 1.10
-
See source merge request #34.
-
CVE-2022-42889 - opencsv dependency on Apache Commons Text Library dependency
-
CVE-2022-42889 - opencsv dependency on Apache Commons Text Library dependency
-
Closed as duplicate. Please see source merge request #34.
1 >