3:13 a.m.
2012/11/8 Emmanuel Bernard <emmanuel(a)hibernate.org>
A property according to the JavaBeans specification is either:
- a pair of [PropertyType] get[PropertyName]() / void
set[PropertyName]([PropertyType] value)
- a [PropertyType] get[PropertyName]()
- a void set[PropertyName]([PropertyType] value)
- if PropertyType is boolean, then boolean is[PropertyName]() is accepted
(and preferred)
There are ways to customize that further but that's out of the scope of
this discussion. So to answer your question backing fields are an
implementation detail.
You and Gunnar seem to want a global VF level flag to activate/inactivate
getters as constrained methods. I would like to know your reasons for that.
When I put myself in situations and try and use method level validations, I
can't seem to find it compelling to get a global flag. It would only let me
chose between two evils instead of giving me choice on a per element basis.
Generally I don't think that considering getters during method
validation really is a problem. So I wouldn't really have a problem with
this being the default behavior (which it also is in the proprietary API in
HV 4.3). I'd prefer that over excluding certain named methods from method
validation as this goes against the principle of least surprise and would
feel like an inconsistency to me.
But if validating getters during method validation really is a problem, I'd
expect this to be the case generally throughout an application or system.
Taking the example of JPA entities which used to be validated upon
persisting only and now would their property constraints get validated upon
getter invocation, then I'd prefer to disable getter validation globally
instead of marking each individual property with an annotation.
If I as a user really needed a configuration per element, I could do so
using validation groups. If for instance single constraints should not be
validated upon getter invocation, I could use a group like this:
public static class Foo {
//doesn't get validated during method validation of Default group
@NotNull(groups=AllConstraints.class)
private String getBar() { ... }
//does get validated during method validation
@NotNull
private String getBaz() { ... }
}
//use this e.g. to validate upon entity persisting
public interface AllConstraints extends Default {}
Therefore I feel we shouldn't introduce a new mechanism such as @ValidateOnCall
since the use case is already covered by existing concepts.
Additionally, an annotation might not be the right vehicle for cases where
only single constraints of a given getter shall be excluded from method
validation while other constraints on the same getter should be considered.
--Gunnar
We already discussed the merits of having method validation activated
by
default vs the other way around in the past but if I follow your argument,
I will ask developers who add constraints to their methods to also create a
META-INF/validation.xml in their various modules to activate method
validation ? That seems to go against the current trend to me.
Emmanuel
On 7 nov. 2012, at 12:36, Hardy Ferentschik <hardy(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev