Vaadin 8 / Spring Boot / Docker -- resources under .../vaadinServlet/APP/..

I had been hacking together an app with a JavaScript-based front-end, with Spring Security etc. on the backend. I had got so far as to run it load-balanced on a Docker VM cluster.

  • Vaadin 8.5.2
  • Vaadin Push (same)
  • Spring Boot 1.5.16

A week or two ago, I started migrating everything over to Vaadin. By now, everything is playing very nicely on localhost, and I tried pushing it onto Docker.

I’ve been having issues here.

I’m running Vaadin off of an embedded Tomcat server, port 8080.

When running in a Docker VM, almost everything behaves – except for (apparently) anything under .../vaadinServlet/APP/.

  • a static image doesn’t load (GET: http://...:8080/vaadinServlet/APP/connector/0/3/source/logo.png)
  • a POST to my login-form component doesn’t work (POST: http://...:8080/vaadinServlet/APP/connector/0/7/loginForm/loginForm)

Other GETs and POSTs work just fine – e.g.:

  • GET: http://...:8080/VAADIN/themes/portal/styles.css?v=8.5.2
  • GET: http://...:8080/vaadinServlet/PUSH?v-uiId=0&v-pushId=dd09e3c1-a9a3-427a-a500-4479e8296137&...
  • POST: http://...:8080/vaadinServlet/UIDL/?v-uiId=0

Again: when executing simply on localhost, everything works fine.

Has anyone else run into a similar issue? Any bright ideas inspired? Any leads I might follow?


Some investigation later –

(random thought: I’m using the [vaadin4spring]
( project – I wonder how that is affecting anything?)

Attached a debugger to my Docker container so I can watch requests being handled.

Before I get too far: I’m using 2 different UIs in my application:

  1. LoginUI under /login – open to the public, presents login/forgot-password forms
  2. AppUI, under / – authenticated users only

So far, when booting up this app in Docker, I’m trying only to fully render the /login login form.

com.vaadin.server.ConnectorResourceHandler is responsible for fulfilling .../APP/{uiID}/{componentID}/... requests. When, say, my request for .../APP/connector/0/3/source/logo.png comes along, ConnectorResourceHandler.handleRequest(...):

  1. picks it up
  2. determines that the request is handle-able
  3. parses out the UI-ID, component-ID, and “key” (respectively, 0, 3, and source/logo.png
  4. attempts to retrieve the appropriate UI from the current VaadinSession using that UI-ID

That UI-ID is not recognized by the session. OK.

So I put a breakpoint on VaadinSession.addUI(...).

It appears that the VaadinSession picked up by the ConnectorResourceHandler (i.e., the instance passed in as a parameter) is not the same one that receives the addUI(...) call.

Something is up with the way that VaadinSessions are retrieved further up the request-handling stream. Further investigation is indicated.

Following up –

I believe I’ve solved my problem – or, at least, isolated it.

In the previous, non-Vaadin version of my app, I’d used Spring Session’s Redis integration to manage session-replication across multiple application-instances (so as to implement load-balancing). Where I went wrong, apparently, is in not giving thought to how Spring Session handles the HttpSession – and how that plays with the VaadinSession.

To avoid showing everyone how little I actually know about how Spring Session works – basically, I cut out Spring Session + Redis from my project, and everything works as expected.

I need to do more research on how Spring Session actually works, and how best to integrate it with Vaadin.

Stephen, have you looked more into Spring Session with Vaadin for replication?