Support for non-standard Java beans
Description
Environment
is followed up by
relates to
Activity

Gunnar Morling June 15, 2017 at 6:55 AM
Should this be compatible with 5.1 (BV 1.1) and / or 6.0 (or BV 2.0) ?
The latter. 5.x will only receive bug fixes at this point.
Should this be API only (HibernateValidatorConfiguration) or also XML based ?
Having both would be good eventually, but I'd focus on the API first.
Any preference for SPI naming and signature ?
Not really, I'd hope you could come up with a proposal after exploring a bit? A simple predicate won't cut it, as we need to return the name of the represented property, given a method. The input should not be ConstrainedExecutable
as that's an internal implementation type. This might be a good starting point:
If using Java 8 (6.0 version) is simple Predicate<ConstrainedExecutable> sufficient
I don't think so, see above.
Check out how it's done for other things, e.g. ConstraintHelper
. There is no DI or so, all dependencies are passed through the constructors down the object graph. It may be a good idea to make this new functionality available via ExecutableHelper
. That's present in many of the constructor's already, so you'll likely have to adjust only a few places. Also see how ValidatorFactoryImpl
is accessing the HV-specific settings on Configuration
.

Andrei June 14, 2017 at 5:05 PMEdited
I couple of questions.
Should this be compatible with 5.1 (BV 1.1) and / or 6.0 (or BV 2.0) ?
Should this be API only (
HibernateValidatorConfiguration
) or also XML based ?Any preference for SPI naming and signature ? Just a predicate (Single Abstract Method) for
ConstrainedExecutable / Method
or something more evolved ? Can you please give some examples ?If using Java 8 (6.0 version) is simple Predicate<ConstrainedExecutable> sufficient ?
Implementation question
What's recommended way to pass SPI instance from ConfigurationImpl
all the way to PropertyMetadata
or ConstrainedExecutable
?
Example
Say I have the following:
how to make foo
accessible in PropertyMetadata
or ConstrainedExecutable
?

Gunnar Morling June 14, 2017 at 1:03 PM
Yes, the idea would be to add an extension point to Hibernate Validator – i.e. not the spec for the time being – which allows to customize the retrieval of property accessors.
As a starting point check out PropertyMetadata.Builder#accepts() and how it uses ConstrainedExecutable#isGetterMethod() to select only JavaBeans property getters. The logic of the latter would have to be extracted into an SPI, with the current implementation being the default behavior and a way to plug in other implementations via HibernateValidatorConfiguration
.

Andrei June 14, 2017 at 12:29 PM
I will take a look.
Is there something that can be done short-term ? For example, as an extension of implementation (not necessarily spec) ?

Gunnar Morling June 14, 2017 at 7:29 AM
I'm very sympathetic towards the idea of having an extension point (SPI) which makes it more flexible what should be considered as a property accessor. Perhaps you'd be willing to help out and explore such SPI?
Details
Details
Assignee
Reporter

Participants


I see more and more projects start using code generators for their entities. Here are some libraries which generate java code:
Immutables
AutoValue
FreeBuilder
They all seem to adopt direct name accessors instead of getters (from Java Beans):
Example
It seems that hibernate validator still requires POJOs to follow java bean convention. Having standard
getName() / getAge()
works just fine.Is it currently possible to plug custom method name resolution with Validator ?