camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charles Moulliard <ch0...@gmail.com>
Subject Re: Re: Camel Bindy: parse a BigDecimal number with a given pattern
Date Thu, 21 Aug 2014 07:32:46 GMT
For your information, the "pattern" is not relevant when we use
BigDecimalFormat or DoubleFormat.
My idea is to propose to add an attribute to specify the groupSeparator and
replace the separator by empty string ""

Example: We get 123,456,999.00 --> we transform to 125456999.00 before to
create the BigDecimal

Remark : I will have a look as we have also added an attribute
"impliedDecimalSeparator" which is used like that when we create the
BigDecimal. But I think that it is used for FixLength Format and a
different purpose

        BigDecimal result = new BigDecimal(string.trim());
        if (super.hasImpliedDecimalPosition()) {
            result = result.divide(new BigDecimal(super.getMultiplier()),
super.getPrecision(), RoundingMode.HALF_EVEN);
        }




On Thu, Aug 21, 2014 at 8:33 AM, Charles Moulliard <ch007m@gmail.com> wrote:

> Hi,
>
> The AbstractNumberFormat class of Bindy used by Double & BigDecimal uses
> the property GroupingUsed(false) but there is no attribute defined with the
> @DataField annotation to manage group. Can you raise a ticket please so I
> will work on that tomorrow and rediscover the Bindy project that I created
> some years ago now ;-) ?
>
>     public AbstractNumberFormat(boolean impliedDecimalPosition, int
> precision, Locale locale) {
>         this.impliedDecimalPosition = impliedDecimalPosition;
>         this.precision = precision > 0 ? precision : 0;
>         this.format = null;
>         this.multiplier = 1;
>
>         this.format = new DecimalFormat();
>         this.format.setGroupingUsed(false); // SET TO FALSE
>
> Regards,
>
>
>
>
> On Wed, Aug 20, 2014 at 8:39 PM, <a_blithe@web.de> wrote:
>
>> The numbers I'd like to parse could have one the following structures:
>> 123,456,789.01
>> 123.45
>> -1234
>> 1,234
>>
>> (there are several rows in one file so it is possible that different
>> structures appear in a file)
>>
>> Setting the precision already works fine and the decimal separator is
>> treated correctly.
>> The current problem is that I can't tell bindy to ignore the comma sings
>> in every number,
>> because they are for grouping purposes and not needed in the BigDecimal
>> field.
>>
>> If I keep the comma sign in these numbers the parsing process will raise
>> a NumberFormatException
>> mentioning a malformed number. If I remove that comma signs in a test
>> file, everything works fine and the number
>> is mapped to the datafield correctly, but sadly that can't be a solution,
>> because this csv files are provided by
>> different system that cannot be changed.
>>
>> If I use the following annotation
>> @DataField(pos = 2, precision = 2, pattern = "#,###.##")
>> and use Double instead of BigDecimal I can keep the comma sings. But I
>> can't use Double for several reasons.
>>
>> The source code of the FormatFactory class (version 2.13.1) that I linked
>> in my question also shows that the pattern is used for Double types (and
>> several other types) but not for BigDecimal types.
>>
>> -----Urspr√ľngliche Nachricht-----
>> Gesendet: Wednesday, 20 August 2014 um 19:33:05 Uhr
>> Von: "Charles Moulliard" <ch007m@gmail.com>
>> An: users@camel.apache.org
>> Betreff: Re: Camel Bindy: parse a BigDecimal number with a given pattern
>> The @DataField of Camel bindy proposes the parameter precision like also a
>> pattern but not a grouping separator
>>
>> Example
>>
>>     @DataField(pos = 2, precision = 2, pattern = "00.00")
>>     private BigDecimal bigDecimal;
>>
>> Do you have an example to propose about such use case ?
>>
>>
>> On Wed, Aug 20, 2014 at 3:43 PM, <a_blithe@web.de> wrote:
>>
>> > Hello,
>> >
>> > I currently have a problem concerning Camel Bindy. I have a csv file
>> that
>> > should be parsed with Camel Bindy using a given model class. This csv
>> file
>> > contains a number that should be parsed as a BigDecimal. The problem is
>> > that
>> > this number contains a comma as a grouping separator and a point as the
>> > decimal separator.
>> > If I start the camel route the unmarshal process will throw a
>> > NumberFormatException mentioning the invalid format of that number. So I
>> > tried to add a pattern to the DataField annotation, but the error stays.
>> >
>> > After digging throw the documentation (
>> http://camel.apache.org/bindy.html)
>> > and the source code of FormatFactory
>> > (
>> >
>> http://grepcode.com/file_/repo1.maven.org/maven2/org.apache.camel/camel-bindy/2.13.1/org/apache/camel/dataformat/bindy/FormatFactory.java/?v=source
>> > )
>> > I'm a little bit confused, because the documentation mentions the
>> ability
>> > to
>> > specify a grouping separator, but the source code shows that the
>> pattern is
>> > ignored for BigDecimal data types.
>> >
>> > Does anyone know how to specify that grouping separator? Or is this not
>> > implemented yet?
>> >
>> > Many thanks in advance.
>> >
>> > Best regards.
>> > Tom
>> >
>> > P.S. I also posted that question on stackoverflow
>> > (
>> >
>> http://stackoverflow.com/questions/25381052/camel-bindy-add-pattern-for-bigdecimal-type
>> > ),
>> > but with no luck yet.
>> >
>> > P.P.S. I posted that question using nabble.com (
>> > http://camel.465427.n5.nabble.com/Camel-Users-f465428.html) some
>> moments
>> > ago, but it seems that there is a problem with my mail provider that
>> > doesn't allow services like this. So I'm sending this question directly
>> > now. Sorry for any inconveniences.
>> >
>>
>>
>>
>> --
>> Charles Moulliard
>> Apache Committer / Architect @RedHat
>> Twitter : @cmoulliard | Blog :  http://cmoulliard.github.io
>>
>
>
>
> --
> Charles Moulliard
> Apache Committer / Architect @RedHat
> Twitter : @cmoulliard | Blog :  http://cmoulliard.github.io
>
>


-- 
Charles Moulliard
Apache Committer / Architect @RedHat
Twitter : @cmoulliard | Blog :  http://cmoulliard.github.io

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message