[bv-dev] BVAL-221 Constraint violation builder cannot put constraint on a top level map key

Emmanuel Bernard emmanuel at hibernate.org
Fri Nov 23 09:56:54 EST 2012


On Fri 2012-11-23 15:50, Hardy Ferentschik wrote:
> 
> On 23 Jan 2012, at 3:21 PM, Gunnar Morling <gunnar at hibernate.org> wrote:
> 
> > > - relaxing NodeBuilderDefinedContext and adding the new contract on it
> > 
> > I wouldn't really like that as it reduces safety of the API.
> 
> need to still make up my mind about this one
> 
> > > - an explicit new method deprecating addNode
> > 
> > Related to this is BVAL-336 [1]. We've added Node#getDescriptor(), so the question is what should that return for nodes created by the user via the node builder API?
> > 
> > We could have a new method
> > 
> > addNode(String name, ElementDescriptor descriptor) or even 
> > addNode(ElementDescriptor descriptor)
> > 
> > Leaves the question where does the user get the descriptor from? One way could be to provide access to BeanDescriptor via ConstraintValidatorContext. For nodes added via the deprecated method getDescriptor() we would likely have to return null.
> 
> This is one of the reason I never found it such a good idea to "merry" the path with the descriptors. In this context we also talked once about the need of a DummyDescriptor. Using the
> ConstraintValidatorContext you are not obliged to build a ConstraintViolation for an actual property/method/etc. What is going to happen in this case?
> 
> I am wondering whether something like an ElementDescritorFinder (similar to ConstraintFinder) wouldn't be a better alternative (on BeanDescriptor)? 

Note that the main reason for having getElementDescriptor on Node is to
be able to know which parameter (index) a constraint belong to.
This was at the time our nicest approach but we can revisit if someone
finds a better approach.


More information about the beanvalidation-dev mailing list