[
https://hibernate.onjira.com/browse/BVAL-237?page=com.atlassian.jira.plug...
]
Emmanuel Bernard commented on BVAL-237:
---------------------------------------
{quote}bq. My main problem with that is leakage. Forget validateValue, forget reliable
validate based on changesets.
I don't understand what you mean with that. Can you elaborate?{quote}
If a constraint validator is relying on the presence of the bean object, it will fail when
validateValue is used as no bean instance is there. Assuming we add a changeset API to
validate an object based on a set of potential changes. The object will not have the
changeset applied to it and the logic using the bean instance my be tricked.
Expose validated bean via ConstraintValidatorContext
----------------------------------------------------
Key: BVAL-237
URL:
https://hibernate.onjira.com/browse/BVAL-237
Project: Bean Validation
Issue Type: New Feature
Components: spec-general
Affects Versions: 1.0 final
Reporter: Gunnar Morling
Fix For: 1.1
In the feedback forum a user
[
suggested|https://forum.hibernate.org/viewtopic.php?f=26&t=1012111] to expose the
currently validated bean via {{javax.validation.ConstraintValidatorContext}}.
IMO that's a good addition as it would people allow to create custom cross-field
constraints more easily. I'm not sure whether access should be restricted to the
current leaf bean or whether also the root bean should be accessible. In the latter case
some methods from {{ConstraintViolation}} might just be offered on
{{ConstraintValidatorContext}} as well:
{code:java}
getConstraintDescriptor()
getLeafBean()
getPropertyPath()
getRootBean()
getRootBeanClass()
{code}
Another idea would be to have an {{unwrap()}} method on {{ConstraintValidatorContext}}
which would allow for BV providers to expose additional functionality. WDYT?
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira