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

["Thomas Heigl (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/WICKET-6499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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<NotNull> 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&t=1044998&start=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)