Backbase Deployment Guide
Backbase Deployment Guide
1
JSF Edition
Deployment Guide
JSF Edition 4.3.1 2
Table of Contents
Chapter 1. Introduction 3
Chapter 2. Prerequisites 4
Introduction
About the Deployment Guide
The Backbase Enterprise Ajax 4.3.1 - JSF Edition Deployment Guide describes how to deploy JSF Edition web applications
in all supported application containers. The procedure requires deploying the Backbase_4_3_1.war file and Backbase
JSF application WAR files directly into an application server. Although the deployment instructions vary from one application
server to another, for each individual container the process to deploy the development application is the same as for the
production application.
For the production WAR file, we walk you through the process of deployment in all supported application containers.
Information is also provided on server compression.
The information in this guide is IDE-agnostic. For information on how to create and run JSF Edition web
applications in the Eclipse IDE, please refer to the Tooling chapter in the Application Development Guide.
Intended Audience
The Deployment Guide is intended for web/system administrators and developers with responsibility for deploying JSF
Edition web applications in either the development environment or a production environment.
Getting Answers
If you are working on a difficult problem that cannot be resolved using information in this document, try the following:
Prerequisites
The prerequisite to deploy a JSF Edition web application is that the Backbase_4_3_1.war (the Client Runtime) is first
deployed. JSF Edition components render Backbase XHTML and BTL tags. This means that every JSF Edition web application
is reliant on the Client Runtime.
The JSF Edition installation includes a blank application (blank.war). Although not strictly a prerequisite for
JSF Edition web application development, the blank application is the recommended starting point for
developers not intending to use the Backbase Eclipse plugin.
The Backbase_4_3_1.war application makes the Client Runtime available to your JSF Edition web application.
In your JSF Edition web application, the Backbase JSF Server Runtime and the Client Runtime are responsible for managing
communications between the web server and the client browser. The Client Runtime is installed as a web application in your
servlet container, and is downloaded transparently to the client on an initial request.
The Client Runtime application (Backbase_4_3_1.war) is located in the client folder of your JSF Edition installation.
For detailed instructions to deploy the application, please refer to WAR Deployment Procedures [p. 7].
The blank application provides a template for JSF Edition web application development, and is delivered as a convenience to
developers not intending to use the Backbase Eclipse plugin.
If at any stage you decide to use the Backbase Eclipse plugin for JSF Edition web application development, an
Eclipse IDE project can be created by importing the blank WAR.
All the resources to build the blank application WAR are located in the blank folder of your JSF Edition installation. For
detailed instructions to build and deploy the application for all supported application servers, please refer to the chapters
entitled The blank Application [p. 5] and WAR Deployment Procedures [p. 7], respectively.
The blank application provides a template for JSF Edition web application development, and is delivered as a convenience to
developers not intending to use the Backbase Eclipse plugin.
If at any stage you decide to use the Backbase Eclipse plugin for JSF Edition web application development, an
Eclipse IDE project can be created by importing the blank WAR.
Before starting to develop a JSF Edition web application, it is recommended to copy the original blank folder to a new
location, and to develop using the copy.
During development, Tomcat is the recommended container. To create the WAR, run the build script in the buildtools
folder and deploy the resulting blank.war as described in the chapter entitled WAR Deployment Procedures [p. 7].
• Edit the JSP of the deployed application (adding BJSF tags and client events, for example)
• Redeploy the application and examine the results in your browser
To implement the custom components and backing beans that are likely to be a feature of enterprise JSF Edition web
applications, use the build script to recreate the WAR. For more details about developing custom components, please refer to
the Component Development Guide.
The resources to build the blank application WAR are located in the blank folder of your JSF Edition installation. The
scripts to build the blank application WAR are located in the buildtools folder. This folder includes an ANT build script
and properties files:
The build.xml script contains relative references to libraries on which the build depends. It is thus necessary to run the
script from its original location in the buildtools folder. The blank.war is created in a folder named build.
By default, the build script does not overwrite the contents of an existing build folder. Consequently, before
running the build script, make sure that the contents of an existing build folder are moved or deleted.
The resources are preconfigured to generate an application WAR for deployment in Tomcat. To deploy in a production server,
it is recommended to backup the original blank folder before tailoring the properties files, deployment descriptors, and, if
necessary, the script for the target application server.
• The JDK used to build the application needs to match the JDK supported by the production server
• For production servers (including WebLogic 8.1, Oracle 10g 9.0.4, Sun 8, and WebSphere 5.1.1) that do not support the
JSP 2.0 specification, the build script needs to be edited so that the following code is uncommented:
Example 1 – Enabling Application Support for JSP 2.0
<!--
<copy file="${jsp-2.0.jar}" todir="${exploded.dir}/WEB-INF/lib"/>
-->
Although the blank application provides all the resources needed to start developing a JSF Edition web application, the
rendered JSP is very simple, consisting of a button labelled Hello World that toggles some text.
If the deployed blank application does not display the Hello World button, check to make sure that the Client
Runtime application is deployed, and that its context matches the
com.backbase.bjsf.CLIENT_BOOT_DIR entry in the web.xml deployment descriptor. For more
information, please see WAR Deployment Procedures [p. 7] and the topic entitled web.xml in the Application
Development Guide.
To deploy the blank application, or any other JSF Edition web application WAR, the procedure is exactly the
same.
Deployment of JSF Edition web applications is supported in the following application servers:
Pre-Deployment Considerations
• In your production environment, you should ONLY deploy the production Backbase_4_3_1_optimized.war file. It is
optimized for use in a production environment and will perform better then the development version.
• You can find the appropriate WAR file in the client directory. The production WAR file is named
Backbase_4_3_1_optimized.war, while the development file is named Backbase_4_3_1.war.
• DO NOT switch usage of the development and production version WAR files in your production environment. There is a
possibility that JSF Edition enabled applications will malfunction for returning visitors using Microsoft Internet Explorer
with caching enabled.
• By default, the client for JSF Edition will run from http://servername:port/client.
• Please make sure that your application points to the correct location of the Client Runtime. This location is defined in the
com.backbase.bjsf.CLIENT_BOOT_DIR parameter in the application web.xml configuration file.
• As of version 4.3.1, the Backbase.war file has been renamed to Backbase_4_3_1_optimized.war (production) or
Backbase_4_3_1.war (development). Screenshots that say Backbase.war or
Backbase_4_3_1_optimized.war refer to the same .war file.
An application WAR file can be deployed in Tomcat by copying the WAR file to the Tomcat web application directory. By
default, the Tomcat web application directory is webapps. Tomcat automatically unpacks and deploys WAR files uploaded
to this location. The name of the WAR file without its extension is used as the context path name.
As an alternative to working with the server filesystem, the Tomcat console can be used to deploy application WARs:
1. In the browser Address field, type http://serverName:8080 (8080 is the default port for Tomcat). You should see the
Tomcat landing page.
2. Click the Tomcat Manager link on the left side of the page. You should see the Web Application Manager screen.
3. In the WAR file to deploy section, click Browse.
4. Navigate to and select the Backbase_4_3_1.war file.
5. Click Deploy. If successful, a message is displayed at the top of the page to confirm the deployment, and there will be a
new item in the Applications section of the page labelled Backbase_4_3_1.
The use of automatic deployment in Tomcat is strongly discouraged in a production environment because it
causes dramatic memory leaks each time you deploy or undeploy your application.
In rare situations, the files in the unpacked web archives cannot be deleted or undeployed due to a locking problem in win32
systems. When you try to redeploy, Tomcat recognizes the web application is an old one but without a web.xml file.
Tomcat continues to trigger the code of the registered listener and eventually hits the class
DigesterFacesConfigUnmarshallerImpl, which is the first to make use of a class contained in utility JARs that no
longer exist.
To avoid locking resources and JAR files for Tomcat version 5.5, for each of your web applications add the following content
to the context.xml file in the META-INF folder:
Example 2 – web.xml contents
Deploying and undeploying becomes slightly slower if the locking solution is implemented.
Perform the following steps to deploy the Backbase_4_3_1.war file on the WebSphere 5.1.1 or 6.0.2 application server:
These installation instructions assume that you have installed the application server with default configuration. If
you have changed your configuration settings, make sure to those changes are taken into account when
following the instructions.
1. Open the WebSphere console by typing the URL. For version 5.1.1 you can access the console using
http://serverName:7090/admin, whilst version 6.0.2 uses http://serverName:9060/ibm/console.
2. In the menu, expand Applications, and select Install New Application to load the Preparing for the application installation
page.
3. In the Preparing for the application installation page, make sure the Local file system option is selected, and click Browse.
4. Locate and select the production Backbase_4_3_1.war file.
5. In the Preparing for the application installation page, set the Context root to Backbase.
6. Click Next to load the Enterprise Applications page.
7. Select the Use default virtual host name for Web Modules option.
8. Make sure the Host name is set to default_host.
9. Click Next.
12. Click Next in Step 1, Step 2 and Step 3 of the Install New Application page.
13. In Step 4 of the Install New Application page, click Finish to install the application. WebSphere messages are displayed
that report the installation status.
If you use WebLogic 8.1, you cannot use the Sun JDK. Instead, you must use the BEA JRockit JDK starting with
version 1.4.2 or the 1.5 line.
These installation instructions assume that you have installed the application server with default configuration. If
you have changed your configuration settings, make sure to those changes are taken into account when
following the instructions.
These installation instructions assume that you have installed the application server with default configuration. If
you have changed your configuration settings, make sure to those changes are taken into account when
following the instructions.
Instead of using the JBoss web console, the recommended procedure is to can copy your WAR file into the root level of the
deploy directory for a given server configuration. The default name for the server configuration is default.
These installation instructions assume that you have installed the application server with default configuration. If
you have changed your configuration settings, make sure to those changes are taken into account when
following the instructions.
These installation instructions assume that you have installed the application server with default configuration. If
you have changed your configuration settings, make sure to those changes are taken into account when
following the instructions.
4. Click Next.
5. In the Application Attributes step, and set the following fields:
An application container is very useful when serving dynamic content like JSF or Struts pages. However, for static content,
it is recommended that you use a web server which is faster and more robust. This section will help you configure Apache
Httpd Server as your front-end web server in combination with the Apache Tomcat application server.
For instructions on using a front-end web server on other Backbase verified application containers, please refer
to the documentation of the respective container.
Although we recommend using a front-end web server, it is possible to deploy Backbase static content on any
web server, including the Backbase verified application containers.
When choosing a front-end web server, the support for server-side compression is an important feature to be aware of. This
Deployment Guide will instruct you how to enable compression for both Apache Httpd Server and Microsoft Internet
Information Server.
This section assumes that you have Apache Httpd Server (port 80) and Apache Tomcat (port 8080) installed and running.
Running Apache Httpd Server and Apache Tomcat in tandem means that you will need to find a way for them to
communicate.
Because JSF Edition leans heavily on JavaScript, it is important that, although we are using two web servers, the browser
thinks that all content is coming from the same source. This is to avoid problems with security settings, not allowing
JavaScript to interact cross-domain. Since Apache Httpd Server and Apache Tomcat work on different ports, this is
considered a security threat.
Therefore, we must configure Apache Httpd Server to internally connect to and process all content from Apache Tomcat,
returning the entire result from the request operation to the browser. That is where connectors come in to play.
Apache provides multiple connectors for different front-end servers. These connectors allow Apache Httpd Server to
connect to Apache Tomcat and let Apache Tomcat process the dynamic content. Below you can find a schema which
shows how the connector fits in the entire request/response cycle:
Figure 1 – Http Connectors
Configuring the connector will consist of three steps: Creating the worker.properties file for Apache Tomcat, editing
the httpd.conf configuration file for Apache Httpd Server and editing the server.xml configuration file for Apache
Tomcat.
In your installation directory of Apache Httpd Server, there is a directory called conf. Inside that directory, we will create a
simple text file and name it worker.properties. Next, we will add the following content:
Example 3 – worker.properties file
worker.list=backbase
worker.backbase.type=ajp13
worker.backbase.host=localhost
worker.backbase.port=8009
A default worker.properties file has been included in the documentation folder of your JSF Edition installation.
You can also copy and edit this file to match your specific configuration.
The next step is to configure the Apache Httpd Server configuration file. You can find the httpd.conf file in the conf
folder of your Apache Httpd Server installation directory.
Open the file in a simple text editor and locate the section on "Dynamic Shared Object (DSO) Support". Add the following line
to ensure that the mod_jk module is initialized:
Example 4 – worker.properties file
Now go to the end of the httpd.conf configuration file and add the following directives:
Example 5 – Apache Server configuration file
The above snippet binds the worker.properties file to the mod_jk. Also, it creates a log file, with the level error,
which will log all error messages in the logs\mod_jk.log file inside your Apache Httpd Server installation directory.
The JkAutoAlias directive automatically creates aliases for all folders inside your Apache Tomcat \webapps. This allows
Apache Httpd Server to serve static content from those folders.
You can specify which content should be relayed to Apache Tomcat. Use JKMount or JKUnMount to specify which
documents or folders should be handled as dynamic content by Apache Tomcat and which documents should be processed
by Apache Httpd Server.
You should replace the file locations used in the snippet to match the locations where you have installed your
versions of Apache Httpd Server and Apache Tomcat.
Please read the documentation on the mod_jk connector for more information on proper usage and additional
directives. You can find the documentation at http://tomcat.apache.org .
Finally, Apache Tomcat should also be made aware that the mod_jk connector has been put in place, and ready to process
all requests.
To do so, open the server.xml configuration file, which can be found in the conf folder of your Apache Tomcat
installation directory.
Open the file in a simple text editor and locate the following tag:
Example 6 – Tomcat Server configuration file
Below this tag, add the following line, which will add a listener to Apache Tomcat that is ready to process all requests:
Example 7 – Tomcat Server configuration file
<Listener className="org.apache.jk.config.ApacheConfig"
modJk="c:\progra~1\apache~1\apache2\modules\mod_jk.so"
workersConfig="c:\progra~1\apache~1\apache2\conf\worker.properties" />
You should replace the file locations used in the snippet to match the locations where you have installed your
versions of Apache Httpd Server and Apache Tomcat.
After you have set up all configuration properties and directives, we recommend that you restart the Apache Httpd Server
and Apache Tomcat application servers to implement the mod_jk connector.
You can also use Microsoft Internet Information Server to function as your front-end web server. You can download the
isapi_redirect.dll plugin for IIS. Please read the documentation on http://tomcat.apache.org for installation
instructions.
Compression
Backbase highly recommends that you implement some form of server-side compression. Compression can be handled
on-the-fly, in which case the web server will compress the output sent to the browser upon request, or by pre-compressing
the content to be sent.
When dealing with server-side compression, the web-server will first determine if the client browser supports it. Browsers
that support compression include an Accept-Encoding header in client-server communication. If the compression is
supported by both client and server, the server will then return compressed content to the browser.
Apache Httpd Server requires the use of the mod_gzip or mod_deflate modules to support compression.
You can download mod_gzip from http://sourceforge.net/projects/mod-gzip/ . Here you will also find
documentation required to install the module.
The mod_deflate is part of the Apache Httpd Server installation. More documentation on mod_deflate can be
found at http://httpd.apache.org/docs/2.0/mod/mod_deflate.html
Microsoft Internet Information Server 6.x has native support for compression, while Microsoft Internet Information
Server 5.x and lower require a third-party component.
Contact Backbase
Community
The Backbase Developer Network http://bdn.backbase.com brings many developers resources such as the latest
releases, errata, updates, news and our free forum to your fingertips. Architects and evaluators will also benefit from the
insights and articles posted by Backbase and by the community.
Support
Free community-based support is available through our Backbase Developer Network discussion forums. Commercial
support is available through a Backbase yearly subscription, which includes product support and software licenses. This
support is useful for individuals and businesses requiring superior technical support, regular maintenance releases,
notification and alerts on product issues, knowledge base access, email or phone support, hot fixes, and an account
manager.
Training
Backbase training courses are designed for a whole range of developers, from AJAX beginners to enterprise developers.
Courses are available online, on site, and in classroom settings. Our online classes are live with real-time instructors.
Training attendees are encouraged to communicate in real time with the instructor. All of our instructors are AJAX experts
with extensive teaching experience.
Sales
For sales-related questions and inquiries, contact your local or regional office. For up-to-date information on our global sales
offices check: http://www.backbase.com/contact
You can also submit questions to our general email address at: [email protected] .