For example, consider a bean CostUnit that should have a unique Id.
Cost units are managed by a CostUnitManager, which knows about all used Ids.

So, to implement the uniqueness check for the CostUnit id,
the corresponding ConstraintValidator needs a reference to the CostUnitManager instance
(in addition to the cost unit instance).

How to pass such additional objects to a JSR303 Bean Validator?

Thanks,
Holger

Hi,

I guess in your case you could use a custom ConstraintValidatorFactory. The default factory uses the public no-arg constructor to instantiate a validator implementation. Using a custom factory you can use other means to instantiate the validator. For example you could inject a CostUnitManager via dependency injection. You can determine which factory is used via the Configuration object, eg



See also section 2.5 of the specification.

--Hardy

Thanks for the info, Hardy.

Assuming that major DI containers like Spring will integrate with JSR303 and provide their own ConstraintValidatorFactory, this appears to be a clean solution.

It gets more complicated, if you need to inject non-singleton-scoped beans.
In the example above, the CostUnitManager could be scoped to a particular customer.
If another customer is loaded by the client, another CostUnitManager instance gets relevant and needs to be provided to the ConstraintValidator.
In this case, either you would have to implement and apply a custom scope in Spring or do the injection manually by providing a self-made ConstraintValidatorFactory and recreating the ConstraintValidator for a different customer.
For the latter way, it could be problematic that ConstraintValidators may be cached:
From section 2.4:
"The life cycle of a constraint validation implementation instance is undefined. Compliant implementations are allowed to cache ConstraintValidator instances retrieved from the ConstraintValidatorFactory"

Holger

i agree with this...this is almost an absolute necessity on any series of validation rules. sometimes it's simply not practical to re-lookup stuff in each rule/constraint. i've already run into the prospect of doing a db lookup across a large selection of items in a few different circumstances. these really should be different constraints, but i have to implement them as a single validator to make it performant, resolving that a few bean properties do not occur across this large selection of other beans. another good example of this might be user-specific validation, validating with the bean and the user in the validators.

another thing i've found is the need to customize metadata associated with a constraint violation. in most cases, i've been able to accomplish it by adding to my annotations.

there should be a validation heap/stack available to the validators, something like a map of anything you like, which can be looked up by name added to, subtracted from in the validators. additionally, i think someone suggested that the message template/raw message be converted to an object from a string.

i'd also like to see some kind of conversion of property to user-readable property name. it's common to add context to error messages such that if property X is causing the constraint violation, you need to add a user-readable, internationalized property as part of the message.
eg. message={user-friendly property name} is null.
for what should be generic messages, i've found us overriding every generic message that the annotations have.

...just got Beta2 and saw that it had some really good improvements.