BV 2.0 - Add constraints?
by Marco Molteni
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
9 years, 11 months
Promote fail fast?
by Marco Molteni
Hi guys,
What do you think about the 'promotion' of fail-fast (from hibernate
validator) to the BV API?
I see frequently this 2 use cases (in the 9-5 projects) to support the
request ;)
1. batch: there are a lot of batch processes that have to validate the
input data (flat file -> bean -> validation) and return for each bean only
a technical error if at least one field is not valid ('input refused').
When there are millions (e.g. payments transactions) of beans to validate
in a batch and 30-50 fields for each bean the fail-fast saves a lot of time
(and the night is never long enough for all the batches required) ;)
2. REST response: in the validation of REST services often when 2 systems
exchange data the answer in case of error is an HTTP 4xx without many
details. The fail-fast is a time and machine resources saving when your
application is accessed by (hundred of) thousand users through some
external web client (e.g. JS client).
In the do-it-yourself implementations for the 2 uses cases at the first
error an IllegalArgumentException is thrown with the information of the
first error found.
The full test of every field is very well suited for uses cases in which
there is a human to machine communication (e.g. web forms).
If your opinion is positive I can do more investigations if needed.
Cheers
Marco
9 years, 12 months
Making built-in constraints repeatable
by Gunnar Morling
Hi all,
One of the things making life easier in Java 8 is repeatable annotations
[1], for instance allowing to specify several @Pattern constraints, without
the explicit usage of @Pattern.List.
The transition is very smooth for BV built-in constraints, essentially we
just need to mark them with @Repeatable, using the existing inner @List
annotations as containers. Hence I didn't bother to create a separate
proposal document but instead Guillaume and me have prepared changes for
the API and the spec already. You can find the GitHub pull requests at [2]
and [3], respectively.
Speaking of changes to the API sources, we also increased the Java version
to 8, bumped the project version to 2.0.0-SNAPSHOT and we've prepared a
change for BVAL-486 [4] which is about not going through the provider
resolver if a specific provider type is passed into bootstrapping via
Validation#byProvider(). This was a tad inconvenient when e.g. explicitly
bootstrapping the RI under OSGi, where you still had to provide a specific
provider resolver.
Please let me know if you have any concerns or other remarks on any of
these by the end of the week. Silence will be taken as expression of
agreement :)
Cheers,
--Gunnar
[1] https://docs.oracle.com/javase/tutorial/java/annotations/repeating.html
[2] https://github.com/beanvalidation/beanvalidation-api/pull/65
[3] https://github.com/beanvalidation/beanvalidation-spec/pull/111
[4] https://github.com/beanvalidation/beanvalidation-api/pull/66
9 years, 12 months
Some first proposals
by Gunnar Morling
Hi all,
The way we've been working towards changes in BV 1.1 was via a proposal
document for each suggested change, investigating different options, their
pros and cons etc. As needed, we'd also prototype specific approaches in
the RI. Once consensus was reached, someone would modify the spec document
as per the agreed on solution.
Proposals are simple AsciiDoc files living on the website. There are
already a couple of first proposals for BV 2.0 listed [1]. Feedback on
these is highly welcome, either on GitHub (e.g. by commenting inline or
sending a PR with another option for a given issue) or here on the mailing
list.
Hendrik, the one for BVAL-214 ([2], "Ability to validate an object and a
list of changes") may be of specific interest for JavaFX, because it should
improve cross-field validation in UI use cases (think of field "password"
should match field "password confirm"). What we should do for JavaFX in
general is a very interesting topic on its own, but probably better to
discuss that one separately.
Everyone is welcome to work on new proposals themselves. If you are
interested, check out the issues currently marked for 2.0 in the JIRA
tracker [3] and let me know if you'd like to get going on individual items.
This list of BV 2.0 change candidates is not cast in stone (nor will we be
able to address all of it), so if you think something should be (up high)
on that list, please speak up. My personal focus will mostly be on the Java
8 related changes for the time being, with the usage of type level
annotations being the one requiring the most consideration probably.
Cheers,
--Gunnar
[1] http://beanvalidation.org/proposals/
[2] http://beanvalidation.org/proposals/BVAL-214
[3]
https://hibernate.atlassian.net/issues/?jql=project%20%3D%20BVAL%20AND%20...
9 years, 12 months
BV 2.0 - Introductions
by Gunnar Morling
Hi everyone,
I'm very happy to report that the review ballot for the Bean Validation 2.0
JSR proposal was approved by the JCP EC with a great majority [1]!
This means we can get the ball rolling and work towards an early draft of
the new spec revision. As described in [2], the schedule is compact and
thus we'll need to choose the things to tackle wisely. The most important
issue will be making BV fit for Java 8, but we should be able to address
some other requests besides that.
The JSR proposal [3] contains a few potential ideas, but I'm very eager to
learn about your requests and demands from the field. Anything which helps
to further improve usefulness and/or usability of BV is worth discussing.
Note that you don't need to be on the expert group - although you are very
welcome to join [7] - in order to contribute. We also value any inputs by
non-members on this mailing list, the forum [4] and the issue tracker [5].
The JCP 2.10 rules (under which this JSR operates) foresee the role of
"Contributors" which has very low entry barriers.
Before diving into details though, let's have a quick round of
introductions so everyone knows who they are dealing with :)
Let me start:
I'm working as a software engineer in the Hibernate team at Red Hat and
took over the lead of the BV JSR from Emmanuel Bernard (who will remain
active in the EG). In the past I've been contributing to the 1.1 spec (e.g.
method validation), worked on the reference implementation Hibernate
Validator (which I'm also leading now) and the 1.1 TCK. Besides BV, I'm
working on several other projects in the Hibernate universe, most notably
Hibernate OGM (providing object mapping via JPA to NoSQL stores) and
Hibernate Search (providing full-text search for JPA domain models).
I'm looking forward very much to make BV 2.0 happen together with all of
you!
I'll soon start separate thread(s) on some first action items.
--Gunnar
PS: Please subscribe to the beanvalidation-dev list [6] if you haven't done
so yet; it's where discussions mostly will take place. To be sure I've sent
this mail in copy to all those who had signalled an interest in
contributing to BV 2.0 beforehand.
[1] https://www.jcp.org/en/jsr/results?id=5871
[2] http://beanvalidation.org/news/2016/07/15/bean-validation-2-0-is-coming/
[3] https://jcp.org/en/jsr/detail?id=380
[4] https://forum.hibernate.org/viewforum.php?f=26
[5] https://hibernate.atlassian.net/projects/BVAL/summary
[6] http://lists.jboss.org/pipermail/beanvalidation-dev/
[7] https://jcp.org/en/jsr/egnom?id=380
10 years
Three new EG members
by Gunnar Morling
Hi,
I'm very glad to welcome three new members to the BV 2.0 expert group:
Hendrik Ebbers, Marco Molteni and Werner Keil!
Hendrik from Canoo Engineering AG is very active in the JavaFX field and
has lots of experiences when it comes to using BV in the context of UIs and
JavaFX.
Marco Molteni works as an independent consultant and brings a broad range
of experience with applying BV in projects e.g. in the field of banking to
the table.
Werner Keil finally is a long-term member of the Java EE community and is
member of the JCP EC and several other expert groups, amongst them being
Java Money (JSR 354) for which we should discuss integration with BV.
Hendrik, Marco, Werner, I'll leave it to yourselves to introduce you in
greater depth and share your expectations/ideas towards BV 2.0. Welcome
again and great to have you aboard!
--Gunnar
10 years
Spec document converted to AsciiDoc
by Gunnar Morling
Hi all,
In a huge team effort (thanks Sanne, Guillaume et al.!) the BV spec has
been converted from DocBook into AsciiDoc.
This should make the editing and collaboration experience much nicer
(easier syntax, renders much faster, rich diff on GitHub etc.). The
AsciiDoc sources of the individual spec chapters can be found at [1]. A
rendered HTML version is published on beanvalidation.org [2]. Refer to the
README.md in the repo if you want to build the spec yourself locally.
It'd be a great help if everyone could take a look at the document and
report back on any formatting or other issues that may have sneaked in
during conversion. No actual changes to the wording have been made at this
point apart from adding some pointers that this is about BV 2.0 and JSR 380.
Thanks for any feedback,
--Gunnar
[1]
https://github.com/beanvalidation/beanvalidation-spec/tree/master/sources
[2] http://beanvalidation.org/latest-draft/spec/
10 years
