java.lang.NoSuchMethodError: io.grpc.NameResolverProvider.getScheme()Ljava/lang/String;
at io.grpc.NameResolverRegistry.refreshProviders(NameResolverRegistry.java:96) ~[grpc-api-1.42.2.jar:3.4.7]
at io.grpc.NameResolverRegistry.getDefaultRegistry(NameResolverRegistry.java:131) ~[grpc-api-1.42.2.jar:3.4.7]
at net.devh.boot.grpc.client.autoconfigure.GrpcClientAutoConfiguration.grpcNameResolverRegistration(GrpcClientAutoConfiguration.java:119) ~[grpc-client-spring-boot-autoconfigure-2.13.1.RELEASE.jar:2.13.1.RELEASE]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_321]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_321]
2022-11-10 17:22:36.290 ERROR 21408 --- [ restartedMain] o.s.b.d.LoggingFailureAnalysisReporter :
***************************
APPLICATION FAILED TO START
***************************
Action:
Correct the classpath of your application so that it contains compatible versions of the classes io.grpc.NameResolverRegistry and io.grpc.NameResolverProvider
Process finished with exit code 0
Description:
An attempt was made to call a method that does not exist. The attempt was made from the following location:
io.grpc.NameResolverRegistry.refreshProviders(NameResolverRegistry.java:96)
The following method did not exist:
io.grpc.NameResolverProvider.getScheme()Ljava/lang/String;
The calling method's class, io.grpc.NameResolverRegistry, was loaded from the following location:
jar:file:/C:/Users/Bashlaw/.gradle/caches/modules-2/files-2.1/io.grpc/grpc-api/1.42.2/dd67a2446043d3903f7e0532d17b8bd2f1bfe67a/grpc-api-1.42.2.jar!/io/grpc/NameResolverRegistry.class
The called method's class, io.grpc.NameResolverProvider, is available from the following locations:
jar:file:/C:/Users/Bashlaw/.gradle/caches/modules-2/files-2.1/com.github.AfricasTalkingLtd.africastalking-java/core/3.4.8/dba39ba2047b38c53c9e645d535a1db6c1164219/core-3.4.8.jar!/io/grpc/NameResolverProvider.class
jar:file:/C:/Users/Bashlaw/.gradle/caches/modules-2/files-2.1/io.grpc/grpc-api/1.42.2/dd67a2446043d3903f7e0532d17b8bd2f1bfe67a/grpc-api-1.42.2.jar!/io/grpc/NameResolverProvider.class
The called method's class hierarchy was loaded from the following locations:
io.grpc.NameResolverProvider: file:/C:/Users/Bashlaw/.gradle/caches/modules-2/files-2.1/com.github.AfricasTalkingLtd.africastalking-java/core/3.4.8/dba39ba2047b38c53c9e645d535a1db6c1164219/core-3.4.8.jar
io.grpc.NameResolver.Factory: file:/C:/Users/Bashlaw/.gradle/caches/modules-2/files-2.1/com.github.AfricasTalkingLtd.africastalking-java/core/3.4.8/dba39ba2047b38c53c9e645d535a1db6c1164219/core-3.4.8.jar
I tried to exclude the path on gradle but am still getting class path conflict error.
I will appreciate your help here:
The com.github.AfricasTalkingLtd.africastalking-java:core dependency is built as an application. That means that it contains all of its dependencies - it's a so-called uber-JAR.
Since the core dependency contains only one class, which provides only a main method, try replacing it with the separate modules. These are the ones included by core:
compile project(":airtime")
compile project(":payment")
compile project(":sms")
compile project(":ussd")
compile project(":voice")
compile project(":token")
compile project(":server")
compile project(":application")
Includes the ones you need, and your problem should be resolved - gRPC is included from its own dependency, not from this core dependency. Your application can also become smaller if you omit modules you don't need.
Related
I have the following dependencies:
[INFO] +- org.apache.activemq:artemis-core-client:jar:2.19.1:compile
...
[INFO] | \- io.netty:netty-common:jar:4.1.79.Final:compile
[INFO] +- org.apache.activemq:artemis-jms-client-all:jar:2.19.1:compile
After a spring-boot-starter-parent and spring-cloud uplift the following message appeared after the application start:
***************************
APPLICATION FAILED TO START
***************************
Description:
An attempt was made to call a method that does not exist. The attempt was made from the following location:
io.netty.buffer.AbstractReferenceCountedByteBuf.<init>(AbstractReferenceCountedByteBuf.java:50)
The following method did not exist:
io.netty.util.internal.ReferenceCountUpdater.setInitialValue(Lio/netty/util/ReferenceCounted;)V
The calling method's class, io.netty.buffer.AbstractReferenceCountedByteBuf, is available from the following locations:
jar:file:/app/lib/netty-buffer-4.1.79.Final.jar!/io/netty/buffer/AbstractReferenceCountedByteBuf.class
jar:file:/app/lib/artemis-jms-client-all-2.19.1.jar!/io/netty/buffer/AbstractReferenceCountedByteBuf.class
The calling method's class was loaded from the following location:
file:/app/lib/netty-buffer-4.1.79.Final.jar
The called method's class, io.netty.util.internal.ReferenceCountUpdater, is available from the following locations:
jar:file:/app/lib/artemis-jms-client-all-2.19.1.jar!/io/netty/util/internal/ReferenceCountUpdater.class
jar:file:/app/lib/netty-common-4.1.79.Final.jar!/io/netty/util/internal/ReferenceCountUpdater.class
The called method's class hierarchy was loaded from the following locations:
io.netty.util.internal.ReferenceCountUpdater: file:/app/lib/artemis-jms-client-all-2.19.1.jar
Action:
Correct the classpath of your application so that it contains compatible versions of the classes io.netty.buffer.AbstractReferenceCountedByteBuf and io.netty.util.internal.ReferenceCountUpdater
Since both the artemis-jms-client-all-2.19.1.jar and netty-common-4.1.79.Final.jar is in use and only the netty-common-4.1.79.Final.jar has the necessary method (setInitialValue()) I cannot just remove one of the JARs.
Is there a way to define the order of these?
Is this order issue could have come from the uplift? It was more lazy previously?
You have conflicting versions of the same dependency. When you keep your dependencies as they are, this will be only the first of a longer series of troubles to occur.
Try to use an updated version of artemis-jms-client that dependes on the version of netty-common you need.
Decide to either skip the netty-common dependency (since it is contained in the artemis-jms-client) or don't use the ...-all-... dependency of artemis-jms-client but rather us a version that uses transitive dependencies and loads the others via maven (or gradle or whatever build system you use).
Reordering classpath to resolve that kind of troubles is really a very delicate procedure I would never recommend to perform on third-party-dependencies.
Getting error:
Diag message: User class threw exception: java.lang.IllegalArgumentException: An SPI class of type org.apache.lucene.codecs.DocValuesFormat with name 'Memory' does not exist.
You need to add the corresponding JAR file supporting this SPI to your classpath.
The current classpath supports the following names: [Lucene54]
at org.apache.lucene.util.NamedSPILoader.lookup(NamedSPILoader.java:116)
at org.apache.lucene.codecs.DocValuesFormat.forName(DocValuesFormat.java:108)
I have tried running the jar with various newer versions of lucene-core (along with backward-compatibility jar) but no success. Currently, we are using 6.5.0 version.
The Lucene-index we are trying to read contains files like - _4o08_Memory_0.mdvd & _4o08_Memory_0.mdvm which are the real issue.
Solution - add maven dependency https://mvnrepository.com/artifact/org.apache.lucene/lucene-codecs/6.5.0 & make sure its a runtime dependency & not limited to test scope.
Hello I'm trying to upgrade my spring boot version but getting following error,
I have tried enabling circulating reference from configuration but had no success the error is
escription:
An attempt was made to call a method that does not exist. The attempt was made from the following location:
org.springframework.boot.sql.init.dependency.DatabaseInitializationDependencyConfigurer.registerBeanDefinitions(DatabaseInitializationDependencyConfigurer.java:76)
The following method did not exist:
'org.springframework.beans.factory.support.BeanDefinitionBuilder org.springframework.beans.factory.support.BeanDefinitionBuilder.rootBeanDefinition(java.lang.Class, java.util.function.Supplier)'
The method's class, org.springframework.beans.factory.support.BeanDefinitionBuilder, is available from the following locations:
jar:file:/Users/.m2/repository/org/springframework/spring-beans/5.3.5/spring-beans-5.3.5.jar!/org/springframework/beans/factory/support/BeanDefinitionBuilder.class
jar:file:/Users/.m2/repository/org/springframework/spring-beans/5.3.13/spring-beans-5.3.13.jar!/org/springframework/beans/factory/support/BeanDefinitionBuilder.class
The class hierarchy was loaded from the following locations:
org.springframework.beans.factory.support.BeanDefinitionBuilder: file:/Users/.m2/repository/org/springframework/spring-beans/5.3.5/spring-beans-5.3.5.jar
Action:
Correct the classpath of your application so that it contains a single, compatible version of org.springframework.beans.factory.support.BeanDefinitionBuilder
I just deleted my whole "m2" folder and built it from scratch, it seems maven looks at all possible versions from the repository and circulates through it. (In production mode I use Virtualization so there should be no problem)
I'm using v3.7.0 of the plugin as required and JDK 9.0.1. I have added two requires statements, each referring to a jar in the class path (automatic module). The module-info.java compiles successfully in Eclipse after I moved the jars to Modulepath. However, Maven gives me a compiler error saying one of them is missing (strangely, not the first one which is just one line before). I tried to check the automatic module name but I get an error from the commands just for this jar. What does this error mean and how do I fix it so that I can discover the proper module name?
I replaced my username in the output below. The jar in question does use a ServiceLoader but is not compiled with Java 9.
computerName:Commander-java username$ jar --file=/Users/username/.m2/repository/com/username/rcf/1.0/rcf-1.0.jar --describe-module
Unable to derive module descriptor for: /Users/username/.m2/repository/com/username/rcf/1.0/rcf-1.0.jar
Provider class com.username.rcf.server.TestCmdChain not in module
computerName:Commander-java username$ java -p /Users/username/.m2/repository/com/username/rcf/1.0/rcf-1.0.jar --list-modules
Error occurred during initialization of boot layer
java.lang.module.FindException: Unable to derive module descriptor for /Users/username/.m2/repository/com/username/rcf/1.0/rcf-1.0.jar
Caused by: java.lang.module.InvalidModuleDescriptorException: Provider class com.username.rcf.server.TestCmdChain not in module
The answer in How to deal with java keywords in auto generated module names in Java 9? has a different error related to using a Java identifier in the module name. The automatic jar name for my module should just be rcf since the jar name is rcf-1.0.jar. The error I'm getting is different also.
While deriving module description the contents of any
META-INF/services configuration files are mapped to provides
declarations.
The packages scanned for the services are the ones containing class files.
Also, the package name for individual classes is derived from their fully qualified name. From the shared logs com.username.rcf.server shall be the expected package name for the service to be provided and this shall turn into
provides x.y.z.TestCmdChainInterface with com.username.rcf.server.TestCmdChain
Seems like there is no such package com.username.rcf.server existing in your module.
On a Weblogic portal I am getting error.
Details - not available! You either misspelled the module name or forgot to load it. If registering a module ensure that you specify the dependencies as the second argument.
How to overcome this, as my url is showing some different content ?
It is because you failed to instantiate a module or inject a dependency that you are using.