Support for non-standard Java beans

Description

I see more and more projects start using code generators for their entities. Here are some libraries which generate java code:

  1. Immutables

  2. AutoValue

  3. 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 ?

Environment

None

Activity

Show:

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 PM
Edited

I couple of questions.

  1. Should this be compatible with 5.1 (BV 1.1) and / or 6.0 (or BV 2.0) ?

  2. Should this be API only (HibernateValidatorConfiguration) or also XML based ?

  3. 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 ?

  4. 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?

Fixed

Details

Assignee

Reporter

Participants

Andrei
Gunnar Morling
Marko Bekhta

Components

Fix versions

Priority

Created June 14, 2017 at 3:44 AM
Updated December 11, 2018 at 10:19 AM
Resolved June 20, 2018 at 3:33 PM