[ http://opensource.atlassian.com/projects/hibernate/browse/BVAL-208?page=c... ] Emmanuel Bernard commented on BVAL-208: --------------------------------------- There are valid reasons to get groups on @Valid but I did not get yours. Can you explain that a bit further? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/BVAL-208?page=c... ] Emmanuel Bernard commented on BVAL-208: --------------------------------------- OK I see. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/BVAL-208?page=c... ] Arthur Ronald F D Garcia commented on BVAL-208: ----------------------------------------------- Here goes some examples Spring MVC 3.0, for instance, supports JSR-303 by using @Valid as ElementType.PARAMETER public void doSomething(@Valid Command command, BindingResult result) throws Exception {} But if JSR-303 supports the concept of groups, how can i supply which group i want to test. Because of that, i need to implement a Spring Validator interface instead public class CommandValidator implements Validator { public bollean supports(Class clazz) {} public void validate(Object command, Errors errors) { Set<ConstraintViolation<Command>> constraintViolationSet = ValidatorUtil.getValidator().validate((Command) command, SomeUseCase.class); // post-proccessing validation } } So instead of (Not supported) public void doSomething((a)Valid(groups=SomeUseCase.class) Command command, BindingResult result) throws Exception {} I need to use (old-style) private CommandValidator validator = new CommandValidator(); public void doSomething(Command command, BindingResult result) throws Exception { validator.validate(command, result); } There is more As @Valid annotation fullfil nested properties, how can i supply which group of the nested property i want to test ??? As @Valid does not support groups attribute, i just can use @Valid when using default group. Otherwise, i need to remove it public class Command { @Valid public Children getChildren() { return this.children; } } best regards Arthur Ronald F D Garcia -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/BVAL-208?page=c... ] Arthur Ronald F D Garcia commented on BVAL-208: ----------------------------------------------- If @Valid annotation supports groups attribute, javax.validation API may have INCONSISTENT behavior because the validated group MUST BE PROPAGATED to its referenced objects annotated with @Valid annotation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/BVAL-208?page=c... ] Emmanuel Bernard commented on BVAL-208: --------------------------------------- I had two use cases in mind: * define the group to validate in a method level annotation (parameter etc) * let a user redefine the group to validate when cascaded (useful when aggregating object graphs) Both use cases are well described by Arthur in #comment-38181 Note that @Valid left alone would still fulfill the default specification interpretation. But one could envision a "NAT" style transformation from one group to another when a @Valid barrier is crossed. {code}(a)Valid(before={Simple.class, Heavy.class}, after={Easy.class, Default.class}){code} When Simple.class is validated in the mail object, Easy.class is validated on the cascaded object. When Heavy.class is validated in the mail object, Default.class is validated on the cascaded object. A couple of problems to resolve: * what about circular dependencies involving different groups "for a while" (ie Default on the nested object validates back the root object). * what about group sequences. Should direct groups be translated, or should inner groups be too? What about inconsistencies in this case (ie the translated group sequence violating group sequence rules). Note that I had in mind to reuse @Valid but it might be better to have one (or even two) additional annotations for these notions (ie the cascading, the group translation, the method-levle group definition. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/BVAL-208?page=c... ] Emmanuel Bernard updated BVAL-208: ---------------------------------- Summary: support groups translation when cascading operations (hosted on @Valid or not) (was: @Valid should support groups attribute) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/BVAL-208?page=com.atlassian.jira.plug... ] Hardy Ferentschik edited comment on BVAL-208 at 4/3/12 8:09 AM: ---------------------------------------------------------------- I had two use cases in mind: * define the group to validate in a method level annotation (parameter etc) * let a user redefine the group to validate when cascaded (useful when aggregating object graphs) Both use cases are well described by Arthur in [#comment-38181] Note that @Valid left alone would still fulfill the default specification interpretation. But one could envision a "NAT" style transformation from one group to another when a @Valid barrier is crossed. {code}(a)Valid(before={Simple.class, Heavy.class}, after={Easy.class, Default.class}){code} When Simple.class is validated in the mail object, Easy.class is validated on the cascaded object. When Heavy.class is validated in the mail object, Default.class is validated on the cascaded object. A couple of problems to resolve: * what about circular dependencies involving different groups "for a while" (ie Default on the nested object validates back the root object). * what about group sequences. Should direct groups be translated, or should inner groups be too? What about inconsistencies in this case (ie the translated group sequence violating group sequence rules). Note that I had in mind to reuse @Valid but it might be better to have one (or even two) additional annotations for these notions (ie the cascading, the group translation, the method-levle group definition. was (Author: emmanuel): I had two use cases in mind: * define the group to validate in a method level annotation (parameter etc) * let a user redefine the group to validate when cascaded (useful when aggregating object graphs) Both use cases are well described by Arthur in #comment-38181 Note that @Valid left alone would still fulfill the default specification interpretation. But one could envision a "NAT" style transformation from one group to another when a @Valid barrier is crossed. {code}(a)Valid(before={Simple.class, Heavy.class}, after={Easy.class, Default.class}){code} When Simple.class is validated in the mail object, Easy.class is validated on the cascaded object. When Heavy.class is validated in the mail object, Default.class is validated on the cascaded object. A couple of problems to resolve: * what about circular dependencies involving different groups "for a while" (ie Default on the nested object validates back the root object). * what about group sequences. Should direct groups be translated, or should inner groups be too? What about inconsistencies in this case (ie the translated group sequence violating group sequence rules). Note that I had in mind to reuse @Valid but it might be better to have one (or even two) additional annotations for these notions (ie the cascading, the group translation, the method-levle group definition. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/BVAL-208?page=com.atlassian.jira.plug... ] Hardy Ferentschik edited comment on BVAL-208 at 4/3/12 8:11 AM: ---------------------------------------------------------------- Here goes some examples Spring MVC 3.0, for instance, supports JSR-303 by using @Valid as ElementType.PARAMETER {code} public void doSomething(@Valid Command command, BindingResult result) throws Exception {} {code} But if JSR-303 supports the concept of groups, how can i supply which group i want to test. Because of that, i need to implement a Spring Validator interface instead {code} public class CommandValidator implements Validator { public bollean supports(Class clazz) {} public void validate(Object command, Errors errors) { Set<ConstraintViolation<Command>> constraintViolationSet = ValidatorUtil.getValidator().validate((Command) command, SomeUseCase.class); // post-proccessing validation } } {code} So instead of (Not supported) {code} public void doSomething((a)Valid(groups=SomeUseCase.class) Command command, BindingResult result) throws Exception {} {code} I need to use (old-style) {code} private CommandValidator validator = new CommandValidator(); public void doSomething(Command command, BindingResult result) throws Exception { validator.validate(command, result); } {code} There is more As @Valid annotation fullfil nested properties, how can i supply which group of the nested property i want to test ??? As @Valid does not support groups attribute, i just can use @Valid when using default group. Otherwise, i need to remove it {code} public class Command { @Valid public Children getChildren() { return this.children; } } {code} best regards Arthur Ronald F D Garcia was (Author: alpha88): Here goes some examples Spring MVC 3.0, for instance, supports JSR-303 by using @Valid as ElementType.PARAMETER {code} public void doSomething(@Valid Command command, BindingResult result) throws Exception {} {code} But if JSR-303 supports the concept of groups, how can i supply which group i want to test. Because of that, i need to implement a Spring Validator interface instead {code} public class CommandValidator implements Validator { public bollean supports(Class clazz) {} public void validate(Object command, Errors errors) { Set<ConstraintViolation<Command>> constraintViolationSet = ValidatorUtil.getValidator().validate((Command) command, SomeUseCase.class); // post-proccessing validation } } {code} So instead of (Not supported) {code} public void doSomething((a)Valid(groups=SomeUseCase.class) Command command, BindingResult result) throws Exception {} {code} I need to use (old-style) {code} private CommandValidator validator = new CommandValidator(); public void doSomething(Command command, BindingResult result) throws Exception { validator.validate(command, result); } {code} There is more As @Valid annotation fullfil nested properties, how can i supply which group of the nested property i want to test ??? As @Valid does not support groups attribute, i just can use @Valid when using default group. Otherwise, i need to remove it {code} public class Command { @Valid public Children getChildren() { return this.children; } } {code} best regards Arthur Ronald F D Garcia -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/BVAL-208?page=com.atlassian.jira.plug... ] Hardy Ferentschik commented on BVAL-208: ---------------------------------------- {quote} * define the group to validate in a method level annotation (parameter etc) {quote} I am not quite sure this is needed. If you have an actual constraint (_NotNull_, _Size_, etc) you can specify the groups. If you want to validate a whole object you add _@Valid_ to the parameter and the actual constraints (with their specified) groups are getting validated. I guess what I am saying here is that a group belongs to an actual constraint not to a marker (_@Valid_) which basically says all constraints of the anntated element must be valid. {code} public interface GroupA { } public interface GroupB { } public class Command { @NotNull(groups = GroupA.class) String name; } public class Executor { public void doSomething((a)Valid(groups=GroupB.class) Command command) { // ... } } // something like this to handle method validation public class ValidationInvocationHandler { //... public Object invoke(Object object, Method method, Object[] args) throws Throwable { Set<MethodConstraintViolation<Object>> constraintViolations; // ... constraintViolations = validator.validateAllParameters( object, method, args, GroupB.class ); if ( !constraintViolations.isEmpty() ) { throw new MethodConstraintViolationException( constraintViolations ); } Object result = method.invoke( wrapped, args ); constraintViolations = validator.validateReturnValue( wrapped, method, result, groups ); if ( !constraintViolations.isEmpty() ) { throw new MethodConstraintViolationException( constraintViolations ); } return result; } {code} Is a newly created _Command_ instance with a _null_ name valid in this case? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/BVAL-208?page=com.atlassian.jira.plug... ] Hardy Ferentschik edited comment on BVAL-208 at 4/3/12 8:55 AM: ---------------------------------------------------------------- {quote} * define the group to validate in a method level annotation (parameter etc) {quote} I am not quite sure this is needed. If you have an actual constraint (_NotNull_, _Size_, etc) you can specify the groups. If you want to validate a whole object you add _@Valid_ to the parameter and the actual constraints (with their specified) groups are getting validated. I guess what I am saying here is that a group belongs to an actual constraint not to a marker (_@Valid_) which basically says all constraints of the anntated element must be valid. {code} public interface GroupA { } {code} {code} public interface GroupB { } {code} {code} public class Command { @NotNull(groups = GroupA.class) String name; } {code} {code} public class Executor { public void doSomething((a)Valid(groups=GroupB.class) Command command) { // ... } } {code} {code} // something like this to handle method validation public class ValidationInvocationHandler { //... public Object invoke(Object object, Method method, Object[] args) throws Throwable { Set<MethodConstraintViolation<Object>> constraintViolations; // ... constraintViolations = validator.validateAllParameters( object, method, args, GroupB.class ); if ( !constraintViolations.isEmpty() ) { throw new MethodConstraintViolationException( constraintViolations ); } Object result = method.invoke( wrapped, args ); constraintViolations = validator.validateReturnValue( wrapped, method, result, groups ); if ( !constraintViolations.isEmpty() ) { throw new MethodConstraintViolationException( constraintViolations ); } return result; } {code} Is a newly created _Command_ instance with a _null_ name valid in this case? was (Author: hardy.ferentschik): {quote} * define the group to validate in a method level annotation (parameter etc) {quote} I am not quite sure this is needed. If you have an actual constraint (_NotNull_, _Size_, etc) you can specify the groups. If you want to validate a whole object you add _@Valid_ to the parameter and the actual constraints (with their specified) groups are getting validated. I guess what I am saying here is that a group belongs to an actual constraint not to a marker (_@Valid_) which basically says all constraints of the anntated element must be valid. {code} public interface GroupA { } {code} public interface GroupB { } {code} {code} public class Command { @NotNull(groups = GroupA.class) String name; } {code} {code} public class Executor { public void doSomething((a)Valid(groups=GroupB.class) Command command) { // ... } } {code} {code} // something like this to handle method validation public class ValidationInvocationHandler { //... public Object invoke(Object object, Method method, Object[] args) throws Throwable { Set<MethodConstraintViolation<Object>> constraintViolations; // ... constraintViolations = validator.validateAllParameters( object, method, args, GroupB.class ); if ( !constraintViolations.isEmpty() ) { throw new MethodConstraintViolationException( constraintViolations ); } Object result = method.invoke( wrapped, args ); constraintViolations = validator.validateReturnValue( wrapped, method, result, groups ); if ( !constraintViolations.isEmpty() ) { throw new MethodConstraintViolationException( constraintViolations ); } return result; } {code} Is a newly created _Command_ instance with a _null_ name valid in this case? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/BVAL-208?page=com.atlassian.jira.plug... ] Hardy Ferentschik commented on BVAL-208: ---------------------------------------- I think _@MethodValidated_ is a different beast. I lets _@Valid_ and constraint declarations intact. I guess I am most worried about modifying _@Valid_. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://hibernate.onjira.com/browse/BVAL-208?page=com.atlassian.jira.plug... ] Hardy Ferentschik commented on BVAL-208: ---------------------------------------- {quote} I agree with this concern. I think that if we bring this group translation idea to fruition, it is going to be a dedicated annotation. @ConverGroup(from=Foo.clas, to=Bar.class) {quote} +1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira