|
Is the difference in your code not that you in once case explicitly pass an annotation based Paranamer, whereas in the other case you rely on the default? In the case where you are using org.hibernate.validator.parameternameprovider.ParanamerParameterNameProvider you are using just the default constructor:
...
ValidatorFactory factory = Validation.byDefaultProvider()
.configure()
.parameterNameProvider(new ParanamerParameterNameProvider())
.buildValidatorFactory();
...
whereas in your custom config you do something like:
...
ValidatorFactory factory = Validation.byDefaultProvider()
.configure()
.parameterNameProvider(new MyrParameterNameProvider(new NameAnnotationParanamer()))
.buildValidatorFactory();
...
By using the default constructor of ParanamerParameterNameProvider the AdaptiveParanamer is used which uses in its turn BytecodeReadingParanamer and DefaultParanamer. See also https://github.com/paul-hammant/paranamer.
If you want to use the annotation approach you need to use the constructor of ParanamerParameterNameProvider which takes a Paranamer instance. Something like:
...
ValidatorFactory factory = Validation.byDefaultProvider()
.configure()
.parameterNameProvider(new ParanamerParameterNameProvider(new NameAnnotationParanamer()))
.buildValidatorFactory();
...
That said, you seem to indicate that your solution with the default ParanamerParameterNameProvider sometimes works and sometimes not? If that really happens using the same artifact, there might indeed be a problem. However, in the default configuration it will depend for example on how the code is compiled and whether debug symbols are available. What I am trying to say is, I would expect that for a given compiled jar, it either works or not, depending on the build process and options.
Also, I am not sure what this all has to do with inheritance!? Could you please clarify your problem and explain what you want to achieve?
|
