Re: [bv-dev] Method constraints and TraversableResolver contract
That's an interesting question. I think you should call isReachable and isCascadable
for params and return values.
Imagine a constraint validating a JPA entity. You don't want it to be validated if the
entity is a proxy. This constraint could access a few of the entity state properties. And
that's before cascading.
isCascadable was a contract added specifically so that the same entity would not be
validated over and over if it happened to be referenced by several other entities in a
dirty persistence context.
Open an issue because we need to clarify all that in the spec.
Emmanuel
Of the top of my head I cannot think of a reason why we would need to use isReachable on a
parameter
On 9 janv. 2013, at 15:42, Gunnar Morling <gunnar(a)hibernate.org> wrote:
Hi all,
working on the TCK, I'm wondering whether a BV provider should use
TraversableResolver#isReachable() and isCascadable()) to check whether a validated method
parameter or return value may be accessed/traversed.
I think checking for cascadability might make sense, but I'm not so sure about
checking for reachability; can e.g. be a parameter not reachable?
If any of the checks shall be done for method validation, we need to update the
TraversableResolver contract (section 4.6.3) which currently explicitly speaks about
properties and is limited to the element types FIELD and METHOD.
WDYT?
--Gunnar
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev