-
Notifications
You must be signed in to change notification settings - Fork 580
HV-1363 support for non-standard Java beans #938
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
9b26462
dd51f80
e34276b
c63b86e
4cb8d13
1b55886
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -6,9 +6,8 @@ | |
*/ | ||
package org.hibernate.validator.internal.cfg.context; | ||
|
||
import java.lang.reflect.Method; | ||
|
||
import org.hibernate.validator.cfg.context.MethodConstraintMappingContext; | ||
import org.hibernate.validator.internal.properties.Callable; | ||
|
||
/** | ||
* Constraint mapping creational context representing a method. | ||
|
@@ -17,15 +16,15 @@ | |
*/ | ||
class MethodConstraintMappingContextImpl extends ExecutableConstraintMappingContextImpl implements MethodConstraintMappingContext { | ||
|
||
MethodConstraintMappingContextImpl(TypeConstraintMappingContextImpl<?> typeContext, Method method) { | ||
super( typeContext, method ); | ||
MethodConstraintMappingContextImpl(TypeConstraintMappingContextImpl<?> typeContext, Callable callable) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Note: I don't have your vision about the full patch/future developments so these are real questions. Is this really what we want to do or are we talking about I mean do we expect these things to be compatible with anything else than Considering we are introducing the difference between To be honest, I'm wondering if we should introduce Also wondering if we should create different objects for There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I couldn't think of any other kind of executables/callables at this point. But the idea was to not limit ourselves with something specific if the more generic thing could be used. I'll get back to the Method/Constructor part after I'll go through all the other comments and remind myself of what's happening :) |
||
super( typeContext, callable ); | ||
} | ||
|
||
@Override | ||
public MethodConstraintMappingContext ignoreAnnotations(boolean ignoreAnnotations) { | ||
typeContext.mapping | ||
.getAnnotationProcessingOptions() | ||
.ignoreConstraintAnnotationsOnMember( executable, ignoreAnnotations ); | ||
.ignoreConstraintAnnotationsOnMember( callable, ignoreAnnotations ); | ||
|
||
return this; | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a bit surprised we don't also have an abstraction on
ElementType
. I think it's going to be in the way.It's pretty obvious from the way we have to special case things whereas the
ElementType
could be returned by theProperty
object or theCallable
in the case of a method/constructor.Maybe we could call it
ConstraintLocationType
.AFAICS, it's only exposed in BV in the
TraversableResolver
(and considering it only applies to Java Bean properties (either fields or getters), we could check that theConstraintLocationType
is valid and translate it then call agetElementType()
method which would be present onJavaBeanField
andJavaBeanGetter
) and inConstraintFinder
(we probably could have a translation layer there too).Did you think about it?