[
https://issues.apache.org/jira/browse/WICKET-5656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14084613#comment-14084613
]
Martin Grigorov commented on WICKET-5656:
-----------------------------------------
I may be totally off here but here is how I see it:
- org.apache.wicket.bean.validation.ConstraintIterator is not really needed.
All that is needed is its logic to get the *root* constraint descriptors.
- org.apache.wicket.bean.validation.PropertyValidator#findNotNullConstraints()
(or however better name we give it) should return a List<ConstraintDescriptor>
of all ConstraintDescriptors which are either NotNull (the filter) or have
composing constraints which are NotNull.
- org.apache.wicket.bean.validation.PropertyValidator#isRequired() should use
ConstraintDescriptor#getGroups() instead of NotNull#groups()
- org.apache.wicket.bean.validation.PropertyValidator#isRequired() may need
extra logic to handle javax.validation.groups.Default. See
javax.validation.metadata.ConstraintDescriptor#getGroups()
[~ivaynberg] is the above correct ? I may rework it if I'm on the right track
> PropertyResolver does not scan for NotNull in annotation tree
> -------------------------------------------------------------
>
> Key: WICKET-5656
> URL: https://issues.apache.org/jira/browse/WICKET-5656
> Project: Wicket
> Issue Type: Bug
> Components: wicket-bean-validation
> Affects Versions: 6.16.0
> Reporter: Thibault Kruse
> Assignee: Igor Vaynberg
>
> When annotating a field of a bean with e.g.
> org.hibernate.validator.constraints.NotEmpty, this implies
> javax.validation.constraints.NotNull, but PropertyValidator only checks for
> the annotations immediately on the filed not the tree of annotations. As a
> result Wicket does not mark the field as required in the UI, which it should.
> Also PropertyResolver.findNotNullConstraints() is not even protected, so
> cannot be patched in a simple way.
> So as a solution I suggest changing findNotNullConstraints() to be protected
> and rather be something like findConstraints(filter), or
> findConstraints(clazz), and then in that method method recursively invoking
> getComposingConstraints to get all constraints, but collecting only those of
> interest. Possibly some care needs to be taken to prevent infinite recursion
> where constraints are composed of each other (if that compiles).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
