`UI` being instantiated over and over again in default Vaadin 14.0.1 app

Flow
6

Syam Pillai:
Instead of localhost:8080, can you try accessing the application via 0.0.0.0:8080 ?

With @PWA enable, using http://[::1]
:8080/ gives me same results as with IPv4: When I use routing to goto http://[::1]
:8080/other I get UI re-initialized/re-instantiated.

BASIL - new UI instantiated. UI id # 0 2019-08-24T17:53:00.240552Z
BASIL - new MainView instantiated. 2019-08-24T17:53:00.255365Z
BASIL - new UI instantiated. UI id # 1 2019-08-24T17:53:12.330589Z
BASIL - new MainView instantiated. 2019-08-24T17:53:12.744920Z
BASIL - new UI instantiated. UI id # 2 2019-08-24T17:53:36.636009Z
BASIL - new MainView instantiated. 2019-08-24T17:53:37.029630Z
BASIL - new UI instantiated. UI id # 3 2019-08-24T17:53:40.583674Z
BASIL - new OtherView instantiated. 2019-08-24T17:53:40.587653Z
BASIL - new UI instantiated. UI id # 4 2019-08-24T17:53:57.398895Z
BASIL - new UI instantiated. UI id # 5 2019-08-24T17:53:57.680031Z
BASIL - new MainView instantiated. 2019-08-24T17:53:58.072961Z
BASIL - new UI instantiated. UI id # 6 2019-08-24T17:54:13.493352Z
BASIL - new MainView instantiated. 2019-08-24T17:54:13.877363Z
BASIL - new UI instantiated. UI id # 7 2019-08-24T17:54:14.952634Z
BASIL - new OtherView instantiated. 2019-08-24T17:54:14.953239Z
BASIL - new UI instantiated. UI id # 8 2019-08-24T17:54:15.948471Z
BASIL - new OtherView instantiated. 2019-08-24T17:54:16.361519Z
7

Please someone verify this troubling behavior.

Quite easy to do:

  • Make a fresh project.
  • Configure your Node.js & npm.
  • Add a few calls to System.out.println.
  • Add a UI init listener.
8

I had a similar problem in an earlier version when I accessed the application via localhost. The problem was that Vaadin uses cookies to maintain sessions and localhost access to Chrome browser under Linux (don’t know about its behaviour in other OSes) was not keeping cookies. However, it uses cookies if I access using 0.0.0.0 and that’s why I suggested that. Can you verify that your browser under macOS is supporting cookies with that sort of access?

9

Syam Pillai:
I had a similar problem in an earlier version when I accessed the application via localhost. The problem was that Vaadin uses cookies to maintain sessions and localhost access to Chrome browser under Linux (don’t know about its behaviour in other OSes) was not keeping cookies. However, it uses cookies if I access using 0.0.0.0 and that’s why I suggested that. Can you verify that your browser under macOS is supporting cookies with that sort of access?

I created a virtual machine using Parallels, to get a fresh clean environment. Running macOS Mojave 10.14.6 with OpenJDK 11.0.4, Community edition of IntelliJ 2019.2.1. Downloaded a new Vaadin 14.0.1 “Plain Java Servlet” project. Pasted the snippet for the POM to install Node.js/npm. Added the service listener, in which I install a UI init listener. Just as described in my original post on this page. In this round of testisg for this post, I left @PWA intact on MainView, and did not add @PreserveOnRefresh on either of my views.

I tried a different browser too, current Firefox 68.0.2 instead of Safari. I cleared all history from the browser. I pointed Firefox to http://0.0.0.0:8080/ as you suggested. I was confused by this, as I always thought of 0.0.0.0 being special, reserved for LAN routers and such. But I gave it a shot. Same problem where routing to my second view with typing /other in the URL triggers a UIInitEvent. Apparently the UI object is either re-initialized or replaced with a fresh instance — either way, that’s bad.

