From hjohn at xs4all.nl  Thu May 19 06:32:25 2016
From: hjohn at xs4all.nl (John Hendrikx)
Date: Thu, 19 May 2016 12:32:25 +0200
Subject: [bv-dev] ConstraintValidatorContext removes iterable nesting, bug?
Message-ID: <573D9639.7050900@xs4all.nl>

Hi list,

I'm currently trying to use JSR-303 validation inside a project with a 
complicated hierarchical structure that needs validation.  What I find 
is that even in custom validators, the ConstraintValidatorContext is 
limiting me in what paths I can construct to indicate the proper error 
location.

For example, when my custom rule is called as part of an iteration, and 
I want to add another level of iteration in the path like so:

    .addPropertyNode("y").inIterable().atKey("z")

...it will overwrite the current iterable part of the path (allowing me 
to modify the "parent" context it looks like).  So instead of getting:

    root["x"]["z"].y

It removes the ["x"] and results in: root["z"].y which is clearly wrong.

If I add a dummy property node first, I can atleast see the root iterable:

    .addPropertyNode("$DUMMY$")
    .addPropertyNode("y").inIterable().atKey("z")

Results in: root["x"].$DUMMY$["z"].y

I also think it is a shame that nested Iterables are not supported. 
Hierarchical structures can have constructs like Map<String, List<X>> 
and currently annotating X has no effect at all.

--John



From gunnar at hibernate.org  Fri May 20 05:46:43 2016
From: gunnar at hibernate.org (Gunnar Morling)
Date: Fri, 20 May 2016 11:46:43 +0200
Subject: [bv-dev] ConstraintValidatorContext removes iterable nesting,
	bug?
In-Reply-To: <573D9639.7050900@xs4all.nl>
References: <573D9639.7050900@xs4all.nl>
Message-ID: <CADGJaX8FXLRKNj71mqPyTBBN+0xTonnHnuxFRjBzJ8GC2CSQPg@mail.gmail.com>

Hi John,

2016-05-19 12:32 GMT+02:00 John Hendrikx <hjohn at xs4all.nl>:

> Hi list,
>
> I'm currently trying to use JSR-303 validation inside a project with a
> complicated hierarchical structure that needs validation.  What I find
> is that even in custom validators, the ConstraintValidatorContext is
> limiting me in what paths I can construct to indicate the proper error
> location.
>
> For example, when my custom rule is called as part of an iteration, and
> I want to add another level of iteration in the path like so:
>
>     .addPropertyNode("y").inIterable().atKey("z")
>
> ...it will overwrite the current iterable part of the path (allowing me
> to modify the "parent" context it looks like).  So instead of getting:
>
>     root["x"]["z"].y
>
> It removes the ["x"] and results in: root["z"].y which is clearly wrong.
>

Currently, Bean Validation does not support cascaded validation of directly
nested collections (say a Map<String, List<Long>>). So a violation of a
constraint would never result in a path with two adjacent indexes (e.g.
["x"]["z"]) and it's not possible to create such path using the API either.

Could you share your bean types and the path you'd like to create? I
suppose it involves such nested collection?

If I add a dummy property node first, I can atleast see the root iterable:
>
>     .addPropertyNode("$DUMMY$")
>     .addPropertyNode("y").inIterable().atKey("z")
>
> Results in: root["x"].$DUMMY$["z"].y
>
> I also think it is a shame that nested Iterables are not supported.
> Hierarchical structures can have constructs like Map<String, List<X>>
> and currently annotating X has no effect at all.
>

I suppose the reason why it wasn't supported so far is the lack of control
over the depth of cascaded validation.

Associations are only traversed if advised so by means of the @Valid
annotation. So if you have a field "private List<Foo> foos" in your bean,
there is a place to put the @Valid annotation to - the field definition.

But prior to Java 8, there would have been no satisfactory way to express
this in case of nested collections. Now, with the advent of type-level
annotations, there actually is: Map<String, @Valid List<Foo>>. So it's
something we might consider in a BV 2.0 (which would be centered around
migration to Java 8).

--Gunnar





>
> --John
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20160520/00da4aae/attachment-0001.html