Hi Andrei, You've come to the right place to discuss such proposals. Supporting other models than JavaBeans is an interesting idea, we've also been thinking about it as part of the reference implementation. It's too late for BV 2.0, but it's definitely something I could envision in a future spec revision. Thanks; we should definitely explore that within the RI. There's also https://hibernate.atlassian.net/browse/HV-1000 which takes the thought a bit further and aims at supporting models not backed by POJOs at all, but e.g. maps (with key/value pairs as properties), JSON strings etc. Naturally, annotations couldn't be used as metadata source for such models, instead constraints would have to be declared programmatically. Perhaps you'd be interested in contributing and exploring the property resolver SPI you suggest? --Gunnar 2017-06-14 6:12 GMT+02:00 Andrei Sereda <andrei(a)sereda.cc&gt;: > Hello, > > Apologies if I hijack this mailing list. Please redirect me to right DL / > forum, if it is the case. > > I would like to inquire if custom method resolution is within the scope of > the spec (or exists already) for beans which don't exactly follow JavaBean > convention. By custom, I mean name() vs getName(). > > I've noticed, lately, the trend to use code generators (Immutables, > FreeBuilder, AutoValue etc.) for domain entities. By default they all use > name() for getters (instead of getName()) : > > @FreeBuilder public interface Person { > @NotBlank String name(); > @Min(16) int age(); .... } > > It would be nice if BeanValidation could support such use-case via pluggable > (getter / setter) method resolver (for example). > > > Thanks in advance, > Andrei. > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev