vaadin / hilla

Build better business applications, faster. No more juggling REST endpoints or deciphering GraphQL queries. Hilla seamlessly connects Spring Boot and React to accelerate application development.
https://hilla.dev
Apache License 2.0
898 stars 56 forks source link

Applications restart on startup #842

Closed Alazar2019 closed 6 months ago

Alazar2019 commented 1 year ago

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]

platosha commented 1 year 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?

Alazar2019 commented 1 year 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?

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)

platosha commented 1 year ago

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.

cromoteca commented 1 year ago

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.

Artur- commented 1 year ago

The workaround for this is to add

spring.devtools.restart.additional-exclude=dev/hilla/openapi.json

to application.properties

Artur- commented 7 months ago

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

vaadin-bot commented 6 months ago

This ticket/PR has been released with Hilla 24.4.0.alpha14 and is also targeting the upcoming stable 24.4.0 version.