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

[Gunnar Morling]

Right, it's an issue with parallel class hierarchies in general. The
same could happen during constraint validator resolution. In both
cases an extractor (or validator) for the specific sub-type must be
provided to resolve the ambiguity. This would also address your case
of cached and real value.

Based on the preference of option 2), I've added this to the pending
PR in the section on built-in extractors:

===
Compatible implementations provide value extractors for the following
types out of the box:

[...]

* javafx.beans.observable.ObservableValue; value() must be invoked
with the observable value, passing null as node name; the extractor
must be marked with @UnwrapByDefault

* javafx.beans.property.ReadOnlyListProperty and
javafx.beans.property.ListProperty; indexedValue() must be invoked for
each contained element, passing the string literal <iterable element>
as node name

* javafx.beans.property.ReadOnlyMapProperty and
javafx.beans.property.MapProperty; both map keys and map values are to
be supported; keyedValue() must be invoked by the map key extractor
for each contained key, passing the string literal <map key> as node
name; keyedValue() must be invoked by the map value extractor for each
contained value, passing the string literal <map value> as node name
===

2017-04-19 14:42 GMT+02:00 Hendrik Ebbers <hendrik.ebbers at me.com>:
> I think this is not a JavaFX specific problem. This can happen everywhere if
> you have defined extractors for 2 interface types and and have an
> implementation of both.
> In this specific example I would prefer to define ListProperty as a List.
>
> In general I think that this problem might / will happen in other frameworks
> and APIs, too.
>
> I added such an example in a mail about the usage of annotations in the
> generic information:
>
> Until now I only worked with lists and here the approach is quite nice.
> Sadly it won’t work always. By adding an constraints annotation to the
> generic type of the list we know that the annotation mentions the content of
> the list. But this is only working because of one point: The generic type of
> a collection defines the type of the collection content. This works fine for
> collections (and for example JavaFX properties) but in other cases this will
> end in problems.
>
> Let’s say we have the following 2 interfaces:
>
> public interface CachedValue<V> {
>     V getCachedValue();
> }
>
> public interface RealValue<V> {
>     V getRealValue();
> }
>
> Based on this interfaces we can easily create a new class that implements
> both interfaces:
>
> public class CachableValue<V> implements CachedValue<V>, RealValue<V> {
>
>     private V cachedValue;
>
>     @Override
>     public V getCachedValue() {
>         return cachedValue;
>     }
>
>     @Override
>     public V getRealValue() {
>         V realValue = receiveValueFromServer();
>         cachedValue = realValue;
>         return realValue;
>     }
>
>     private V receiveValueFromServer() {
>         return ServerConnector.getCurrentValue(); //Some fake code
>     }
> }
>
>
>
>
> Am 18.04.2017 um 14:57 schrieb Emmanuel Bernard <emmanuel at hibernate.org>:
>
> I'm not using JavaFX but I would be in favor of 2. because it let's
> people put a size constraint on the List.
>
> Have you considered a blog post to get more feedback. Here people don't
> use JavaFX or are shy.
>
> On Wed 17-04-12 16:16, Guillaume Smet wrote:
>
> 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
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev