Hi experts, After reading your comments and mail list I realized that it will be better share our opinions here about our problems. First, I would like to thanks all of you to provide such an elegant library and spec. After latest improvements at spring side, I am sure that bean validation will be defacto validation framework among java community. The only problem We are facing is that ordered validations. In a common sense validation such this can be feasible: public class AccountBean { > > @CheapValidation(groups=Name1.class) > @ExpensiveValidation(groups=Name2.class) > @VeryExpensiveValidation(groups=Name3.class) > String name; > > @CheapValidation(groups=Surname1.class) > @ExpensiveValidation(groups=Surname2.class) > @VeryExpensiveValidation(groups=Surname3.class) > String surname; > > public interface Name1 {} > public interface Name2 {} > public interface Name3 {} > @GroupSequence({Name1.class, Name2.class, Name3.class}) > public interface Name {} > > public interface Surname1 {} > public interface Surname2 {} > public interface Surname3 {} > @GroupSequence({Surname1.class, Surname2.class, Surname3.class}) > public interface Surname {} > } > > There is two common usage for this. The first usage: some validations are expensive that should be runned if all validations pass. Another usage is for each field there should be one violation. For email, if it is empty, uniqueEmail constraint must not be checked. I hope that how much necessary it is for us you can imagine. Almost all fields has such restrictions. Ordering and shortcutting are crucial for us. But just to provide validation order and shortcut GroupSequence is practically impossible to use at enterprice level. For each field again and again we are declaring interfaces. It is not only intuitive but also seems ugly. By the way what is came to my mind is for each constraint, declaring a order like this: public class AccountBean { > > @CheapValidation(order=0,groups=Name1.class) > @ExpensiveValidation(order=1,groups=Name2.class) > @VeryExpensiveValidation(order=2,groups=Name3.class) > String name; > > @CheapValidation(order=0,groups=Surname1.class) > @ExpensiveValidation(order=1,groups=Surname2.class) > @VeryExpensiveValidation(order=2,groups=Surname3.class) > String surname; > } > > Default value for ordering might be same for all constraints. Please help community. :) Thanks & happy new year _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

Also, IMHO it is overdue: not short circuiting (as today) is totally redundant. Is there a reason this wasn't specified for BV 1.0? "When @ReportAsSingleViolation is present, short circuit."

so @Size(5) @Pattern("[0-9]{5}") @Constraint(validatedBy=BusinessPostCodeValidator.class) // expensive; query explodes if size > DB column length @ReportAsSingleViolation // only query DB if @Size and @Pattern pass public @interface PostCode { ... String message() default "not a valid postal code"; }

If different messages are needed, then @GroupSequence works but as Cemo says is unwieldy, and furthermore in practice breaks when combined with group inheritance (which is very natural and useful). So...2nd suggestion: "Allow @GroupSequence to be combined with interface inheritance in the obvious way." (OK, "obvious" has a lot of nasty edge cases, but let me demonstrate why this would be a good change:) Currently the following gives wacky and IMHO wrong results (test case available on request). A close reading of BV 1.0 spec shows @GroupSequence and inheritance are incompatible...but the interactions are not intuitive: @GroupSequence({Name1.class, Name2.class, Name3.class}) interface Names { interface Name1 {} interface Name2 {} interface Name3 {} } @GroupSequence({Surname1.class, Surname2.class, Surname3.class}) interface Surnames { interface Surname1 {} interface Surname2 {} interface Surname3 {} } interface BusinessValidations extends Names, Surnames {} // At least the client wouldn't have to see all the ugliness. // Maintenance, extensibility improved...but the following doesn't work! // Currently no warning/error; only discover failure by test cases. validator.validate(account, BusinessValidations.class);

From my perspective proposal #1 would get 80% of the way, and #2 would get the rest as well as solve some very wacky (buggy?) interactions I've observed in my year+ of using BV 1.0. [There are other, more subtle ways that @GroupSequence messes with inheritance -- even when used in unrelated groups passed to #validate(...) -- that I'd be happy to move to a different topic.]

Hi experts, After reading your comments and mail list I realized that it will be better share our opinions here about our problems. First, I would like to thanks all of you to provide such an elegant library and spec. After latest improvements at spring side, I am sure that bean validation will be defacto validation framework among java community. The only problem We are facing is that ordered validations. In a common sense validation such this can be feasible: public class AccountBean { @CheapValidation(groups=Name1.class) @ExpensiveValidation(groups=Name2.class) @VeryExpensiveValidation(groups=Name3.class) String name; @CheapValidation(groups=Surname1.class) @ExpensiveValidation(groups=Surname2.class) @VeryExpensiveValidation(groups=Surname3.class) String surname; public interface Name1 {} public interface Name2 {} public interface Name3 {} @GroupSequence({Name1.class, Name2.class, Name3.class}) public interface Name {} public interface Surname1 {} public interface Surname2 {} public interface Surname3 {} @GroupSequence({Surname1.class, Surname2.class, Surname3.class}) public interface Surname {} } There is two common usage for this. The first usage: some validations are expensive that should be runned if all validations pass. Another usage is for each field there should be one violation. For email, if it is empty, uniqueEmail constraint must not be checked. I hope that how much necessary it is for us you can imagine. Almost all fields has such restrictions. Ordering and shortcutting are crucial for us. But just to provide validation order and shortcut GroupSequence is practically impossible to use at enterprice level. For each field again and again we are declaring interfaces. It is not only intuitive but also seems ugly. By the way what is came to my mind is for each constraint, declaring a order like this: public class AccountBean { @CheapValidation(order=0,groups=Name1.class) @ExpensiveValidation(order=1,groups=Name2.class) @VeryExpensiveValidation(order=2,groups=Name3.class) String name; @CheapValidation(order=0,groups=Surname1.class) @ExpensiveValidation(order=1,groups=Surname2.class) @VeryExpensiveValidation(order=2,groups=Surname3.class) String surname; } Default value for ordering might be same for all constraints. Please help community. :) Thanks & happy new year _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

Ordered constraints came up several times on the Hibernate Validator mailing list as well. There is a Hibernate Validator specific issue [1] as well as a BVAL one [2] [1] https://hibernate.onjira.com/browse/HV-462 [2] https://hibernate.onjira.com/browse/BVAL-248 On Jan 4, 2012, at 2:29 PM, Emmanuel Bernard wrote: > Hi, > Let me try and summarize what you want to be sure we are on the same page: > > - you want sometimes to return one and only one failure per property > - you want some constraints to be validated before others (to be the one displayed) > > Besides not empty which should be simply ignored by your unique email constraint, do you have other use cases? I would rather exclude null / empty from the list of use cases because it's a fairly pathological case and we plan on addressing that via a different mechanism (namely a way to mark a constraint validator as being called only on non null / non empty values). > > I've been trying to avoid numerical ordering (the fancy name is salience I believe) so far so I'd like to see concrete use cases that cannot be solved otherwise. > > Having a per property shortcut and a global shortcut would be a nice a easy feature to add. We left it out of 1.0 but it almost made it through. > > Likewise, we could fake salience by providing a special group > > ``` > package javax.validation.groups; > > @GroupSequence({Level1.class, Level2.class, Level3.class, Level4.class, Level5.class, Level6.class, Level7.class, Level8.class, Level9.class, Level10.class}) > interface Order { > interface Level1 {} > interface Level2 {} > interface Level3 {} > ... > interface Level10 {} > } > ``` > > Frankly I'd rather avoid it but that would work. > > On 3 janv. 2012, at 21:33, Cemo wrote: > >> Hi experts, >> >> After reading your comments and mail list I realized that it will be better share our opinions here about our problems. >> >> First, I would like to thanks all of you to provide such an elegant library and spec. After latest improvements at spring side, I am sure that bean validation will be defacto validation framework among java community. >> >> The only problem We are facing is that ordered validations. >> >> In a common sense validation such this can be feasible: >> >> public >> class AccountBean { >> >> @CheapValidation(groups=Name1.class) >> @ExpensiveValidation(groups=Name2.class) >> @VeryExpensiveValidation(groups=Name3.class) >> >> String >> name; >> >> @CheapValidation(groups=Surname1.class) >> @ExpensiveValidation(groups=Surname2.class) >> @VeryExpensiveValidation(groups=Surname3.class) >> >> String >> surname; >> >> >> public interface >> Name1 {} >> >> public interface >> Name2 {} >> >> public interface >> Name3 {} >> @GroupSequence({Name1.class, Name2.class, Name3.class}) >> >> public interface >> Name {} >> >> >> public interface >> Surname1 {} >> >> public interface >> Surname2 {} >> >> public interface >> Surname3 {} >> @GroupSequence({Surname1.class, Surname2.class, Surname3.class}) >> >> public interface >> Surname {} >> } >> >> >> >> There is two common usage for this. The first usage: some validations are expensive that should be runned if all validations pass. Another usage is for each field there should be one violation. For email, if it is empty, uniqueEmail constraint must not be checked. I hope that how much necessary it is for us you can imagine. Almost all fields has such restrictions. Ordering and shortcutting are crucial for us. >> >> But just to provide validation order and shortcut GroupSequence is practically impossible to use at enterprice level. For each field again and again we are declaring interfaces. It is not only intuitive but also seems ugly. By the way what is came to my mind is for each constraint, declaring a order like this: >> >> public >> class AccountBean { >> >> @CheapValidation(order=0,groups=Name1.class) >> @ExpensiveValidation(order=1,groups=Name2.class) >> @VeryExpensiveValidation(order=2,groups=Name3.class) >> >> String >> name; >> >> @CheapValidation(order=0,groups=Surname1.class) >> @ExpensiveValidation(order=1,groups=Surname2.class) >> @VeryExpensiveValidation(order=2,groups=Surname3.class) >> >> String >> surname; >> } >> >> >> Default value for ordering might be same for all constraints. >> >> Please help community. :) >> >> Thanks & happy new year >> _______________________________________________ >> 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

Can the proposal for special null/empty handling be generalized? I have two extra use cases, - Concept of "empty" for objects, for example my enterprise often uses a "money" object (value+currency) - Need to define "prerequisite" validations in general, for example check @NotNull+@Size before a DB query to avoid a query exception Regards, Peter Davis On Jan 4, 2012, at 5:29, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: > Hi, > Let me try and summarize what you want to be sure we are on the same page: > > - you want sometimes to return one and only one failure per property > - you want some constraints to be validated before others (to be the one displayed) > > Besides not empty which should be simply ignored by your unique email constraint, do you have other use cases? I would rather exclude null / empty from the list of use cases because it's a fairly pathological case and we plan on addressing that via a different mechanism (namely a way to mark a constraint validator as being called only on non null / non empty values). > > I've been trying to avoid numerical ordering (the fancy name is salience I believe) so far so I'd like to see concrete use cases that cannot be solved otherwise. > > Having a per property shortcut and a global shortcut would be a nice a easy feature to add. We left it out of 1.0 but it almost made it through. > > Likewise, we could fake salience by providing a special group > > ``` > package javax.validation.groups; > > @GroupSequence({Level1.class, Level2.class, Level3.class, Level4.class, Level5.class, Level6.class, Level7.class, Level8.class, Level9.class, Level10.class}) > interface Order { > interface Level1 {} > interface Level2 {} > interface Level3 {} > ... > interface Level10 {} > } > ``` > > Frankly I'd rather avoid it but that would work. > > On 3 janv. 2012, at 21:33, Cemo wrote: > >> Hi experts, >> >> After reading your comments and mail list I realized that it will be better share our opinions here about our problems. >> >> First, I would like to thanks all of you to provide such an elegant library and spec. After latest improvements at spring side, I am sure that bean validation will be defacto validation framework among java community. >> >> The only problem We are facing is that ordered validations. >> >> In a common sense validation such this can be feasible: >> >> public class AccountBean { >> >> @CheapValidation(groups=Name1.class) >> @ExpensiveValidation(groups=Name2.class) >> @VeryExpensiveValidation(groups=Name3.class) >> String name; >> >> @CheapValidation(groups=Surname1.class) >> @ExpensiveValidation(groups=Surname2.class) >> @VeryExpensiveValidation(groups=Surname3.class) >> String surname; >> >> public interface Name1 {} >> public interface Name2 {} >> public interface Name3 {} >> @GroupSequence({Name1.class, Name2.class, Name3.class}) >> public interface Name {} >> >> public interface Surname1 {} >> public interface Surname2 {} >> public interface Surname3 {} >> @GroupSequence({Surname1.class, Surname2.class, Surname3.class}) >> public interface Surname {} >> } >> >> >> There is two common usage for this. The first usage: some validations are expensive that should be runned if all validations pass. Another usage is for each field there should be one violation. For email, if it is empty, uniqueEmail constraint must not be checked. I hope that how much necessary it is for us you can imagine. Almost all fields has such restrictions. Ordering and shortcutting are crucial for us. >> >> But just to provide validation order and shortcut GroupSequence is practically impossible to use at enterprice level. For each field again and again we are declaring interfaces. It is not only intuitive but also seems ugly. By the way what is came to my mind is for each constraint, declaring a order like this: >> >> public class AccountBean { >> >> @CheapValidation(order=0,groups=Name1.class) >> @ExpensiveValidation(order=1,groups=Name2.class) >> @VeryExpensiveValidation(order=2,groups=Name3.class) >> String name; >> >> @CheapValidation(order=0,groups=Surname1.class) >> @ExpensiveValidation(order=1,groups=Surname2.class) >> @VeryExpensiveValidation(order=2,groups=Surname3.class) >> String surname; >> } >> >> Default value for ordering might be same for all constraints. >> >> Please help community. :) >> >> Thanks & happy new year >> _______________________________________________ >> 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

We are talking about two things here, right? 1. That the validation of composed constraints should stop immediately if @ReportAsSingleViolation is specified and the first failing constraints has occurred. That's BVAL-259 BVAL-220 is an extension of BVAL-259 which makes the behavior configurable via something like this @ReportAsSingleViolation(shortCircuit=true) The spec currently keeps the behavior open by saying (page 11, 2.3 Constraint composition): "If a composing constraint fails and if the composed constraint is marked as @ReportAsSingleViolation, the Bean Validation provider is free to not process the other composing constraints for this composed constraint." 2. The ability to define an order in which constraints are getting applied (either on a single property or also in connection of a composed constraint). That's BVAL-248 (and HV-462). Here we have so far the idea of an additional order parameter added to constraints, e.g. @Size(max=100, validationOrder="1") and Emmanuel's @GroupSequence(value={Cheap.class,Expensive.class}, ordering=PER_TARGET) Regarding 1, I think implementing BVAL-259 and BVAL-220 makes sense. In this context we should, however, also discuss boolean composition (BVAL-260) of constraints. Regarding 2, Emmanuel's idea seems more in the spirit of the current spec design, but I disagree that the interface approach is easier to manage the order property. I think that Cemo has a point that juggling all these interfaces around is at no means easier. Given that we talk about a order specific for a property I think it is easiest to understand if you you can specify and see it right there on the constraint specified at the property. --Hardy On Jan 5, 2012, at 11:28 AM, Emmanuel Bernard wrote: > I have not seen your proposal till now. > > https://hibernate.onjira.com/browse/BVAL-220?focusedCommentId=42681&p... > > This looks quite elegant and only require BVAL-259 to be solved. Peter's proposal makes it work for any type and any definition of "null". The only drawback is that's it's more subtle / cryptic than an explicit param or annotation. > > On 4 janv. 2012, at 16:46, Peter Davis wrote: > >> Can the proposal for special null/empty handling be generalized? I have two extra use cases, >> >> - Concept of "empty" for objects, for example my enterprise often uses a "money" object (value+currency) >> - Need to define "prerequisite" validations in general, for example check @NotNull+@Size before a DB query to avoid a query exception >> >> Regards, >> Peter Davis >> >> On Jan 4, 2012, at 5:29, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: >> >>> Hi, >>> Let me try and summarize what you want to be sure we are on the same page: >>> >>> - you want sometimes to return one and only one failure per property >>> - you want some constraints to be validated before others (to be the one displayed) >>> >>> Besides not empty which should be simply ignored by your unique email constraint, do you have other use cases? I would rather exclude null / empty from the list of use cases because it's a fairly pathological case and we plan on addressing that via a different mechanism (namely a way to mark a constraint validator as being called only on non null / non empty values). >>> >>> I've been trying to avoid numerical ordering (the fancy name is salience I believe) so far so I'd like to see concrete use cases that cannot be solved otherwise. >>> >>> Having a per property shortcut and a global shortcut would be a nice a easy feature to add. We left it out of 1.0 but it almost made it through. >>> >>> Likewise, we could fake salience by providing a special group >>> >>> ``` >>> package javax.validation.groups; >>> >>> @GroupSequence({Level1.class, Level2.class, Level3.class, Level4.class, Level5.class, Level6.class, Level7.class, Level8.class, Level9.class, Level10.class}) >>> interface Order { >>> interface Level1 {} >>> interface Level2 {} >>> interface Level3 {} >>> ... >>> interface Level10 {} >>> } >>> ``` >>> >>> Frankly I'd rather avoid it but that would work. >>> >>> On 3 janv. 2012, at 21:33, Cemo wrote: >>> >>>> Hi experts, >>>> >>>> After reading your comments and mail list I realized that it will be better share our opinions here about our problems. >>>> >>>> First, I would like to thanks all of you to provide such an elegant library and spec. After latest improvements at spring side, I am sure that bean validation will be defacto validation framework among java community. >>>> >>>> The only problem We are facing is that ordered validations. >>>> >>>> In a common sense validation such this can be feasible: >>>> >>>> public >>>> class AccountBean { >>>> >>>> @CheapValidation(groups=Name1.class) >>>> @ExpensiveValidation(groups=Name2.class) >>>> @VeryExpensiveValidation(groups=Name3.class) >>>> >>>> String >>>> name; >>>> >>>> @CheapValidation(groups=Surname1.class) >>>> @ExpensiveValidation(groups=Surname2.class) >>>> @VeryExpensiveValidation(groups=Surname3.class) >>>> >>>> String >>>> surname; >>>> >>>> >>>> public interface >>>> Name1 {} >>>> >>>> public interface >>>> Name2 {} >>>> >>>> public interface >>>> Name3 {} >>>> @GroupSequence({Name1.class, Name2.class, Name3.class}) >>>> >>>> public interface >>>> Name {} >>>> >>>> >>>> public interface >>>> Surname1 {} >>>> >>>> public interface >>>> Surname2 {} >>>> >>>> public interface >>>> Surname3 {} >>>> @GroupSequence({Surname1.class, Surname2.class, Surname3.class}) >>>> >>>> public interface >>>> Surname {} >>>> } >>>> >>>> >>>> >>>> There is two common usage for this. The first usage: some validations are expensive that should be runned if all validations pass. Another usage is for each field there should be one violation. For email, if it is empty, uniqueEmail constraint must not be checked. I hope that how much necessary it is for us you can imagine. Almost all fields has such restrictions. Ordering and shortcutting are crucial for us. >>>> >>>> But just to provide validation order and shortcut GroupSequence is practically impossible to use at enterprice level. For each field again and again we are declaring interfaces. It is not only intuitive but also seems ugly. By the way what is came to my mind is for each constraint, declaring a order like this: >>>> >>>> public >>>> class AccountBean { >>>> >>>> @CheapValidation(order=0,groups=Name1.class) >>>> @ExpensiveValidation(order=1,groups=Name2.class) >>>> @VeryExpensiveValidation(order=2,groups=Name3.class) >>>> >>>> String >>>> name; >>>> >>>> @CheapValidation(order=0,groups=Surname1.class) >>>> @ExpensiveValidation(order=1,groups=Surname2.class) >>>> @VeryExpensiveValidation(order=2,groups=Surname3.class) >>>> >>>> String >>>> surname; >>>> } >>>> >>>> >>>> Default value for ordering might be same for all constraints. >>>> >>>> Please help community. :) >>>> >>>> Thanks & happy new year >>>> _______________________________________________ >>>> 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 _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

What about this? @ConstraintSequence({ @NotEmpty(), @IsValidBinCodeNumber(), @IsCardBannedNumber(), @IsValidCardNumber() }) private String creditCard; Thanks On 5 January 2012 13:56, Cemo <cemalettin.koc(a)gmail.com&gt; wrote: @NotEmpty() @IsValidBinCodeNumber() @IsCardBannedNumber() @IsValidCardNumber() @ConstraintSequence(value={NotEmpty.class, IsValidBinCodeNumber .class,IsCardBannedNumber.class, IsValidCardNumber.class}, shortCirtcuit=true) _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

> > Thanks for summing up. No problem. I will try to sum this up on beanvalidation.org asap as well.

On Thu, Jan 5, 2012 at 6:53 AM, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: > > On 5 janv. 2012, at 13:44, Hardy Ferentschik wrote: > >>> >>> Thanks for summing up. >> >> No problem. I will try to sum this up on beanvalidation.org asap as well. > > Thanks, say you sum up BV-220 and BV-259 and I will sum up the other subjects disccussed in the last few days. Lots of good content :) Guys, Just to inject a little insanity into the debate... we've touched on the idea of obtaining information in unorthodox ways before (parameter names come to mind). Now, this proceeds from the assumption that a given Java compiler would assemble bytecode such that visible annotations would stay in the order in which they were defined, but given that that is true for one or more available compilers, what is the feeling of the community toward specifying that order be derived from bytecode inspection? I realize this is quite specific, but in the end nothing is more intuitive than just using the annotations in the order in which they are actually specified.

