[bv-dev] Conflict issue with value extraction and JavaFX collection types

[Guillaume Smet]

Hi,

We are refining the value extraction work and one of the remaining tasks is
to throw a proper exception if we have ValueExtractors defined in parallel
hierarchies for a given type.

This led to discovering the below issue with the JavaFX collection types.

Let's take the ListProperty example (we have the same issue with Set and
Map): ListProperty inherits from ObservableValue and from List.

For now, it uses (by chance) the ObservableValue extractor which unwraps
the value by default. So basically:
@NotNull
private ListProperty<String> listProperty = new
ReadOnlyListWrapper<String>( null );
will return a violation.

With the new conflict detection, it will throw an exception as it's unable
to find ONE most specific ValueExtractor as there are 2 valid candidates:
ObservableValueValueExtractor and ListValueExtractor.

If we want to solve the conflict, we need to introduce a specific
ValueExtractor for ListProperty and decide of its behavior.

We have 2 possibilities:
1/ consider ListProperty as an ObservableValue and thus simply unwrap the
list and validate the constraint against the list. In the above example,
@NotNull would then apply to the inner list. Same behavior as explained
above.
2/ consider ListProperty as a List. Thus the value extractor would iterate
over the element of the list. In the above case, it won't return a
violation. In the below example, the @NotNull would refer to listProperty
itself and the constraints on the elements of the list would be validated:
@NotNull
private ListProperty<@Size(min = 3) String> listProperty = new
ReadOnlyListWrapper<String>( null );

Gunnar and I are in favor of 2/ but it changes the current behavior as the
@NotNull would refer to the container instead of referring to the wrapped
value.

We would really like to have some feedback from people using JavaFX.

Thanks!

-- 
Guillaume
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20170412/92999b1c/attachment-0001.html