Last week, our JUG was working with the BV CR-3, we tested it, but had some issues, we posted the result on our site: https://medellinjug.org/.

[url]
https://medellinjug.org/2017/07/16/adop ... tested-it/[/url]

You can pull the code from github https://github.com/medellinjug/beanvalidation-2.0

We tested the new annotations @NotBlank, @NotEmpty, @Email, @FutureOrPresent, @PastOrPresent, @Positive,@PositiveOrZero, @Negative and @NegativeOrZero. Some of them with some issues:



1. There are two diferents languages : @NotBlank, @NotEmpty are in Spanish, the others in English.

2. Two annotations don’t show messages for the validation:@FutureOrPresent and @PastOrPresent

3. @Email validate only the input has a “@” and some text after the @,

4. @FutureOrPresent goes well if the date is next year, with a future date of the this year (2017) there is a validation message, and @PastOrPresent with a future date in the actual ayer (2017) the validation was ignored



We will be grateful if you says us what can be the problems

Hi Hilmer,

Thanks a lot for getting in touch and trying out the BV CR 3. On your questions:



Should be fixed thanks to your patch to the RI :)



Good catch. They were added for the Final release.



The spec doesn't mandate any specific check for @Email, i.e. it's dependent on the implementation. That said, I'd expect you to get a failure (with the RI) if there an "@" but nothing before that (i.e. "@example.com" should be marked as invalid). Could you try out that one?

4. @FutureOrPresent goes well if the date is next year ...

Could you ellaborate a bit on this one? What is your validated data type? And what are the exact values you are validating? In general, the ...OrPresent constraints consider the entire current "date" as valid. What that is, depends on the validated data type, i.e. for Year, the entire current year would be considered valid, for YearMonth, the entire current month would be considered valid and so on.

Thanks a lot for your feedback,

--Gunnar

Hi Gunnar,

We wanna clarify our findings

@Email: We test these values

hilmer@gmail.com Validations said it's a valid e-mail address
hilmer@ Validations said it's an invalid e-mail address
hilmer@gmail Validations said it's a valid e-mail address.

Our doubt is why the last one (hilmer@gmail) pass the validation if this e-mail address is not recognised as a valid e-mail, We had proposed a change on the class engine/src/main/java/org/hibernate/validator/internal/util/DomainNameUtil.java


@FutureOrPresent
We used java.util.Date, the values were
01/01/2017 Validations said it's valid
01/01/2018 Validations said it's valid

Our doubt is why did the validation take January First 2017 as a value of the present, this test was using Java Server Faces, but We made a second test on a local java Class, this test said 01/01/2017 is not a date in the present or the future.

Hi Hilmer,

Thanks for providing feedback on all these issues, that's much appreciated!



We consider this in the RI as valid, as e.g. hilmer@localhost would be a valid address. IIUC, single-part domain names are valid (although uncommon). You can add a stricter validation via @Email#regexp().



That's a bit weird, perhaps you accidentally used another date in your JSF test? If it works with a simple Java class, I'd say nothing is wrong within the RI.

Thanks,

--Gunnar