[
https://issues.apache.org/jira/browse/TRB-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14220813#comment-14220813
]
Tilo Villwock commented on TRB-94:
----------------------------------
I would propose the following patch to remedy this issue:
--- BigDecimalValidator.java.orig 2014-11-21 12:23:48.169990593 +0100
+++ BigDecimalValidator.java 2014-11-21 12:30:26.140718553 +0100
@@ -22,6 +22,7 @@
import java.math.BigDecimal;
import java.text.NumberFormat;
import java.text.ParseException;
+import java.text.ParsePosition;
import java.util.Locale;
import java.util.Map;
@@ -150,7 +151,11 @@
NumberFormat nf = NumberFormat.getInstance(locale);
try
{
- Number number = nf.parse(testValue);
+
+ ParsePosition pos = new ParsePosition(0);
+ Number number = nf.parse(testValue, pos);
+ if (pos.getIndex() != testValue.length())
+ throw new ParseException(null, 0);
bd = new BigDecimal(number.doubleValue());
}
catch (ParseException e)
> Intake's BigDecimalValidator and the BaseValueParser don't parse inputs the
> same way
> ------------------------------------------------------------------------------------
>
> Key: TRB-94
> URL: https://issues.apache.org/jira/browse/TRB-94
> Project: Turbine
> Issue Type: Bug
> Components: Turbine 2.3
> Affects Versions: Core 2.3.3
> Reporter: Tilo Villwock
>
> Hello,
> I don't know if this is still the case in the current development version but
> the BigDecimalValidator does not check whether the parsed value has the same
> length as the original input while the BaseValueParser does. This leads to
> unexpected behavior because while a String like "3.21a" passes the validation
> test it will not get set because the parsed length is not alike. One would
> expect that the user will get notified by a message that this is not a valid
> number.
> The relevant lines are:
> org.apache.turbine.services.intake.validator.parser.BigDecimalParser: 149
> org.apache.turbine.util.parser.BaseValueParser: 653-668
> Tilo
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
