Exception in thread "main" java.lang.NoSuchMethodError: org.apache.curator.CuratorZookeeperClient.<init> exception - apache-curator

INFO [2020-02-10 07:03:32,933]
curator.utils.Compatibility:[Compatibility::48] - [main] -
Running in ZooKeeper 3.4.x compatibility mode INFO [2020-02-10
07:03:32,934] curator.utils.Compatibility:[Compatibility::61]
- [main] - Using emulated InjectSessionExpiration Exception in thread "main" java.lang.NoSuchMethodError:
org.apache.curator.CuratorZookeeperClient.(Lorg/apache/curator/utils/ZookeeperFactory;Lorg/apache/curator/ensemble/EnsembleProvider;IIILorg/apache/zookeeper/Watcher;Lorg/apache/curator/RetryPolicy;ZLorg/apache/curator/connection/ConnectionHandlingPolicy;)V
at
org.apache.curator.framework.imps.CuratorFrameworkImpl.(CuratorFrameworkImpl.java:131)
at
org.apache.curator.framework.CuratorFrameworkFactory$Builder.build(CuratorFrameworkFactory.java:165)
at
org.apache.curator.framework.CuratorFrameworkFactory.newClient(CuratorFrameworkFactory.java:113)
at
org.apache.curator.framework.CuratorFrameworkFactory.newClient(CuratorFrameworkFactory.java:94)
at
com.vnera.common.utils.DistributedSemaphore$CuratorFrameworkWrapper.(DistributedSemaphore.java:166)
at
com.vnera.common.utils.DistributedSemaphore.create(DistributedSemaphore.java:65)
at
com.vnera.tools.DistributedSemaphoreTestTool.main(DistributedSemaphoreTestTool.java:86)
Isn't curator 4.2 compatible with zookeepr 3.4.x?
Any pointers?

It is but you need to make sure your dependencies are correct. Please see the doc here: https://curator.apache.org/zk-compatibility.html
You need to:
Exclude the transitive dependency to ZooKeeper in your Curator dependency statement (the doc has examples for both Gradle and Maven)
Add a hard dependency to ZooKeeper 3.4.x

Related

Caused by: java.lang.NoClassDefFoundError: Could not initialize class io.confluent.kafka.serializers.KafkaAvroSerializerConfig since 6.0.0

im working on a flink (v.1.13.2) application which should publish some objects to my Kafka broker.
For schema validation I use the Confluent Schema Registry.
I previously used the library in version 5.2.0 (also tried other 5.x.x versions):
<dependency>
<groupId>io.confluent</groupId>
<artifactId>kafka-avro-serializer</artifactId>
<!--<version>5.x.x</version>-->
<version>6.2.0</version>
</dependency>
This seems to work but there was a strange behaviour while registering the schema to the registry. The schema was just ""bytes"" After investigation I found out that the suspect part in 'AvroSchemaUtils' was changed.
https://github.com/confluentinc/schema-registry/blob/a2f80f30d6713c50ee54c47885bcde2945932660/client/src/main/java/io/confluent/kafka/schemaregistry/avro/AvroSchemaUtils.java#L88
So I've tryed to update the library to the next working version.
After I updated to 6.x.x. I've got the following error:
Caused by: java.lang.NoClassDefFoundError: Could not initialize class io.confluent.kafka.serializers.KafkaAvroSerializerConfig
at io.confluent.kafka.serializers.KafkaAvroSerializer.configure(KafkaAvroSerializer.java:50)
at org.apache.kafka.clients.producer.KafkaProducer.<init>(KafkaProducer.java:369)
... 23 more
How to find out what wrong here?
This may be the problem. After Kafka Avro Serializer is upgraded, the dependent kafka client is upgraded from kafka_2.12 to kafka_2.13
https://mvnrepository.com/artifact/io.confluent/kafka-avro-serializer/6.2.0

Karate 0.9.1 - Exception in thread "main" java.lang.StackOverflowError

When I'm trying to run *.feature file or a single scenario with "right-click" (IntelliJ Idea), I've always received an exception:
Exception in thread "main" java.lang.StackOverflowError
at java.util.HashMap.<init>(HashMap.java:457)
at java.util.LinkedHashMap.<init>(LinkedHashMap.java:347)
at java.util.HashSet.<init>(HashSet.java:162)
at java.util.LinkedHashSet.<init>(LinkedHashSet.java:154)
at jdk.nashorn.internal.runtime.ScriptObject$KeyIterator.init(ScriptObject.java:2467)
at jdk.nashorn.internal.runtime.ScriptObject$ScriptObjectIterator.hasNext(ScriptObject.java:2441)
at jdk.nashorn.api.scripting.ScriptObjectMirror$13.call(ScriptObjectMirror.java:368)
at jdk.nashorn.api.scripting.ScriptObjectMirror$13.call(ScriptObjectMirror.java:363)
at jdk.nashorn.api.scripting.ScriptObjectMirror.inGlobal(ScriptObjectMirror.java:858)
at jdk.nashorn.api.scripting.ScriptObjectMirror.entrySet(ScriptObjectMirror.java:363)
at net.minidev.json.reader.JsonWriter$7.writeJSONString(JsonWriter.java:135)
at net.minidev.json.reader.JsonWriter$7.writeJSONString(JsonWriter.java:128)
at com.intuit.karate.JsonUtils$NashornObjectJsonWriter.writeJSONString(JsonUtils.java:77)
at com.intuit.karate.JsonUtils$NashornObjectJsonWriter.writeJSONString(JsonUtils.java:67)
...
Same scenario works fine if I run with TestRunner.java. Looks like that problem is in IJ cucumber plugin.
Maybe someone has a solution or workaround for this issue.
I'm using karate 0.9.1, cucumber for Java plugin: v183.4284.148, Idea 2018.3.3
No one has reported this - and from the stack-trace it looks like some JSON that you are using is being printed to the console - has some circular references, maybe you are using a Map of object references. But yes I can't explain why this works fine in the runner.
Can you follow the instructions here and submit a sample project, we can try open it in IntelliJ: https://github.com/intuit/karate/wiki/How-to-Submit-an-Issue
EDIT: this was a cyclic reference, but we have fixed it to be safe in future.

Exception while running Seedstack Application

I have used seedstack dependecies for Hibernate and JPA to create DAO services that performs crud operations on Database.
I am trying to Launch this Seedstack application module through Java application Launcher in eclipse, by SeedMain class.
In pom.xml - dependecy for undertow is given.
<dependency>
<groupId>org.seedstack.seed</groupId>
<artifactId>seed-web-undertow</artifactId>
</dependency>
When executing the SeedMain class, I am getting the below error snakeyaml error:-
Exception in thread "main" java.lang.NoSuchMethodError: org.yaml.snakeyaml.DumperOptions.setSplitLines(Z)V
at com.fasterxml.jackson.dataformat.yaml.YAMLGenerator.buildDumperOptions(YAMLGenerator.java:259)
at com.fasterxml.jackson.dataformat.yaml.YAMLGenerator.<init>(YAMLGenerator.java:232)
at com.fasterxml.jackson.dataformat.yaml.YAMLFactory._createGenerator(YAMLFactory.java:447)
at com.fasterxml.jackson.dataformat.yaml.YAMLFactory.createGenerator(YAMLFactory.java:397)
at org.seedstack.seed.core.internal.diagnostic.DefaultDiagnosticReporter.writeDiagnosticReport(DefaultDiagnosticReporter.java:75)
at org.seedstack.seed.core.internal.diagnostic.DefaultDiagnosticReporter.writeDiagnosticReport(DefaultDiagnosticReporter.java:67)
at org.seedstack.seed.core.internal.diagnostic.DiagnosticManagerImpl.dumpDiagnosticReport(DiagnosticManagerImpl.java:70)
at org.seedstack.seed.core.SeedMain.handleException(SeedMain.java:68)
at org.seedstack.seed.core.SeedMain.main(SeedMain.java:61)
As per my understanding the Error is due to some version inconsistency for snakeyaml, But for Seedstack as the versions for dependecies are resolved by seedstack-bom dependecy, so where exactly should I do the changes to resolve the error.
Thanks in Advance!
From reading the stacktrace, it seems that you have some error on startup which is handled by the handleException() method. This method then tries to write a YAML diagnostic report but ultimately fails due to the snakeyaml version issue you mentioned.
You should do two things:
Fix the snakeyaml dependency issue by looking into the dependency tree. This kind of problem is often caused by some library that makes Maven choose an older version. SeedStack needs at least jackson-dataformat-yaml version 2.9.4 which in turn needs at least snakeyaml 1.18.
Fix the other error by looking at the full stacktrace. When a diagnostic report cannot be written, the original exception is still printed on the console (on stderr).

Nullpoint exception when startup JDeveloper 12.1.3 with SOA suite

Any one met exceptions below when startup JDeveloper 12.1.3 with SOA suite ? this lead to I can not save the workspace, very bad. actually, I was wondering if there is anyone like JDeveloper, but I have to use it. :(
JDeveloper version: Build JDEVADF_12.1.3.0.0_GENERIC_140521.1008.S
Jdk version: java version "1.7.0_80"
stack trace as below:
SEVERE:
javax.naming.NamingException [Root exception is java.lang.NullPointerException]
at oracle.adf.share.jndi.ContextImpl.throwNamingException(ContextImpl.java:671)
at oracle.adf.share.jndi.ContextImpl.saveDocument(ContextImpl.java:968)
at oracle.adf.share.jndi.ContextImpl.save(ContextImpl.java:986)
at oracle.adf.share.dt.ConnectionNsChangeListener.refreshInternal(ConnectionNsChangeListener.java:242)
at oracle.adf.share.dt.ConnectionNsChangeListener.refresh(ConnectionNsChangeListener.java:180)
at oracle.adf.share.dt.ConnectionNsChangeListener.objectAdded(ConnectionNsChangeListener.java:43)
...
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)
Caused by: java.lang.NullPointerException
at oracle.jdevimpl.jps.JpsConfigUtilsImpl.getDefaultJpsContext(JpsConfigUtilsImpl.java:722)
at oracle.jdevimpl.jps.JpsConfigUtilsImpl.getCredentialStoreLocation(JpsConfigUtilsImpl.java:1407)
at oracle.adf.share.dt.security.providers.jps.CSFDTCredentialStore.checkInitCSFStore(CSFDTCredentialStore.java:333)
at oracle.adf.share.dt.security.providers.jps.CSFDTCredentialStore.fetchCredential(CSFDTCredentialStore.java:588)
at oracle.adf.share.dt.security.providers.jps.CSFDTCredentialStore.fetchCredential(CSFDTCredentialStore.java:578)
at oracle.adf.share.security.credentialstore.CredentialStore.fetchCredential(CredentialStore.java:187)
at oracle.adf.share.jndi.CredentialStoreHelper.fetchCredential(CredentialStoreHelper.java:104)
at oracle.adf.share.jndi.ReferenceStoreHelper.saveCredentialsInternal(ReferenceStoreHelper.java:520)
at oracle.adf.share.jndi.ReferenceStoreHelper.saveCredentials(ReferenceStoreHelper.java:476)
at oracle.adf.share.jndi.ContextImpl.saveDocument(ContextImpl.java:957)
... 123 more
this caused by 3 files below missing, usually it will not happen
src/META-INF/cwallet.sso
src/META-INF/cwallet.sso.lck
src/META-INF/jps-config.xml
please also refer to https://community.oracle.com/thread/3870268?sr=stream

NoSuchMethodError in Tomcat embedded MULE when executing http:set-cookie

