Chapter 4. Deploying OpenLaszlo Applications

Table of Contents

1. Introduction
2. Steps to deploying an OpenLaszlo application
3. Developing an OpenLaszlo application
3.1. LPS (standard)
3.2. OpenLaszlo Core
4. Servlet containers/application servers
4.1. Changing servlet container settings
4.2. Setting Java memory (heap) sizes
4.3. Java
5. Java web application directories (webapps)
5.1. Creating OpenLaszlo-enabled Web Applications
5.2. Creating the minimal OpenLaszlo Server
6. Configuring the OpenLaszlo Server
6.1. Open Proxy by Default
6.2. Configuration files
6.3. WEB-INF/web.xml
6.4. WEB-INF/lps/config/lps.properties
6.5. Request types
6.6. Compilation Manager Dependency Option
6.7. Configuring Compiler, Media, and Data Caches
6.8. WEB-INF/lps/config/lps.xml
6.9. LPS logging configuration
6.10. SOAP Options
6.11. WEB-INF/lps/config/lzusers.xml
6.12. WEB-INF/lps/config-deploy sample deploymeht configuration
7. Security
7.1. Further notes on Open Proxies
7.2. HTTPS considerations
7.3. Crossdomain.xml files for Flash acess
7.4. Preventing denial of service (DOS) attacks
7.5. Readability of Source Files
8. Monitoring OpenLaszlo Server activity
9. Browser Compatibility
10. OpenLaszlo Server statistics
10.1. Load
10.2. URL collection
11. Using compression to reduce size of DHTML downloads
11.1. Server-side compression
11.2. Client-side decompression

1. Introduction

This document explains how to deploy proxied OpenLaszlo applications with the OpenLaszlo Server. If you deploy your applications SOLO, that is, not proxied by the OpenLaszlo Server, you do not need to read this chapter.

An OpenLaszlo application is the set of LZX files and accompanying art assets and data files that are used by that application.

The OpenLaszlo Server is a set of 100% pure Java classes (along with some configuration files) that can be used to develop and deploy OpenLaszlo applications inside Java servlet containers/application servers. OpenLaszlo application deployers need to know a few details about Java servlet containers/application servers. This document reviews these details and then goes on to explain how to deploy proxied OpenLaszlo applications with OpenLaszlo Server.

2. Steps to deploying an OpenLaszlo application

Once a proxied OpenLaszlo application has been developed, for users other than the developer to have access to it, it must be deployed. OpenLaszlo applications are deployed inside Java servlet containers/application servers. The steps include:

  1. Develop a Laszlo application

  2. Choose, install, and configure a servlet container for deployment.

  3. Create a web application including the OpenLaszlo application and OpenLaszlo Server software.

  4. Configure the OpenLaszlo Server

  5. Monitor OpenLaszlo Server activity

3. Developing an OpenLaszlo application

In order to develop an OpenLaszlo application, you should install OpenLaszlo Server on your development machine. The OpenLaszlo Server comes in two distributions.

3.1. LPS (standard)

  • Bundles the Jakarta Tomcat Servlet Container

  • Includes a Java web application archive (WAR) that is pre-configured for OpenLaszlo applications.

  • Requires just a few simple installation steps.

3.2. OpenLaszlo Core

  • Includes a Java web application archive (WAR) directory that is pre-configured for OpenLaszlo applications.

  • Requires that you have a Java servlet container or application server that supports at least 2.3 of the Java servlet specification.

The same installation can be used to both develop and deploy an OpenLaszlo application. Alternatively, you may use a separate installation to deploy your OpenLaszlo applications.

Conventions used in the remainder of this document:

  • We use $INSTALLDIR as the directory in which you installed the OpenLaszlo Server.

  • When file or directory path names are provided, unless otherwise noted, we use the Unix convention for the separator character--the forward slash ('/'). To translate the documentation for use on Windows systems, simply replace every instance of '/' with a '\'.

4. Servlet containers/application servers

A quick note on terminology: The terms servlet container and application server are often used interchangeably. OpenLaszlo documentation tends to prefer the term servlet container because it is more specific and accurate. The term application server is less standard but, in general, it is used to describe Java server software that usually is actually a servlet container. Also, any J2EE application server is, by the definition given in the J2EE specification, a servlet container. In general, the OpenLaszlo Server requires that a servlet container/application server support at least version 2.3 of the Java servlet specification.

The OpenLaszlo Server comes with the Jakarta Tomcat servlet container, which can be used to deploy OpenLaszlo applications. There are several other servlet containers on the market today. Laszlo does not endorse any specific servlet containers. See the public Laszlo website for the latest list of supported containers. Information on how to choose a and configure a servlet container is beyond the scope of this document, but deployers should note that performance of a servlet container (and underlying JVM) can have a significant impact on OpenLaszlo Server performance.

4.1. Changing servlet container settings

Once you have chosen and installed a servlet container, you may need to adjust some of its default configuration settings. In particular, you may need to configure the default TCP/IP port and secure (SSL/https) TCP/IP port. You may also need to configure the container's JVM settings like the initial and maximum heap sizes (see below) and the default and maximum number of threads.

Some servlet containers may also be configured with web servers like the Apache HTTPD web server sitting in front of them. The precise details for how to set up configurations like this, as well as the how to adjust the settings mentioned above are beyond the scope of this document; see your servlet container documentation for details. However, see below for more details on which parameters you may need to set.

4.1.1. Setting compression

[Warning]
[DHTML]

For best results, you may need to change your servelet container's compression settings, especially for DHTML applications. You can use an internet search engine using a phrase gzip followed by your server, e.g. 'gzip tomcat'. For example, here's a typical tomcat/conf/server.xml

   <Connector acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" port="8080" redirectPort="8443"
               compression="on"
               compressionMinSize="2048"
               noCompressionUserAgents="gozilla, traviata"
               compressableMimeType="text/html,text/xml,text/javascript,application/x-javascript,application/javascript">
    </Connector>
    <Connector acceptCount="100" disableUploadTimeout="true" port="8443" scheme="https" secure="true" sslProtocol="TLS" keystoreFile="conf/lzkeystore" keystorePass="changeit"
               compression="on"
               compressionMinSize="2048"
               noCompressionUserAgents="gozilla, traviata"
               compressableMimeType="text/html,text/xml,text/javascript,application/x-javascript,application/javascript">
    </Connector>

4.2. Setting Java memory (heap) sizes

You can set the heap sizes via the -Xmx and -Xms command line options such

JAVA_OPTS='-Xmx512 -Xms256m'

which will set both the initial heap size to 256 MBytes and maximum heap sizes to 512 MBytes. See your servlet container documentation, in particular, for where to place this setting.

Note that the DNS hostname of the computer running the servlet container as well as the TCP/IP port(s) on which it listens will surface as part of the URL that will be used to access your OpenLaszlo application when it is deployed. In the remainder of this document, we will use the hostname host and port number $port to indicate the values of these settings.

4.3. Java

To run the OpenLaszlo Server you must have the Java SDK (sometimes called the JDK, J2SDK, or J2SE SDK), not just the JRE, version 1.4 or greater. It's available at http://java.sun.com/j2se/1.4.2/download.html (click the Download J2SE SDK link).

[Note] Note

Mac OSX users do not have to install the SDK, as it is installed with OSX by default.

5. Java web application directories (webapps)

The name for the directory structure that houses OpenLaszlo applications within a servlet container is called, confusingly, a Java web application, or often simply a webapp. Webapps are sometimes packaged as single files that are called web application archive (WAR) files.

The LPS (standard) distribution comes with an OpenLaszlo-enabled webapp directory pre-installed in Tomcat. The web application directory is

$INSTALLDIR/Server/lps-4.0.3

This webapp includes sample Laszlo applications, example LZX files, tutorials, and documentation. The LPS Core distribution comes with a copy of this Laszlo-enabled webapp for you to install into your own servlet container. The directory version of this webapp is

$INSTALLDIR/lps-4.0.3

Note that the name of the webapp surfaces as part of the URL used to access your Laszlo applications. We will use the string $webapp below to indicate the name of a deployed web application.

For more details on Java web applications and WAR files, see the Sun documentation on servlets.

5.1. Creating OpenLaszlo-enabled Web Applications

To create an empty OpenLaszlo-enabled webapp, you simply create a new directory and copy in the WEB-INF directory from the lps-4.0.3 webapp. On a UNIX system, do

mkdir myappcp -r $LPS-WEBAPPDIR/WEB-INF myappcp -r $LPS-WEBAPPDIR/lps myapp

where $LPS-WEBAPPDIR is the path to a copy of the lps-4.0.3 web application. For LPS (standard) distribution, $LPS-WEBAPPDIR is $INSTALLDIR/Server/lps-4.0.3.

To place your Laszlo applications inside myapp, copy the LZX (.lzx extension) files and art assets for your Laszlo application(s) inside the myapp directory.

To deploy the webapp, follow your servlet container's instructions.

[Note] Note

Note that the lps-4.0.3 webapp that is packaged with LPS comes pre-configured for development, not deployment. Before deploying your applications you will nteed to reconfigure the OpenLaszlo Server for deployment, as explained in the next section.

5.2. Creating the minimal OpenLaszlo Server

The OpenLaszlo Server comes with several assets, such as documentation and examples, that you may not need or want to deploy with your OpenLaszlo application. To create a minimal deployment configuration: (For LPS 2.2 and later).

  1. clear the OpenLaszlo Server caches and server logs (or stop server and remove caches/logs and restart server)

  2. compile your applications

Now you can safely remove everything under the webapp except the WEB-INF directory and the lps directory. keeping only:

  • lps-$version/WEB-INF

  • lps-$verson/lps

You should also remove

lps-3.1/lps/utils

as it includes the source code viewer jsp and other unneeded utilities.

6. Configuring the OpenLaszlo Server

The OpenLaszlo Server comes preconfigured for use as a development platform. There are a number of configurable settings that affect the Server performance and security that should be set properly when deploying OpenLaszlo applications. You can see a sample deployment configuration in $WEBAPP/WEB-INF/lps/config-deploy

6.1. Open Proxy by Default

By default, the OpenLaszlo proxy server ships "wide open". See the discussion of security, below. See also the section on white listing and black listing for instructions on how to change this default behavior.

6.2. Configuration files

The files that are used to configure the OpenLaszlo Server are:

Changing settings in any of these files will require that the OpenLaszlo-enabled web application be restarted. See you servlet container documentation for instructions on how to restart. For the OpenLaszlo (standard) distribution, you can simply stop and re-start Tomcat.

6.3. WEB-INF/web.xml

This file is used to configure the webapp that houses OpenLaszlo applications as well as the main OpenLaszlo servlet.

The web.xml must contain a servlet declaration that uses the org.openlaszlo.servlets.LZServlet class like:

<servlet>
  <servlet-name>LPS</servlet-name>
  <servlet-class>org.openlaszlo.servlets.LZServlet</servlet-class>
</servlet>

There should be a servlet mapping that maps all .lzx files to this servlet like:

<servlet-mapping>
  <servlet-name>LPS</servlet-name>
  <url-pattern>*.lzx</url-pattern>
</servlet-mapping>

There are also other settings you can make here that affect the authentication scheme used by the OpenLaszlo Server to authenticate use of the OpenLaszlo Server's persistent connection feature. See ??? for more details.

6.4. WEB-INF/lps/config/lps.properties

This file contains numerous settings that affect LPS operation. Below is the lps.properties file that ships with LPS.

#===============================================================================
# LPS properties file for development
#===============================================================================
# * P_LZ_COPYRIGHT_BEGIN ******************************************************
# * Copyright 2001-2007 Laszlo Systems, Inc.  All Rights Reserved.            *
# * Use is subject to license terms.                                          *
# * P_LZ_COPYRIGHT_END ********************************************************

#===============================================================================
# Default request type for naked .lzx requests (requests with no (or unknown) lzt 
# query string).  For development, you want 'app_console'.  For deployment, you
# want 'html'.
#defaultRequestType=html
defaultRequestType=app_console

#===============================================================================
# Request toggles - many of these should be set to false 
# for deployment.
allowRequestXML=true
allowRequestINFO=true
allowRequestSOURCE=true
allowRequestFILTER=true


# The following requests will require the admin. password if set below
allowRequestCLEARCACHE=true
allowRequestCLEARLOG=true
allowRequestLOG=true
allowRequestLOGCONFIG=true
allowRequestGC=true
allowRequestCACHEINFO=true
allowRequestSETCACHESIZE=true
allowRequestSERVERINFO=true
allowRequestERRORCOUNT=true
allowRequestSTAT=true
allowRequestCONNECTIONINFO=true
allowRequestJAVARPCINFO=true
allowRequestSOAPINFO=true
allowRequestXMLRPCINFO=true

#===============================================================================
# Allow forced recompile (will require admin password if reset)
allowRecompile=true

#===============================================================================
# Uncomment for stat (default is true) and url collection (default is false)
#collectStat=true
#dataRequest.collectURL=true
#mediaRequest.collectURL=true

#===============================================================================
# Password to check for administrative requests.
# Uncomment and admin requests will require this passwd in the query
# string as ?pwd=your_passwd_here
#adminPassword=SET_ME_PLEASE

