Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: Release 1.5
-
Fix Version/s: Release 1.5.1, Release 1.6
-
Component/s: Validation
-
Labels:None
-
Environment:SuSE 11.0, Tomcat 6.0.18, JDK 1.6.0_07
Description
In 1.5 configured default type converters take presidence over the @Validate(converter).
I believe this to be the wrong behavior, I think if you are explicit in the Validate method then you should use that converter over what the default is.
EX:
In your stripes package you create:
public class StringEscapeTypeConverter extends StringTypeConverter implements TypeConverter<String>
We do this because we want the default case to be secure and escape html and javascript syntax for every string entered into the site.
However, in a few cases you don't want to do this, say for password creation. So in that case we do a:
@Validate(field = "password", converter=StringTypeConverter.class)
In 1.4 this would pick up StringTypeConverter for password, in 1.5 this picks up StringEscapeTypeConverter.
The issue is in DefaultActionBeanPropertyBinder.convert(....) :
converter = factory.getTypeConverter(declaredType, locale);
if (validationInfo != null && validationInfo.converter() != null) {
// If a specific converter was requested and it's the same type as one we'd use
// for the delcared type, set the return type appropriately
if (converter != null && validationInfo.converter().isAssignableFrom(converter.getClass())) {
returnType = declaredType;
}
// Otherwise assume that it's a converter for the scalar type inside a collection
else {
converter = factory.getInstance(validationInfo.converter(), locale);
returnType = scalarType;
}
}
Which I think should be:
converter = factory.getTypeConverter(declaredType, locale);
if (validationInfo != null && validationInfo.converter() != null) {
// Always use validationInfo.converter if it exists
converter = factory.getInstance(validationInfo.converter(), locale);
// If a specific converter was requested and it's the same type as one we'd use
// for the delcared type, set the return type appropriately
if (converter != null && validationInfo.converter().isAssignableFrom(converter.getClass())) { returnType = declaredType; } }
// Otherwise assume that it's a converter for the scalar type inside a collection
else {
returnType = scalarType;
}
}
Fixed in build 963 (branches/1.5.x) and build 964 (trunk).
Jacob, thanks for reporting this issue. The problem occurs as you described, but only when your custom type converter extends a stock type converter (StringTypeConverter for example). Therefore, if you cannot for some reason use the snapshot version of Stripes that has the fix for this issue, you can, in the meantime, work around by having StringEscapeTypeConverter implement TypeConverter<String> but /not/ extend StringTypeConverter.