HttpServletRequestListener.onRequestStart and Application.start replacement

[David3 (David Wall)]

@Leif Åstrand

Vaadin 7.1 will provide new way of doing generic request handling with the basic thread local values set up by adding a RequestHandler to VaadinService (during VaadinService init). These request handlers are run with all the standard thread locals except the current UI set up.

I presume this is the createServletService() method we can override to create our own VaadinServletService with requestStart() and requestEnd(). I do have that code commented out in our EsfVaadinServlet to give it a try once it’s ready.

@Leif Åstrand

Handling a request with the current UI defined requires answering some further questions:

2. What about requests that are not “UIDL” requests, but still tightly related to a specific UI instance, e.g. file uploads or ConnectorResource serving?
3. What about using server push and receiving a WebSocket message? This is technically not a HTTP request, although it is basically the same from a semantic point of view.
4. What about accessing one UI from a HTTP request originally directed to another UI, e.g. when updating the contents of the main UI from a UI opened in a popup window or when broadcasting something between independent UIs?
   

The answers to these questions generally depend on what you want to achieve.

Very true. I think we were not entirely sure about all of the Vaadin-specific requests you mentioned, but in our testing we found that since we map Vaadin to the a “/ui/" path from our login page (so we can handle all of our own JSP/servlets/files without going through the VaadinServlet), we were able to allow all "/VAADIN/” requests to just pass through without the login verification and just ensure they are logged in otherwise. It seems this is working.

@Leif Åstrand

Finally some comments about your example code:

• It seems that the login redirect is not directly related to this discussion as it does not really need anything set up by Vaadin?
• I can’t comment on the part that calls MainView.updateLastServerCommunications as I don’t know the purpose of that method.
• VaadinService.getCurrentRequest() in servletInitialized seems kind of pointless as the current request will be null at that point since servletInitialized is run before the first request to the servlet is processed.
• The SystemMessagesProvider code does not seem to be related to this issue?
  

Well, the login redirect now is using only servlet code because we couldn’t get it to work using just Vaadin APIs.

The MainView.updateLastServerCommunications is a hook we have that shows/monitors the last server communications – and we also happen to show the last communications time in our app’s footer. We’d like this to occur on each HTTP request with Vaadin objects setup, so this code will probably live in the new 7.1 onRequestStart() once it’s ready, and then our login check will probably take place there, too.

You are right that when we found out how to make the SystemMessages override work in Vaadin 7, we slipped in the code to see about the VaadinRequest, but it’s actually test code that we failed to remove as we tried out various options trying to beat it all into submission. We still use it to override SystemMessages, but we’ve removed that dead code thanks to your review pointing out it was still in there!