Project I am working on requires the use of both Elasticsearch and a dependency (I didn't design or get to dictate its design) that utilizes Lucene and running into a version conflict between the two. The following error is spit out when I try to start the project
Exception in thread "main" java.lang.NoSuchFieldError: LUCENE_5_2_1
at org.elasticsearch.Version.<clinit>(Version.java:39)
at org.elasticsearch.common.io.stream.StreamOutput.<init>(StreamOutput.java:74)
at org.elasticsearch.common.io.stream.BytesStreamOutput.<init>(BytesStreamOutput.java:60)
at org.elasticsearch.common.io.stream.BytesStreamOutput.<init>(BytesStreamOutput.java:57)
at org.elasticsearch.common.io.stream.BytesStreamOutput.<init>(BytesStreamOutput.java:47)
at org.elasticsearch.common.xcontent.XContentBuilder.builder(XContentBuilder.java:69)
at org.elasticsearch.common.settings.Setting.arrayToParsableString(Setting.java:726)
at org.elasticsearch.common.settings.Setting.lambda$listSetting$26(Setting.java:672)
at org.elasticsearch.common.settings.Setting$2.getRaw(Setting.java:676)
at org.elasticsearch.common.settings.Setting.lambda$listSetting$24(Setting.java:660)
at org.elasticsearch.common.settings.Setting.listSetting(Setting.java:665)
at org.elasticsearch.common.settings.Setting.listSetting(Setting.java:660)
at org.elasticsearch.common.network.NetworkService.<clinit>(NetworkService.java:50)
at org.elasticsearch.client.transport.TransportClient.newPluginService(TransportClient.java:91)
at org.elasticsearch.client.transport.TransportClient.buildTemplate(TransportClient.java:119)
at org.elasticsearch.client.transport.TransportClient.<init>(TransportClient.java:247)
at org.elasticsearch.transport.client.PreBuiltTransportClient.<init>(PreBuiltTransportClient.java:92)
at org.elasticsearch.transport.client.PreBuiltTransportClient.<init>(PreBuiltTransportClient.java:81)
at org.elasticsearch.transport.client.PreBuiltTransportClient.<init>(PreBuiltTransportClient.java:71)
Any idea on whether or not its possible to resolve without being able to dictate the design of the dependency or Elasticsearch?
Ended up adding the Lucene core dependency version that is being mentioned in the error to the project. build.gradle now contains compile group: 'org.apache.lucene', name: 'lucene-core', version: '5.2.1' and that solved the problem.
Related
I don't know if the kubernetes upgrade has anything to do with the problem, but it's the only change I know of between the time the application was working as expected and when it started throwing this exception.
I have some code in a Spring Boot app that adds a List<Object> to a JSONObject. The line looks like this:
jsonObject.put("some_name", someList);
This code hasn't been touched in a year, but suddenly started throwing this exception after a k8s upgrade from 1.21 to 1.23:
org.springframework.web.util.NestedServletException: Handler dispatch failed; nested exception is java.lang.NoSuchMethodError: 'org.json.JSONObject org.json.JSONObject.put(java.lang.String, java.util.Collection)' at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:1082)
[...]
Caused by: java.lang.NoSuchMethodError: 'org.json.JSONObject org.json.JSONObject.put(java.lang.String, java.util.Collection)' at com.example.service.MyClass.convertToJson(MyClass.java:109)
The k8s upgrade also included a change from Java 17.0.5+8 to Java 17.0.6+10, but everything runs as expected locally using both of those JDK versions.
I ran a mvn dependency tree -Dverbose and couldn't find anything weird there either. These were the only entries that had to do with json.
org.json:json:jar:20220320
org.springframework.boot:spring-boot-starter-json:jar:2.6.4
I'm out of ideas for what might be causing this issue, so any suggestions on what to look at next are welcome.
It could be that the version of org.json:json included in your project is out of date, and doesn't include the put(String, Collection) method you're trying to use. Try updating this dependency to a more recent version and seeing if that resolves the issue. It's also possible there are some other dependencies in your project which conflict with org.json:json or override it with an older version - check for any similarly named libraries (e.g., json-simple instead of org.json). You may also want to check the version of Spring Boot you're using, as this might be incompatible with the org.json library you're trying to use.
I just updated my Hibernate dependencies in my gradle build file from:
implementation 'org.hibernate:hibernate-core:5.4.12.Final'
implementation 'org.hibernate.validator:hibernate-validator:6.0.18.Final'
implementation 'org.hibernate:hibernate-c3p0:5.4.21.Final'
to:
implementation 'org.hibernate:hibernate-core:5.5.7.Final'
implementation 'org.hibernate.validator:hibernate-validator:7.0.1.Final'
implementation 'org.hibernate:hibernate-c3p0:5.5.7.Final'
I already saw, that the validation API has been moved from javax.* to jakarta.* and I guess it has something to do with that. However, I was not able to find out which dependencies are in conflict in this case and what I would have to change to make it compatible.
Can someone help me there?
I solved it by adding 'javax.validation:validation-api:2.0.1.Final' to my dependencies. Can anyone explain to me why this is explicitly required? Are parts of the validation API still in the javax package?
I faced with same exception. It throws from TypeSafeActivator class
So according to https://hibernate.org/orm/releases/5.5/
Hibernate ORM 5.5 adds new artifacts with the artifact id suffix
"-jakarta" like hibernate-core-jakarta.
In our Corda project We are using FlowExternalAsyncOperation to interact with an external service. The flows are able to interact with external service when invoked via Corda node cli. We have implemented a standalone rpc client to invoke the flows. We are getting the below error when trying to start the nodes via rpc connection. Below is the stack trace of the error
Exception in thread "main" java.lang.NoSuchMethodError: com.google.common.util.concurrent.MoreExecutors.directExecutor()Ljava/util/concurrent/Executor;
at net.corda.client.rpc.internal.RPCClientProxyHandler.createRpcObservableMap(RPCClientProxyHandler.kt:205)
at net.corda.client.rpc.internal.RPCClientProxyHandler.<init>(RPCClientProxyHandler.kt:168)
at net.corda.client.rpc.internal.RPCClientProxyHandler.<init>(RPCClientProxyHandler.kt:108)
at net.corda.client.rpc.internal.RPCClient$start$1.invoke(RPCClient.kt:90)
at net.corda.client.rpc.internal.RPCClient$start$1.invoke(RPCClient.kt:32)
at net.corda.core.internal.InternalUtils.logElapsedTime(InternalUtils.kt:224)
at net.corda.core.internal.InternalUtils.logElapsedTime(InternalUtils.kt:214)
at net.corda.client.rpc.internal.RPCClient.start(RPCClient.kt:72)
at net.corda.client.rpc.CordaRPCClient.start(CordaRPCClient.kt:620)
at net.corda.client.rpc.CordaRPCClient.start(CordaRPCClient.kt:575)
at net.corda.client.rpc.CordaRPCClient.start(CordaRPCClient.kt:529)
at net.corda.client.rpc.CordaRPCClient.start$default(CordaRPCClient.kt:527)
at net.corda.client.rpc.CordaRPCClient.start(CordaRPCClient.kt)
Putting the solution in the answer.
The issue comes mostly due to version mismatch in the dependencies. This case perhaps has two different versions of the same library. One of them can be excluded using gradle.
Example:
compile('org.springframework.boot:spring-boot-starter-web') {
exclude group: 'org.springframework.boot', module: 'spring-boot-starter-tomcat'
}
I am am migrating project to dagger 1.2.2. I'd like to override some dependencies for functional tests. For that I included the dagger-compiler as a dependency of the androidTest-build(?) as well:
apt "com.squareup.dagger:dagger-compiler:$daggerVersion"
compile "com.squareup.dagger:dagger:$daggerVersion"
androidTestApt "com.squareup.dagger:dagger-compiler:$daggerVersion
Now the compiler complains that he cannot find a class (I guess because both builds now contain the transitive dependencies of dagger-compiler):
Error:Execution failed for task ':app:compileDebugAndroidTestJava'.
> java.lang.NoClassDefFoundError: javax/inject/Scope
Looking around github it seems the approach should work without manually excluding stuff.
Nevermind. Actually reading the whole buildfile helps alot.
Because of previous dependency-foo I had a directive that excluded the missing dependency explicitly:
configurations {
androidTestCompile.exclude(group:'javax.inject')
}
Removing that fixed it.
My project depends on the Pax Exam framework. I declare, among others, these dependencies on Pax (PAX_EXAM_VERSION = 3.4.0):
compile group: 'org.ops4j.pax.exam', name: 'pax-exam-junit4', version: PAX_EXAM_VERSION
compile group: 'org.ops4j.pax.exam', name: 'pax-exam-container-native', version: PAX_EXAM_VERSION
Both of these depend on org.ops4j.pax.exam:pax-exam-spi, which is the module causing my issue.
So, when I try to build my project, the error reported is this one:
Could not resolve org.ops4j.pax.exam:pax-exam-spi:3.4.0
...
Could not parse POM http://repo.maven.apache.org/maven2/org/ops4j/pax/exam/pax-exam-spi/3.4.0/pax-exam-spi-3.4.0.pom
Unable to resolve version for dependency 'com.google.guava:guava:jar'
I have tried:
excluding pax-exam-spi from the transitive dependencies of the modules I depend on (but notice I still need the classes in it to be able to compile), adding Guava to my first-level dependencies, then trying to make pax-exam-spi a first-level dependency with transitive = false (won't work, same problem as above).
same as above, but instead of doing transitive = false, trying to use artifact-only notation, like this:
compile "org.ops4j.pax.exam:pax-exam-spi:${PAX_EXAM_VERSION}#jar"
I know the root of the problem is that the guava version is not declared in the pax-exam-spi pom, but in its parent exam, which only declares the Guava version(s) to use in 2 different profiles' dependencyManagement sessions (this works in Maven because one of the profiles is activated if the property glassfish.release is NOT set, and the other if that property IS set). However, knowing this has not been useful so far :(
Please let me know if there's any not-so-hacky way to make sure Gradle does include the pax-exam-spi's jar in my classpath, but does not even try to parse its POM (in particular, referring to a hard-coded path to the jar is out of question!).