Here I will post a simple working implementation that works.
TODO:
1) Create a class that implements TraversableResolver like below:
package blogspot.soadev.validator; import java.lang.annotation.ElementType; import javax.validation.Path; import javax.validation.TraversableResolver; public class CustomTraversableResolver implements TraversableResolver { public boolean isReachable(Object traversableObject, Path.Node traversableProperty, Class rootBeanType, Path pathToTraversableObject, ElementType elementType) { return true; } public boolean isCascadable(Object object, Path.Node node, Class c, Path path, ElementType elementType) { return true; } }
2) Modify your code that gets the validator instance to as follows:
import blogspot.soadev.validator.CustomTraversableResolver; import javax.validation.Validation; import javax.validation.Validator; import javax.validation.ValidatorFactory; ... ValidatorFactory factory = Validation.byDefaultProvider().configure() .traversableResolver( new CustomTraversableResolver() ) .buildValidatorFactory(); Validator validator = factory.getValidator();
Kudos to Java Powers who first attended and tested this!
Related Posts
- JSR 303 Bean Validation: @AssertMethodAsTrue - A reusable constraint annotation that spans multiple properties.
- JSR 303 Bean Validation: @ValidateDateRange - A reusable constraint annotation to validate date ranges
- Integrating JSR 303 Bean Validation with Oracle ADF 11g
Pino
hi..there is no need to write a custom traversableresolver.
ReplyDeletejust upgrade your ejb-persistence-1.0.1.GA jar with ejb-persistence-1.0.2.GA.
hope it works.
Hi Beko,
ReplyDeleteThat is good to know.
Thanks,
Pino
Nice work. Tried all sorts of things to avoid this, but ended up having to do this. Our issue sprouts from hibernate validation not working right on a weblogic servers. Anyhow, this can be made more seamless if the new class is placed at the same spot where hibernate's is. Change the package of the class to be "org.hibernate.validator.engine.resolver" and there will be no need to create the validatorfactory. The one in the project will always be higher on the classpath, so it will get found first and used instead of the hibernate one. Just remember to put a giant todo in there to have it removed later, when the issue is fixed.
ReplyDeleteNice work. Tried all sorts of things to avoid this, but ended up having to do this. Our issue sprouts from hibernate validation not working right on a weblogic servers. Anyhow, this can be made more seamless if the new class is placed at the same spot where hibernate's is. Change the package of the class to be "org.hibernate.validator.engine.resolver" and there will be no need to create the validatorfactory. The one in the project will always be higher on the classpath, so it will get found first and used instead of the hibernate one. Just remember to put a giant todo in there to have it removed later, when the issue is fixed.
ReplyDeleteNice work. Tried all sorts of things to avoid this, but ended up having to do this. Our issue sprouts from hibernate validation not working right on a weblogic servers. Anyhow, this can be made more seamless if the new class is placed at the same spot where hibernate's is. Change the package of the class to be "org.hibernate.validator.engine.resolver" and there will be no need to create the validatorfactory. The one in the project will always be higher on the classpath, so it will get found first and used instead of the hibernate one. Just remember to put a giant todo in there to have it removed later, when the issue is fixed.
ReplyDelete