BASIL - `UIInitEvent` for UI id # 0. 2019-08-25T06:22:37.406351Z
BASIL - constructor `MainView`.
BASIL - `UIInitEvent` for UI id # 1. 2019-08-25T06:22:52.197492Z
BASIL - Constructor `OtherView`. 2019-08-25T06:22:52.199454Z

To further explore your theory about cookie management misbehaving within the browser because of loopback or localhost, I used Firefox on my real Mac hosting to first clear its history, and then to connect to the IP address of the virtual machine Mac running Jetty within IntelliJ, using URL http://192.168.0.186:8080/. Again, routing to /other generated another UIInitEvent.

BASIL - `UIInitEvent` for UI id # 0. 2019-08-25T06:28:05.788582Z
BASIL - constructor `MainView`.
BASIL - `UIInitEvent` for UI id # 1. 2019-08-25T06:30:06.134719Z
BASIL - Constructor `OtherView`. 2019-08-25T06:30:06.135540Z

So I think I ruled out cookie mismanagement as the problem. I used different browsers (Firefox vs Safari), and used 0.0.0.0 rather than localhost or 127.0.0.1, and used a regular IP address on my real Mac to reach my virtual Mac running Vaadin.

10

Yet another test: I added @PreserveOnRefresh to both my views.

@PreserveOnRefresh
@Route("")
@PWA(name = "Project Base for Vaadin", shortName = "Project Base")
public class MainView extends VerticalLayout {

and

@PreserveOnRefresh
@Route("other")
public class OtherView extends VerticalLayout {

Rather than run Jetty from within IntelliJ, I quit IntelliJ, copied the WAR file to a newly-installed Apache Tomcat 9.0.24 within my Parallels virtual machine. Same behavior where routing to /other from my Safari on the host (real) Mac triggers a UIInitEvent.

BASIL - `ServiceInitEvent`.2019-08-25T06:53:28.256149Z
BASIL - `UIInitEvent` for UI id # 0. 2019-08-25T06:53:28.370298Z
BASIL - constructor `MainView`.
BASIL - `UIInitEvent` for UI id # 1. 2019-08-25T06:58:21.677119Z
BASIL - Constructor `OtherView`. 2019-08-25T06:58:21.678951Z
11

Looks like a bug. Need to wait for a response from the Vaadin team.

12

I was thinking maybe this troubling UI re-initialization/re-instantiation was because of my manually typing in the URL bar of the web browsers. The browsers may be doing active calls to the server as part of the URL suggesting feature.

So I revamped my example app to using links.

@PreserveOnRefresh
@Route("")
@PWA(name = "Project Base for Vaadin", shortName = "Project Base")
public class MainView extends VerticalLayout {

