Configuration Properties
You can change the behavior of Vaadin applications by setting the configuration properties. Either set them through the system properties, or with the servlet initialization parameters. See the full list of properties for details.
See also the Spring-specific instructions for Spring-based applications.
System Properties
When using Java system properties to set Vaadin application parameters, the vaadin. prefix has to be specified before each parameter name. The following shows how to set the pnpm.enable system property when executing a Maven goal from the command-line:
mvn jetty:run -Dvaadin.pnpm.enable=trueYou can also configure system properties for Maven plugin executions. For instance, the following sets a Vaadin-specific system property when running the Jetty Maven plugin:
<plugin>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<configuration>
<systemProperties>
<systemProperty>
<name>vaadin.pushMode</name>
<value>disabled</value>
</systemProperty>
</systemProperties>
</configuration>
</plugin>Servlet Initialization Parameters
Another option for setting configuration properties is to use servlet initialization parameters. Use the Servlet 3.0 @WebServlet annotation. This requires you to configure your servlet — unless you want Vaadin Flow to do it — using default parameter values.
@WebServlet(urlPatterns = "/*", name = "myservlet", asyncSupported = true, loadOnStartup = 1,
initParams = { @WebInitParam(name = "pnpm.enable", value = "true") })
public class MyServlet extends VaadinServlet {
}Yet another approach is to use the web.xml file. Below is an example of one:
<?xml version="1.0" encoding="UTF-8"?>
<web-app
id="WebApp_ID" version="3.0"
xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd">
<servlet>
<servlet-name>myservlet</servlet-name>
<servlet-class>
com.vaadin.flow.server.VaadinServlet
</servlet-class>
<load-on-startup>1</load-on-startup>
<init-param>
<param-name>pnpm.enable</param-name>
<param-value>true</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>myservlet</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
</web-app>|
Note
|
System Properties Override Servlet Parameters
When a system property and a servlet parameter have the same name, the system property is used, while the servlet parameter is ignored.
|
Properties Defined
The following table contains the properties that are defined in the com.vaadin.server.DeploymentConfiguration, com.vaadin.flow.server.Constants and com.vaadin.flow.server.InitParameters classes. They’re listed in alphabetical order. If you use Spring Boot, you should add the vaadin. prefix to them (e.g., change brotli to vaadin.brotli).
In the table Modes used are Development, Production, Runtime, Build and Bundle. Development and Production parameters are used in execution of the application in these modes. Runtime parameter changes functionality during execution and doesn’t depend on development/production modes. Build parameter changes build time functionality. Bundle parameter controls parts of frontend bundle creation.
Property Name | System Property | Description | Default Value | Mode |
|
| Application identifier that’s generated by default based on the project build settings. The property is used only for the moment by the daily active users license model. It can be configured by developers to differentiate end-users distribution between the same applications running in a cluster — ones that have the same group and artifact IDs. |
| Runtime |
|
| Determines whether pre-compressed Brotli files should be used if accepted by the browser. Brotli files are created during a production build. The property is used only in production mode. Set to |
| Runtime |
|
| Closes the Vaadin session if no UI is active. A UI is considered active if it’s open on the client-side and has any activity — besides heartbeat requests. By default, heartbeat requests keep the Vaadin session open even when there isn’t any user interaction. Set to |
| Runtime |
|
| Enable component tracking in development mode. |
| Development |
|
| Parameter for enabling development tools. Production mode always evaluates as |
| Development |
|
| Define additional frontend file extensions to copy from jar files to the application | `` | Development |
|
| Defines the hosts allowed to access Vaadin development tools. A comma-separated list of allowed hosts should be provided as the value. The |
| Development |
|
| Enables live reload. When using a server-side live reload tool, the browser is refreshed after code is rebuilt on the server. Set to |
| Development |
|
| Optimizes frontend resource bundles. All frontend resources in the classpath are included by default in the generated bundle in development mode. When set to |
| Build |
|
| Defines the time to wait for the frontend build tool to output either the success or error string for completion. | 60000 ms | Development |
|
| The name of the custom HTTP header that contains the client IP address that is checked to allow access to the development mode server. The HTTP header is supposed to contain a single address, and the HTTP request to have a single occurrence of the header. If not specified, remote address are read from the | Development | |
|
| Enables session serialization. When session serialization is enabled, |
| Development |
|
| Enables Vaadin to collect usage statistics that can guide further development. Statistics are collected based on features that are used in the application. No data is collected in production mode. Some usage statistics are collected through the web browser. See the client-side collector repository for instructions on how to opt out. This applies only to development mode. |
| Development |
|
| Define extra options for Vite execution. | Development | |
|
| Disables automatic servlet registration that’s required by Vaadin applications. You must register Vaadin servlets if set to |
| Runtime |
|
| Disables cross-site request forgery protection. The protection is enabled by default. You should keep it enabled — except for certain types of testing. |
| Runtime |
|
| Enables the client-side bootstrap page to include the initial JSON data fragment. |
| Runtime |
|
| If |
| Runtime |
|
| Enables development using the frontend development server instead of an application bundle. This applies only to development mode. Hilla always forces frontend |
| Development |
|
| A comma-separated list of module directories to watch for frontend file changes when detecting hot-deployable resources. Entries need to point to directories relative to the module that starts the Vaadin application, and can point to the module itself as well, in case it provides frontend files as resources. The value could be for example "./,./component-module-1,./component-module-2". Flow will watch for changes in both Do note that if this parameter is not defined, Vaadin wathes for changes under | `` | Development |
|
| Sets the heartbeat interval time. UIs that are open on the client-side send a regular heartbeat to the server indicating that they’re still active even without ongoing user interaction. When the server doesn’t receive a valid heartbeat from a given UI within a certain amount of time, it removes that UI from the session. The interval value is expressed in | 300 seconds (i.e., 5 minutes) | Runtime |
|
| Sets the fully-qualified name for the internationalization provider class. To translate strings for localization, the application should implement the |
| Runtime |
|
| Defines how long to wait before opening a new browser tab for the staring application. The time is counted always from the latest application start that would try to open a tab. | 30 min | Development |
|
| Sets the maximum time in | 5000 ms (i.e., 5 seconds) | Runtime |
|
| Define a menu access control implementation by giving a Fully Qualified Name to the control class. | Runtime | |
|
| Base URL to download Node.js during build. | Build | |
|
| Node.js version to get if one doesn’t exist. | See | Build |
|
| If true framework installed Node.js is updated to |
| Build |
|
| Excludes all Vaadin professional and core components from |
| Build |
|
| Define post-install scripts that need to be executed after npm install completes. | Build | |
|
| Enables |
| Build |
|
| Force use of system installed pnpm instead of a Flow managed one. |
| Build |
|
| Enables |
| Build |
|
| Build directory for application |
| Build |
|
| Sets the timeout in |
| Runtime |
|
| Enables server push. The permitted values are |
| Runtime |
|
| Specifies the servlet mapping used for bidirectional (i.e., "push") client-server communication. Some Java application servers require special context. For example, you can specify websockets with this. |
| Runtime |
|
| Whether to use React Router, add React core dependencies, React integration helpers and Vaadin’s provided React components (i.e., |
| Runtime |
|
| Includes basic timing information in responses that can be used for performance testing. |
| Runtime |
|
| Force use of Vaadin installed Node.js instead of a globally installed Node.js version. |
| Build |
|
| Enables synchronized ID checking. The synchronized ID is used to handle situations in which the client sends a message to a connector that has been removed from the server. It’s set to |
| Runtime |
|
| Sets the number of | 300 seconds (i.e., 5 minutes) | Runtime |
|
| When production mode is enabled, the Vaadin session lock check is done according to this setting. By default, the check is performed only if assertions are also enabled. This is to avoid the small performance impact of checking continuously the lock status. Alternative values are | assert | Runtime |
Vaadin Plugin Properties
The following table contains the properties that are used only by the Vaadin Maven and Gradle Plugin, and are not applicable for deployment configuration:
Plugin Configuration | System Property | Description | Default Value | Mode |
|
| Determines whether |
| Build |
|
| Forces Vaadin Flow to create a new production bundle, even if there is already a usable pre-compiled bundle. This is required usually when creating an optimized production bundle, and to load component sources to the browser on demand — such as when opening a route where these components are used. |
| Build |
| Directory containing the project’s frontend files. Can be given as relative or absolute. |
| Build | |
| Directory where any generated frontend files should be placed. By default, the directory is |
| Build | |
|
| Makes Flow skip node and npm/pnpm/bun version checks during bundle build and development server startup. Note that disabling frontend tools version checking can cause failing builds and other issues that are difficult to debug. | Development, Bundle | |
| Source folder used for component scanning during development mode. |
| Development | |
| Resources source folder used for component scanning during development mode. |
| Development | |
| Directory containing |
| Build | |
| Defines where the OpenAPI JSON file is generated if required for exported services. |
| Build | |
| Directory containing |
| Build | |
| Directory to place resources that are not served from the application. |
| Build | |
| Directory to generate served resources as |
| Build | |
|
| Prevents a frontend development bundle from being re-built, even if Vaadin Flow decides to use an existing compiled development bundle. This is mainly needed when the re-bundling checker in Vaadin Flow has problems leading to false re-bundling, and one needs a workaround while it’s being resolved. |
| Bundle |
|
| Clears the generated frontend files after building a project for production. It keeps the generated files if they existed before the build, or if this parameter is set to |
| Bundle |
27BF72FB-1E23-42B0-B540-A602F9AD4571