Emmanuel Bernard edited a comment on Improvement BVAL-344

Discussion between Pete and me:

Pete Muir
22:32
what does "By default, getters (as defined in http://beanvalidation.org/latest-draft/spec/#constraintdeclarationvalidationprocess-requirements) are not considered constrained methods." mean?
Emmanuel
22:33
@NotNull String getName() { … } is not validated
Pete Muir
22:33
ok, and you guys handle that in BV code?
22:33
BV impl code?
Emmanuel
22:33
@NotNull String getBestTeam(SportType type); is validated
22:33
No this filtering is part of the code that will bind interceptors
22:34
it won't intercept getters (unless @validateExecutable overrides it somehow)
Pete Muir
22:34
got it
22:34
btw
22:34
@ValidateExecutable(type=GETTER_METHODS)
   @Min(0)
   Integer getBacklog() { ... }
Emmanuel
22:34
I was for having BV doing a noop ie handling @ValidateExecutable etc but Hardy and Gunnar were against
Pete Muir
22:34
this is very odd to look at
Emmanuel
22:35
So I al considering making ALL the default value for @ValidateExecutable.type
22:35
so your example would become 

   @ValidateExecutable
   @Min(0)
   Integer getBacklog() { ... }
22:36
Still to disable it, you need to use it

@ValidateExecutable(type=NONE)
 @Min(0)
 Integer getBacklog(int level) { ... }
Pete Muir
22:36
yeah
Emmanuel
22:36
But then I am thinking of renaming NONE to OFF to make that case easier
22:36
Thoughts?
Pete Muir
22:37
makes more sense to me
22:37
what about renaming type -> value
22:37
as well
Emmanuel
22:37
evolution mostly
Pete Muir
22:37
@ValidateExecutable(OFF) and @ValidateExecutable({CONSTRUCTOR, GETTER_METHODS})
Emmanuel
22:38
yes I get that it reads better
22:38
but if we add new stuffs, type will make more sense
22:38
but I'll ponder it
Pete Muir
22:38
true
22:39
I would rewrite Every Bean Validation provider should provide a CDI Extension (or alternative solution provided it fulfills the requirements) -> Every Bean Validation provider should must fulfill the requirements if CDI is present. For example, this could be done using a CDI portable extension.
22:39
And, I would change it so that you have:
22:40
(pseudo text) A CDI container integrates with Bean Validation like this. In a Java EE container, this integration must be present.
22:40
so you specify how it integrates
22:40
and when it must integrate
22:41
in other situations, whether it must integrate is optional, but if it does integrate, it must meet your requirements
22:41
does that make sense?
Emmanuel
22:41
yes I get that if it intergrates -> these are the rules and in EE you must
Pete Muir
22:41
well today you have something different IMO
Emmanuel
22:42
possibly
22:42
Still it's the responsibility of the BV impl to provide this integration in your rewording
22:42
instead of being the CDI's
Pete Muir
22:42
hmm, no
22:42
it's not defined who must provide
22:42
only that it must be provided
22:42
(and in Java EE that it must be provided)
22:43
So yeah. I would rephrase 10.3 as
Emmanuel
22:43
I see, I read "must fulfill" as "must provide"
Pete Muir
22:43
oh, well you wrote fulfill
22:43
i wouldn't use that word 
22:44
10.3 There are several integrations points between Bean Validation and CDI. If a Bean Validation provider wishes to integrate with CDI, it must follow the rules laid out in this section. In a Java EE container, a Bean Validation provider must integrate with CDI.
22:44
Then in 10.3.1
22:45
start with
22:45
The container must support injection of built-in default ValidatorFactory and Validator beans via @Inject:
22:45
I would remove the stuff about "has to be via a CDI extension"
22:45
and focus on the actual rules
22:46
I would maybe add a note (non-normative) that you can do it via an extension
22:46
the actual rules look fine to me
Emmanuel
22:46
good
Pete Muir
22:46
10.3.2 looks good
22:46
10.3.3 "Ordinarily CDI requires that intercepted methods are annotated with a so called interceptor binding annotation. To make method validation implicit by just adding the Bean Validation constraints to a constructor or method, the interceptor biding annotation needs to be added programmatically to any method requiring validation." this is a mess
22:47
it's specifying implementation
22:49
Bean Validation requires that adding only a constraint to a constructor or method will cause validation to occur. The CDI interceptor binding facility does not directly support this, but the effect may be achieved using the CDI portable extension SPI, or vendor specific SPIs.
Emmanuel
22:50
Thanks. Indeed the implementation details were the reason for the overall rewriting
22:51
You mentioned "and when it must integrate". It's at application startup? Is it when the CDI container starts?
Pete Muir
22:53
i can't find that
22:53
what is the full sentence
Emmanuel
22:54

22:54
ah that's when as in EE vs SE
22:54
I was thinking when in th lifecycle
22:54
Sorry
Pete Muir
22:55
oh i see
22:55
yes right
22:55
when == what environment
Emmanuel
22:56
I have what I need, thanks man
Pete Muir
22:58
np
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira