Saturday, February 6, 2010

JSR 303 Bean Validation: Error "java.lang.NoSuchMethodError: javax.persistence.Persistence.getPersistenceUtil()Ljavax/persistence/PersistenceUtil;"

When we adopted the JSR 303 Bean Validation into our ADF/EJB project, we encountered the above error, so I posted on hibernate forums and was advised to implement my own custom class that implements TraversableResolver (Check the discussion here).
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

Cheers!

Pino

5 comments:

  1. hi..there is no need to write a custom traversableresolver.
    just upgrade your ejb-persistence-1.0.1.GA jar with ejb-persistence-1.0.2.GA.
    hope it works.

    ReplyDelete
  2. Hi Beko,

    That is good to know.

    Thanks,
    Pino

    ReplyDelete
  3. 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.

    ReplyDelete
  4. 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.

    ReplyDelete
  5. 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.

    ReplyDelete