validation-configuration.xsd and value-extractors
by Guillaume Smet
Hi,
In the current revision of the spec, the value-extractor element is at the
same level as message-interpolator for instance.
So, when you want to add several value-extractors, you end up having the
following:
<validation-config>
<message-interpolator>org.hibernate.beanvalidation.tck.tests.integration.cdi.managedobjects.MessageInterpolatorUsingDependencyInjection</message-interpolator>
<value-extractor>package.MapKeyValueExtractorUsingDependencyInjection</value-extractor>
<value-extractor>package.MapValueValueExtractorUsingDependencyInjection</value-extractor>
</validation-config>
I was thinking that we should maybe wrap it into a value-extractors
element. It would be nicer and more consistent with the usual conventions.
What do you all think about it?
--
Guillaume
7 years, 5 months
Results on @Positive/@Negative poll
by Gunnar Morling
Hi all,
We've received quite some good feedback on the poll on the behavior of
@Positive and @Negative (98 answers overall, see the original data
below).
As per question 2), there's a preference for having separate
annotations instead of an attribute. I think the poll is clear enough
that we should go for the separate annotation route. While I was no
fan originally, it grew on me due to its explicitness.
The remaining question is on their names. We had asked about
@PositiveOrZero/@NegativeOrZero in the poll, but several people
suggested @NonNegative and @NonPositive.
Personally I'd prefer to stick to @PositiveOrZero/@NegativeOrZero
because I think negated names should be avoided generally, as
non-negated names are easier to grok (see? ;). And they'll be easier
to find via auto-completion in the IDE, i.e. when typing @Posit<TAB>,
you'll get both options shown, unlike when going for the @Non...
approach. But eventually I could live with both.
Thoughts?
--Gunnar
Original poll data
=============
* When validating @Positive/@Negative, should 0 (zero) be considered
as valid by default?
- 58.2%: No, i.e. the following constraint is violated: private
@Positive int myNum= 0
- 41.8%: Yes, i.e. the following constraint is valid: private
@Positive int myNum =0
* How should we call the constraint attribute for controlling whether
0 is considered valid or not?
- 36.7%: no attribute, but rather add separate annotations:
@PositiveOrZero and@NegativeOrZero
- 28.6%: orZero(), e.g. used like so:@Positive(orZero=true)
- 25.5%: strict(), e.g. used like so:@Positive(strict=false)
- 9.2 %: others:
- "@NonNegative/@NonPositive" (7x)
- "Different annotation @Zero"
- "Either make each explicit or use a @Range(min, max)"
* Other related remarks:
- I think that 0(zero) should not be default, especially as it is
default for primitives. One should explicitly allow them, otherwise
users can forget to specify it.
- What's so bad about @Min(0) with inclusive again?
- "non-negative" is a well-established and widely used term for this constraint
- The constraints are to fine a open closed range could do the same thing
- Java's logic was always from inclusive and to exclusive and that can
also be applied to 0.
- let's not create confusion by acting like "positive numbers"
includes zero. Developers can get over a little inconvenience of
@Positive not passing on values that aren't positive, such as 0.
- Do not be tempted to violate Bloch's api design rules. An API is
long-lived and making it incorrect to please early adopters is a poor
choice. https://www.infoq.com/articles/API-Design-Joshua-Bloch
- https://math.stackexchange.com/questions/26705/is-zero-positive-or-negative
- Zero is mathematically neither positive not negative so please don't
throw math principle out. But the idea of attribute is a great thing
for usuability
- I would just use @Positive(> 0), @Negative (< 0), @NonNegative (>=
0) and @NonPositive (<= 0) to make it more explicit, this also follows
the general rules found on sites such as Wikipedia:
https://en.wikipedia.org/wiki/Sign_(mathematics)#Terminology_for_signs
7 years, 5 months
Public Review draft updated
by Gunnar Morling
Hi all,
Our update to the Public Review draft has been published on jcp.org now:
http://beanvalidation.org/news/2017/05/24/bean-validation-2-0-public-revi...
This is mainly about ExtractedValue#type() --so OptionalInt et al. can
be supported -- and adding support for container element paths to the
node builder API exposed via ConstraintValidatorContext.
The ballot will begin next week, so if you are member of the EC or
your company is, please to don't forget to vote / remind you
representatives to vote :)
The Proposed Final Draft is due in about one month from now. I'll work
on several clarifications of wording, mainly around container element
validation, which came up during implementation within the RI. If you
think there's anything we should still do, please speak up as soon as
possible.
Cheers,
--Gunnar
7 years, 6 months
Support for OptionalInt, OptionalLong and OptionalDouble
by Gunnar Morling
Hi,
I'm curious about your take on supporting the types in ${subject}
(BVAL-579 [1]).
They are non-generic wrappers for int, long and double. Should we
support them with the numeric constraints such as @Min et al.? The
easiest way to do so would be to just mandate support in the JavaDoc
of the numeric constraint types.
The only thing I can see speaking against this is that we may migrate
to an extractor-based approach in a future revision. Currently
extractors cannot be used, as those types don't have any type
parameter which could be extracted. But assuming we extend the
extractor API in a future revision to deal with non-generic types,
too, we could then rather mandate built-in extractors for those types.
Which will allow to put *any* constraint applying to int also to
OptionalInt.
Should we do such change in a future revision, I don't think anything
would change for users. Only providers would have to implement support
for these types via extractors instead of dedicated constraint
validators. I think such change is acceptable.
What do others think?
Thanks,
--Gunnar
[1] https://hibernate.atlassian.net/browse/BVAL-579
7 years, 6 months
Jigsaw module name
by Gunnar Morling
Hi,
Java 9 is still in the works, so it's too early to put anything final
into the BV spec, but should we add a recommended module name for API
modules?
My thinking is to have a short appendix stating:
"Implementors that wish to provide the Bean Validation API in form
of a Java 9 module,
should use the module name "javax.validation". A mandatory module
name will be
defined in a future revision of this specification".
A commonly agreed on module name is required by Jigsaw to ensure
different API modules (e.g. the reference one and the one provided by
Apache) are interchangeable.
I expect further changes to the spec to support Java 9 down the road
(e.g. to resolve message bundles in client modules and to provide a
way for passing in a Lookup granting private access (see [1]), but
it's nothing we can bake into the spec yet.
Thoughts?
--Gunnar
[1] http://in.relation.to/2017/04/11/accessing-private-state-of-java-9-modules/
7 years, 6 months
Questions from BV spec 2.0 public draft
by Matt Benson
After reviewing the proposed API, I have the following
questions/suggestions. I apologize if any of these have already been
considered:
* Should there be a common superinterface for
Path$[BeanNode|PropertyNode|ContainerElementNode], all of which define
the same methods?
* Should ValidatorContext include a self type, as does Configuration?
This would facilitate the use of custom ValidatorContext subclasses.
* Should Positive/Negative#strict() default true be provided as
#orZero() default false, for commonality with
[Past|Future]#orPresent() ?
Matt
7 years, 6 months
Conflict issue with value extraction and JavaFX collection types
by 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
7 years, 6 months
