When will the validators be invoked on an instance?

rburton · **Joined:** Mon Mar 31, 2008 12:05 pm **Posts:** 11

From what I understand after reading the specification, the following are the conditions in which trigger validation on a given instance.

1. If the class has a field, method or type decorated with one or more "Validation Annotations" that meets the requirements described below at the end of this message.
2. If the any interface that a class implements has a method or any of its extended interfaces is decorated with one or more "Validation Annotations".
3. If the super class that meets the use case described in the first item are met.

=========================================
What makes an Annotation a "Validation Annotation"
=========================================

An annotation that’s in turn annotated with in turn with the javax.validation.ConstraintValidator annotation as described in (Section 2.1 "Constraint Annotation") or the "value" property contains an array of Annotations that are decorated with javax.validation.ConstraintValidator (Section 2.2 "Multi-Valued Constraints").

Is this correct?

Best Regards,
Richard L. Burton III

emmanuel · **Posted:** Thu Apr 03, 2008 2:05 pm

Almost
What triggers the validation is a call to validator.validate(object)
What is taken care of when such a call is made is what you describe (if we exclude the idea of @Valid)

Note that a validator instance is dedicated to a given object type (Address for example).

rburton · **Joined:** Mon Mar 31, 2008 12:05 pm **Posts:** 11

So taking a worked example where my constraints vary based upon the context that I'm validating against, I would need to define a 'group' of constraints for the properties that I wish to validate at that time?

E.g., my class level annotations would have something on the lines of..

class Address{

@NotNull(groups={"signup"})
@Length(max=100, groups={"contract"})
// and so on...
private String state;
}

and in the location I intend to do the validation, I would invoke the validator and provide it the group(s) I want to validate? This to me seems a little hard to maintain since the validation 'group' will span multiple objects at various levels.

In such a case, it would be easier to provide a Constraints object that I could configure for a given instance.

This leads me to go back to my initial concern that managing the context using the 'groups' attribute seems to be problematic and people will start reverting back to the old way of doing validation.

Best regards,
Richard L. Burton III

emmanuel · **Posted:** Thu Apr 03, 2008 2:54 pm

rburton wrote:

So taking a worked example where my constraints vary based upon the context that I'm validating against, I would need to define a 'group' of constraints for the properties that I wish to validate at that time?

E.g., my class level annotations would have something on the lines of..

class Address{

@NotNull(groups={"signup"})
@Length(max=100, groups={"contract"})
// and so on...
private String state;
}

and in the location I intend to do the validation, I would invoke the validator and provide it the group(s) I want to validate?

you are correct, except that in your example, there is no reason for @NotNull and @Length to be split into different use cases. It would be nice to come up with more advanced use cases.

But let's imagine for some reason they are split. I think in this case I would do

Code:

class Address{

     @NotNull(groups={"signup", "default"})
     @Length(max=100, groups={"contract", "default"})
     // and so on...
     private String state;
}

Because in most default cases I want to apply both (ie before the entity is saved by JPA)

Quote:

This to me seems a little hard to maintain since the validation 'group' will span multiple objects at various levels.

In such a case, it would be easier to provide a Constraints object that I could configure for a given instance.

I don't fully follow you. Can you detail your proposal?

Quote:

This leads me to go back to my initial concern that managing the context using the 'groups' attribute seems to be problematic and people will start reverting back to the old way of doing validation.

I don't yet understand why you find that problematic, surely it's easier than the old way (whatever the old way is).

rburton · **Joined:** Mon Mar 31, 2008 12:05 pm **Posts:** 11

Please understand, I'm not bashing the JSR and I'm all for a standard. Yes, the old way was a mess :)

When you're talking about JPA, its a narrow focus and works extremely well. Let's focus on validation in a web environment. In such a case, validation varies based upon the context that an object is being validated. E.g., Address.

In some cases, we could reuse the Address object, but we only want to validate certain properties and the validation could just as well vary. Constraints vs Validation are very similar but two different animals. In the example you provided, you focused on constraints of the underlaying data store.

What's your view with JSR 303 in terms of a web application? How do you see it being used in a web application such as a wizard.

I'm not trying to be the guy that sits in the back seat and yells out "That's dumb what if I wanted to do..." so please excuse me if I come off harass or ignorant.

Best Regards,
Richard L. Burton III

emmanuel · **Posted:** Thu Apr 03, 2008 7:04 pm

you are not harassing me, not yet :)

Group is intended to solve the wizard issue. I will do a blog entry on it probably early next week, maybe we should hold on the discussion till I blog about it to have a more user friendly background.

If groups does not solve the problem well enough, then we will have to find something better.