Describe the bug
While trying to use the remote:dev plugin for development in a container I faced a NullPointerException in the remote application after trying to connect with remote:dev.
First I start an image that starts my application in dev mode quarkus:dev. After it is up and running I try to connect using the specified properties in the documentation:
./mvnw compile quarkus:remote-dev -Dquarkus.live-reload.url=http://localhost:8080 -Dquarkus.live-reload.password=123
Expected behavior
Connect successfully to the container in development mode.
Actual behavior
Remote application exception:
2020-07-26 20:07:00,124 ERROR [io.qua.ver.htt.run.dev.RemoteSyncHandler] (vert.x-eventloop-thread-6) Connect failed: java.lang.NullPointerException
at io.quarkus.deployment.dev.IsolatedRemoteDevModeMain.createHashes(IsolatedRemoteDevModeMain.java:298)
at io.quarkus.deployment.dev.RuntimeUpdatesProcessor.syncState(RuntimeUpdatesProcessor.java:204)
at io.quarkus.vertx.http.runtime.devmode.RemoteSyncHandler$6.handle(RemoteSyncHandler.java:182)
at io.quarkus.vertx.http.runtime.devmode.RemoteSyncHandler$6.handle(RemoteSyncHandler.java:168)
at io.vertx.core.http.HttpServerRequest.lambda$bodyHandler$0(HttpServerRequest.java:216)
at io.vertx.core.http.impl.HttpServerRequestImpl.onEnd(HttpServerRequestImpl.java:521)
at io.vertx.core.http.impl.HttpServerRequestImpl.lambda$pendingQueue$1(HttpServerRequestImpl.java:115)
at io.vertx.core.streams.impl.InboundBuffer.handleEvent(InboundBuffer.java:237)
at io.vertx.core.streams.impl.InboundBuffer.drain(InboundBuffer.java:224)
at io.vertx.core.streams.impl.InboundBuffer.lambda$fetch$0(InboundBuffer.java:277)
at io.vertx.core.impl.ContextImpl.executeTask(ContextImpl.java:366)
at io.vertx.core.impl.EventLoopContext.lambda$executeAsync$0(EventLoopContext.java:38)
at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:164)
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:472)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:500)
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
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:834)
Client exception:
2020-07-27 11:48:11,261 ERROR [io.qua.ver.htt.dep.dev.HttpRemoteDevClient] (Remote dev client thread) Remote dev request failed: java.io.IOException: Server did not start a remote dev session
at io.quarkus.vertx.http.deployment.devmode.HttpRemoteDevClient.doConnect(HttpRemoteDevClient.java:65)
at io.quarkus.vertx.http.deployment.devmode.HttpRemoteDevClient.access$200(HttpRemoteDevClient.java:27)
at io.quarkus.vertx.http.deployment.devmode.HttpRemoteDevClient$Session.run(HttpRemoteDevClient.java:163)
at java.base/java.lang.Thread.run(Thread.java:834)
To Reproduce
Steps to reproduce the behavior:
Environment:
uname -a or ver: Darwin JDantas-Mac-01.local 18.7.0 Darwin Kernel Version 18.7.0: Mon Apr 27 20:09:39 PDT 2020; root:xnu-4903.278.35~1/RELEASE_X86_64 x86_64java -version: java version "11.0.7" 2020-04-14 LTSmvnw --version or gradlew --version): Maven 3.6.3_1Additional context
I'm still a beginner in the codebase. Looking at the source code of IsolatedRemoteDevModeMain class looks like some kind of race condition since the _appRoot_ is null when it calls _setupRuntimeCompilation_ and is only set later after get the _generateApplication_ result object.
augmentAction = new AugmentActionImpl(curatedApplication);
**runtimeUpdatesProcessor = setupRuntimeCompilation(context, appRoot);**
if (runtimeUpdatesProcessor != null) {
runtimeUpdatesProcessor.checkForFileChange();
runtimeUpdatesProcessor.checkForChangedClasses();
}
JarResult result = generateApplication();
if (result != null) {
**appRoot = result.getPath().getParent();
currentHashes = createHashes(appRoot);**
}
@stuartwdouglas is this maybe fixed by https://github.com/quarkusio/quarkus/pull/10977?
Forgot to mention that I also tested with the master build. This can be reproduced in the branch https://github.com/joao-dantas/remot-dev-test/tree/use-quarkus-master.
Adding this to the list of issues I track for 1.7.0.
I can take a look at this tomorrow if Stuart hasn't fixed it by then :)
Please let me know if I can be of any help
The this is combing the old approach with the new approach, which is why it is failing.
You don't run mvn quarkus:dev on the remote side, you run a 'mutable-jar' application with 'QUARKUS_LAUNCH_DEVMODE'