Re: [bv-dev] BV 2.0 - Add constraints?
by Otávio Gonçalves de Santana
I sent to adopt JSR email list and share it on social media.
https://twitter.com/otaviojava/status/776549007799701504
On 15 Sep 2016 12:00, "Otávio Gonçalves de Santana" <
otaviopolianasantana(a)gmail.com> wrote:
> Nice form!!
> I'm sharing it in adopt JSR program email list.
>
> On 15 Sep 2016 03:46, "Gunnar Morling" <gunnar(a)hibernate.org> wrote:
>
>> Hi,
>>
>> I've created a survey using Google Forms on our blog (staging atm.):
>> http://staging.beanvalidation.org/news/2016/09/15/
>> which-constraints-to-add/
>>
>> Feedback welcome. Unless I hear back otherwise, I'll push it to the
>> production site tomorrow and then let's announce it on Twitter to get some
>> answers. I'd leave it open for two weeks (allowing people to reply after J1
>> which is next week), which should be plenty of time.
>>
>> One question I have is should we allow anonymous voting or require
>> logging in via Google. The latter prevents double votes, but it raises the
>> level for participation and don't think people feel motivated to vote
>> several times on this topic really.
>>
>> Andy thoughts?
>>
>> Thanks,
>>
>> --Gunnar
>>
>>
>> 2016-09-14 12:02 GMT+02:00 Marco Molteni <moltenma(a)gmail.com>:
>>
>>> I agree about @Length. It was listed only because of the frequency. I'd
>>> limit the addition to @NotBlank and @NotEmpty.
>>>
>>> On Wed, Sep 14, 2016 at 11:52 AM, Gunnar Morling <gunnar(a)hibernate.org>
>>> wrote:
>>>
>>>> Btw. I don't see a strong reason for @Length, as we have @Size in the
>>>> spec for it already.
>>>>
>>>> I think it's commonly used in older applications which migrated from HV
>>>> 3.x (proprietary API) to HV 4.x (BV RI) and kept using the legacy
>>>> constraint instead of using the spec'-ed @Size.
>>>>
>>>> 2016-09-14 11:48 GMT+02:00 Gunnar Morling <gunnar(a)hibernate.org>:
>>>>
>>>>> Hi,
>>>>>
>>>>> I like the idea of collecting some more feedback from the community.
>>>>>
>>>>> A blog post may be an option, though I reckon feedback will be sparse
>>>>> based on previous experiences. I'd rather do a survey as it's more
>>>>> actionable for people. Either on Twitter (though that seems a bit limited)
>>>>> or using Google Forms [1], which is my preference.
>>>>>
>>>>> I'll prepare something and share it with you soon. If the survey looks
>>>>> good, we can promote it on Twitter and during the Hackergarten at J1 (of
>>>>> course talking to people in person there will be a great chance to learn
>>>>> about their wishes, too).
>>>>>
>>>>> It'd be nice if we got some insight from that.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> --Gunnar
>>>>>
>>>>> [1] https://docs.google.com/forms/
>>>>>
>>>>>
>>>>> 2016-09-09 11:34 GMT+02:00 Marco Molteni <moltenma(a)gmail.com>:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> which is the best / common way to get a representative feedback
>>>>>> according to your experience?
>>>>>> Thanks!
>>>>>>
>>>>>> On Thu, Sep 8, 2016 at 7:44 AM, Christian Kaltepoth <
>>>>>> christian(a)kaltepoth.de> wrote:
>>>>>>
>>>>>>> I also think that adding the most popular 3rd party constraints
>>>>>>> directly to the spec is a good thing. Especially @NotBlank and @NotEmpty.
>>>>>>>
>>>>>>> However, I also agree that it would be nice to gather more feedback
>>>>>>> from the community to learn which constraints people would like to see in
>>>>>>> the spec.
>>>>>>>
>>>>>>> 2016-09-06 20:50 GMT+02:00 Michael Nascimento <misterm(a)gmail.com>:
>>>>>>>
>>>>>>>> +1 to including them.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Michael
>>>>>>>>
>>>>>>>> On Mon, Aug 22, 2016 at 2:37 PM, Marco Molteni <moltenma(a)gmail.com>
>>>>>>>> wrote:
>>>>>>>> > Hi all,
>>>>>>>> >
>>>>>>>> > It would be possible to add some built-in constraints to the V
>>>>>>>> 2.0?
>>>>>>>> >
>>>>>>>> > @NotBlank, @NotEmpty, @Length are used very often in projects,
>>>>>>>> they are
>>>>>>>> > already present in Hibernate Validator and their implementation
>>>>>>>> is well
>>>>>>>> > defined.
>>>>>>>> >
>>>>>>>> > What do you think?
>>>>>>>> >
>>>>>>>> > Here a list of the most used constraint for GitHub's projects
>>>>>>>> (the numbers
>>>>>>>> > change at every request but you get the idea. HV = Hibernate
>>>>>>>> Validator, BV =
>>>>>>>> > Bean Validation):
>>>>>>>> >
>>>>>>>> > 189'143 - BV - NotNull
>>>>>>>> > 56'902 - BV - Size
>>>>>>>> > 39'551 - HV - NotEmpty <-
>>>>>>>> > 20'687 - HV - NotBlank <-
>>>>>>>> > 17'735 - BV - Pattern
>>>>>>>> > 16'763 - HV - Email
>>>>>>>> > 16'033 - BV - Min
>>>>>>>> > 12'769 - HV - Length <-
>>>>>>>> > 7'806 - BV - Digits
>>>>>>>> > 4'982 - BV - Max
>>>>>>>> > 4'971 - BV - Past
>>>>>>>> > 3'598 - BV - DecimalMin
>>>>>>>> > 2'753 - BV - AssertTrue
>>>>>>>> > 2'379 - BV - DecimalMax
>>>>>>>> > 2'308 - BV - Future
>>>>>>>> > 1'999 - HV - Range
>>>>>>>> > 1'497 - HV - URL
>>>>>>>> > < 1'000 other constraints
>>>>>>>> >
>>>>>>>> > Thanks
>>>>>>>> >
>>>>>>>> > Cheers
>>>>>>>> >
>>>>>>>> > Marco
>>>>>>>> >
>>>>>>>> >
>>>>>>>> > _______________________________________________
>>>>>>>> > beanvalidation-dev mailing list
>>>>>>>> > beanvalidation-dev(a)lists.jboss.org
>>>>>>>> > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>>>>> _______________________________________________
>>>>>>>> beanvalidation-dev mailing list
>>>>>>>> beanvalidation-dev(a)lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Christian Kaltepoth
>>>>>>> Blog: http://blog.kaltepoth.de/
>>>>>>> Twitter: http://twitter.com/chkal
>>>>>>> GitHub: https://github.com/chkal
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> beanvalidation-dev mailing list
>>>>>>> beanvalidation-dev(a)lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> beanvalidation-dev mailing list
>>>>>> beanvalidation-dev(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> beanvalidation-dev mailing list
>>>> beanvalidation-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>>
>>>
>>>
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>>
>>
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>
5 years, 12 months
Sticker
by Hendrik Ebbers
Hi,
I attached a preview of the sticker. I will order in now :)
Cheers,
Hendrik
6 years
Fwd: Limitations found in previous bean validation
by Anders Persson
Hi all,
So a couple of months back I had a bean structure that I wanted to validate.
My selection was to use the validation framework.
I could after a while see that the framework specification, and hence the
implementations, fell short in several areas so my ideas below are based on
a live project.
1) Sometimes the contents of one bean depends on the contents of another
bean. The current specification does not in any way allow navigating the
bean tree despite this information being available internally of the
implementations. Also accessing the bean instances to get hold of the data
is not supported. The closest to a solution here was the Hibernate
implementation which did add a proprietary interface to extract the data
using PropertyNode. There is however a somewhat strange limitation in the
Hibernate implementation in that navigating the bean path does not allow
you to access the root bean, only the first children under the bean. This
means if the relevant data is located in another branch under the root node
there is no way to gain access to the data.
Solution: Allow full navigation up and down the bean structure and allow
accessing the bean instance to get hold of the data. A framework should not
impose limitations to what validation a user wants to do. This means make
the getValue method of Hibernate PropertyNode part of the standard and add
a getParent() to, for instance, Path.BeanNode to allow moving up the path.
2) Sometimes the bean structure can consist of lists with a large number of
elements. The current solution with index number makes it very cumbersome
to match a failed validation to whatever source of data you have (database,
xml file, input from webservice etc). In many cases an element (bean)
contains some data which can be considered as a "primary key" which makes
it easy to identify in the input data. To handle this I created a StringId
interface that the beans would implement and I then used this as output
when parsing the validation result. This however requires me to implement a
formatter for something that I think should be supported out of the box by
the validation specification.
Solution: Create an interface (of annotation, I have no strong feeling
about the actual implementation) that can be used to identify elements in a
list.
3) Sometimes the validation is situation dependent, for instance, the
expected bean contents depend on where the data is coming from or at what
point in time in the business process it is being validated. It would be
desirable to easily pass in a settings object in the validation method.
Solution: Extend ConstraintValidatorContext to allow passing user data or
extend the validation method to take an arbitrary Object given by the user.
I hope that I have been able to make my ideas clear and that there are not
too many errors in what I have written. It has been a while since I wrote
this code and I have since changed company so I can't check and verify that
I have gotten all details right.
Anders
6 years
Value extraction open issue #5: Should value extractors be discoverable via the service loader?
by Gunnar Morling
Hi,
I think there already was agreement essentially that value extractors
should be discoverable using the service loader mechanism.
This will allow providers of custom collection types (e.g. Google
Guava) to bundle a value extractor with their library and have it
being picked up automatically, allowing application developer to put
@Valid to these types without any further configuration.
So I've prepared a change for that:
https://github.com/beanvalidation/beanvalidation-spec/pull/140
The open question was how value extractors should be
overridden/disabled. I've foreseen the following sources for value
extractors, in descending order of precedence:
* ValidatorContext#addValueExtractor(ValueExtractor<?>)
* Configuration#addValueExtractor(ValueExtractor<?>)
* META-INF/validation.xml
* META-INF/services/javax.validation.valueextraction.ValueExtractor
If an extractor for a specific type (e.g. java.util.List) and type
parameter (e.g. "E") is given at one level (e.g. ValidatorContext) it
will override any extractors for the same type and type parameter
given at the lower levels and the built-in extractor for that type and
type parameter, if any.
I don't think there's a way needed to explicitly disable an extractor
without providing an alternative implementation. I.e. I cannot see a
use case why one would want to disable cascaded validation let's say
for List. Hence the proposed overriding scheme.
Can you please let me know what you think of this by the end of the week?
Thanks,
--Gunnar
6 years
Value extraction open issue #13 and #14: Path and nodes
by Guillaume Smet
Hi,
We would like to discuss with you the node structure of the
ConstraintViolation path in the case of value extraction (2 cases really:
cascaded validation and type argument constraints).
This is not an easy one! And we will also digress on the string
representation while we're at it even if it's not part of the spec.
= 1. Type parameter information
== 1.1 Should we add the type parameter to the node?
Assume the example of a map:
private Map<@Valid City (1), @Valid Statistics (2)> map;
With the current way of doing things, you end up with the following paths:
(1) (name = map, type = PROPERTY) -> (name = name, type = PROPERTY,
isInIterable = true, key = city)
(2) (name = map, type = PROPERTY) -> (name = count, type = PROPERTY,
isInIterable = true, key = city)
So you wouldn't be able to differentiate if the violations is coming from
City or Statistics.
One of the ideas we had is to integrate the TypeVariable<?> type parameter
info into the last node. In the case of (1), you would have 2 nodes:
(1) (name = map, type = PROPERTY) -> (name = name, type = PROPERTY,
isInIterable = true, key = city, typeParameter = K)
(2) (name = map, type = PROPERTY) -> (name = count, type = PROPERTY,
isInIterable = true, key = city, typeParameter = V)
WDYT?
== 1.2 If we add this information, what should it be?
At first, Gunnar thought about using java.lang.reflect.TypeVariable for
this type parameter information but we have an issue with it: it is not
serializable and the path is supposed to be.
Thus we need to either use a String with the name of the type parameter or
introduce our own serializable structure.
What's your take on this? If we go the structure route, which information
should this structure contain apart from the name?
java.lang.reflect.TypeVariable also has the generic declaration information.
Do you foresee issues if we are not using java.lang.reflect.TypeVariable?
Typically it would be harder to do additional reflection things.
= 2. Type argument constraints
So, the discussion above also applies to type argument constraints but
there are some specific questions for them.
== 2.1 New node type
Type argument constraints cover the following case, ZipCode being a
constraint:
Map<@ZipCode String, String> map;
In this case, we envision the following node structure (assuming we would
add the typeParameter discussed in 1.1):
(name = map, type = property) -> (name = '<map key>', type = TYPE_ARGUMENT,
isInIterable = true, key = myKey, typeParameter = K)
TYPE_ARGUMENT is a new type introduced in javax.validation.ElementKind.
Does it make sense?
== 2.2 Default node names
The default extractors define the following node names for the added
TYPE_ARGUMENT node:
- arrays and Iterables (List included): <iterable element>
- Map key: <map key>
- Map value: <map value>
This is similar to the nodes we created for "<return value>" or
"<cross-parameter>" constraints.
Question: should they have a node name? should it be the type parameter
name instead (so E or K or V for instance)?
Note that this might have consequences in the string representation we will
discuss later.
== 2.3 Optional and ObservableValue
In these 2 cases, we won't append a node.
Note that while in the ObservableValue case, it might feel more natural as
the constraint will probably be used like:
@NotBlank StringProperty property;
to apply a NotBlank constraint on the wrapped value so it's rather logical
to not have a node.
Just to be clear, for Optional, on the other hand, with our proposal, we
won't have a node whereas the code looks like:
Optional<@NotBlank String> optional;
= 3 String representation
Note: this is implementation specific but we thought it might be
interesting to discuss it here anyway.
The Path toString() is included in
ConstraintViolationException.getMessage().
If we consider what we proposed above and the following property:
Map<@NotNull @Valid Address, String> nicksByAddress;
We would end up with:
map<K>[address.toString()].street //error in address.street
map<K>[address.toString()].<map key> //error in type param of address
map<K>[address.toString()] //error in class level address - there is a bean
node which we don't show
If we consider the following property:
Map<String, @NotNull @Valid Address> addressesByNick;
And we decided to be consistent with the fact that we add the type
parameter information, we would end up with:
map<V>[address.toString()].street //error in address.street
map<V>[address.toString()].<map key> //error in type param of address
map<V>[address.toString()] //error in class level address - there is a bean
node which we don't show
Note that this breaks the previous behavior of HV 5.x as we used to only
support constraints on the value and we did not have the '<V>' information.
The issue becomes a bit more pregnant in the case of Lists. Let's assume we
have the following property:
List<@NotNull @Valid Address> addresses;
We would end up with:
addresses<E>[0].street //error in address.street
addresses<E>[0].<iterable element> //error in type param of address
addresses<E>[0] //error in class level address - there is a bean node which
we don't show
Question that becomes obvious here: if it were possible to only display the
type parameter if we have > 1 type parameters in the original generic
declaration, would it make sense to omit it? Basically, we have to discuss
consistency vs readability.
To completely illustrate the discussion, let's take a look at what happens
with nested type argument constraints (it is not in the spec yet but we
experimented with it in HV - we'll discuss this in a future email):
Map<String, List<@NotNull @Valid Address>> listOfAddressesByNick;
In this case, the envisioned string representation would be:
listOfAddressesByNick<V>[myKey].<map value><E>[0].street //error in
address.street
listOfAddressesByNick<V>[myKey].<map value><E>[0].<iterable element>
//error in type param of address
listOfAddressesByNick<V>[myKey].<map value><E>[0] //error in class level
address - there is a bean node which we don't show
So, as you can see, the readability can become an issue.
Thoughts? Ideas?
--
Guillaume
6 years
Re: [bv-dev] Posted Early Draft 1 to the JCP
by Christian Kaltepoth
That's great news. Thanks everyone for the good work.
Am 08.02.2017 12:00 schrieb "Gunnar Morling" <gunnar(a)hibernate.org>:
Hi all,
As discussed, I've cut an 2.0.0.Alpha1 release of the Bean Validation
API plus spec and send them to the JCP team for starting an Early
Draft review.
It may take a few days until it's up on jcp.org, so let's wait with
tweeting, blogging etc. until it's there at
https://www.jcp.org/en/jsr/detail?id=380.
We are in a good spot with the RI, too. So we should be able to do an
Alpha1 release of HV 6.0 at the same time as the EDR begins.
--Gunnar
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
6 years, 1 month
Posted Early Draft 1 to the JCP
by Gunnar Morling
Hi all,
As discussed, I've cut an 2.0.0.Alpha1 release of the Bean Validation
API plus spec and send them to the JCP team for starting an Early
Draft review.
It may take a few days until it's up on jcp.org, so let's wait with
tweeting, blogging etc. until it's there at
https://www.jcp.org/en/jsr/detail?id=380.
We are in a good spot with the RI, too. So we should be able to do an
Alpha1 release of HV 6.0 at the same time as the EDR begins.
--Gunnar
6 years, 1 month
JSR 380 Contributor Nominations
by Gunnar Morling
Hi,
For the sake of transparency: There have been several nominations to
become a "Contributor" of this JSR. As per the JCP, "Contributors are
people who are NOT on the Expert Group of the JSR but whom you wish to
publicly recognize for their work on the JSR".
I'm very willing to formally recognize every contributor, but I think
at first there should be some actual contribution. The bar can be very
low, e.g. start a discussion on this mailing list on a topic you'd
like to see addressed in BV 2.0 and I'd consider that worthy to be
listed (ongoing contributions are even better of course). Or e.g.
provide feedback on the upcoming drafts.
So my recommendation for such incoming nominations is to do exactly
that: come to this mailing list, get involved by any means and you are
a true contributor.
--Gunnar
6 years, 1 month
