12:19 p.m.
For method validation, we have so far managed to get away with
requiring an annotation based metadata to direct how method validation
behaves.
One question that popped up during the recent write up is whether or not
getters should be considered regular methods and thus be intercepted and
validation by CDI or AspectJ interceptors.
I have my own ideas, but I'd like to get your opinion on the subject.
Emmanuel
12:37 p.m.
On Tue, Oct 23, 2012 at 12:19 PM, Emmanuel Bernard
<emmanuel(a)hibernate.org> wrote:
For method validation, we have so far managed to get away with
requiring an annotation based metadata to direct how method validation
behaves.
One question that popped up during the recent write up is whether or not
getters should be considered regular methods and thus be intercepted and
validation by CDI or AspectJ interceptors.
I have my own ideas, but I'd like to get your opinion on the subject.
Hi, Emmanuel! Great/horrible question. :)
My inclination, for the purposes of the specification, is "a method is
a method" but I'd hope to see implementation-specific mechanisms to
globally disable method validation on getters.
$0.02,
Matt
Emmanuel
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
6:23 a.m.
Any other input? Gunnar and Hardy you had some thoughts on the subject
afair :)
Emmanuel
On Tue 2012-10-23 12:37, Matt Benson wrote:
On Tue, Oct 23, 2012 at 12:19 PM, Emmanuel Bernard
<emmanuel(a)hibernate.org> wrote:
> For method validation, we have so far managed to get away with
> requiring an annotation based metadata to direct how method validation
> behaves.
>
> One question that popped up during the recent write up is whether or not
> getters should be considered regular methods and thus be intercepted and
> validation by CDI or AspectJ interceptors.
>
> I have my own ideas, but I'd like to get your opinion on the subject.
Hi, Emmanuel! Great/horrible question. :)
My inclination, for the purposes of the specification, is "a method is
a method" but I'd hope to see implementation-specific mechanisms to
globally disable method validation on getters.
$0.02,
Matt
>
> Emmanuel
> _______________________________________________
> 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
12:31 p.m.
Hi,
I think getters should be handled as any other methods during method validation.
Not considering them during method validation would IMO be some form
irregularity, causing getter-named methods not to be validated
although a user might expect it:
//subject to method validation
public class OrderService {
//not validated upon invocation
@NotNull
List<Order> getAllOrders() { ... }
//validated upon invocation
@NotNull
Order findOrderById(long id) { ... }
}
I'd also expect that in many cases different types/objects are subject
to method validation than to validation of property-level constraints.
IMO the former typically applies more on a service level (e.g. via
CDI), while the latter typically applies to model objects/bean (e.g.
via JPA), so maybe there is not really a big area of overlap.
Things of course change a bit when taking technologies such as AspectJ
into account which could apply a method validation interceptor to any
kind of object. But also then I'd say a validation of getter
(property) constraints during method validation shouldn't do any harm.
One could still make use of validation groups to control which
constraints are to be applied.
Maybe we could even consider providing a mechanism to optionally apply
getter constraints upon invocation of the corresponding setter to
avoid storing illegal parameter values in the first place?
@Matt: How is it in Apache Validation, are there any mechanisms to
control the exact behavior? In HV, getters are handled as any other
methods.
--Gunnar
2012/10/26 Emmanuel Bernard <emmanuel(a)hibernate.org>:
Any other input? Gunnar and Hardy you had some thoughts on the
subject
afair :)
Emmanuel
On Tue 2012-10-23 12:37, Matt Benson wrote:
> On Tue, Oct 23, 2012 at 12:19 PM, Emmanuel Bernard
> <emmanuel(a)hibernate.org> wrote:
> > For method validation, we have so far managed to get away with
> > requiring an annotation based metadata to direct how method validation
> > behaves.
> >
> > One question that popped up during the recent write up is whether or not
> > getters should be considered regular methods and thus be intercepted and
> > validation by CDI or AspectJ interceptors.
> >
> > I have my own ideas, but I'd like to get your opinion on the subject.
>
> Hi, Emmanuel! Great/horrible question. :)
>
> My inclination, for the purposes of the specification, is "a method is
> a method" but I'd hope to see implementation-specific mechanisms to
> globally disable method validation on getters.
>
> $0.02,
> Matt
>
> >
> > Emmanuel
> > _______________________________________________
> > 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
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
12:47 p.m.
Hi Gunnar,
I'm not intimately familiar with Apache BVal's custom method
validation module, but from what I can tell at a high level we
likewise have no special handling for getter methods. When I spoke of
implementation-specific mechanisms for ignoring these (or, more
generally, any pattern the user might like to configure), I thought
more along the lines of the integration modules responsible for
actually invoking methods of MethodValidator (which Apache BVal does
not provide).
br,
Matt
On Fri, Oct 26, 2012 at 12:31 PM, Gunnar Morling <gunnar(a)hibernate.org> wrote:
Hi,
I think getters should be handled as any other methods during method validation.
Not considering them during method validation would IMO be some form
irregularity, causing getter-named methods not to be validated
although a user might expect it:
//subject to method validation
public class OrderService {
//not validated upon invocation
@NotNull
List<Order> getAllOrders() { ... }
//validated upon invocation
@NotNull
Order findOrderById(long id) { ... }
}
I'd also expect that in many cases different types/objects are subject
to method validation than to validation of property-level constraints.
IMO the former typically applies more on a service level (e.g. via
CDI), while the latter typically applies to model objects/bean (e.g.
via JPA), so maybe there is not really a big area of overlap.
Things of course change a bit when taking technologies such as AspectJ
into account which could apply a method validation interceptor to any
kind of object. But also then I'd say a validation of getter
(property) constraints during method validation shouldn't do any harm.
One could still make use of validation groups to control which
constraints are to be applied.
Maybe we could even consider providing a mechanism to optionally apply
getter constraints upon invocation of the corresponding setter to
avoid storing illegal parameter values in the first place?
@Matt: How is it in Apache Validation, are there any mechanisms to
control the exact behavior? In HV, getters are handled as any other
methods.
--Gunnar
2012/10/26 Emmanuel Bernard <emmanuel(a)hibernate.org>:
> Any other input? Gunnar and Hardy you had some thoughts on the subject
> afair :)
>
> Emmanuel
>
> On Tue 2012-10-23 12:37, Matt Benson wrote:
>> On Tue, Oct 23, 2012 at 12:19 PM, Emmanuel Bernard
>> <emmanuel(a)hibernate.org> wrote:
>> > For method validation, we have so far managed to get away with
>> > requiring an annotation based metadata to direct how method validation
>> > behaves.
>> >
>> > One question that popped up during the recent write up is whether or not
>> > getters should be considered regular methods and thus be intercepted and
>> > validation by CDI or AspectJ interceptors.
>> >
>> > I have my own ideas, but I'd like to get your opinion on the subject.
>>
>> Hi, Emmanuel! Great/horrible question. :)
>>
>> My inclination, for the purposes of the specification, is "a method is
>> a method" but I'd hope to see implementation-specific mechanisms to
>> globally disable method validation on getters.
>>
>> $0.02,
>> Matt
>>
>> >
>> > Emmanuel
>> > _______________________________________________
>> > 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
> _______________________________________________
> 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
7:17 p.m.
On 26 Oct 2012, at 19:31, Gunnar Morling <gunnar(a)hibernate.org> wrote:
I think getters should be handled as any other methods during method
validation.
+1
Not considering them during method validation would IMO be some form
irregularity, causing getter-named methods not to be validated
although a user might expect it:
+1
From the method validation point of view there is just no reason to
treat getXYZ() differently.
I rather have two validations of the same constraints
happening, but I don't think it will be a big problem in most cases.
A provider could always choose to make it configurable.
--hardy
10:36 a.m.
I have my own ideas, but I'd like to get your opinion on the
subject.
So what's your take on this, Emmanuel?
Handling getters as normal methods in the spec and leaving it to providers
to make other behavior configurable seems reasonable to me.
--Gunnar
2012/10/27 Hardy Ferentschik <hardy(a)hibernate.org>
On 26 Oct 2012, at 19:31, Gunnar Morling <gunnar(a)hibernate.org> wrote:
> I think getters should be handled as any other methods during method
validation.
+1
> Not considering them during method validation would IMO be some form
> irregularity, causing getter-named methods not to be validated
> although a user might expect it:
+1
>From the method validation point of view there is just no reason to treat
getXYZ() differently.
I rather have two validations of the same constraints happening, but I
don't think it will be a big problem in most cases.
A provider could always choose to make it configurable.
--hardy
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
11:53 a.m.
Well yes as you can imagine I do think getters should not be considered
methods. Let me try and give you my arguments.
## Backward compatibility
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.
Even if a getter was to be constrained on call - you would probably want
to constrain on the setter - it's quite unlikely that existing attribute
style constraints would be the same as the method ones. They would likely
use different groups.
## 80% - 20% rule
It seems to be that amongst the getXxx() methods, there is a whole
lot more getters than action methods. That's why making getXxx()
act as attributes does fly for me.
## Interception technology
Someone could mitigate the backward compatibility issue by arguing
that CDI beans are not that often hosting getters.
I am not sure that is true but even if it was, this eclipses more
thorough interception technologies like AspectJ which could intercept
all getter calls even possibly from the JPA or other bean data
providers.
## But
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.
Regardless, there are situations where action methods look like
getters.
### 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.
### Should we leave this undefined in the spec?
A "solution" could be to leave this undefined in the specification
and let providers provide the right mechanisms.
I don't think this would be the right approach. This is an important
enough use case for us to cover it I think. Additional means of
adjusting the behavior can be left to providers.
What do you think?
Emmanuel
On Sat 2012-11-03 16:36, Gunnar Morling wrote:
> I have my own ideas, but I'd like to get your opinion on the
subject.
So what's your take on this, Emmanuel?
Handling getters as normal methods in the spec and leaving it to providers
to make other behavior configurable seems reasonable to me.
--Gunnar
2012/10/27 Hardy Ferentschik <hardy(a)hibernate.org>
>
>
>
>
> On 26 Oct 2012, at 19:31, Gunnar Morling <gunnar(a)hibernate.org> wrote:
>
> > I think getters should be handled as any other methods during method
> validation.
>
> +1
>
> > Not considering them during method validation would IMO be some form
> > irregularity, causing getter-named methods not to be validated
> > although a user might expect it:
>
> +1
> >From the method validation point of view there is just no reason to treat
> getXYZ() differently.
> I rather have two validations of the same constraints happening, but I
> don't think it will be a big problem in most cases.
>
> A provider could always choose to make it configurable.
>
> --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
5:36 a.m.
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
5:42 a.m.
New subject: Fwd: Should getters be considered methods during validation
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(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
7:22 a.m.
Hi,
2012/11/7 Hardy Ferentschik <hardy(a)hibernate.org>
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.
A JavaBeans property IMO doesn't have to be backed by a field. Properties
are identified looking for methods in the form
public <PropertyType> get<PropertyName>();
public void set<PropertyName>(<PropertyType> a);
There may be read-/writable, read-only and write-only properties, For
boolean properties the form
public boolean is<PropertyName>();
is allowed for the read method (see [1] and [2]). There may also be
properties which are computed dynamically.
So AFAICS we would have to exclude all methods adhering to the pattern
<PropertyType>
{get|is}<PropertyName>() from method-validation. As outlined before this
would be kind of irregular.
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.
Right, in case a user actively enables method validation, there should be
no surprise for the user if getter methods are validated upon invocation.
That's also the approach followed by Seam Validation and Spring 3.1, both
integrating with the proprietary method validation feature of Hibernate
Validator 4.2. I'm also not aware of any issue, bug report in HV etc.
regarding getters being validated.
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.
A configuration option on VF might indeed be a possibility. I think
validating getter methods should be the default setting :)
> 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.
+1
> ### 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.
No big fan of an annotation either. Globally configuring this makes more
sense IMO. If really fine-grained control is required, validation groups
may be used.
--Hardy
--Gunnar
[1] http://docs.oracle.com/javase/tutorial/javabeans/writing/properties.html
[2]
http://download.oracle.com/otndocs/jcp/7224-javabeans-1.01-fr-spec-oth-JS...
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
5:41 p.m.
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.
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
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
4:13 a.m.
I have to back up Gunnar on this one on all counts :-)
On 9 Jan 2012, at 10:13 AM, Gunnar Morling wrote:
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.
+1
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.
+1
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:
+1
Are not more people have an opinion on this issue?
--Hardy
2:44 p.m.
hi @ all,
@ "treat getter-methods as regular methods for method-validation":
there are cases which would benefit from it, but such a behaviour can also
break a lot!
-> if we support it:
imo we need a global config option as well as an api for de-/activating it.
in case of the api we would also need a possibility for de-/activating it
dynamically for one validation process. e.g. in a jsf application there is
only one phase (invoke application) of the request-lifecycle for which such
a feature could make sense (and for a lot of applications not even there).
in all other phases it just doesn't make sense and it would just be a
performance penalty which only leads to side-effects you can hardly control
(if a jsf implementation doesn't handle it explicitly).
that's imo also true for many other constellations which are independent of
jsf.
regards,
gerhard
2012/11/9 Hardy Ferentschik <hardy(a)hibernate.org>
I have to back up Gunnar on this one on all counts :-)
On 9 Jan 2012, at 10:13 AM, Gunnar Morling wrote:
> 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.
+1
> 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.
+1
> 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:
+1
Are not more people have an opinion on this issue?
--Hardy
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
10:52 a.m.
I tried to summarize all the discussions at http://beanvalidation.org/proposals/BVAL-327/
While I wish we could go the easy way and consider getters as methods, I
really really fear that we would create a time bomb.
I also polled people at Devoxx trying to explain the pros and cons
and an overwhelming majority of people wanted to not consider getters
as regular constrained methods.
Emmanuel
On Tue 2012-10-23 18:19, Emmanuel Bernard wrote:
For method validation, we have so far managed to get away with
requiring an annotation based metadata to direct how method validation
behaves.
One question that popped up during the recent write up is whether or not
getters should be considered regular methods and thus be intercepted and
validation by CDI or AspectJ interceptors.
I have my own ideas, but I'd like to get your opinion on the subject.
Emmanuel
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
1:32 p.m.
hi @ all,
i agree with emmanuel (as mentioned earlier).
@emmanuel:
thx for writing the summary!
short addition:
we also have to think about implicit grouping here.
regards,
gerhard
2012/11/21 Emmanuel Bernard <emmanuel(a)hibernate.org>
I tried to summarize all the discussions at
http://beanvalidation.org/proposals/BVAL-327/
While I wish we could go the easy way and consider getters as methods, I
really really fear that we would create a time bomb.
I also polled people at Devoxx trying to explain the pros and cons
and an overwhelming majority of people wanted to not consider getters
as regular constrained methods.
Emmanuel
On Tue 2012-10-23 18:19, Emmanuel Bernard wrote:
> For method validation, we have so far managed to get away with
> requiring an annotation based metadata to direct how method validation
> behaves.
>
> One question that popped up during the recent write up is whether or not
> getters should be considered regular methods and thus be intercepted and
> validation by CDI or AspectJ interceptors.
>
> I have my own ideas, but I'd like to get your opinion on the subject.
>
> Emmanuel
> _______________________________________________
> 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
1:47 p.m.
Implicit grouping?
On 21 nov. 2012, at 20:32, Gerhard Petracek <gerhard.petracek(a)gmail.com> wrote:
hi @ all,
i agree with emmanuel (as mentioned earlier).
@emmanuel:
thx for writing the summary!
short addition:
we also have to think about implicit grouping here.
regards,
gerhard
2012/11/21 Emmanuel Bernard <emmanuel(a)hibernate.org>
> I tried to summarize all the discussions at
http://beanvalidation.org/proposals/BVAL-327/
>
> While I wish we could go the easy way and consider getters as methods, I
> really really fear that we would create a time bomb.
>
> I also polled people at Devoxx trying to explain the pros and cons
> and an overwhelming majority of people wanted to not consider getters
> as regular constrained methods.
>
> Emmanuel
>
> On Tue 2012-10-23 18:19, Emmanuel Bernard wrote:
> > For method validation, we have so far managed to get away with
> > requiring an annotation based metadata to direct how method validation
> > behaves.
> >
> > One question that popped up during the recent write up is whether or not
> > getters should be considered regular methods and thus be intercepted and
> > validation by CDI or AspectJ interceptors.
> >
> > I have my own ideas, but I'd like to get your opinion on the subject.
> >
> > Emmanuel
> > _______________________________________________
> > 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
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
2:40 p.m.
someone >could< argue that users should just use constraints at getter
methods, if they really want to ensure a valid state at every access of a
property.
without @ValidateOnCall that's an issue in case of implicit grouping -
there you only have methods...
regards,
gerhard
2012/11/21 Emmanuel Bernard <emmanuel(a)hibernate.org>
Implicit grouping?
On 21 nov. 2012, at 20:32, Gerhard Petracek <gerhard.petracek(a)gmail.com>
wrote:
hi @ all,
i agree with emmanuel (as mentioned earlier).
@emmanuel:
thx for writing the summary!
short addition:
we also have to think about implicit grouping here.
regards,
gerhard
2012/11/21 Emmanuel Bernard <emmanuel(a)hibernate.org>
> I tried to summarize all the discussions at
> http://beanvalidation.org/proposals/BVAL-327/
>
> While I wish we could go the easy way and consider getters as methods, I
> really really fear that we would create a time bomb.
>
> I also polled people at Devoxx trying to explain the pros and cons
> and an overwhelming majority of people wanted to not consider getters
> as regular constrained methods.
>
> Emmanuel
>
> On Tue 2012-10-23 18:19, Emmanuel Bernard wrote:
> > For method validation, we have so far managed to get away with
> > requiring an annotation based metadata to direct how method validation
> > behaves.
> >
> > One question that popped up during the recent write up is whether or not
> > getters should be considered regular methods and thus be intercepted and
> > validation by CDI or AspectJ interceptors.
> >
> > I have my own ideas, but I'd like to get your opinion on the subject.
> >
> > Emmanuel
> > _______________________________________________
> > 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
>
_______________________________________________
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
9:50 a.m.
That should hopefully be the last round. Here are the alternatives that
I think are viable http://goo.gl/ubjn3
Please give your feedback.
Emmanuel
On Tue 2012-10-23 18:19, Emmanuel Bernard wrote:
For method validation, we have so far managed to get away with
requiring an annotation based metadata to direct how method validation
behaves.
One question that popped up during the recent write up is whether or not
getters should be considered regular methods and thus be intercepted and
validation by CDI or AspectJ interceptors.
I have my own ideas, but I'd like to get your opinion on the subject.
Emmanuel
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
12:32 p.m.
+1 for 2.b but -1 for a package annotation and/or config.
regards,
gerhard
2012/12/11 Emmanuel Bernard <emmanuel(a)hibernate.org>
That should hopefully be the last round. Here are the alternatives
that
I think are viable http://goo.gl/ubjn3
Please give your feedback.
Emmanuel
On Tue 2012-10-23 18:19, Emmanuel Bernard wrote:
> For method validation, we have so far managed to get away with
> requiring an annotation based metadata to direct how method validation
> behaves.
>
> One question that popped up during the recent write up is whether or not
> getters should be considered regular methods and thus be intercepted and
> validation by CDI or AspectJ interceptors.
>
> I have my own ideas, but I'd like to get your opinion on the subject.
>
> Emmanuel
> _______________________________________________
> 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
2:29 a.m.
Can you elaborate on why you don't like package level definitions?
My reason for not liking is is that is requires people to navigate their packages to see
if the behavior has been redefined. But I like it as most of the time, categories of
artifacts like JPA entities or model in general, action services etc are in separate
packages so setting a behavior per category becomes very easy.
On 11 déc. 2012, at 19:32, Gerhard Petracek <gerhard.petracek(a)gmail.com> wrote:
+1 for 2.b but -1 for a package annotation and/or config.
regards,
gerhard
2012/12/11 Emmanuel Bernard <emmanuel(a)hibernate.org>
> That should hopefully be the last round. Here are the alternatives that
> I think are viable http://goo.gl/ubjn3
>
> Please give your feedback.
>
> Emmanuel
>
> On Tue 2012-10-23 18:19, Emmanuel Bernard wrote:
> > For method validation, we have so far managed to get away with
> > requiring an annotation based metadata to direct how method validation
> > behaves.
> >
> > One question that popped up during the recent write up is whether or not
> > getters should be considered regular methods and thus be intercepted and
> > validation by CDI or AspectJ interceptors.
> >
> > I have my own ideas, but I'd like to get your opinion on the subject.
> >
> > Emmanuel
> > _______________________________________________
> > 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
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
5:01 a.m.
+1 for 2b as well and I am fine with package annotation. Given that many people group
their packages
around things like domain vs service classes, I think it can make configuration easier.
I have to admit that 1b is growing on me, if getters would just not be excluded per
default.
In contrast to Sebastian I actually think that if a user configures its app to use method
validation via some sort of interceptor or similar he
wants it to occur for all methods. If a getter is annotated with @NotNull and I call this
method I don't care whether
is is returning a state variable or whether this is a calculated value. The returned value
is supposed to be non
null.
Note, I am still against enabling method validation per default in a CDI environment. I
still think it should an active choice to enable the
appropriate technology. This also mitigates the problem of backwards compatibility imo.
--Hardy
On 11 Jan 2012, at 7:32 PM, Gerhard Petracek <gerhard.petracek(a)gmail.com> wrote:
+1 for 2.b but -1 for a package annotation and/or config.
2:02 p.m.
i had a nice discussion with matt.
since bv 1.0 only supports one validation.xml, i'm ok with a package config
in validation.xml.
however, package annotations are in most cases just unexpected (and
error-prone).
(e.g. in deltaspike we dropped such annotations because of that.)
@IsInvariant vs @ValidateOnCall:
still +1 for @ValidateOnCall - imo it's easier for users, because it
describes what will be triggered.
regards,
gerhard
2012/12/12 Hardy Ferentschik <hardy(a)hibernate.org>
+1 for 2b as well and I am fine with package annotation. Given that
many
people group their packages
around things like domain vs service classes, I think it can make
configuration easier.
I have to admit that 1b is growing on me, if getters would just not be
excluded per default.
In contrast to Sebastian I actually think that if a user configures its
app to use method validation via some sort of interceptor or similar he
wants it to occur for all methods. If a getter is annotated with @NotNull
and I call this method I don't care whether
is is returning a state variable or whether this is a calculated value.
The returned value is supposed to be non
null.
Note, I am still against enabling method validation per default in a CDI
environment. I still think it should an active choice to enable the
appropriate technology. This also mitigates the problem of backwards
compatibility imo.
--Hardy
On 11 Jan 2012, at 7:32 PM, Gerhard Petracek <gerhard.petracek(a)gmail.com>
wrote:
> +1 for 2.b but -1 for a package annotation and/or config.
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
3:28 a.m.
On Wed 2012-12-12 21:02, Gerhard Petracek wrote:
i had a nice discussion with matt.
since bv 1.0 only supports one validation.xml, i'm ok with a package config
in validation.xml.
however, package annotations are in most cases just unexpected (and
error-prone).
(e.g. in deltaspike we dropped such annotations because of that.)
I am curious about that. What makes you say that? What made them
error-prone for Deltaspike?
You mean unexpected because people are not used to them?
Emmanuel
9:40 a.m.
I think folk not being used to package annotations was a big part of
Gerhard's objections, but what I personally find more problematic is the
fact that multiple jars could conceivably include annotations for the same
package. We might respond to that with a rule that a package annotation is
only applied to the archive in which it is found, but then, AFAICT, an
implementor would have to resort to bytecode analysis in order to sort out
which setting applies to which jar. That could be more cleanly done by
using a resource-based mechanism for package configs per containing jar,
but then we're left with the IMO somewhat ugly situation of disparate
mechanisms for package config vs. everything else.
Matt
On Thu, Dec 13, 2012 at 3:28 AM, Emmanuel Bernard <emmanuel(a)hibernate.org>wrote:
On Wed 2012-12-12 21:02, Gerhard Petracek wrote:
> i had a nice discussion with matt.
> since bv 1.0 only supports one validation.xml, i'm ok with a package
config
> in validation.xml.
> however, package annotations are in most cases just unexpected (and
> error-prone).
> (e.g. in deltaspike we dropped such annotations because of that.)
I am curious about that. What makes you say that? What made them
error-prone for Deltaspike?
You mean unexpected because people are not used to them?
Emmanuel
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
10:58 a.m.
Having multiple definitions of package annotations for a given package (via split
packages) is equivalent to having the same class name used twice in a split package. The
first version found in your class path is the one used by the VM.
I don't think we should use a different rule. And to me the same class define twice is
of the same level of error as a package-info.java defined twice for the same package.
On 13 déc. 2012, at 16:40, Matt Benson <mbenson(a)apache.org> wrote:
I think folk not being used to package annotations was a big part of
Gerhard's objections, but what I personally find more problematic is the fact that
multiple jars could conceivably include annotations for the same package. We might
respond to that with a rule that a package annotation is only applied to the archive in
which it is found, but then, AFAICT, an implementor would have to resort to bytecode
analysis in order to sort out which setting applies to which jar. That could be more
cleanly done by using a resource-based mechanism for package configs per containing jar,
but then we're left with the IMO somewhat ugly situation of disparate mechanisms for
package config vs. everything else.
Matt
On Thu, Dec 13, 2012 at 3:28 AM, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
> On Wed 2012-12-12 21:02, Gerhard Petracek wrote:
> > i had a nice discussion with matt.
> > since bv 1.0 only supports one validation.xml, i'm ok with a package config
> > in validation.xml.
> > however, package annotations are in most cases just unexpected (and
> > error-prone).
> > (e.g. in deltaspike we dropped such annotations because of that.)
>
> I am curious about that. What makes you say that? What made them
> error-prone for Deltaspike?
> You mean unexpected because people are not used to them?
>
> Emmanuel
> _______________________________________________
> 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
5:12 p.m.
if everything is fine in an application, you won't see issues with package
annotations.
that users aren't used to it is an important part, because package
annotations are quite hidden and usually unexpected.
esp. because they are quite unexpected, it can happen pretty easily e.g.
during a refactoring/cleanup/... that the application behaves differently
afterwards, but you don't recognize it immediately and later on most people
just check the history of config file/s (and not the package-info).
@ "... the first version found ...":
yes - the behaviour you described is correct, but that's imo even worse.
such issues are sometimes hard enough with classes (e.g. there are
ee-servers which behave differently depending on the names of the archives
-> something can work in application x and in application y there is the
same setup but it fails due to different archive-names). since such issues
are around for years a lot of people know about them, but imo issues caused
by package annotations are harder to find, because package annotations are
just unexpected and it's hard(er) to find the meta-data if it's e.g. a
leftover in a different jar than the one you are looking at.
fyi: mark just told me that the cdi-eg dropped package annotations as well.
regards,
gerhard
2012/12/13 Emmanuel Bernard <emmanuel(a)hibernate.org>
Having multiple definitions of package annotations for a given
package
(via split packages) is equivalent to having the same class name used twice
in a split package. The first version found in your class path is the one
used by the VM.
I don't think we should use a different rule. And to me the same class
define twice is of the same level of error as a package-info.java defined
twice for the same package.
On 13 déc. 2012, at 16:40, Matt Benson <mbenson(a)apache.org> wrote:
I think folk not being used to package annotations was a big part of
Gerhard's objections, but what I personally find more problematic is the
fact that multiple jars could conceivably include annotations for the same
package. We might respond to that with a rule that a package annotation is
only applied to the archive in which it is found, but then, AFAICT, an
implementor would have to resort to bytecode analysis in order to sort out
which setting applies to which jar. That could be more cleanly done by
using a resource-based mechanism for package configs per containing jar,
but then we're left with the IMO somewhat ugly situation of disparate
mechanisms for package config vs. everything else.
Matt
On Thu, Dec 13, 2012 at 3:28 AM, Emmanuel Bernard <emmanuel(a)hibernate.org>wrote:
> On Wed 2012-12-12 21:02, Gerhard Petracek wrote:
> > i had a nice discussion with matt.
> > since bv 1.0 only supports one validation.xml, i'm ok with a package
> config
> > in validation.xml.
> > however, package annotations are in most cases just unexpected (and
> > error-prone).
> > (e.g. in deltaspike we dropped such annotations because of that.)
>
> I am curious about that. What makes you say that? What made them
> error-prone for Deltaspike?
> You mean unexpected because people are not used to them?
>
> Emmanuel
> _______________________________________________
> 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
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
11:42 a.m.
OK, we have had experience with packaged annotations for both Hibernate
Search and Hibernate ORM and I have personally not seen people confused by
them.
I am a bit uneasy about offering an XML only feature (or an annotation
only feature for what it is worth). So we would go for an all or nothing
here. Hardy and I feel that package annotations are the natural
solution to the problem but if people feel uneasy about them, we can
offer them as a provider extension only.
About CDI, I don't know the exact reason for them to drop package
annotations but I know a few reasons why it would be inconvenient for them.
CDI does scanning and that creates a significant performance bottleneck as class
loading is dead slow in Java. So forcing CDI impl to load all classes
within a package can be seen as costly though I have had discussions with
the JBoss AS 7 lead and Pete from CDI about how that would not be that
bad.
In our case however, we don't need any scanning, we simply need to load
the package-info of the package a given constrained method bean is in to
find the expected behavior. Such lookup is unlikely to make any
significant performance difference.
Emmanuel
On Sat 2012-12-15 0:12, Gerhard Petracek wrote:
if everything is fine in an application, you won't see issues
with package
annotations.
that users aren't used to it is an important part, because package
annotations are quite hidden and usually unexpected.
esp. because they are quite unexpected, it can happen pretty easily e.g.
during a refactoring/cleanup/... that the application behaves differently
afterwards, but you don't recognize it immediately and later on most people
just check the history of config file/s (and not the package-info).
@ "... the first version found ...":
yes - the behaviour you described is correct, but that's imo even worse.
such issues are sometimes hard enough with classes (e.g. there are
ee-servers which behave differently depending on the names of the archives
-> something can work in application x and in application y there is the
same setup but it fails due to different archive-names). since such issues
are around for years a lot of people know about them, but imo issues caused
by package annotations are harder to find, because package annotations are
just unexpected and it's hard(er) to find the meta-data if it's e.g. a
leftover in a different jar than the one you are looking at.
fyi: mark just told me that the cdi-eg dropped package annotations as well.
regards,
gerhard
2012/12/13 Emmanuel Bernard <emmanuel(a)hibernate.org>
> Having multiple definitions of package annotations for a given package
> (via split packages) is equivalent to having the same class name used twice
> in a split package. The first version found in your class path is the one
> used by the VM.
> I don't think we should use a different rule. And to me the same class
> define twice is of the same level of error as a package-info.java defined
> twice for the same package.
>
> On 13 déc. 2012, at 16:40, Matt Benson <mbenson(a)apache.org> wrote:
>
> I think folk not being used to package annotations was a big part of
> Gerhard's objections, but what I personally find more problematic is the
> fact that multiple jars could conceivably include annotations for the same
> package. We might respond to that with a rule that a package annotation is
> only applied to the archive in which it is found, but then, AFAICT, an
> implementor would have to resort to bytecode analysis in order to sort out
> which setting applies to which jar. That could be more cleanly done by
> using a resource-based mechanism for package configs per containing jar,
> but then we're left with the IMO somewhat ugly situation of disparate
> mechanisms for package config vs. everything else.
>
> Matt
>
>
> On Thu, Dec 13, 2012 at 3:28 AM, Emmanuel Bernard
<emmanuel(a)hibernate.org>wrote:
>
>> On Wed 2012-12-12 21:02, Gerhard Petracek wrote:
>> > i had a nice discussion with matt.
>> > since bv 1.0 only supports one validation.xml, i'm ok with a package
>> config
>> > in validation.xml.
>> > however, package annotations are in most cases just unexpected (and
>> > error-prone).
>> > (e.g. in deltaspike we dropped such annotations because of that.)
>>
>> I am curious about that. What makes you say that? What made them
>> error-prone for Deltaspike?
>> You mean unexpected because people are not used to them?
>>
>> Emmanuel
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> 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
2:24 p.m.
+1 on everything Hardy said :) There's not really much I could add.
--Gunnar
2012/12/12 Hardy Ferentschik <hardy(a)hibernate.org>
+1 for 2b as well and I am fine with package annotation. Given that
many
people group their packages
around things like domain vs service classes, I think it can make
configuration easier.
I have to admit that 1b is growing on me, if getters would just not be
excluded per default.
In contrast to Sebastian I actually think that if a user configures its
app to use method validation via some sort of interceptor or similar he
wants it to occur for all methods. If a getter is annotated with @NotNull
and I call this method I don't care whether
is is returning a state variable or whether this is a calculated value.
The returned value is supposed to be non
null.
Note, I am still against enabling method validation per default in a CDI
environment. I still think it should an active choice to enable the
appropriate technology. This also mitigates the problem of backwards
compatibility imo.
--Hardy
On 11 Jan 2012, at 7:32 PM, Gerhard Petracek <gerhard.petracek(a)gmail.com>
wrote:
> +1 for 2.b but -1 for a package annotation and/or config.
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
2:17 p.m.
Hi,
I'm +1 for option 1b.
A constraint annotation added to a regular non-getter method always
describes a return value contract whereas a constraint annotation added
to a getter method may be meant to be
a) a return value contract or
b) a property constraint, that only is supposed to be considered during
bean validation.
For getter method constraint annotation my gut feeling is, that you
usually want b) - a property constraint definition.
In OVal we have the annotation @IsInvariant to mark the constraints
defined on a getter for being return value contracts if not present the
constraints are not interpreted as return value contracts.
Regards,
Seb
On 11.12.2012 16:50, Emmanuel Bernard wrote:
That should hopefully be the last round. Here are the alternatives
that
I think are viable http://goo.gl/ubjn3
Please give your feedback.
Emmanuel
On Tue 2012-10-23 18:19, Emmanuel Bernard wrote:
> For method validation, we have so far managed to get away with
> requiring an annotation based metadata to direct how method validation
> behaves.
>
> One question that popped up during the recent write up is whether or not
> getters should be considered regular methods and thus be intercepted and
> validation by CDI or AspectJ interceptors.
>
> I have my own ideas, but I'd like to get your opinion on the subject.
>
> Emmanuel
> _______________________________________________
> 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
4:12 p.m.
hi sebastian,
i was going to +1 1.b as well, but i don't agree with point #1 (if it is
globally and/or users have to do it in any case) and #2.
(with @ValidateOnCall i'm ok with both default behaviours, if there is a
way to change it for a bv-archive.)
regards,
gerhard
2012/12/11 Sebastian Thomschke <sebastian.thomschke(a)web.de>
Hi,
I'm +1 for option 1b.
A constraint annotation added to a regular non-getter method always
describes a return value contract whereas a constraint annotation added
to a getter method may be meant to be
a) a return value contract or
b) a property constraint, that only is supposed to be considered during
bean validation.
For getter method constraint annotation my gut feeling is, that you
usually want b) - a property constraint definition.
In OVal we have the annotation @IsInvariant to mark the constraints
defined on a getter for being return value contracts if not present the
constraints are not interpreted as return value contracts.
Regards,
Seb
On 11.12.2012 16:50, Emmanuel Bernard wrote:
> That should hopefully be the last round. Here are the alternatives that
> I think are viable http://goo.gl/ubjn3
>
> Please give your feedback.
>
> Emmanuel
>
> On Tue 2012-10-23 18:19, Emmanuel Bernard wrote:
>> For method validation, we have so far managed to get away with
>> requiring an annotation based metadata to direct how method validation
>> behaves.
>>
>> One question that popped up during the recent write up is whether or not
>> getters should be considered regular methods and thus be intercepted and
>> validation by CDI or AspectJ interceptors.
>>
>> I have my own ideas, but I'd like to get your opinion on the subject.
>>
>> Emmanuel
>> _______________________________________________
>> 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
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
2:26 a.m.
A couple of remarks, I am not tied to @ValidateOnCall. We can find better names and/or a
different split. I like @IsInvariant described by Sebastian which means
@ValidateOnCall(INCLUDE_GETTERS) in my proposal. My concern is that it would not scale for
bean/package level settings nor allow to disable validation on a particular method.
My point being, if we finally agree on the proper default and overriding approach we can
refine names.
Gerhard, let me try and clarify your position. You like 1.b but you want to be able to
change the default global behavior per archive (with a validation.xml setting) if needed
and therefore that's why you voted for 2.b. I don't see a big problem with that.
My two concerns are:
- I am not sure that would be useful very often in practice but I imagine it could be
useful in a pure service archive
- to know the behavior, it forces people to look for a validation.xml to see what behavior
is set but as long as we have the default defined in 1, that's not a huge concern to
me.
Emmanuel
On 11 déc. 2012, at 23:12, Gerhard Petracek <gerhard.petracek(a)gmail.com> wrote:
hi sebastian,
i was going to +1 1.b as well, but i don't agree with point #1 (if it is globally
and/or users have to do it in any case) and #2.
(with @ValidateOnCall i'm ok with both default behaviours, if there is a way to
change it for a bv-archive.)
regards,
gerhard
2012/12/11 Sebastian Thomschke <sebastian.thomschke(a)web.de>
> Hi,
>
> I'm +1 for option 1b.
>
> A constraint annotation added to a regular non-getter method always
> describes a return value contract whereas a constraint annotation added
> to a getter method may be meant to be
> a) a return value contract or
> b) a property constraint, that only is supposed to be considered during
> bean validation.
>
> For getter method constraint annotation my gut feeling is, that you
> usually want b) - a property constraint definition.
>
> In OVal we have the annotation @IsInvariant to mark the constraints
> defined on a getter for being return value contracts if not present the
> constraints are not interpreted as return value contracts.
>
> Regards,
>
> Seb
>
> On 11.12.2012 16:50, Emmanuel Bernard wrote:
> > That should hopefully be the last round. Here are the alternatives that
> > I think are viable http://goo.gl/ubjn3
> >
> > Please give your feedback.
> >
> > Emmanuel
> >
> > On Tue 2012-10-23 18:19, Emmanuel Bernard wrote:
> >> For method validation, we have so far managed to get away with
> >> requiring an annotation based metadata to direct how method validation
> >> behaves.
> >>
> >> One question that popped up during the recent write up is whether or not
> >> getters should be considered regular methods and thus be intercepted and
> >> validation by CDI or AspectJ interceptors.
> >>
> >> I have my own ideas, but I'd like to get your opinion on the subject.
> >>
> >> Emmanuel
> >> _______________________________________________
> >> 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
>
> _______________________________________________
> 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
4340
days inactive
4395
days old
beanvalidation-dev@lists.jboss.org
32 comments
7 participants
participants (7)
-
Emmanuel Bernard -
Gerhard Petracek -
Gunnar Morling -
Hardy Ferentschik -
Matt Benson -
Michael Nascimento -
Sebastian Thomschke