On Fri, Jan 6, 2012 at 11:11 AM, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: > > On 5 janv. 2012, at 16:58, Matt Benson wrote: > >> On Thu, Jan 5, 2012 at 6:53 AM, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: >>> >>> On 5 janv. 2012, at 13:44, Hardy Ferentschik wrote: >>> >>>>> >>>>> Thanks for summing up. >>>> >>>> No problem. I will try to sum this up on beanvalidation.org asap as well. >>> >>> Thanks, say you sum up BV-220 and BV-259 and I will sum up the other subjects disccussed in the last few days. Lots of good content :) >> >> Guys, >>  Just to inject a little insanity into the debate... we've touched on >> the idea of obtaining information in unorthodox ways before (parameter >> names come to mind).  Now, this proceeds from the assumption that a >> given Java compiler would assemble bytecode such that visible >> annotations would stay in the order in which they were defined, but >> given that that is true for one or more available compilers, what is >> the feeling of the community toward specifying that order be derived >> from bytecode inspection?  I realize this is quite specific, but in >> the end nothing is more intuitive than just using the annotations in >> the order in which they are actually specified. > > An alternative is to use annotation processors to capture source time information via some kind of annotations but > both approaches sound very scary. > Matt do you think it's really worth exploring? A little scary, yes.  I think the annotation processing route is a little *more* scary than the bytecode avenue... the least palatable thing about it to me is that it places a heavy burden at the spec level, constraining the implementations to do very specific things. But I do find the bytecode examination idea interesting. Matt > _______________________________________________ > 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

On Sat, Jan 7, 2012 at 6:27 AM, Gunnar Morling <gunnar.morling(a)googlemail.com&gt; wrote: > One idea might be to introduce some kind of "validation order > provider" contract (similar to the parameter name provider we > discussed recently) with a reasonable default implementation. > > BV providers could then come up with custom implementations based on > byte code order, meta data pre-generated by an annotation processor > etc. as they like which we still might spec later on if they proved > useful. This sounds like a good compromise to transfer the responsibility from the spec to the implementations for doing crazy things like reading bytecode... so this would be a new collaborator managed for/by the ValidatorFactory?

I am not so sure whether such a contract would be such a good idea. If we want to hold on to the byte code or annotation processor idea (if the latter is even possible), such a contract would make sense. However, that excludes imo the explicit configuration of order, either via Emmanuel's @GroupSequence.ordering=PER_TARGET or via a simple order property in the constraint itself. As a user of BV I think I would rather prefer to directly see and hence be able to infer the order. And just imagine different compilers actually do have different orders. That would be a total mess. --Hardy On Jan 7, 2012, at 9:40 PM, Matt Benson wrote: > On Sat, Jan 7, 2012 at 6:27 AM, Gunnar Morling > <gunnar.morling(a)googlemail.com&gt; wrote: >> One idea might be to introduce some kind of "validation order >> provider" contract (similar to the parameter name provider we >> discussed recently) with a reasonable default implementation. >> >> BV providers could then come up with custom implementations based on >> byte code order, meta data pre-generated by an annotation processor >> etc. as they like which we still might spec later on if they proved >> useful. > > This sounds like a good compromise to transfer the responsibility from > the spec to the implementations for doing crazy things like reading > bytecode... so this would be a new collaborator managed for/by the > ValidatorFactory? _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

1. I am not sure whether I file another issue or not but if there is an opportunity I would like set error message via violating constraint. :) @ReportAsSingleViolation(shortCircuit=true, messageSource=ByOriginatingConstraint)

We are talking about two things here, right? 1. That the validation of composed constraints should stop immediately if @ReportAsSingleViolation is specified and the first failing constraints has occurred. That's BVAL-259 BVAL-220 is an extension of BVAL-259 which makes the behavior configurable via something like this @ReportAsSingleViolation(shortCircuit=true) The spec currently keeps the behavior open by saying (page 11, 2.3 Constraint composition): "If a composing constraint fails and if the composed constraint is marked as @ReportAsSingleViolation, the Bean Validation provider is free to not process the other composing constraints for this composed constraint."