Closed Alazar2019 closed 6 months ago
Hi. The error message says this web application instance has been stopped already
. Is there any other error logged that caused the application to stop?
Hi. The error message says
this web application instance has been stopped already
. Is there any other error logged that caused the application to stop?
Yes, logged error above that: 2023-03-16T18:24:48.837+03:00 WARN 15836 --- [ Thread-10] o.a.c.loader.WebappClassLoaderBase : The web application [ROOT] appears to have started a thread named [Thread-15] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: java.base@17.0.6/sun.nio.ch.Net.connect0(Native Method)
From the error above it is unfortunately not clear why the application has attempted to stop the mentioned thread. It seems that the actual problem occurred before and caused the thread stop as a result.
Hilla 2 requires openapi.json
to be generated in the classpath to be used at runtime (in Hilla 1, this file was generated elsewhere since it was only used by the generator).
When a Hilla application is run for the first time, it doesn't find that file and displays an error:
ERROR 2840 --- [ restartedMain] dev.hilla.EndpointController : Resource '/dev/hilla/openapi.json' is not available
(This is shown as an error because later this file is expected, but we should address it anyway since at the first run it's normal.)
Then, that file gets generated, and this causes Spring Boot Dev Tools to trigger an immediate reload, which interrupts the bootstrap abruptly with that stacktrace.
The best solution would be to put openapi.json
elsewhere, outside of the classpath, and load it differently. Or tell Spring to not monitor that file, if possible.
The workaround for this is to add
spring.devtools.restart.additional-exclude=dev/hilla/openapi.json
to application.properties
Starting from Vaadin 24.4 alpha 3 this now affects all Vaadin applications and it is not reasonable to say that everybody should add a workaround to their projects
This ticket/PR has been released with Hilla 24.4.0.alpha14 and is also targeting the upcoming stable 24.4.0 version.
When using Hilla 2 with react:
1- OS - Windows 10 2 - VS code 3 - Node 18.15
when try to run with mvnw or mvn spring-boot:run,
it generates the below exception:
java.lang.IllegalStateException: Illegal access: this web application instance has been stopped already. Could not load [META-INF/frontend/lumo-includes.ts]. The following stack trace is thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access. at org.apache.catalina.loader.WebappClassLoaderBase.checkStateForResourceLoading(WebappClassLoaderBase.java:1457) ~[tomcat-embed-core-10.1.5.jar:10.1.5] at org.apache.catalina.loader.WebappClassLoaderBase.getResource(WebappClassLoaderBase.java:1047) ~[tomcat-embed-core-10.1.5.jar:10.1.5] at com.vaadin.flow.server.frontend.scanner.ClassFinder$DefaultClassFinder.getResource(ClassFinder.java:105) ~[flow-server-24.0.0.jar:24.0.0] at com.vaadin.flow.server.frontend.scanner.ClassFinder$CachedClassFinder.getResource(ClassFinder.java:159) ~[flow-server-24.0.0.jar:24.0.0] at com.vaadin.flow.server.frontend.TaskUpdateImports$UpdateMainImportsFile.getResource(TaskUpdateImports.java:181) ~[flow-server-24.0.0.jar:24.0.0] at com.vaadin.flow.server.frontend.AbstractUpdateImports.hasMetaInfResource(AbstractUpdateImports.java:573) ~[flow-server-24.0.0.jar:24.0.0] at com.vaadin.flow.server.frontend.AbstractUpdateImports.resolveResource(AbstractUpdateImports.java:264) ~[flow-server-24.0.0.jar:24.0.0] at com.vaadin.flow.server.frontend.AbstractUpdateImports.lambda$resolveModules$1(AbstractUpdateImports.java:192) ~[flow-server-24.0.0.jar:24.0.0] at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) ~[na:na] at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179) ~[na:na] at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625) ~[na:na] at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509) ~[na:na] at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) ~[na:na] at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921) ~[na:na] at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[na:na] at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:682) ~[na:na] at com.vaadin.flow.server.frontend.AbstractUpdateImports.resolveModules(AbstractUpdateImports.java:193) ~[flow-server-24.0.0.jar:24.0.0] at com.vaadin.flow.server.frontend.AbstractUpdateImports.collectModules(AbstractUpdateImports.java:289) ~[flow-server-24.0.0.jar:24.0.0] at com.vaadin.flow.server.frontend.AbstractUpdateImports.run(AbstractUpdateImports.java:102) ~[flow-server-24.0.0.jar:24.0.0] at com.vaadin.flow.server.frontend.TaskUpdateImports.execute(TaskUpdateImports.java:362) ~[flow-server-24.0.0.jar:24.0.0]
at com.vaadin.flow.server.frontend.NodeTasks.execute(NodeTasks.java:301) ~[flow-server-24.0.0.jar:24.0.0] at com.vaadin.base.devserver.startup.DevModeInitializer.runNodeTasks(DevModeInitializer.java:372) ~[vaadin-dev-server-24.0.0.jar:na] at com.vaadin.base.devserver.startup.DevModeInitializer.lambda$initDevModeHandler$0(DevModeInitializer.java:313) ~[vaadin-dev-server-24.0.0.jar:na] at java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1804) ~[na:na] at java.base/java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1796) ~[na:na] at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373) ~[na:na] at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182) ~[na:na] at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655) ~[na:na] at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622) ~[na:na] at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165) ~[na:na]