When running Mule ESB 3.2.1 as embedded server inside Tomcat 7.0.27 (executed with webapp-runner), during execution of a flow with the Http endpoint, while sending response back to caller, an Exception is raised:
java.lang.NoSuchMethodError: org.apache.tomcat.util.http.ServerCookie.appendCookieValue(Ljava/lang/StringBuffer;ILjava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;IZ)V
Exception Below:
org.mule.api.MuleRuntimeException: Connector that caused exception is: connector.http.mule.default
at org.mule.transport.AbstractConnector.handleWorkException(AbstractConnector.java:2034)
at org.mule.transport.AbstractConnector.workCompleted(AbstractConnector.java:1998)
at org.mule.work.WorkerContext.run(WorkerContext.java:369)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.NoSuchMethodError: org.apache.tomcat.util.http.ServerCookie.appendCookieValue(Ljava/lang/StringBuffer;ILjava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;IZ)V
at org.mule.transport.http.CookieHelper.formatCookieForASetCookieHeader(CookieHelper.java:310)
at org.mule.transport.http.transformers.MuleMessageToHttpResponse.createResponse(MuleMessageToHttpResponse.java:261)
at org.mule.transport.http.transformers.MuleMessageToHttpResponse.transformMessage(MuleMessageToHttpResponse.java:90)
at org.mule.transformer.AbstractMessageTransformer.transform(AbstractMessageTransformer.java:145)
at org.mule.transformer.AbstractMessageTransformer.transform(AbstractMessageTransformer.java:93)
at org.mule.DefaultMuleMessage.applyAllTransformers(DefaultMuleMessage.java:1387)
at org.mule.DefaultMuleMessage.applyTransformers(DefaultMuleMessage.java:1348)
at org.mule.DefaultMuleMessage.applyTransformers(DefaultMuleMessage.java:1331)
at org.mule.transport.AbstractMessageReceiver.applyResponseTransformers(AbstractMessageReceiver.java:235)
at org.mule.transport.AbstractMessageReceiver.routeMessage(AbstractMessageReceiver.java:214)
at org.mule.transport.AbstractMessageReceiver.routeMessage(AbstractMessageReceiver.java:163)
at org.mule.transport.AbstractMessageReceiver.routeMessage(AbstractMessageReceiver.java:150)
at org.mule.transport.http.HttpMessageReceiver$HttpWorker.doRequest(HttpMessageReceiver.java:299)
at org.mule.transport.http.HttpMessageReceiver$HttpWorker.processRequest(HttpMessageReceiver.java:258)
at org.mule.transport.http.HttpMessageReceiver$HttpWorker.run(HttpMessageReceiver.java:163)
at org.mule.work.WorkerContext.run(WorkerContext.java:310)
If you are using Mule 3.2.1, you can not use the http:response-builder. The feature is just not there. That's why you can't use it.
Check it out:
It's not in the doc: http://www.mulesoft.org/documentation-3.2/display/32X/HTTP+Transport+Reference
It's not in the source: https://github.com/mulesoft/mule/blob/mule-3.2.1/transports/http/src/main/java/org/mule/transport/http/config/HttpNamespaceHandler.java#L56
I had this problem too. Check answer here.
Mule ESB does not work with cookie
In short, make sure you have provided group: 'org.apache.tomcat', name: 'coyote', version: '6.0.44' for mule 3.7.0.
In your case, you should have another library - tomcat-util 5.5.23 because you use different version of mule 3.2.1.
compile group: 'tomcat', name: 'tomcat-util', version: '5.5.23'
When you use SpringBoot, it ovverides a version of some library (depending on version of Spring and Mule), so you will get this error. You have class ServerCookie but the method appendCookieValue will disappear!
Solution - play with libraries. Or another bad workaround, write your own version of one of these classes that fail, and make sure classloader will use your version of the classes. (Again, creating a class with the same name and package to fix a bug - is a risky and bad thing...)