Introduction
This section covers the technical details of application deployment, user sessions, and the UI instance lifecycle in vaadin. These details are generally not needed to write a Vaadin application, but they help understand how it works, especially under what circumstances execution terminates.
Application Lifecycle
Deployment
Before using the Vaadin application, you must deploy it to a Java web server. The deployment process reads servlet classes in the application that are annotated with the @WebServlet annotation or in the web.xml deployment descriptor and registers servlets for specific URL paths. Then the class is loaded. Static blocks within a class are executed when loaded, but when deployed, the application typically does not execute any code yet.
Servlet class must extend VaadinServlet class. However, using the Servlet 3.1 specification, you don't need to define your own servlet class. At least one class with @Route annotation is required. A VaadinServlet instance is automatically registered, and Vaadin automatically registers the required servlets.
Must Read Static Blocks In Java.
Automatic Servlet Registration
On startup, the Vaadin application attempts to register the Vaadin application servlet associated with the path /*.
This servlet is required to serve the main application files.
Servlet not registered if VaadinServlet is already registered or if there is no class annotated with @Route
A servlet is also not registered if:
- there is already a servlet mapped to the same path, or
- the system property disables.automatic.servlet.registration is set to true.
Undeploy and Redeploy
Applications are undeployed when the server goes down, redeployment, and explicitly undeployed. Undeploying, the Vaadin application on the server side stops execution. All application classes are unloaded, and heap space allocated by the application is freed for garbage collection.
If a user session is open at this point, the user interface client-side state will not be changed. I'm getting an asynchronous error with the following server request:
Vaadin Servlet and Services
VaadinServlet takes all server requests associated with URLs defined in the deployment configuration and maps them to sessions. Sessions also map requests to specific UIs. When processing a
request, the Vaadin servlet handles all the normal tasks of a servlet within a VaadinService. It manages sessions, grants access to deployment configuration information, handles system messages, and performs various other tasks. The corresponding VaadinServletService handles all other servlet-specific tasks. This service acts as the main low-level customization layer for handling requests.
VaadinServiceInitListener should be used to add custom functionality related to the Vaadin service. This listener allows you to add RequestHandlers, IndexHtmlRequestListeners, DependencyFilters, etc.
User Session
A user session starts when a user opens the URL in a particular user interface and makes the first request to her Vaadin servlet. The VaadinServlet class handles all server requests belonging to a particular UI class. When a new client connects, a new user session is created, represented by an instance of VaadinSession. Sessions are tracked using cookies stored in your browser.
The VaadinSession in the UI can be obtained globally using getSession() or using VaadinSession.getCurrent(). It also provides access to his lower-level HttpSession session object via WrappedSession. You can also access the deployment configuration via VaadinSession.
The session ends when the last UI instance expires or is closed.
Read this guide to learn how to listen for session initialization and destruction events.
UI Loading
The Vaadin servlet generates a loading page when the browser first accesses the URL associated with the servlet of a particular UI class. The page loads the client-side engine (widget set), which loads her UI with another request to his Vaadin servlet.
A UI instance is created when the client-side engine makes its first request.
After the new UI is created, its init() method is called. The method receives the request as a VaadinRequest.
Customizing the Loader Page
The HTML content of the the loader page is generated as an HTML DOM object that can be customized by implementing an IndexHtmlRequestListener that modifies the DOM object. To do this, you need to extend VaadinServlet and add a SessionInitListener to your service object, as described in User Sessions. When the session is initialized, you can add bootstrap listeners to the session using addIndexHtmlRequestListener().
Widget set loading is handled on the loader side using functions defined in a separate BootstrapHandler.js script whose content is inlined into the page.
UI Expiration
A UI instance is purged if no communication is received after a certain time. If there are no other server requests, the client side sends a "keep alive" heartbeat request. The UI lives as long as it receives requests or heartbeats. It expires after three consecutive missed heartbeats.
Heartbeats occur every 5 minutes. This can be changed with the servlet's heartbeatInterval parameter. This parameter can be configured in application.properties (for Spring Boot projects) or via system properties.
When UI cleanup occurs, send a DetachEvent to all DetachListener objects added to the UI. When the UI disconnects from the session, disconnect() is called.
Explicitly closing the UI
You can explicitly close the UI using close(). This method marks the UI disconnecting from the session after handling the current request. So the method doesn't immediately invalidate his UI instance, and the response is sent normally.
Detaching the UI does not close the page or browser window the UI is running on. Subsequent server requests will fail. Usually, you need to close the window, reload it, or redirect to another URL. If the pages are regular browser windows or tabs, browsers usually don't allow them to be closed programmatically. However, redirection is possible. You can use JavaScript to redirect the window to another URL.
Closing UIs other than those associated with the current request does not disconnect them at the end of the current request. This happens after each of the following requests from the user interface. You can speed this up by increasing the UI heartbeat rate or using server push out of the box.
Session Expiration
Sessions are maintained by server requests caused by user interaction with the application and heartbeat monitoring mechanism of the UI. The session remains if all UI expires
Cleaned up by the server when the session timeout set by the web application expires. If the application has an active UI, its heartbeat will keep the session alive indefinitely. A session can be expired if the user is inactive for a certain amount of time. This is the original purpose of the session timeout setting.
If the servlet's deployment configuration parameter "closeIdleSessions" is set to true, the closing mechanism works as follows:
After the last non-heartbeat request, the session and all its user interfaces are closed after the timeout specified by the servlet's session-timeout parameter. After the session ends, the browser will show an asynchronous error on the next server request.
For information on setting configuration parameters, see Configuration Properties. You can use the SessionDestroyListener to handle session expiration server-side, as described in User Sessions.
Closing a Session
You can close a session by calling close() on the VaadinSession. This is typically used when logging out a user. This is because the session and all user interfaces belonging to the session must be closed. After calling the method, the session is immediately closed, and all related objects are no longer available.
Java:
@Route("")
public class MainLayout extended Div {
protected void onAttach(AttachEvent AttachEvent) {
UI UI = getUI().get();
Button button = new Button ("Logout", event -> {
// redirect this page immediately
ui.getPage()
executeJs("window.location.href='logout.html'");
// close session
ui.getSession().close();
});
add (button);
/ / Quickly determine if the other UI is closed
ui.setPollInterval(3000);
}
}
More work to do; when the UI closes the session, all other UIs connected to it hang. When the client-side engine detects that the UI and session no longer exist on the server-side, it displays the message "Session has expired" and, by default, reloads the UI when the message is clicked.
You can also check out What is Servlet here.
428+ registered 
