MPR Vaadin 7 Navigator - sometimes session not set in Vaadin 7 UI element

In my pure Vaadin 7 app, I do the following:

  1. Browser tab one: login and do general setup
  2. Browser tab two: go to same website, and reload some settings if VaadinSession indicates certain things are true, else start from scratch ( forcing them to login )

I can do this because, in UI.init, I have the following:

		// Check session for login user.  If user in session, then use it.
		User sessionUser = WmsDataProvider.getCurrent().getLoginUser(true);
		if( sessionUser instanceof User 						&&
				sessionUser.getUserId() instanceof String 		&&
				!sessionUser.getUserId().trim().isEmpty()		&&
				sessionUser.getPassword() instanceof String	&&
				!sessionUser.getPassword().trim().isEmpty() )
			LoginView.doLogin(sessionUser.getUserId(), sessionUser.getPassword(),
					null/*registration id*/, null);
			updateContent( null );

The updateContent(null); path is the initial step or when I need to start from scratch.

Now, Flow of course does not have the UI.init, so I was going to try to do it in my beforeEnter method of my root element ( Route("") ). But when my updateContent method creates the Navigator, the Vaadin 7 UI does not have a session. What am I doing wrong? What initialization step am I missing?

Sadly, I am not ready to move to a pure Flow Route ( no Navigator ), at least not unless I absolutely have to. Trying to minimize changes so I can give this to the users as soon as possible and stop supporting the pure Vaadin 7 version.

This is interesting, since I have recently been investigating issue that may indicate some trouble with session too But I can’t yet conclude are we seeing different symptoms of the same root cause.


  1. Changed from using BeforeEnterObserver to BeforeEnterListener, and adding UI.getCurrent().addBeforeEnterListener(this); to the entry point constructor. This did not fix the problem.
  2. Commented out UI.getCurrent().addBeforeEnterListener(this); in entry point and instead called my special code directly in the constructor, similar to what I do in init. This did not fix the problem.
  3. Currently merging my Vaadin 7 code into a Vaadin 14.0.0.rc7 version project. I was sort of worried about using 14.0.3 because it looked like it used a lot of the new npm stuff, and at the time, when I first tried it, it would not even run. Because it was not running, I could not tell if it was my migrated code or the 14.0.3 update. My next experiment will be to try 14.0.3 with the proper migration steps as defined the the Vaadin 14 MPR documentation.

What is interesting is that it consistently works when I first connect to the session, but does not when I connect to the same session again. It is like the MprUI stuff is not initialized yet. In fact, in the debugger, both the “session” element is null ( thus all this problem ). The flow UI looks perfect, and looks to be properly initialized.

Maybe the MPR UI stuff is not fully initialized until later in the process, like when components are attached?

Same results for Vaadin 14.0.0, and here is the except stack trace, if it helps ( I get the same stack trace for rc7 ):

	at com.vaadin.server.Page.getLocation(
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(
	at java.lang.reflect.Method.invoke(
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(
	at java.lang.reflect.Constructor.newInstance(
	at com.vaadin.flow.internal.ReflectTools.createProxyInstance(
	at com.vaadin.flow.internal.ReflectTools.createInstance(
	at com.vaadin.flow.di.DefaultInstantiator.create(
	at com.vaadin.flow.di.DefaultInstantiator.getOrCreate(
	at com.vaadin.flow.di.Instantiator.createRouteTarget(
	at com.vaadin.flow.router.internal.AbstractNavigationStateRenderer.lambda$getRouteTarget$1(
	at java.util.Optional.orElseGet(
	at com.vaadin.flow.router.internal.AbstractNavigationStateRenderer.getRouteTarget(
	at com.vaadin.flow.router.internal.AbstractNavigationStateRenderer.createChain(
	at com.vaadin.flow.router.internal.AbstractNavigationStateRenderer.handle(
	at com.vaadin.flow.router.Router.handleNavigation(
	at com.vaadin.flow.router.Router.navigate(
	at com.vaadin.flow.router.Router.initializeUI(
	at com.vaadin.flow.server.BootstrapHandler.createAndInitUI(
	at com.vaadin.flow.server.BootstrapHandler.synchronizedHandleRequest(
	at com.vaadin.flow.server.SynchronizedRequestHandler.handleRequest(
	at com.vaadin.flow.server.VaadinService.handleRequest(
	at com.vaadin.flow.server.VaadinServlet.service(
	at javax.servlet.http.HttpServlet.service(
	at org.eclipse.jetty.servlet.ServletHolder.handle(
	at org.eclipse.jetty.servlet.ServletHandler.doHandle(
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(
	at org.eclipse.jetty.server.session.SessionHandler.doHandle(
	at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(
	at org.eclipse.jetty.server.handler.ContextHandler.doHandle(
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(
	at org.eclipse.jetty.servlet.ServletHandler.doScope(
	at org.eclipse.jetty.server.session.SessionHandler.doScope(
	at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(
	at org.eclipse.jetty.server.handler.ContextHandler.doScope(
	at org.eclipse.jetty.server.handler.ScopedHandler.handle(
	at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(
	at org.eclipse.jetty.server.handler.HandlerCollection.handle(
	at org.eclipse.jetty.server.handler.HandlerWrapper.handle(
	at org.eclipse.jetty.server.Server.handle(
	at org.eclipse.jetty.server.HttpChannel.handle(
	at org.eclipse.jetty.server.HttpConnection.onFillable(
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(
	at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(
	at org.eclipse.jetty.util.thread.ReservedThreadExecutor$
	at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(
	at org.eclipse.jetty.util.thread.QueuedThreadPool$

Same exact results for 14.0.3. I figured I might as well bring this application to the latest, on the chance some change or bug fix since 14.0.0 fixes this issue, but I guess the issue is deeper than that.