4.8. Deploying an Application

Vaadin applications are deployed as Java web applications, which can contain a number of servlets, each of which can be a Vaadin application or some other servlet, and static resources such as HTML files. Such a web application is normally packaged as a WAR (Web application ARchive) file, which can be deployed to a Java application server (or a servlet container to be exact). A WAR file, which has the .war extension, is a subtype of JAR (Java ARchive), and like a regular JAR, is a ZIP-compressed file with a special content structure.

For a detailed tutorial on how web applications are packaged, please refer to any Java book that discusses Java Servlets.

In the Java Servlet parlance, a "web application" means a collection of Java servlets or portlets, JSP and static HTML pages, and various other resources that form an application. Such a Java web application is typically packaged as a WAR package for deployment. Server-side Vaadin UIs run as servlets within such a Java web application. There exists also other kinds of web applications. To avoid confusion with the general meaning of "web application", we often refer to Java web applications with the slight misnomer "WAR" in this book.

4.8.1. Creating Deployable WAR in Eclipse

To deploy an application to a web server, you need to create a WAR package. Here we give the instructions for Eclipse.

  1. Select FileExport and then WebWAR File. Or, right-click the project in the Project Explorer and select WebWAR File.

  2. Select the Web project to export. Enter Destination file name (.war).

  3. Make any other settings in the dialog, and click Finish.

4.8.2. Web Application Contents

The following files are required in a web application in order to run it.

Web Application Organization

WEB-INF/web.xml (optional with Servlet 3.0)

This is the web application descriptor that defines how the application is organized, that is, what servlets and such it has. You can refer to any Java book about the contents of this file. It is not needed if you define the Vaadin servlet with the @WebServlet annotation in Servlet API 3.0.

