I am trying to replace my local geckodriver.exe with WebDriverManager, but when i invoke
WebDriverManager.firefoxdriver().setup();
i get the following error
4391 [main] INFO io.github.bonigarcia.wdm.WebDriverManager - Reading https://api.github.com/repos/mozilla/geckodriver/releases to seek geckodriver
4704 [main] WARN io.github.bonigarcia.wdm.WebDriverManager - There was an error managing geckodriver (latest version) (Type com.google.gson.internal.LinkedTreeMap not present) ... trying again using latest driver stored in cache
4704 [main] INFO io.github.bonigarcia.wdm.WebDriverManager - Reading https://api.github.com/repos/mozilla/geckodriver/releases to seek geckodriver
4876 [main] ERROR io.github.bonigarcia.wdm.WebDriverManager - There was an error managing geckodriver (latest version) (Type com.google.gson.internal.LinkedTreeMap not present)
java.lang.TypeNotPresentException: Type com.google.gson.internal.LinkedTreeMap not present
at sun.reflect.generics.factory.CoreReflectionFactory.makeNamedType(CoreReflectionFactory.java:117)
at sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Reifier.java:125)
at sun.reflect.generics.tree.ClassTypeSignature.accept(ClassTypeSignature.java:49)
at sun.reflect.generics.visitor.Reifier.reifyTypeArguments(Reifier.java:68)
...
at io.github.bonigarcia.wdm.WebDriverManager.fallback(WebDriverManager.java:825)
at io.github.bonigarcia.wdm.WebDriverManager.handleException(WebDriverManager.java:802)
at io.github.bonigarcia.wdm.WebDriverManager.manage(WebDriverManager.java:599)
at io.github.bonigarcia.wdm.WebDriverManager.setup(WebDriverManager.java:287)
I am using the latest 5.0.3 WebDriverManager from maven
<dependency>
<groupId>io.github.bonigarcia</groupId>
<artifactId>webdrivermanager</artifactId>
<version>5.0.3</version>
</dependency>
TypeNotPresentException is thrown when an application tries to access a type using a string representing the type's name, but no definition for the type with the specified name can be found.
It's pretty similar to ClassNotFoundException, but not checked during compilation.
But the root cause is:
com.google.gson.internal.LinkedTreeMap not present in the project classpath.
Try to add gson dependency to the project.
<dependency>
<groupId>com.google.code.gson</groupId>
<artifactId>gson</artifactId>
<version>2.9.0</version>
</dependency>
https://docs.oracle.com/javase/9/docs/api/java/lang/TypeNotPresentException.html
Change the WebDriverManager scope to test in pom.xml as follows:
<dependency>
<groupId>io.github.bonigarcia</groupId>
<artifactId>webdrivermanager</artifactId>
<version>5.0.3</version>
<scope>test</scope>
</dependency>
or change the scope to compile in pom.xml as follows:
<dependency>
<groupId>io.github.bonigarcia</groupId>
<artifactId>webdrivermanager</artifactId>
<version>5.0.3</version>
<scope>compile</scope>
</dependency>
Additionally, you may need to add the slf4j dependency as follows:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.25</version>
</dependency>
As per Driver Management - Feature:
Although not mandatory, it is highly recommended to use a logger library to trace your application and tests. In the case of WebDriverManager, you will see the relevant steps of the driver management following its traces. See for example the following tutorial to use SLF4J and Logback. Also, you can see an example of a WebDriverManager test using logging here (this example uses this configuration file).
Reference
You can find a couple of relevant detailed discussion in:
I am getting an error while executing the basic website launch using web driver manager
Related
I recently started upgrading my application JDK version from jdk1.7.0_121_x64 to jdk1.8.0_202_x64. I have some legacy code using Drools 5.4.0.Final. This code is working with JDK version jdk1.7.0_121_x64 without any issue.
Maven dependencies are:
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-core</artifactId>
<version>5.4.0.Final</version>
</dependency>
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-decisiontables</artifactId>
<version>5.4.0.Final</version>
</dependency>
DRL files are loaded as:
final KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase();
final KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
kbuilder.add(resource, ResourceType.DRL);
knowledgeBase.addKnowledgePackages(kbuilder.getKnowledgePackages());
I was aware that there are issues using Drools with JDK 8. I referrred to other SO thread to start with.
When I built my application and executed Junit tests using JDK 8, tests failed with error:
testRunRule(com.company.app.RuleTest) Time elapsed: 0.073 sec <<< ERROR!
java.lang.RuntimeException: java.lang.RuntimeException: wrong class format
at org.eclipse.jdt.internal.compiler.classfmt.ClassFileReader.<init>(ClassFileReader.java:372)
at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.createNameEnvironmentAnswer(EclipseJavaCompiler.java:287)
at org.drools.commons.jci.compilers.EclipseJavaCompiler$2.findType(EclipseJavaCompiler.java:258)
As mentioned in SO thread, I found reference to this bugfix ticket DROOLS-329.
Based on approaches mentioned in this bugfix ticket, I tried to use JANINO compiler:
Added following maven dependency:
<dependency>
<groupId>org.codehaus.janino</groupId>
<artifactId>janino</artifactId>
<version>2.5.16</version>
</dependency>
I added following VM argument (I was running tests from eclipse, so in eclipse launch configuration in JRE VM argument added the argument):
-Ddrools.dialect.java.compiler=JANINO
I could still see the wrong class format error. So I modified my code to load DRL files as:
final KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase();
final Properties props = new Properties();
props.setProperty("drools.dialect.java.compiler", "JANINO");
final KnowledgeBuilderConfiguration config = KnowledgeBuilderFactory.newKnowledgeBuilderConfiguration(props, null);
final KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder(config);
kbuilder.add(resource, ResourceType.DRL);
knowledgeBase.addKnowledgePackages(kbuilder.getKnowledgePackages());
It didn't help. I could still see the wrong class format error.
I followed another apprroach mentioned in this external link. I updated added/updated maven dependencies as:
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-core</artifactId>
<version>5.4.0.Final</version>
<exclusions>
<exclusion>
<groupId>org.mvel</groupId>
<artifactId>mvel2</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.drools</groupId>
<artifactId>drools-decisiontables</artifactId>
<version>5.4.0.Final</version>
<exclusions>
<exclusion>
<groupId>org.eclipse.jdt.core.compiler</groupId>
<artifactId>ecj</artifactId>
</exclusion>
<exclusion>
<groupId>org.mvel</groupId>
<artifactId>mvel2</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.mvel</groupId>
<artifactId>mvel2</artifactId>
<version>2.1.9.Final</version>
</dependency>
<dependency>
<groupId>org.eclipse.jdt.core.compiler</groupId>
<artifactId>ecj</artifactId>
<version>4.6.1</version>
</dependency>
mvel2 patch is built using:
https://github.com/mkornipati/mvel/tree/2.1.9.Final.Patch
With this wrong class format error is gone. But my tests are now failing with following error:
testRunRule(com.company.app.RuleTest)) Time elapsed: 4.684 sec <<< ERROR!
java.lang.RuntimeException: org.drools.rule.InvalidRulePackage: Rule Compilation error : [Rule name='ruleCheck']
org/drools/template/parser/Rule_ruleCheck_8eb4621227714a36b7b84c8b764527e4.java (2:80) : Only a type can be imported. java.util.Map resolves to a package
org/drools/template/parser/Rule_ruleCheck_8eb4621227714a36b7b84c8b764527e4.java (2:101) : Only a type can be imported. java.util.HashMap resolves to a package
org/drools/template/parser/Rule_ruleCheck_8eb4621227714a36b7b84c8b764527e4.java (6:299) : org.drools.spi.KnowledgeHelper cannot be resolved to a type
org/drools/template/parser/Rule_ruleCheck_8eb4621227714a36b7b84c8b764527e4.java (6:339) : org.drools.template.parser.Row cannot be resolved to a type
org/drools/template/parser/Rule_ruleCheck_8eb4621227714a36b7b84c8b764527e4.java (6:373) : org.drools.FactHandle cannot be resolved to a type
org/drools/template/parser/Rule_ruleCheck_8eb4621227714a36b7b84c8b764527e4.java (6:411) : org.drools.template.parser.DefaultGenerator cannot be resolved to a type
org/drools/template/parser/Rule_ruleCheck_8eb4621227714a36b7b84c8b764527e4.java (6:487) : org.drools.runtime.rule.RuleContext cannot be resolved to a type
at org.drools.rule.Package.checkValidity(Package.java:445)
I don't know how to proceed further. Please let me know if you are able to make Drools 5.4 work with JDK 8.
I used Drools 7.7.0 with Java 8 and worked great for me. I am not sure what is the oldest Drools version that is compatible with Java 8. That said, Drools 5.4.0 was released in 2011. Java 8 was released in 2014, so you can assume it won't be compatible. Java 7 was released in July 2011. Depending on when 5.4.0 was released it might or might not be. Based on that, I expect Drools 5.4.0 to be compatible with Java 6 or earlier. If you want to use Java 8 with Drools, I don't see how you can without upgrading. I think the earliest compatible version is 6.1.0 download.jboss.org/drools/release.
In summary: Either downgrade your project to Java 6 to use Drools 5.4.0 or Upgrade Drools to use 6.1.0. Better yet, upgrade to latest Drools and then figure out what is the latest Java version it supports.
I made a program that parses turtle files with Jena library. These are the dependencies i use:
<dependency>
<groupId>org.apache.jena</groupId>
<artifactId>jena-iri</artifactId>
<version>3.10.0</version>
</dependency>
<dependency>
<groupId>org.apache.jena</groupId>
<artifactId>jena-core</artifactId>
<version>3.10.0</version>
</dependency>
<dependency>
<groupId>org.apache.jena</groupId>
<artifactId>jena-arq</artifactId>
<version>3.10.0</version>
</dependency>
<dependency>
<groupId>org.apache.jena</groupId>
<artifactId>jena-tdb</artifactId>
<version>3.10.0</version>
</dependency>
So the parsing is working well on my java program but when i create my jar and try to run it, i have these kind of errors :
ERROR JenaService:146 - org.apache.jena.n3.turtle.TurtleParseException: Line 28015, column 79: org.apache.jena.iri.impl.IRIImplException:
<http://www.reussir.fr,> Code: 28/NOT_DNS_NAME in HOST: The host component did not meet the restrictions on DNS names.
Any ideas ?
EDIT
I have a warning for the invalid IRI problem by running my program with the IDE, but still giving me errors with the generated jar.
<http://www.reussir.fr,>
There is a comma in the URI in a place where commas are not allowed.
It is better to find and fix the data problem because it can lead to other problems later if not fixed.
I found the problem, the only dependency i really needed was jena-arq, so i removed others dependencies (especially jena-iri which was throwing the TurtleParseException) and the bad-iri errors became warnings like in the IDE execution logs.
Has anyone used Spring JDBC with Clickhouse? What is the driver class name?
spring.datasource.driver-class-name=<what is it?>
I guess it could be it, even though it doesn't look like any other driver class names that I have seen.
spring.datasource.driver-class-name=ru.yandex.clickhouse.ClickHouseDriver
There is also lighter and faster alternative to the official driver version - clickhouse4j. (fork of the official driver with some improvements)
You can use it like this:
spring.datasource.driver-class-name=cc.blynk.clickhouse.ClickHouseDriver
Driver was renamed due to moving vom yandex to clickhouse.com.
Clickhouse Driver
spring.datasource.driver-class-name=com.clickhouse.jdbc.ClickHouseDriver
See https://github.com/ClickHouse/clickhouse-jdbc
Also note Java Client and JDBC Driver MVN dependencies changed as well:
Maven Clickhouse Java Client
<dependency>
<groupId>com.clickhouse</groupId>
<!-- or clickhouse-grpc-client if you prefer gRPC -->
<artifactId>clickhouse-http-client</artifactId>
<version>0.3.2-patch11</version>
</dependency>
Maven Clickhouse JDBC Driver
<dependency>
<!-- please stop using ru.yandex.clickhouse as it's been deprecated -->
<groupId>com.clickhouse</groupId>
<artifactId>clickhouse-jdbc</artifactId>
<version>0.3.2-patch11</version>
<!-- use uber jar with all dependencies included, change classifier to http for smaller jar -->
<classifier>all</classifier>
<exclusions>
<exclusion>
<groupId>*</groupId>
<artifactId>*</artifactId>
</exclusion>
</exclusions>
</dependency>
Starting 4.0.0 yandex packages will be removed and be non functional!
We are using a library called logback-ext-cloudwatch-appender to send our logback-based logs to AWS Cloudwatch. This is what the dependency looks like in our pom.xml file.
<dependency>
<groupId>org.eluder.logback</groupId>
<artifactId>logback-ext-cloudwatch-appender</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
A few days ago these errors started appearing in our logs.
java.lang.NoSuchMethodError: com.amazonaws.transform.JsonErrorUnmarshaller: method <init>(Ljava/lang/Class;)V not found
at com.amazonaws.services.logs.model.transform.InvalidParameterExceptionUnmarshaller.<init>(InvalidParameterExceptionUnmarshaller.java:26)
at com.amazonaws.services.logs.AWSLogsClient.init(AWSLogsClient.java:280)
at com.amazonaws.services.logs.AWSLogsClient.<init>(AWSLogsClient.java:275)
at com.amazonaws.services.logs.AWSLogsClient.<init>(AWSLogsClient.java:248)
at org.eluder.logback.ext.cloudwatch.appender.AbstractCloudWatchAppender.doStart(AbstractCloudWatchAppender.java:100)
at org.eluder.logback.ext.aws.core.AbstractAwsEncodingStringAppender.start(AbstractAwsEncodingStringAppender.java:123)
at org.eluder.logback.ext.cloudwatch.appender.AbstractCloudWatchAppender.start(AbstractCloudWatchAppender.java:95)
at ch.qos.logback.ext.spring.DelegatingLogbackAppender.getDelegate(Unknown Source)
at ch.qos.logback.ext.spring.DelegatingLogbackAppender.append(Unknown Source)
at ch.qos.logback.ext.spring.DelegatingLogbackAppender.append(Unknown Source)
at ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:84)
at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:48)
at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:270)
at ch.qos.logback.classic.Logger.callAppenders(Logger.java:257)
at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:421)
at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:383)
at ch.qos.logback.classic.Logger.info(Logger.java:579)
(truncated)
I found out that we had upgraded to AWS 1.11.5, but I couldn't find any evidence of such a bug in that release.
It turns out that the current version of logback-ext-cloudwatch-appender has a transitive dependency on a specific version of aws-java-sdk-logs 1.10.2, which is not compatible with other aws-java-sdk libraries 1.11.0 and above. We do use a number of other aws-java-sdk libraries. We excluded the dependency like this.
<dependency>
<groupId>org.eluder.logback</groupId>
<artifactId>logback-ext-cloudwatch-appender</artifactId>
<version>1.0-SNAPSHOT</version>
<exclusions>
<exclusion>
<groupId>com.amazonaws</groupId>
<artifactId>aws-java-sdk-core</artifactId>
</exclusion>
<exclusion>
<groupId>com.amazonaws</groupId>
<artifactId>aws-java-sdk-logs</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.amazonaws</groupId>
<artifactId>aws-java-sdk-core</artifactId>
<version>1.11.5</version>
</dependency>
<dependency>
<groupId>com.amazonaws</groupId>
<artifactId>aws-java-sdk-logs</artifactId>
<version>1.11.5</version>
</dependency>
At that point we started getting another error.
Exception in thread "org.myorg.task.MyTask working" java.lang.NoSuchMethodError: com.amazonaws.services.logs.AWSLogsClient.createLogGroup(Lcom/amazonaws/services/logs/model/CreateLogGroupRequest;)V
at org.eluder.logback.ext.cloudwatch.appender.AbstractCloudWatchAppender.createLogGroup(AbstractCloudWatchAppender.java:171)
at org.eluder.logback.ext.cloudwatch.appender.AbstractCloudWatchAppender.doStart(AbstractCloudWatchAppender.java:107)
at org.eluder.logback.ext.aws.core.AbstractAwsEncodingStringAppender.start(AbstractAwsEncodingStringAppender.java:123)
at org.eluder.logback.ext.cloudwatch.appender.AbstractCloudWatchAppender.start(AbstractCloudWatchAppender.java:95)
at ch.qos.logback.core.joran.action.AppenderAction.end(AppenderAction.java:90)
at ch.qos.logback.core.joran.spi.Interpreter.callEndAction(Interpreter.java:309)
at ch.qos.logback.core.joran.spi.Interpreter.endElement(Interpreter.java:193)
at ch.qos.logback.core.joran.spi.Interpreter.endElement(Interpreter.java:179)
at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:62)
at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:155)
at ch.qos.logback.core.sift.SiftingJoranConfiguratorBase.doConfigure(SiftingJoranConfiguratorBase.java:82)
at ch.qos.logback.core.sift.AbstractAppenderFactoryUsingJoran.buildAppender(AbstractAppenderFactoryUsingJoran.java:51)
at ch.qos.logback.core.sift.AppenderTracker.buildComponent(AppenderTracker.java:56)
at ch.qos.logback.core.sift.AppenderTracker.buildComponent(AppenderTracker.java:32)
at ch.qos.logback.core.spi.AbstractComponentTracker.getOrCreate(AbstractComponentTracker.java:124)
at ch.qos.logback.core.sift.SiftingAppenderBase.append(SiftingAppenderBase.java:104)
at ch.qos.logback.core.AppenderBase.doAppend(AppenderBase.java:82)
at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:48)
at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:270)
at ch.qos.logback.classic.Logger.callAppenders(Logger.java:257)
at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:421)
at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:383)
at ch.qos.logback.classic.Logger.info(Logger.java:579)
Merely excluding the dependencies did not work. I had to fork and rebuild the logback-ext-cloudwatch-appender jar with a dependency on the current 1.11.5 aws-java-sdk libraries. Trying to use the new AWS dependencies with the logback-ext-cloudwatch-appender jar which had been built against the old libraries caused a mismatch in the method signature (return type) of createLogGroup which caused a runtime error. To get this to run, I only had to change the pom.xml files, not the source code, in my forked version.
I'm trying to use Hibernate Validator in my project, but it isn't working. On the following line:
SessionFactory sessions = config.buildSessionFactory(builder.build());
I get the following exception:
org.hibernate.cfg.beanvalidation.IntegrationException: Error activating Bean Validation integration
at org.hibernate.cfg.beanvalidation.BeanValidationIntegrator.integrate(BeanValidationIntegrator.java:154)
at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:311)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1857)
at net.myProject.server.util.HibernateUtil.<clinit>(HibernateUtil.java:32)
... 36 more
Caused by: java.lang.NoSuchMethodError: javax.validation.spi.ConfigurationState.getParameterNameProvider()Ljavax/validation/ParameterNameProvider;
at org.hibernate.validator.internal.engine.ValidatorFactoryImpl.<init>(ValidatorFactoryImpl.java:119)
at org.hibernate.validator.HibernateValidator.buildValidatorFactory(HibernateValidator.java:45)
at org.hibernate.validator.internal.engine.ConfigurationImpl.buildValidatorFactory(ConfigurationImpl.java:217)
at javax.validation.Validation.buildDefaultValidatorFactory(Validation.java:111)
I found this question which seems quite similar to my problem. He describes his solution as
I had yet another bean validator jar in the class path. But not from
maven, so i didn't realize it. Removing that solved the problem.
I think my problem is the same. On http://hibernate.org/validator/documentation/getting-started/ it says:
This transitively pulls in the dependency to the Bean Validation API
(javax.validation:validation-api:1.1.0.Final)
That must be causing this issue, since reverting to an older version (4.3.1.Final) fixes the issue. Is there a way to force Hibernate to not pull in the Bean Validation API?
Edit: I've tried to exclude the javax-validation api:
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-validator</artifactId>
<version>5.0.3.Final</version>
<exclusions>
<exclusion>
<groupId>javax.validation</groupId>
<artifactId>validation-api</artifactId>
</exclusion>
</exclusions>
</dependency>
But it didn't seem to have any effect.
Try adding this dependency to your pom.xml
<dependency>
<groupId>javax.validation</groupId>
<artifactId>validation-api</artifactId>
<version>1.0.0.GA</version>
</dependency>
If not consider using hibernate-validator4.2.0.Final I have that one in my config and it is working fine.
For me, the 1.1.0.Final version javax.validation.validation-api had worked. Because, the javax.validation.spi.ConfigurationState interface of 1.1.0.Final has getParameterNameProvider method, which was absent in 1.0.0.GA.
I added the below dependency in pom.xml
<dependency>
<groupId>javax.validation</groupId>
<artifactId>validation-api</artifactId>
<version>1.1.0.Final</version>
<scope>test</scope>
</dependency>
I had the problem again. Thats how I've fixed that:
1-Exclude spring.validator from the 'web' dependency:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<exclusions>
<exclusion>
<groupId>org.hibernate.validator</groupId>
<artifactId>hibernate-validator</artifactId>
</exclusion>
</exclusions>
</dependency>
2-After insert the dependecy with a previous version:
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-validator</artifactId>
<version>5.1.3.Final</version>
</dependency>
in my case i just deleted the hibernate-validator and it worked .(i also had a combo of both validation api and hibernate-validator and tried everything) or you can go to your maven repository-->org and then delete the hibernate folder and rebuild your project again..
hope it helps..
I thought it would be useful to explain what is going on here.
Hibernate is calling ConfigurationState.getParameterNameProvider:
ValidatorFactoryImpl.java:
public ValidatorFactoryImpl(ConfigurationState configurationState) {
...
configurationState.getParameterNameProvider()
...
}
You can find the documentation of getParameterNameProvider:
getParameterNameProvider
ParameterNameProvider getParameterNameProvider()
Returns the parameter name provider for this configuration.
Returns:
parameter name provider instance or null if not defined
Since:
1.1
So what's the problem? The problem is that the method didn't always exist. It was added at some point in the future.
And the rule when creating interfaces is that they are set in concrete: you shall not change an interface ever. Instead the JavaX validator changed the ConfigurationState interface, and added a few new methods over the years.
The java validation code is passing the Hiberate an outdated ConfiguationState interface; one that doesn't implement the required interfaces.
You need to ensure that javax.validation.Validation.buildDefaultValidatorFactory is updated to to support version 1.1.
Removing this jar javax.validation:validation-api:1.1.0.Final solved my problem.
Make sure you have only one validation jar. If we have two jars then they may conflict resulting in error.
Go to the dependecies project and delete, hibernate.validator, and reinstall that in the most recent version. It has solved the problem for me.