Cisco Cisco Customer Voice Portal 8.0(1) Developer's Guide

name conflicts within an individual application. One consequence, however, is that static
class variables are static only within each application, even if they appear in classes stored
in 

.

Additionally, when an application is updated, a new classloader is created for the application,
replacing the previous one. This is not a problem unless dealing with static variables, which
would be reset once the application is updated. While knowledge of classloaders is not
required in order to know how to build custom components, it can be useful to understand
how classloaders work in Java to understand how custom component code integrates with
VXML Server.

•

An application is loaded into memory when VXML Server first starts up or the application
is updated. During this process, a single instance of each element (both standard and
configurable) is created and cached for the application to use. Whenever a call to that
application encounters an element, VXML Server will call the execution method of that
single instance. This means that a single element instance will handle requests made across
all calls to the application. This applies to multiple uses of an element type in the call flow
(for example, if the call flow contains two Digits elements, VXML Server will actually use
the same instance for both across all calls). This is very important because in this design, the
element class acts as if it is static.

The consequence of this is that all member variables defined in the element class act as static
variables, meaning that once changed, every caller experiencing that element type is exposed
to the same value. It is highly recommended to use only static final member variables, store
any persistent data in the session (which the API provides access to), and keep all other
variables local to the execution method. Everything an element needs is provided by the API
so while this is important to be aware of, this design restriction should not prevent the
developer from implementing any desired functionality within the element.

•

VXML Server runs in a multi-threaded environment. If the guidelines above are followed,
such as avoiding member variables and non-final static variables this does not pose a problem.
The developer does not need to worry about architecting their code with synchronization in
mind when dealing with local or session variables. They would, however, when performing
tasks such as accessing external resources such as files.

Compiling Custom Java Components

Once a component is constructed in Java, the process for compiling and deploying these classes
is very simple. The VXML Server 

 directory includes JAR files containing everything a

developer requires to compile custom components. The main JAR file of interest is 

, which defines the entire Unified CVP Java API (including the VFCs).

To create custom components, all that is needed is to ensure that this JAR file appears in the
compiler’s 

 or referred to in a Java IDE project file. Some Java IDEs may require

additional JAR files, 

 and 

, to appear in the 

 since the

classes within 

 refer to classes defined in those JAR files and these IDEs

cannot compile without definitions for these additional classes. The command-line Java compiler
does not require 

 or 

 to appear in the 

. The developer is

then responsible for adding to the 

 any additional JAR files their custom code

requires.

Programming Guide for Cisco Unified CVP VXML Server and Cisco Unified Call Studio Release 8.0(1)