Use APPLICATION_SCOPE for the session lock (#11792)
The Vaadin session itself is also stored in APPLICATION_SCOPE. The default
scope is PORTLET_SCOPE, so lock would be otherwise not be in sync with
the session.
To be able to do this, relevant methods in VaadinService are made protected so
that VaadinPortletService can override them.
Fixes #11611
Move session store/load/remove logic to service from session (#9782, #18998)
The session storage logic when implemented in VaadinSession was and must be
partly static. This makes it impossible to override the storage logic.
To be able to support storage customizations for portals (storing using
APPLICATION_SCOPE), the logic was moved to VaadinService.
For portals, all storage operations now use APPLICATION_SCOPE. Previously
only the store operation was done using APPLICATION_SCOPE, leading to
some portals not being able to load the session at all (the default
scope for reading attributes in portals is PORTLET_SCOPE).
Change-Id: I3d112608d98c883a457e650c0a25bf10c81acc78
Refactored static path resolution in VaadinPortletService.
Refactored theme name resolution in VaadinPortletService.
Refactored widgetset name resolution in VaadinPortletService.
Change-Id: I44c5ffaa7530383843205aadd8da7642899a04c9
Furthermore, the exception that might get thrown from there is passed up
through the call stack until it can be handled in a sensible way.
Change-Id: I4a741b5ad4d9216255932c2328b49e73e92df2f4
Refactored how all requests are handled by VaadinServlet and VaadinPortlet (#11192)
* Handling is now based on a list of RequestHandlers in VaadinService
* Request handling logic has been moved to VaadinService
* Users can customize the list by adding own (service level) request handlers
* For users specific request handlers you can still use the request handlers in VaadinSession
* Deprecated RequestType - all handlers are given the opportunity to handle a request until one of them chooses to handle it. RequestType makes no sense as it does not tell which handler will handle the request.
* Removed serveStaticResource which has never been used
Change-Id: Ia7d088535e46430ca8adf631d3f1dd944b9d51e2
Removed CommunicationManager and PortletCommunicationManager
* Moved AbstractCommunicationManager abstract methods
getThemeResourceAsStream and createBootstrapHandler to VaadinService
* Made ACM non-abstract and renamed to LegacyCommunicationManager
* Lifted anonymous inner BootstrapHandler subclasses into named public classes
Change-Id: I31739ce8a506d572e75ca8cd5509be215e01693d
This change enables developer to get a reference to the VaadinServlet/VaadinPortlet class without using thread locals (#10882)
Change-Id: I7cb87b6ddb6f2ac3c46f7652a807363b336cdc4e
* Primary use case for CombinedRequest (special path and parameters)
already elimiated by other changes
* BrowserDetails.getLocation is now available through Page
* BrowserDetails.getWindowName only used internally in one location
* VaadinServletRequest.cast and similar for portlets removed now that a
normal cast can always be used as there's no CombinedRequest to consider
Change-Id: I44f28722a12f86015b3c30e83768e4611b87479c
Bootstrap UI using relative URLs with servlets (#6771)
* Configure widgetset using URLs relative to the requested page
* Provide a Util method for getting an absolute URL from a relative URL
* Test by using an embedded Jetty acting as a transparent proxy
* Make /embed1 use the Buttons test to enable testing UIDL requests
Change-Id: I4ef9b40e3954ae16b682d743a339f4360db40d4d
Add SystemMessagesProvider for getting messages for a Locale (#4127)
Also add an internal helper for finding the most suitable Locale based
on the currently available information.
Change-Id: Ie9893db4be5ace7b0d60c030b7ca383359500525