[jira] [Commented] (WICKET-6499) Support for Bean Validation 2.0

2017-11-18 Thread Thomas Heigl (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-6499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258121#comment-16258121
 ] 

Thomas Heigl commented on WICKET-6499:
--

Ok great, I'll try to provide a PR next week.

> Support for Bean Validation 2.0
> ---
>
> Key: WICKET-6499
> URL: https://issues.apache.org/jira/browse/WICKET-6499
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket-bean-validation
>Reporter: Thomas Heigl
>
> Bean Validation 2.0 and the reference implementation Hibernate Validator 6.0 
> were [recently released|http://beanvalidation.org/2.0/].
> I upgraded my application and discovered that fields annotated with 
> {{@NotEmpty}} and {{@NotBlank}} are not automatically marked as required 
> anymore.
> So I started to investigate.
> h4. Bean Validation 1.x
> Wicket {{PropertyValidator}} marks form components as required if it 
> encounters the {{@NotNull}} annotation on a field:
> {code}
> boolean isRequired()
>   {
>   List constraints = findNotNullConstraints();
>   for (NotNull constraint : constraints)
>   {
>   ...
>   }
>   return false;
>   }
> {code}
> In Bean Validation 1.x, this lookup returns not only properties annotated 
> with 
> - {{@javax.validation.constraints.NotNull}}
> but also properties annotated with  
> - {{@org.hibernate.validator.constraints.NotEmpty}} 
> - {{@org.hibernate.validator.constraints.NotBlank}} 
> because these annotations are implemented as composed constraints:
> {code}
> @NotNull
> @Deprecated
> public @interface NotEmpty {}
> {code}
> {code}
> @NotNull
> @Deprecated
> public @interface NotBlank {}
> {code}
> h4. Bean Validation 2.x
> Both annotations are now deprecated and replaced with "official" versions: 
> - {{javax.validation.constraints.NotEmpty}}
> - {{javax.validation.constraints.NotBlank}}
> The new annotations are *not* implemented as composed constraints, and thus 
> do *not* contain the {{@NotNull}} annotation.
> I asked about the rationale and the recommended solution on the [HV 
> forum|https://forum.hibernate.org/viewtopic.php?f=9=1044998=0] and 
> got the following reply from the Hibernate Team:
> {quote}
> When promoting @NotEmpty and @NotBlank from HV to the Bean Validation spec we 
> decided to define them as composed constraints (as their previous 
> counterparts), but instead leave this as an implementation detail to BV 
> providers. The reason being, that the implementation can be more efficient 
> when using a single constraint validator instead of relying on constraint 
> composition.
> So you'd indeed have to expand your scan to look for @NotNull, @NotEmpty and 
> @NotBlank.
> {quote}
> I suggest that {{PropertyValidator}} should scan for these new annotations 
> when Bean Validation 2.0 is on the classpath.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


wicket git commit: Fixed link to examples site

2017-11-18 Thread adelbene
Repository: wicket
Updated Branches:
  refs/heads/wicket-7.x 884018dcf -> 63ec7f0b6


Fixed link to examples site


Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/63ec7f0b
Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/63ec7f0b
Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/63ec7f0b

Branch: refs/heads/wicket-7.x
Commit: 63ec7f0b6953138515ce29414d460a09d9caac5b
Parents: 884018d
Author: Andrea Del Bene 
Authored: Sat Nov 18 17:13:36 2017 +0100
Committer: Andrea Del Bene 
Committed: Sat Nov 18 17:14:13 2017 +0100

--
 wicket-user-guide/src/main/asciidoc/single.adoc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
--


http://git-wip-us.apache.org/repos/asf/wicket/blob/63ec7f0b/wicket-user-guide/src/main/asciidoc/single.adoc
--
diff --git a/wicket-user-guide/src/main/asciidoc/single.adoc 
b/wicket-user-guide/src/main/asciidoc/single.adoc
index ba4ea7e..b5d846d 100644
--- a/wicket-user-guide/src/main/asciidoc/single.adoc
+++ b/wicket-user-guide/src/main/asciidoc/single.adoc
@@ -5,8 +5,8 @@ The Apache Software Foundation
 :sectlinks:
 
 //custom variables used inside the guide
-:wicket_examples_url: http://examples7x.wicket.apache.org
-:wicket_tutorial_examples_url: http://examples-wickettutorial.rhcloud.com/
+:wicket_examples_url: http://examples7x.wicket.apache.org/wicket-examples
+:wicket_tutorial_examples_url: https://wicket-guide.herokuapp.com/
 
 :sectnums:
 



wicket git commit: Fixed link to examples site

2017-11-18 Thread adelbene
Repository: wicket
Updated Branches:
  refs/heads/master 01e76cf5e -> b230793ba


Fixed link to examples site


Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/b230793b
Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/b230793b
Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/b230793b

Branch: refs/heads/master
Commit: b230793bab0cc53f8c128fe7551e3b1a36e27fbf
Parents: 01e76cf
Author: Andrea Del Bene 
Authored: Sat Nov 18 17:12:10 2017 +0100
Committer: Andrea Del Bene 
Committed: Sat Nov 18 17:13:05 2017 +0100

--
 wicket-user-guide/src/main/asciidoc/single.adoc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
--


http://git-wip-us.apache.org/repos/asf/wicket/blob/b230793b/wicket-user-guide/src/main/asciidoc/single.adoc
--
diff --git a/wicket-user-guide/src/main/asciidoc/single.adoc 
b/wicket-user-guide/src/main/asciidoc/single.adoc
index 4fc1464..f989ff4 100644
--- a/wicket-user-guide/src/main/asciidoc/single.adoc
+++ b/wicket-user-guide/src/main/asciidoc/single.adoc
@@ -7,7 +7,7 @@ The Apache Software Foundation
 :sectnums:
 
 //custom variables used inside the guide
-:wicket_examples_url: http://examples8x.wicket.apache.org
+:wicket_examples_url: http://examples8x.wicket.apache.org/wicket-examples
 :wicket_tutorial_examples_url: https://wicket-guide.herokuapp.com/
 
 == Introduction



[jira] [Commented] (WICKET-6499) Support for Bean Validation 2.0

2017-11-18 Thread Sven Meier (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-6499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16258031#comment-16258031
 ] 

Sven Meier commented on WICKET-6499:


+1 for #4

> Support for Bean Validation 2.0
> ---
>
> Key: WICKET-6499
> URL: https://issues.apache.org/jira/browse/WICKET-6499
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket-bean-validation
>Reporter: Thomas Heigl
>
> Bean Validation 2.0 and the reference implementation Hibernate Validator 6.0 
> were [recently released|http://beanvalidation.org/2.0/].
> I upgraded my application and discovered that fields annotated with 
> {{@NotEmpty}} and {{@NotBlank}} are not automatically marked as required 
> anymore.
> So I started to investigate.
> h4. Bean Validation 1.x
> Wicket {{PropertyValidator}} marks form components as required if it 
> encounters the {{@NotNull}} annotation on a field:
> {code}
> boolean isRequired()
>   {
>   List constraints = findNotNullConstraints();
>   for (NotNull constraint : constraints)
>   {
>   ...
>   }
>   return false;
>   }
> {code}
> In Bean Validation 1.x, this lookup returns not only properties annotated 
> with 
> - {{@javax.validation.constraints.NotNull}}
> but also properties annotated with  
> - {{@org.hibernate.validator.constraints.NotEmpty}} 
> - {{@org.hibernate.validator.constraints.NotBlank}} 
> because these annotations are implemented as composed constraints:
> {code}
> @NotNull
> @Deprecated
> public @interface NotEmpty {}
> {code}
> {code}
> @NotNull
> @Deprecated
> public @interface NotBlank {}
> {code}
> h4. Bean Validation 2.x
> Both annotations are now deprecated and replaced with "official" versions: 
> - {{javax.validation.constraints.NotEmpty}}
> - {{javax.validation.constraints.NotBlank}}
> The new annotations are *not* implemented as composed constraints, and thus 
> do *not* contain the {{@NotNull}} annotation.
> I asked about the rationale and the recommended solution on the [HV 
> forum|https://forum.hibernate.org/viewtopic.php?f=9=1044998=0] and 
> got the following reply from the Hibernate Team:
> {quote}
> When promoting @NotEmpty and @NotBlank from HV to the Bean Validation spec we 
> decided to define them as composed constraints (as their previous 
> counterparts), but instead leave this as an implementation detail to BV 
> providers. The reason being, that the implementation can be more efficient 
> when using a single constraint validator instead of relying on constraint 
> composition.
> So you'd indeed have to expand your scan to look for @NotNull, @NotEmpty and 
> @NotBlank.
> {quote}
> I suggest that {{PropertyValidator}} should scan for these new annotations 
> when Bean Validation 2.0 is on the classpath.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (WICKET-6499) Support for Bean Validation 2.0

2017-11-18 Thread Thomas Heigl (JIRA)

 [ 
https://issues.apache.org/jira/browse/WICKET-6499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Heigl updated WICKET-6499:
-
Description: 
Bean Validation 2.0 and the reference implementation Hibernate Validator 6.0 
were [recently released|http://beanvalidation.org/2.0/].

I upgraded my application and discovered that fields annotated with 
{{@NotEmpty}} and {{@NotBlank}} are not automatically marked as required 
anymore.

So I started to investigate.

h4. Bean Validation 1.x

Wicket {{PropertyValidator}} marks form components as required if it encounters 
the {{@NotNull}} annotation on a field:

{code}
boolean isRequired()
{
List constraints = findNotNullConstraints();
for (NotNull constraint : constraints)
{
...
}
return false;
}
{code}

In Bean Validation 1.x, this lookup returns not only properties annotated with 
- {{@javax.validation.constraints.NotNull}}

but also properties annotated with  
- {{@org.hibernate.validator.constraints.NotEmpty}} 
- {{@org.hibernate.validator.constraints.NotBlank}} 

because these annotations are implemented as composed constraints:

{code}
@NotNull
@Deprecated
public @interface NotEmpty {}
{code}

{code}
@NotNull
@Deprecated
public @interface NotBlank {}
{code}

h4. Bean Validation 2.x

Both annotations are now deprecated and replaced with "official" versions: 
- {{javax.validation.constraints.NotEmpty}}
- {{javax.validation.constraints.NotBlank}}

The new annotations are *not* implemented as composed constraints, and thus do 
*not* contain the {{@NotNull}} annotation.

I asked about the rationale and the recommended solution on the [HV 
forum|https://forum.hibernate.org/viewtopic.php?f=9=1044998=0] and got 
the following reply from the Hibernate Team:

{quote}
When promoting @NotEmpty and @NotBlank from HV to the Bean Validation spec we 
decided to define them as composed constraints (as their previous 
counterparts), but instead leave this as an implementation detail to BV 
providers. The reason being, that the implementation can be more efficient when 
using a single constraint validator instead of relying on constraint 
composition.

So you'd indeed have to expand your scan to look for @NotNull, @NotEmpty and 
@NotBlank.
{quote}

I suggest that {{PropertyValidator}} should scan for these new annotations when 
Bean Validation 2.0 is on the classpath.

  was:
Bean Validation 2.0 and the reference implementation Hibernate Validator 6.0 
were [recently released|http://beanvalidation.org/2.0/].

I upgraded my application and discovered that fields annotated with 
{{@NotEmpty}} and {{@NotBlank}} are not automatically marked as required 
anymore.

So I started to investigate.

h4. Bean Validation 1.x

Wicket {{PropertyValidator}} marks form components as required if it encounters 
the {{@NotNull}} annotation on field:

{code}
boolean isRequired()
{
List constraints = findNotNullConstraints();
for (NotNull constraint : constraints)
{
...
}
return false;
}
{code}

In Bean Validation 1.x, this lookup returns not only properties annotated with 
- {{@javax.validation.constraints.NotNull}}

but also properties annotated with  
- {{@org.hibernate.validator.constraints.NotEmpty}} 
- {{@org.hibernate.validator.constraints.NotBlank}} 

because these annotations are implemented as composed constraints:

{code}
@NotNull
@Deprecated
public @interface NotEmpty {}
{code}

{code}
@NotNull
@Deprecated
public @interface NotBlank {}
{code}

h4. Bean Validation 2.x

Both annotations are now deprecated and replaced with "official" versions: 
- {{javax.validation.constraints.NotEmpty}}
- {{javax.validation.constraints.NotBlank}}

The new annotations are *not* implemented as composed constraints, and thus do 
*not* contain the {{@NotNull}} annotation.

I asked about the rationale and the recommended solution on the [HV 
forum|https://forum.hibernate.org/viewtopic.php?f=9=1044998=0] and got 
the following reply from the Hibernate Team:

{quote}
When promoting @NotEmpty and @NotBlank from HV to the Bean Validation spec we 
decided to define them as composed constraints (as their previous 
counterparts), but instead leave this as an implementation detail to BV 
providers. The reason being, that the implementation can be more efficient when 
using a single constraint validator instead of relying on constraint 
composition.

So you'd indeed have to expand your scan to look for @NotNull, @NotEmpty and 
@NotBlank.
{quote}

I suggest that {{PropertyValidator}} should scan for these new annotations when 
Bean Validation 2.0 is on the classpath.


> Support for Bean Validation 2.0
> ---
>
> Key: WICKET-6499
> URL: 

[jira] [Commented] (WICKET-6499) Support for Bean Validation 2.0

2017-11-18 Thread Maxim Solodovnik (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-6499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16257987#comment-16257987
 ] 

Maxim Solodovnik commented on WICKET-6499:
--

+1 for #4 :)

> Support for Bean Validation 2.0
> ---
>
> Key: WICKET-6499
> URL: https://issues.apache.org/jira/browse/WICKET-6499
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket-bean-validation
>Reporter: Thomas Heigl
>
> Bean Validation 2.0 and the reference implementation Hibernate Validator 6.0 
> were [recently released|http://beanvalidation.org/2.0/].
> I upgraded my application and discovered that fields annotated with 
> {{@NotEmpty}} and {{@NotBlank}} are not automatically marked as required 
> anymore.
> So I started to investigate.
> h4. Bean Validation 1.x
> Wicket {{PropertyValidator}} marks form components as required if it 
> encounters the {{@NotNull}} annotation on field:
> {code}
> boolean isRequired()
>   {
>   List constraints = findNotNullConstraints();
>   for (NotNull constraint : constraints)
>   {
>   ...
>   }
>   return false;
>   }
> {code}
> In Bean Validation 1.x, this lookup returns not only properties annotated 
> with 
> - {{@javax.validation.constraints.NotNull}}
> but also properties annotated with  
> - {{@org.hibernate.validator.constraints.NotEmpty}} 
> - {{@org.hibernate.validator.constraints.NotBlank}} 
> because these annotations are implemented as composed constraints:
> {code}
> @NotNull
> @Deprecated
> public @interface NotEmpty {}
> {code}
> {code}
> @NotNull
> @Deprecated
> public @interface NotBlank {}
> {code}
> h4. Bean Validation 2.x
> Both annotations are now deprecated and replaced with "official" versions: 
> - {{javax.validation.constraints.NotEmpty}}
> - {{javax.validation.constraints.NotBlank}}
> The new annotations are *not* implemented as composed constraints, and thus 
> do *not* contain the {{@NotNull}} annotation.
> I asked about the rationale and the recommended solution on the [HV 
> forum|https://forum.hibernate.org/viewtopic.php?f=9=1044998=0] and 
> got the following reply from the Hibernate Team:
> {quote}
> When promoting @NotEmpty and @NotBlank from HV to the Bean Validation spec we 
> decided to define them as composed constraints (as their previous 
> counterparts), but instead leave this as an implementation detail to BV 
> providers. The reason being, that the implementation can be more efficient 
> when using a single constraint validator instead of relying on constraint 
> composition.
> So you'd indeed have to expand your scan to look for @NotNull, @NotEmpty and 
> @NotBlank.
> {quote}
> I suggest that {{PropertyValidator}} should scan for these new annotations 
> when Bean Validation 2.0 is on the classpath.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Comment Edited] (WICKET-6499) Support for Bean Validation 2.0

2017-11-18 Thread Thomas Heigl (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-6499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16257983#comment-16257983
 ] 

Thomas Heigl edited comment on WICKET-6499 at 11/18/17 9:00 AM:


[~svenmeier]: I can give it a try sure, but we should first decide how we want 
to approach this. I see 4 options for supporting BV 1.x and 2.x at the same 
time:

# Use class loading and reflection to detect BV 2.x support and scan for the 
new annotations that do not exist in the old API
# Add BV 2.x as an optional dependency and create a new implementation 
{{PropertyValidator2x}} that is chosen if BV 2.x is on the class path
# Create a second module {{wicket-bean-validation-2x}} that depends on the new 
API (but duplicates a lot of logic)
# Bump the BV dependency to 2.0 in Wicket 8 and adapt the module accordingly

I'd personally prefer option 4 ;)

How do you usually deal with a situation like this in the Wicket ecosystem?



was (Author: thomas.heigl):
[~svenmeier]: I can give it a try sure, but we should first decide how we want 
to approach this. I see 4 options for supporting BV 1.x and 2.x at the same 
time:

# Use class loading and reflection to detect BV 2.x support and scan for the 
new annotations that do not exist in the old API
# Add BV 2.x as an optional dependency and create a new implementation 
{{PropertyValidator2x}} that is chosen if BV 2x is on the class path
# Create a second module {{wicket-bean-validation-2x}} that depends on the new 
API (but duplicates a lot of logic)
# Bump the BV dependency to 2.0 in Wicket 8 and adapt the module accordingly

I'd personally prefer option 4 ;)

How do you usually deal with a situation like this in the Wicket ecosystem?


> Support for Bean Validation 2.0
> ---
>
> Key: WICKET-6499
> URL: https://issues.apache.org/jira/browse/WICKET-6499
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket-bean-validation
>Reporter: Thomas Heigl
>
> Bean Validation 2.0 and the reference implementation Hibernate Validator 6.0 
> were [recently released|http://beanvalidation.org/2.0/].
> I upgraded my application and discovered that fields annotated with 
> {{@NotEmpty}} and {{@NotBlank}} are not automatically marked as required 
> anymore.
> So I started to investigate.
> h4. Bean Validation 1.x
> Wicket {{PropertyValidator}} marks form components as required if it 
> encounters the {{@NotNull}} annotation on field:
> {code}
> boolean isRequired()
>   {
>   List constraints = findNotNullConstraints();
>   for (NotNull constraint : constraints)
>   {
>   ...
>   }
>   return false;
>   }
> {code}
> In Bean Validation 1.x, this lookup returns not only properties annotated 
> with 
> - {{@javax.validation.constraints.NotNull}}
> but also properties annotated with  
> - {{@org.hibernate.validator.constraints.NotEmpty}} 
> - {{@org.hibernate.validator.constraints.NotBlank}} 
> because these annotations are implemented as composed constraints:
> {code}
> @NotNull
> @Deprecated
> public @interface NotEmpty {}
> {code}
> {code}
> @NotNull
> @Deprecated
> public @interface NotBlank {}
> {code}
> h4. Bean Validation 2.x
> Both annotations are now deprecated and replaced with "official" versions: 
> - {{javax.validation.constraints.NotEmpty}}
> - {{javax.validation.constraints.NotBlank}}
> The new annotations are *not* implemented as composed constraints, and thus 
> do *not* contain the {{@NotNull}} annotation.
> I asked about the rationale and the recommended solution on the [HV 
> forum|https://forum.hibernate.org/viewtopic.php?f=9=1044998=0] and 
> got the following reply from the Hibernate Team:
> {quote}
> When promoting @NotEmpty and @NotBlank from HV to the Bean Validation spec we 
> decided to define them as composed constraints (as their previous 
> counterparts), but instead leave this as an implementation detail to BV 
> providers. The reason being, that the implementation can be more efficient 
> when using a single constraint validator instead of relying on constraint 
> composition.
> So you'd indeed have to expand your scan to look for @NotNull, @NotEmpty and 
> @NotBlank.
> {quote}
> I suggest that {{PropertyValidator}} should scan for these new annotations 
> when Bean Validation 2.0 is on the classpath.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Commented] (WICKET-6499) Support for Bean Validation 2.0

2017-11-18 Thread Thomas Heigl (JIRA)

[ 
https://issues.apache.org/jira/browse/WICKET-6499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16257983#comment-16257983
 ] 

Thomas Heigl commented on WICKET-6499:
--

[~svenmeier]: I can give it a try sure, but we should first decide how we want 
to approach this. I see 4 options for supporting BV 1.x and 2.x at the same 
time:

# Use class loading and reflection to detect BV 2.x support and scan for the 
new annotations that do not exist in the old API
# Add BV 2.x as an optional dependency and create a new implementation 
{{PropertyValidator2x}} that is chosen if BV 2x is on the class path
# Create a second module {{wicket-bean-validation-2x}} that depends on the new 
API (but duplicates a lot of logic)
# Bump the BV dependency to 2.0 in Wicket 8 and adapt the module accordingly

I'd personally prefer option 4 ;)

How do you usually deal with a situation like this in the Wicket ecosystem?


> Support for Bean Validation 2.0
> ---
>
> Key: WICKET-6499
> URL: https://issues.apache.org/jira/browse/WICKET-6499
> Project: Wicket
>  Issue Type: Improvement
>  Components: wicket-bean-validation
>Reporter: Thomas Heigl
>
> Bean Validation 2.0 and the reference implementation Hibernate Validator 6.0 
> were [recently released|http://beanvalidation.org/2.0/].
> I upgraded my application and discovered that fields annotated with 
> {{@NotEmpty}} and {{@NotBlank}} are not automatically marked as required 
> anymore.
> So I started to investigate.
> h4. Bean Validation 1.x
> Wicket {{PropertyValidator}} marks form components as required if it 
> encounters the {{@NotNull}} annotation on field:
> {code}
> boolean isRequired()
>   {
>   List constraints = findNotNullConstraints();
>   for (NotNull constraint : constraints)
>   {
>   ...
>   }
>   return false;
>   }
> {code}
> In Bean Validation 1.x, this lookup returns not only properties annotated 
> with 
> - {{@javax.validation.constraints.NotNull}}
> but also properties annotated with  
> - {{@org.hibernate.validator.constraints.NotEmpty}} 
> - {{@org.hibernate.validator.constraints.NotBlank}} 
> because these annotations are implemented as composed constraints:
> {code}
> @NotNull
> @Deprecated
> public @interface NotEmpty {}
> {code}
> {code}
> @NotNull
> @Deprecated
> public @interface NotBlank {}
> {code}
> h4. Bean Validation 2.x
> Both annotations are now deprecated and replaced with "official" versions: 
> - {{javax.validation.constraints.NotEmpty}}
> - {{javax.validation.constraints.NotBlank}}
> The new annotations are *not* implemented as composed constraints, and thus 
> do *not* contain the {{@NotNull}} annotation.
> I asked about the rationale and the recommended solution on the [HV 
> forum|https://forum.hibernate.org/viewtopic.php?f=9=1044998=0] and 
> got the following reply from the Hibernate Team:
> {quote}
> When promoting @NotEmpty and @NotBlank from HV to the Bean Validation spec we 
> decided to define them as composed constraints (as their previous 
> counterparts), but instead leave this as an implementation detail to BV 
> providers. The reason being, that the implementation can be more efficient 
> when using a single constraint validator instead of relying on constraint 
> composition.
> So you'd indeed have to expand your scan to look for @NotNull, @NotEmpty and 
> @NotBlank.
> {quote}
> I suggest that {{PropertyValidator}} should scan for these new annotations 
> when Bean Validation 2.0 is on the classpath.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)