    public MainView() {
        System.out.println("BASIL - constructor `MainView`.");
        Button button = new Button("Click me " + Instant.now(),
                event -> Notification.show("Clicked!"));
        add(button);

        // Link back to main view.
        String route = UI.getCurrent().getRouter().getUrl(OtherView.class);
        Anchor link = new Anchor(route, "Go to other view.");
        this.add(link);
    }
}

…and…

@PreserveOnRefresh
@Route("other")
public class OtherView extends VerticalLayout {
    public OtherView() {
        System.out.println("BASIL - Constructor `OtherView`. " + Instant.now());
        H1 h1 = new H1("Other. " + Instant.now());
        this.add(h1);

        // Link back to main view.
        String route = UI.getCurrent().getRouter().getUrl(MainView.class);
        Anchor link = new Anchor(route, "Go to main view.");
        this.add(link);
    }
}

But no change in behavior. Clicking the link to visit the opposite view via Routing triggers another UIInitEvent.

BASIL - `ServiceInitEvent`.2019-08-25T20:30:23.716983Z
BASIL - `UIInitEvent` for UI id # 0. 2019-08-25T20:30:23.842385Z
BASIL - `UIInitEvent` for UI id # 0. 2019-08-25T20:31:09.774154Z
BASIL - constructor `MainView`.
BASIL - `UIInitEvent` for UI id # 1. 2019-08-25T20:31:27.056157Z
BASIL - Constructor `OtherView`. 2019-08-25T20:31:27.057202Z
BASIL - `UIInitEvent` for UI id # 2. 2019-08-25T20:31:32.022503Z
BASIL - constructor `MainView`.
BASIL - `UIInitEvent` for UI id # 3. 2019-08-25T20:31:39.179601Z
BASIL - Constructor `OtherView`. 2019-08-25T20:31:39.180369Z

Furthermore, notice the constructors running on MainView and OtherView despite my having annotated them with @PreserveOnRefresh.

13

No, web browsers do not invoke web pages while typing other than showing entries from the cache.

14

Syam Pillai:
No, web browsers do not invoke web pages while typing other than showing entries from the cache.

Incorrect.

Typing an “l” (for localhost) in Safari web browser’s URL address bar causes my Vaadin app to run a new session, with output on the console. This happens in the background, with no Vaadin app yet loaded into the browser window.

See screenshot attached.

And try it for yourself.

17811735.png

15

To my understanding, a new UI should indeed be created when navigating “manually”, e.g. not using the Vaadin router. Effectively, the page is reloaded, so a new UI is created.

I believe @PreserveOnRefresh also intentionally creates a new UI, while retaining all other components.

If you set the router-link attribute on your anchor, getElement().setAttribute("router-link", "");, new UI instances should not be created.

16

Erik Lumme:
…
I believe @PreserveOnRefresh also intetionally creates a new UI, while retaining all other components.
…

I am just now experimenting with showing that UI object is indeed lost when clicking the browser Reload button, despite using @PreserveOnRefresh. I was going to report that as a bug.

How does it make sense to wipe out the UI yet preserve other content? I don’t see the logic.

And losing the UI object also means losing any state I may have attached to the UI via ComponentsUtil.setData, which is akin to setAttribute on the VaadinSession and on the VaadinContext. I always thought of UI as the browser window/tab-specific scope, just as VaadinSession is the user-specifc scope, and VaadinContext is app-wide scope.

➥ Where should I store window-level state if not on the UI?

This cavalier attitude about replacing the UI object is puzzling to me. In previous generations of Vaadin, when we wrote a Vaadin app by subclassing UI, our UI object was the core of app (well, the core of each window of our app), and stable for the entire time user kept window open.

Effectively, the page is reloaded, so a new UI is created.

I believe @PreserveOnRefresh also intentionally creates a new UI, while retaining all other components.

Those two sentences seem like a logical contradiction to me. The whole point of @PreserveOnRefresh is to not reload the page. So why intentionally create a new UI?

17

This was my understanding as well. I have thought that @PreserveOnRefresh only means that the View instance (not the UI!) would be reused (aka not re-initialized) upon refreshing, as I believed that the UI instance remained the same for each tab anyway.

The question that I have to ask myself now is one that Basil has posed too:

Where would I store window-level state if not on the UI?

There are many reasons why Session Scope is not optimal for storing window scoped states. But as long as the UI is being reinstantiated upon any navigation or page-refresh, the UI cannot be used at all for storing data/states.

Edit: In the [docs for @PreserveOnRefresh]
(https://vaadin.com/docs/v14/flow/advanced/tutorial-preserving-state-on-refresh.html#preconditions-and-limitations) it says:

Vaadin 10 and later does not preserve the UI instance between refreshes. The view is detached from its previous UI and then attached to a fresh UI instance on refresh.

Ok i guess this is intended. But it also says this:

Another use case is supporting browser tab-specific “sessions” as an alternative to the standard cookie-based session.

This “tab-specific session” is exactly what I want. But I think what is meant here is more like a view-specific session. As soon as you navigate to another view, all your “tab-specific” data is lost even if you stayed in the application, in the same tab.

18

In order to achieve a window-level storage, you may leverage a public class MainLayout extends VerticalLayout implements RouterLayout (or something similar) as the base RouterLayout for all your @Route annotations.

Since routes which use the same RouterLayout class share the instance of that RouterLayout, you can use that instance to store data that should be shared between views. As refreshing the page will still recreate the UI and associated components, you can annotate the MainLayout with @PreserveOnRefresh to keep the whole Component tree through the refresh. This of course means that things that should not be retained, need to be manually cleaned.

Here’s a quick and dirty approach for a shared RouterLayout which provides an interface for the components to implement. The interface retrieves the MainLayout instance.

public class MainLayout extends VerticalLayout implements RouterLayout {

    public interface Retriever extends HasElement {
        default Optional<Component> getMainLayout() {
            Component parent = getElement().getComponent().orElse(null);

            while (parent != null && !parent.getClass().equals(MainLayout.class)) {
                parent = parent.getParent().orElse(null);
            }

            return Optional.ofNullable(parent);
        }
    }
}
19

here is my topic about UI.
https://vaadin.com/forum/thread/17748771/when-an-ui-instance-is-created-in-vaadin-flow

20

Note that there is now a new ticket filed in GitHub issues related to this topic

https://github.com/vaadin/flow/issues/6395

21

Any update on this? In Vaadin 7, I could logout and cycle through UI to do special logout activity for each UI, but now, because of the multiple UI instances, even for one tab,my code is quite confused. In other words, on logout, I expect only one UI because only 1 tab open, but I see 2-4 UI.

22

Anthony Baldarelli:
Any update on this? In Vaadin 7, I could logout and cycle through UI to do special logout activity for each UI, but now, because of the multiple UI instances, even for one tab,my code is quite confused. In other words, on logout, I expect only one UI because only 1 tab open, but I see 2-4 UI.

Looking at [Leif’s answer]
(https://github.com/vaadin/flow/issues/6321#issuecomment-527957755) to the first ticket, you’ll see that multiple UIs may be created initially when a stray service worker sends requests that result in a 404.

If you haven’t had @PWA and then removed it, only one UI will be created. However, refreshing the page or otherwise navigating without using RouterLink or UI.navigate will result in a new UI being created, as I believe it used to work in Vaadin 7 and 8 also.

Note that old UI’s detach after missing three heartbeats, where the standard heartbeat interval I think is 5 minutes.

If the issue is with @PreserveOnRefresh, there’s an issue here https://github.com/vaadin/flow/issues/6395

23

OK, this is what I did: I started the application in the eclipse debugger and just waited, did not touch the browser at all, no human actions. I just have a breakpoint in my UIInitListener:

public class WmsServiceInitListener implements VaadinServiceInitListener {
	/**
	 * 
	 */
	private static final long serialVersionUID = -1029506952956361276L;
	private static final Logger LOGGER = Logger.getLogger(WmsServiceInitListener.class.getName());

	@Override
	public void serviceInit(ServiceInitEvent event) {
		event.getSource().addUIInitListener(ue -> {
			LOGGER.info(
					"Starting new UI: WMS session/UI " + VaadinSession.getCurrent() + "/" + ue.getUI() );
		});
		
		event.getSource().addSessionDestroyListener(new WmsSessionDestroyListener());
		event.getSource().addSessionInitListener(new WmsSessionInitListener());
	}

}

I also have a breakpoint in sessionInit method of my WmsSessionInitListener. With or without @PreserveOnRefresh enabled ( I never enabled it for Vaadin 7 because I did not need it ), I keep hitting my uiInitListener breakpoint. Note that I am doing nothing, at least not as a user. I am not currently using @PWA, since I don’t need it yet and my MPR + Vaadin 7 app is not ready for it at all. Here is the logging ( I cut out some portions of lines, but left every line of logging to show timing of events ). Why is it initializing the UI even though I am doing nothing? You mention service workers, but to the best of my knowledge I don’t have one. How can I prove that true or false?

[INFO]
 Started Jetty Server
19-09-10 17:13:00:489  WARN qtp1122084462-30 server.DefaultDeploymentConfiguration:242 - 
====================================================================
Vaadin is running in DEBUG MODE.
Add productionMode=true to web.xml to disable debug features.
====================================================================
Sep 10, 2019 5:13:19 PM com.mobiwms.website.WmsSessionInitListener sessionInit INFO: Initializing session com.vaadin.flow.server.VaadinSession@5ed864e4 with 0 UIs
Sep 10, 2019 5:13:25 PM com.mobiwms.website.WmsServiceInitListener lambda$0 INFO: Starting new UI: WMS session/UI com.vaadin.flow.server.VaadinSession@5ed864e4/com.vaadin.flow.component.UI@78fafb66
Sep 10, 2019 5:13:26 PM com.mobiwms.website.WmsEntryPoint <init> INFO: Starting WMS session/UI com.vaadin.flow.server.VaadinSession@5ed864e4/com.vaadin.flow.component.UI@78fafb66
Sep 10, 2019 5:13:26 PM com.mobiwms.website.WmsEntryPoint <init> INFO: Flow version '2.0.10', platform version '14.0.3', vaadin7 version '7.7.17', project version '3.8.Merge-vaadin14.0.3'
Sep 10, 2019 5:13:26 PM com.mobiwms.website.WmsEntryPoint <init> INFO: Browser/computer info: browser is Chrome, IP 0:0:0:0:0:0:0:1, OS Windows
Sep 10, 2019 5:13:26 PM com.mobiwms.website.WmsEntryPoint INFO: 4 servlet registrations.
Sep 10, 2019 5:13:26 PM com.wmsvision.util.ServletUtils logContextServlets INFO: Servlet name: default (org.eclipse.jetty.servlet.DefaultServlet); Mappings: /
Sep 10, 2019 5:13:26 PM com.wmsvision.util.ServletUtils logContextServlets INFO: Servlet name: jsp (org.eclipse.jetty.jsp.JettyJspServlet); Mappings: *.jsp, *.jspf, *.jspx, *.xsp, *.JSP, *.JSPF, *.JSPX, *.XSP
Sep 10, 2019 5:13:26 PM com.wmsvision.util.ServletUtils logContextServlets INFO: Servlet name: com.vaadin.mpr.MprServlet; Mappings: /framework/*
Sep 10, 2019 5:13:26 PM com.wmsvision.util.ServletUtils logContextServlets INFO: Servlet name: com.vaadin.flow.server.startup.ServletDeployer (com.vaadin.flow.server.VaadinServlet); Mappings: /*
Sep 10, 2019 5:13:26 PM com.mobiwms.website.component.HelpVideoWindow <init> INFO: Title: Login; ...
Sep 10, 2019 5:13:26 PM com.mobiwms.website.component.HelpVideoWindow getWmsHelpVideo INFO: Title: Login; Video name: null
Sep 10, 2019 5:13:26 PM com.mobiwms.website.component.HelpVideoWindow getWmsHelpVideoByTitle INFO: Title: Login; videoDirectory: null
Sep 10, 2019 5:13:26 PM com.mobiwms.website.component.HelpVideoWindow getWmsHelpVideoByTitle INFO: Title: Login; videoDirectory: null
Sep 10, 2019 5:13:26 PM com.mobiwms.website.domain.MessageMgmtService getInstance WARNING: No MessageMgmtService in WmsUI data provider, so trying session
Sep 10, 2019 5:13:26 PM com.mobiwms.website.view.login.LoginView <init> INFO: Got message mgmt service for holiday footer.
Sep 10, 2019 5:13:26 PM com.mobiwms.website.domain.LoginService getInstance WARNING: com.vaadin.flow.server.VaadinSession@5ed864e4/com.vaadin.flow.component.UI@78fafb66: No LoginService in WmsEntryPoint data provider, so trying session
Sep 10, 2019 5:13:26 PM com.wmsvision.web.util.WebConfig getClientSocket INFO: Get socket for client: mobiwms
Sep 10, 2019 5:13:26 PM com.wmsvision.web.util.WebConfig getWmsConfPath INFO: Path 1 ...
Sep 10, 2019 5:13:26 PM com.wmsvision.web.util.WebConfig getWmsConfPath INFO: Path 2 ...
Sep 10, 2019 5:13:26 PM com.wmsvision.web.util.WebConfig getWmsConfPath INFO: Path 3 ...
Sep 10, 2019 5:13:26 PM com.wmsvision.web.util.WebConfig getWmsConfPath INFO: Getting configuration from ...
Sep 10, 2019 5:13:26 PM com.wmsvision.web.util.WebConfig getClientSocket INFO: Name 'socket.xml';Path '...'
Sep 10, 2019 5:13:26 PM com.wmsvision.web.util.WebConfig getClientSocket SEVERE: Configuration file (socket.xml) missing.
Sep 10, 2019 5:13:26 PM com.wmsvision.web.WebClientSocket getInstance WARNING: Ignored WebClientSock exception java.io.FileNotFoundException: D:\...\vaadinwebsite\src\conf\wms\socket.xml (The system cannot find the path specified): D:\...\vaadinwebsite\src\conf\wms\socket.xml (The system cannot find the path specified)
Sep 10, 2019 5:13:26 PM com.mobiwms.website.domain.LoginService getInstance INFO: com.vaadin.flow.server.VaadinSession@5ed864e4/com.vaadin.flow.component.UI@78fafb66: Getting new login service, created at Tue Sep 10 17:13:26 EDT 2019
Sep 10, 2019 5:13:26 PM com.mobiwms.website.data.WmsDataProvider setLoginService INFO: com.vaadin.flow.server.VaadinSession@5ed864e4/com.vaadin.flow.component.UI@78fafb66: Setting login service to com.mobiwms.website.domain.LoginService@50304d18
Sep 10, 2019 5:13:26 PM com.mobiwms.website.domain.LoginService getInstanceClient SEVERE: No client for login session created at Tue Sep 10 17:13:26 EDT 2019, so get a new client, forcing a refresh
Sep 10, 2019 5:13:26 PM com.wmsvision.web.util.WebConfig getClientSocket INFO: Get socket for client: mobiwms
Sep 10, 2019 5:13:26 PM com.wmsvision.web.util.WebConfig getClientSocket INFO: Name 'socket.xml';Path '...'
Sep 10, 2019 5:13:26 PM com.wmsvision.web.util.WebConfig getClientSocket SEVERE: Configuration file (socket.xml) missing.
Sep 10, 2019 5:13:26 PM com.wmsvision.web.WebClientSocket getInstance WARNING: Ignored WebClientSock exception java.io.FileNotFoundException: D:\...\vaadinwebsite\src\conf\wms\socket.xml (The system cannot find the path specified): D:\...\vaadinwebsite\src\conf\wms\socket.xml (The system cannot find the path specified)
Sep 10, 2019 5:13:26 PM com.mobiwms.website.domain.LoginService getInstanceClient INFO: Got login service, created at Tue Sep 10 17:13:26 EDT 2019, with no client
Sep 10, 2019 5:13:26 PM com.mobiwms.website.view.login.LoginView <init> SEVERE: Backend seems to be down: Test webClient down
Sep 10, 2019 5:13:31 PM com.mobiwms.website.WmsServiceInitListener lambda$0 INFO: Starting new UI: WMS session/UI com.vaadin.flow.server.VaadinSession@5ed864e4/com.vaadin.flow.component.UI@6d92f062
Sep 10, 2019 5:15:15 PM com.mobiwms.website.WmsServiceInitListener lambda$0 INFO: Starting new UI: WMS session/UI com.vaadin.flow.server.VaadinSession@5ed864e4/com.vaadin.flow.component.UI@539b01ac
Sep 10, 2019 5:18:43 PM com.mobiwms.website.WmsServiceInitListener lambda$0 INFO: Starting new UI: WMS session/UI com.vaadin.flow.server.VaadinSession@5ed864e4/com.vaadin.flow.component.UI@271e8d0b
Sep 10, 2019 5:20:20 PM com.mobiwms.website.WmsServiceInitListener lambda$0 INFO: Starting new UI: WMS session/UI com.vaadin.flow.server.VaadinSession@5ed864e4/com.vaadin.flow.component.UI@13651aa0
Sep 10, 2019 5:23:51 PM com.mobiwms.website.WmsServiceInitListener lambda$0 INFO: Starting new UI: WMS session/UI com.vaadin.flow.server.VaadinSession@5ed864e4/com.vaadin.flow.component.UI@690376f3
24

More info, a little bit clearer logging. Note how the session does not change, but the number of UIs keeps increasing. Except for the generic website stuff I snipped out to make it briefer, this is the exact order of events. When the number of UIs went from 2 to 7, I was not even looking at the web page, I was looking at Eclipse, trying to find places that could be triggering new UIs by accident.

Sep 10, 2019 7:42:43 PM com.mobiwms.website.WmsServiceInitListener lambda$0 INFO: Starting new UI: WMS session/UI com.vaadin.flow.server.VaadinSession@60d47c7b/com.vaadin.flow.component.UI@735634c6 with 1 UIs.
Sep 10, 2019 7:42:43 PM com.mobiwms.website.WmsEntryPoint <init> INFO: Starting WMS session/UI com.vaadin.flow.server.VaadinSession@60d47c7b/com.vaadin.flow.component.UI@735634c6
... /* some website stuff */
19-09-10 19:42:43:987  WARN qtp1278339302-191 communication.PushHandler:84 - Invalid identifier in new connection received from 0:0:0:0:0:0:0:1
Sep 10, 2019 7:42:46 PM com.mobiwms.website.WmsServiceInitListener lambda$0 INFO: Starting new UI: WMS session/UI com.vaadin.flow.server.VaadinSession@60d47c7b/com.vaadin.flow.component.UI@5c5c75e2 with 2 UIs.
Sep 10, 2019 7:43:31 PM com.mobiwms.website.WmsServiceInitListener lambda$0 INFO: Starting new UI: WMS session/UI com.vaadin.flow.server.VaadinSession@60d47c7b/com.vaadin.flow.component.UI@3f6d51c4 with 3 UIs.
Sep 10, 2019 7:47:44 PM com.mobiwms.website.WmsServiceInitListener lambda$0 INFO: Starting new UI: WMS session/UI com.vaadin.flow.server.VaadinSession@60d47c7b/com.vaadin.flow.component.UI@b280d8a with 4 UIs.
Sep 10, 2019 7:48:45 PM com.mobiwms.website.WmsServiceInitListener lambda$0 INFO: Starting new UI: WMS session/UI com.vaadin.flow.server.VaadinSession@60d47c7b/com.vaadin.flow.component.UI@1fbaf2d7 with 5 UIs.
Sep 10, 2019 7:52:44 PM com.mobiwms.website.WmsServiceInitListener lambda$0 INFO: Starting new UI: WMS session/UI com.vaadin.flow.server.VaadinSession@60d47c7b/com.vaadin.flow.component.UI@7c898701 with 6 UIs.
Sep 10, 2019 7:53:15 PM com.mobiwms.website.WmsServiceInitListener lambda$0 INFO: Starting new UI: WMS session/UI com.vaadin.flow.server.VaadinSession@60d47c7b/com.vaadin.flow.component.UI@1e43a788 with 7 UIs.
25

For service workers, in Chrome you can open the developer tools, go to the “Application” tab, and then to “Service Workers” to see if any are present.

In the network tab of your browser developer tools, what requests are sent when the new UIs are created?