[
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)
