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