I have successfully created a shadow-jar with few verticles using Kotlin coroutines extension and able to run them via vertx run command line while specifying the path to my jar except a verticle that on its start-up creates a telnet shell with exception:
java.lang.NoClassDefFoundError: io.vertx.ext.shell.term.TelnetTermOptions
at io.vertx.kotlin.ext.shell.term.TelnetTermOptionsKt.telnetTermOptionsOf(TelnetTermOptions.kt:119)
at io.vertx.kotlin.ext.shell.term.TelnetTermOptionsKt.telnetTermOptionsOf$default(TelnetTermOptions.kt:119)
at **********************.ContactsReceiver.start(ContactsReceiver.kt:20)
at io.vertx.kotlin.coroutines.CoroutineVerticle$start$1.invokeSuspend(CoroutineVerticle.kt:53)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run(Dispatched.kt:238)
at io.vertx.kotlin.coroutines.VertxCoroutineExecutor.execute(VertxCoroutine.kt:214)
at kotlinx.coroutines.ExecutorCoroutineDispatcherBase.dispatch(Executors.kt:64)
at kotlinx.coroutines.DispatchedKt.resumeCancellable(Dispatched.kt:413)
at kotlinx.coroutines.intrinsics.CancellableKt.startCoroutineCancellable(Cancellable.kt:25)
at kotlinx.coroutines.CoroutineStart.invoke(CoroutineStart.kt:109)
at kotlinx.coroutines.AbstractCoroutine.start(AbstractCoroutine.kt:154)
at kotlinx.coroutines.BuildersKt__Builders_commonKt.launch(Builders.common.kt:54)
at kotlinx.coroutines.BuildersKt.launch(Unknown Source)
at kotlinx.coroutines.BuildersKt__Builders_commonKt.launch$default(Builders.common.kt:47)
at kotlinx.coroutines.BuildersKt.launch$default(Unknown Source)
at io.vertx.kotlin.coroutines.CoroutineVerticle.start(CoroutineVerticle.kt:51)
at io.vertx.core.Verticle.start(Verticle.java:66)
at io.vertx.core.impl.DeploymentManager.lambda$doDeploy$8(DeploymentManager.java:556)
at io.vertx.core.impl.DeploymentManager$$Lambda$126.0000000063922220.handle(Unknown Source)
at io.vertx.core.impl.ContextImpl.executeTask(ContextImpl.java:369)
at io.vertx.core.impl.EventLoopContext.lambda$executeAsync$0(EventLoopContext.java:38)
at io.vertx.core.impl.EventLoopContext$$Lambda$127.0000000060DA8B00.run(Unknown Source)
at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163)
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:510)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:518)
at io.netty.util.concurrent.SingleThreadEventExecutor$6.run(SingleThreadEventExecutor.java:1044)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:831)
My project is built using Gradle (Kotlin DSL)
These are my vert.x dependencies:
io.vertx:vertx-core
io.vertx:vertx-lang-kotlin
io.vertx:vertx-lang-kotlin-coroutines
io.vertx:vertx-shell
io.vertx:vertx-auth-shiro
io.vertx:vertx-tcp-eventbus-bridge
And my shadow jar task configered like so:
tasks.withType<com.github.jengelman.gradle.plugins.shadow.tasks.ShadowJar> {
classifier = "fat"
isPreserveFileTimestamps = false
isReproducibleFileOrder = true
minimize()
manifest {
attributes["Main-Verticle"] = vertx.mainVerticle
}
mergeServiceFiles {
include("META-INF/services/io.vertx.core.spi.VerticleFactory")
}
}
Seems like minimize() is not the issue but what is important that if I deploy that verticle programatically from the main function evrything works fine and I got the telnet shell.
Perhaps I missing something in my manifest configuration on the shadow jar task?
I had a remotely similar issues with the HoconProcessor (here), but in the mean time more relevantly, also with the class GraphiQLHandlerOptions, of which I imported a deprecated version (look), causing the class to be included in the jar under the same name, but its use expectedly throwing java.lang.NoClassDefFoundError.
Since TelnetTermOptions is such an options class too, maybe it suffered from a similar deprecation recently. Hope this helps/inspires.
Related
Hi I'm new to kotlin and trying to get a Jetpack compose desktop calculator application up and running. I wrote some JUnit tests and attempted to run them, but I am met with an internal error instead. This is the IntelliJ output:
Kotlin: [Internal Error] java.lang.IllegalStateException: The provided plugin androidx.compose.compiler.plugins.kotlin.ComposeComponentRegistrar is not compatible with this version of compiler
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment$Companion.registerExtensionsFromPlugins$cli(KotlinCoreEnvironment.kt:618)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment$ProjectEnvironment.registerExtensionsFromPlugins(KotlinCoreEnvironment.kt:130)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment.<init>(KotlinCoreEnvironment.kt:170)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment.<init>(KotlinCoreEnvironment.kt)
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment$Companion.createForProduction(KotlinCoreEnvironment.kt:431)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.createCoreEnvironment(K2JVMCompiler.kt:226)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:152)
at org.jetbrains.kotlin.cli.jvm.K2JVMCompiler.doExecute(K2JVMCompiler.kt:52)
at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:92)
at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:44)
at org.jetbrains.kotlin.cli.common.CLITool.exec(CLITool.kt:98)
at org.jetbrains.kotlin.daemon.CompileServiceImpl.compile(CompileServiceImpl.kt:1500)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:691)
at java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:587)
at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:828)
at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:705)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:391)
at java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:704)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
at java.base/java.lang.Thread.run(Thread.java:831)
Caused by: java.lang.AbstractMethodError: Receiver class androidx.compose.compiler.plugins.kotlin.ComposeComponentRegistrar does not define or inherit an implementation of the resolved method 'abstract void registerProjectComponents(com.intellij.mock.MockProject, org.jetbrains.kotlin.config.CompilerConfiguration)' of interface org.jetbrains.kotlin.compiler.plugin.ComponentRegistrar.
at org.jetbrains.kotlin.cli.jvm.compiler.KotlinCoreEnvironment$Companion.registerExtensionsFromPlugins$cli(KotlinCoreEnvironment.kt:610)
... 28 more
I've spent a few hours trying to get the right dependencies in my build.gradle.kts file. Right now I have:
dependencies {
kotlinCompilerClasspath("com.android.tools.build:gradle:7.0.0-alpha02")
implementation(compose.desktop.currentOs)
implementation("org.junit.jupiter:junit-jupiter:5.8.1")
kotlinCompilerClasspath("org.jetbrains.kotlin:kotlin-gradle-plugin:1.5.21")
}
Another post suggested using Compose version 1.0.0-beta08, which I tried and got:
Plugin [id: 'org.jetbrains.compose', version: '1.0.0-beta08'] was not found in any of the following sources:
with no further information. 1.0.0-alpha3 has been the only version to successfully build. If you have thoughts on this, let me know, else I can ask it in a new question.
I'm running Kotlin 1.5.21, Jetbrains Compose version 1.0.0-alpha3 and I have the maven repository set to "https://maven.pkg.jetbrains.space/public/p/compose/dev" as is recommended in several forums. If you have any resources I may check out, or know of a fix, I feel as though I've exhausted my options -- please leave me a comment, thanks.
I have a simple build script (shorted for clarity) which uses Guava as a dependency
group 'test'
version '0.1.0'
apply plugin: 'java'
apply plugin: 'application'
sourceCompatibility = 1.8
targetCompatibility = 1.8
mainClassName = 'Test'
repositories {mavenCentral()}
task wrapper(type: Wrapper) {gradleVersion = '3.5'}
dependencies {compile 'com.google.guava:guava:21.0'}
When running this code:
public class Test {
public static void main(String[] args) {
LoadingCache<Long, String> applicantCache = CacheBuilder.newBuilder()
.maximumSize(30000)
.expireAfterAccess(31, TimeUnit.DAYS)
.build(new CacheLoader<Long, String>() {
#Override
public String load(Long key) {
return "";
}
});
}
}
I get this error:
java.lang.NoClassDefFoundError: com/google/common/cache/CacheLoader
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
at java.lang.Class.privateGetMethodRecursive(Class.java:3048)
at java.lang.Class.getMethod0(Class.java:3018)
at java.lang.Class.getMethod(Class.java:1784)
at sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:544)
at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526)
Caused by: java.lang.ClassNotFoundException: com.google.common.cache.CacheLoader
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 7 more
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main"
When downgrading the Gradle Wrapper version to 3.3 the problem is fixed but, I need version 3.5 for something else that is not feasible in version 3.3. As far as I can understand there is some dependency conflict between this version of Gradle and Guava but according to this post - it is not possible.
I know the jar is in place + using gradle dependencyInsight --dependency com.google.guava shows that the dependency exists:
:dependencyInsight
com.google.guava:guava:21.0
\--- compile
Thanks for any help
EDIT:
After testing on other computers it seems the problem only occurs when I update the wrapper task, execute it and then refresh the gradle project by clicking on the Refresh all Gradle projects button (see attached image). When running the executing distribution script every thing works fine - so it only happens in Intellij. I'm guessing I'm missing something in how Gradle Wrapper works or when to execute it...
EDIT
Tested on Gradle version 3.4 and the problem occurres.
if anyone else encounters similar issues the answer is here.
A bug in my Intellij version (2016.2.5) caused compile scoped dependencies to transform into provided scoped dependencies by Intellij. This, in turn, makes dependencies to appear only in Intellij's compile classpath but not in it's runtime classpath. That's why when running the ./gradlew run command the issue could not be reproduced as there was no issue on Gradle's part.
Upgrading the Intellij version (2017.1) solved the issue.
Recently I created a new project using IntelliJ IDEA and Gradle for dependency management. After resolving all the dependencies needed by the project and running it I get the following error:
java.lang.NoClassDefFoundError: org/springframework/boot/SpringApplication
at com.some.fancy.name.Application.main(Application.java:13)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
Caused by: java.lang.ClassNotFoundException: org.springframework.boot.SpringApplication
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 6 more
The problem occurs only with the classes from the resolved dependencies (I tried it also with a simple main program using Cache from Guava). The class causing the error is the following:
#SpringBootApplication
public class Application {
public static void main(String... args) {
SpringApplication.run(Application.class, args);
}
}
All the fields are shown correct colour (annotations are yellow, nothing is red), IntelliJ has all the resolved dependencies in the External Libraries directory. I'm using the green "run" arrow to start the project.
When using gradle from the command line, creating a fat jar then everything works fine. I already tried "Invalidate Caches/Restart", pulled the project several times from the repository, cleared the gradle caches, removed all the dependencies by hand, tried to run it using the Community Edition, the Ultimate Edition, running older projects which already worked some time ago (and don't work now).
Could it be somehow related to updating IntelliJ IDEA to 2016.3.4, build 163.12024.16?
It's a known issue in IntelliJ IDEA that is specific to Gradle 3.4 and later versions:
IDEA-167412 Gradle 3.4-rc-1 changes compile dependencies to provided
original bug report in the Gradle project with more details
comment from the responsible developer regarding "Create Module per source set" option and how Gradle integration works in IntelliJ IDEA
It's already fixed in IntelliJ IDEA 2017.1 and 2016.3.6.
You can also use Gradle 3.3 or older as a workaround if you can't or don't want to update IntelliJ IDEA.
I had the same problem, getting the error below from a spring boot application which was working fine a day before. I am using IntelliJ 2020.3, Gradle 6.5.1. I suspect my repository might have been corrupted.
Caused by: java.lang.ClassNotFoundException: org.springframework.boot.SpringApplication
After lot of tries from my IntelliJ I tried bootRun (in the gradle tree you can find this under Tasks > application > bootRun) and it worked.
Setting gradle version to 3.3 corrected this issue.
Recently I created a new project using IntelliJ IDEA and Gradle for dependency management. After resolving all the dependencies needed by the project and running it I get the following error:
java.lang.NoClassDefFoundError: org/springframework/boot/SpringApplication
at com.some.fancy.name.Application.main(Application.java:13)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
Caused by: java.lang.ClassNotFoundException: org.springframework.boot.SpringApplication
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 6 more
The problem occurs only with the classes from the resolved dependencies (I tried it also with a simple main program using Cache from Guava). The class causing the error is the following:
#SpringBootApplication
public class Application {
public static void main(String... args) {
SpringApplication.run(Application.class, args);
}
}
All the fields are shown correct colour (annotations are yellow, nothing is red), IntelliJ has all the resolved dependencies in the External Libraries directory. I'm using the green "run" arrow to start the project.
When using gradle from the command line, creating a fat jar then everything works fine. I already tried "Invalidate Caches/Restart", pulled the project several times from the repository, cleared the gradle caches, removed all the dependencies by hand, tried to run it using the Community Edition, the Ultimate Edition, running older projects which already worked some time ago (and don't work now).
Could it be somehow related to updating IntelliJ IDEA to 2016.3.4, build 163.12024.16?
It's a known issue in IntelliJ IDEA that is specific to Gradle 3.4 and later versions:
IDEA-167412 Gradle 3.4-rc-1 changes compile dependencies to provided
original bug report in the Gradle project with more details
comment from the responsible developer regarding "Create Module per source set" option and how Gradle integration works in IntelliJ IDEA
It's already fixed in IntelliJ IDEA 2017.1 and 2016.3.6.
You can also use Gradle 3.3 or older as a workaround if you can't or don't want to update IntelliJ IDEA.
I had the same problem, getting the error below from a spring boot application which was working fine a day before. I am using IntelliJ 2020.3, Gradle 6.5.1. I suspect my repository might have been corrupted.
Caused by: java.lang.ClassNotFoundException: org.springframework.boot.SpringApplication
After lot of tries from my IntelliJ I tried bootRun (in the gradle tree you can find this under Tasks > application > bootRun) and it worked.
Setting gradle version to 3.3 corrected this issue.
I am using the Apache HttpClient libs to handle my communication with an API. All of my code compiles and runs without error when I unit test the exploded code. However, when I JAR my source and test the code in a isolated integration test I get this error:
Exception in thread "main" java.lang.NoClassDefFoundError: org/jboss/logmanager/Logger$AttachmentKey
at org.slf4j.impl.Slf4jLoggerFactory.<clinit>(Slf4jLoggerFactory.java:31)
at org.slf4j.impl.StaticLoggerBinder.getLoggerFactory(StaticLoggerBinder.java:33)
at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:240)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:208)
at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:155)
at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:131)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:645)
at org.apache.http.impl.client.AbstractHttpClient.<init>(AbstractHttpClient.java:159)
at org.apache.http.impl.client.DefaultHttpClient.<init>(DefaultHttpClient.java:178)
at opart.api.client.trasnsport.Transport.get(Transport.java:81)
at opart.api.client.dao.objects.ObjectsDao.getInterestingObjects(ObjectsDao.java:70)
at opart.api.client.OpartApiClient.getInterestingObjects(OpartApiClient.java:79)
at ApiTest.interesting(ApiTest.java:32)
at ApiTest.main(ApiTest.java:21)
Caused by: java.lang.ClassNotFoundException: org.jboss.logmanager.Logger$AttachmentKey
at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
at java.lang.ClassLoader.loadClass(ClassLoader.java:321)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
at java.lang.ClassLoader.loadClass(ClassLoader.java:266)
... 14 more
When I try to instantiate a DefaultHttpClient object thusly:
DefaultHttpClient defaultHttpClient = new DefaultHttpClient();
The libs I have included in my JAR are:
guava-r09.jar
commons-logging-1.1.1.jar
httpclient-4.1.2.jar
httpcore-4.1.2.jar
gson-1.7.1.jar
Any ideas as to why it is trying to reference JBoss?
The solution I found was to use the zipfileset ant target which safely explodes the contents of the JARchives inside the root of the uber JAR.