IntegerValidator does not default to "Entry was not a valid number" if the
entry does not contain a valid number.
-----------------------------------------------------------------------------------------------------------------
Key: TRB-74
URL: https://issues.apache.org/jira/browse/TRB-74
Project: Turbine
Issue Type: Bug
Components: Core
Affects Versions: Core 2.3.3
Environment: Linux OS running turbine 2.3.3 & tomcat
Reporter: Susi Berrington
Priority: Minor
We are using intake for our validation where possible and recently noticed that
if the intake.xml file specifies a field with type="int" and doesn't specify an
"invalidNumber" rule, i.e.:
<group name="Config" key="ConfigKey" mapToObject="data.details.ConfigDetails">
<field name="Field" key="field" type="int" mapToProperty="Field">
<rule name="minValue" value="0">Please enter a value between 0
and 100</rule>
<rule name="maxValue" value="100">Please enter a value between
0 and 100</rule>
</field>
</group>
then there is no error message displayed when you call
$intake.Config.Default.Field.Message. This is because this error message is
only set in the org.apache.turbine.services.intake.validator.IntegerValidator
constructor that takes a Map and the
org.apache.turbine.services.intake.model.Field class which is creating the
IntegerValidator calls the default constructor.
I notice that in 2.4 M1 javadoc this whole section of code is deprecated in
favour of package org.apache.fulcrum.intake.validator.IntegerValidator, etc.
but looking at that source code the defect is still in there too.
I've written this as a minor defect as the work around is to add the
"invalidNumber" to the field's rules but this isn't a preferred long term
solution.
I think the best solution would be to initialize invalidNumberMessage to "Entry
was not a valid number" in NumberValidator as a safety net. Then if any
overriding class doesn't create their own default error message at least there
would be a generic one set. And then in IntegerValidator, LongValidator, etc.
either get both constructors to set a default message for invalidNumberMessage
or try removing the default constructor and see if all the places which call
the default constructor could call the other constructor?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.