[bv-dev] Fwd: Should getters be considered methods during validation

[Michael Nascimento]

Your arguments make sense Emmanuel, but I think we also need both
something in ValidatorFactory and per bean - imagine how painful it
could be to annotate every single getter on a large class - to turn it
on.

Regards,
Michael

On Wed, Nov 7, 2012 at 9:36 AM, Hardy Ferentschik <hardy at hibernate.org> wrote:
> Hi,
>
> I think I would like to clarify a few things first. We keep just talking about getters.
> What does this actually mean? Do we talk about any method starting with 'get' or
> do we mean getters for properties in the Java Bean sense (aka getters for fields with
> the matching name)?
>
> Do you want to exclude any method starting with 'get' from method validation or just
> properties getters? If the latter, are we not introducing some quite arbitrary distinction
> between methods starting with 'get'?
>
> Also what's about methods starting with 'is'? Wouldn't we have to exclude them
> as well in this case?
>
> Also, in the current specification (1.0, 3.1.2. Field and property validation) is the intention
> to only validate a getter when it is a Java Bean property (backed up by a matching field)?
> I think this is not very clear and not explicitly tested in the TCK.
>
>
> On 6 Jan 2012, at 6:53 PM, Emmanuel Bernard wrote:
>
>> If we treat getters as regular methods, we would add a new
>> behavior to all existing constrained beans. Things that were constrained
>> at specific lifecycles boundaries would now be constrained every time a
>> getter is called. That would break backward compatibility.
>
> Backward compatibility is indeed an issue. However, instead of imo arbitrarily
> considering a getXYZ not as a method, I would have just not enabled method validation
> out of the box. I would have made it an active choice. Alternatively I would add an option
> to switch between ignoring getters and taking them into consideration for method validation.
> However, I don't think  @ValidateOnCall is a good option though. This seems to me to
> intrusive. I rather add a configuration option for the ValidatorFactory.
>
>> Even if a getter was to be constrained on call - you would probably want
>> to constrain on the setter
>
> What if other method modify the state of the property (not just a setter). Maybe the intend
> is to verify that the object is in a certain state when I request it.
>
>> But I do like the simplicity of the rule claiming that all methods
>> are constrained regardless of their similarity to the Bean
>> specification. I do not currently thing that this argument alone
>> outweighs the other problems.
>
> I think it is a argument for consistency. Excluding getter methods from a general method validation
> framework seems to introduce unnecessary inconsistency and might even exclude the framework
> as general method validation framework of choice.
>
>> ### Forcing a getter to behave as a regular method
>>
>> To solve this use case, we can introduce a `@ValidateOnCall`
>> annotation that should be placed on the getter method.
>
> See above.
>
> --Hardy
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev