You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I tried to parse an integer value, that had a comma delimiter, like '1,234' and faced a problem with conversion with locale.
fr.whimtrip.ext.jwhtscrapper.exception.ModelBindingException: Scrap failed with exception Cannot parse field fiveStarsCount.class com.service.parser.pojo.ProductPojo with value 1,626 and locale: us.
at fr.whimtrip.ext.jwhthtmltopojo.adapter.AbstractHtmlFieldImpl.instanceForNode(AbstractHtmlFieldImpl.java:201) ~[whimtrip-ext-htmltopojo-1.0.2.jar:na]
So, we need to respect locale while conversion number values, because currently an example like this
@Selector(
value = ".example ",
locale = 'US',
returnDefValueOnThrow = false
)
public Integer fiveStarsCount;
can't be correctly casted. To use locale during number conversion we need to use method like this Number number = NumberFormat.getIntegerInstance(Locale.US).parse('123,45');
This is default realiztaion of conversion at castValue in HtmlToPojoUtils
Sorry for the very late reply, I'm not using this account very often now...
I think the issue is because you should use a Float here because Integer.valueOf("1,65") would fail anyway.
I think I should have added the locale to those numbers parsing as well, unfortunately, I didn't so a the moment, there is no quick fix...
Or probably the solution you highlighted would have been more resilient...
I tried to parse an integer value, that had a comma delimiter, like '1,234' and faced a problem with conversion with locale.
So, we need to respect locale while conversion number values, because currently an example like this
can't be correctly casted. To use locale during number conversion we need to use method like this
Number number = NumberFormat.getIntegerInstance(Locale.US).parse('123,45');
This is default realiztaion of conversion at castValue in HtmlToPojoUtils
My question is - can we solve this problem without using custom deserializer? Because currently this problem is in each of hundreds of Integer fields
The text was updated successfully, but these errors were encountered: