> Can you give an example/use case for 1)? Is it that validation of bean
> A depends on the state of a bean B referenced by A? If so, couldn't
> you put this validation logic to B instead of A? And how do you
> interact with PathNode here? Discussing a specific example would help
> to grasp the full picture.
Unfortunately I have changed company since I implemented this so I will have to rely on my shoddy memory...
The issue here was that based on a setting in bean B the result would be different in bean A.
The bean structure was read from an XML structure using JAXB.
Bean A and bean B were not aware of each other, they were even residing in different subtrees under the root node (meaning it would not help to put the validation in bean B as suggested).
What I ended up having to do was to implement a full handling of parent nodes in the beans just in order to be able to navigate up to the tree to the root node to get hold of the relevant setting.
This I find is totally redundant work, especially when dealing with List objects, since the validation is already keeping track of the path.
That is why I suggest that
a) the path should be fully navigatable upwards and allow access to the actual instances
b) the path should be made available in the
ConstraintValidatorContextthat is passed to the validation method.
> Interesting one. Can you elaborate a bit on how you envision this
> interface to look like and how it would be used?
I did this in the simplest way possible.
I created an interface called StringId with one single method, String getId().
This String would return whatever was considered the "primary key" of the bean, thereby allowing an easy search in the XML structure for the violation culprit.
When parsing and creating the validation failure I checked if the failing object implemented StringId and if so I used that value, otherwise the index.
This solution also mandates a possibility to access the actual bean instance.
So the needs I found fully relied on the Hibernate implementation of the validation framework.
I have a vague memory of it actually being Gunnar that implemented this extra Path interface in Hibernat.
> Do you want to apply different constraints in different "situations"?
> If so, validation groups should be helpful.
> If you want one constraint to behave situation-specific (not sure
> whether it's a good idea), there is a solution if you work with a
> container such as CDI or Spring: Inject the required context using the
> correct scope (e.g. request-scoped) into ConstraintValidator
> implementations.
In my case the different behavior depended on a simple flag so I would prefer that for really simple cases to just pass down this flag rather than dealing with injections etc.
Passing down a Map with arbitrary content would also have offered a working solution for the first problem since I could have passed down the root node instead of navigating up the tree.