Hi,
I think you are wrong.
metaConstraint.getPropertyName() might be confusing though. It does not mean that we compare against the getter name. What the
MetaConstraint stores is the JavaBean name of the constraint field or property. For a field it is the field name for a property (getter) is the name of the method with 'get' resp. 'is' stripped off.
I would assume that JSF is passing
accountNumber to
validateProperty and there is no constraint defined on the method nor is there a field with that name. Really JSF would have to pass '_accountNumber'.
I added a test to our codebase which shows that Validator really does not care that the field name and getter do not match.
Code:
class NotFollowingJavaBeanNotation {
@NotNull
String m_foo;
public String getFoo() {
return m_foo;
}
}
Code:
@Test
public void testConstraintDefinedOnEntityNotFollowingBeanNotation() {
CountValidationCallsValidator.init();
Set<ConstraintViolation<NotFollowingJavaBeanNotation>> constraintViolations = getValidator().validate( new NotFollowingJavaBeanNotation() );
// validating the whole entity - ok
assertNumberOfViolations( constraintViolations, 1 );
assertCorrectConstraintTypes( constraintViolations, NotNull.class );
// using validateProperty (which is used by JSF) to validate explicitly using the field name
constraintViolations = getValidator().validateProperty( new NotFollowingJavaBeanNotation(), "m_foo" );
assertNumberOfViolations( constraintViolations, 1 );
assertCorrectConstraintTypes( constraintViolations, NotNull.class );
// using validateProperty (which is used by JSF) to validate explicitly (no violation, because there is no
// property foo Validator knows about
constraintViolations = getValidator().validateProperty( new NotFollowingJavaBeanNotation(), "foo" );
assertNumberOfViolations( constraintViolations, 0 );
}
I don't think there is a Validator issue here. WDYT?
--Hardy
Login
FAQ
Search
