Let's hypotethically assume that some scenario needs this. I'm thinking of an application which as different compilation units, so some module might have been compiled with different conventions and need different name resolvers.
Would you enforce such a use case to use different, independently configured ValidatorContext instances? Would that be viable && practical? On 19 March 2018 at 16:47, Guillaume Smet <guillaume.s...@gmail.com> wrote: > Hi, > > So I know we like to have API compatibility discussions these days, so > let's start a new one. > > FWIW, this discussions doesn't come out of the blue, it's based on > discussions we had for one of Marko's PRs. > > In HV, you can set the parameter name provider at the VF level and you can > also override it on a per Validator basis using > HibernateValidatorContext#parameterNameProvider(). > > To be honest, I'm a bit skeptical about the usefulness of overriding this > setting at the Validator level: it really seems to be a global setting, > especially because it has an influence on what could be considered a > metadata and metadata are considered static in HV. > > At the moment, the parameter name is resolved at runtime each time it's > required due to this feature. > > I would like to deprecate the feature for now and possibly remove it in a > future version (I thought about maybe keeping the method for a while but > logging a warning stating it's not doing anything anymore?). > > We expect some runtime performance enhancement (this is not the reason of > this post) but it seems we could also get rid of storing the Executable in > the metadata and reduce our memory footprint for executables, which would > be nice. > > Thoughts? > > -- > Guillaume > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