WEB-INF/lib/*.jar

These are the Vaadin libraries and their dependencies. They can be found in the installation package or as loaded by a dependency management system such as Maven or Ivy.

Your UI classes

You must include your UI classes either in a JAR file in WEB-INF/lib or as classes in WEB-INF/classes

Your own theme files (OPTIONAL)

If your application uses a special theme (look and feel), you must include it in VAADIN/themes/themename directory.

Widget sets (OPTIONAL)

If your application uses a project-specific widget set, it must be compiled in the VAADIN/widgetset/ directory.

4.8.3. Web Servlet Class

When using the Servlet 3.0 API, you normally declare the Vaadin servlet classes with the @WebServlet annotation. The Vaadin UI associated with the servlet and other Vaadin-specific parameters are declared with a separate @VaadinServletConfiguration annotation.

@WebServlet(value = "/*",
            asyncSupported = true)
@VaadinServletConfiguration(
        productionMode = false,
        ui = MyProjectUI.class)
public class MyProjectServlet extends VaadinServlet {
}

The Vaadin Plugin for Eclipse creates the servlet class as a static inner class of the UI class. Normally, you may want to have it as a separate regular class.

The value parameter is the URL pattern for mapping request URLs to the servlet, as described in Section 4.8.5, “Servlet Mapping with URL Patterns”. The ui parameter is the UI class. Production mode is disabled by default, which enabled on-the-fly theme compilation, debug window, and other such development features. See the subsequent sections for details on the different servlet and Vaadin configuration parameters.

You can also use a web.xml deployment descriptor in Servlet 3.0 projects.

4.8.4. Using a web.xml Deployment Descriptor

A deployment descriptor is an XML file with the name web.xml in the WEB-INF sub-directory of a web application. It is a standard component in Java EE describing how a web application should be deployed. The descriptor is not required with Servlet API 3.0, where you can also define servlets with the @WebServlet annotation as decribed earlier, as web fragments, or programmatically. You can use both a web.xml and WebServlet in the same application. Settings in the web.xml override the ones given in annotations.

The following example shows the basic contents of a deployment descriptor for a Servlet 2.4 application. You simply specify the UI class with the UI parameter for the com.vaadin.server.VaadinServlet. The servlet is then mapped to a URL path in a standard way for Java Servlets.

<?xml version="1.0" encoding="UTF-8"?>
<web-app
  id="WebApp_ID" version="2.4"
  xmlns="http://java.sun.com/xml/ns/j2ee" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
     http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">

  <servlet>
    <servlet-name>myservlet</servlet-name>
    <servlet-class>
        com.vaadin.server.VaadinServlet
    </servlet-class>

    <init-param>
      <param-name>UI</param-name>
      <param-value>com.ex.myprj.MyUI</param-value>
    </init-param>

    <!-- If not using the default widget set-->
    <init-param>
      <param-name>widgetset</param-name>
      <param-value>com.ex.myprj.MyWidgetSet</param-value>
    </init-param>
  </servlet>

  <servlet-mapping>
    <servlet-name>myservlet</servlet-name>
    <url-pattern>/*</url-pattern>
</servlet-mapping>
</web-app>

The descriptor defines a servlet with the name myservlet. The servlet class, com.vaadin.server.VaadinServlet, is provided by Vaadin framework and is normally the same for all Vaadin projects. For some purposes, you may need to use a custom servlet class that extends the VaadinServlet. The class name must include the full package path.

Servlet API Version

The descriptor example given above was for Servlet 2.4. For a later version, such as Servlet 3.0, you should use:

<web-app
id="WebApp_ID" version="3.0"
xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd">

Servlet 3.0 support is useful for at least server push.

Widget Set

If the UI uses add-on components or custom widgets, it needs a custom widget set, which can be specified with the widgetset parameter for the servlet. Alternatively, you can defined it with the @WidgetSet annotation for the UI class. The parameter is a class name with the same path but without the .gwt.xml extension as the widget set definition file. If the parameter is not given, the com.vaadin.DefaultWidgetSet is used, which contains all the widgets for the built-in Vaadin components.

Unless using the default widget set (which is included in the vaadin-client-compiled JAR), the widget set must be compiled, as described in Chapter 17, Using Vaadin Add-ons or Section 13.4, “Compiling a Client-Side Module”, and properly deployed with the application.

4.8.5. Servlet Mapping with URL Patterns

The servlet needs to be mapped to an URL path, which requests it is to handle.

With @WebServlet annotation for the servlet class:

@WebServlet(value = "/*", asyncSupported = true)

In a web.xml:

 <servlet-mapping>
    <servlet-name>myservlet</servlet-name>
    <url-pattern>/*</url-pattern>
</servlet-mapping>

The URL pattern is defined in the above examples as /*. This matches any URL under the project context. We defined above the project context as myproject so the URL for the page of the UI will be http://localhost:8080/myproject/.

Mapping Sub-Paths

If an application has multiple UIs or servlets, they have to be given different paths in the URL, matched by a different URL pattern. Also, you may need to have statically served content under some path. Having an URL pattern /myui/* would match a URL such as http://localhost:8080/myproject/myui/. Notice that the slash and the asterisk must be included at the end of the pattern. In such case, you also need to map URLs with /VAADIN/* to a servlet (unless you are serving it statically as noted below).

With a @WebServlet annotation for a servlet class, you can define multiple mappings as a list enclosed in curly braces as follows:

@WebServlet(value = {"/myui/*", "/VAADIN/*"},
            asyncSupported = true)

In a web.xml:

    ...
    <servlet-mapping>
        <servlet-name>myservlet</servlet-name>
        <url-pattern>/myui/*</url-pattern>
    </servlet-mapping>

    <servlet-mapping>
        <servlet-name>myservlet</servlet-name>
        <url-pattern>/VAADIN/*</url-pattern>
    </servlet-mapping>

If you have multiple servlets, you should specify only one /VAADIN/* mapping. It does not matter which servlet you map the pattern to, as long as it is a Vaadin servlet.

You do not have to provide the above /VAADIN/* mapping if you serve both the widget sets and (custom and default) themes statically in the /VAADIN directory in the web application. The mapping simply allows serving them dynamically from the Vaadin JAR. Serving them statically is recommended for production environments as it is faster. If you serve the content from within the same web application, you may not have the root pattern /* for the Vaadin servlet, as then all the requests would be mapped to the servlet.

4.8.6. Other Servlet Configuration Parameters

The servlet class or deployment descriptor can have many parameters and options that control the execution of a servlet. You can find complete documentation of the basic servlet parameters in the appropriate Java Servlet Specification. @VaadinServletConfiguration accepts a number of special parameters, as described below.

In a web.xml, you can set most parameters either as a <context-param> for the entire web application, in which case they apply to all Vaadin servlets, or as an <init-param> for an individual servlet. If both are defined, servlet parameters override context parameters.

Production Mode

By default, Vaadin applications run in debug mode (or development mode), which should be used during development. This enables various debugging features. For production use, you should have the productionMode=true setting in the @VaadinServletConfiguration, or in web.xml:

<context-param>
<param-name>productionMode</param-name>
<param-value>true</param-value>
<description>Vaadin production mode</description>
</context-param>

The parameter and the debug and production modes are described in more detail in Section 11.3, “Debug Mode and Window”.

Custom UI Provider

Vaadin normally uses the DefaultUIProvider for creating UI class instances. If you need to use a custom UI provider, you can define its class with the UIProvider parameter. The provider is registered in the VaadinSession.

In a web.xml:

 <servlet>
    ...
    <init-param>
      <param-name>UIProvider</param-name>
      <param-value>com.ex.my.MyUIProvider</param-value>
    </init-param>

The parameter is logically associated with a particular servlet, but can be defined in the context as well.

UI Heartbeat

Vaadin follows UIs using a heartbeat, as explained in Section 4.7.5, “UI Expiration”. If the user closes the browser window of a Vaadin application or navigates to another page, the Client-Side Engine running in the page stops sending heartbeat to the server, and the server eventually cleans up the UI instance.

The interval of the heartbeat requests can be specified in seconds with the heartbeatInterval parameter either as a context parameter for the entire web application or an init parameter for the individual servlet. The default value is 300 seconds (5 minutes).

In a web.xml:

<context-param>
<param-name>heartbeatInterval</param-name>
<param-value>300</param-value>
</context-param>

Session Timeout After User Inactivity

In normal servlet operation, the session timeout defines the allowed time of inactivity after which the server should clean up the session. The inactivity is measured from the last server request. Different servlet containers use varying defaults for timeouts, such as 30 minutes for Apache Tomcat. You can set the timeout under <web-app> with:

In a web.xml:

<session-config>
    <session-timeout>30</session-timeout>
</session-config>

The session timeout should be longer than the heartbeat interval or otherwise sessions are closed before the heartbeat can keep them alive. As the session expiration leaves the UIs in a state where they assume that the session still exists, this would cause an Out Of Sync error notification in the browser.

However, having a shorter heartbeat interval than the session timeout, which is the normal case, prevents the sessions from expiring. If the closeIdleSessions parameter for the servlet is enabled (disabled by default), Vaadin closes the UIs and the session after the time specified in the session-timeout parameter expires after the last non-heartbeat request.

In a web.xml:

 <servlet>
    ...
    <init-param>
      <param-name>closeIdleSessions</param-name>
      <param-value>true</param-value>
    </init-param>

Push Mode

You can enable server push, as described in Section 11.16, “Server Push”, for a UI either with a @Push annotation for the UI or in the descriptor. The push mode is defined with a pushmode parameter. The automatic mode pushes changes to the browser automatically after access() finishes. With manual mode, you need to do the push explicitly with push(). If you use a Servlet 3.0 compatible server, you also want to enable asynchronous processing with the async-supported parameter.

In a web.xml:

<servlet>
  ...
  <init-param>
    <param-name>pushmode</param-name>
    <param-value>automatic</param-value>
</init-param>
<async-supported>true</async-supported>

Cross-Site Request Forgery Prevention

Vaadin uses a protection mechanism to prevent malicious cross-site request forgery (XSRF or CSRF), also called one-click attacks or session riding, which is a security exploit for executing unauthorized commands in a web server. This protection is normally enabled. However, it prevents some forms of testing of Vaadin applications, such as with JMeter. In such cases, you can disable the protection by setting the disable-xsrf-protection parameter to true.

In a web.xml:

<context-param>
<param-name>disable-xsrf-protection</param-name>
<param-value>true</param-value>
</context-param>

4.8.7. Deployment Configuration

The Vaadin-specific parameters defined in the deployment configuration are available from the DeploymentConfiguration object managed by the VaadinSession.

DeploymentConfiguration conf =
        getSession().getConfiguration();

// Heartbeat interval in seconds
int heartbeatInterval = conf.getHeartbeatInterval();

Parameters defined in the Java Servlet definition, such as the session timeout, are available from the low-level HttpSession or PortletSession object, which are wrapped in a WrappedSession in Vaadin. You can access the low-level session wrapper with getSession() of the VaadinSession.

WrappedSession session = getSession().getSession();
int sessionTimeout = session.getMaxInactiveInterval();

You can also access other HttpSession and PortletSession session properties through the interface, such as set and read session attributes that are shared by all servlets belonging to a particular servlet or portlet session.

Preface
I. Introduction
1. Introduction
1.1. Overview
1.2. Example Application Walkthrough
1.3. Support for the Eclipse IDE
1.4. Goals and Philosophy
1.5. Background
2. Getting Started with Vaadin
2.1. Overview
2.2. Setting up the Development Environment
2.3. Overview of Vaadin Libraries
2.4. Installing Vaadin Plugin for Eclipse
2.5. Creating and Running a Project with Eclipse
2.6. Using Vaadin with Maven
2.7. Creating a Project with NetBeans IDE
2.8. Creating a Project with IntelliJ IDEA
2.9. Vaadin Installation Package
2.10. Using Vaadin with Scala
3. Architecture
3.1. Overview
3.2. Technological Background
3.3. Client-Side Engine
3.4. Events and Listeners
II. Server-Side Framework
4. Writing a Server-Side Web Application
4.1. Overview
4.2. Building the UI
4.3. Handling Events with Listeners
4.4. Images and Other Resources
4.5. Handling Errors
4.6. Notifications
4.7. Application Lifecycle
4.8. Deploying an Application
5. User Interface Components
5.1. Overview
5.2. Interfaces and Abstractions
5.3. Common Component Features
5.4. Field Components
5.5. Component Extensions
5.6. Label
5.7. Link
5.8. TextField
5.9. TextArea
5.10. PasswordField
5.11. RichTextArea
5.12. Date and Time Input with DateField
5.13. Button
5.14. CheckBox
5.15. Selecting Items
5.16. Table
5.17. Tree
5.18. MenuBar
5.19. Embedded Resources
5.20. Upload
5.21. ProgressBar
5.22. Slider
5.23. Calendar
5.24. Component Composition with CustomComponent
5.25. Composite Fields with CustomField
6. Managing Layout
6.1. Overview
6.2. UI, Window, and Panel Content
6.3. VerticalLayout and HorizontalLayout
6.4. GridLayout
6.5. FormLayout
6.6. Panel
6.7. Sub-Windows
6.8. HorizontalSplitPanel and VerticalSplitPanel
6.9. TabSheet
6.10. Accordion
6.11. AbsoluteLayout
6.12. CssLayout
6.13. Layout Formatting
6.14. Custom Layouts
7. Visual User Interface Design with Eclipse
7.1. Overview
7.2. Creating a New Composite
7.3. Using The Visual Editor
7.4. Structure of a Visually Editable Component
8. Themes
8.1. Overview
8.2. Introduction to Cascading Style Sheets
8.3. Syntactically Awesome Stylesheets (Sass)
8.4. Creating and Using Themes
8.5. Creating a Theme in Eclipse
8.6. Responsive Themes
9. Binding Components to Data
9.1. Overview
9.2. Properties
9.3. Holding properties in Items
9.4. Creating Forms by Binding Fields to Items
9.5. Collecting Items in Containers
10. Vaadin SQLContainer
10.1. Architecture
10.2. Getting Started with SQLContainer
10.3. Filtering and Sorting
10.4. Editing
10.5. Caching, Paging and Refreshing
10.6. Referencing Another SQLContainer
10.7. Using FreeformQuery and FreeformStatementDelegate
10.8. Non-implemented methods of Vaadin container interfaces
10.9. Known Issues and Limitations
11. Advanced Web Application Topics
11.1. Handling Browser Windows
11.2. Embedding UIs in Web Pages
11.3. Debug Mode and Window
11.4. Request Handlers
11.5. Shortcut Keys
11.6. Printing
11.7. Google App Engine Integration
11.8. Common Security Issues
11.9. Navigating in an Application
11.10. Advanced Application Architectures
11.11. Managing URI Fragments
11.12. Drag and Drop
11.13. Logging
11.14. JavaScript Interaction
11.15. Accessing Session-Global Data
11.16. Server Push
12. Portal Integration
12.1. Overview
12.2. Creating a Portlet Project in Eclipse
12.3. Portlet UI
12.4. Deploying to a Portal
12.5. Installing Vaadin in Liferay
12.6. Handling Portlet Requests
12.7. Handling Portlet Mode Changes
12.8. Non-Vaadin Portlet Modes
12.9. Vaadin IPC for Liferay
III. Client-Side Framework
13. Client-Side Vaadin Development
13.1. Overview
13.2. Installing the Client-Side Development Environment
13.3. Client-Side Module Descriptor
13.4. Compiling a Client-Side Module
13.5. Creating a Custom Widget
13.6. Debugging Client-Side Code
14. Client-Side Applications
14.1. Overview
14.2. Client-Side Module Entry-Point
14.3. Compiling and Running a Client-Side Application
14.4. Loading a Client-Side Application
15. Client-Side Widgets
15.1. Overview
15.2. GWT Widgets
15.3. Vaadin Widgets
16. Integrating with the Server-Side
16.1. Overview
16.2. Starting It Simple With Eclipse
16.3. Creating a Server-Side Component
16.4. Integrating the Two Sides with a Connector
16.5. Shared State
16.6. RPC Calls Between Client- and Server-Side
16.7. Component and UI Extensions
16.8. Styling a Widget
16.9. Component Containers
16.10. Creating Add-ons
16.11. Migrating from Vaadin 6
16.12. Integrating JavaScript Components and Extensions
IV. Vaadin Add-ons
17. Using Vaadin Add-ons
17.1. Overview
17.2. Downloading Add-ons from Vaadin Directory
17.3. Installing Add-ons in Eclipse with Ivy
17.4. Using Add-ons in a Maven Project
17.5. Troubleshooting
18. Vaadin Charts
18.1. Overview
18.2. Installing Vaadin Charts
18.3. Basic Use
18.4. Chart Types
18.5. Chart Configuration
18.6. Chart Data
18.7. Advanced Uses
18.8. Timeline
19. Vaadin JPAContainer
19.1. Overview
19.2. Installing
19.3. Defining a Domain Model
19.4. Basic Use of JPAContainer
19.5. Entity Providers
19.6. Filtering JPAContainer
19.7. Querying with the Criteria API
19.8. Automatic Form Generation
19.9. Using JPAContainer with Hibernate
20. Mobile Applications with TouchKit
20.1. Overview
20.2. Considerations Regarding Mobile Browsing
20.3. Installing Vaadin TouchKit
20.4. Importing the Vornitologist Demo
20.5. Creating a New TouchKit Project
20.6. Elements of a TouchKit Application
20.7. Mobile User Interface Components
20.8. Advanced Mobile Features
20.9. Offline Mode
20.10. Building an Optimized Widget Set
20.11. Testing and Debugging on Mobile Devices
21. Vaadin TestBench
21.1. Overview
21.2. Installing Vaadin TestBench
21.3. Preparing an Application for Testing
21.4. Using Vaadin TestBench Recorder
21.5. Developing JUnit Tests
21.6. Taking and Comparing Screenshots
21.7. Running Tests in a Distributed Environment
21.8. Headless Testing
21.9. Known Issues
A. Songs of Vaadin
Index