PiT 23.2: CDI and Quarkus starters need an HTTP hit for start compiling the frontend #14479

manolo · 2022-09-06T12:31:35Z

Description of the bug

Quarkus and CDI starters got stuck at some point before compiling the frontend.
By sending an HTTP request, the process continues compiling the frontend.
It din't happen with webpack or in other starters like spring flow

Expected behavior

Frontend compilation in dev mode does not need any http trigger for compiling the frontend in dev mode

Minimal reproducible example

base-starter-flow-quarkus

First double check that you dont have any browser with an open tab pointing to http://localhost:8080
second download and run the application

git clone https://github.com/vaadin/base-starter-flow-quarkus.git
cd base-starter-flow-quarkus
mvn

check that It gets stuck (for ever) at this point:

2022-09-06 14:57:15,043 INFO  [com.vaa.flo.ser.fro.TaskUpdatePackages] (ForkJoinPool.commonPool-worker-11) using '/usr/local/bin/npm --no-update-notifier --no-audit --scripts-prepend-node-path=true --ignore-scripts install' for frontend package installation
2022-09-06 14:57:21,391 INFO  [com.vaa.flo.ser.fro.TaskUpdatePackages] (ForkJoinPool.commonPool-worker-11) Frontend dependencies resolved successfully.
2022-09-06 14:57:22,323 INFO  [com.vaa.flo.ser.fro.TaskCopyFrontendFiles] (ForkJoinPool.commonPool-worker-11) Copying frontend resources from jar files ...
2022-09-06 14:57:22,353 INFO  [com.vaa.flo.ser.fro.TaskCopyFrontendFiles] (ForkJoinPool.commonPool-worker-11) Visited 20 resources. Took 29 ms.

finally visit http://localhost:8080, and it will continue frontend compilation

skeleton-starter-flow-cdi

Close all tabs in your browser
download and run the starter

git clone https://github.com/vaadin/skeleton-starter-flow-cdi.git 
cd skeleton-starter-flow-cdi
mvn

It is stuck for ever

15:00:53,498 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 8) WFLYUT0021: Registered web context: '/' for server 'default-server'
15:00:53,528 INFO  [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0010: Deployed "project-base-flow-cdi-1.0-SNAPSHOT.war" (runtime-name : "project-base-flow-cdi-1.0-SNAPSHOT.war")
15:00:55,690 INFO  [com.vaadin.flow.server.frontend.TaskUpdatePackages] (ForkJoinPool.commonPool-worker-1) using '/usr/local/bin/npm --no-update-notifier --no-audit --scripts-prepend-node-path=true --ignore-scripts install' for frontend package installation
15:01:03,318 INFO  [com.vaadin.flow.server.frontend.TaskUpdatePackages] (ForkJoinPool.commonPool-worker-1) Frontend dependencies resolved successfully.
15:01:04,314 INFO  [com.vaadin.flow.server.frontend.TaskCopyFrontendFiles] (ForkJoinPool.commonPool-worker-1) Copying frontend resources from jar files ...
15:01:04,360 INFO  [com.vaadin.flow.server.frontend.TaskCopyFrontendFiles] (ForkJoinPool.commonPool-worker-1) Visited 23 resources. Took 46 ms.

visit http://localhost:8080 and it will start frontend compilation

Versions

Vaadin / Flow version: 23.2

The text was updated successfully, but these errors were encountered:

Legioth · 2022-09-06T12:37:27Z

Spontaneously, this sounds like load-on-startup is missing from somewhere?

mcollovati · 2022-09-12T09:43:29Z

When using Vite, the thread running node tasks, launched by DevModeInitializer, waits until VaadinServlet.getFrontendMapping() returns a not null value; Vite is started only when the command is completed.
Value for frontendMapping is set during Servlet.init, and, at least with Quarkus, the method seems to be invoked on the first http request

mcollovati · 2022-09-12T10:10:00Z

Yes, exactly. And we can easily change ServletDeployer on Flow, CdiServletDeployer for CDI and VaadinQuarkusProcessor to set it.
But we should also warn users and document that custom servlet must set loadOnStartup.
Not a big effort for the end user, but can be annoying

mcollovati · 2022-09-12T14:13:33Z

Also https://github.com/vaadin/skeleton-starter-flow seems to be affected by the same issue

When using Vite, DevModeInitializer blocks dev-server startup until a VaadinServlet is deployed because it needs to get the servlet path to use. If the container lazily loads servlets, Vite will not start until the first HTTP request for the Vaadin servlet is received. This change sets load-on-startup feature for automatically deployed Vaadin servlet, to ensure that the servlet and Vite are loaded on the startup of the Web application Part of #14479

When using Vite, DevModeInitializer blocks dev-server startup until a VaadinServlet is deployed because it needs to get the servlet path to use. If the container lazily loads servlets, Vite will not start until the first HTTP request for the Vaadin servlet is received. This change sets load-on-startup feature for automatically deployed Vaadin servlet, to ensure that the servlet and Vite are loaded on the startup of the Web application Part of vaadin/flow#14479

When using Vite, DevModeInitializer blocks dev-server startup until a VaadinServlet is deployed because it needs to get the servlet path to use. If the container lazily loads servlets, Vite will not start until the first HTTP request for the Vaadin servlet is received. This change sets load-on-startup feature for all Vaadin Servlet registered by the extension, to ensure that Vite is loaded at the startup of the Web application. A warning message is shown for custom Vaadin servlets that do not set loadOnStartup on WebServlet annotation. Part of vaadin/flow#14479

Artur- · 2022-09-13T07:36:40Z

Just as a note: If you use the browser launcher when in dev mode, then the value of load on startup does not matter as the browser will be opened and trigger the servlet deployment immediately when the server is up and running. This is how our Spring Boot support works

As of Flow 23.2, Vite dev-server needs VaadinServlet to be initialized before to start. In order to have Vite starting eagerly (before any HTTP request), VaadinServlet must be registered with load-on-startup attribute to a value greater than zero. For custom VaadinServlet this must be done explicitly by the developer. This change updates example code defining custom Vaadin Servlet by adding load-on-startup setting. Part of vaadin/flow#14479

…14501) When using Vite, DevModeInitializer blocks dev-server startup until a VaadinServlet is deployed because it needs to get the servlet path to use. If the container lazily loads servlets, Vite will not start until the first HTTP request for the Vaadin servlet is received. This change sets load-on-startup feature for automatically deployed Vaadin servlet, to ensure that the servlet and Vite are loaded on the startup of the Web application Part of #14479

…14501) (#14513) When using Vite, DevModeInitializer blocks dev-server startup until a VaadinServlet is deployed because it needs to get the servlet path to use. If the container lazily loads servlets, Vite will not start until the first HTTP request for the Vaadin servlet is received. This change sets load-on-startup feature for automatically deployed Vaadin servlet, to ensure that the servlet and Vite are loaded on the startup of the Web application Part of #14479 Co-authored-by: Marco Collovati <[email protected]>

…398) When using Vite, DevModeInitializer blocks dev-server startup until a VaadinServlet is deployed because it needs to get the servlet path to use. If the container lazily loads servlets, Vite will not start until the first HTTP request for the Vaadin servlet is received. This change sets load-on-startup feature for automatically deployed Vaadin servlet, to ensure that the servlet and Vite are loaded on the startup of the Web application Part of vaadin/flow#14479

…398) (#409) When using Vite, DevModeInitializer blocks dev-server startup until a VaadinServlet is deployed because it needs to get the servlet path to use. If the container lazily loads servlets, Vite will not start until the first HTTP request for the Vaadin servlet is received. This change sets load-on-startup feature for automatically deployed Vaadin servlet, to ensure that the servlet and Vite are loaded on the startup of the Web application Part of vaadin/flow#14479 Co-authored-by: Marco Collovati <[email protected]>

…398) (#410) When using Vite, DevModeInitializer blocks dev-server startup until a VaadinServlet is deployed because it needs to get the servlet path to use. If the container lazily loads servlets, Vite will not start until the first HTTP request for the Vaadin servlet is received. This change sets load-on-startup feature for automatically deployed Vaadin servlet, to ensure that the servlet and Vite are loaded on the startup of the Web application Part of vaadin/flow#14479 Co-authored-by: Marco Collovati <[email protected]>

…#84) * fix: set load-on-startup for automatically registered Vaadin servlet When using Vite, DevModeInitializer blocks dev-server startup until a VaadinServlet is deployed because it needs to get the servlet path to use. If the container lazily loads servlets, Vite will not start until the first HTTP request for the Vaadin servlet is received. This change sets load-on-startup feature for all Vaadin Servlet registered by the extension, to ensure that Vite is loaded at the startup of the Web application. A warning message is shown for custom Vaadin servlets that do not set loadOnStartup on WebServlet annotation. Part of vaadin/flow#14479 * Fixes from code review Co-authored-by: marcin <[email protected]> Co-authored-by: marcin <[email protected]>

…1712) * chore: add load-on-startup configuration for custom Vaadin servlet As of Flow 23.2, Vite dev-server needs VaadinServlet to be initialized before to start. In order to have Vite starting eagerly (before any HTTP request), VaadinServlet must be registered with load-on-startup attribute to a value greater than zero. For custom VaadinServlet this must be done explicitly by the developer. This change updates example code defining custom Vaadin Servlet by adding load-on-startup setting. Part of vaadin/flow#14479 * Update articles/configuration/properties.asciidoc Co-authored-by: Mikhail Shabarov <[email protected]>

vaadin-bot · 2022-09-20T11:49:36Z

This ticket/PR has been released with Vaadin 23.1.10.

vaadin-bot · 2022-09-26T12:22:46Z

This ticket/PR has been released with Vaadin 23.2.2.

vaadin-bot · 2022-10-03T09:37:50Z

This ticket/PR has been released with Vaadin 23.3.0.alpha1 and is also targeting the upcoming stable 23.3.0 version.

manolo mentioned this issue Sep 6, 2022

PiT 23.2 vaadin/platform#3086

Closed

15 tasks

manolo changed the title ~~PiT 23.2: CDI and Quarkus starters need an an HTTP hit for start compiling the frontend~~ PiT 23.2: CDI and Quarkus starters need an HTTP hit for start compiling the frontend Sep 6, 2022

mshabarov added bug Impact: High Severity: Major quarkus CDI labels Sep 6, 2022

mcollovati mentioned this issue Sep 12, 2022

fix: set load-on-startup for automatically registered Vaadin servlet #14501

Merged

9 tasks

mcollovati mentioned this issue Sep 12, 2022

fix: set load-on-startup for automatically registered Vaadin servlet vaadin/cdi#398

Merged

9 tasks

mshabarov assigned MarcinVaadin Sep 13, 2022

mcollovati mentioned this issue Sep 13, 2022

fix: set load-on-startup for automatically registered Vaadin servlets vaadin/quarkus#84

Merged

9 tasks

mcollovati mentioned this issue Sep 13, 2022

chore: add load-on-startup configuration for custom Vaadin servlet vaadin/docs#1712

Merged

mshabarov closed this as completed Sep 20, 2022

vaadin-bot added the Released with Vaadin 23.1.10 label Sep 20, 2022

vaadin-bot added the Released with Vaadin 23.2.2 label Sep 26, 2022

vaadin-bot added prerelease version for Vaadin 23.3.0 Released with Vaadin 23.3.0.alpha1 labels Oct 3, 2022

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

PiT 23.2: CDI and Quarkus starters need an HTTP hit for start compiling the frontend #14479

PiT 23.2: CDI and Quarkus starters need an HTTP hit for start compiling the frontend #14479

manolo commented Sep 6, 2022

Legioth commented Sep 6, 2022

mcollovati commented Sep 12, 2022

mcollovati commented Sep 12, 2022 •

edited

Loading

mcollovati commented Sep 12, 2022

Artur- commented Sep 13, 2022

vaadin-bot commented Sep 20, 2022

vaadin-bot commented Sep 26, 2022

vaadin-bot commented Oct 3, 2022

PiT 23.2: CDI and Quarkus starters need an HTTP hit for start compiling the frontend #14479

PiT 23.2: CDI and Quarkus starters need an HTTP hit for start compiling the frontend #14479

Comments

manolo commented Sep 6, 2022

Description of the bug

Expected behavior

Minimal reproducible example

base-starter-flow-quarkus

skeleton-starter-flow-cdi

Versions

Legioth commented Sep 6, 2022

mcollovati commented Sep 12, 2022

mcollovati commented Sep 12, 2022 • edited Loading

mcollovati commented Sep 12, 2022

Artur- commented Sep 13, 2022

vaadin-bot commented Sep 20, 2022

vaadin-bot commented Sep 26, 2022

vaadin-bot commented Oct 3, 2022

mcollovati commented Sep 12, 2022 •

edited

Loading