#===============================================================================
## Backend http properties
#
#http.maxConns=1000
#http.maxConnsPerHost=1000
# The number of redirects to try (security issue; default is 0)
http.followRedirects=3
# Timeout for back-end http requests
#http.backendTimeout=30000
#http.backendConnectionTimeout=30000

#===============================================================================
# Compilation manager dependency options: 
#
# never - compile once
# check  - check all includes
# always - compile for each access
#
# 'never' results in highest performance, requires an ?lzrecompile=true request
# to recompile the application.
compMgrDependencyOption=check

#===============================================================================
# Cache settings
#
# Locations of cache directories
# The default location is inside the WEB-INF/lps/work directory
# of your web application.  

# Compilation cache
#cache.directory=WEB-INF/lps/work/cache
# Compilation media cache
#cmcache.directory=WEB-INF/lps/work/cache/cmcache
# Script compiler cache
#scache.directory=WEB-INF/lps/work/scache

# Runtime Media cache
#mcache.directory=WEB-INF/lps/work/mcache
# Runtime Data cache
#dcache.directory=WEB-INF/lps/work/dcache

# Cache sizes (0 = disabled (or allow 1 item for disk caches), -1 means infinite)
# Defaults are 500000000 for disk and 1000000 for mem
#mcache.disk.size=500000000
#mcache.mem.size=1000000

# Max size allowable for an item to be cached in memory
# in the media cache (some media files are big and we
# need to keep them on disk only).
mcache.mem.item.max=1000000

# Cache sizes (0 = disabled (or allow 1 item for disk caches), -1 means infinite)
# Defaults are 500000000 for disk and 1000000 for mem
#dcache.disk.size=500000000
#dcache.mem.size=1000000

# Compiler Media Cache
# there is no need to keep any of these files in memory
cmcache.mem.size=0

# Keeps script cache small
scache.disk.size=10000000
scache.mem.size=1000000

#===============================================================================
# Apache AXIS settings

# Defaults to WEB-INF/lps/config/client-config.wsdd
# axis.clientConfigFile=client-config.wsdd

#===============================================================================
# WSDL load options: 
#
# never - loads once
# always - loads for each access
#
# 'never' results in highest performance
rpc.soap.wsdlLoadOption=always

#===============================================================================
# Persistent connection properties
maxMessageLen=2000
connectionLength=65536

#===============================================================================

#===============================================================================
# Compiler parameters
compiler.runtime.default=swf7

6.5. Request types

In general, when you go to deploy an OpenLaszlo application, you may wish to disable certain request types. The OpenLaszlo Server supports numerous request types that are indicated via the ?lzt query string variable in an URL. You can specify the default request type for URLs that don't specify ?lzt via the defaultRequestType property.

Table 4.1. Request Types

Property Request type LPS Response when enabled
allowRequestXML ?lzt=xml XML for the LZX application source
allowRequestINFO ?lzt=info Information about compiled LZX application
allowRequestSOURCE ?lzt=source Allows or prevents download of LZx source
(debugging) ?lzt=debug HTML wrapper for LZX source code Debugger
allowRequestFILTER ?lzt=filter Filter for dynamic HTML wrapper
allowRequestCLEARCACHE ?lzt=clearcache Clears all server caches
allowRequestLOG ?lzt=log Responds with the current detailed log
allowRequestLOGCONFIG ?lzt=logconfig Displays and sets log configuration
allowRequestCLEARLOG ?lzt=clearlog Clears the current log
allowRequestCACHEINFO ?lzt=cacheinfo Gets media cache information
allowRequestSERVERINFO ?lzt=serverinfo Gets LPS information
allowRequestERRORCOUNT ?lzt=errorcount Gets LPS error count
allowRequestSTAT ?lzt=stat Gets LPS statistics when enabled
allowRequestGC ?lzt=gc Runs the garbage collector
allowRequestCONNECTIONINFO ?lzt=connectioninfo Gets information on persistent connection

6.6. Compilation Manager Dependency Option

There are three values for this property:

always

compile an LZX application on each request.

check

compile the LZX application if it or any of its source files or assets have changed since the application was last compiled.

never

compile the LZX application only if there is no cached version. This results in highest server performance but requires server restarts to pick up any application changes.

In general, deployments where the LZX source files and assets are fixed should use never. For deployments where LZX source and/or art assets may change, you should use check. If you choose never and need to update the application, you may provide the lzrecompile=true query string at the end of a request for the application. You may also need to provide the administrator password for this to take affect.

6.6.1. OpenLaszlo Server script compiler cache

The server maintains an in-memory cache of recently compiled script segments. In general, the default value of 100 should suffice. Under rare circumstances, when deployed Laszlo application will be edited, recompiled frequently, or generated automatically via a pre-processing request, you may want to increase the size of this cache.

6.6.2. OpenLaszlo Server cache directories

By default, LPS places its caches inside the web application's WEB-INF directory. this is $INSTALLDIR/lps-4.0.3/WEB-INF/lps/work/cache.

6.7. Configuring Compiler, Media, and Data Caches

The server uses several caches that are maintained via a standard LRU (least recently used) algorithm. Each caches can be configured independently and each one can be set to use disk only or memory (backed by disk) plus additional disk space. The caches (and their names) are:

Table 4.2. Server Caches

Cache Name Use
Compiler cache applications
Media media runtime media
Data data runtime XML data
Compiler Media cmcache statically compiled media

In general, it helps to know the expected number and size of the items being cached to optimally tune some of these numbers. Here's the list:

Table 4.3. Server cache configuration

Property Definition Values
name.disk.size max size in bytes for disk cache

-1 means infinite; 0 means disabled

name.mem.size max size in bytes for RAM cache

Same as above except 0 means allow 0 items

name.mem.item.max max size in bytes for an in memory item  
name.disk.load   default 0.75
name.disk.mapsize initial map capacity  
name.mem.load   default 0.75
name.mem.mapsize initial map capacity  

name is one of cache, dcache, mcache, cmcache.

Note that the amount of disk space a cache will use is actually name.disk.size + name.mem.size. Also note that the cache will does not keep track of the amount of disk space used for meta data. For smaller items, the meta data can be significant.

Each cache has two properties that affect its performance: initial capacity (mapsize) and load factor (load). The capacity is the number of buckets in a hash table, and the initial capacity is simply the capacity at the time the hash table is created. The load factor is a measure of how full the hash table is allowed to get before its capacity is automatically increased. When the number of entries in the hash table exceeds the product of the load factor and the current capacity, the capacity is roughly doubled by calling the rehash() method.

As a general rule, the default load factor (.75) offers a good tradeoff between time and space costs. Higher values decrease the space overhead but increase the lookup cost (reflected in most of the operations of the HashMap class, including get() and put()). The expected number of entries in the map and its load factor should be taken into account when setting its initial capacity, so as to minimize the number of rehash() operations. If the initial capacity is greater than the maximum number of entries divided by the load factor, no rehash() operations will ever occur.

6.8. WEB-INF/lps/config/lps.xml

The lps.xml file contains configuration options for

  • specifying a security 'white-list/black-list' for LPS back-end data/media requests

  • allowing/denying gzip content-encoding based on user-agent

  • allowing/denying persistent connections based on user-agent

Here is an example on what this file can look like:

<lps-configuration>

    <!-- Default options -->
    <option name="content-encoding-user-agent" >
        <deny>
            <!-- Deny Netscape 4.7* -->
            <pattern>Mozilla/4\.7[0-9]* .*</pattern>
        </deny>
    </option>

    <option name="connection-user-agent" >
        <deny>
            <!-- Deny Safari -->
            <pattern>Safari</pattern>
        </deny>
    </option>

    <application path="/examples/dataimage.lzx" >
        <option name="proxy-security-urls">
            <allow>
                <pattern>http://.*\.images\.com/.*</pattern>
                <pattern>http://.*\.adobe\.com/.*</pattern>
            </allow>
        </option> 
    </application>

    <application path="/examples/data.lzx" >
        <option name="proxy-security-urls" >
            <deny>
                <pattern>http://.*\.foobar\.net/.*</pattern>
            </deny>
        </option> 
    </application>

    <!-- Deny requests under /secret in the foobar.com domain -->
    <!-- for LZX files that begin with /data.                 -->
    <application pattern="/data.*\.lzx" >
        <option name="proxy-security-urls" >
            <deny>
                <pattern>http://*\.foobar\.net/.*</pattern>
            </deny>
        </option> 
    </application>

</lps-configuration>

The root element of lps.xml is <lps-configuration> and only two valid tags exist:

  • <option>

  • <application>

Any <option> tag defined under <lps-configuration> is considered a global default. This default option may be overridden by using the <application> tag.

The <option> tag has one attribute called name that takes one of the following values:

content-encoding-user-agent

determines which user-agents are allowed/denied content-encoding.

proxy-security-urls

white-list/black-list of allowed/prohibited request URLs.

6.8.1. Setting "white lists" and "black lists"

Each <option> can have one of two elements: <allow> or <deny>. The <allow> and <deny> tags contain a list of regular expression patterns to be matched. For example, to disallow content encoding for Netscape 4.7:

    <option name="content-encoding-user-agent" >
        <deny>
            <pattern>Mozilla/4\.7[0-9]* .*</pattern>
        </deny>
    </option>

Or to only allow requests to fetch data from the laszlosystems.com or foobar.com domain:

    <option name="proxy-security-urls" >
        <allow>
            <pattern>http://.*\.laszlosystems\.com/.*</pattern>
            <pattern>http://.*\.foobar\.com/.*</pattern>
        </allow>
    </option>

6.8.2. Overriding default options

A set of <option> tags also can be placed inside the <application> tag, which will override the default option for an application path. The <application> tag takes one of two attributes:

path

the pathname of the application.

pattern

a regular expression to match an application path.

Both path and pattern are relative to the web application name.

To match the application path /examples/dataimage.lzx and only allow URL requests that for any directory under images.com and adobe.com:

    <application path="/examples/dataimage.lzx">
        <option name="proxy-security-urls">
            <allow>
                <pattern>http://.*\.images\.com/.*</pattern>
                <pattern>http://.*\.adobe\.com/.*</pattern>
            </allow>
        </option> 
    </application>

You can also use a regular expression to match a set of application paths by using the pattern attribute:

    <application pattern="/examples/data.*\.lzx" >
        <option name="proxy-security-urls">
            <deny>
                <pattern>http://.*\.foobar\.com/.*</pattern>
            </deny>
        </option> 
    </application>

The OpenLaszlo Server uses the following precedence to determine which filter will be applied to your application:

  1. There is a matching application path attribute and it contains a matching option.

  2. There is a matching application pattern attribute and it contains a matching option.

  3. There is matching global option.

  4. Allow request.

6.9. LPS logging configuration

The OpenLaszlo Server provides a highly configurable and efficient logging mechanism that you can use to debug and monitor server activities.

The server uses the well-known Log4j package for logging details about its operation. You can configure LPS logging by modifying elements of the log4j:configuration tag in the lps.xml configuration file. The default location for the detailed log file is inside the web application's WEB-INF directory at $webapp/WEB-INF/lps/work/logs/lps.log.

You can change the location of this file using a "File" parameter in the lps appender. For example,

<appender name="lps" class="org.apache.log4j.RollingFileAppender">
  <param name="File" value="lps.log"/>
    <!-- other settings here -->
</appender>

will leave the log in the default location inside the web applications's WEB-INF directory. You can also modify the amount of logging done by changing the priority of your logger from info to debug. For more details on this file see the online manual and the xml configurator primer. There's also the detailed doc about the pattern layout for controlling the format of each log statement. The default settings will keep 5 backup log files each with a maximum size of 10 MBytes. You can change them by using the MaxBackupIndex param and MaxFileSize param in the lps appender. For example, the following will keep 20 backup log files with a maximum size of 5 MBytes.

<appender name="lps" class="org.apache.log4j.RollingFileAppender">
  <param name="MaxBackupIndex" value="20"/>
  <param name="MaxFileSize" value="5MB"/>
  <!-- other settings here -->
</appender>

Your servlet container will likely maintain logs of its own. See your servlet container documentation of the location and configuration of these logs.

The default configuration that ships with the OpenLaszlo Server also includes a logger named, org.openlaszlo.exceptions. The server will log unexpected exceptions to this logger. During development this logger should be left as WARN or ERROR level, but most deployments will prefer to comment it out, unless they are troubleshooting.

6.9.1. Runtime log configuration

Logging can be configured during runtime with the lzt=logconfig request type. The request by itself returns the server's log4j configuration. You can modify and tell the OpenLaszlo Server to read your new configuration options by passing a lzt=logconfig&reread=1 query parameter. The server always looks for a log4j.xml file first in the server's configuration directory before checking for the <log4j:configuration> element in lps.xml.

You can also pass a new XML configuration to the server by sending using the xml parameter.

    lzt=logconfig&xml=%3Clog4j:configuration%3E...%3C/log4j:configuration%3E

To save your new settings into a log4j.xml file that your server can use as your default log configuration, send save=1 with your new settings.

    lzt=logconfig&xml=...&save=1

6.10. SOAP Options

6.10.1. WSDL Load Option

There are two values for this property:

always

Fetch the WSDL from the backend for every load of a SOAP object.

never

Fetch the WSDL from the backend once during startup. Subsequent loads will fetch WSDL from cache.

Use never during deployment and always for development. Default is always. You'll need to restart the server for changes to take effect.

6.10.2. Modifying AXIS SOAP Transport

The Apache Axis library is used to support SOAP in the OpenLaszlo Server. The server uses HttpClient as its HTTP transport of choice through its configuration of WEB-INF/lps/config/client-config.wsdd.

<?xml version="1.0" encoding="UTF-8"?>
<deployment name="commonsHTTPConfig" xmlns="http://xml.apache.org/axis/wsdd/" 
            xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">
  <transport name="http" pivot="java:org.apache.axis.transport.http.CommonsHTTPSender" />
</deployment>

The CommonsHTTPSender class uses HttpClient to call SOAP services.

6.11. WEB-INF/lps/config/lzusers.xml

This file contains the set of users recognized by the default security servlet (used by the default OpenLaszlo Server authenticator interface). The authenticator is used by to authenticate users who attempt to connect to the ther sever via the Persistent Connection Manager.

6.12. WEB-INF/lps/config-deploy sample deploymeht configuration

In parallel with the config directory in WEB-INF/lps there is a directory named config-deploy which contains a sample OpenLaszlo configuration for deployment purposes. To use this directory, simply delete, move, or rename the config directory out of the way and copy, rename the config-deploy one to config. You should definitely review the configuration and modify it to suit your needs. Of course you will have to (re)start your OpenLaszlo Server.

7. Security

7.1. Further notes on Open Proxies

As noted above, by default the OpenLaszlo Server is set up as an open proxy. As with any servlet (or CGI), the OpenLaszlo Server is a program that responds to web queries. When connected to the big, bad, internet, it is possible that an unexpected or malformed query can exercise an unexpected code path that could lead to failure of the servlet or to the servlet's being exploited to take control of the server on which it is hosted. Therefore the OpenLaszlo Server should not be deployed as an open server without careful consideration of these issues. If you are using Tomcat as your servlet container, we recommend the security chapter of the O'Reilly Tomcat book which discusses how to secure a Tomcat server. If you are using another servlet container, you should consult that provider's documentation on how to best secure your system.

In addition, you can use OpenLaszlo'swhite-listing and black-listing capabilities to limit access.

The OpenLaszlo Server and OpenLaszlo applications inherit the security of the container in/from which they are deployed. If you would like to serve OpenLaszlo applications over secure HTTPS transport, you will need to enable this feature in your servlet container.

7.2. HTTPS considerations

With few exceptions, OpenLaszlo applications work identically when served over HTTPS. The two exceptions are:

  • There is increase in server and client CPU load to handle the encryption/decryption that is part of HTTPS/SSL.

  • An HTTPS-served application can make runtime HTTPS data and media requests without any additional configuration.

OpenLaszlo applications served over standard (insecure) HTTP transport can make secure runtime HTTPS requests. These requests are transported securely from the client to the OpenLaszlo Server. (They are also transported securely from any back-end to the server itself).

7.3. Crossdomain.xml files for Flash acess

[Warning]
[SWF]

SWF only: The features described in this section only work in applications compiled to SWF. They do not work in applications compiled to other runtimes.

OpenLaszlo applications served over (insecure) HTTP that run in the Macromedia Flash 7 player may require additional server configuration to access runtime data and media over secure HTTPS. According to Macromedia documentation, you will need to provide a cross-domain policy file that explicitly allows such access to your remote data. OpenLaszlo provides a sample (and lenient) cross-domain policy file ($WEBAPP/WEB-INF/lps/config/crossdomain.xml) that, when copied to the root directory of the front-most server that serves the OpenLaszlo application, will enable HTTPS access from applications that are loaded over (insecure) HTTP from any server. If you need to support HTTPS access from HTTP-loaded apps, you should read this example file and follow the instructions inside it before copying. See the Macromedia article on security in Flash 7 for details on the format and interpretation of the cross-domain policy file.

If you are running the OpenLaszlo Server inside a servlet container and the servlet container is directly accessible, then the file crossdomain.xml should be placed in container's ROOT web application. See your servlet container's documentation for locating this directory. If you are fronting your container with another server such as Apache, this file needs to be placed in that server's root directory. For example, with Apache, this would be Apache's DocumentRoot directory (or the root of Apache's virtual host directory for the host that's serving the application).

7.4. Preventing denial of service (DOS) attacks

The configuration of your servlet container (or front-side server) can also affect the security of the LPS. To prevent certain denial-of-service (DOS) attacks, you may want to configure the max size of an HTTP request body, the maximum size of an HTTP request header, the maximum number of HTTP headers in a request, and the maximum size of the initial request line (url and query string).

7.5. Readability of Source Files

The OpenLaszlo Source Viewer, which ships with the OpenLaszlo Server, allows anyone with internet access to read any XML files, including sources to any .lzx program, in your LPS directory by using a query such as, for example, http://127.0.0.1:8080/lps/lps/utils/viewer/viewer.jsp?file=/examples/tag-definition.lzx.

To prevent this, remove or rename the viewer directory from the lps/lps/utils directory and set allowRequestSOURCE=false in the file.

Also note that source code to your applications may be made visible through the context ("right click") menu. See this page for a discussion about how to disable this programmatically.

8. Monitoring OpenLaszlo Server activity

You can monitor OpenLaszlo Server activity by looking at the log file. You can examine the log file directly on the server (see above for locating the log file). Or you can use the simple administrator's console that comes with OpenLaszlo Server at http://$host:$port/$webapp/lps/admin/console.lzx.

(If the administrative password has been configured in the lps.properties file, then you will need this password to use the console.)

See also the next section on server statistics.

9. Browser Compatibility

Different browsers vary in their support for options such as gzip compression and http request options . The table below summarizes known browser capabilities at this time. As explained in section WEB-INF/lps/config/lps.xml, the lps.xml file is configured with regexp patterns which specify these browsers by matching on their user-agent string.

Doesn't support gzip correctly Say they support gzip but don't Don't support if-modified-since correctly Can't abort an HTTP request
Older Safaris, MAC IE5.2 See lps.xml table Everything but Safari Mac IE5.2, NS 4.7x

10. OpenLaszlo Server statistics

You can use the lzt=stat request type to track server statistics. You will need to verify that you have the stat request type enabled in your lps.properties. The stat request type will return XML showing general server configuration, server load for the past 1/5/15 minutes, and information on the number of unique data and media urls. Note that administrative requests are not included in these statistics.

10.1. Load

The server keeps track of the following loads:

  • application: load on server for LZX application requests.

  • media: load on server for media requests, e.g., mp3, gif.

  • data: load on server for data requests.

  • persistent connection: number of active persistent connections.

  • all: sum of application, media, and data loads.

10.2. URL collection

The server also keeps track of the number of unique data and media urls that have been requested. You can toggle url details at run-time by using the durl=[0|1] and murl=[0|1] query string parameters for data and media urls, respectively. By default, url details are turned off. See lps.properties for more info.

11. Using compression to reduce size of DHTML downloads

SWF files are internally gzip-compressed, which results in smaller files, especially when those files consist primarily of script, as do most OpenLaszlo-compiled applications. As a result, the smallest SWF-compiled OpenLaszlo application, which includes the LFC, is approximately 60K in size. The comparable DHTML-complied OpenLaszlo application, in contrast, is approximately 250K. This would be a serious problem, except that gzip compression is supported as part of the HTTP standard, and can be enabled in various ways, including by settings on the Web server (Apache Web Server or similar) or, when the deployment includes the OpenLaszlo server, in the Java server environment.

The effect of this compression, when correctly enabled in the serving environment, is that the compression is actually slightly better than the internal gzip compression supported by the SWF file format. Our measurements indicate that the 250K compresses down to 50K.

11.1. Server-side compression

The server-side configuration is different for different servlet containers and web servers. The idea is to tell whatever application responds to HTTP requests that it should compress JavaScript before sending it. We expect our users to deploy to a variety of servlet containers and web servers, so, instructions on how to configure a particular system to gzip JavaScript are beyond the scope of this document. We recommend that deployers do do this configuration. As an example, for tomcat, one would add attributes about compression to the connector tag in your server.xml:

<Connector port="8080"
compression="on"
compressionMinSize="2048"
noCompressionUserAgents="gozilla, traviata"
compressableMimeType="text/html,text/xml,text/JavaScript,application/x-JavaScript,application/JavaScript"/>

11.2. Client-side decompression

The client-side configuration is much easier; the HTTP protocol specifies "content codings" which may include gzip. A properly configured server will add the appropriate content-coding=gzip header, and modern browsers will recognize that that header means that the content will be gzipped. With todays browsers (including all browsers supported by OL4), this does not require any client-side (browser) configuration.