Writing a Server-Side Web Application

If you use the Vaadin Plugin for Eclipse for creating the project and compiling the widget set, it automatically generates the project widget set definition file, which includes all other widget sets it finds from the class path, and sets the parameter.

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.

Servlet Mapping with URL Patterns

The url-pattern is defined above 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/. If the project were to have multiple UIs or servlets, they would have to be given different names to distinguish them. For example, 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.

Notice also that if the URL pattern is other than /* (such as /myUI/*), you will also need to make a servlet mapping to /VAADIN/* (unless you are serving it statically as noted below). For example:

...

<servlet-mapping> <servlet-name>myservlet</servlet-name> <url-pattern>/myurl/*</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 WebContent/VAADIN/ directory.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.4. Other Deployment Parameters

A deployment descriptor can have many parameters and options that control the execution of a servlet. You can find complete documentation of the deployment descriptor in the appropriate Java Servlet Specification [http://wiki.apache.org/tomcat/Specifications].

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 following setting in your web.xml:

Other Deployment Parameters

85

Writing a Server-Side Web Application

<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 detail in Section 11.3, “Debug and Production Mode”.

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.

<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).

<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:

<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

86	Other Deployment Parameters