NonStop Servlets for JSP System Administrator`s Guide

Transcription

NonStop Servlets for
JavaServer Pages
(NSJSP) System
Administrator’s Guide
Abstract
NonStop Servlets for JavaServer Pages (NSJSP) is a container that runs Java servlets
and JavaServer Pages (JSPs), which are platform-independent server-side programs
that programmatically extend the functionality of web-based applications by providing
dynamic content from a webserver to a client browser over the HTTP protocol.
Product Version
NonStop Servlets for JavaServer Pages 5.0
Supported Release Version Updates (RVUs)
This guide supports G06 and all subsequent RVUs until otherwise indicated in a new
edition. For Parallel Library TCP/IP support you must be running G06.08 or later.
Part Number
Published
525644-002
December 2005
Document History
Part Number
Product Version
Published
525644-001
March 2003
525644-002
December 2005
NonStop Servlets for
JavaServer Pages (NSJSP)
System Administrator’s Guide
Glossary
Index
Examples
What’s New in This Manual xi
Manual Information xi
New and Changed Information
Figures
Tables
xi
About This Manual xiii
Who Should Read This Guide xiii
Organization of This Guide xiv
Related Manuals xiv
Reference Information on the Internet
Notation Conventions xviii
Abbreviations xxiii
xvii
1. Overview and Architecture
Java 2 Enterprise Edition (J2EE) Overview 1-3
The Web Container 1-3
JavaServer Pages (JSP) 1-4
The Web Application 1-5
The WEB-INF Subdirectory 1-6
The Deployment Descriptor 1-6
Web Archive (WAR) Files 1-6
JavaServer Pages (JSP) Architecture 1-7
Model-View-Controller Designs 1-7
JSP Syntax Basics 1-10
An Example of JSP Code 1-10
NonStop Servlets for JavaServer Pages (NSJSP) Architecture
New Features in the HP NSJSP Implementation 1-14
J2EE Standards Support 1-14
Standalone Application Deployer 1-14
Complete Server Monitoring 1-14
Enhanced JSP Runtime Engine 1-14
JAASRealm Support 1-15
Enhanced Security Manager Support 1-15
Hewlett-Packard Company —525644-002
i
1-12
1. Overview and Architecture (continued)
Contents
1. Overview and Architecture (continued)
JMX Based Administration Feature 1-16
admin Web Application 1-16
manager Web Application 1-17
Enhanced NSJSPCoyoteConnector 1-19
Session Clustering (not supported) 1-19
Invoker Servlet Availability 1-19
2. Installing NSJSP
Before You Begin the Installation 2-1
Begin the Installation 2-2
setupjava 2-3
setup 2-4
Starting or Restarting NSJSP 2-6
Possible Error Conditions 2-6
Stopping NSJSP 2-7
Uninstalling NSJSP 2-8
NSJSP Directory Structure 2-9
Directory Example 2-11
3. Configuring NSJSP
Configuring the NSJSP Container 3-1
servlet.config 3-2
nsjspadmin.config 3-5
iTP_server.xml 3-9
web.xml 3-11
jdbc.config 3-13
filemaps.config 3-13
Configuring Web Applications 3-14
Add a New Web Application 3-15
Deploy an Existing Application WAR File 3-15
Deploy a Web Application Automatically 3-15
Deploy Using the Standalone Application Deployer 3-16
Deploy Using the admin or manager Web Applications 3-17
Create a New Application 3-17
Compile a Servlet 3-18
Deploy a Servlet 3-18
Map Requests to Applications and Servlets 3-20
URL Mapping to the Application 3-20
NonStop Servlets for JavaServer Pages (NSJSP) System Administrator’s Guide —525644-002
ii
Contents
URL Mapping to the Servlet 3-20
Configuring the Security Manager 3-21
Starting NSJSP Through a Security Manager 3-24
Troubleshooting the Security Manager 3-25
Enhanced Security Manager 3-26
Configuring Virtual Hosting 3-28
Configuring Realms 3-28
MemoryRealm 3-29
JDBCRealm 3-31
JNDIRealm 3-35
JAASRealm 3-40
DataSourceRealm 3-43
UserDatabaseRealm 3-44
Digested Passwords 3-45
Configuring Single Sign-On Support 3-46
Configuring Persistent Sessions 3-49
Creating a NonStop SQL Database to Store the Persistent Session Data
Configuring the Manager for Sessions Support 3-51
Configuring the Persistent Store 3-55
3-58
3-49
4. Programming and Management Features
Client Programming Features 4-1
Invoking a Servlet 4-1
Passing Request Information 4-1
Receiving Response Information 4-2
Servlet Programming Features 4-2
Programming Using NonStop Server for Java 4-3
Programming Using Other Java Environments 4-4
Servlet and NSJSP Examples and References 4-4
Using the Servlet API 4-4
Obtaining Specific CGI Environment Variable Values
Context-Management 4-6
Multithreading – Spawning Java Threads 4-6
Request and Response Streams 4-7
Security Considerations 4-7
International Character Set Support 4-7
Reserved Cookie Names 4-8
4-6
iii
Contents
javax.servlet.request.X509Certificate 4-8
JMX Based Administration 4-9
admin Web Application 4-10
Overview and Architecture 4-10
Login and Security Considerations 4-12
Administering Server Objects 4-16
Administering Service and Engine Objects 4-17
Administering Connector Objects 4-19
Administering Host Objects 4-20
Administering Context Objects 4-20
Administering Default Context Objects 4-21
Administering Logger Object 4-22
Administering Realm Objects 4-22
Administering Valve Objects 4-25
Administering Resources 4-26
Administering User Definition 4-28
Inconsistent Conditions 4-30
nsjspadmin.config ServerClass Configuration File
nsjspadmin.ssc 4-31
servlet ServerClass Restrictions 4-31
Access Security Considerations 4-31
iTP_server.xml Configuration File 4-32
4-31
5. Manager Web Application
Accessing the manager Web Application 5-1
Security Constraints 5-1
The manager GUI Interface 5-2
NSJSP Status Command 5-7
NSJSP Server Instance Detail 5-11
Cleaning Up the NonStop SQL Session Data 5-20
Managing Constraints 5-21
Shell Scripts 5-21
nsjsp_migrateSessionStore 5-21
nsjsp_digestPassword 5-22
nsjsp_cleanConfigBackups 5-22
6. Logs and Error Conditions
NSJSP Logging
6-1
iv
Contents
6. Logs and Error Conditions (continued)
6. Logs and Error Conditions (continued)
Logging Configuration 6-1
Switching From Multiple Log Files to a Single Log File
Switching From a Single Log File to Multiple Log Files
Status Information 6-4
Log Files Rollover 6-4
Log Files Cleanup Script 6-4
nsjsp_cleanlogs Syntax 6-5
nsjsp_cleanlogs Options 6-5
Recovery Procedure for Broadcast Error 6-5
Broadcast 6-5
Broadcast Error 6-6
Broadcast Failure 6-6
Causes of Broadcast Error/Failure 6-7
EMS Message Format 6-8
6-2
6-3
7. Migrating to NSJSP 5.0
NSJSP Environment 7-1
Installation 7-1
Directory Structure 7-1
Jar File Considerations 7-1
Configuration Considerations 7-2
servlet.config File 7-2
iTP_server.xml File 7-2
nsjspadmin.config File 7-2
filemaps.config File 7-2
jdbc.config File 7-2
Context Configuration 7-2
Configuring the Security Manager 7-3
Pre-Compiled JSPs 7-4
manager Web Application 7-4
Application Migration Considerations 7-4
Strict Rules on TagExtraInfo Classes 7-5
Persistent Sessions Database Changes 7-5
Persistent Session Classes Moved 7-6
Changes from Servlet 2.3 to Servlet 2.4 7-7
Changes from JSP 1.2 to JSP 2.0 7-12
v
8. Security Considerations
Contents
8. Security Considerations
Virtual Hosts 8-1
Roles 8-1
Single Sign-On 8-1
A. JMXProxy Servlet
JMX Query command A-1
JMX Set command A-1
B. Sample Ant Script for the Client Deployer
C. NSJSP Container Objects
Server Object C-1
Service Object C-2
Connector Object C-2
Engine Object C-5
Host Object C-6
Context and Default Context Objects
Loader Object C-11
Logger Object C-12
Manager Object C-13
Resources C-16
Data Sources C-17
Mail Sessions C-18
Environment Entries C-18
User Databases C-19
Resource Links C-21
Realm Object C-21
Valve Object C-27
C-7
Glossary
Index
Examples
Example 1-1.
Example 2-1.
Example 2-2.
Example 3-1.
Example 3-2.
JSP Code 1-11
The nsjsp_stop Script 2-8
Directory and Configuration Overview 2-11
Sample Server Directive Arglist 3-5
Configuration File nsjspadmin.config 3-7
vi
Examples (continued)
Contents
Example 3-3.
Example 3-4.
Example 3-5.
Example 3-6.
Example 3-7.
Example 3-8.
Example 3-9.
Example 3-10.
Example 3-11.
Example 3-12.
Example 3-13.
Example 3-14.
Example 3-15.
Example 3-16.
Example 3-17.
Example 3-18.
Example 3-19.
Example 3-20.
Example 3-21.
Example 3-22.
Example 3-23.
Example 3-24.
Example 3-25.
Example 3-26.
Example 3-27.
Example 3-28.
Example 3-29.
Example 3-30.
Example 3-31.
Example 3-33.
Example 3-32.
Example 3-34.
Example 3-35.
Example 3-36.
Example 4-1.
Example 5-1.
Example 5-2.
Example 5-3.
Basic Structure of iTP_server.xml 3-9
iTP_server.xml Statements 3-10
Setting the Context Path 3-10
Setting the Reloadable Attribute 3-11
Preloading Servlets 3-12
Defining a Session Timeout Value 3-12
Initializing Servlets 3-13
Sample Application Directory Structure on OSS 3-14
Deploying a Servlet 3-19
How to Set the MIME Type 3-19
Mapping a URL to the Servlet 3-21
Java Policy File Entry 3-21
Policy File Entry for the NSJSP Container 3-23
Starting NSJSP With a Security Manager 3-25
Troubleshooting the NSJSP Security Manager 3-26
Default Security Property File 3-27
Configuring Virtual Hosting 3-28
Adding an XML Element to Configure a Realm 3-29
Default User File Format 3-31
SQL Commands to Add Users and User Roles 3-32
SQLCI Commands to Create and Load the JDBCRealm 3-33
Using the SQL/MP Database to Specify JDBCRealm Attributes 3-35
LDBM Database Definitions 3-38
User and Role Definitions 3-39
Realm Element for the OpenLDAP Directory Server 3-40
Realm Element in the iTP Web Server Configuration File 3-42
DataSourceRealm 3-43
UserDatabaseRealm 3-44
Configuring Single Sign-On Support 3-47
Adding Extra Partitions to Support Persistent Sessions 3-50
SQL Script for Configuring Persistent Sessions 3-50
Adding Partitions Using the SQLCI ALTER TABLE Command 3-51
Using the NSJSPStandardManager 3-53
Using the NSJSPPersistentManager 3-58
Use of getAttribute() Method to Obtain Environment Variables 4-6
Message Box 5-4
NSJSP Status Summary Manager Area 5-9
NSJSP Status Summary Information Area 5-9
vii
Contents
Example 5-4.
Example 5-5.
Example 5-6.
Example 5-7.
Example 5-8.
Example 5-9.
Example 5-10.
Example 5-11.
Example 5-12.
Example 5-13.
Example 5-14.
Example 5-15.
Example 5-16.
Example 6-1.
Example 7-1.
Example B-1.
NSJSP Status Summary Server Processes Area 5-9
NSJSP Status Summary JVM Area 5-10
NSJSP Status (JVM) Statistics Detail Area 5-10
NSJSP Status Summary Connector Area 5-10
NSJSP Status (Connector) Statistics Detail Area 5-11
NSJSP Status ($Z5BA) Page 5-12
NSJSP Status ($Z5BA) Application List Area 5-15
NSJSP Status ($Z5BA) localhost/servlet_jsp/servlets-examples Web
Application Statistics Area 5-15
Complete NSJSP Status Page 5-17
Complete NSJSP Status Application List Area 5-19
Web Application Statistics Summary 5-19
SQL Session Data Cleanup Script 5-20
Using the nsjsp_cleanSessionData Script 5-20
Logger Configuration 6-2
Mapping Servlets in the Web Application Deployment Descriptor
(web.xml) 7-5
Sample Ant Script for the Client Deployer B-1
Figures
Figure 1-1.
Figure 1-2.
Figure 1-3.
Figure 1-4.
Figure 1-5.
Figure 1-6.
Figure 1-7.
Figure 4-1.
Figure 4-2.
Figure 4-3.
Figure 4-4.
Figure 4-5.
Figure 4-6.
Figure 4-7.
Figure 4-8.
Figure 4-9.
Figure 4-10.
Figure 4-11.
A J2EE Web Container With Two Applications 1-4
JSP Data Flows 1-5
A Basic NSJSP Model 1-8
A Model-View-Controller Design 1-9
iTP Secure WebServer Servlet Architecture 1-13
Admin User Interface 1-17
Manager User Interface 1-18
Operator Save Command 4-12
Operator Commit Changes Command 4-12
Admin Login page 4-13
Admin Initial page 4-14
Server Object View/Modify page 4-16
Service and Engine Object View/Modify page 4-17
Connector Object View/Modify page 4-19
Context Object View/Modify page 4-21
JAASRealm Object View/Modify page 4-23
Data Source View/Modify page 4-26
Users List page 4-28
viii
Figures (continued)
Contents
Figures (continued)
Figure 4-12.
Figure 5-1.
Figure 5-2.
Figure 5-3.
Figure 5-4.
Figure 5-5.
Figure 5-6.
Figure 5-7.
Figure 5-8.
Figure 7-1.
Inconsistent Warning 4-30
Manager Web Application Architecture 5-1
Manager Web Application Login Dialog 5-2
Manager Web Application User Interface 5-3
Manager Area 5-4
Application Area 5-5
Deploy Area 5-5
NSJSP Information Area 5-6
NSJSP Status Summary Page 5-8
New Persistent Session Class Location 7-6
Tables
Table 2-1.
NSJSP Directory Structure
2-9
ix
Contents
x
What’s New in This Manual
Manual Information
NonStop Servlets for JavaServer Pages (NSJSP) System Administrator’s Guide
Abstract
and JavaServer Pages (JSPs), which are platform-independent server-side programs
Product Version
Supported Release Version Updates (RVUs)
This guide supports G06 and all subsequent RVUs until otherwise indicated in a new
edition. For Parallel Library TCP/IP support you must be running G06.08 or later.
Part Number
Published
525644-002
December 2005
Document History
Part Number
Product Version
Published
525644-001
March 2003
525644-002
December 2005
This is a new manual, beginning with the NonStop Servlets for JavaServer Pages
(NSJSP) 5.0 RVU. This manual describes the following new features:
•
•
•
•
Support for the new J2EE specifications. NSJSP supports Java Servlet 2.4 and
JavaServer Pages 2.0 specifications (porting Tomcat 5.0.28).
Support for an optional standalone application deployer. NSJSP allows customer
web applications to be validated and compiled before they are used in a production
environment. For more information, see Deploy Using the Standalone Application
Deployer on page 3-16.
Support for complete server monitoring using JMX and the manager web
application. NSJSP allows you to monitor servers in real-time. For more
information, see Manager Web Application on page 5-1.
Improved taglibs handling. NSJSP supports JSP custom tag pooling, background
JSP compilation, and recompilation when pages are modified. For more
information, see Enhanced JSP Runtime Engine on page 1-14.
xi
What’s New in This Manual
•
•
•
•
•
•
•
•
•
Enhanced JSP runtime engine. NSJSP uses the new Jasper 2 JSP engine which
includes significant performance improvements over the original Jasper engine.
For more information, see Enhanced JSP Runtime Engine on page 1-14.
Support for an enhanced Security Manager. NSJSP allows you to configure which
NSJSP internal packages are protected against package definition and access.
This prevents non-trusted web applications from accessing sensitive NSJSP
internal packages. For more information, see Configuring the Security Manager on
page 3-21.
Support for JAASRealm. NSJSP includes support for the JAASRealm user
database. For more information, see JAASRealm on page 3-40.
Support for JMX based administration. NSJSP uses JMX technology to manage
internal objects (for example, Servers, Services, Hosts, Contexts, Loggers, and
other resource entities online). In prior releases, you were required to bring down
the entire container and change the configuration file iTP_server.xml to modify
container objects. Because objects can now be modified online, this change
enhances the NSJSP container's availability. For more information, see JMX
Based Administration on page 4-9.
Support for a new admin web application which provides a GUI interface for
administering container object and resource modifications using JMX MBeans. For
more information, see admin Web Application on page 4-10.
Support for a new manager web application which provides the management
functions for web applications in the NSJSP container. In prior releases, these
functions were provided using the nsjsp_manager (an interactive shell script).
For more information, see Manager Web Application on page 5-1.
Support for enhanced NSJSP connector component NSJSPCoyoteConnector.
The connector is managed using JMX MBeans. For more information, see
Enhanced NSJSPCoyoteConnector on page 1-19.
No provision for the support of session clustering. NSJSP does not implement
session clustering. Instead, the current session routing mechanism continues to be
used in NSJSP 5.0. For more information see Session Clustering (not supported)
on page 1-19.
Discontinuance of external support for NonStop EJB.
xii
About This Manual
This guide describes the installation, configuration, and management of the NonStop
Servlets for JavaServer Pages (NSJSP) 5.0 component of the iTP Secure WebServer.
Who Should Read This Guide
The NonStop Servlets for JavaServer Pages (NSJSP) System Administrator’s Guide is
intended for experienced HP NonStop system administrators and operators who need
to install, configure, and manage the iTP Secure WebServer on an HP NonStop
system.
The guide assumes that:
•
You are an experienced user of HP products and are specifically familiar with the
Open System Services (OSS) environment and the PATHCOM interface of
NonStop TS/MP.
The guide also assumes that you are familiar with:
•
•
•
•
•
The Common Gateway Interface (CGI/1.1) standard and the HyperText Transfer
Protocol (HTTP/1.1).
The Java language and tools.
Writing and using configuration scripts.
The TCP/IP family of protocols.
Network security and authentication techniques.
This guide also assumes that you have experience operating a secure computing
system. For an introduction to basic network security concepts, refer to the iTP Secure
WebServer System Administrator’s Guide.
If you need more information about HP NonStop systems, consult the following
publications before reading this guide:
•
G06.nn Release Version Update Compendium if you use an operating system
RVU starting with “G,” for example, G06.
xiii
About This Manual
Organization of This Guide
Organization of This Guide
Section 1, Overview and Architecture gives a general introduction to the Java 2
Enterprise Edition (J2EE) and discusses the architecture of NonStop Servlets for
JavaServer Pages (NSJSP).
Section 2, Installing NSJSP provides the procedures for installing NSJSP, including
what to do before you begin, starting and restarting NSJSP, stopping NSJSP, and
uninstalling NSJSP. This section also shows the post-installation NSJSP 5.0 directory
structure.
Section 3, Configuring NSJSP provides information on configuring the web container,
the web applications, the security manager, virtual hosting, realms, single sign-on
support, and persistent sessions.
Section 4, Programming and Management Features provides information on client
programming features and servlet programming features. This section also describes
the JMX based administration and the admin web application (GUI interface).
Section 5, Manager Web Application provides information on the manager web
application.
Section 6, Logs and Error Conditions provides information on logging and tracking
error conditions.
Section 7, Migrating to NSJSP 5.0 discusses considerations for migrating from a
previous NSJSP release to NSJSP 5.0 and provides information on changes from Java
Servlet 2.3 to the Java Servlet 2.4 version and changes from JavaServer Pages 1.2 to
the JavaServer Pages 2.0 version.
Section 8, Security Considerations discusses security sensitive applications and proper
security constraints that should be implemented.
The Glossary contains definitions of NSJSP and iTP Secure WebServer terms.
The Index contains references and cross-references to all major topics in this guide.
Related Manuals
Related iTP manuals:
•
•
The iTP Secure WebServer System Administrator’s Guide describes how to install,
configure, and manage the iTP Secure WebServer. It also discusses how to
develop and integrate Common Gateway Interface (CGI) applications and Java
Servlets and JSPs into an iTP Secure WebServer environment. This guide is
intended for experienced HP NonStop system administrators and operators who
need to install, configure, and manage the iTP Secure WebServer on an HP
NonStop system.
The iTP Secure WebServer Operator Messages Manual describes the operator
messages reported by components of the iTP Secure WebServer and related
xiv
About This Manual
TCP/IP Manuals
products. The audience for this manual is system managers and operators who will
monitor and control the operations of an iTP Secure WebServer environment.
The following manuals contain additional information about installing, configuring, and
managing HP NonStop systems or other products you can use with NSJSP.
TCP/IP Manuals
For information specific to managing the TCP/IP subsystem, refer to the following
manuals:
•
•
•
•
The TCP/IP Configuration and Management Manual describes the installation,
configuration, and management of the NonStop TCP/IP subsystem. It is for system
managers, operators, and others who require a basic understanding of the HP
TCP/IP implementation.
The TCP/IP (Parallel Library) Configuration and Management Manual describes
how to configure and manage the Parallel Library TCP/IP subsystem. Use this
manual to configure Parallel Library TCP/IP on your system in conjunction with the
TCP/IP (Parallel Library) Migration Guide.
The TCP/IP (Parallel Library) Migration Guide lists migration considerations that
could affect your configuration.
The TCP/IP and IPX/SPX Programming Manual describes the programmatic
interface to the TCP/IP data communications software.
Open System Services (OSS) Manuals
For information specific to the OSS environment, refer to the following manuals:
•
•
•
The Open System Services User’s Guide describes the Open System Services
(OSS) environment: the shell, file-system, and user commands.
The Open System Services Installation Guide describes how to install and
configure the HP NonStop Kernel OSS environment.
The Open System Services Management and Operations Guide describes how to
manage and operate the NonStop Kernel OSS environment.
NonStop Transaction Services/MP (NonStop TS/MP) Manuals
For information specific to managing PATHMON environments, refer to the following
manuals:
•
The TS/MP System Management Manual discusses the PATHCOM and TACL
commands used to configure and manage PATHMON environments. This manual
also includes manageability guidelines, information about monitoring and tuning a
PATHMON environment to optimize performance, and methods for diagnosing and
correcting problems.
xv
About This Manual
•
NonStop Java Manuals
The TS/MP Management Programming Manual describes how to start, configure,
and manage PATHMON environments programmatically and describes the event
messages that report errors and other occurrences of interest to operators.
NonStop Java Manuals
For information about the features of the NonStop Server for Java, or if you plan to use
JDBC, refer to the following HP manual:
•
NonStop Server for Java (NSJ) Programmer’s Guide
NonStop SQL Manuals
For information specific to the NonStop SQL environment, refer to the following
manuals:
•
•
The SQL/MP Reference Manual describes NonStop SQL/MP, the HP relational
database management system that uses SQL to describe and manipulate data in a
NonStop SQL/MP database. The manual includes information about SQLCI, the
conversational interface to NonStop SQL/MP.
The SQL/MX Reference Manual describes SQL language elements—data types,
literals, expressions, functions, and predicates—and SQL statements of NonStop
SQL/MX, the HP relational database management system based on ANSI SQL-92.
It also includes MXCI commands.
Other Related Manuals
The following manuals contain additional information about NonStop systems:
•
•
The G06.nn Release Version Update Compendium provides an overview of the
hardware and software supported for G-series systems and describes how to plan
for the migration to a G-series system. It is for system managers or anyone who
needs to understand how migrating or upgrading to a G-series RVU affects
installation, configuration, operations, system management, maintenance, and the
migration of applications, networks, and database files.
The NonStop S-Series Planning and Configuration Guide describes how to plan
and configure a NonStop S-series server and provides a case study documenting
a sample system. This guide describes the ServerNet system area network
(ServerNet SAN), the available hardware and software configurations for NonStop
S-series servers, site planning and preparation, creating the operational
environment, and making hardware and software configuration changes to an
existing server. This guide is for the personnel responsible for planning the
installation, configuration, and maintenance of the server and the software
environment at a particular site.
This book is useful for anyone who has to administer a UNIX system attached to a
TCP/IP network.
xvi
About This Manual
The following URL references are available on the Internet:
•
•
•
•
•
•
General references:
http://www.w3.org
HyperText Transfer Protocol (HTTP) references:
http://www.w3.org/Protocols/rfc2616/rfc2616.txt
Common Gateway Interface (CGI) references:
http://hoohoo.ncsa.uiuc.edu/cgi
Tomcat 5.0 Documentation:
http://jakata.apache.org/tomcat/tomcat-5.0-doc/index.html
Java Servlet Specification Version 2.4:
http://java.sun.com/products/servlet/
JavaServer Pages API Specification Version 2.0:
http://java.sun.com/products/jsp/
xvii
About This Manual
Notation Conventions
Notation Conventions
Hypertext Links
Blue underline is used to indicate a hypertext link within text. By clicking a passage of
text with a blue underline, you are taken to the location described. For example:
This requirement is described under Backup DAM Volumes and Physical Disk
Drives on page 3-2.
General Syntax Notation
This list summarizes the notation conventions for syntax presentation in this manual.
UPPERCASE LETTERS. Uppercase letters indicate keywords and reserved words. Type
these items exactly as shown. Items not enclosed in brackets are required. For
example:
MAXATTACH
lowercase italic letters. Lowercase italic letters indicate variable items that you supply.
Items not enclosed in brackets are required. For example:
file-name
computer type. Computer type letters within text indicate C and Open System Services
(OSS) keywords and reserved words. Type these items exactly as shown. Items not
enclosed in brackets are required. For example:
myfile.c
italic computer type. Italic computer type letters within text indicate C and Open
System Services (OSS) variable items that you supply. Items not enclosed in brackets
are required. For example:
pathname
[ ] Brackets. Brackets enclose optional syntax items. For example:
TERM [\system-name.]$terminal-name
INT[ERRUPTS]
A group of items enclosed in brackets is a list from which you can choose one item or
none. The items in the list can be arranged either vertically, with aligned brackets on
each side of the list, or horizontally, enclosed in a pair of brackets and separated by
vertical lines. For example:
FC [ num ]
[ -num ]
[ text ]
K [ X | D ] address
xviii
About This Manual
General Syntax Notation
{ } Braces. A group of items enclosed in braces is a list from which you are required to
choose one item. The items in the list can be arranged either vertically, with aligned
braces on each side of the list, or horizontally, enclosed in a pair of braces and
separated by vertical lines. For example:
LISTOPENS PROCESS { $appl-mgr-name }
{ $process-name }
ALLOWSU { ON | OFF }
| Vertical Line. A vertical line separates alternatives in a horizontal list that is enclosed in
brackets or braces. For example:
INSPECT { OFF | ON | SAVEABEND }
… Ellipsis. An ellipsis immediately following a pair of brackets or braces indicates that you
can repeat the enclosed sequence of syntax items any number of times. For example:
M address [ , new-value ]…
[ - ] {0|1|2|3|4|5|6|7|8|9}…
An ellipsis immediately following a single syntax item indicates that you can repeat that
syntax item any number of times. For example:
"s-char…"
Punctuation. Parentheses, commas, semicolons, and other symbols not previously
described must be typed as shown. For example:
error := NEXTFILENAME ( file-name ) ;
LISTOPENS SU $process-name.#su-name
Quotation marks around a symbol such as a bracket or brace indicate the symbol is a
required character that you must type as shown. For example:
"[" repetition-constant-list "]"
Item Spacing. Spaces shown between items are required unless one of the items is a
punctuation symbol such as a parenthesis or a comma. For example:
CALL STEPMOM ( process-id ) ;
If there is no space between two items, spaces are not permitted. In this example, no
spaces are permitted between the period and any other items:
$process-name.#su-name
Line Spacing. If the syntax of a command is too long to fit on a single line, each
continuation line is indented three spaces and is separated from the preceding line by
xix
Notation for Messages
About This Manual
a blank line. This spacing distinguishes items in a continuation line from items in a
vertical list of selections. For example:
ALTER [ / OUT file-spec / ] LINE
[ , attribute-spec ]…
!i and !o. In procedure calls, the !i notation follows an input parameter (one that passes data
to the called procedure); the !o notation follows an output parameter (one that returns
data to the calling program). For example:
CALL CHECKRESIZESEGMENT (
segment-id
, error
) ;
!i
!o
!i,o. In procedure calls, the !i,o notation follows an input/output parameter (one that both
passes data to the called procedure and returns data to the calling program). For
example:
error := COMPRESSEDIT ( filenum ) ;
!i:i.
!i,o
In procedure calls, the !i:i notation follows an input string parameter that has a
corresponding parameter specifying the length of the string in bytes. For example:
error := FILENAME_COMPARE_ (
filename1:length
, filename2:length ) ;
!i:i
!i:i
!o:i. In procedure calls, the !o:i notation follows an output buffer parameter that has a
corresponding input parameter specifying the maximum length of the output buffer in
bytes. For example:
error := FILE_GETINFO_ (
filenum
, [ filename:maxlen ] ) ;
!i
!o:i
Notation for Messages
This list summarizes the notation conventions for the presentation of displayed
messages in this manual.
Bold Text. Bold text in an example indicates user input typed at the terminal. For example:
ENTER RUN CODE
?123
CODE RECEIVED:
123.00
The user must press the Return key after typing the input.
Nonitalic text. Nonitalic letters, numbers, and punctuation indicate text that is displayed or
returned exactly as shown. For example:
Backup Up.
xx
About This Manual
Notation for Management Programming Interfaces
lowercase italic letters. Lowercase italic letters indicate variable items whose values are
displayed or returned. For example:
p-register
process-name
[ ] Brackets. Brackets enclose items that are sometimes, but not always, displayed. For
example:
Event number = number [ Subject = first-subject-value ]
A group of items enclosed in brackets is a list of all possible items that can be
displayed, of which one or none might actually be displayed. The items in the list can
be arranged either vertically, with aligned brackets on each side of the list, or
horizontally, enclosed in a pair of brackets and separated by vertical lines. For
example:
proc-name trapped [ in SQL | in SQL file system ]
{ } Braces. A group of items enclosed in braces is a list of all possible items that can be
displayed, of which one is actually displayed. The items in the list can be arranged
either vertically, with aligned braces on each side of the list, or horizontally, enclosed in
a pair of braces and separated by vertical lines. For example:
obj-type obj-name state changed to state, caused by
{ Object | Operator | Service }
process-name State changed from old-objstate to objstate
{ Operator Request. }
{ Unknown.
}
| Vertical Line. A vertical line separates alternatives in a horizontal list that is enclosed in
brackets or braces. For example:
Transfer status: { OK | Failed }
% Percent Sign. A percent sign precedes a number that is not in decimal notation. The
% notation precedes an octal number. The %B notation precedes a binary number.
The %H notation precedes a hexadecimal number. For example:
%005400
%B101111
%H2F
P=%p-register E=%e-register
This list summarizes the notation conventions used in the boxed descriptions of
programmatic commands, event messages, and error lists in this manual.
xxi
About This Manual
UPPERCASE LETTERS. Uppercase letters indicate names from definition files. Type
these names exactly as shown. For example:
ZCOM-TKN-SUBJ-SERV
lowercase letters. Words in lowercase letters are words that are part of the notation,
including Data Definition Language (DDL) keywords. For example:
token-type
!r.
The !r notation following a token or field name indicates that the token or field is
required. For example:
ZCOM-TKN-OBJNAME
!o.
token-type ZSPI-TYP-STRING.
!r
The !o notation following a token or field name indicates that the token or field is
optional. For example:
ZSPI-TKN-MANAGER
token-type ZSPI-TYP-FNAME32.
!o
xxii
About This Manual
Abbreviations
Abbreviations
The following list defines abbreviations and acronyms used in this guide. Both industrystandard terms and HP terms are included.
AWT. Abstract Windowing Toolkit
ARPA. Advanced Research Project Agency
ATP. Active Transaction Pages
BSD. Berkeley Software Distribution
C.
Country
CA. Certificate Authority
CBC. Cipher Block Chaining
CCITT. Consultative Committee for International Telegraph and Telephone
CGI. Common Gateway Interface
CN. Common Name
CWD. Current Working Directory
DES. Data Encryption Standard
DN. Distinguished Name
DNS. Domain Name Server
DTD. Document Type Definition
EAS. Enterprise Application Server
EMS. Event Management Service
FBA. Forms Based Administration
FTP. File Transfer Protocol
GIF. Graphics Interchange Format
GUI. Graphical User Interface
HTML. HyperText Markup Language
HTTP. HyperText Transfer Protocol
xxiii
About This Manual
Abbreviations
HTTPD. HyperText Transfer Protocol Daemon
IEEE. Institute of Electrical and Electronics Engineers
IEN. Internet Engineering Note
IP.
Internet Protocol
J2EE. Java 2 Enterprise Edition
JAR. Java Archive Tool
JDBC. Java DataBase Connectivity
JDK. Java Development Kit
JIT. Just-In-Time (Java compiler)
JNDI. Java Naming and Directory Interface
JNI. Java Native Interface
JSP. JavaServer Pages
JVCP. Java Visual Class Package
JVM. Java Virtual Machine
KEK. Key Exchange Key
L.
Locality
LAN. Local Area Network
LDAP. Lightweight Directory Access Protocol
LDIF. LDAP Data Interchange Format
MAC. Message Authentication Code
MD5. Message Digest
MFK. Master File Key
MIME. Multipurpose Internet Mail Extensions
NCSA. National Center for Supercomputing Applications
NSJ. NonStop Java
NSJSP. NonStop Servlets for JavaServer Pages
xxiv
About This Manual
O.
Abbreviations
Organization
OLTP. Online Transaction Processing
OSS. Open System Services
OU. Organizational Unit
PAID. Process Accessor ID
PCT. Private Communication Technology
PDF. Portable Document Format
PEM. Privacy Enhanced Message
PKS. Public Key Certificate Standard
PPP. Point to Point Protocol
QIO. Queued Input Output
RFC. Request for Comments
RLS. Resource Locator Service
RSA. Rivest, Shamir, and Adelman
SCF. Subsystem Control Facility
SCT. Secure Configuration Terminal
SGC. Server Gated Cryptography (Microsoft)
SGML. Standard Generalized Markup Language
SHA1. Secure Hash Algorithm
SI.
Session Identifier
SLIP. Serial Line IP
SMTP. Simple Mail Transfer Protocol
SSC. Servlet ServerClass (for Java)
SSI. Server Side Include
SSL. Secure Sockets Layer
ST.
State
xxv
About This Manual
Abbreviations
TACL. Tandem Advanced Command Language
TAL. Transaction Application Language
Tcl. Tool Command Language
Tcl/CGI. Tool Command Language/Common Gateway Interface
TCP/IP. Transmission Control Protocol/Internet Protocol
TS/MP. Transaction Services/Massively Parallel
URL. Uniform Resource Locator
WAR. Web Archive
WID. WebSafe2 Interface Driver
WISP. WebSafe2 Internet Security Processor
X.509. CCITT Recommendation for Security Service
XML. Extended Markup Language
xxvi
1
Overview and Architecture
This section describes:
•
•
•
•
Java 2 Enterprise Edition (J2EE) Overview on page 1-3
JavaServer Pages (JSP) Architecture on page 1-7
NonStop Servlets for JavaServer Pages (NSJSP) Architecture on page 1-12
New Features in the HP NSJSP Implementation on page 1-14
and JavaServer Pages (JSPs), which are platform-independent, server-side programs
The HP implementation of NSJSP 5.0 (HP product number T1222) is based on Tomcat
5.0.28 and runs with the iTP Secure WebServer 6.0 (SPR ABV or later). NSJSP
implements the Java Servlet 2.4 and the JavaServer Pages 2.0 specifications. The
official reference implementation for the Java Servlet 2.4 and JavaServer Pages 2.0
specifications is developed and maintained by the Jakarta Project at
http://jakarta.apache.org/ of the Apache Foundation.
NSJSP includes the following new features and improvements:
•
•
•
•
•
•
J2EE standards support
•
Java Servlet 2.4 and JavaServer Pages 2.0 specifications
Performance optimizations and reduced garbage collection
An optional standalone application deployer
Complete server monitoring using JMX technology and the manager web
application
Improved taglibs handling (including advanced pooling and tag plugins)
Enhanced Security Manager support
For more detailed information, see the Tomcat 5.0 documentation at
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/index.html.
NSJSP 5.0 also incorporates the JMX based administration application as well as the
HTML-based manager application.
Note. NSJSP 5.0 uses MX4J from SourceForge.net which is a JMX reference implementation
based on Sun’s JMX specifications. For more information, see
http://sourceforge.net/projects/mx4j.
For details about migrating from previous NSJSP releases to NSJSP 5.0, refer to
Section 7, Migrating to NSJSP 5.0.
1 -1
To use this documentation, you should have some familiarity with the Java language
and tools and the Java Servlet Application Programming Interface (API) as defined by
JSR 154: Java 2.4 Specifications. This section does not attempt to teach you how to
program servlets or JSPs, although it does offer advice and ideas.
You also should be familiar with the overall iTP Secure WebServer environment, which
must be installed and running before you can install and use NSJSP.
1 -2
Java 2 Enterprise Edition (J2EE) Overview
Java 2 Enterprise Edition (J2EE) Overview
This subsection summarizes the following topics:
•
•
•
•
•
•
The Web Container on page 1-3
JavaServer Pages (JSP) on page 1-4
The Web Application on page 1-5
The WEB-INF Subdirectory on page 1-6
The Deployment Descriptor on page 1-6
Web Archive (WAR) Files on page 1-6
J2EE defines the standard for developing and running applications in a multi-tier
architecture.
The iTP WebServer implementation of servlets and JSP is a key component for J2EE
compliance. For an overview of all the other components of a complete J2EE
environment, consult the Sun Microsystems J2EE website.
The J2EE architecture has two types of client: web clients and application clients.
Application clients belong to the client-server model where the “fat” client provides not
only the GUI, but also most of the application logic. Web clients, belong to a newer
three-tier model where the “thin” client (typically a browser) supplies the GUI, and a
middleware layer, on a Webserver, provides the application logic between the GUI and
the database. The middleware layer itself is now typically based on reusable
components designed in a Model-View-Controller architecture. For an introduction to
this concept, see Model-View-Controller Designs on page 1-7.
The web client model typically uses HTTP to provide a request-response relationship
between the browser and the application logic. The client Resource Locator (URL) —
for example www.company.com/index.html — consists of the domain name —
www.company.com — and the Universal Resource Identifier (URI), the name of the
resource, in this case index.html. The URI provides the context path that is used to
locate servlets (see Map Requests to Applications and Servlets on page 3-20).
Initially, HTTP resources were static pages of text or graphics, the same resource
being served to each client request, but now the emphasis is on building and using
dynamic resources where the same resource can be dynamically modified for each
different client request. For example, consider a mailbox, where the structure and
function is the same, but the content is clearly different for each user.
Dynamic content was initially supplied by CGI, but now the more powerful and flexible
Java Servlet API and JSP programs provide logic for the new web applications.
The Web Container
For building and running web-based applications, J2EE provides a web container,
which is a Java runtime environment that has the following content:
1 -3
JavaServer Pages (JSP)
•
•
•
The applications, including Java servlets and JavaServer Pages, class libraries,
resources such as HTML or XML documents, and images.
The Servlet API and runtime management including initializing, invoking, and
managing the Servlet and JSP lifecycles.
The deployment descriptors (the web.xml file) that contain resource definitions
such as MIME types, mapping of requests to servlets, access control, and servlet
initialization parameters.
The web container instantiates the servlet and provides the communication between
the iTP WebServer and the servlet. Specifically, the web container:
•
•
•
•
•
•
Instantiates the servlet
Invokes the servlet’s init() method
Requests services from the user by invoking the service() method
Invokes the destroy() method when the servlet is to be garbage-collected
Manages a similar lifecycle for JSP files
Deploys and creates WAR (web archive) files
Figure 1-1. A J2EE Web Container With Two Applications
WEB CONTAINER
APPLICATION # 1
DEPLOYMENT
DESCRIPTOR
APPLICATION # 2
DEPLOYMENT
DESCRIPTOR
JAVA
SERVLETS
JAVA
SERVLETS
JAVA
CLASSES
JAVA
CLASSES
JSP
PAGES
JSP
PAGES
VST901.vsd
JavaServer Pages (JSP)
JavaServer Pages (JSP), a presentation-layer technology that sits on top of the Java
servlets model, simplifies the creation and management of dynamic HTML. JSP uses a
component-based rather than a page-based approach to development. In page-based
1 -4
The Web Application
design, the web page combines the presentation material usually created by designers
with the business logic usually created by programmers.
By separating the user interface from content generation, JSP allows page designers
to change the page layout without altering the underlying programmable dynamic
content. Furthermore, the programmable content, or business logic, can be written in
the form of reusable components such as Java Beans. This separation of the page
logic from its display and the support for a reusable component-based design makes
JSP a fast and easy way to build web-based applications.
JavaServer Pages use XML-like tags and scriptlets written in the Java programming
language to encapsulate the logic that generates the content for the page. Additionally,
the application logic can reside in server-based resources, Java Beans, that the page
accesses by using these tags and scriptlets. All formatting (HTML or XML) tags are
passed directly back to the response page. The underlying JSP engine (actually a
specialized servlet itself) transforms JSP tags, scriptlets, and HTML into Java code
which is organized as a Java servlet. This servlet is compiled as Java bytecode, so the
page does not need to be interpreted every time it is requested. The code is
recompiled automatically if the page is changed. A high-level view of JSP is shown in
Figure 1-2, JSP Data Flows.
Figure 1-2. JSP Data Flows
First Time Use
JSP Page
Compilation
Client Browser
iTP WebServer
Subsequent Use
Component
Java Servlet
VST902.vsd
The Web Application
The web application is a collection of servlets, HTML pages, images, JSPs, a
deployment descriptor, and other configuration files that together represent all the
resources necessary to host a complete application on a J2EE-compliant webserver.
NonStop Servlets for JavaServer Pages (NSJSP) System Administrator’s Guide—525644-002
1 -5
The WEB-INF Subdirectory
Web applications should be located in a directory (typically called webapps) under the
root directory of the container engine (default for the root for NSJSP is
/usr/tandem/webserver/servlet_jsp).
Assume you have an application called myapp1 and that one of the servlets in that
application is called helloworld.
The directory structure to myapp1 would be
/servlet_jsp/webapps/myapp1
where myapp1 is the name of your web application directory.
At this level you can store files such index.html, or create subdirectories to manage
your web application resources, for example, /images for graphics files.
The WEB-INF Subdirectory
The WEB-INF subdirectory contains private files, that is, files that cannot be directly
served to the user for rendering by the browser. These files are typically Java class
files. To deploy any servlets, you must create the WEB-INF subdirectory. This directory
contains the /classes subdirectory where you store the compiled classes, the /lib
subdirectory (containing the zip or jar files), and your customized version of the
web.xml file – the deployment descriptor.
webapps/myapp1/WEB-INF/web.xml
webapps/myapp1/WEB-INF/classes/helloworld.class
webapps/myapp1/WEB-INF/lib
A detailed description of the directory structure can be found in Configuring Web
Applications on page 3-14.
The Deployment Descriptor
A default version of web.xml sets the basic configuration for a context and MIME
types for all servlets, and can also preload and start up servlets when the web
container is first started. If you have a custom web.xml file for your particular servlet
or JSP, that custom file overrides the default.
In NSJSP, the default version of web.xml is located in the following directory:
/usr/tandem/webserver/servlet_jsp/conf
Web Archive (WAR) Files
The web application can be packaged into a web archive (WAR) file to provide a
simplified means of distributing Java class files and related resources as a single
deployment unit.
1 -6
JavaServer Pages (JSP) Architecture
For example, to create a WAR file for the application /myapp1 go to the root of the
application.
cd /usr/tandem/webserver/servlet_jsp/webapps/myapp1
The following command packs all the files and subdirectories into a single file called
myapp1.war. The -c option creates a new archive, the -f option specifies the target file
name, and the -v (verbose) option echoes the files to your display.
jar -cf myapp1.war *
To view the contents of an existing WAR file, type:
jar -tvf myapp1.war
To deploy a WAR file, see Add a New Web Application on page 3-15.
JavaServer Pages (JSP) Architecture
This subsection discusses
•
•
•
The reasons for using distributed servlets
How to include one servlet within another
How to forward responses between servlets
Simple examples of JSP code are annotated.
A general introduction to JSP is given in JavaServer Pages (JSP) on page 1-4. This
section introduces implementation, models, and syntax basics. For full details consult
the Sun Microsystems Java website, http://java.sun.com/products/jsp.
Typically, JSP pages are subject to a translation phase and a request-processing
phase. The translation phase is carried out once (unless the page changes) when the
JSP page is requested for the first time or when it is precompiled. The result is a JSP
page implementation class file that implements the servlet interface.
The JSP page implementation class file extends HttpJspBase, which in turn
implements the servlet interface. The service method of this class, _jspService(),
essentially inlines the contents of the JSP page. Although the _jspService cannot
be overridden, you can handle initialize and destroy events by providing
implementations for the jspInit() and jspDestroy() methods within your own
pages. When the class file is loaded within the web container, the _jspService()
method replies to a client request. By default, the _jspService() method is
dispatched on a separate thread by the web container when processing concurrent
client requests.
Model-View-Controller Designs
There are two design philosophies for JSP usage. The approaches differ in terms of
where most of the processing takes place. In the first approach, shown in Figure 1-3, A
Basic NSJSP Model, the incoming request from a web browser is sent directly to the
1 -7
JSP page that processes the request and replies to the client. Content is separated
from presentation because data access is performed using Java Beans.
This approach works well for simple applications, but requires that all request
processing occurs in the JSP page, making each page individually responsible for
managing the application state, verifying authentication, and maintaining security.
Figure 1-3. A Basic NSJSP Model
WEB CONTAINER
CLIENT
BROWSER
REQ
1
RES
4
JSP
2
Java Bean
or Java Servlet
3
Data Storage
VST904.vsd
1 -8
The second approach is to adopt the design, shown in Figure 1-4, A Model-ViewController Design. In this design, processing is divided between the controller and
presentation components. The presentation component, or View, consists of JSP
pages that generate the HTML or XML response that determines the user interface
rendered by the browser. The controller (a servlet or JSP page) is a front-end that is
not concerned with presentation, just the processing of HTTP requests. The controller
instantiates Java Beans and other objects to be used by the presentation component.
The MVC design has two advantages. First, no processing logic exists in the
presentation component; it simply retrieves objects or Java Beans created by the
controller and extracts the dynamic content for insertion in the JSP static templates.
Creating clear separation of presentation and content the controller presents a single
point of entry into the application, the management of state and security is easy.
Figure 1-4. A Model-View-Controller Design
WEB CONTAINER
REQ
1
Controller
Servlet
CLIENT
BROWSER
2
3
4
RES
JSP
5
View
3
Java Bean
or Java Servlet
4
Data Storage
Model
VST905.vsd
The MVC design is easily implemented using the request dispatcher, which allows one
servlet to use the services of another servlet by including or by forwarding. For
including, response of a servlet can include the output of another servlet. The included
servlet can only send output to the client; it cannot alter the header information. For
forwarding, the original servlet cannot send output to the client, instead the servlet
forwards the request and the response to another servlet.
Three programming steps are involved:
1. Obtain a reference to the servlet context by invoking getServletContext().
The return value is a javax.servlet.ServletContext object, which contains
several methods for the servlet to communicate with the container.
1 -9
JSP Syntax Basics
2. Obtain a reference to the request dispatcher object for the servlet in use. Use the
getRequestDispatcher(String name) method, which takes in the path and
name of the servlet (URI) and returns the request dispatcher object.
3. Invoke the include or forward method of the RequestDispatcher object. Either
method takes two arguments; the HttpServletRequest and
HttpServletResponse objects.
Sample code for a simple JSP include directive is shown in An Example of JSP Code
on page 1-10.
JSP Syntax Basics
JSP syntax has two main classifications: directives and scripting elements (such as
declarations, expressions, and scriptlets).
Directives
The Page Directive. This directive is a JSP tag used in almost every JSP source file.
The page directive gives instructions to the JSP container that apply to the entire JSP
source file. For example, a page directive can include comments that will become part
of the compiled JSP file or the scripting language used in the JSP source file,
packages the source file would import, or the error page called if an error or exception
occurs.
The Include Directive. This directive inserts the contents of another file in the main
JSP file, where the directive is located. You can use the include directive for including
copyright information, scripting language files, or anything you might want to reuse in
other applications. The include directive allows you to separate your content into
manageable elements such as including a common page header or footer. The page
included can be a static HTML page or more JSP content.
Scripting Elements
Declarations. Declarations allow you to define methods or variables in a JSP page
that will be accessible to other code within the same page.
Expressions. Expressions are simple JSP tags that convert the value of an
expression defined between <%= %> into a string and emits that value as dynamically
generated text. Expressions are shortcuts for generating text so that you do not have
to call the println() method to display text.
Scriptlets. You can write Java code anywhere in a JSP page, in the form <% code
%>. By using the import attribute of the page directive you have access to all Java
APIs from within your scriptlet code.
An Example of JSP Code
Example 1-1 shows the use of templating, a common technique used in web-page
development, which uses the services of more than one servlet. In this example, the
1-10
An Example of JSP Code
template is coded as JSP using the include directive to reference some HTML in
another file.
Example 1-1. JSP Code
<%-- Filename: "TemplateDemo.jsp" --%>
<HTML>
<BODY>
<CENTER> Welcome To My WebSite</CENTER>
<BR>
<P> The time is <% new java.util.Date().toString() %> </P>
<%@ include file = "Body.html" %>
</BODY>
</HTML>
_____________________________________________________________________________
The HTML file called Body is:
<BR>
<H1>
This is text that will be included in the body of the HTML in the JSP file
</H1>
<BR>
1-11
NonStop Servlets for JavaServer Pages (NSJSP)
Architecture
NonStop Servlets for JavaServer Pages
(NSJSP) Architecture
This subsection contains background information about the NonStop Servlets for
JavaServer Pages (NSJSP) architecture. It illustrates and discusses the relationships
between HTML clients, iTP Secure WebServer processes, and the NSJSP
environment. It also describes the lifecycle of a servlet and the benefits of running
servlets in NonStop TS/MP ServerClasses.
The NSJSP implementation is a multi-threaded, out-of-process servlet container: a
Java web container (with web applications) that runs in a Java Virtual Machine (JVM)
outside of the iTP Secure WebServer HTTPD process. This architecture is shown in
Figure 1-5, iTP Secure WebServer Servlet Architecture.
In essence, NSJSP provides the same JVM functionality as any other J2EE
implementation, but is unique in its ability to scale across multiple CPUs to provide a
scalable NSJSP computing environment.
Each web container can contain a number of applications, each with their own servlets,
JSP, and other resources. These containers are accessible by any HTTPD process
running on any CPU. The containers and the HTTPD processes are part of the
NonStop TS/MP environment.
1-12
Architecture
The iTP Secure WebServer software, which is inherently scalable and reliable, enables
the creation of Java servlets that can take advantage of the database and transaction
services infrastructure on the HP NonStop server. Java servlets run in a NSJSP
container that is implemented as a NonStop TS/MP ServerClass that can be replicated
and automatically load-balanced across multiple processor nodes for scalability
throughput. Consequently, large volumes of servlet-based web transactions can be run
concurrently to maintain consistent response times.
Figure 1-5. iTP Secure WebServer Servlet Architecture
NonStop CPU 0
WEB CONTAINER
WEB CONTAINER
WEB CONTAINER
NonStop CPU 1
NonStop CPU n
WEB CONTAINER
WEB CONTAINER
WEB CONTAINER
WEB CONTAINER
WEB CONTAINER
WEB CONTAINER
JSP Pages
JSP Pages
JSP Pages
Servlets
Servlets
Servlets
iTP WebServer
TCP/IP/PL
iTP WebServer
iTP WebServer
TCP/IP/PL
TCP/IP/PL
FESA, E4SA
or GESA
SERVERNET
I/O
VST903.vsd
1-13
New Features in the HP NSJSP Implementation
New Features in the HP NSJSP Implementation
New features incorporated in the HP NSJSP implementation are described below:
J2EE Standards Support
NSJSP 5.0 implements the Java Servlet 2.4 and JavaServer Pages 2.0 specifications
by porting Tomcat version 5.0.28. For more information about Tomcat version 5.0, see
the Apache Jakarta Tomcat 5 Servlet/JSP Container documentation at
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/index.html.
Standalone Application Deployer
NSJSP 5.0 supports a standalone application deployer. In prior versions of NSJSP,
various forms of application deployment (such as, static deployment and dynamic
deployment) have existed. In NSJSP 5.0, a client deployer is supported which
validates, compiles, and deploys a web application to a live NSJSP container.
Customer web applications can now be validated and compiled before they are placed
in a production environment.
For more information about using the standalone application deployer, see Deploy
Using the Standalone Application Deployer on page 3-16.
For more information about the client deployer, see the documentation at
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/deployer-howto.html.
Complete Server Monitoring
NSJSP 5.0 supports complete server monitoring. You can monitor NSJSP servers in
real-time. Using JMX technology and the manager web application, a complete server
status reports the status of each web application as well as its associated statistics
counters in the entire container. Using the manager web application, you can query for
the following status information:
•
•
•
•
•
The current status of the NSJSP container
The status of an individual NSJSP ServerClass process
Summary of statistics information of the NSJSP container
Summary of statistics information of an individual NSJSP ServerClass process
The detailed statistics information of an individual NSJSP ServerClass process
For more information about server monitoring, see Section 5, Manager Web
Application.
Enhanced JSP Runtime Engine
NSJSP 5.0 uses the Jasper 2 JSP Engine to implement the JavaServer Pages 2.0
specification. Jasper 2 has been redesigned to improve performance over the original
1-14
JAASRealm Support
Jasper engine. In addition to general code improvements, the following changes have
been made:
•
•
•
JSP custom tag pooling. The Java objects instantiated for JSP custom tags can
be pooled and reused. This arrangement significantly boosts the performance of
JSP pages which use custom tags.
Background JSP compilation. If you make a change to a previously compiled
JSP page, Jasper 2 can recompile that page in the background. The previously
compiled JSP page is still available to serve requests until the new page has been
compiled successfully. This arrangement improves availablity of your JSP pages in
a production environment.
Recompile JSP when included page changes. Jasper 2 detects when a page
included at compile time from a JSP has changed and then recompiles the parent
JSP.
For more information about these functions, see the documentation at
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/jasper-howto.html.
JAASRealm Support
A Realm is a user database which stores user names and associated passwords for
validating users. JAASRealm is an implementation of the NSJSP Realm interface that
authenticates users through the Java Authentication & Authorization Service (JAAS)
framework. The JAAS package is fully integrated in J2SE version 1.4 and is available
in NSJ 4.0 and later versions.
NSJSP supports the JAASRealm interface, in addition to the already supported
DataSourceRealm, JDBCRealm, JNDIRealm, MemoryRealm, and UserDatabase
Realm.
The JAASRealm interface also supports an NSJSP provided NonStop specific
LoginModule (NonStopLoginModule). For more information about JAASRealm and
using the NonStopLoginModule, see JAASRealm on page 3-40.
Enhanced Security Manager Support
NSJSP 5.0 supports enhanced security by allowing you to configure which NSJSP
internal packages are protected against package definition and access. This
arrangement prevents a non-trusted application from accessing sensitive NSJSP
internal packages. For more information about JAASRealm and using the
NonStopLoginModule.
For more information about the security manager, see the documentation at
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/security-manager-howto.html.
1-15
JMX Based Administration Feature
JMX Based Administration Feature
NSJSP supports JMX based administration. NSJSP incorporates JMX technology to
manage internal objects (for example, Servers, Services, Hosts, Contexts, Loggers,
and other resource entities).
In prior releases, NSJSP required you to bring down the entire container and change
the configuration file iTP_server.xml to modify container objects. With the support
of JMX MBeans for manageability, objects can now be modified while the container is
running. This arrangement enhances the NSJSP container's availability.
For more information about administering container objects online, see JMX Based
Administration on page 4-9.
For more information about JMX MBeans, see the Apache Jakarta Tomcat 5
Servlet/JSP Container documentation at http://jakarta.apache.org/tomcat/tomcat-5.0doc/index.html.
admin Web Application
The admin web application provides a GUI-based interface to administer container
objects and resource modifications using JMX MBeans. The admin web application
uses the Apache Struts framework to implement the administration GUI-based
interface. The Struts framework promotes applications to be based on the Model-ViewController (MVC) design. The admin web application uses JSP pages for the View
component. These JSP pages create HTML forms for the operator to specify object
attributes and to initiate various object operations.
Figure 1-6 is an example of the admin user interface.
1-16
manager Web Application
Figure 1-6. Admin User Interface
For more information about the admin web application, see admin Web Application on
page 4-10.
The manager web application provides the management functions for web applications
in the NSJSP container. In prior versions, the management functions were provided
using the nsjsp_manager (an interactive shell script). The nsjsp_manager is
discontinued in NSJSP 5.0 and is replaced with the GUI-based manager web
application.
Figure 1-7 is an example of the manager user interface.
1-17
Figure 1-7. Manager User Interface
On this page, the manager lists the installed web applications in a table. Each row in
the table represents a web application. The management functions supported are
listed using hyperlinks. By selecting a specific hyperlink, the operator issues the
specified command to the web application.
Note. The GUI interface does not support any scripts from previous NSJSP releases, but they
can still be run directly from the OSS shell.
For more information, see Manager Web Application on page 5-1.
1-18
Enhanced NSJSPCoyoteConnector
Enhanced NSJSPCoyoteConnector
The NSJSP connector component NSJSPCoyoteConnector has been enhanced so
the connector is managed using JMX MBeans.
Session Clustering (not supported)
NSJSP 5.0 does not support session clustering. Instead, the current session routing
mechanism continues to be used in NSJSP 5.0.
Session clustering was not implemented because Tomcat 5.0 uses private backend
TCP sessions to support in memory session replication among servers in the same
cluster. Each session update triggers the server to send the session update to the
other servers in the cluster. If the number of servers increases, the backend session
traffic may cause performance degradation.
Invoker Servlet Availability
By default, the invoker servlet is no longer available in all web applications. However,
you can enable the invoker servlet by editing the
/usr/tandem/webserver/conf/web.xml and uncommenting the "/servlet/*"
servlet-mapping definition.
Using the invoker servlet in a production environment is not recommended. You can
achieve the same functionality and be more secure by adding and mapping your
servlets individually using the <servlet> and <servlet-mapping> elements in
your web application's deployment descriptor web.xml.
For more information, see the servlets-examples web applications deployment
descriptor (web.xml).
1-19
Invoker Servlet Availability
1- 20
2
Installing NSJSP
The section describes:
•
•
•
•
•
•
Before You Begin the Installation on page 2-1
Begin the Installation on page 2-2
Starting or Restarting NSJSP on page 2-6
Stopping NSJSP on page 2-7
Uninstalling NSJSP on page 2-8
NSJSP Directory Structure on page 2-9
The procedure for installing NSJSP software depends on the distribution medium for
the product. Check the readme.txt file if you have received the software on a CD.
Check the softdoc if you are installing the product from a tape. The following
installation instructions are correct as of the time this manual was published; however,
the readme.txt file or softdoc supersedes the information here.
Before You Begin the Installation
•
•
•
•
Ensure that the following software is installed and configured before you install
NSJSP:
°
The OSS environment on a NonStop system running NonStop operating
system G06 or later.
°
NonStop Server for Java (NSJ) 4.2 or later, as described in the NonStop
Server for Java (NSJ) Programmer’s Reference.
°
Every time you install a new version of NonStop Server for Java, you must rerun the NSJ "make" to ensure that the NSJSP software is linked with the JVM.
Refer to the NonStop Server for Java (NSJ) Programmer’s Reference for more
information.
°
iTP Secure WebServer 6.0 SPR ABV or later. Note that you will need to restart
the iTP Secure WebServer after installing NSJSP.
Ensure that the requirements for using this product are met (see the iTP Secure
WebServer System Administrator’s Guide or the NSJSP Readme file).
Ensure that the prerequisites for the installation utility and any product-specific
installation requirements are met (see the NSJSP Readme file).
Review the file USRGUIDE.PDF (in the subdirectory NSK_SW on the product CD)
containing the IPSetup User Guide, which provides instructions for using IPSetup,
a utility provided on the CD that enables installation of Independent Products. You
need Adobe Acrobat Reader (available on the product CD) to read or print the
IPSetup User Guide.
2 -1
Installing NSJSP
•
•
Begin the Installation
To fully deploy the product pax file into the OSS space, ensure that the "Extract
files from ustar archives to OSS file system" option is selected when prompted.
If TCP/IP and FTP are unavailable, or if you have problems using automatic file
placement, use the instructions in the IPSetup User Guide section about Manual
Software Placement to manually place NonStop operating system files.
Begin the Installation
The iTP WebServer installation location is iTPWS_INSTALL_DIR, which defaults to
/usr/tandem/webserver. From this point on, the
iTPWS_INSTALL_DIR/servlet_jsp directory is also referred to as the
$NSJSP_HOME directory.
If you are using IPSetup from a product CD, skip steps 1 and 2 and continue at
step 3.
IPSetup delivers the contents of T1222PAX into the version-specific OSS directory
located at:
$NSJSP_HOME/<version>
where <version> is the vproc of this RVU (for example:
T1222V50_10NOV05_BASE_V500_2)
The IPSetup step moves the product pax and softdoc files into the product ISV and
unpaxes the T1222PAX file. Running the COPYOSS macro on the product PAX file
does not affect any currently running environment.
If you are not using IPSetup, follow steps 1, 2, and continue at step 3.
1. Copy the files, T1222PAX to <$ISV>.ZOSSUTL.
2. On the HP NonStop system, log on as SUPER.SUPER, go to <$ISV>.ZOSSUTL,
and unpax the product file using the TACL macro COPYOSS:
TACL> LOGON SUPER.SUPER
TACL> VOLUME <$ISV>.ZOSSUTL
TACL> RUN COPYOSS T1222PAX
COPYOSS delivers the contents of T1222PAX into the version-specific OSS
directory located at:
where <version> is the vproc of this software RVU (for example:
T1222V50_10NOV05_BASE_V500_2).
The softdoc file, T1222V50 is a text file that you can keep on <$ISV>.SOFTDOC,
or you can copy the file to any other location on your NonStop system by using the
FUP DUP or FUP RENAME commands.
2 -2
Installing NSJSP
setupjava
3. To complete a typical installation of NSJSP, first run the setupjava script, then run
the setup script. Both these scripts are located in the OSS file system directory:
setupjava
The setupjava script updates and re-links the JVM (default /usr/tandem/java) to
include this version of the NSJSP software libraries and class files. By default,
setupjava updates the JVM java binary located in /usr/tandem/java. Both the
setupjava and setup scripts enable an alternate location to be specified if the JVM Java
binary is in a location other than the default.
1. Run the setupjava script using the same user ID that was used to install the JVM
NSJ software.
For example, if you previously used SUPER.SUPER to install the NSJ software,
setupjava would be run as follows:
TACL> OSH
OSS:
cd $NSJSP_HOME/<version>
OSS: ./setupjava
2 -3
Installing NSJSP
setup
2. After running the setupjava script, ensure that no errors have been reported by
the script.
Once the setupjava script is run, the Servlet JNI code (libT1222.a and
libT1222log.a) libraries are in the
/usr/tandem/java_public_lib_jdk142 directory
The Java binaries will have been automatically rebuilt to include the Servlet JNI
code.
The setupjava script is expected to be run only once when the product is first
unpaxed (by using COPYOSS) into its version-specific location. Running the script
a second time is not necessary unless you need to re-install the T1222 NSJSP
libraries.
setup
The setup script integrates NSJSP 5.0 with a previously installed iTP Secure
WebServer. The iTP Secure WebServer version must be 6.0 and SPR version ABV or
later.
The setup script prompts you for:
1. The location of an installed iTP Secure WebServer to which you wish to add
NSJSP support.
2. The logger choices: whether to select multiple log files (the default) or a single log
file. For more information about log files, refer to Section 6, Logs and Error
Conditions.
3. The JDBC drivers for SQL/MX and SQL/MP (if needed).
4. The online administration: whether to enable online NSJSP administration
(configuration and web application management). If this feature is enabled, a user
name and password is prompted.
The password must be at least 8 characters long and a combination of upper
and lower case characters. The password is scrambled by a utility script
nsjsp_digestPassword using SHA digest. The name and digested
password are then stored in the file nsjspadmin-users.xml.
The utility script and the file are both located in the $NSJSP_HOME/conf
directory.
Note. If you want to change the password or use a different digest
method (only those supported by the JVM) after installation, rerun the
nsjsp_digestPassword. Make sure you modify the value of the digest of the
Realm’s directive in admin.xml and manager.xml to match the new value. Since
the admin web application uses the Apache struts framework for the GUI-based
interface, the selection of the online NSJSP administration slows down the
NSJSP start-up time.
2 -4
Installing NSJSP
setup
5. Run the setup script using the same user ID as you used to install the iTP Secure
WebServer.
For example, if you previously used the SUPER.WEB user ID to install the iTP
Secure WebServer you must now use SUPER.WEB to install this portion of the
product as follows:
TACL> LOGON SUPER.WEB
TACL> OSH
OSS: cd $NSJSP_HOME/<version>
OSS: ./setup
After the setup script runs, the default files are located in the
iTPWS_INSTALL_DIR/conf directory are:
•
•
•
•
•
•
jdbc.config (only if jdbc configuration was specified)
jdbc.config.sample
nsjspadmin.config (only if online administration is selected)
nsjspadmin.config.sample
filemaps.config (only if online administration is selected)
filemaps.config.sample
The default files located in $NSJSP_HOME/conf are:
•
•
•
•
•
•
•
iTP_jaas.config
iTP_jaas.config.sample
nsjsp_cleanConfigBackups
nsjsp_digestPassword
nsjsp_migrateSessionStore
nsjspadmin-users.xml
nsjspadmin-users.xml.sample
If a pre-existing NSJSP configuration already exists and the version matches, no
backup is made and the pre-existing NSJSP configuration files are kept
unmodified. If the version is not the same, the existing configuration files,
iTP_server.xml, web.xml, servlet.config, and nsjspadmin.config are
saved with the extension bkup.version appended, for example,
servlet.config.bkup.3.2.3.
Once the setupjava and setup scripts have run, do not delete or modify the
version-specific directory $NSJSP_HOME/<version> or its subdirectories as there
are OSS symbolic links pointing back to that directory tree. If you do delete any of
these directories or subdirectories, you may need to reinstall the entire product
starting with unpaxing the product PAX file.
2 -5
Installing NSJSP
Starting or Restarting NSJSP
6. Verify the VPROC of the $NSJSP_HOME/bin/servlet.ssc binary. There should
be a T1222 VPROC that matches the <version> portion of the installation
directory. If no match exists, an installation error has occurred and must be
corrected before proceeding.
7. To compile servlets in the NSJSP environment, update your OSS profile. After
installing NSJSP 5.0, include the servlet-api.jar file in the Java classpath.
For example:
$NSJSP_HOME/<version>/common/lib/servlet-api.jar
Starting or Restarting NSJSP
When the NSJSP software is started, a running TCP/IP process is required. This
process is set by the setup script.
1. To start NSJSP, run the start script from the iTPWS_INSTALL_DIR/conf
directory in the iTP Secure WebServer environment. The script starts the HTTPD
process using the httpd.config configuration file. The script is shown below:
OSS: cd iTPWS_INSTALL_DIR/conf
OSS: ./start
2. When you see the EMS message
(#1) Servlet ServerClass started. Version
Procedure = T1222V50_10NOV05_BASE_V500_2
you can access the NSJSP sample page from a web browser at URL:
http://hostname:portnumber/servlet_jsp/
NSJSP can also be started by using a security manager. For information on this, refer
to Starting NSJSP Through a Security Manager on page 3-24.
For information on JAAS support, see JAASRealm on page 3-40.
To restart NSJSP, use the restart script, stop or nsjsp_stop and start scripts in
sequence, as described in the iTP Secure WebServer System Administrator’s Guide,
or use the PATHCOM utility to freeze, stop, thaw, and start NSJSP. The restart
script is shown below:
OSS: cd iTPWS_INSTALL_DIR/conf
OSS: ./restart
Possible Error Conditions
The NSJSP class file (ServletJSPConnector.jar) and Servlets JNI
(libT1222.a) must be the same version; otherwise, startup of the NSJSP
environment fails and a message reporting the error appears in the
servlet_error.log file.
2 -6
Installing NSJSP
Stopping NSJSP
Stopping NSJSP
You can stop NSJSP in two ways by using the stop script, as described in the iTP
Secure WebServer System Administrator’s Guide, or by using the nsjsp_stop script,
described as follows.
The NSJSP script called nsjsp_stop is located in the iTPWS_INSTALL_DIR/conf
directory. This script, shown in Example 2-1, enables the NSJSP container to be
stopped gracefully by invoking the servlet/jsp destroy() methods for cleanups
and flushing the persistent session data into a pre-configured persistent data store.
To save persistent session data and allow your applications to shut down gracefully,
use the nsjsp_stop script instead of the iTPWS_INSTALL_DIR/conf/stop script
(described in the iTP Secure WebServer System Administrator’s Guide) to shut down
the NSJSP and iTP WebServer environments.
Note. This script is slower than the iTPWS_INSTALL_DIR/conf/stop script. So if you do
not use persistent sessions and do not care about gracefully allowing your applications to exit,
using the iTPWS_INSTALL_DIR/conf/stop script might be more appropriate for your
environment.
Caution. If you use the nsjsp_stop script when servlet requests are still pending, you must
restart the WebServer environment. Stopping the web container immediately stops all
execution threads that are running within the web container. There are no runtime checks that
allow the web container to stay up and wait for all threads to finish when an nsjsp_stop script
has been issued against the web container.
2 -7
Installing NSJSP
Uninstalling NSJSP
Example 2-1. The nsjsp_stop Script
/usr/tandem/webserver/conf :
./nsjsp_stop
NonStop(tm) Servlets for JavaServer Pages(tm) Stop Script
T1222V50_10NOV2005_BASE_V500_2
__________________________________________________________
Gracefully shuts down the NonStop(tm) Servlets for JavaServer Pages(tm)
ServerClass (SERVLET+NSJSPAdmin)and the iTP WebServer environment. This
script should be used if you need to flush the session data into a preconfigured store or if you need the destroy() methods to be invoked on all
loaded servlet and jsp programs.
Note: This script may take a long time to stop the SERVLET and NSJSPAdmin
ServerClasses (depending on your configuration). You can use ^C (Control-C)
at any time to break out of this script in case it takes too long. You will
then need to use the '/usr/tandem/webserver/conf/stop' script to shutdown the
iTP WebServer environment.
iTP WebServer Installation = /usr/tandem/webserver
iTP WebServer Config File = /usr/tandem/webserver/conf/httpd.config
iTP WebServer Pathmon Name = /G/zweb ($zweb)
Freezing and stopping the
NSJSPAdmin
NSJSPAdmin
SERVLET
SERVLET
ServerClass ...
ServerClass ...
ServerClass ...
ServerClass ...
Done.
Done.
Shutting down the iTP WebServer environment via
/usr/tandem/webserver/conf/stop ...
httpd: (#451) self-signed test certificate in use (server:
<www.mycompany.com, port: 80) - do not trust for secure transactions
/usr/tandem/webserver/conf
Uninstalling NSJSP
The uninstall script removes the currently installed version of the NSJSP software
libraries from the specified JVM (default /usr/tandem/java) and relinks the JVM.
The uninstall script also removes all the NSJSP files, directories, and web
applications that were installed in your iTP WebServer environment.
Caution. Back up your web applications before you run the uninstall script. Running uninstall
resets your JVM to the pre-NSJSP installation level and removes all your web applications in
the webapps directory.
You must run this script using the same user ID that was previously used to install
NSJSP. For example, if you previously used the SUPER.SUPER ID to install NSJSP,
the uninstall script should be run as follows:
TACL> OSH
OSS: cd $NSJSP_HOME/<version>
OSS: ./uninstall
If you use the wrong user ID, the uninstall script does not run.
2 -8
Installing NSJSP
After the uninstall script runs, the Servlet JNI code (libT1222.a and
libT1222log.a) is removed from the /usr/tandem/java_public_lib_jdk142
directory. The Java binaries are automatically rebuilt.
To reinstall NSJSP after the uninstall script has been run, follow the installation
instructions for the specific NSJSP version you wish to reinstall.
Table 2-1 shows the various directories under the NSJSP home directory,
$NSJSP_HOME, after installation.
Table 2-1. NSJSP Directory Structure
Directory
Description
bin/
Binary executables and scripts.
common/
Classes available to both NSJSP internal and web
applications.
classes/
Unpacked common classes.
lib/
Common classes in JAR files.
endorsed/
Common classes in jar files used by the Endorsed Standards
Override Mechanism (ESOM) in Java2.
Configuration files, including:
conf/
iTP_server.xml
iTP_jaas.config
iTP_catalina.policy
web.xml
tomcat_users.xml
nsjspadmin-users.xml
NSJSP/
Engine specific configuration files and directories (default
Engine name in NSJSP).
backup/
Directory containing backup files saved when the NSJSP
environment is modified using the admin and manager web
applications.
logs/
Contains NSJSP log files. Logging is configured using the
iTP_server.xml file.
server/
Contains internal NSJSP classes and their dependencies.
classes/
Unpacked classes (internal only).
lib/
Classes packed in JAR files (internal only).
2 -9
Installing NSJSP
Table 2-1. NSJSP Directory Structure
Directory
nsjsp_webapps
Description
Admin and manager web applications.
webapps/
Base directory containing web applications
included with NSJSP.
work/
Used by NSJSP to store temporary files, notably the .java
source files and compiled .class files created when
processing JSP pages.
deployer/
The standalone application deployer.
share/
The classes/ and lib/ subdirectories shared across all web
applications.
temp/
Temporary working directory.
2- 10
Installing NSJSP
Directory Example
Directory Example
Example 2-2 is intended to summarize the answer to the question, "How do you get
from a URL to the application and to a servlet?" (Refer to Map Requests to
Applications and Servlets on page 3-20.) The example shows the main directories and
the configuration necessary to get NSJSP up and running.
The example assumes the default location of /usr/tandem/webserver as the root
of your directory structure.
For more information, see Configuring Web Applications on page 3-14, which shows
the directory structures for applications and the changes you make to the configuration
files to host an application and deploy its servlets.
Example 2-2. Directory and Configuration Overview
In this example the default root directory ($root) is shown as
/usr/tandem/webserver
/usr/tandem/webserver
/conf
servlet.config set env (SERVLET_NSJSP_HOME) /usr/tandem/webserver/servlet_jsp
Filemap /myapp1 $server_objectcode
/usr/tandem/webserver/servlet_jsp
/conf/NSJSP/localhost
myappl.xml
<Context path = “/myapp1” docbase=”myapp1”>
</Context>
/usr/tandem/webserver/servlet_jsp/webapps
/myapp1
index.html
Put static resources at the top level of structure
/images
logo.gif
ourfounder.gif
Or use subdirectories for separating resources
/WEB-INF
REQUIRED - A private subdirectory structure containing
resources directly provided by servlets and jsp
web.xml
Eg. <servlet-name>, <servlet-class>, <init-param>,
<load-on-startup>
/src
A directory for source files
shoppingcart.java
/lib
shopping.jar
A directory for JAR files to be deployed
/classes
All servlet class files are kept here
shoppingcart.class
login.class
2- 11
Installing NSJSP
Directory Example
By default, the /webapps subdirectory contains your server applications. (Use
docbase in myappl.xml to set this path, or any other preferred location.)
myapp1 is a sample application subdirectory. At this (root) level you can store files
such as index.html, or create subdirectories to manage your web application
resources, for example /images for graphics files.
Every application must have a WEB-INF subdirectory. This subdirectory is a private
area whose contents are not directly served to users. WEB-INF is a structured set of
subdirectories containing servlet classes, archives, and an application specific
deployment descriptor web.xml file. Use this web.xml file to override any global
settings in the $NSJSP_HOME/conf/web.xml file to customize your web application.
Java class files are located in the /classes subdirectory; this subdirectory is
required. The server looks for class files here (either by class name or alias, set in
either of the web.xml files) and these file override the zip version in the jar/ files
shared in the lib/ directory.
You can place Java source files in a /src subdirectory (optional).
2- 12
3
Configuring NSJSP
The section describes:
•
•
•
•
•
•
•
Configuring the NSJSP Container on page 3-1
Configuring Web Applications on page 3-14
Configuring the Security Manager on page 3-21
Configuring Virtual Hosting on page 3-28
Configuring Realms on page 3-28
Configuring Single Sign-On Support on page 3-46
Configuring Persistent Sessions on page 3-49
Configuring the NSJSP Container
Several configuration files support the NSJSP container environment and web
applications. The main configuration files are listed and described below. These
configuration files contain default values and, in most cases, you do not need to make
any changes to them.
servlet.config contains the configuration information required for the NSJSP SERVLET
ServerClass and the file mapping for the iTP WebServer. This file is located in the
iTPWS_INSTALL_DIR/conf directory.
iTP_server.xml contains the initial attributes of the NSJSP container to work with the
iTP WebServer. The file is located in the webserver’s $NSJSP_HOME/conf directory.
web.xml contains configuration contexts for a web application. The default version
located in the webserver’s $NSJSP_HOME/conf directory is the default used by all
web applications hosted by this environment. Each web application can create an
application-specific version used to support that application's specific servlet and JSP
initializations.
nsjspadmin.config contains the configuration information required for the nsjspadmin
ServerClass and the file mapping for the iTP WebServer. This file is located in the
jdbc.config contains the JDBC specific configuration including the locations of the
JDBC/MX and JDBC/MP installations. This file is located in the
filemaps.config contains the dynamically added Filemaps. This file is sourced in from
the servlet.config file.
3 -1
Configuring NSJSP
servlet.config
servlet.config
This file contains the configuration information and filemaps required for the SERVLET
ServerClass. The file is located (by default) in iTPWS_INSTALL_DIR/conf.
For security when you run a new installation (of T1222) for the first time, the setup
script automatically makes a backup of any pre-existing servlet.config file. You
can then make any changes to the default, such as adding filemaps.
Environment Variables
You may need to change the NSJSP_HOME environment variable. It must be set, as
follows:
set env(NSJSP_HOME) /usr/tandem/webserver/servlet_jsp
Server Directive
Among many other entries, Numstatic and Maxservers are set in the server
directive. By default, Numstatic set to 2 and Maxservers is set to 5, because the
NSJSP process is multi-threaded.
To support sessions, all processes in the NSJSP container must be static if you are not
using persistent sessions. That is, the Numstatic and Maxservers attributes of the
NSJSP container must have the same value. If the values are not equal, the LINKMON
will bring up additional dynamic servlet server processes based on the system load. If
a dynamic servlet server process is shut down because the system load has
decreased, all the session data it contained is lost.
The following entries must not be changed:
Arglist
The arglist parameter in the server directive has been used to specify the
following configuration:
The class file which the NSJSP server process loads immediately upon startup.
com.tandem.servlet.NSJSPBootstrap
The NSJSP home directory
-Dcatalina.home=$env(NSJSP_HOME)
The name of the customized server.xml file for NSJSP to use
$nsjsp_config_file
3 -2
Configuring NSJSP
servlet.config
Java Runtime Arguments
Consider adding any of the optional Java runtime arguments (listed below) to the
Java Arglist parameter. Note that the Arglist arguments for Java precede the
NSJSP container class, as in the following example:
Arglist -Xbootclasspath/a:$env(JAVA_HOME)/lib/tools.jar \
-Xnoclassgc -Xmx64m -Xss128k -Dbrowserdebug=false \
-Djdbc.drivers=com.tandem.sqlmp.SQLMPDriver \
-Xbootclasspath
Sets the classpath of the arguments.
-Xnoclassgc
The -Xnoclassgc optional argument turns off Java class garbage collection.
By default, the Java runtime reclaims space for unused Java classes. Including
this optional argument may help prevent potential memory-leak problems.
-Xmx maximum-heap-size [ k | m ]
maximum-heap-size
Sets the maximum size of the memory allocation pool, which is the garbage
collected heap, to maximum-heap-size which must be greater than or equal
to 1000 bytes.
Sets the servlet.config file value to 64 MB, which specifies the maximum
heap size to use.
k
Sets the value to be read in kilobytes. If neither k or m is specified, the
value is read in bytes.
m
Sets the value to be read in megabytes. If neither k or m is specified, the
value is read in bytes.
-Xss maximum-stack-size
maximum-stack-size
Sets the servlet.config file value to 128 KB, which specifies the maximum
stack size that can be used by a Java thread.
-Dbrowserdebug=[ true | false ]
Allows the browser to show error details. The default is false. If you encounter
an unexplained error, look at the log files, turn on the browserdebug (true),
restart the server, and rerun the request.
3 -3
Configuring NSJSP
servlet.config
-Djdbc.drivers
Identifies the SQL driver to NonStop Server for Java. This option is required for
servlets that use SQL/MP or SQL/MX for Java. If present, this option must
have the value com.tandem.sqlmp.SQLMPDriver or
com.tandem.sqlmx.SQLMXDriver.
-Djava.security.manager
Sets the Java Security Manager. By default, NSJSP is run without a security
manager (-Dnsjsp.security.manager=none).
-Djava.security.policy
sets the Java Security Manager policy file
(-Djava.security.policy==<file>).
The double equality signs (==) are required to inform the JVM to use this file
exclusively and to ignore all others.
-Djava.security.auth.login.config==$env(JAAS_CONFIG_FILE)
Sets the JAAS login configuration file. By default, NSJSP is run without a JAAS
configuration file (-Dnsjsp.jaas.login.config=none).
-Djava.endorsed.dirs
Identifies the directories that have the JAR files and classes that are used with
the Java Endorsed Standards Override Mechanism (ESOM) (Djava.endorsed.dirs=$env(NSJSP_ENDORSED_DIRS).
-Djava.io.tmpdir
Defines the temporary directory. This argument and value are required.
(-Djava.io.tmpdir=$env(NSJSP_HOME)/temp).
-DSaveSessionOnCreation=[ true | false ]
Enables or disables saving sessions to a persistent store at creation time.
Setting this to false does not save sessions to a persistent store (if one is
configured through either the iTP_server.xml file or in any Context
configuration (<context>.xml) files when a new session is created, loaded,
or recreated across restarts of the NSJSP container.
The default value is true (-DSaveSessionOnCreation=true). If you set the
-DSessionBasedLoadBalancing option to false, you may want to set this
option (-DSaveSessionOnCreation) to false for performance reasons.
Otherwise, same session is saved twice (once on session creation or load and
once upon the request completion).
3 -4
Configuring NSJSP
nsjspadmin.config
-DDiscardFileMapHistory=[ true | false ]
Preserves or discards the history of all Filemap related changes. The default is
false, if the option is not specified. This means that all the history of Filemap
related changes is preserved.
-DEnableJMXProxyServlet=[ true | false ]
Enables or disable the JMXProxyServlet in the manager web application. The
default is false, which is disabled.
-DSessionBasedLoadBalancing=[ true | false ]
Enables or disables session-based load balancing support. Setting this option
to false and configuring a PersistentManager and Persistent Store using the
iTP_server.xml configuration file enables any SERVLET ServerClass
process to handle a session-based request. The default value is true
(-DSessionBasedLoadBalancing=true).
-DSessionBasedCookieExpiry=[ true | false ]
Enables or disables the expiration time for session cookies based on the
session expiration time on the server side. The default value is false
(-DSessionBasedCookieExpiry=false).
Note. If the session timeout value is low (default is 30 minutes) and the clock values
on the server and client are badly skewed, the cookie may expire immediately after
being sent to the client (browser). The default value of false sets the cookie expiration
time to -1, which means that the cookie persists until the client (browser) window is
shut down or closed. However, if the client sends a cookie that refers to a session that
has expired (and the current request does not need or refer to a session), then the
server ensures that the cookie expires immediately.
Example 3-1. Sample Server Directive Arglist
$NSJSP_SECMGR $NSJSP_SECMGR_POLICY $NSJSP_JAAS_CONFIG \
-DEnableJMXProxyServlet=false
-Djava.endorsed.dirs=$env(NSJSP_ENDORSED_DIRS) \
-Dcatalina.home=$env(NSJSP_HOME) \
-Djava.io.tmpdir=$env(NSJSP_HOME)/temp \
com.tandem.servlet.NSJSPBootstrap -config $nsjsp_config_file start
For additional information about NonStop Server for Java, see the NonStop Server for
Java (NSJ) Programmer’s Reference.
nsjspadmin.config
The nsjspadmin.config file contains the configuration of the nsjspadmin
ServerClass. Although the nsjspadmin ServerClass is in the same TS/MP
environment as the SERVLET ServerClass, it still has its own configuration file so that
3 -5
Configuring NSJSP
nsjspadmin.config
the attributes of the nsjspadmin ServerClass are not changed accidentally. For the
nsjspadmin server to perform properly, most of these attributes should be maintained
as the installed value.
The nsjspadmin ServerClass is in the same TS/MP environment as the SERVLET
ServerClass and also uses the same iTP_server.xml configuration file as the
SERVLET ServerClass. Therefore, if there is more than one SERVLET ServerClass
running in your system, you are required to have one nsjspadmin ServerClass for
every SERVLET ServerClass. In the nsjspadmin ServerClass configuration, the Env
TANDEM_SERVLET_SC_NAME should specify the name of the SERVLET
ServerClass to be managed.
The nsjspadmin ServerClass must have these ServerClass attributes:
•
•
•
Numstatic = 1
Maxservers = 1
Additional ENV entires to servlet configration:
•
Env TANDEM_HTTPD_SC_NAME
The Env TANDEM_HTTPD_SC_NAME specifies the HTTPD ServerClass to
be managed (used when dynamically adding Filemaps). Use of this Env is
optional. The default is HTTPD.
•
Env TANDEM_SERVLET_SC_NAME
The Env TANDEM_SERVLET_SC_NAME specifies the NSJSP SERVLET
ServerClass name in your iTP WebServer environment. Use of this Env is
optional. The default is SERVLET.
•
Env TANDEM_SERVLET_SC_PATH
The Env TANDEM_SERVLET_SC_PATH specifies the path of the binary
executable of the NSJSP SERVLET ServerClass which is managed by this
nsjspadmin ServerClass. The default is
iTPWS_DIR_INSTALL/bin/servlet.ssc.
•
Env TANDEM_FILEMAPS_CONFIG
The Env TANDEM_FILEMAPS_CONFIG specifies the path or location to the
filemaps.config file. The default is filemaps.config in the
$root/conf directory.
A sample nsjspadmin.config configuration file is shown below:
3 -6
Configuring NSJSP
nsjspadmin.config
Example 3-2. Configuration File nsjspadmin.config
set nsjspadmin_objectcode $root/bin/nsjspadmin.ssc
Server $nsjspadmin_objectcode {
CWD $env(NSJSP_HOME)
Env CLASSPATH=$JVCP:$USRCP
Env JAVA_HOME=$env(JAVA_HOME)
Env JREHOME=$env(JAVA_HOME)/jre
Env TANDEM_HTTPD_SC_NAME=HTTPD
Env TANDEM_SERVLET_SC_NAME=SERVLET
Env TANDEM_SERVLET_SC_PATH=$server_objectcode
Env TANDEM_FILEMAPS_CONFIG=$root/conf/filemaps.config
MapDefine =TCPIP^PROCESS^NAME $transport
Maxservers 1
Numstatic 1
Maxlinks 250
#
#
Check that the Linkdepth and TANDEM_RECEIVE_DEPTH parameter
values match.
#
#
#
#
#
This value should also match the acceptCount and not exceed
the value of maxProcessors specified in the
$env(NSJSP_home/conf/iTP_server.xml file. Otherwise, requests
will be queued when they reach this maximum configured value.
The default is 25.
Linkdepth 25
Env TANDEM_RECEIVE_DEPTH=25
#
#
#
File locations to direct standard input, output and error.
Stdin /dev/null
Stdout $root/logs/nsjspadmin.log
Stderr $root/logs/nsjspadmin.log
#
#
#
#
This is the actual Arglist used to start up the NSJSPAdmin
Container.
-DEnableJMXProxyServlet=false \
com.tandem.servlet.NSJSPAdminBootstrap \
-config $nsjsp_config_file start
}
3 -7
Configuring NSJSP
nsjspadmin.config
In addition, the following Filemaps are also added to the nsjspadmin.config
configuration file:
Filemap /admin $nsjspadmin_objectcode
Filemap /manager $nsjspadmin_objectcode
This action directs all requests starting with /admin and /manager to the nsjspadmin
ServerClass.
3 -8
Configuring NSJSP
iTP_server.xml
iTP_server.xml
iTP_server.xml is a version of the standard server.xml file modified to use with
the iTP WebServer. iTP_server.xml is an XML file. The file’s default location is
$NSJSP_HOME/conf.
Example 3-3. Basic Structure of iTP_server.xml
<Server>
<Service>
<Connector/>
<Engine>
<Host>
</Host>
</Engine>
</Service>
</Server>
<Server>
At the top level, the <Server> element represents the entire Java Virtual Machine
(JVM).
<Service>
A <Service> element represents a collection of one or more <Connector>
elements that share a single container (therefore, the web applications are visible
within that container). Normally, that container is an <Engine>.
<Connector>
A <Connector> element represents an endpoint by which requests are received
and responses are returned, passing them on to the associated <Engine> for
processing.
<Engine>
An <Engine> element represents the Catalina object that processes every
request, passing the requests on to the appropriate <Host>.
<Host>
The <Host> element defines the virtual host.
<Context>
A <Context> element defines an individual web application. Note that it is no
longer recommended that you have the <Context> tag in the iTP_server.xml
file. These tags should be moved to the Context configuration file
(<context>.xml) and placed in the $NSJSP_HOME/conf/NSJSP/<hostname>/ directory.
3 -9
Configuring NSJSP
iTP_server.xml
The default iTP_server.xml file is well commented, read these comments to
become familiar with the contents of this file. Various additional elements, not shown or
described here but included in the default iTP_server.xml file, provide for logging
and other similar functionality, and define authentication realms.
For more information about Tomcat version 5.0, see the Apache Jakarta Tomcat 5
documentation at http://jakarta.apache.org/tomcat/tomcat-5.0-doc/index.html.
The statements in the iTP_server.xml file, shown in Example 3-4, are required to
work with the iTP WebServer.
Example 3-4. iTP_server.xml Statements
<Server debug="0" >
<Service name="NSJSP-iTPWebServer">
<Listener>
<GlobalNamingResources>
<Connector
className="com.tandem.servlet.coyote.tomcat5.
NSJSPCoyoteConnector"
minProcessors="5" maxProcessors="75"
acceptCount="25" debug="0" />
<Engine name="NSJSP" defaultHost="localhost" debug="0">
<Host name="localhost" debug="0" appBase="webapps"
unpackWARs="true">
</Host>
</Engine>
</Service>
</Server>
Context Paths
To add an application, you must add a Context configuration file to
$NSJSP_HOME/conf/NSJSP/<host-name> or in the webapps directory. For
example, you want to add the application orders with associated servlets, JSP and
other resources, enter the context path as shown in Example 3-5:
Example 3-5. Setting the Context Path
<Context path= "/orders" docBase="orders" debug= "0">
</Context>
The context path shows the context which is the start of the path for any URL
attempting to locate and run a servlet. The docbase could be used to create a separate
location for the application, instead of the default webapps directory. For convenience,
you could name this file as orders.xml so that it is easy to identify later on.
The corresponding filemap from filemaps.config should look like this:
Filemap /orders $server_objectcode
3- 10
Configuring NSJSP
web.xml
Reloading Servlets
If the reloadable attribute is set to true in the <context>.xml file (located in the
Context configuration file in the $NSJSP_HOME/conf/NSJSP/<host-name>
directory, as shown in Example 3-6), the container automatically reloads classes
(loaded from either the WEB-INF /classes directory or JAR files in the WEB-INF/lib
directory) that have changed.
Example 3-6. Setting the Reloadable Attribute
<Context path="/examples" docBase="examples" debug="0"
reloadable="true" >
</Context>
Note that automatic reload support is not recommended for production applications
because of the extra overhead required to perform the necessary checks on every
request.
Log Files
The iTP_server.xml file also sets the location of the files that contain logging
information. See Section 6, Logs and Error Conditions for details.
web.xml
The web.xml file is a deployment descriptor containing context configuration. A
default version of the web.xml file is located in the $NSJSP_HOME/conf directory.
This file sets the behaviors of all applications and their related resources.
You can also create a version of the same web.xml file within the WEB-INF
subdirectory of any specific application to override the global web.xml file to support
specific servlet control.
The Default Version
The web.xml file in $NSJSP_HOME/conf provides the default path contexts and
controls of servlets and JSP. The text below describes some sample XML control
elements.
Preloading Servlets
A set of servlets can be automatically loaded on startup time by using the <load-onstartup> element in the web.xml file, as shown in Example 3-7.
The load-on-startup element indicates that this servlet should be loaded on the
startup of the web application. The content of this element must be a positive integer
indicating the order in which the servlets should be loaded. Lower integers are loaded
before higher integers. If no value is specified, or if the value specified is not a positive
integer, the container loads the element any time in the startup sequence.
3- 11
Configuring NSJSP
web.xml
Example 3-7 shows a servlet class file, SessionSnoop, which has a priority of 3. Files
that have a higher priority are loaded before this one. Note that the servlet class name
is SessionSnoop, but a URL could reference the servlet by the servlet name Snoop.
Example 3-7. Preloading Servlets
<servlet>
<servlet-name>Snoop</servlet-name>
<servlet-class>SessionSnoop</servlet-class>
<load-on-startup>3<load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Snoop</servlet-name>
<url-pattern>/Snoop</url-pattern>
</servlet-mapping>
<servlet-mapping>
</servlet-name>Snoop</servlet-name>
<url-pattern>/servlet/Snoop</url-pattern>
</servlet-mapping>
Defining a Session Timeout Value
A session timeout parameter could be in either of the two versions of the web.xml file.
You can define a default session timeout interval value for all sessions created in the
web application by using the <session-config> and <session-timeout>
elements in the web.xml file. The specified timeout value must be expressed in
minutes, as shown in Example 3-8.
Example 3-8. Defining a Session Timeout Value
<session-config>
<session-timeout>
30
</session-timeout>
</session-config>
Your Application Version of web.xml
Each application can have a copy of web.xml, the deployment descriptor, for
example:
/webapps/myapp1/WEB-INF/web.xml
This file overrides any settings made in the web.xml file at the $NSJSP_HOME/conf
level.
3- 12
Configuring NSJSP
jdbc.config
Initializing Servlets
You can initialize servlets in either of the two versions of the web.xml file.
If portability is a requirement, you may prefer to put the initialization within the
application version of web.xml which is the deployment descriptor location used when
packing or unpacking web application archive (WAR) files.
The <init-param> element contains a name/value pair as the initialization parameter
of the servlet, as shown in Example 3-9.
Example 3-9. Initializing Servlets
<servlet>
<servlet-name>your alias servlet name</servlet-name>
<servlet-class>your servlet class name</servlet-class>
<init-param>
<param-name>name1</param-name>
<param-value>value1</param-value>
<param-name>name2</param-name>
<param-value>value2</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>your alias servlet name</servlet-name>
<url-pattern>your URL pattern map</url-pattern>
</servlet-mapping>
As noted previously, the servlet name is an alias of the servlet class name. The alias
allows you to change the name of the servlet class without having to make changes to
URL references in the servlet in the application. If you do not need this feature, use the
same name in both places.
jdbc.config
The jdbc.config file contains JDBC specific configuration including the locations of
the JDBC/MX and JDBC/MP installations. The JDBC/MX and JDBC/MP installations
used are either the default values or then what was specified when the setup script
was run. Based on the existence of the JDBC/MX and JDBC/MP jar files
(jdbcMx.jar and sqlmp.jar), the classpath is also setup to contain the jar files.
filemaps.config
For each new application (a collection of related servlets, JSP and other resources)
you may need to add a corresponding filemap in the filemaps.config file.
For example, a new application called orders could be accessed while the default path
is /servlet_jsp/orders or by adding the following filemap.
Filemap /orders $server_objectcode
3- 13
Configuring NSJSP
Configuring Web Applications
Any application deployed using the admin or manager application has the option of
requesting the nsjspadmin ServerClass to add the context path as a Filemap for
HTTPD routing purpose. The nsjspadmin ServerClass manages filemaps.config
file so it is recommended that you place all user-defined filemaps in the
filemaps.config file.
Configuring Web Applications
A web application is a collection of servlets, HTML pages, images, JSP files, a
deployment descriptor, and other configuration files all in one location. The web
application is organized as a structured hierarchy of directories that can be packaged
or unpackaged from a WAR file.
The directory structure has two parts:
•
•
A public area for resources such as HTML pages and images that are downloaded
to clients for direct rendering on the browser.
A private area that has the root WEB-INF, which contains configuration files such
as the web.xml deployment descriptor, servlet classes, and library files resources that require a managed lifecycle.
Example 3-10. Sample Application Directory Structure on OSS
/webapps/myapp1/
index.html
login.jsp
images/
companylogo.gif
ourfounder.gif
literature/
whitepaper.pdf
WEB-INF/
web.xml
classes/
shoppingcart.class
checkout.class
lib/
xmltools.jar
src/
shoppingcart.java
checkout.java
In the example myapp1, a public area contains the files that are directly accessible for
rendering by the browser, for example, the GIF and HTML files. Although JSP files
cannot be directly rendered, the API considers them the same as HTML files and
allows them to be located in the public area. For security reasons, in these examples,
the Java source files are located in the subdirecory of the WEB-INF subdirectory. The
WEB-INF area is controlled by the NSJSP container.
3- 14
Configuring NSJSP
Add a New Web Application
The NSJSP container knows where to look for your classes if you use this application
directory structure. You do not need to add classes and JAR files explicitly to the
CLASSPATH. Each application can be managed separately from others in the
container. To add an application, just add the context to a Context configuration file in
the $NSJSP_HOME/conf/NSJSP/<host-name>/ directory.
When this application directory structure is used, each application has its own
document root, and is the start of the context path to resources such as servlets in that
application.
Add a New Web Application
You can add an application to a run-time production system, such as the iTP
WebServer, in several ways.
•
•
•
•
Deploy an Existing Application WAR File
Deploy a Web Application Automatically
Deploy Using the Standalone Application Deployer
Deploy Using the admin or manager Web Applications
Deploy an Existing Application WAR File
If you already have a fully developed application in a WAR file, move the WAR file to
the webapps directory. Optionally, you can create the Context configuration file in the
$NSJSP_HOME/conf/NSJSP/<host-name>/ directory, add a filemap in
filemaps.config and restart the web container. This action deploys the application.
The container creates a directory that uses the WAR file name (minus the extension)
as the context (prefixed by /servlet_jsp/). For example, if the WAR file name is
myapp1.war, the container automatically creates a directory called myapp1 and
appends it to the prefix, creating a dynamic context called /servlet_jsp/myapp1
or the context specified in the <context>.xml file.
Deploy a Web Application Automatically
NSJSP supports dynamic contexts. Any web application archive (WAR) file that does
not have a corresponding directory of the same name (without the .war extension) is
expanded automatically, unless the unpackWARs property is set to false. If you
redeploy an updated WAR file, delete the expanded directory when restarting NSJSP,
so that the updated WAR file will be re-expanded.
Any subdirectory within the application base directory that appears to be an unpacked
web application (that is, contains a /WEB-INF/web.xml file) will receive an
automatically generated context element, even if this directory does not have context
defined in the $NSJSP_HOME/conf/NSJSP/<host-name>/ directory. This
generated context entry will be configured according to the properties set in any
<DefaultContext> element nested in its <Host> element. The context path for this
deployed context will be /servlet_jsp/ followed by the directory name. The URL
3- 15
Configuring NSJSP
needs to include the default NSJSP root directory (/servlet_jsp) when accessing a
web application using this automatically generated context:
http://hostname:port/servlet_jsp/web_application_name
To access a servlet from the browser, specify the servlet keyword in the URL, as
shown:
http://hostname:port/servlet_jsp/web_application_name/servlet
/Myservlet
This feature allows you to not define a context for your web application in
$NSJSP_HOME/conf/NSJSP/<host-name>/ directory or a filemap in the
filemaps.config file, unless you wish to define non-default properties for the
corresponding context or unless you do not want to add an extra NSJSP root directory
(/servlet_jsp) when accessing a web application.
NSJSP supports a standalone application deployer which validates, compiles, and
deploys a web application to a live NSJSP container. Customer web applications can
be validated and compiled before they are placed in a production environment.
The standalone application deployer consists of the manager Ant tasks, the JSP
compiler, and a task which validates the application deployment descriptor. By using
the Ant script build.xml, the deployer can:
•
•
•
•
•
Compile and validate without a running NSJSP container
Deploy a web application to a running NSJSP container
Undeploy a web application in a running NSJSP container
Start and stop a web application in a running NSJSP container
Reload a web application in a running NSJSP container
The deployer package and the Ant script can be easily integrated with many
application IDE products allowing you to develop and deploy web applications from the
same IDE. See the web.xml file for an example of the Ant script build.xml. In the
example below, you can run the Ant script to manage a web application called myapp:
C:\java\nsjsp 5.0\deployer> ant
Buildfile: build.xml
clean:
compile:
[copy] Copying 299 files to C:\java\nsjsp5.0\deployer\build\myapp
[validator] web.xml validated
[javac] Compiling 41 source files to
C:\java\nsjsp5.0\deployer\build\myapp\WEB-INF\classes
[javac] Note: C:\java\nsjsp 5.0\deployer\build\myapp\WEBINF\classes\examples\LogTag.java uses or overrides a deprecated API.
[javac] Note: Recompile with -deprecation for details.
[jar] Building jar: C:\java\nsjsp 5.0\deployer\build\myapp.war
3- 16
Configuring NSJSP
Deploy Using the admin or manager Web
Applications
BUILD SUCCESSFUL
Total time: 11 seconds
C:\java\nsjsp 5.0\deployer>ant deploy
deploy:
[deploy] OK - Deployed application at context path
/servlet_jsp/myapp
BUILD SUCCESSFUL
C:\java\nsjsp 5.0\deployer>
C:\java\nsjsp 5.0\deployer>ant stop
stop:
[stop] OK - Stopped application at context path /servlet_jsp/myapp
BUILD SUCCESSFUL
Total time: 1 second
C:\java\nsjsp 5.0\deployer>ant undeploy
undeploy:
[undeploy] OK - Undeployed application at context path
/servlet_jsp/myapp
BUILD SUCCESSFUL
C:\java\nsjsp 5.0\deployer>
Note. You should update the build.xml file based on your application.
For more information about the client deployer, see the documentation at
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/deployer-howto.html.
Deploy Using the admin or manager Web Applications
You can also add an application by adding a new context using the admin web
application or using the manager web application’s deploy command. See the admin
Web Application on page 4-10 and the Manager Web Application on page 5-1 for more
information.
Create a New Application
If you are creating a new application using the iTP WebServer environment you
should:
3- 17
Configuring NSJSP
Compile a Servlet
1. Create the appropriate directory structure under $NSJSP_HOME/webapps. If you
prefer to locate elsewhere, use the docbase attribute of the context path. Populate
with the required servlets and JSP files.
2. Create a local version of the web.xml file for deployment descriptors. Note that if
you write the deployment descriptors in the main default web.xml file, creating a
WAR file is difficult later on (only the local version of web.xml becomes part of the
WAR file).
3. Create the <context>.xml in the $NSJSP_HOME/conf/NSJSP/<host-name>/
directory.
4. Add a filemap to filemaps.config corresponding to the application name.
5. Restart the NSJSP process.
Compile a Servlet
To compile a servlet in the NSJSP container, include the following JAR file in your OSS
environment variable CLASSPATH:
$NSJSP_HOME/common/lib/servlet-api.jar
If you are using the source code location
. ./webapps/yourapplicationname/WEB-INF/src
Enter the following command to compile the servlet:
javac -d
../WEB-INF/classes/ *.java
where
asterisk (*) is the servlet name or names of Java classes you wish to compile and
use in your servlet applications.
This command compiles the Java files and creates the class files under /WEBINF/classes.
Deploy a Servlet
Enter a servlet name and a class name in the deployment descriptor. You can use the
same name for both the servlet and class, or you can use the servlet name as an alias
in a URL rather than revealing the whole servlet class name. Thus, in Example 3-11,
the URL could refer to start rather than startCartRequest.
The deployment descriptor web.xml is located in the WEB-INF/ subdirectory within
your application directory.
A fragment of that file is shown in Example 3-11:
3- 18
Configuring NSJSP
Deploy a Servlet
Example 3-11. Deploying a Servlet
<web-app>
<servlet>

<servlet-mapping>

<servlet-name>start</servlet-name>

<url-pattern>/myapp1/*</url-pattern>
</servlet-mapping>
</web-app>
The deployment descriptor is used to customize other servlet parameters such as:
•
•
•
•
Initializing Servlets on page 3-13.
Preloading Servlets on page 3-11.
Defining a Session Timeout Value on page 3-12.
MIME Mapping. The HTTP protocol uses Multipurpose Internet Mail Extensions
(MIME) types for describing content. When a webserver sends a document to a
client, the server should include a section in the response to indicate the type of
document so the browser can render the document correctly. Most browsers can
guess the type from the extension, for example doc, pdf, or gif, but it is good
programming practice to include a definition in the deployment descriptor.
This is not necessary for dynamic content where the servlet generating the
response should specify the MIME type using setContentType() on the
HttpServletResponse object, but it is useful to define the MIME types for your
static content in the public area of the web application.
Default MIME types are provided in the mime-types.config file in the conf
directory (the default is /usr/tandem/webserver/conf). You may add to that
file. If you do, you must also add those MIME types in the global web.xml file in
the $NSJSP_HOME/conf directory.
Example 3-12. How to Set the MIME Type
<web-app>
<mime-mapping>
<extension>doc</extension>
<mime-type>application/msword</mime-type>
</mime-mapping>
</web-app>
3- 19
Configuring NSJSP
Map Requests to Applications and Servlets
Map Requests to Applications and Servlets
Mapping requests to servlets is closely linked to the concept of a context path.
The application name and the context path lead to the application subdirectory. The
<servlet-mapping> and <servlet> tags are needed to find a servlet or JSP within
that application.
The location of the application directory (and, therefore, the servlet or JSP) is
determined in the docBase attribute of a Context if an absolute path is specified or
then as a relative path to the value of the appBase attribute of the Host this Context
belongs to.
The servlet or JSP could be any name (given the <servlet-name> and <servletclass> XML elements of the web.xml file) not just the class name. Using these
elements allows separation between the web pages (using a servlet name) and the
underlying Java code (using the class name), and makes maintenance easier.
URL Mapping to the Application
In a NSJSP container, each application is associated with a context, and all resources
exist relative to that context. The context path starts at the root level of the application
directory. In Configuring Web Applications on page 3-14, the context is /myapp1, the
name of the application.
Consider the URL that locates that context:
http://www.hostname.com/myapp1
The http://www.hostname.com is a URL for the HTTP scheme located at
www.hostname.com. The URI path is /myapp1. Together they form the URL.
As well as the www.hostname.com notation shown above, URLs can take the form
http://hostname:portnumber/myapp1
Each web application must be mapped to a unique URL path prefix, for instance,
/myapp1. The NSJSP container uses this prefix to map requests to resources within
the web application. The path name serves as the document root for serving resources
within the application.
URL Mapping to the Servlet
The mapping process has two parts. The first part is to provide servlet name and,
optionally, an alias for the full servlet class name. Therefore you could have a servlet
name such as start that refers to the servlet class startCartRequest.
The second part is to use the <servlet-mapping> elements of the deployment
descriptor to provide a more complex mapping than the usual inclusion of servlet name
(or class name) in the URL.
Example 3-13 is a sample fragment of a web.xml file that maps any URL containing
the application name to a specific servlet.
3- 20
Configuring NSJSP
Configuring the Security Manager
Example 3-13. Mapping a URL to the Servlet
<servlet>
<servlet>
<servlet-mapping>
<url-pattern>/myapp1/*</url-pattern>
</servlet-mapping>
Path mappings are relative to the context’s URL path. By providing a wildcard (*), any
URL containing the path /myapp1 can always be passed to the startCartRequest
servlet.
NSJSP can be started through a security manager. The SecurityManager function
enables a web application to run its own sandbox. The security manager allows you to
restrict trusted functionality to code that requires it.
NSJSP uses its own version of the standard catalina.policy file that is
documented in Tomcat 5.0.28. The security policies implemented by the Java security
manager are configured in the iTP_catalina.policy file located in the
$NSJSP_HOME/conf directory.
The iTP_catalina.policy file replaces any system java.policy file. The
iTP_catalina.policy file contains a default set of security policies to be enforced
(by the JVM) when NSJSP is run with the -Djava.security.manager option (see
servlet.config on page 3-2). You can assign additional permissions to particular web
applications by adding additional grant entries.
Entries in the iTP_catalina.policy file use the standard java.policy file
format, as shown in Example 3-14:
Example 3-14. Java Policy File Entry
// Example policy file entry
grant [signedBy <signer>,] [codeBase <code source>] {
permission <class> [<name> [, <action list>]];
};
The signedBy and codeBase entries are optional when granting permissions.
Comment lines begin with // and end at the end of the current line. The codeBase is
in the form of a URL, and a file URL can use the ${java.home} and
${catalina.home} properties, which are expanded to the directory paths defined for
them by the JAVA_HOME and CATALINA_HOME environment variables.
3- 21
Configuring NSJSP
The default iTP_catalina.policy file contains all the grant entries in the standard
catalina.policy file plus the following additional entries for the NSJSP container:
3- 22
Configuring NSJSP
Example 3-15. Policy File Entry for the NSJSP Container
// These permissions apply to the nsjsp-logging code
grant codeBase "file:${catalina.home}/bin/nsjsp-logging.jar" {
permission java.security.AllPermission;
};
grant codeBase "file:${catalina.home}/bin/nsjsp_bootstrap.jar" {
};
...
// These permissions apply to the servlet API classes
// and those that are shared across all class loaders
// located in the "common" directory. Need 3 different directory
// paths as the java Security Manager can't handle symbolic
// links within a directory tree.
grant codeBase "file:${catalina.home}/common/classes/-" {
};
grant codeBase "file:${catalina.home}/common/endorsed/-" {
};
grant codeBase "file:${catalina.home}/common/lib/-" {
};
// These permissions apply to the container's core code, plus
// any additional libraries installed in the "server" directory.
grant codeBase "file:${catalina.home}/server/classes/-" {
};
grant codeBase "file:${catalina.home}/server/lib/-" {
};
grant codeBase "file:${catalina.home}/server/nsjsp_webapps/-" {
};
// ========== JDBC DRIVERS CODE PERMISSIONS ====================
grant codeBase "file:/usr/tandem/jdbcMx/current/lib/jdbcMx.jar"
{
};
grant codeBase "file:/usr/tandem/jdbcMp/current/lib/sqlmp.jar" {
};
3- 23
Configuring NSJSP
Starting NSJSP Through a Security Manager
Example 3-15. Policy File Entry for the NSJSP Container
// These permissions are granted to the NSJSP balancer web
// application.
grant codeBase "file:${catalina.home}/webapps/balancer/WEBINF/lib/catalina-balancer.jar" {
permission java.lang.reflect.ReflectPermission
"suppressAccessChecks";
};
// These permissions are granted by default to all web
// applications. In addition, a web application will be given a
// read FilePermission and JndiPermission for all files and
// directories in its document root.
grant {
...
// NSJSP Specific properties to allow read access
permission java.util.PropertyPermission
"com.tandem.servlet.*","read";
permission
java.util.PropertyPermission"org.apache.commons.logging.*",
"read";
...
};
Starting NSJSP Through a Security Manager
Once you have configured the iTP_catalina.policy file for use with a security
manager, NSJSP can be started through a security manager in place by using the
-Djava.security.manager and
-Djava.security.policy==$env(NSJSP_HOME)/conf/iTP_catalina.policy
options in the servlet.config file (see servlet.config on page 3-2).
3- 24
Configuring NSJSP
Troubleshooting the Security Manager
Example 3-16. Starting NSJSP With a Security Manager
#
# NSJSP Java2 System policy file and Java2 VM option.
#
# Note: the "double" equalto signs "==" is not a typo!! This informs
the JVM
# to use this file exclusively and that all others are to be ignored.
#
set env(JVM_POLICY_FILE) $env(NSJSP_HOME)/conf/iTP_catalina.policy
set NSJSP_SECMGR_POLICY -Djava.security.policy==$env(JVM_POLICY_FILE)
...
set NSJSP_SECMGR -Djava.security.manager
...
#
# This is the actual Arglist used to startup the NSJSP Container.
#
Arglist -Xbootclasspath/a:$env(JAVA_HOME)/lib/tools.jar -Xnoclassgc
-Xmx64m -Xss128k -Dbrowserdebug=false \
com.tandem.servlet.NSJSPBootstrap -config
$nsjsp_config_file start
\
By default, the NSJSP container is run without a security manager. You can optionally
set the following option if you choose not to use the security manager:
-Dnsjsp.security.manager=none
Troubleshooting the Security Manager
You can turn on Java Security Manager debug logging by including
-Djava.security.debug=all in the servlet.config file before starting NSJSP.
The debug output is sent the log file
iTPWS_INSTALL_DIR/logs/servlet_error.log or
iTPWS_INSTALL_DIR/logs/servlet.log if you are using the single log file option.
3- 25
Configuring NSJSP
Enhanced Security Manager
Example 3-17. Troubleshooting the NSJSP Security Manager
Arglist -Xbootclasspath/a:$env(JAVA_HOME)/lib/tools.jar -Xnoclassgc
-Xmx64m -Xss128k -Dbrowserdebug=false \
-Djava.security.debug=all \
com.tandem.servlet.NSJSPBootstrap -config $nsjsp_config_file
start
Caution. The code in Example 3-17 generates many megabytes of output; however, you can
use this output to find problems: search for the word "FAILED" and determine which
permission was being checked for.
See the Java Debugging Support online documentation for more options that you can
specify for the java.security.debug property. This documentation is located at
http://java.sun.com/j2se/1.4.2/docs/guide/plugin/developer_guide/debugger.html.
NSJSP allows you to configure which NSJSP internal packages are protected against
package definition and access. This configuration prevents a non-trusted application
from accessing sensitive NSJSP internal packages. For more information about the
security manager, see the documentation at http://jakarta.apache.org/tomcat/tomcat5.0-doc/security-manager-howto.html.
The default security property file nsjsp.properties used is located in the
nsjsp_bootstrap.jar file and can be overridden by creating a file named
$NSJSP_HOME/conf/nsjsp.properties.
A sample file is located at $NSJSP_HOME/conf/nsjsp.properties.sample and
its contents are the exact same as the default security property file
nsjsp.properties (in the nsjsp_bootstrap.jar file).
3- 26
\
Configuring NSJSP
Example 3-18. Default Security Property File
#
#
#
#
List of comma-separated packages that start with or equal this string
will cause a security exception to be thrown when passed to
checkPackageAccess unless the corresponding RuntimePermission
("accessClassInPackage."+package) has been granted.
package.access=sun.,com.tandem.servlet.,org.apache.catalina.,org.apache.coyot
e.,org.apache.tomcat.,org.apache.jasper.,sun.beans.
#
#
#
#
#
#
List of comma-separated packages that start with or equal this string
will cause a security exception to be thrown when passed to
checkPackageDefinition unless the# corresponding RuntimePermission
("defineClassInPackage."+package) has been granted.
By default, no packages are restricted for definition, and none of the
class loaders supplied with the JDK call checkPackageDefinition.
package.definition=sun.,java.,com.tandem.servlet.,org.apache.catalina.,org.ap
ache.coyote.,org.apache.tomcat.,org.apache.jasper.
#
#
#
#
#
#
#
#
#
List of comma-separated paths defining the contents of the "common"
classloader. Prefixes should be used to define what is the repository
type.Path may be relative to the NSJSP_HOME path or absolute. If left as
blank, the JVM system loader will be used as the NSJSP Container's "common"
loader. Examples:
"foo": Add this folder as a class repository
"foo/*.jar": Add all the JARs of the specified folder as class
repositories
"foo/bar.jar": Add bar.jar as a class repository
common.loader=${catalina.home}/common/classes,${catalina.home}/common/endorse
d/*.jar,${catalina.home}/common/lib/*.jar
# List of comma-separated paths defining the contents of the "server"
# classloader. Prefixes should be used to define what is the repository type.
# Path may be relative to the NSJSP_HOME path or absolute. If left as blank,
# the "common" loader will be used as the NSJSP Container's "server" loader.
#Examples:
#
#
#
repositories
#
server.loader=${catalina.home}/server/classes,${catalina.home}/server/lib/*.j
ar
#
#
#
#
#
#
#
#
#
List of comma-separated paths defining the contents of the "shared"
classloader. Prefixes should be used to define what is the repository type.
Path may be relative to the NSJSP_HOME path or absolute. If left as blank,
the "common" loader will be used as the NSJSP Container's "shared" loader.
Examples:
repositories
shared.loader=${catalina.home}/shared/classes,${catalina.home}/shared/lib/*.j
ar
See the Tomcat 5.0 documentation for detailed information about how to run with a
security manager.
3- 27
Configuring NSJSP
Configuring Virtual Hosting
Configuring Virtual Hosting
The virtual hosting feature enables you to access web services on multiple IP
addresses or hostnames through a single iTP WebServer/NSJSP environment. Each
virtual host can have its own servlet context or a set of servlet contexts. Servlet
contexts cannot be shared across virtual hosts.
In the iTP_server.xml file, the <Host> element represents a virtual host. One or
more <Host> elements are nested inside an <Engine> element. Exactly one of the
Hosts associated with each <Engine> must have a name matching the
defaultHost attribute of that <Engine>. Any context associated with a virtual host
can be defined in the $NSJSP_HOME/conf/NSJSP/<host-name>/ directory.
The <Host> element attributes are described in detail in the Apache Tomcat
documentation at http://jakarta.apache.org/tomcat/tomcat-5.0-doc/index.html.
Example 3-19. Configuring Virtual Hosting
<Host name="www.hp.com" debug="0" appBase="webapps"
unpackWARs="true">
<Alias>hp.com</Alias>
...
</Host>
...
<Host name="nonstop.hp.com" debug="0" appBase="nsk_webapps"
unpackWARs="true">
<Alias>nonstop.compaq.com</Alias>
<Alias>www.tandem.com</Alias>
...
</Host>
Configuring Realms
NSJSP allows the use of realms. A realm is a database of user names and passwords
that identify valid users of a web application (or set of web applications), plus a list of
roles associated with each valid user. Roles are similar to groups in Unix-like operating
systems, because access to specific web application resources is granted to all users
possessing a particular role (rather than the list of associated user names). A particular
user can have any number of roles associated with that particular user’s user names.
The following types of storage may be used to contain the realm database:
MemoryRealm
Accesses authentication information stored in an in-memory object collection,
which is initialized from an XML document ($NSJSP_HOME/conf/tomcatusers.xml).
3- 28
Configuring NSJSP
MemoryRealm
JDBCRealm
Obtains authentication information stored in a relational database, accessed
through a Java Database Connectivity (JDBC) driver.
JNDIRealm
Obtains authentication information stored in an Lightweight Directory Access
Protocol (LDAP) based directory server, accessed through a Java Naming and
Directory Interface (JNDI) provider.
JAASRealm
Obtains authentication information through the Java Authentication and
Authorization Service (JAAS) framework.The JAAS package is fully integrated in
J2SE version 1.4.
To configure a realm, add an XML element to your
$NSJSP_HOME/conf/iTP_server.xml configuration file that looks something like
Example 3-20 or you can add an XML element to your context configuration files
located at $NSJSP_HOME/conf/NSJSP/<host-name>/ directory.
Example 3-20. Adding an XML Element to Configure a Realm
<Realm className="... class name for this implementation"
... other attributes for this implementation .../>
The <Realm> element can be nested inside one of three elements. Where the
<Realm> element is nested has a direct impact on the scope of that realm (that is,
which web applications will share the same authentication information):
•
•
•
Inside an <Engine> element – This realm will be shared across all web
applications on all virtual hosts, unless it is overridden by a <Realm> element
nested inside a subordinate <Host> or <Context> element.
Inside a <Host> element – This realm will be shared across all web applications
for this virtual host, unless it is overridden by a <Realm> element nested inside a
subordinate <Context> element. The <Context> element is defined in XML
configuration files located in the $NSJSP_HOME/conf/NSJSP/<host-name>/
directory.
Inside a <Context> element – This realm will be used only for this web
application. The <Context> element defined in XML configuration files located in
the $NSJSP_HOME/conf/NSJSP/<host-name>/ directory.
MemoryRealm
MemoryRealm is a simple implementation of the NSJSP realm interface. It is not
designed for production use. At startup time, MemoryRealm loads information about all
users, and their corresponding roles, from an XML document (by default, this
3- 29
Configuring NSJSP
MemoryRealm
document is loaded from the $NSJSP_HOME/conf/tomcat-users.xml file).
Changes to the data in this file are not recognized until NSJSP is restarted.
Realm Element Attributes
To configure MemoryRealm, create a <Realm> element and nest it in your
$NSJSP_HOME/conf/iTP_server.xml file or in the <Context> element in the
context configuration file, as described in Example 3-20. The following attributes are
supported for MemoryRealm:
className
The value is org.apache.catalina.realm.MemoryRealm.
debug
The level of debugging detail logged by this realm to the associated <Logger>.
Higher numbers generate more detailed output. If not specified, the default
debugging detail level is zero (0).
digest
The digest algorithm used to store passwords in non-plain text formats.
Valid values are those accepted for the algorithm name by the
java.security.MessageDigest class. See Digested Passwords on page 3-45
for more information. If not specified, passwords are stored in clear text.
pathname
The absolute or relative pathname of the users file (XML document) containing
valid user names, passwords, and roles. See User File Format on page 3-30 for
more information about the format of this file. If not specified, the value
$NSJSP_HOME/conf/tomcat-users.xml is used. For example:
<Realm className="org.apache.catalina.realm.MemoryRealm" />
User File Format
The users file (by default, $NSJSP_HOME/conf/tomcat-users.xml) must be an
XML document, with a root element <tomcat-users>. Nested inside the root element
is a <user> element for each valid user, consisting of the following attributes:
name
The user name this user must use to log on.
password
The password this user must use to log on (in clear text if the digest attribute was
not set on the <Realm> element, or digested appropriately as described in
Digested Passwords on page 3-45).
3- 30
Configuring NSJSP
JDBCRealm
roles
Comma-delimited list of the role names associated with this user.
The default contents of the $NSJSP_HOME/conf/tomcat-users.xml file are shown
in Example 3-21.
Example 3-21. Default User File Format
<tomcat-users>
<user name="tomcat" password="tomcat" roles="tomcat" />
<user name="role1" password="tomcat" roles="role1" />
<user name="both"
password="tomcat" roles="tomcat,role1" />
/tomcat-users>
MemoryRealm operates according to the following rules:
•
•
•
•
•
When NSJSP first starts up, it loads all defined users and their associated
information from the users file. Changes to the data in this file are not recognized
until NSJSP is restarted.
When a user attempts to access a protected resource for the first time, the NSJSP
container calls the authenticate() method of this Realm.
Once a user has been authenticated, the user (and the associated roles) is cached
within NSJSP for the duration of the user's login. (For FORM-based authentication,
the duration lasts until the session times out or is invalidated; for BASIC and
DIGEST authentication, the duration last until the user closes the browser).
Administering the information in the users file is the responsibility of your
application. The NSJSP container does not provide any built-in capabilities to
maintain users and roles.
Debugging and exception messages logged by this realm are recorded by the
<Logger> that is associated with the surrounding <Context>, <Host>, or
<Engine>. By default, the corresponding <Logger> creates a log file in the
$NSJSP_HOME/logs directory.
JDBCRealm
JDBCRealm is an implementation of the NSJSP Realm interface that looks up users in
a relational database accessed through a JDBC driver. The substantial configuration
flexibility lets you adapt to existing table and column names, as long as your database
structure conforms to the following requirements:
•
A users table must exist, as referenced in Example 3-22, that contains one row
for every valid user that this realm should recognize. The users table must
contain at least two columns (it can contain more according to the requirements of
your existing applications):
°
User name, to be recognized by the NSJSP container when the user logs in.
3- 31
Configuring NSJSP
°
•
JDBCRealm
Password, to be recognized by the NSJSP container when the user logs in.
This value can be in clear text or digested as described under Digested
Passwords on page 3-45.
A userRole table must exist, as referenced in Example 3-22, that contains one
row for every valid role that is assigned to a particular user. A user may have zero,
one, or more than one role. The userRole table must contain at least two
columns (more if your existing applications require more):
°
User name, to be recognized by the NSJSP container (the same value as is
specified in the users table).
°
Role name of a valid role associated with this user.
Example 3-22. SQL Commands to Add Users and User Roles
create catalog ;
create table users (
user_name varchar(15) not null,
user_pass varchar(15) not null,
primary key user_name);
create table roles (
role_name varchar(15) not null,
primary key role_name);
create table userrole (
user_name varchar(15) not null,
role_name varchar(15) not null,
primary key(user_name, role_name));
insert into users values ("tomcat", "tomcat");
insert into users values ("user1", "role1");
insert into users values ("user2", "role2");
insert into roles values ("tomcat");
insert into roles values ("other");
insert
insert
insert
insert
into
into
into
into
userrole
userrole
userrole
userrole
values
values
values
values
("user1", "tomcat");
("user2", "other");
("tomcat", "other");
("tomcat", "tomcat");
Two sample files, iTP_JDBCRealm.create.sample and
iTP_JDBCRealm.load.sample, exist in the $NSJSP_HOME/conf directory.
After replacing the =T1222DBDIR string with the Guardian location (of the form
$Volume.SubVolume) in a copy of these two sample files, you can pass these files
as input to the NonStop SQL Command Interpreter (SQLCI) through the OSS
command shown in Example 3-23.
3- 32
Configuring NSJSP
JDBCRealm
Example 3-23. SQLCI Commands to Create and Load the JDBCRealm
osh>
gtacl -p
sqlci
<
iTP_JDBCRealm.create.your_copy
osh>
gtacl -p
sqlci
<
iTP_JDBCRealm.load.your_copy
You may also run the NonStop SQL Commands directly through the NonStop
Command Interpreter (SQLCI) after replacing the =T1222DBDIR string with the
Guardian Location of the JDBCRealm catalog (of the form $Volume.SubVolume).
This subvolume (disk) should be an HP NonStop Transaction Management Facility
(TMF) audited data volume.
Note. Example 3-22 uses a varchar(15) field for the user_name column in the users table. If
you configure a web application by using the client-certificate based authentication method,
this column size (variable length characters with a maximum size of 15 characters) is not large
enough because the value stored in the user_name column is the subject (subject
distinguished name field) from the client-certificate. If the subject exceeds the NonStop SQL
maximum allowable primary key limit of 256 characters, alter the user_name field to the
appropriate size and define a new primary key that conforms to the NonStop SQL limits.
JDBCRealm Element Attributes
To configure JDBCRealm, create a <Realm> element and nest it in your
context configuration file. The following attributes are supported for JDBCRealm:
className
The value is org.apache.catalina.realm.JDBCRealm.
connectionURL
The database URL used to establish a JDBC connection.
For SQL/MP, specify the value jdbc:sqlmp:
For SQL/MX, specify the value jdbc:sqlmx:
debug
digest
The digest algorithm used to store passwords in non-plain text formats. Valid
values are those accepted for the algorithm name by the
3- 33
Configuring NSJSP
JDBCRealm
driverName
The fully qualified Java class name of the JDBC driver to be used.
For SQL/MP, specify the value com.tandem.sqlmp.SQLMPDriver here. You
must have the sqlmp.jar file in your classpath.
For SQL/MX, specify the value com.tandem.sqlmx.SQLMXDriver here. You
must have the jdbcMx.jar file in your classpath.
roleNameCol
The name of the column in the userRoleTable that contains the name of a role
assigned to this user. The default is role_name.
userCredCol
The name of the column in the userTable that contains the password for this
user (either in clear text, or digested if the digest attribute is set). The default is
user_pass.
userNameCol
The name of the column in the userTable and userRoleTable that contains
the user name of this user. The default is user_name.
userRoleTable
The name of the table that contains one row for each role assigned to a particular
user name. This table must include at least the columns named by the
userNameCol and roleNameCol attributes. The table name must be fully
qualified Guardian name, for example, $$data05.john.userrole. Note that the
“$$” sign is used to escape the $ sign in the XML parsing.
userTable
The name of the table that contains one row for each user name to be recognized
by NSJSP. This table must include at least the columns named by the
userNameCol and userCredCol attributes. The table name must be fully
qualified Guardian name, such as $$data05.john.users. Note that the “$$”
sign is used to escape the $ sign in the XML parsing.
Example <Realm> elements are included (commented out) in the default
$NSJSP_HOME/conf/iTP_server.xml file.
3- 34
Configuring NSJSP
JNDIRealm
Example 3-24. Using the SQL/MP Database to Specify JDBCRealm Attributes
<Realm className="org.apache.catalina.realm.JDBCRealm"
debug="0"
driverName="com.tandem.sqlmp.SQLMPDriver"
connectionURL="jdbc:sqlmp:"
userTable="$$data05.john.users”
userNameCol="user_name"
userCredCol="user_pass"
userRoleTable="$$data05.john.userrole”
roleNameCol="role_name" />
JDBCRealm operates according to the following rules:
•
•
•
•
When a user attempts to access a protected resource for the first time, the NSJSP
container calls the authenticate() method of this realm. Thus, any changes
you have made to the database directly (such as adding new users or changing
passwords or roles) are immediately reflected.
Once a user has been authenticated, the user (and user’s associated roles) is
cached within NSJSP for the duration of the user's login. For FORM-based
authentication, the duration last until the session times out or is invalidated; for
BASIC and DIGEST authentication, the duration lasts until the user closes the
browser. Any changes to the database information for an already authenticated
user are not reflected until the next time that user logs on.
Administering the information in the users, role, and user role tables is the
responsibility of your applications. The NSJSP container does not provide any
built-in capabilities to maintain users and roles.
Debugging and exception messages logged by this realm are recorded by the
<Logger> that is associated with the surrounding <Context>, <Host>, or
<Engine>. By default, the corresponding <Logger> creates a log file in the
$NSJSP_HOME/logs directory.
JNDIRealm
JNDIRealm is a user realm implementation of NSJSP that looks up users in a
directory server accessed by a JNDI provider (typically, the standard LDAP provider
that is available with the JNDI API classes). The substantial configuration flexibility
enables you to adapt to the existing schema inside your directory server, as long as it
conforms to the following requirements:
•
•
Each user that can be authenticated is represented by an individual element in the
top level DirContext, which is accessed through the connectionURL attribute.
The user element must have the following characteristics:
°
The distinguished name (dn) attribute of this element contains the user name
to be authenticated.
3- 35
Configuring NSJSP
°
•
•
•
JNDIRealm
There must be an attribute (identified by the userPassword attribute of our
<Realm> element) that contains the user's password, either in clear text or
digested (see Digested Passwords on page 3-45).
Each group of users that has been assigned a particular role is represented by an
individual element in the top level DirContext, which is accessed through the
connectionURL attribute.
The user group element must have the following characteristics:
°
The set of all possible groups of interest can be selected by an LDAP search
pattern configured by the roleSearch attribute in the <Realm> element.
°
The roleSearch pattern optionally includes pattern replacements {0} for the
distinguished name, and {1} for the username of the authenticated user for
which roles are to be retrieved.
°
The roleBase attribute can be set to the element that is the base of the
search for matching roles. If not specified, the entire directory context is
searched.
°
The roleSubtree attribute can be set to true to search the entire subtree of
the directory context. The default value of false requests a search of only the
current level.
°
The element includes an attribute (whose name is configured by the
roleName attribute of our <Realm> element) containing the name of the role
represented by this element.
There must be an administrator user name and password that NSJSP can use to
establish a connection to the directory server, with at least read-only access to the
information described above.
Realm Element Attributes
To configure a JNDIRealm, create a <Realm> element and nest it in your
context configuration file, as in Example 3-20. The following attributes are supported
for JNDIRealm:
className
The value is org.apache.catalina.realm.JNDIRealm.
connectionName
The user name used to establish a JNDI connection with the directory server.
connectionPassword
The password used to establish a JNDI connection with the directory server.
3- 36
Configuring NSJSP
JNDIRealm
connectionURL
The directory server URL with which to establish a JNDI connection.
debug
digest
roleBase
The base element for role searches. If not specified, the top-level element in the
directory context is used.
roleName
The name of the directory server attribute, which contains the role name.
roleSearch
The LDAP search pattern to use for selecting roles in the JNDIRealm. This pattern
should follow the syntax supported by the java.text.MessageFormat class.
You can use {0} to substitute the distinguished name and {1} to substitute the user
name of the user you want roles for.
roleSubtree
Specifies if you want role searches to search subtrees of the element selected by
roleBase. The default value is false, which causes only the top-level element to
be searched.
userPassword
The directory server attribute name (in the user element) that contains the clear
text or digested user password (depending on the setting of the digest attribute).
userPattern
The LDAP search pattern for selecting users in the JNDIRealm. This pattern
You can use {0} to substitute the distinguished name of the user you want roles for.
3- 37
Configuring NSJSP
JNDIRealm
The schema creation for your directory server is beyond the scope of this document
because it is unique to each directory server implementation. The examples below
show you how to configure the OpenLDAP directory server, which can be downloaded
from http://www.openldap.org.
These examples assume that the OpenLDAP server's configuration file (slapd.conf)
contains the LDBM settings (among others).
Example 3-25. LDBM Database Definitions
###############################################################
# ldbm database definitions
###############################################################
database
suffix
rootdn
rootpw
ldbm
"dc=hp,dc=com"
"cn=Manager,dc=hp,dc=com"
secret
These examples further assume that this directory server has been populated with
elements as shown in Example 3-26 (in LDIF format), which define the same users and
roles as the default $NSJSP_HOME/conf/tomcat-users.xml does for
MemoryRealm.
3- 38
Configuring NSJSP
JNDIRealm
Example 3-26. User and Role Definitions
# Define a user named 'tomcat'
dn: cn=tomcat,dc=hp,dc=com
cn: tomcat
userPassword: tomcat
sn: Tomcat User
objectClass: person
# Define a user named 'role1'
dn: cn=role1,dc=hp,dc=com
cn: role1
sn: Role1 User
objectClass: person
# Define a user named 'both'
dn: cn=both,dc=hp,dc=com
cn: both
sn: Both User
objectClass: person
# Define an entry to base role searches on
dn: dc=roles,dc=hp,dc=com
cn: roles
objectClass: person
sn: Roles Entry
# Define all members of the 'tomcat' role
dn: cn=tomcat,dc=roles,dc=hp,dc=com
cn: tomcat
objectClass: groupOfUniqueNames
uniqueMember: cn=tomcat,dc=hp,dc=com
uniqueMember: cn=both,dc=hp,dc=com
# Define all members of the 'role1' role
dn: cn=role1,dc=roles,dc=hp,dc=com
cn: role1
objectClass: groupOfUniqueNames
uniqueMember: cn=role1,dc=hp,dc=com
uniqueMember: cn=both,dc=hp,dc=com
A <Realm> element for the OpenLDAP directory server configured as described
above, might look like the example Example 3-27.
3- 39
Configuring NSJSP
JAASRealm
Example 3-27. Realm Element for the OpenLDAP Directory Server
<Realm className="org.apache.catalina.realm.JNDIRealm"
debug="0"
connectionName="cn=Manager,dc=hp,dc=com"
connectionPassword="secret"
connectionURL="ldap://nonstop.hp.com:1025"
roleBase="dc=roles,dc=hp,dc=com"
roleName="cn"
roleSearch="(uniqueMember={0})"
roleSubtree="false"
userPassword="userPassword"
userPattern="cn={0},dc=hp,dc=com"/
JAASRealm
JAASRealm is a user realm implementation of NSJSP that authenticates users for a
web application (or applications) through the Java Authentication and Authorization
Service (JAAS) framework. The JAAS package is fully integrated in J2SE version
1.4.and is available in NSJ 4.0 or later releases.
Based on the JAAS framework, the JAASRealm allows pluggable authentication
mechanisms whose implementations are totally container-independent. You could use
the JAAS login module and principal to develop your own security mechanism or to
wrap other third-party mechanisms to support the web applications' security
constraints. To set up NSJSP to use JAASRealm:
1. Prepare your own LoginModule, User, and Role classes to be managed by JAAS
LoginContext (see the JAAS Login Module Developer's Guide) or you may use the
NSJSP provided NonStopLoginModule, NonStopUserPrincipal, and
NonStopRolePrincipal.
2. Add the classes to the NSJSP container.
3. Create a login configuration file (refer to JAAS LoginConfig file), and specify its
location in the Arglist of the NSJSP (in the servlet.config). (add Djava.security.auth.login.config==$NSJSP_HOME/conf/iTP_jaas.c
onfig). Note that the double equal sign (==) specifies that only this file should be
used. Below is the NSJSP provided login configuration file using the NonStop
LoginModule (iTP_jaas.config):
/**
*
*
*
*
*
*
*
*
*
*
*
*
*
*
File :
Product Name :
iTP_jaas.config
NonStop(tm) Servlets For Java Server Pages(tm)
Product Version :
Description :
T1222 v5.0
The configuration file to authenticate NonStop Users
via the JAAS NonStopLoginModule code. The User Name
can be passed in 4 different ways to the JAAS
NonStopLoginModule for user authentication via:
NonStop User Name
E.g. SUPER.SUPER
NonStop Group,User
E.g. 255,255
NonStop User ID
E.g. 65535
3- 40
Configuring NSJSP
*
*
*/
JAASRealm
Safeguard Alias
NonStopUserDB {
com.tandem.servlet.jaas.NonStopLoginModule
REQUIRED
E.g.
root
debug=false;
};
If you use the NonStopLoginModule, then the user name may be specified in any
of the following forms:
Nonstop User Name: SUPER.WEBMSTR
Nonstop Group,User: 255,20
Nonstop User ID: 65305
Safeguard Alias: webman
On successful authentication of Nonstop users (and optionally Safeguard aliases if
Safeguard has been configured), the NonStopLoginModule returns the groups the
user or alias belongs to, in addition to the actual Nonstop user name as the roles
that are granted to the authenticated Nonstop user.
For example, if the Safeguard alias "webman" (for NonStop user
SUPER.WEBMSTR) is configured as belonging to groups SUPER, SOFTWARE
and WEB, then on successful authentication, the roles returned for the "webman"
alias are:
SUPER
SOFTWARE
WEB
SUPER.WEBMSTR (the actual NonStop user name)
4. Configure the security-constraints in your web applications' deployment
descriptors(modify the web application's web.xml for the resources you want to
protect). For example, update your application’s web.xml to allow “SUPER” and
“SYSSW” NonStop user group to access your application:
:
:
<security-constraint>
<web-resource-collection>
<web-resource-name>My Appl's Secure Pages</web-resource-name>
<description>Security constraint for resources in the secure
directory</description>
<url-pattern>/secure/*</url-pattern>
<http-method>POST</http-method>
<http-method>GET</http-method>
</web-resource-collection>
<auth-constraint>
<description>only let the system user login </description>
<role-name>SYSSW</role-name>
<role-name>SUPER</role-name>
</auth-constraint>
</security-constraint>
:
:
<login-config>
<auth-method>BASIC</auth-method>
</login-config>
3- 41
Configuring NSJSP
JAASRealm
<security-role>
<description>The System User ROLE</description>
<role-name>SYSSW</role-name>
<role-name>SUPER</role-name>
</security-role>
:
:
5. Configure the JAASRealm module in the iTP_server.xml file or in your Context
configuration file located in the $NSJSP_HOME/conf/NSJSP/<host-name>/
directory. Example 3-28 shows an example of using the NSJSP provided
NonStopLoginModule.
.
Example 3-28. Realm Element in the iTP Web Server Configuration File
<Realm className="org.apache.catalina.realm.JAASRealm"
appName="NonStopUserDB"
userClassNames="com.tandem.servlet.jaas.NonStopUserPrincipal"
roleClassNames="com.tandem.servlet.jaas.NonStopRolePrincipal"
useContextClassLoader=”true”
debug="0"/>
JAASRealm Element Attributes
To configure JAASRealm, create a <Realm> element and nest it in your
for JAASRealm.
className
The value is org.apache.catalina.realm.JAASRealm.
appName
The name of the application as configured in the login configuration file.
digest
userClassNames
A comma-separated list of user Principal class names.
roleClassNames
A comma-separated list of role Principal class names.
3- 42
Configuring NSJSP
DataSourceRealm
useContextClassLoader
Instructs the JAASRealm to use the context’s loader for loading the user specified
LoginModule and associated classes. The default is true.
debug
The level of debugging logged by the Logger. The default is 0.
For more information about configuring JAASRealm or creating your own login module,
see the Tomcat 5.0 Specification at
http://jakata.apache.org/tomcat/tomcat-5.0-doc.index.html.
DataSourceRealm
DataSourceRealm is an implementation of NSJSP's Realm interface that uses a user
database accessed using a JNDI named JDBC DataSource. Similar to the
JDBCRealm, the DataSourceRealm requires a set of underlying SQL database tables
to be available.
A DataSourceRealm can be configured in the iTP_server.xml configuration file
nested inside a service or a virtual host. In addition, it can also be configured for a
specific context by nesting the <Realm> element inside the <Context> element in the
context configuration file. Example 3-29 shows an example configuring
DataSourceRealm.
Example 3-29. DataSourceRealm
<Realm className="org.apache.catalina.realm.DataSourceRealm"
dataSourceName="jdbc/userDB"
roleNameCol="role_name"
userCredCol="user_pass"
userNameCol="user_name"
userRoleTable="$$DATA00.REALMDB.USERROLE"
userTable="$$DATA00.REALMDB.USERS" />
DataSourceRealm Element Attributes
To configure DataSourceRealm, create a <Realm> element and nest it in your
for DataSourceRealm.
className
The value is org.apache.catalina.realm.DataSourceRealm.
dataSourceName
Specifies a defined JNDI named JDBC DataSource for your database.
3- 43
Configuring NSJSP
UserDatabaseRealm
digest
roleNameCol
Specifies the name of the column in the User RoleTable where the name of a role
assigned to this user.
userCredCol
Specifies the name of the column in the Users Table where the user's password is
kept.
userNameCol
Specifies the name of the column in the user Table where the user's name is kept.
userRoleTable
Specifies the location of the User Role Table.
userTable
Specifies the location of the Users Table.
For more information about configuring DataSourceRealm, see the Tomcat 5.0
Specification at
UserDatabaseRealm
UserDatabaseRealm is an implementation of NSJSP's Realm interface that uses a
defined naming resource of org.apache.catalina.UserDatabase type. In fact,
there is a UserDatabase Realm added to the iTP_server.xml configuration file at
the product installation. Example 3-30 shows an example configuring
UserDatabaseRealm.
Example 3-30. UserDatabaseRealm
<Realm className="org.apache.catalina.realm.UserDatabaseRealm"
resourceName="myOwnUserDatabase"/>
UserDatabaseRealm Element Attributes
To configure UserDataBaseRealm, create a <Realm> element and nest it in your
for DataSourceRealm.
3- 44
Configuring NSJSP
Digested Passwords
className
The value is org.apache.catalina.realm.UserDataBaseRealm.
digest
resourceName
Specifies a defined resource for user database.
In the above example, the “myOwnUserDatabase” is defined as a global naming
resource as follows:
<GlobalNamingResources>
:
:
<Resource name="myOwnUserDatabase"
description="my own user database"
type="org.apache.catalina.UserDatabase"/>
:
:
<ResourceParams name="myOwnUserDatabase">
<parameter>
<name>factory</name>
<value>org.apache.catalina.users.MemoryUserDatabaseFactory</value>
</parameter>
<parameter>
<name>pathname</name>
<value>conf/myOwnUsers.xml</value>
</parameter>
</ResourceParams>
:
:
</GlobalNamingResources>
For more information about configuring UserDatabaseRealm, see the Tomcat 5.0
Specification at
Digested Passwords
For each of the standard realm implementations, the user's password (by default) is
stored in clear text. In many environments, this situation is undesirable because casual
observers of the authentication data can collect enough information to log on
successfully and impersonate other users. To avoid this problem, the standard
implementations support the concept of digesting user passwords. Digesting
passwords causes the stored version of the passwords to be encoded in a form that is
not easily reversible, but which the Realm implementation can still use for
authentication.
You select digested passwords by specifying the digest attribute on your <Realm>
element. The value for this attribute must be one of the digest algorithms supported by
the java.security.MessageDigest class (SHA, MD5, and so on). When you
3- 45
Configuring NSJSP
Configuring Single Sign-On Support
select this option, the contents of the password that is stored in the realm must be the
digested version of the clear text password, as digested by the specified algorithm.
When the authenticate() method of the realm is called, the (clear text) password
specified by the user is itself digested by the same algorithm, and the result is
compared with the value returned by the Realm. A match means that the user is
authorized.
To calculate the digested value of a clear text password, two convenient techniques
are supported:
•
•
If you are writing an application that needs to calculate digested passwords
dynamically, call the static Digest() method of the
org.apache.catalina.realm.RealmBase class, passing the clear text
password and the digest algorithm name as arguments. This method returns the
digested password.
A command line utility is provided to calculate the digested password, type
$NSJSP_HOME/conf/nsjsp_digestPassword \
{digest algorithm} {cleartext-password}
and the digested version of this clear text password is returned to standard output.
NSJSP enables users to authenticate themselves just once across the entire set of
web applications associated with a virtual host. To successfully configure NSJSP for
single sign-on support, the following requirements must be taken into account:
•
•
All clients that intend to use single sign-on support must provide support for
cookies, which maintain the user identity across web applications.
As implemented in the NSJSP container, the scope of single sign-on support is the
entire set of web applications registered with a single virtual host.
The system administrator must configure the
$NSJSP_HOME/conf/iTP_server.xml file as follows to enable single sign-on
support:
1. At the <Engine> or <Host> level, configure a <Realm> element that defines the
database of valid users and their corresponding roles. In the default configuration
shipped with NSJSP, this configuration is done at the <Engine> level.
It is recommended that you not configure a <Realm> element inside one of the
<Context> elements describing the web applications associated with this virtual
host. If you configure a <Realm> element inside a context element than the same
user credentials (username and password) need to be in this realm to support
single sign-on.
2. Nested inside the <Host> element, include the element as shown in
Example 3-31.
3- 46
Configuring NSJSP
Example 3-31. Configuring Single Sign-On Support
<Host name="localhost" ...>
...
<Valve className="org.apache.catalina.authenticator.SingleSignOn"
debug="0"/>
...
</Host>
3. For each web application that you need to operate under the single sign-on
support environment, define appropriate <security-constraint> and
<login-config> elements in the web application’s web.xml. The <securityconstraint> elements identify portions of the application's URI space that are
required for user authentication, and the <login-config> element is used if this
application is the first one accessed by the user that requires the user to log in.
There are no restrictions on different web applications utilizing different
authentication methods.
3- 47
Configuring NSJSP
The single sign-on facility operates according to the following rules:
•
•
•
•
•
•
•
All web applications configured for this virtual host must share the same Realm. In
practice, that means you can nest the <Realm> element inside this <Host>
element (or the surrounding <Engine> element), but not inside a <Context>
element for one of the involved web applications.
As long as you access only unprotected resources in any of the web applications
on this virtual host, you will not be challenged to authenticate yourself.
As soon as you access a protected resource in any web application associated
with this virtual host, you will be challenged to authenticate yourself, using the login
method defined for the web application currently being accessed.
Once authenticated, the roles associated with you will be used for access control
decisions across all of the associated web applications, without challenging you to
authenticate yourself to each application individually.
As soon as you log out of one web application (for example, by invalidating or
timing out the corresponding session if FORM-based login is used), your sessions
in all web applications are invalidated. Any subsequent attempt to access a
protected resource in any application requires you to authenticate yourself again.
The single sign-on feature uses HTTP cookies to transmit a token that associates
each request with the saved user identity, so it can only be utilized in client
environments that support cookies.
The single sign-on feature uses HTTP sessions so it also depends on the session
timeout value (default is 30 minutes).
Security Considerations
Because the single sign-on support implementation uses cookies to maintain user
identity across applications, the same risks of information exposure apply here as
when cookies are used to maintain session identity within a single web application. If
you are concerned that attackers may try to impersonate an ongoing session, you
should run your applications across a secure network connection (such as an SSL
connection using the HTTPS protocol).
3- 48
Configuring NSJSP
Configuring Persistent Sessions
Configuring Persistent Sessions
NSJSP provides support for persistent sessions through the <Manager> element in
the Context configuration file. Nest the <Manager> element below a <Context>
element, because the <Manager> element represents a session manager that can be
used to create and maintain session data for a particular web application/Context.
If a <Manager> element is not specified for a <Context> element, a default
<Manager> configuration is automatically created that handles and stores session
data only for the life of the Container/JVM process. The default configuration uses the
NSJSPStandardManager class for the className attribute in the <Manager>
element.
Creating a NonStop SQL Database to Store the Persistent
Session Data
To successfully configure NSJSP for persistent sessions support, first create a
NonStop SQL database (catalog and table) for storing and saving the persistent
session data. A sample SQL script located at
$NSJSP_HOME/conf/iTP_SessionStore.sql.sample
is provided with the NSJSP distribution, enabling you to create a NonStop SQL catalog
and table.
To create the NonStop SQL database for storing the persistent session data, you can
do one of the following:
•
Copy the iTP_SessionStore.sql.sample file and replace all occurrences of
=TheT1222SessionCatalog with the Guardian location (of the form
$Volume.SubVolume) where you wish the persistent session catalog and table to
be created. This subvolume (disk) should be a TMF-audited data volume.
Then, pass this file as an input to the NonStop SQL Command Interpreter (SQLCI)
using the following OSS command:
osh> gtacl -p sqlci < iTP_SessionStore.sql.your_copy
•
Or run the NonStop SQL commands directly from the NonStop SQL Command
Interpreter (SQLCI), replacing the =TheT1222SessionCatalog string with the
Guardian location of the persistent session catalog (of the form
$Volume.SubVolume). This subvolume (disk) should be a TMF-audited data
volume.
Note. The following example assumes that you are creating a NonStop SQL/MP database
table. If you wish to create a NonStop SQL/MX database table, be aware that the maximum
record size limit is 4036 bytes (unlike the 4096 byte limit in SQL/MP). As a result, you will have
to reduce the size of app_name field to VARCHAR(200) in order to create a NonStop SQL/MX
database table.
3- 49
Configuring NSJSP
Creating a NonStop SQL Database to Store the
Persistent Session Data
Example 3-32. SQL Script for Configuring Persistent Sessions
sqlci>
sqlci>
create catalog =TheT1222SessionCatalog secure "OOOO";
create table =TheT1222SessionCatalog.SessData (
session_id
VARCHAR(48)
NO DEFAULT NOT NULL,
process_name
VARCHAR(8)
rec_number
INTEGER UNSIGNED
app_name
VARCHAR(255)
session_data
VARCHAR(3712)
CHARACTER SET ISO88591,
valid
SMALLINT UNSIGNED NO DEFAULT,
maxinactiveinterval INTEGER
NO DEFAULT,
lastaccessed
LARGEINT
NO DEFAULT
primary key (session_id, process_name, rec_number) )
organization key sequenced
audit
catalog =TheT1222SessionCatalog;
To support the persistent session database scalability, partition the session data. This
can be done either by adding the partitions at the NonStop SQL table creation time or
on-the-fly by using the ALTER TABLE command in the NonStop SQL Command
Interpreter (SQLCI). Partitioning can be done by adding the partition option to the
CREATE TABLE command, as shown in Example 3-32.
Example 3-33 shows how to add two partitions based on the value of the session_id
key. The two partitions (in addition to the main table) are indicated by the two
parameters passed to the partition option. These parameters are
=TheFirstSessionPartition and =TheSecondSessionPartition values.
Replace these two values with Guardian locations of the form $Volume.SubVolume.
These two subvolumes (disks) should be TMF-audited data volumes.
Example 3-33. Adding Extra Partitions to Support Persistent Sessions
sqlci>
session_id
VARCHAR(128)
process_name
VARCHAR(8)
rec_number
INTEGER UNSIGNED
app_name
VARCHAR(255)
session_data
VARCHAR(3712)
valid
SMALLINT UNSIGNED NO DEFAULT,
NO DEFAULT,
lastaccessed
LARGEINT
NO DEFAULT
partition (=TheFirstSessionPartition.SessData
FIRST KEY “5”
catalog =TheT1222SessionCatalog,
=TheSecondSessionPartition.SessData
FIRST KEY “A”
catalog =TheT1222SessionCatalog)
organization key sequenced
audit
Alternatively, if you have already created the NonStop SQL table, you can use the
ALTER TABLE command to create or add partitions on-the-fly. Example 3-34 shows
how to add the same two partitions (shown in Example 3-31) using the ALTER TABLE
command in the NonStop SQL Command Interpreter (SQLCI).
3- 50
Configuring NSJSP
Configuring the Manager for Sessions Support
Example 3-34. Adding Partitions Using the SQLCI ALTER TABLE Command
sqlci>
alter table =TheT1222SessionCatalog.SessData
=TheFirstSessionPartition.SessData
FIRST
add partition
KEY “5”
sqlci>
alter table =TheT1222SessionCatalog.SessData
=TheSecondSessionPartition.SessData
FIRST
add partition
KEY “A”
Note that the session_id field used above as the partitioning key contains only
hexadecimal characters (0 through 9 or A through F). As a result,
•
•
•
All records that have session IDs starting with 0 through 4 are stored in the main
table.
All records that have session IDs starting with 5 through 9 are stored in the
partition indicated by =TheFirstSessionPartition.
All records that have session IDs starting with A through F are stored in the
partition indicated by =TheSecondSessionPartition.
To configure NSJSP for persistent sessions support, create a <Manager> element
and nest it under a <Context> element in your Context configuration file. All
implementations of the <Manager> element support the following attributes:
className
The Java class name of the implementation to use. This class must implement the
org.apache.catalina.Manager interface. If not specified, the default is
com.tandem.servlet.catalina.session.NSJSPStandardManager.
distributable
If distributable is set to true, the session manager enforces the restrictions
described in the Servlet 2.3 specifications on distributable applications which
means that all the session attributes should implement the
java.io.Serializable interface. The default value is false.
The value of this property is automatically inherited from the web application
deployment descriptor (WEB-INF/web.xml) based on the presence or absence of
the <distributable> element.
3- 51
Configuring NSJSP
maxInactiveInterval
The maximum inactive interval (in minutes) for any sessions created. The default
value is 30 minutes.
The value of this property is automatically inherited from the web application
deployment descriptor (WEB-INF/web.xml) based on the value specified in the
<session-timeout> element.
NSJSP provides two implementations of the manager:
•
•
The default, NSJSPStandardManager, provides no persistence and stores
sessions in memory only.
The optional, NSJSPPersistentManager, stores active sessions that have been
swapped out and also saves sessions across restarts of the NSJSP container. By
configuring the appropriate <Store> element nested under the <Manager>
element, you can specify the storage location for the session data.
NSJSPStandardManager (Standard Implementation)
NSJSPStandardManager is the standard manager implementation that is used for
any context unless overridden by specifying a <Manager> element nested under a
<Context> element. This manager implementation does not provide session
persistence: sessions are stored in memory only.
In addition to the attributes specified in Configuring the Manager for Sessions Support
on page 3-51, NSJSPStandardManager supports the following attributes:
algorithm
Name of the message digest algorithm to calculate the session identifiers it
generates. The java.security.MessageDigest class must support this value.
The default value is MD5.
checkInterval
The number of seconds between checks for expired sessions. The default value
used is 60 seconds.
debug
The debug level for messages logged to the associated <Logger>. Higher
numbers generate more detailed output. The default is 0 (zero).
entropy
A string value used when seeding the random-number generator that creates
session identifiers. If this attribute is not specified, a preset value is used. For a
security-conscious environment, use a long string value.
3- 52
Configuring NSJSP
maxActiveSessions
The maximum number of active sessions that can be created. The default is -1 for
no limit or unlimited active sessions.
randomClass
The Java class name of the java.util.random implementation class. The
default class is java.security.SecureRandom.
Example 3-35 shows how to use the NSJSPStandardManager.
Example 3-35. Using the NSJSPStandardManager
<Context path="/servlet_jsp/myapp" docbase="myapp" reloadable="false"
debug="0" >
<!- Using the default NSJSPStandardManager but with a check
Interval time of 5 minutes (300 secs) instead of the default 60
seconds and also changed the entropy attribute for security
reasons.
-->
<Manager
className="com.tandem.servlet.catalina.session.NSJSPStandardManager"
debug="0" checkInterval="300"
entropy="hp NonStop™ Enterprise Division" />
</Context>
NSJSPPersistentManager (Session Persistence Support)
NSJSPPersistentManager is the persistent implementation of a session manager. It
can swap active, but idle, sessions out to a persistent store, as well as save sessions
across restarts of the NSJSP container. The actual persistent store mechanism is
configured through a <Store> element nested under the <Manager> element.
Note. To provide persistent sessions support, configure a <Store> element.
In addition to the attributes specified in Configuring the Manager for Sessions Support
on page 3-51, NSJSPPersistentManager supports the following attributes:
algorithm
Name of the message digest algorithm that calculates the session identifiers it
The default is MD5.
checkInterval
The number of seconds between checks for expired sessions. The default is 60
seconds.
className
The Java class name of the implementation to use. Specify
com.tandem.servlet.catalina.session.NSJSPPersistentManager.
3- 53
Configuring NSJSP
debug
The debug level for messages logged to the associated logger. Higher numbers
generate more detailed output. The default is 0 (zero).
entropy
A string value used when seeding the random-number generator that creates
session identifiers. If this attribute is not specified, a semi-useful preset value is
used. For a security-conscious environment, use a long string value.
maxActiveSessions
The maximum number of active sessions that can be created. The default is -1 for
no limit or unlimited active sessions.
If this value is 0 (zero) or greater and too many active sessions exist, some active
sessions will be swapped out. The minIdleSwap attribute limits the sessions
being swapped out. Setting the minIdleSwap value to 0 (zero) means that
sessions are always swapped out after use, but slows performance. However, if
minIdleSwap is too low, sessions may not be created.
If you change the value of maxActiveSessions, ensure that value and the
minIdleSwap value are configured according to the amount of session-based
traffic this server is expected to receive. The recommended setting is -1.
maxIdleBackup
The interval (in seconds) a session must be idle (time since last access to the
session) before it can be persisted to the session store. The default value of -1
disables this feature. Note however that the maxActiveSessions,
minIdleSwap, and maxIdleSwap parameters could override this parameter
value and swap out a session before it reaches its maximum idle time interval. If
this feature is enabled, the interval specified here should be less than the value
specified for maxIdleSwap.
minIdleSwap
The interval (in seconds) for which a session must be idle (time since last access
to the session) before it is eligible to be persisted to the session store and
passivated out of the NSJSP container's memory. If this feature is enabled, the
interval specified here should be less than the value specified for maxIdleSwap.
The default of -1 disables this feature.
maxIdleSwap
to the session) before it is persisted to the session store and passivated out of the
NSJSP container's memory. If this feature is enabled, the interval specified here
should be equal to or longer than the value specified for maxIdleBackup. The
default of -1 disables this feature.
3- 54
Configuring NSJSP
Configuring the Persistent Store
randomClass
default class is java.security.SecureRandom.
saveOnRestart
Determines whether all sessions should be saved to the store on shutdown. The
default is true. To allow the session data to be persisted, bring down the NSJSP
SERVLET and nsjspadmin ServerClass by using the nsjsp_stop script
(iTPWS_INSTALL_DIR/conf/nsjsp_stop) instead of the stop script provided
with the iTP WebServer distribution (iTPWS_INSTALL_DIR/conf/stop). See
Stopping NSJSP on page 2-7 for more details.
If you are using the NSJSPStandardManager, no elements can be nested inside your
<Manager> element.
For the persistence manager implementation (NSJSPPersistentManager), you
must nest a <Store> element that defines the characteristics of the persistent data
store.
To enable the session data to be persisted, bring down the NSJSP SERVLET and
nsjspadmin ServerClass by using the nsjsp_stop script
(iTPWS_INSTALL_DIR/conf/
nsjsp_stop) instead of the stop script provided with the iTP WebServer distribution.
See Stopping NSJSP on page 2-7 for more details.
NonStopSQLJDBCStore
The NonStopSQLJDBCStore implementation is a NonStop SQL database-based
store that saves swapped-out sessions into a pre-configured NonStop SQL database
table that is accessed by a JDBC driver.
To configure a NonStopSQLJDBCStore, add a <Store> element nested under the
<Manager> element using the following attributes:
checkInterval
The number of seconds between checks for expired sessions that are stored in the
NonStop SQL Database. The default is 60 seconds.
className
The Java class name of the implementation to use. Specify
com.tandem.servlet.catalina.session.NonStopSQLJDBCStore.
debug
The debug level for messages logged to the associated <Logger>. Higher
numbers generate more detailed output. The default is 0 (zero).
3- 55
Configuring NSJSP
driverName
The fully qualified Java class name of the JDBC driver to be used.
For SQL/MP, specify the value com.tandem.sqlmp.SQLMPDriver. You must
have the sqlmp.jar file in your classpath.
For SQL/MX, specify the value com.tandem.sqlmx.SQLMXDriver. You must
have the jdbcMx.jar file in your classpath.
connectionURL
The connection URL to hand to the JDBC driver to establish a connection to the
database containing the session information.
For SQL/MP, specify the value jdbc:sqlmp:
For SQL/MX, specify the value jdbc:sqlmx:
sessionTable
The name of the NonStop SQL database table used for storing swapped
out/backed up sessions. This table must contain at least the database columns
that are configured by the Column Name attributes of the <Store> element
specified below. The session table name can be a DEFINE name of the form
=<Define Name> or a fully qualified Guardian file of the form
$$Volume.SubVolume.FileName. Note that the “$$” sign is used to escape the
$ sign in the XML parsing.
sessionIdCol
The name of the NonStop SQL database column contained in the specified
sessionTable that contains the session identifier of the swapped out/backed up
session. This column type must accept at least as many characters as contained in
the session identifiers created by the NSJSP container (typically 38).
3- 56
Configuring NSJSP
sessionProcessNameCol
sessionTable that contains the HP NonStop process name of the NonStop
Server for Java (NSJ) process. This column type must accept as many characters
as are contained in the NonStop process name (typically 6).
sessionRecNumberCol
sessionTable that contains the record number level of the swapped out/backed
up session. This column type must accept a Java integer (32 bits).
sessionAppCol
sessionTable that contains the web application name of the swapped
out/backed up session. This column type must accept at least 255 bytes.
sessionDataCol
sessionTable that contains the serialized form of the session attributes of the
swapped out/backed up session. This column type must accept at least 3712
bytes.
sessionValidCol
sessionTable that contains a flag indicating whether this swapped out/backed
up session is still valid. This column type must accept a Java short value (16 bits).
sessionMaxInactiveCol
sessionTable that contains the maxInactiveInterval property of the
swapped out/backed up session. This column type must accept at least Java
integer (32 bits).
sessionLastAccessedCol
sessionTable that contains the lastAccessedTime property of the swapped
out/backed up session. This column type must accept at least Java long (64 bits).
Note. If you change the default values of the NonStop SQL table column names, you need to
change the names of column name attribute values in the <Store> element described above. In
addition, ensure that the nsjsp_cleanSessionData script is modified accordingly.
3- 57
Configuring NSJSP
Before using the NonStop SQL JDBC-based store, create a NonStop SQL catalog and
database table to store the swapped out/backed up sessions. See Configuring the
Manager for Sessions Support on page 3-51 for more details.
Note. The NonStop SQL catalog must be created on a TMF-audited data volume (disk). To
save the persistent session data to the persistent store, you should use the
iTPWS_INSTALL_DIR/conf/nsjsp_stop script instead of the stop script (see Stopping
NSJSP on page 2-7 for more details).
Example 3-36. Using the NSJSPPersistentManager
<Context path="/servlet_jsp/examples" docbase="examples" debug ="0"
reloadable="false" crossContext="true">
<Manager
className="com.tandem.servlet.catalina.session.NSJSPPersistentManager"
debug="0" saveOnRestart="true" checkInterval="300"
maxActiveSessions="-1" minIdleSwap="-1" maxIdleSwap="600"
maxIdleBackup="-1">
<Store
className="com.tandem.servlet.catalina.session.NonStopSQLJDBCStore
debug="0" driverName="com.tandem.sqlmp.SQLMPDriver"
sessionTable="$$SYSTEM.T1222CAT.SessData"
sessionIdCol="session_id"
sessionProcessNameCol="process_name"
sessionRecNumberCol="rec_number"
sessionAppCol="app_name"
sessionDataCol="session_data" sessionValidCol="valid"
sessionMaxInactiveCol="maxinactiveinterval"
sessionLastAccessedCol="lastaccessed" />
</Manager>
</Context>
3- 58
4
Programming and Management
Features
The information discussed in this section includes the following:
•
•
•
•
Client Programming Features on page 4-1
Servlet Programming Features on page 4-2
JMX Based Administration on page 4-9
admin Web Application on page 4-10
Client Programming Features
Before you read this subsection, you should be familiar with the information in the iTP
Secure WebServer System Administrator’s Guide.
This subsection describes how to refer to a servlet and how to send requests to and
receive responses from a servlet. For a web client, little difference exists between
using a servlet or any other type of CGI application.
This subsection describes the following topics:
•
•
•
Invoking a Servlet on page 4-1
Passing Request Information on page 4-1
Receiving Response Information on page 4-2
Invoking a Servlet
You invoke a servlet by including a reference to its URL. The syntax of a servlet URL is
described in Map Requests to Applications and Servlets on page 3-20.
Passing Request Information
You can pass request information to a servlet in any of the following ways:
•
•
•
Query strings appended to URLs. The servlet receives this data through the
QUERY_STRING environment variable.
Extra path information appended to URLs. The servlet receives this information
through the PATH_INFO and PATH_TRANSLATED environment variables.
HTML forms. A servlet receives data from HTML forms in an input stream.
A servlet accesses environment variables and the input stream through an object, as
described in Using the Servlet API on page 4-4.
4 -1
Programming and Management Features
Receiving Response Information
Receiving Response Information
The response from the NSJSP container has the same form as the output from any
other CGI program and consists of:
•
•
•
One or more HTTP response headers
A blank line
The response content
However, the servlet/JSP itself need not generate all these elements. If it does not
provide header information, the servlet API methods insert the header
content-type: text/html. If the servlet/JSP does not include the blank line, the servlet
API methods insert the required carriage return and linefeed.
For information about how a servlet/JSP generates its output, see Using the Servlet
API on page 4-4.
Servlet Programming Features
This subsection describes the following topics:
•
•
•
•
•
•
•
•
•
•
•
•
Programming Using NonStop Server for Java on page 4-3
Programming Using Other Java Environments on page 4-4
Servlet and NSJSP Examples and References on page 4-4
Using the Servlet API on page 4-4
Obtaining Specific CGI Environment Variable Values on page 4-6
Context-Management on page 4-6
Multithreading – Spawning Java Threads on page 4-6
Request and Response Streams on page 4-7
Security Considerations on page 4-7
International Character Set Support on page 4-7
Reserved Cookie Names on page 4-8
javax.servlet.request.X509Certificate on page 4-8
A servlet uses the servlet API to receive and respond to requests from web clients. It
uses other NonStop Server for Java packages to perform such functions as access to
NonStop SQL/MP or NonStop SQL/MX databases. Because an NSJSP process is a
NonStop TS/MP ServerClass, your servlets inherit the scalability, persistence, and
performance benefits of such classes.
4 -2
Programming Using NonStop Server for Java
This section provides a brief summary about how to use the Servlet API 2.4. For
detailed information about the Servlet API 2.4, see the Java Servlet API Specification,
Version 2.4 at the following web site:
http://java.sun.com/products/servlet/
and other API documentation available from Sun Microsystems.
For information about programming using NonStop Server for Java, refer to the
NonStop Server for Java (NSJ) Programmer’s Reference.
You can create a new servlet or modify an existing servlet by using NonStop Server for
Java or by using some other standard Java environment.
Programming Using NonStop Server for Java
HP NonStop Server for Java 4 is a Java environment that supports compact,
concurrent, dynamic, portable programs for the Enterprise server. NonStop Server for
Java 4 requires the HP NonStop Open System Services (OSS) environment. NonStop
Server for Java 4 uses the HP NonStop operating system to add the NonStop system
fundamentals of scalability and program persistence to the Java environment.
NonStop Server for Java 4 is based on the Java 2 Platform, Standard Edition (J2SE)
SDK 1.4.2 reference Java implementation for Solaris, licensed by HP from Sun
Microsystems, Inc. NonStop Server for Java 4 is a conformant version of the Sun
Microsystems J2SE SDK 1.4.2 and is branded as Java Compatible. NonStop Server
for Java 4 complies with all conformance tests in version 1.4.2 of the Java
Conformance Kit (JCK).
NonStop Server for Java 4 supports the Java Platform Debugger Architecture (JPDA),
which consists of three interfaces designed for use by debuggers in development
environments for desktop systems. This is described in the Sun Microsystems
documentation for JPDA:
http://java.sun.com/j2se/1.4.2/docs/guide/jpda/index.html
NonStop Server for Java 4 also supports the Java Virtual Machine Profiler Interface
(JVMPI), which is used to develop profilers that work in conjunction with the Java VM
implementation.
NonStop Server for Java 4 supports the Sun Microsystems enhancement to AWT
called headless support that allows a Java Virtual Machine (JVM) to indicate whether a
display, keyboard, sound, or mouse operation can be supported in a graphics
environment. Because of the nonvisual nature of NonStop servers, NonStop Server for
Java 4 is always a headless JVM.
NonStop Server for Java 4 also includes the following features:
•
•
SQL/MP for Java. This feature gives your servlet access to NonStop SQL/MP
databases.
SQL/MX for Java. This feature gives your servlet access to NonStop SQL/MX
databases.
4 -3
•
Programming Using Other Java Environments
Transaction protection using TMF.
For detailed information about NonStop Server for Java, see NonStop Server for Java
(NSJ) Programmer’s Reference.
Programming Using Other Java Environments
You also can develop servlets in some other Java environment and use them on the
NonStop system, for example:
•
•
•
The Abstract Windowing Toolkit (AWT) is included in the NonStop Server for Java
4, but classes that produce graphical output return an exception.
NonStop Server for Java 4 supports runtime execution of invisible Java beans but
does not support runtime execution that requires a graphical user interface (GUI)
operation.
Transaction protection in NonStop Server for Java 4 is based on, but not identical
to the current interface defined by Java Transaction Services.
For complete information about compliance characteristics of NonStop Server for Java
4 and about ensuring portability of Java programs to and from NonStop Server for
Java, see the NonStop Server for Java (NSJ) Programmer’s Reference.
Servlet and NSJSP Examples and References
Once you install and start the servlet container, you can access the NSJSP Sample
page from a web browser at URL:
http://hostname:portnumber/servlet_jsp/
From there you can find a listing of the Servlet API 2.4 and JSP API 2.0 (servlets and
JSP) interfaces, classes, and methods. The list of methods corresponds to the content
of the javax.servlet and javax.servlet.http packages defined by Sun
Microsystems.
If you are migrating from a previous release of Java servlets, you check the API
specification to ensure that any methods or interfaces you have used in the past have
not been deprecated. See the iTP Secure WebServer System Administrator’s Guide
for information about migration. Then, refer to Migrating to NSJSP 5.0 on page 7-1 for
information about migrating from previous NSJSP releases.
Using the Servlet API
The servlet API includes interfaces, classes, and methods that structure the interaction
between a servlet and a web client. The following classes facilitate servlet usage.
The HttpServlet Class
This class extends the class GenericServlet by overriding the service
(ServletRequest,ServletResponse) method, which receives, processes, and
4 -4
Using the Servlet API
responds to a request from a web client. The HttpServlet class inherits the
init(ServletConfig) and destroy() methods from the GenericServlet
class.
A servlet that you write for the iTP WebServer environment must extend the
GenericServlet class or the HttpServlet class; the HttpServlet class is
preferable for the web environment because it includes many features supporting
HTTP protocol. Your servlet should override the init(ServletConfig) method to
perform any necessary initialization, the
service(ServletRequest,ServletResponse) or
service(HttpServletRequest,HttpServletResponse) method to process
requests as the application requires, and the destroy() method to deallocate
resources gracefully.
Your servlet should also use the doGet() and doPost() methods where applicable.
The HttpServletRequest Class
This class extends the ServletRequest class which provides methods for retrieving
information from a standard input stream and obtaining the values of various headers
and environment variables. The HttpServletRequest class defines methods for
obtaining HTTP-protocol header information and CGI environment variables such as
QUERY_STRING, PATH_INFO, and PATH_TRANSLATED.
To obtain an enumeration of all CGI environment variables in effect for a servlet, use
the getHeaderNames() or getAttribute() methods with the string parameter
value
"com.tandem.servlet.attribute_names"
The HttpServletResponse Class
This class extends the ServletResponse class which provides methods for writing to
the standard output stream and error file. The HttpServletResponse class defines
methods for sending HTTP response headers and error information to the web client.
To generate its own response headers, a servlet must generate all such headers
before writing any data to the output stream.
CONTENT_TYPE=text/html
The ServletException Class
This class provides methods for reporting servlet-specific exceptions. The doGet()
and doPost() methods of your servlet should use this class, or a class you derive
from this class, to report an error.
4 -5
To obtain the value of a specific CGI environment variable, use the
getHeaderNames() or getAttribute() methods with the string parameter value
"com.tandem.servlet.parameter-name"
where parameter_name is the name of the desired environment variable.
The code fragment in Example 4-1 illustrates the use of getAttribute to obtain and
print an enumeration of environment variables and their values:
Example 4-1. Use of getAttribute() Method to Obtain Environment Variables
out.println("</pre>");
Enumeration x =
(Enumeration)req.getAttribute("com.tandem.servlet.attribute_names");
out.println("<pre>");
while (x.hasMoreElements()) {
String pn = (String)x.nextElement();
out.println(pn +" = " + req.getAttribute(pn) );
}
out.println("</pre>");
Context-Management
Because the same servlet or JSP can be running in multiple processes, a series of
requests to the servlet class may not be serviced by the same process. This situation
has implications for the design of a servlet:
•
•
No data maintained by a servlet can be presumed to apply to the servlet class
collectively. Class data applies only within a process.
Context created in memory by one request may not be available to subsequent
requests because subsequent requests might not run in the same data space.
Therefore, a servlet that needs to make context available should write the context
to disk before returning.
Unless you are using session tracking, a feature of the Servlet API, the only way to
ensure that the same process services a series of requests is to limit the web container
to one process (Maxservers=1). A ServerClass limited in this way retains the quality
of persistence but loses the scalability advantage of a ServerClass. To support
sessions, the web container’s Numstatic and Maxservers attributes must have the
same value unless you are using persistent sessions and turn off session-based load
balancing. For information about turning off session-based load balancing.
Multithreading – Spawning Java Threads
The NSJSP product supports spawning Java threads from within a servlet or JSP.
When multiple users access a servlet simultaneously, the web container does not
instantiate a new servlet instance for each user. When a client access the servlet, the
service() method is invoked in a separate thread. Therefore, each client is sharing
4 -6
Request and Response Streams
the data of the servlet. In most cases this arrangment is the most efficient method of
handling multiple requests for servlets that do not contain client data.
Be aware that multithreading may require you to allow for threading synchronization.
Every client has access to each field in the servlet: the fields of the servlet are being
shared by each client. If a field contains client-specific data, the access to that field
must be synchronized.
Caution. Exercise caution when you use TS/MP (Pathway) or iTP WebServer commands that
stop ServerClass executions in environments where threads are spawned from within the web
container. Stopping the web container immediately stops all execution threads that are running
within the web container. There are no runtime checks that allow the web container to stay up
and wait for all threads to finish running when a TS/MP (Pathway) STOP command has been
issued against the web container. If you stop the web container accidentally, restart the iTP
Secure WebServer environment or THAW,START the servlet server if you have issued the
FREEZE,STOP command.
The SingleThreadModel interface has been deprecated in the Servlet 2.4
specification. You can achieve the same functionality using a singleton Java class.
Request and Response Streams
The CGI interfaces of the iTP Secure WebServer implement standard input and output
as streams. Therefore, the length of a request to or response from a servlet is
unlimited.
The NonStop system interprocess communications mechanism is not inherently
stream-oriented. The Pathway CGI interfaces simulate stream behavior by accepting a
series of interprocess messages as streams.
You can use the Region directive to restrict access to a JSP or servlet by protecting
its URL. In addition, you can use Safeguard to restrict access to any disk, file, or
process on a NonStop system.
Beyond these rudimentary types of protection, all servlets are considered trusted. The
fact that all servlets must be loaded from the local iTP Secure WebServer environment
tends to limit, but does not rule out, breaches of security. Specifically, neither the iTP
Secure WebServer nor the NSJSP places any restrictions on what a servlet does,
beyond restrictions imposed by NonStop Server for Java.
The web container inherits the security attributes of the Pathmon environment.
International Character Set Support
The iTP Secure WebServer supports international character sets (Unicode) for input to
and output from the servlet environment. No specific configuration procedures are
required to use international character sets with servlets/JSP.
4 -7
Reserved Cookie Names
Reserved Cookie Names
The cookie names JSESSIONID, JSESSIONIDSSO, NSJSPADMINSSO, and
iTPWebSessionId are reserved for internal use. According to the servlet API the
name of the cookie must be JSESSIONID and the name of the session-tracking
parameter used in the URL rewriting must be jsessionid.
javax.servlet.request.X509Certificate
javax.servlet.request.X509Certificate returns an array of one object of
type java.security.cert.X509Certificate that is the leaf certificate of the
client certificate chain for all secure requests (using the HTTPS protocol) with clientside certificates passed to the server.
4 -8
JMX Based Administration
NSJSP allows administering container objects using JMX technology to manage
internal objects (for example, Servers, Services, Hosts, Contexts, Loggers, and other
resource entities).These objects are administered using the admin web application
which is described in admin Web Application on page 4-10.
In prior releases, you were required you to bring down the entire NSJSP container and
change the configuration file (iTP_server.xml) to modify container objects. With the
support of JMX MBeans for manageability, you can modify objects while the container
is running. Modifying objects online enhances the NSJSP container's availability.
The container objects you can administer online using JMX technology are:
•
•
•
•
•
•
•
•
•
•
•
•
Server Object on page C-1
Service Object on page C-2
Connector Object on page C-2
Engine Object on page C-5
Host Object on page C-6
Context and Default Context Objects on page C-7
Loader Object on page C-11
Logger Object on page C-12
Manager Object on page C-13
Resources on page C-16
Realm Object on page C-21
Valve Object on page C-27
For detailed information about the objects, see Appendix C, NSJSP Container Objects.
For more information about JMX MBeans, see the Apache Jakarta Tomcat 5
Servlet/JSP Container documentation at http://jakarta.apache.org/tomcat/tomcat-5.0doc/index.html.
4 -9
The admin web application provides a graphical user interface (GUI) for administering
container objects and resource modifications using JMX MBeans. In addition, an
MBean invocation can also be done using the manager web application by specifying
the target object (or resource name), the invoking method, and the associated
argument list in the query string of the URI.
The admin web application uses the Apache Struts framework to implement the
administration GUI-based interface. The Struts framework helps you design
applications based on the Model-View-Controller (MVC) design paradigm. The admin
web application uses JSP pages for the View component. These JSP pages create
HTML forms in which the operator can specify object attributes and initiate various
object operations.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Overview and Architecture on page 4-10
Login and Security Considerations on page 4-12
Administering Server Objects on page 4-16
Administering Service and Engine Objects on page 4-17
Administering Connector Objects on page 4-19
Administering Host Objects on page 4-20
Administering Context Objects on page 4-20
Administering Logger Object on page 4-22
Administering Realm Objects on page 4-22
Administering Resources on page 4-26
Resource Links on page 4-27
Inconsistent Conditions on page 4-30
nsjspadmin.config ServerClass Configuration File on page 4-31
nsjspadmin.ssc on page 4-31
servlet ServerClass Restrictions on page 4-31
Access Security Considerations on page 4-31
iTP_server.xml Configuration File on page 4-32
For more information about the Struts framework, see http://struts.apache.org.
The NSJSP admin operations do not behave the same way as the Apache Tomcat
implementation. The Apache Tomcat implementation is a standalone application.
4- 10
When an admin operation is run in Tomcat (after the Save button is clicked), the
change takes effect immediately. For example, a change made to the Debug Level
property of the Server object directly affects the Tomcat server at the time the Save
button is clicked. Later, the Commit Changes command simply serializes the Tomcat
server configuration back to the server.xml file.
An NSJSP 5.0 container is a TS/MP ServerClass, which consists of multiple server
processes. A simple change made to the container requires NSJSP to propagate it to
every running server in the ServerClass as well as any subsequently started dynamic
servers. Thus, the NSJSP container can maintain a consistent service among its
server processes. To achieve this, a new ServerClass, named nsjspadmin is a frontend to the administration and management functions. The SERVLET ServerClass
handles just the application requests.
The admin requests are first routed to the nsjspadmin ServerClass (by adding a new
Filemap to the iTP WebServer). Through the nsjspadmin server, the operator
browses objects and performs updates. When an update is made by selecting the
Save button, the save operations do not change the object properties in the SERVLET
ServerClass immediately. At this time, only the nsjspadmin server remembers the
saved changes. When the Commit Changes operation is processed, the nsjspadmin
server updates the iTP_server.xml configuration file and broadcasts all the saved
changes to all running server instances of the SERVLET ServerClass. Only at this time
are the object properties actually changed.
Note. If the nsjspadmin server fails for any reason (or the server is stopped), the servlet
ServerClass continues running. All web applications except admin and manager are still
accessible.
4- 11
Login and Security Considerations
Figure 4-1 shows that the operator commands received by the iTP WebServer are
directed to the nsjspadmin server. Figure 4-2 shows that when the Commit Changes
button is clicked, the nsjspadmin server first updates the iTP_server.xml
configuration file, then broadcasts all the previously saved changes in a chunk to every
running server instance of the SERVLET ServerClass. As a result, the subsequently
created servers have the same configuration as the currently running servers.
Figure 4-1. Operator Save Command
object browses,
updates, &
“SAVE”
nsjspdmin
httpd
httpd
httpd
server
Figure 4-2. Operator Commit Changes Command
Select “Commit
Change” button
httpd
httpd
httpd
nsjspdmin
server
servlet
servlet
broadcast Servlet
update
Read by new
dynamic servers
iTP_server.xml
The admin web application uses the FORM method for its login control and uses the
admin role for its access control (by default). You should configure the admin web
application in a private virtual host so that security is not a concern. However, if you
4- 12
need remote access to the admin web application, you should run the admin web
application over SSL with proper security setup.
Figure 4-3 displays the admin login page of the NSJSP admin web application. You
may log into the admin web application by entering your user name, password, and
then clicking the Login button. If you are not authorized to access the admin web
application or the authentication process fails, an error page is displayed.
Figure 4-3. Admin Login page
4- 13
Having completed the authentication and authorization process, the admin page
displays the entire NSJSP server's container objects in an expandable directory-tree
structure as shown in Figure 4-4.
Figure 4-4. Admin Initial page
Every tree node represents an object node. The open and (+) sign indicates an
expandable object node. By selecting, you can fold or unfold a specific object node.
The (-) sign indicates a non-expandable object node. To show and modify a specific
node you select the label of an object node. The object tree is on the left-hand side of
the frame. The frame on the right is for the view of a selected object. The two buttons
on the top frame are the Commit Changes button and Log Out button.The Commit
4- 14
Changes button commits all of the previously saved operations and updates the
iTP_server.xml configuration file.
4- 15
Administering Server Objects
Administering Server Objects
Figure 4-5 displays the views of a Server object. The Server Actions drop-down menu
lists the actions you can select, for example:
•
•
Create a new Service
Delete existing Services
Figure 4-5. Server Object View/Modify page
The Server object properties are described in detail in Server Object on page C-1.
4- 16
Administering Service and Engine Objects
Figure 4-6 displays the views of a Service object. The Service Actions drop-down
menu lists the available actions for a Service object, for example:
•
•
•
•
Delete existing Connectors
Create a new Host or delete existing Hosts
Create a new Logger or delete existing Loggers
Create a new Valve or delete existing Valves
Figure 4-6. Service and Engine Object View/Modify page
The Engine object is nested inside the Service object because a one-to-one
relationship exists between the two.
4- 17
The Service object properties are described in detail in Service Object on page C-2.
4- 18
Administering Connector Objects
4 Programming and Management Features
Administering Connector Objects
Figure 4-7 displays the views of a Connector object. The Connector Actions drop-down
menu lists one available action:
•
Delete this Connector. (You cannot add or delete an NSJSPCoyoteConnector).
Figure 4-7. Connector Object View/Modify page
The Connector object properties are described in detail in Connector Object on
page C-2.
Note. NSJSP supports only one NSJSPCoyoteConnector in a server.
4- 19
Administering Host Objects
Administering Host Objects
Displays the views of a Host object. The Host Actions drop-down menu lists the
available actions, for example:
•
•
•
•
•
•
Create a new Alias or delete existing Aliases
Create a new Context or delete existing Contexts
Create new User Realm or delete User Realms
Create a new Valves or delete existing Valves
Delete this host
An Alias is the alias of a Host object. A Host object can have multiple Aliases. The
Host object properties are described in detail in Host Object on page C-6.
Administering Context Objects
Figure 4-8 displays the views of a Context object. The Context Actions drop-down
menu lists the available actions, for example:
•
•
•
•
Create a new Valve or delete existing Valves
Create a new User Realm or delete existing User Realms
Delete this Context
Context is also associated with a Class Loader and a Session Manager. Therefore, all
objects share the same view as the Context object.
4- 20
Administering Default Context Objects
Figure 4-8. Context Object View/Modify page
The supported session managers are: NSJSPStandardManager and the
NSJSPPersistentManager. The NSJSPStandardManager properties and
NSJSPPersistentManager properties are described in detail in Manager Object on
page C-13.
Administering Default Context Objects
Displays the views of a DefaultContext object. There is no available actions in the
DefaultContext Actions drop-down menu.
A DefaultContext may be created at the Engine or Host levels. In order to configure a
DefaultContext, edit the $NSJSP_HOME/conf/iTP_server.xml configuration file
directly and restart the iTP WebServer environment.
4- 21
Administering Logger Object
The admin web application does not allow a DefaultContext object to be created online
as this affects all the running Contexts at the Engine or Host levels.
Administering Logger Object
Displays the views of a Logger object. The Logger Actions drop-down menu lists the
available action, for example:
•
Delete this Logger
The Logger object properties are described in detail in Logger Object on page C-12. In
addition, Logger objects may have their type-specific logger properties. The
NSJSPFileLogger type-specific properties are described in detail in Logger Object on
page C-12.
Administering Realm Objects
Figure 4-9 displays a view of a JAASRealm object. NSJSP supports several types of
Realms. Different types of Realm may have their own type specific properties.
Note. The JDBCRealm, MemoryRealm, UserDatabaseRealm, DataSourceRealm,
JNDI Realm, and JAASRealm properties are described in detail in Realm Object on
page C-21.
4- 22
Figure 4-9. JAASRealm Object View/Modify page
4- 23
4- 24
Administering Valve Objects
4 Programming and Management Features
Administering Valve Objects
This section displays views of Value objects. NSJSP supports several types of Valves:
RemoteHostValve, AccessLogValve, RemoteAddrValve, RequestDumperValve, and
SingleSignOnValve using the admin web application. See Valve Object on page C-27
for a detailed description of the attributes.
4- 25
Administering Resources
Figure 4-10 displays views of Data Sources. The Data Source Actions drop-down
menu lists the available actions, for example:
•
•
Create a new Data Source
Delete existing Data Sources
Figure 4-10. Data Source View/Modify page
The Data Source properties are described in detail in Data Sources on page C-17.
4- 26
Mail Sessions
Displays views of Mail Sessions. The Mail Session Actions drop-down menu lists the
•
•
Create a new Mail Session
Delete existing Mail Sessions
The Mail Session properties are described in detail in Mail Sessions on page C-18.
Environment Entries
Displays views of Environment Entries. The Environment Entry Actions drop-down
menu lists all available actions, for example:
•
•
Create a new Environment Entry
Delete existing Environment Entries
The Environment Entry properties are described in detail in Environment Entries on
page C-18.
User Databases
Displays views of User Databases. The User Database Actions drop-down menu lists
the available actions, for example:
•
•
Create a new User Database Object
Delete existing User Database Objects
The User Database properties are are described in detail in User Databases on
page C-19.
Resource Links
Displays views of Resource Links. The Resource Link Actions drop-down menu lists
•
•
Create a new Resource Link Object
Delete existing Resource Link Objects
The Resource Link properties are described in detail in Resource Links on page C-21.
4- 27
Administering User Definition
This section displays views of the Users List, Groups List, and Roles List.
Users List
Figure 4-11 displays a view of the Users List. The User Actions drop-down menu lists
•
•
•
Create new User
Delete existing Users
List existing Users
Figure 4-11. Users List page
4- 28
The Users List properties are described in detail in Users on page C-20.
Groups List
Displays views of the Groups List. The Groups List Actions drop-down menu lists the
•
•
•
Create new Group
Delete existing Groups
List existing Groups
The Group properties are described in detail in Group on page C-20.
Roles List
Displays views of the Roles List. The Role Actions drop-down menu lists available
actions, for example:
•
•
•
Create a new Role
Delete existing Roles
List existing Roles
The Role properties are described in detail in Role on page C-20.
4- 29
Inconsistent Conditions
Inconsistent Conditions
When the Commit Changes button is clicked all previously saved changes are sent to
every server processes of the SERVLET ServerClass. Because these commands have
already been validated and processed by the nsjspadmin ServerClass, no errors are
expected from the SERVLET ServerClass. If a server instance returns an error, the
server is marked as inconsistent and an warning message is returned to the operator.
Currently, the solution for the inconsistent server is to stop the server so that the
SERVLET ServerClass can maintain its consistency. Figure 4-12 displays an
inconsistent warning.
Figure 4-12. Inconsistent Warning
The returned warning page lists the NonStop process names of the inconsistent
servers. The operator can stop these server processes immediately by clicking the
4- 30
Stop button. The Ignore button allows these inconsistent servers to continue to run.
The operator should stop these processes manually.
All occurrences of inconsistency are logged to the associated Logger objects. When a
servlet server process catches an exception while processing an admin command, the
servlet server process automatically stops itself. The warning page lists those servlet
server processes that exit by themselves. However, if an exception is caught before
the admin web application processes the admin request, the exception is returned to
the nsjspadmin ServerClass. The warning page lists the server process names and
allows the operator to stop them.
If instructed to stop the inconsistent servers, nsjspadmin first chooses a graceful stop
method which allows the inconsistent servers to flush all their session information
before they are stopped. If this graceful stop method fails to stop any of the
inconsistent servers, a forced stop method is used. Depending on the flush of session
information, you may experience servers lingering for a while since the response to
your stop command is returned before the inconsistent servers are actually stopped.
The nsjspadmin.config file is created for the configuration of the nsjspadmin
ServerClass. Although the nsjspadmin ServerClass is in the same TS/MP
environment as the SERVLET ServerClass, it still has its own configuration file to
prevent the attributes of the nsjspadmin ServerClass from being changed
accidentally. Most of these attributes should be maintained as the installed value.
For detailed information about configuirng the nsjspadmin.config file, see
nsjspadmin.config on page 3-5.
nsjspadmin.ssc
A symbolic link named nsjspadmin.ssc is added to the bin directory of the iTP
WebServer installation. (The same location where servlet.ssc resides)
servlet ServerClass Restrictions
The nsjspadmin ServerClass handles admin-related requests. Any attempts to
access admin and manager web applications from the SERVLET ServerClass directly
are rejected with error 503: Service Unavailable.
Access Security Considerations
If the online administration (configuration and management) option is not selected at
setup time, then no user with the admin or manager role is added to the
$NSJSP_HOME/conf/nsjspadmin-users.xml configuration file. In order to access
the admin and manager web application, you will need to add users with these roles
manually.
4- 31
iTP_server.xml Configuration File
The commit change operation causes the nsjspadmin server to serialize the current
configuration back to the NSJSP's iTP_server.xml configuration file. At the same
time, the current version of the iTP_server.xml file is preserved using the following
naming convention:
iTP_server.xml.yyyy-mm-dd.hh-mm-ss
where
yyyy-mm-dd is the year-month-day
hh-mm-ss is the hour-minutes-seconds (in 24-hour format)
The yyyy-mm-dd.hh-mm-ss is the timestamp when the commit change operation is
performed. For example, the iTP_server.xml.2004-06-21.14-43-39 is created
to preserve the configuration file before the commit change performed at 2:43:39 PM
on June 21st, 2004.
These preserved iTP_server.xml files are located in the
$NSJSP_HOME/conf/backup/ directory.
The preserved Context configuration files (with names of the form <contextname>.xml.yyyy-mm-dd.hh-mm-ss) are located in the
$NSJSP_HOME/conf/NSJSP/<host-name>/backup/ directory.
The default location is the $NSJSP_HOME/conf/NSJSP/localhost/backup/
directory.
Content of the iTP_server.xml File
When the nsjspadmin server serializes its configuration back to the
iTP_server.xml file, the following changes occur in addition to the configuration
changes:
•
•
•
All comments are removed.
All contexts are serialized including those that were dynamically deployed.
All attributes are listed including those that were omitted (using default values).
As a result, the iTP_server.xml may not be as readable as it was previously. Be
careful if you use a text editor to make subsequent changes.
Role Back a Commit Change Operation
Because these iTP_server.xml files are preserved, you can role back a commit
change operation manually by using the following steps:
1. Shutdown the iTP WebServer environment.
2. Rename the current iTP_server.xml to iTP_server.xml.temp.
4- 32
3. Rename the previously preserved iTP_server.xml.yyyy-mm-dd.hh-mm-ss
file to iTP_server.xml.
4. Depending on the nature of the commit change operation, rename the appropriate
context configuration files <context-name>.xml files to <contextname>.xml.temp.
5. Depending on the nature of the commit change operation, rename the previously
preserved context configuration files <context-name>.xml.yyyy-mm-dd.hhmm-ss files to <context-name>.xml wherever appropriate.
6. Restart the iTP WebServer environment.
Cleaning Up Preserved iTP_server.xml Files
A periodic cleanup operation may be required because the number of files may grow
over time. The operator is responsible for keeping track of the older versions of the
iTP_server.xml files.
A utility script nsjsp_cleanConfigBackups (located in the $NSJSP_HOME/conf
directory) is provided to help the operator cleanup older backup configuration files. See
nsjsp_cleanConfigBackups on page 5-22 for more details.
4- 33
4- 34
5
Manager Web Application
The managerweb application provides the management functions for all web
applications in the NSJSP container. In prior releases, the management functions were
provided using the nsjsp_manager (an interactive shell script). The nsjsp_manager
is no longer supported. The manager web application replaces nsjsp_manager and
provides the same functionality.
NSJSP uses the nsjspadmin ServerClass to handle all the web application
management front-end functions. Figure 5-1 shows the nsjspadmin ServerClass that
receives a manager request and broadcasts the corresponding command to every
server processes in the servlet ServerClass after it has done its processing.
Figure 5-1. Manager Web Application Architecture
Web Appl
manager
cmds
httpd
httpd
httpd
Broadcast
cmds
nsjspad
min
Servlet
servlet
servlet
Accessing the manager Web Application
The NSJSP web application manager is accessed using the following URIs:
/manager URI (http://<host-name>:<port-number>/manager)
Security Constraints
By default, the access control to /manager differs from access controls to the admin
web application so that the manager web application can be managed separately. The
default authorization constraint assigned to the manager web application is manager.
You can change the security constraints by modifying the manager web application's
deployment descriptor.
5 -1
The manager GUI Interface
Figure 5-2. Manager Web Application Login Dialog
The manager web application lists all the configured web applications in the NSJSP
container (including both static configured and dynamically deployed web applications)
after the user has logged in.
Figure 5-3 shows the manager GUI which contains the following sections:
•
•
•
•
•
Message Box on page 5-3
Manager Area on page 5-4
Application Area on page 5-4
Deploy Area on page 5-5
NSJSP Information Area on page 5-6
5-2
Figure 5-3. Manager Web Application User Interface
Message Box
The Message box lists the result of last run command. This message shows the result
of stopping the /servlet_jsp/jsp-examples context:
5-3
Example 5-1. Message Box
Manager Area
The Manager area contains links to the following commands:
•
Lists Applications
Refreshes the display which lists the configured web applications in the NSJSP
container.
•
HTML Manager Help
The help document for the HTML-based manager web application.
•
Manager Help
The Manager App HOW-TO document which describes the access control of the
manager application and supported commands.
•
NSJSP Status Summary
Retrieves the current NSJSP container status. For detailed information about
NSJSP Status command.
Figure 5-4. Manager Area
Application Area
The Application area contains a list of the currently configured web applications. The
application area lists the application's path, display name, running status, number of
active sessions, and the operational commands for these applications.
Figure 5-5 shows an example of the Application area. In the example, the /jspexamples web application uses the path of /servlet_jsp/jsp-examples. The
Display Name is JSP 2.0 Examples. It is currently stopped and does not have any
active session. It supports the stop, reload, and undeploy commands.
5-4
Figure 5-5. Application Area
Deploy Area
Web applications can be installed using files or directories located on the server, or
you can upload a web application archive (WAR) file to the server. Figure 5-6 displays
the Deploy area. The Context Path field is optional. If the Context Path field is omitted,
the directory name or the war file name without the .war extension is appended to
/servlet_jsp/ and the entire string is used as the new application's context path.
Figure 5-6. Deploy Area
If you specify an application context path which does not have the prefix of
/servlet_jsp in the Context Path field, it is recommended you check the
"Automatically add Filemap" checkbox. Otherwise, you must manually add the context
path as a Filemap in your iTP WebServer configuration and restart your iTP
WebServer environment in order to access the new web application.
The WAR or Directory URL field specifies a URL for the application's directory or a
WAR file on the HP NonStop server. For example, if the application is located in the
directory /usr/appls/newAppl you must specify file:///usr/appls/newAppl
in the WAR or Directory file URL field.
5-5
You can also install a web application directory or WAR file located in your host's
appBase directory (see Host Object on page C-6 for appBase directory) by specifying
the WAR file name without the .war extension in the WAR or Directory URL field. For
example, if you had a WAR file named myAppl.war residing in your host's appBase
directory, you could specify myAppl in the WAR or Directory URL field.
If the host's deployXML property is enabled (see Host Object on page C-6 for
deployXML property), you could install a web application using a Context configuration
<context>.xml file and an optional WAR file or web application directory. The
Context Path field is not used in this case. A Context configuration <context>.xml
file is a valid XML document for a web application Context. For example:
<Context path="/myAppl" docBase="/usr/appls/myAppl" />
You can also upload a WAR file from a workstation and install it into your virtual host.
The name of the WAR file without the .war extension is used as the context path of
the new application. You can use the Browse button to select a WAR file to upload to
the server from your workstation.
The "Automatically add context path as Filemap" checkbox adds a new Filemap to the
iTP WebServer configuration using the specified context path (using this Filemap is
optional).
NSJSP Information Area
The NSJSP Information area contains the:
•
•
•
•
•
•
NSJSP Version: For NSJSP, it is "NonStop™ Servlets For JavaServer Pages™
v5.0".
JVM Version: For example, 1.4.2_04-b05.
JVM Vendor: Hewlett-Packard Company.
OS Name: NONSTOP_KERNEL.
OS Version: For example, G06.
OS Architecture: For example, mips.
Figure 5-7. NSJSP Information Area
5-6
NSJSP Status Command
5 Manager Web Application
Access the NSJSP Status command from the link or the /manager/status URI.
NSJSP allows you to choose from three levels of detailed information:
•
•
•
The Entire Container
The Summary of Servers
Detail Status and Statistics of Individual Server Instance
NSJSP Container Status
The NSJSP container status has following sections:
•
•
•
•
•
Manager on page 5-8
NSJSP Information on page 5-9
Server Processes on page 5-9
JVM on page 5-10
Connectors on page 5-10
5-7
Figure 5-8. NSJSP Status Summary Page
Manager
•
Lists Applications
container.
•
HTML Manager Help
5-8
•
Retrieves the summary status of the NSJSP container. For detailed information
about the NSJSP Status command, see NSJSP Status Command on page 5-7.
•
Complete NSJSP Status
Retrieves detailed status information.
Example 5-2. NSJSP Status Summary Manager Area
NSJSP Information
•
•
•
•
•
•
NSJSP Version: For NSJSP, NonStop™ Servlets For JavaServer Pages™ v5.0.
JVM Version: For example,1.4.2_04-b05.
Example 5-3. NSJSP Status Summary Information Area
Server Processes
Lists an entry for every running server instance. This entry links to the next level of
detailed information for the server process. Example 5-4 shows the server processes.
Example 5-4. NSJSP Status Summary Server Processes Area
5-9
JVM
The aggregation of JVM statistics counters of all NSJSP server processes. The JVM
title links to the JVM Statistics Detail which lists the JVM statistics of every running
server instance. Example 5-5 shows an example of the status summary JVM area.
Example 5-5. NSJSP Status Summary JVM Area
Example 5-6. NSJSP Status (JVM) Statistics Detail Area
Connectors
The aggregation of statistics counters of the Connectors for all NSJSP server
processes. Example 5-7 shows an example of the connector summary area.
Example 5-7. NSJSP Status Summary Connector Area
The title of the Connectors links to the Connector Summary Detail which lists the
connector summary of every NSJSP running server. Figure 5-8 shows an example of
the connector summary detail.
5- 10
NSJSP Server Instance Detail
Example 5-8. NSJSP Status (Connector) Statistics Detail Area
The NSJSP Server Instance Detail lists the complete status and statistics information
for an NSJSP server instance. It is accessed using the link listed in the Server
Instances. The NSJSP Server Instance Detail has the following sections:
•
•
•
•
•
Manager on page 5-12
JVM on page 5-13
Connector Summary on page 5-13
Web Applications on page 5-18
5- 11
Example 5-9. NSJSP Status ($Z5BA) Page
Manager
•
Lists Applications
container.
•
HTML Manager Help
•
5- 12
Retrieves the summary status of the NSJSP container
•
Retrieves detailed status information.
NSJSP Information
The NSJSP Information area contains the following:
•
•
•
•
•
•
JVM
Lists the JVM memory usage of this server instance.
Connector Summary
Lists the connector statistics information as well as the status of the currently running
threads.
5- 13
5- 14
5 Manager Web Application
Web Applications
Lists all of the configured web applications. Every entry is a link to the detail display of
the application. Example 5-10 shows an example of the application list area.
Example 5-10. NSJSP Status ($Z5BA) Application List Area
Example 5-11 shows the detail display of the servlets-examples web application.
Example 5-11. NSJSP Status ($Z5BA) localhost/servlet_jsp/servlets-examples
Web Application Statistics Area
5- 15
The complete NSJSP Status lists the aggregation of all status and statistics counters
for all NSJSP server processes. It is accessed using the link listed in the Manager Area
of the NSJSP Status page. The NSJSP Status has the following sections:
•
•
•
•
•
Manager on page 5-18
JVM on page 5-18
Connectors on page 5-18
Web Applications on page 5-18
5- 16
Example 5-12. Complete NSJSP Status Page
5- 17
Manager
•
Lists Applications
Refreshes the display which lists all of the configured web applications in the
NSJSP container.
•
HTML Manager Help
•
Retrieves the summary status of the NSJSP container.
•
Retrieves complete NSJSP status information.
NSJSP Information
The NSJSP Information area contains the following:
•
•
•
•
•
•
JVM
Lists the aggregated JVM memory usage of the entire NSJSP container.
Connectors
Lists the connector statistics information as well as the status of the currently running
threads.
Web Applications
Lists the configured web applications with hyperlinks to their detailed statistics.
Example 5-13 shows the application list area.
5- 18
Example 5-13. Complete NSJSP Status Application List Area
Example 5-14 shows the detail display of the NSJSP Status
localhost/servlet_jsp/servlets-examples and localhost/manager Area.
Example 5-14. Web Application Statistics Summary
5- 19
Cleaning Up the NonStop SQL Session Data
Cleaning Up the NonStop SQL Session Data
Sessions saved by the NonStopSQLJDBCStore to a NonStop SQL database may
never get cleaned up and remain as orphan sessions when
•
•
The sessions are saved on an NSJSP container restart and never accessed after
the restart,
Or the seesion were backed up or swapped out to the NonStop SQL database and
not accessed again after the NSJSP container failed and was restarted.
Over time, the database may become very large.
The iTPWS_INSTALL_DIR/bin/nsjsp_cleanSessionData script enables you to
clean up the sessions that have expired prior to a specified number of days (the nDays
parameter). Run this script periodically as part of a cron job or any other administrative
process.
Example 5-15. SQL Session Data Cleanup Script
Usage:
where
nsjsp_cleanSessionData
nDays:
nDays
Number of days for which session data is to be
preserved/saved. Sessions that have expired more
than 'nDays' ago will be deleted. A value of zero (0)
will delete all the expired sessions.
Example 5-16. Using the nsjsp_cleanSessionData Script
osh>
/usr/tandem/webserver/bin/nsjsp_cleanSessionData
5
Sessions that have expired at least 5 days ago will be deleted from the
NonStop™ SQL Database.
5- 20
Managing Constraints
Managing Constraints
The manager web application has the following constraints:
•
•
•
The manager web application only manages the web applications in a virtual host.
Therefore, you must configure a manager web application for every virtual host.
The manager web application manages only the running NSJSP container.
Any commands or changes made using the manager web application affects only
the running server processes. Therefore, any new dynamic server processes
created after the change may be inconsistent with the existing servers. This
behavior is exactly the same as the nsjsp_manager utility behavior used by prior
versions of NSJSP.
This section lists some of the manager commands that may cause the inconsistency.
Stop Command
The Stop command stops a specific application only in the running server processes.
A dynamic server created after the command may still have the same application
running. The Stop command always returns the following warning:
Warning: Command applied only to the running servers.
Any servers created subsequently may be inconsistent.
Install and Undeploy Commands
Both the Install and Undeploy commands cause the deployed or undeployed web
application to be persisted to the Context configuration file if the application is not
deployed to the default local host's appBase.
Shell Scripts
NSJSP 5.0 introduces the following new shell scripts to ease the managing of the
NSJSP container. These are in addition to the existing nsjsp_cleanSessionData
and nsjsp_cleanlogs.
The nsjsp_migrateSessionStore script is an OSS shell script that aids migrating
a session store from a prior NSJSP release. To run this script, you enter the script
name from your OSS prompt and the script guides you through the migration. An
example of running this script follows:
/h/myInstall/webserver/servlet_jsp/conf: nsjsp_migrateSessionStore
NonStop(tm) Servlets for JavaServer Pages(tm)
Persistent Sessions Migration Script
5- 21
T1222V50_10NOV2005_BASE_V500_2
_________________________________________________________________
Migrates the persistent session data stored in a NonStop(tm) SQL
database for NonStop(tm) Servlets for JavaServer Pages(tm).
Please enter the database table name [$SYSTEM.T1222CAT.SessData] :
$DATA00.MYSESS.SESSDATA
******************************
WARNING
*****************************
The persisted session data stored in a NonStop(tm) SQL Database
will now be migrated to the new schema used in the
NonStop(tm) Servlets for JavaServer Pages(tm) T1222V50_10NOV2005_BASE_V500_1
release.
NonStop(tm) SQL database table name = $DATA00.MYSESS.SESSDATA
**********************************************************************
Do you wish to migrate the persistent session data (y/n) ? y
SQL Conversational Interface - T9191G07 - (01AUG05)
(C) 1987 COMPAQ (C) 2004 Hewlett Packard Development Company, L.P.
>>>>ALTER TABLE $DATA00.MYSESS.SESSDATA
+>+>
ADD COLUMN app_name VARCHAR(255)
--- SQL operation complete.
>>>>
>>
End of SQLCI Session
Note:
DEFAULT
""
NOT NULL;
In the future, if you do not wish to be prompted for the
Persistent Session catalog, then please edit your setup
information file located at:
./.nsjsp_setup.info
Edit the the two entries for T1222SessionCatalog and
T1222SessionTable at the very end of this file. Replace the
persistent session catalog/subvolume [$SYSTEM.T1222CAT] with
the location of your persistent session catalog/subvolume.
Ensure that the dollar sign ($) is properly escaped.
/h/myInstall/webserver/servlet_jsp/conf:
The nsjsp_digestPassword script is an OSS shell script which allows you to
generate a digested form of your password. The syntax is:
{digest algorithm}
{clear-texted password}
An example:
/h/myInstall/webserver/servlet_jsp/conf: nsjsp_digestPassword MD5 myPassword
myPassword:deb1536f480475f7d593219aa1afd74c
/h/myInstall/webserver/servlet_jsp/conf:
The nsjsp_cleanConfigBackups script is an OSS shell script which helps the
operator to cleanup the older backup configuration files. NSJSP 5.0 automatically
saves copies of all of the configuration files such as the iTP_server.xml and all of
the context configuration files residing in the $NSJSP_HOME/conf/NSJSP/<hostNonStop Servlets for JavaServer Pages (NSJSP) System Administrator’s Guide—525644-002
5- 22
name>/ directories before they are updated using the admin web application.
Overtime, these backup files may need to be cleaned up. The syntax is:
[-h]
[-s]
[-d
<cfg_backup_dir>]
[-n
<number_of_days>]
where
-h
prints out help (usage information).
-s
runs in silent mode suppressing messages.
<cfg_backup_dir>
Additional config backup directory to search for backup configuration files. This is
in addition to the
/h/myInstall/webserver/servlet_jsp/conf/backup and
/h/myInstall/webserver/servlet_jsp/conf/NSJSP/localhost/backu
p directories, which are always cleaned up.
<number_of_days>
Number of days to filter cleaning up backup configuration files. Files that have a file
name older than these many days will becleaned up (deleted). Default is 10 days.
5- 23
5- 24
6
•
•
•
•
•
•
•
Logs and Error Conditions
NSJSP Logging on page 6-1
Logging Configuration on page 6-1
Status Information on page 6-4
Log Files Rollover on page 6-4
Log Files Cleanup Script on page 6-4
Recovery Procedure for Broadcast Error on page 6-5
EMS Message Format on page 6-8
NSJSP Logging
NSJSP processes report configuration and status information to the standard output
(STDOUT) file, and report errors and exceptions to the EMS log and standard error
(STDERR) files and other log files. Depending on your configuration, these files are
located as follows:
One or both of the following logs are available for tracking error conditions:
/usr/tandem/webserver/logs/servlet.log
This is the servlet output file (STDOUT of the NSJSP Process).
/usr/tandem/webserver/logs/servlet_error.log
This is the servlet error output file (STDERR of the NSJSP Process).
In addition, the NSJSP log files are located by default at:
/usr/tandem/webserver/servlet_jsp/logs/
The log files created in this directory depend on how you configure your NSJSP
installation through the iTP_server.xml file and the context.xml files. The
default installation, which uses the multiple log files option, creates the following
three log files in this directory:
NSJSP_Catalina.YYYY-MM-DD.log
localhost.YYYY-MM-DD.log
localhost_examples.YYYY-MM-DD.log
Note that /usr/tandem/webserver/ is the default location for the iTP Secure
WebServer installation. The rest of the path is also configurable.
Logging Configuration
The <Logger> tag is used to configure application specific logging in the NSJSP
container and can be specified in either the iTP_server.xml or the context.xml
configuration files (<context>.xml). The <Logger> tag enables you to redirect all the
6-1
Switching From Multiple Log Files to a Single Log
File
log messages to a single log file or to multiple log files. The default logging option is to
use multiple log files. In case of the single log file option, all output is sent to a single
log file (that is, servlet.log).
Example 6-1 shows an example on how to use the <Logger> tag to redirect all the log
messages to a file myApp.<YYYY-MM-DD>.log using time stamped log messages.
Example 6-1. Logger Configuration
<Logger
className="com.tandem.servlet.catalina.logger.NSJSPFileLogger"
prefix="myApp." suffix=".log"
timestamp="true" />

The <Logger> tag is used to configure the logging options at the Engine, Host or
Context levels in the NSJSP Container. The <Logger> tag at a subordinate level
overrides the logging configuration specified at a higher level.
For example, a <Logger> tag at the Context level overrides the logging configuration
in effect for the Host or Engine.
In addition, the NSJSP Container uses "Commons Logging" to have a consistent
logging mechanism for all internal components. The "Commons Logging" configuration
is controlled using the commons-logging.properties file in the
$NSJSP_HOME/common/classes/ directory and allows you to specify custom
logging implementations to use. The default NSJSP configuration uses a simple
logging implementation class com.tandem.servlet.logging.NSJSPSimpleLog,
which logs all messages at the "info" level.
The $NSJSP_HOME/common/classes/simplelog.properties file contains the
configuration for the NSJSPSimpleLogger class.
For more information about "Commons Logging" including how to configure and use it,
see the documentation at http://jakarta.apache.org/commons/logging/.
In summary, the <Logger> tag in the iTP_server.xml or the context.xml
configuration files (<context>.xml) along with the "Commons Logging" configuration
controls the logging configuration in the NSJSP Container.
The default logging option uses multiple log files.
Switching From Multiple Log Files to a Single Log File
If you are switching from the multiple log files option (the default) to the single log file
option, perform the following steps:
1. Stop the NSJSP container as described under Stopping NSJSP on page 2-7.
2. Navigate to your /conf subdirectorys:
cd
$NSJSP_HOME/conf
6-2
Switching From a Single Log File to Multiple Log
Files
3. Use the DIFF program to compare the iTP_server.xml with the
iTP_server.xml.sample and save the changes.
4. Back up the iTP_server.xml file.
5. Copy the iTP_server-singleLog.xml.sample to the iTP_server.xml file.
6. Delete the iTP_server.xml.sample and create the
iTP_server.xml.sample by symbolically linking to the iTP_serversingleLog.xml.sample file:
ln -s iTP_server-singleLog.xml.sample
iTP_server.xml.sample
7. Migrate the changes saved in Step 3 to the iTP_server.xml file.
8. Change the Stderr from servlet.log to servlet_error.log in the
servlet.config file:
Stderr
$root/logs/servlet.log
9. Remove any <Logger> tags in the context.xml configuration files or use the
com.tandem.servlet.catalina.logger.NSJSPSystemLogger.
10. Restart the NSJSP container.
Switching From a Single Log File to Multiple Log Files
If you are switching from the single log file option to the multiple log files option,
perform the following steps:
1. Stop the NSJSP container as described under Stopping NSJSP on page 2-7.
2. Navigate to your /conf subdirectory:
cd $NSJSP_HOME/conf
3. Use the DIFF program to compare the iTP_server.xml with the
iTP_server.xml.sample and save the changes.
4. Back up the iTP_server.xml file.
5. Copy the iTP_server-multiLogs.xml.sample to the iTP_server.xml file.
6. Delete the iTP_server.xml.sample and create the
iTP_server.xml.sample by symbolically linking to the iTP_servermultiLogs.xml.sample file:
ln -s iTP_server-multiLogs.xml.sample iTP_server.xml.sample
7. Migrate the changes saved in step 3 to the iTP_server.xml file.
8. Change the Stderr from servlet.log to servlet.error.log in the
servlet.config file:
Stderr
$root/logs/servlet_error.log
6-3
Status Information
9. Optionally, you can add <Logger> tags with the
com.tandem.servlet.catalina.logger.NSJSPFileLogger to your
context.xml configuration file.
10. Restart the NSJSP container.
Status Information
NSJSP processes report the following kinds of information to the standard output file:
•
•
A message indicating that the NSJSP process has started or failed to start.
Any message written to the standard output file by a servlet or JSP. For example,
the default init() method of a servlet may write a message reporting that it was
invoked.
Log Files Rollover
The rollover feature applies to log files created by NSJSP, except the servlet.log
and servlet_error.log files in the iTPWS_INSTALL_DIR/logs directory.
The NSJSP logger records all logged messages to disk file(s) in a specified directory
(the default is $NSJSP_HOME/logs). The actual filenames of the log files are created
from a configured prefix, the current date in YYYY-MM-DD format, and a configured
suffix. After midnight each night, the next logged message switches to a new log file
(based on the new date), without having to shut down SERVLET ServerClass to switch
logs.
Log Files Cleanup Script
Use the command-line utility nsjsp_cleanlogs as an aid in cleaning up log files
generated by the NSJSP container. This script is located in the
iTPWS_INSTALL_DIR/bin directory. The nsjsp_cleanlogs utility can be used as
part of a cron job or some other form of regularly scheduled administrative process.
By default, log files created by the NSJSP container are named using the specified
prefix, the current date, and the specified suffix in the following format: prefix.YYYYMM-DD.suffix. The nsjsp_cleanlogs script recursively searches the specified
directory for filenames in this format. Files that are older than the specified number of
days and that have an extension matching the specified file extension (suffix) are
deleted. Log file names in other formats are not checked or deleted.
This cleanup utility also provides an option to move log files to the specified directory
for safe-keeping, so you can decide later what to do with the saved log files.
6-4
nsjsp_cleanlogs Syntax
nsjsp_cleanlogs Syntax
nsjsp_cleanlogs [-d log_file_directory] [-n number_of_days]
[-x log_file_extension] [-b backup_directory] -s
nsjsp_cleanlogs Options
-d log_file_directory
The -d option takes one argument, a string, which specifies the directory where
the log files are located. The log file directory path given can be in relative or
absolute format. $NSJSP_HOME/logs is the default directory
-n number_of_days
The -n option requires a number argument. Log files older than the number of
days specified in this option are deleted. Files that are the specified number of
days old are not deleted. By default, files with a date greater than 10 days in the
past are deleted.
-x log_file_extension
The -x option specifies a file extension other than the default, .log. If log files
should end in an extension other than .log, use this option to specify this.
-b backup_directory
The -b option takes one argument, a string, which specifies the directory where
the log files are to be backed up. Prior to removing the files, nsjsp_cleanlogs
copies all the files fitting the specified characteristics to the backup_directory
specified. There is no default backup directory. If the directory specified does not
exist, you are asked if it should be created.
-s
The -s option suppresses the output generated by the nsjsp_cleanlogs
command. By default, nsjsp_cleanlogs runs in verbose mode.
Recovery Procedure for Broadcast Error
The following section discusses how to recover from a broadcast error.
Broadcast
A management related command sent by the nsjspadmin server (the frontend) to all of
the running SERVLET ServerClass processes (the backend) to invoke a management
function or to gather status/statistics information. All broadcasts in the NSJSP are
reliable broadcast, (i.e., a response is returned by every one of the running servers.
6-5
Broadcast Error
Broadcast Error
A broadcast resulted in error. Some, but not all, of the server processes reported error
in their responses. As a result, those failed servers may be out of sync (in an
inconsistent state) from the rest of the servers. For example, if the broadcast is on
behalf of a deploy command, then these failed servers will not have the new
application. This causes an inconsistent service (i.e., requests served by these servers
will be returned with status 404 (resource not found). But, if the broadcast fails for a
status command, then the problem is not so severe (only the returned status does not
contain these failed servers' status). Therefore, the recovery procedures are totally
dependent on the commands that caused the broadcast failure. Listed below are some
guidelines to help you decide how to recover from a broadcast error:
1. For admin commands (commit changes):
Stop all inconsistent servers so that the entire NSJSP container maintains a
consistent service.
The admin application has a broadcast error page that reports the failed server
processes, and has a button for the operator to choose to stop the servers or to
ignore the broadcast failure.
2. For manager commands (status):
This may not constitute a real problem. Continue monitoring the servers by issuing
status commands. If the problem persists, these failed servers may have stalled
and require to be stopped.
3. For manager commands (other than status):
Stop all inconsistent servers so that the entire NSJSP container maintains a
consistent service. The manager has a broadcast error page that lists all the failed
servers and has a button for the operator to choose to stop the servers or ignore
the broadcast failure.
Broadcast Failure
This is a complete broadcast failure. All the server processes returned an error in their
response. This creates a situation where the nsjspadmin server and the configuration
files are out of sync with the currently running SERVLET ServerClass processes.
The recommended recovery procedures are:
•
•
•
Resolve any reported TS/MP or Guardian File System error.
Stop your iTP WebServer environment.
Manually roll back the changes you just committed.
•
Rollback the iTP_server.xml (if needed) using the backup copy in the
$NSJSP_HOME/conf/backup/ directory.
6-6
•
•
Causes of Broadcast Error/Failure
Additionally, you will need to rollback any Context configuration files
(<context>.xml) that have been modified. You can use the backup copies
from the $NSJSP_HOME/conf/NSJSP/<host-name>/backup/ directory.
Restart your iTP WebServer environment.
Causes of Broadcast Error/Failure
A broadcast error could be the result of the following:
1. TS/MP or Guardian File System error:
If a CPU has just failed, the Path Down file system error will likely be received by
the nsjspadmin server. In such a case, no recovery is necessary since the server
process is no longer running. Refer to TS/MP Manual or Guardian System Error
Manual for any other reported errors and their recommended recovery procedures.
2. A temporary stall on the server process. This would cause the broadcast operation
to timeout with Guardian File System error 40.The nsjspadmin server has a default
timeout of 20 seconds for each message sent as part of a broadcast operation. For
example, if an application is running a CPU-bound operation such as prime
number search, the server process is pre-occupied and may not be able to handle
the broadcast message in time. The other potential cause of timeout is a blocking
SQL operation (such as all of the SQL/MP queries). Therefore, the timeout may not
constitute a real problem. The timer is configurable using an environment variable
named TANDEM_BROADCAST_SEND_TIMEOUT in the nsjspadmin server
configuration file (iTPWS_INSTALL_DIR/conf/nsjspadmin.config)
Env TANDEM_BROADCAST_SEND_TIMEOUT=<timeout-in-milliseconds>
Default: 20000 or 20 seconds
3. Processing exception reported by the server process. This reports that the server
is in an inconsistent state and could not handle the broadcast command. It is
recommended that you stop all such server processes.
6-7
EMS Message Format
EMS Message Format
When an error occurs during startup, the container reports an EMS message
consisting of the following elements:
•
•
A line that reports the date, the time, the process name, and the syslog severity
category, as described in the OSS manual set.
A descriptive string, for example, (#7001) Servlet ServerClass started. Version
Procedure = T1222V50_10NOV0503_BASE_V500_2. This message indicates that
the SERVLET ServerClass (the NSJSP process) has been started.
The EMS messages for the T1222 (NSJSP process) are listed below. They are also
documented in the iTP Secure WebServer Operator Messages Manual.
Event #7001 Servlet ServerClass started. Version Procedure =
%VPROC%
where %VPROC% is the version procedure number. The NSJSP process has
started.
Event #7001 NSJSPAdmin ServerClass started. Version Procedure =
%VPROC%
where %VPROC% is the version procedure number. The NSJSP process has
started.
Event #7002 Servlet ServerClass object code vproc %VPROC1% does
not match Class file vproc: %VPROC2% Terminating Server.
where %VPROC1% and %VPROC2% are the vprocs of the two T1222 product
components. Re-install the NSJSP product.
Event #7002 NSJSPAdmin ServerClass object code vproc %VPROC1%
does not match Class file vproc: %VPROC2% Terminating Server.
where %VPROC1% and %VPROC2% are the vprocs of the two T1222 product
components. Re-install the NSJSP product.
Event #7013 Servlet ServerClass Object code call to %FUNC%
failed. Terminating Server
where %FUNC% is the native function that caused the failure. Currently it is either
processhandle_getmine_() or getProcessInfo(). Restart the NSJSP
process.
Event #7013 NSJSPAdmin ServerClass Object code call to %FUNC%
failed. Terminating Server
where %FUNC% is the native function that caused the failure. Currently it is either
processhandle_getmine_() or getProcessInfo(). Restart the NSJSP
process.
6-8
EMS Message Format
6-9
EMS Message Format
6- 10
7
•
•
•
•
•
•
•
•
Migrating to NSJSP 5.0
NSJSP Environment on page 7-1
Jar File Considerations on page 7-1
Configuration Considerations on page 7-2
Pre-Compiled JSPs on page 7-4
Application Migration Considerations on page 7-4
Strict Rules on TagExtraInfo Classes on page 7-5
Persistent Session Classes Moved on page 7-6
Changes from JSP 1.2 to JSP 2.0 on page 7-12
NSJSP Environment
NSJSP 5.0 continues running in the same environment as in prior versions. For
example, NSJSP is still a ServerClass running in a NonStop TS/MP environment.
NSJSP also continues to rely on the iTPWebServer as a front-end HTTP processor for
incoming requests in the OSS environment.
Installation
The installation procedure remains the same as in prior releases by running
setupjava and setup scripts. The setup script has been modified to populate code,
directories, and configuration files for the additional nsjspadmin ServerClass.
Directory Structure
The NSJSP 5.0 container is based on Tomcat version 5.0 (or later) source code,
therefore the NSJSP 5.0 release package content differs slightly from the previous
NSJSP versions (see NSJSP Directory Structure on page 2-9 for details).
Jar File Considerations
The location of the jar files remain the same as in NSJSP 2.0.
•
•
All servlet related jar files are located under the $NSJSP_HOME sub-directory tree.
No jar files are located in the $JAVA_HOME/jre/lib directory.
The servlet and JSP API classes have been divided into two separate jar files. The
filenames are servlet-api.jar and jsp-api.jar in the
$NSJSP_HOME/common/lib/ directory. In previous releases, the servlet.jar
file contained both the servlet and JSP APIs and now these two files replace the
servlet.jar file.
7-1
Configuration Considerations
Configuration Considerations
Both SERVLET and nsjspadmin ServerClasses are defined in the servlet.config
and nsjspadmin.config respectively. They both use the same iTP_server.xml
configuration file. When configuration is altered using the admin web application, a
backup copy of the iTP_server.xml is saved in the $NSJSP_HOME/conf/backup
directory.
There are three new configuration files for NSJSP 5.0. They are:
•
•
•
nsjspadmin.config File on page 7-2
filemaps.config File on page 7-2
jdbc.config File on page 7-2
servlet.config File
The servlet.config file has been changed in NSJSP 5.0 (for detailed information
see servlet.config on page 3-2). During installation, your existing servlet.config
file is backed-up. Incorporate your specific configuration into the new
servlet.config file.
iTP_server.xml File
The content of the iTP_server.xml file is similar to previous NSJSP versions (see
iTP_server.xml on page 3-9 for details).
During installation, the existing iTP_server.xml file is backed up. Incorporate your
specific configuration into the new iTP_server.xml file.
nsjspadmin.config File
The nsjspadmin.config file is new in NSJSP 5.0. For more information, see
nsjspadmin.config on page 3-5.
filemaps.config File
The filemap.config file is new in NSJSP 5.0. For more information, see
filemaps.config on page 3-13.
jdbc.config File
The jdbc.config file is new in NSJSP 5.0. For more information, see jdbc.config on
page 3-13.
Context Configuration
NSJSP 5.0 introduces a new method of configuring Contexts (web applications). In
addition to nesting Context elements inside a Host element in the iTP_server.xml
7-2
configuration file, you can store Context elements in individual files (with a .xml
extension) in the $NSJSP_HOME/conf/<engine-name>/<host-name>/ directory.
This method allows dynamic reconfiguration of the web application because the main
iTP_server.xml file cannot be reloaded without restarting NSJSP. It is
recommended that you not place <Context> elements directly in the
iTP_server.xml file. Instead, you should put them in the META-INF/context.xml
directory of your WAR file or in the $NSJSP_HOME/conf/<engine-name>/hostname>/ directory.
In addition, NSJSP 5.0 evaluates variables (${<variable-name}) while parsing XML
documents. Therefore, an extra "$" (dollar sign) is required while specifying NonStop
SQL session tables. For example:
<Context path="/servlet_jsp/examples" docbase="examples" >
<Manager
className="com.tandem.servlet.catalina.session.NSJSPPersistentManager"
saveOnRestart="true" checkInterval="300">
<Store className=
"com.tandem.servlet.catalina.session.NonStopSQLJDBCStore"
driverName="com.tandem.sqlmp.SQLMPDriver"
sessionTable= "$$SYSTEM.T1222CAT.SessData" />
</Manager>
</Context>
In the same way, the table name for a NonStop SQL JDBCRealm requires extra "$"
(dollar sign). For example:
<Context path="/Servlet_jsp/jsp_examples" docBase="jsp-examples">
<Realm className="org.apache.catalina.realm.JDBCRealm"
connectionURL="jdbc:sqlmp:" driverName="com.tandem.sqlmp.SQLMPDriver"
userRoleTable="$$DATA00.REALMDB.USERROLE"
userTable="$$DATA00.REALMDB.USERS"/>
</Context>
If a context is altered using the admin web application, changes are saved to its
corresponding configuration file. In the meantime, a backup copy of the context is
saved in the $NSJSP_HOME/conf/<engine-name>/<host-name>/backup/
directory.
NSJSP 5.0 supports enhanced security by allowing you to configure which NSJSP
internal packages are protected against package definition and access. This
arrangement prevents a non-trusted application from accessing sensitive NSJSP
internal packages.
7-3
Pre-Compiled JSPs
During installation the existing iTP_catalina.policy file is backed up. Incorporate
your specific configuration into the new iTP_catalina policy file.
For more information about the NSJSP enhanced security manager, see Enhanced
Security Manager on page 3-26.
For more information about the security manager, see the documentation at
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/security-manager-howto.html.
Pre-Compiled JSPs
The NSJSP 5.0 release has an upgraded JSP compiler and runtime environment
(Jasper2). As part of the upgrade when the setup script is run, the work directory
$NSJSP_HOME/work is deleted. This causes the first access to a JSP resource to
trigger off a JSP compilation and ensures that all JSPs use the upgraded Jasper2
compiler and runtime environment.
Note the JSP compilation always causes the first access to a JSP resource to be slow.
It is recommended that you pre-compile your JSPs because this allows for better
performance and response time for the first request. Typically in most production
environments, JSPs are very rarely modified so it makes sense to have your web
application perform and scale better.
The Standalone Application Deployer allows you to pre-compile your JSP programs
and compile your web application. The "jasper2" task in the sample
$NSJSP_HOME/deployer/build.xml configuration file, will pre-compile and
generate <servlet-mapping> tags for all JSPs that are part of your web application.
For more information on the Standalone Application Deployer, see the documentation
at http://jakarta.apache.org/tomcat/tomcat-5.0-doc/deployer-howto.html.
The $NSJSP_HOME/bin/jspc.sh script is no longer shipped in the NSJSP 5.0
release. You can use the Standalone Application Deployer to achieve the same
functionality by using the "jasper2" task as described above.
The manager web application provides the management functions for all web
applications in the NSJSP container. In prior versions, the management functions were
provided using the nsjsp_manager (an interactive shell script). The nsjsp_manager
is no longer supported.
Application Migration Considerations
In NSJSP 5.0, for security, the Invoker Servlet is no longer enabled at the product
installation. However, you can enable the Invoker Servlet manually after carefully
examination of your security considerations.
7-4
Strict Rules on TagExtraInfo Classes
If the Invoker Servlet is disabled, some servlets in your web applications might not
work and may return error 404 (page not found) to the browser. This problem occurs if
your web application descriptors do not explicitly describe all of the servlet mappings.
Example 7-1 illustrates how to add mappings for a servlet to a web application's
deployment descriptor (web.xml file).
Example 7-1. Mapping Servlets in the Web Application Deployment Descriptor
(web.xml)
<servlet>
</servlet>
<servlet-mapping>
<url-pattern>/servlet/startCartRequest</url-pattern>
</servlet-mapping>
Strict Rules on TagExtraInfo Classes
With the implementation of the JSP 2.0 specification, any TagExtraInfo Classes
defined in a web application's TLD (TagLibrary Descriptor) files through <teiclass>
tag must be present even if they are not referenced. An Error 500 (server error) may
be returned to the browser if any such defined TagExtraInfo class cannot be found in
the CLASSPATH (even if the specific custom tag is not used). In prior releases, an
exception was thrown only when the specific custom tag was referenced.
Persistent Sessions Database Changes
For NSJSP 5.0, the persistent session database has an additional column, app_name,
for specifying the associated application. Below is the new iTP_SessionStore.sql
script for creating the session database.
session_id
VARCHAR(48)
NO DEFAULT
NOT NULL,
process_name
VARCHAR(8)
NO DEFAULT
NOT NULL,
rec_number
INTEGER UNSIGNED
NO DEFAULT
NOT NULL,
app_name
VARCHAR(255)
NO DEFAULT
NOT NULL,
session_data
VARCHAR(3712)
valid
SMALLINT UNSIGNED
NO DEFAULT,
NO DEFAULT,
lastaccessedLARGEINT NO DEFAULT,
For existing NSJSP persistent session database, a new shell script
nsjsp_migrateSessionStore is provided to ease the migration. The script alters
your exising table for the additional column.
The example above assumes that you are creating a NonStop SQL/MP database
table. If you wish to create a NonStop SQL/MX database table, please be aware that
the maximum record size limit is 4036 bytes (unlike the 4096 byte limit in SQL/MP). As
7-5
Persistent Session Classes Moved
a result, you will have to reduce the size of app_name field to VARCHAR(200) in order
to create a NonStop SQL/MX database table.
Persistent Session Classes Moved
Both NSJSPPersistentManager and NonStopSQLJDBCStore classes have been
moved from org.apache.catalina.session package to
com.tandem.servlet.catalina.session package.
All existing <Manager> elements nested inside <Context> tags are required to
change.
Figure 7-1 is an example using the com.tandem.servlet.catalina.session
package.
Figure 7-1. New Persistent Session Class Location
<Context path=“/servlet_jsp/examples” docbase=”examples” >
<Manager
className=“com.tandem.servlet.catalina.session.NSJSPPersistentManager”
saveOnRestart=“true” checkInterval=“300”>
<Store
className= “com.tandem.servlet.catalina.session.NonStopSQLJDBCStore”
driverName=”com.tandem.sqlmp.SQLMPDriver”
connectionURL=“jdbc:sqlmp:”
sessionTable= “$$SYSTEM.T1222CAT.SessData” />
</Manager>
</Context>
7-6
Changes from Servlet 2.3 to Servlet 2.4
The differences between the Java Servlet 2.4 API specification and Java Servlet 2.3 is
as follows:
•
Java Servlets 2.4 requires HTTP/1.1 and at least the J2SE (Java 2 Platform,
Standard Edition) 1.3 version.
In addition, the HttpServletResponse interface has a new variable called
SC_FOUND for HTTP/1.1 Status code 302. This variable is similar to the variable
SC_MOVED_TEMPORARILY (which has the same 302 status code value), but
represents a tie-in to the HTTP/1.0 specification. All applications should use the
SC_FOUND variable instead of SC_MOVED_TEMPORARILY.
•
•
•
An Optional "X-Powered-By" header added to the HttpServletResponse class.
A security model is applied to both servlets and filters.
FORM authentication failures set status code in the response to 200 (instead of
401).
FORM-based authentication failures result in a Response Status code of 200
(instead of 401) because no appropriate error code exists in the HTTP/1.1
specification to handle such a case.
•
•
•
A consistent view of Request and Response wrapper objects in servlet and filters.
An application cannot override J2SE platform classes such as those in the java.*
and javax.* namespaces (those platform classes to which J2SE does not allow
modification).
Clarification of processing order at web application deployment.
For web applications deployed into the NSJSP Container before the web
application begins processing requests, the setup steps performed internally are:
1. Create an instance of each event listener as configured using the
<listener> element in the deployment descriptor web.xml.
2. For the instantiated listeners call the contextInitialized() method in all
the listeners that implement the ServletContextListener interface.
3. Create an instance of each filter as configured using the <filter> element in
the deployment descriptor web.xml.
4. Finally, create an instance of each servlet as configured using the <servlet>
element in the deployment descriptor web.xml and call the init() method
in all the instantiated servlets. The order in which the servlets are loaded is
governed by the <load-on-startup> sub-element within the <servlet>
elements in the deployment descriptor web.xml.
•
Filters are now used with RequestDispatcher include() and forward() calls.
7-7
Filters are configured such that they are invoked on RequestDispatcher
include() and forward() calls. Use the <dispatcher> sub-element under
the <filter-mapping> element in the deployment descriptor web.xml.
For example, the following code configures filter mapping whereby a filter named
"my Forward Filter" is invoked when the request being processed under a
RequestDispatcher matches the <url-pattern> for a forward() call.
<filter-mapping>
<filter-name>my Forward Filter</filter-name>
<url-pattern>/myApp/*</url-pattern>
<dispatcher>FORWARD</dispatcher>
</filter-mapping>
Supported values in the <dispatcher> sub-element include one or more
combinations of REQUEST, INCLUDE, FORWARD, and ERROR.
•
New HttpSessionListener events for session migration and for Object binding.
New HttpSession event methods have been added for session migration
(activation and passivation of Sessions) and for Object binding (bind and unbind
operations) using the HttpSessionActivationListener and
HttpSessionBindingListener interfaces. In addition, a new
HttpSessionBindingEvent has been defined.
•
•
The HttpSessionListener.sessionDestroyed() event is now notified
before the session is invalidated (and not after the session is invalidated as in
previous API specifications).
Support for event notifications about state changes in the ServletRequest objects.
The Java Servlet 2.4 API specification also adds new Listener interfaces and Event
classes to allow notifications of request lifecycle events and events for changes to
request attributes. The ServletRequestListener and
ServletRequestAttributeListener are the two new Listener interfaces, and
the ServletRequestEvent and ServletRequestAttributeEvent are their
corresponding event classes. Request lifecycle events are defined when the
request is about to enter the first servlet or filter and when the request exits the last
servlet or filter in the application filter chain for any web application.
Some exceptions thrown in the Listener interfaces have an adverse impact on
subsequent requests to a particular web application. For example, unhandled
exceptions thrown when a ServletContextListener gets a servlet context
initialization notification or when a ServletRequestListener gets a request
initialization/destruction event or when a SessionListener gets a session
timeout event.
•
The HttpSession.logout() method (added in an intermediate version of the
Java Servlet 2.4 API specification) has been removed and will be addressed in the
next version.
7-8
•
Provision for shared library files and Classloader extension mechanisms.
For web applications that use shared library files, the Container now provides a
directory for all shared libraries. The files placed in the directory are available to all
web applications. Additionally, deployment support for extensions is recommended
but not required. (Support for extensions is specified using METAINF/MANIFEST/MF entry in the web application.)
For more details about the MANIFEST.MF entries, see The Java Extension
Mechanism at: http://java.sun.com/j2se/1.4/docs/guide/extensions/
•
Longest path-prefix matching for URL paths.
The Web Container is now required to return the longest path-prefix matching for
URL paths. The order for this matching is:
•
•
•
•
•
•
Look for an exact match of the request path to the path of a servlet.
Recursively try to match the longest path-prefix by going up the URL path
(from the end) using the forward-slash character (/) as a path separator.
If the last piece of the URL path contains an extension (for example, .jsp), the
Container matches a resource which handles request for that particular
extension.
If the above rules do not produce a match, the Container tries to serve the
appropriate content for the requested resource. If a default servlet is defined
for the particular web application, the default is used.
The HttpServletRequest.getRequestedSessionID() returns the clientspecified session ID. Note that session ID may not be the session ID currently
being used (in case of loads from a persistent store).
The RequestDispatcher.forward() includes new attributes for original
request information.
For servlets and JSPs that have been invoked using RequestDispatcher
forward(), and were not obtained using the getNamedDispatcher() method,
the following request attributes, which refer to the original request, are now set:
•
•
•
•
•
javax.servlet.forward.request_uri
javax.servlet.forward.context_path
javax.servlet.forward.servlet_path
javax.servlet.forward.path_info
javax.servlet.forward.query_string
This arrangement is similar to the include request attributes set for all included
requests except that the included request attributes refer to the included request
whereas the forward request attributes refer to the original request. And similar to
the include request attributes, these forward request attributes can be accessed
using the request's getAttribute() method.
7-9
Note that these attributes are not set for forwarded servlets and JSPs obtained
using the getNamedDispatcher() method.
•
The ServletRequest and ServletRequestWrapper classes have four new
methods to return information about the IP connection.
•
•
•
•
•
getRemotePort(): returns the IP port number of the client or last proxy that
sent this request.
getLocalName(): returns the host name on which this request was received.
getLocalAddr(): returns the IP address of the network interface on which
the request was received.
The ServletResponse and ServletResponseWrapper classes define two new
methods for internationalization support:
•
•
•
•
getLocalPort(): returns the IP port number on which the request was
received.
The setCharacterEncoding(String) method sets the character encoding
for the response back to the web client’s character encoding. In earlier Java
Servlets API specifications this was done using the charset parameter
specified to the setContentType(String) method (for example,
setContentType("text/html;charset=en-us"); ) or by using a Locale specified to
the setLocale(Locale) method. Note that this method has no effect if it is
called after a getWriter() method has been invoked or if the response has
already been committed.
For a list of the character sets allowed, see
http://www.iana.org/assignments/character-sets for more details.
The getContentType() method returns the content type used for the data
sent in the response.
The SingleThreadModel interface has been deprecated; there is no replacement.
To ensure that code is thread-safe, use multi-threaded programming paradigms
(avoiding sharing, setting, or using instance variables or then using synchronized
blocks of code for accessing common storage). Note that the SingleThreadModel
does not solve all thread-safe issues (access to session attributes, static variables,
and so on) even though multiple instances of the servlet are loaded in memory.
•
•
•
Null values passed to the ServletRequest.setAttribute(String,
Object) method are equivalent to calling
ServletRequest.removeAttribute(String) method.
The HttpServletRequest.getAuthType() method returns a containerspecific scheme in addition to the four pre-defined authentication schemes.
The Deployment Descriptor web.xml is extensible, and is defined in terms of an
XML schema document, and has some new elements.
7- 10
•
In the Deployment Descriptor web.xml, all sub-elements under the <web-app>
element can be in any order.
In the schema for the deployment descriptor web.xml, the <url-pattern>
element under the <web-app>/<security-constraint>/<web-resourcecollection> element tree is mandatory and must always be specified.
•
Allows multiple constraints on pattern and method (specified using <urlpattern> and <http-method> elements in the deployment descriptor
web.xml).
Multiple constraints on pattern and method (specified with <url-pattern> and
<http-method> elements in the deployment descriptor web.xml are now
supported and the constraints applied to the web application is the resultant set
defined by combining the individual constraints.
•
•
•
The container throws HTTP Error 500 (Internal Service Error) for the entire web
application for any unhandled exceptions in the Application Listener code.
The deployment descriptor web.xml defines Servlets using the <welcome-file>
element under the <web-app>/<welcome-file-list> element tree.
Clarifications for always alive sessions (sessions that never time out).
In the schema for the deployment descriptor web.xml the <session-timeout>
element under the <web-app>/<session-config> element tree supports
sessions that never time out (that is , sessions can have zero or negative values).
•
The container now returns SC_NOT_FOUND (404) codes on direct access to
/WEB-INF/ and /META-INF/ resources.
See the Java Servlet 2.4 API documentation for more information
http://java.sun.com/products/servlet/.
7- 11
Changes from JSP 1.2 to JSP 2.0
Differences between the JavaServer Pages 2.0 API specification and JavaServer
Pages 1.2 specification.
•
A new simple Expression Language.
The JavaServer Pages Expression Language (EL) has been added to the
JavaServerPages 2.0 API. The Expression Language was originally defined in the
JSP StandardTag Library (JSTL) 1.0 specification and is now incorporated in the
JavaServer Pages 2.0 API specifications. You can use EL with all standard and
custom JSP components as well as with template text (that is, EL is no longer
restricted to custom tags).
•
An Expression Language extension with a function call mechanism.
The EL has a function call mechanism that makes a set of commonly used
functions more readily available.
•
Better error handling in JSP error pages.
JSP Error pages have more information about the error. A new class
javax.servlet.jsp.ErrorData, which has methods to return the request
URI, servlet name, status code, and the actual exception. In addition, the
Container reporting for JSP syntax errors is stricter, which simplifies error tracking.
The JavaServer Pages 2.0 API specification also defines a Simple Invocation
Protocol, which avoids the complex invocation mechanism of the classic invocation
protocol and which implements tag files.
•
XML content handling improvements.
•
•
•
Dynamic XML content can be written as JSP content. File extensions .jspx
and .tagx indicate XML versions of JSP and tag files.
The Java Servlet 2.4 API specification uses a XML schema for the declaration
of the deployment descriptor rules. The JavaServer Pages 2.0 API adds
configuration options under the <jsp-configType> and the <taglib>
elements. In addition, several configuration options allow for global
configuration instead of a per- page configuration.
Loosened Page directive checks.
Page directive checks allow for duplicates (in the same manner as for the taglib
directive) and make static includes more useful. Note that duplicates are only
allowed as long as their values are identical.
•
JSP Fragments.
JSP API classes have been added for JSP fragments, tag libraries, and the EL
function call mechanism. In addition, the PageContext class extends the
JSPContext and has had some functionality moved to the JSPContext
7- 12
superclass for a cleaner implementation. This change does not affect the
PageContext class and is compatible with previous JSP releases.
Fragments are pieces of a JSP page that are translated into implementations of
the JspFragment class before being passed to a tag handler. Fragments are
automatically created for any JSP code in the body of any tag handled by the
SimpleTagHandler or defined using a named attribute (one defined through
<jsp:attribute> tag), that is declared to be a fragment or of type JspFragment
in the Tag Library Descriptor (TLD). Therefore, a tag handler can evaluate and reevaluate this fragment as many times as needed and even pass it on to other tag
handlers. Note that JSP fragments cannot contain scriptlets or scriptlet
expressions.
•
Tag Files.
Tag Files are JSP fragment files that have JSP content and which are
implementations of JSP tags. Tag Files allow for modular page components,
including XML content, which can be included in any JSP page.
•
Simple Tag Handlers.
Tag handlers can use the simplified TagHandler API.
Referring to any classes from the unnamed (default) package is illegal.
From the JavaServer Pages 2.0 API specifications, section JSP.11.2:
"As of JSP 2.0, it is illegal to refer to any classes from the unnamed (a.k.a. default)
package. This may result in a translation error on some containers, specifically those
that run in a JDK 1.4 or greater environment. It is unfortunate, but unavoidable, that
this will break compatibility with some older JSP applications. However, as of JDK 1.4,
importing classes from the unnamed package is not valid (see
http://java.sun.com/j2se/1.4/compatibility.html#source for details). Therefore, for
forwards compatibility, applications must not rely on the unnamed package. This
restriction also applies for all other cases where classes are referenced, such as when
specifying the class name for a tag in a TLD."
See the JavaServer Pages 2.0 API documentation for more information
http://java.sun.com/products/servlet/.
7- 13
7- 14
8
•
•
•
Virtual Hosts on page 8-1
Roles on page 8-1
Single Sign-On on page 8-1
The admin web application directly changes the attributes of the NSJSP container
which affects every application running in the container. The manager web application
allows install, deploy, and control of all web applications running in the NSJSP
container. Therefore, the admin and manager web applications are security-sensitive
applications and proper security constraints should be implemented.
Virtual Hosts
If you have more than one virtual host in your NSJSP environment, you need only one
admin web application to administer the NSJSP container. However, you need one
manager web application for every virtual host since the manager web application only
manages web applications in the same virtual host. If, for any reason, you do not wish
to expose on-line web application manageability for a virtual host, you can remove the
manager web application from the virtual host. To add the manager web application to
a virtual host, you could copy the nsjsp_manager.xml (application configuration file)
residing in your $NSJSP_HOME/conf/NSJSP/<local-host-name>/ directory to
$NSJSP_HOME/conf/NSJSP/<virtual-host-name>/ directory before you start
the NSJSP 5.0 environment. You could also use the admin application to add the
manager web application to your virtual host. See Administering Context Objects on
page 4-20.
Roles
The security constraints for the admin and manager web applications are implemented
using Roles. The NSJSP container performs the access control for these web
applications just as it does for any other web application. To change the security
constraints, modify the web.xml the deployment descriptor file, in the WEB-INF
directory under admin or under the manager docBase directory (see Context and
Default Context Objects on page C-7). By default, the admin web application uses the
admin role and the manager web application uses the manager role for their access
control. It is recommended for better security control, you should choose you own
security roles.
Single Sign-On
The admin and manager web applications can be configured to use Single Sign-On in
the same virtual host so that the operator can perform both configuration and
management functions after a single login. However, the Single Sign-On works only in
the same virtual host. You are required to log onto each individual virtual host in order
to manage its web applications.
8-1
Single Sign-On
8-2
A
JMXProxy Servlet
The JMX Proxy Servlet is a lightweight proxy that gets and sets NSJSP internal objects
by using JMX MBeans. Although the admin web application can perform most of the
functions, using the JMX Proxy Servlet simplifies writing control scripts (especially, if
you are monitoring and performing minor attribute changes).
The -DEnableJMXProxyServlet=true Java system property enables the
JMXProxy Servlet. The JMXProxy Servlet is disabled by default (property value set to
false). To enable set this property value to "true" in both the servlet.config and
nsjspadmin.config configuration files, located in the
iTPWS_INSTALL_DIR/conf/ directory.
The JMXProxy Servlet supports two commands:
•
•
JMX Query command
JMX Set command
JMX Query command
The JMX query command is invoked using the following URL:
http://<server>:<port>/manager/jmxproxy/?qry=<query>
<query> is the JMX query you wish to perform.
Examples:
qry=*:* -> to get all objects
qry=*:type=Connector,* -> to get all Connectors
qry=*:j2eeType=WebModule,* -> to get all web applications
JMX Set command
The JMX set command is invoked using the following URL:
http://<server>:<port>/manager/jmxproxy/?set=<MBean-name>&att=<attributename>&val=<attribute-value>
<MBean-name> is the full name of the target JMX MBean.
<attribute-name> is the attribute name.
<attribute-value> is the new attribute value.
Examples:
http://localhost:8080/manager/jmxproxy/
?set=NSJSP:type=Valve,name=ErrorReportValve,host=localhost&at
t=debug&val=10
This command alters the debug attribute value of the value named
NSJSP:type=Valve,name=ErrorReportValve,host=localhost to 10.
A- 1
JMXProxy Servlet
JMX Set command
A- 2
B
Sample Ant Script for the
Client Deployer
Example B-1. Sample Ant Script for the Client Deployer
- <project name="Deployer" default="compile" basedir=".">
<property file="deployer.properties" />
- <!-Configure the directory into which the web application is built
-->
<property name="build" value="${basedir}/build" />
- <!-Configure the folder and context path for this application
-->
<property name="webapp" value="myapp" />
<property name="path" value="/myapp" />
- <!-Configure properties to access the Manager application
-->
<property name="host" value="www.mycompany.com" />
<property name="port" value="80" />
<property name="url" value="http://${host}:${port}/manager”/>
<property name="username" value="user"/
<property name="password" value="pass"/
<property name="webapp.path" value="${build}/${webapp}"/
- <path id="deployer.classpath">
- <fileset dir="${basedir}/lib">
<include name="*.jar" />
</fileset>
</path>
- <!-Configure the custom Ant tasks for the Manager application
-->
<taskdef resource="org/apache/catalina/ant/catalina.tasks"
classpathref="deployer.classpath" />
- <!-Executable Targets
-->
- <target name="clean" description="Removes build directory">
<delete dir="${build}" />
</target>
- <target name="compile" description="Compile web application"
depends="clean"
- <copy todir="${webapp.path}">
<fileset dir="${webapp}" />
</copy>
<jasper2 validateXml="false" uriroot="${webapp.path}"
webXmlFragment="${webapp.path}/WEBINF/generated_web.xml" addWebXmlMappings="true"
outputDir="${webapp.path}/WEB-INF/classes" />
<validator path="${webapp.path}" />
<mkdir dir="${webapp.path}/WEB-INF/classes" />
<mkdir dir="${webapp.path}/WEB-INF/lib" />
- <javac destdir="${webapp.path}/WEB-INF/classes"
optimize="off" debug="on" failonerror="false"
srcdir="${webapp.path}/WEB-INF/classes"
encoding=”UTF-8” excludes="**/*.smap">
- <classpath>
B- 1
Sample Ant Script for the Client Deployer
Example B-1. Sample Ant Script for the Client Deployer
- <fileset dir="${webapp.path}/WEB-INF/lib">
<include name="*jar" />
<fileset>
- <fileset dir="${basedir}/lib"/
<include name="*.jar"/>
<fileset>
<classpath>
<include name="**" />
<exclude name="tags/**" />
</javac>
<jar destfile="${webapp.path}.war"
basedir="${webapp.path}" />
</target>
- <target name="deployLocal" description="Deploy web application">
<deploy url="${url}" username="${username}"
password="${password}"path="${path}"
localwar="jar:file:${build}/${webapp}.war" update="true" addFilemap=”true”
/>
</target>
- <target name="deployLocalWar" description="Deploy web application">
localwar="file:${build}/${webapp}.war" update="true" addFilemap=”true” />
</target>
- <target name="deploy"description="Deploy web application">
war="${build}/${webapp}.war" update="true" addFilemap=”true” />
</target>
- <target name="undeploy"description="Undeploy web application">
<undeploy url="${url}" username="${username}"
password="${password}"path="${path}"/>
</target>
- <!-Webapp lifecycle control
-->
- <target name="start" description="Start web application">
<start url="${url}" username="${username}"
password="${password}" path="${path}" />
</target>
- <target name="reload" description="Reload web application">
<reload url="${url}" username="${username}"
</target>
- <target name="stop" description="Stop web application">
<stop url="${url}" username="${username}"
</target>
</project>
B- 2
C
NSJSP Container Objects
The container objects you can administer using JMX technology are:
•
•
•
•
•
•
•
•
•
•
•
•
Server Object on page C-1
Service Object on page C-2
Connector Object on page C-2
Engine Object on page C-5
Host Object on page C-6
Context and Default Context Objects on page C-7
Loader Object on page C-11
Logger Object on page C-12
Manager Object on page C-13
Resources on page C-16
Realm Object on page C-21
Valve Object on page C-27
Server Object
The Server object represents the NSJSP container. Therefore, it is a singleton. The
Server object supported properties are:
debug(int)
The level of debugging detail logged by this Server object to the associated
Logger. Higher numbers generate more detailed output. The default is 0.
managedResource (java.lang.Object)
The managed resource with which the MBean is associated. The default is
NSJSPStandardServer.
port (int)
The shutdown port for the server. This value should be always -1 for NSJSP.
serviceNames (javax.management.ObjectName[])
List of all configured Service Object Names. The default is the NSJSPiTPWebServer StandardService object.
C- 1
Service Object
Service Object
The Service object represents the combination of one or more Connector components
that share a single Engine component for processing incoming requests. The Service
object properties supported are:
name (String)
The name of the Service object which is the same name specified in the
<Service> tag of your iTP_server.xml configuration file. The default is
NSJSP-iTPWebServer.
debug (int)
Specifies the level of debugging detail logged by this Service object to the
associated Logger. The default is 0.
The managed resource with which the MBean is associated. The default is
StandardService <service-name>.
connectorNames (javax.management.ObjectName[])
List of all configured Connector Object Names. The default is the
NSJSPCoyoteConnector object.
container (org.apache.catalina.Container)
Specifies the servlet engine that processes the requests. The default is
StandardEngine <engine-name>.
containerName (String)
Specifies the ObjectName of the engine. The default is NSJSP:type=Engine.
Connector Object
The Connector object represents a communication endpoint on which requests are
received from a client. NSJSP uses the NSJSPCoyoteConnector which works with
the iTP WebServer to process requests. The iTP WebServer handles most of the static
pages as well as the SSL protocol while leaving NSJSP to handle all of the Servlet and
JSP dynamic pages. The NSJSPCoyoteConnector properties are:
className (String)
The value is
com.tandem.servlet.coyote.tomcat5.NSJSPCoyoteConnector.
C- 2
Connector Object
acceptCount (int)
The maximum queue length of the incoming connections. This attribute is
reserved, and uses the TANDEM_RECEIVE_DEPTH value from the
servlet.config configuration file.
allowTrace (boolean)
Enables or disables the TRACE HTTP method. The default is false.
bufferSize (int)
Specifies the buffer size to be used for input streams. The default is 2048.
clientAuth (boolean)
Specifies the SSL stack to require a valid certificate chain from the client before
accepting a connection. The default is false.
compression (on/off)
Enables data compression. The default is off.
connectionTimeout (int)
Specifies the timeout value for the incoming connection. The default is 0.
connectionUploadTimeout (int)
Specifies the timeout value for the incoming connection for data upload. The
default is 300000.
disableUploadTimeout (boolean)
Specifies the buffer size to be used for input streams. The default is true.
debug (int)
Specifies the level of debugging detail logged by this Connector object to the
associated Logger. The default is 0 (zero).
enableLookups (boolean)
Instructs the server to perform DNS lookups on remote IP addresses. The default
is false.
maxHTTPHeaderSize (int)
Specifies the maximum data size for the POST method. The default is 4096.
maxPostSize (int)
Specifies the maximum size of the request and response HTTP header in bytes.
The default is 2097152.
C- 3
Connector Object
maxProcessors (int)
The maximum processor threads supported by this connector. This number should
always be greater than the minProcessors and greater than or equal to
acceptCount. The default is 75.
maxSpareThreads (int)
The maximum number of unused request processing threads supported by this
connector. The default is 25.
maxThreads (int)
The maximum number of request processing threads supported by this connector.
The default is 75.
minSpareThreads (int)
The number of request processing threads first started by this connector. The
default is 5.
minProcessors (int)
The minimum number of processor threads to be created at container start-up. The
default is 5.
port (String)
The port number. This value should always be 0 as the $RECEIVE file of the
process is used.
protocol (String)
Specifies the NSJSP Coyote protocol handler in use. The default is
iTP_WebServer-CGI/1.1.
protocolHandlerClassName (String)
the name is com.tandem.servlet.coyote.http11.iTPWscgiprotocol.
proxyName (String)
Specifies the proxy name if there is one configured.
proxyPort (int)
Specifies the port number of the proxy server if one is configured.
redirectPort (int)
Specifies the port number to be re-directed for SSL transport. The default is 443.
C- 4
Engine Object
scheme (String)
The protocol scheme of the connector. The default value is http.
secure (boolean)
Specifies whether this is a secure connector. The default value is false.
tcpNoDelay (boolean)
Specifies whether to use TPC_NO_DELAY option. The default value is true.
threadPriority (int)
The priority of the request processing threads within the JVM. The default value is
5.
type (String)
The connector type. The default value is iTPWS-CGI.
URIEncoding (String)
Specifies the character encoding used to decode the URI bytes.
useBodyEncodingForURI (boolean)
Specifies if the encoding specified in the contentType should be used for URI
query parameters instead of the character encoding specified in the URIEncoding.
The default is false.
xpoweredBy (boolean)
Specifies the generation of X-Powered-By response header enabled or disables.
The default is false.
Note. Only one NSJSPCoyoteConnector or iTPWScgiConnector is allowed in a Server object.
This is not a new restriction, but is stated here as a reminder.
Engine Object
The Engine object represents the entire request-processing machinery associated with
a particular Service. Every Engine object is owned by a Service object. Conversely, an
Engine object contains one or more Host objects. The Engine object properties
supported using the JMX interface are:
name (String)
The name of the Engine object which is the same name specified using the
<Engine> tag of the iTP_server.xml configuration file. The default is NSJSP.
C- 5
Host Object
debug (int)
Specifies the level of debugging detail logged by this Engine to the associated
Logger. The default is 0.
defaultHost (String)
Specifies the default host name. The default is localhost.
Specifies the managed resource with which this MBean is associated. The default
is StandardEngine <engine-name>.
baseDir (String)
Specifies the base directory for the engine. Typically, this is $NSJSP_HOME.
realm (org.apache.catalina.Realm)
Specifies the realm configured for the engine.
valveObjectNames (javax.management.ObjectName)
List of all the Valve Object Names associated with this engine.
Host Object
The Host object represents an individual virtual host which has a unique set of
associated web applications. A Host could have zero or more DNS names as its
aliases. The Host object properties supported using the JMX interface are:
name (String)
The DNS name of the virtual host represented by this object specified using the
<Host> tag of the iTP_server.xml configuration file.
appBase (String)
The absolute or relative (to $NSJSP_HOME) path of the directory from which web
applications are automatically deployed. The default is webapps.
The managed resource with which the MBean is associated. The default is a
combination of StandardEngine <engine-name> and StandardHost <hostname>.
debug (int)
Specifies the level of debugging detail logged by this Host object to the associated
Logger. The default is 0 (zero).
C- 6
children (javax.management.ObjectName[])
List of all subordinate (child) MBean objects associated with this Host.
autoDeploy (boolean)
Instructs the virtual host to automatically deploy web applications if the web
application resides in the virtual host's appBase directory. The default is false.
deployOnStartup (boolean)
Instructs the virtual host to automatically deploy web applications at start-up. The
default is true.
deployXML (boolean)
Enables the deployment of a web application using Context XML configuration
files. The default is true.
unpackWARs (boolean)
Indicates that the web application archive (WAR) files placed in the appBase
directory should be unpacked. Otherwise, such web applications are run directly
from a WAR file. The default is true.
xmlNamespaceAware (boolean)
Indicates whether this host is Namespace aware when dealing with XML
documents. The default is false.
xmlValidation (boolean)
Indicates whether this host performs XML validation. The default is false.
aliases (java.lang.String[])
Specifies the host’s aliases..
Specifies the realm configured for the host.
valveNames (String[])
List of all configured Valve names associated with this Host.
valveObjectNames (javax.management.ObjectName)
List of all configured Valve Object Names associated with this Host.
The Context object represents an individual web application. The Default Context
object represents a subset of the configurable properties of a Context and is used to
C- 7
set defaults for those properties when web applications are automatically deployed.
The Context object properties supported using the JMX interface are:
allowLinking[*] (boolean)
Specifies whether to allow symbolic links inside a web application. The default is
false.
cacheMaxSize[*] (int)
Specifies the maximum size of the static resource cache in KBytes. The default is
10240.
cacheTTL[*] (int)
Specifies the time interval in milliseconds for cache revalidation. The default is
5000.
cachingAllowed[*] (boolean)
Specifies whether or not to cache static resources for this web application. The
default is true.
caseSensitive[*] (boolean)
Specifies whether checks are case sensitive. The default is true.
cookies[*] (boolean)
Enables cookies to be used for session identifier communication (if supported by
the client). If set to false, it disables the use of cookies for session-identifier
communication and relies only on URL rewriting by the application. The default is
true.
compilerClasspath (String)
Specifies the compiler classpath to be used by the web application.
crossContext[*] (boolean)
Enables cross context support. The default is true.
debug (int)
Specifies the level of debugging detail logged by this Context to the associated
deploymentDescriptor (String)
Specifies the deployment descriptor.
C- 8
docBase (String)
Specifies the absolute or relative (to the appBase of the owning Host) pathname of
a directory containing an unpacked web application or of a web application archive
(WAR) file.
engineName (String)
Specifies the engine name of this web application.
delegate (boolean)
Enables the class loader to follow the standard java2 delegation model, and
attempt to load classes and resources from parent class loaders before looking
inside the web application. Otherwise, the class loader looks inside the web
application first. The default is false.
environments (javax.management.ObjectName[])
List of all MBean objects of the defined environment entries associated with this
Context.
eventProvider (boolean)
Specifies whether event provider is supported. This is always false.
loader (org.apache.catalina.Loader)
Specifies the associated loader. The default is WebappLoader <path-name>.
logger (org.apache.catalina.Logger)
Specifies the associated logger.
Specifies the managed resource with which this MBean is associated. Typically, it
is a combination of StandardEngine<engine-name>, StandardHost<hostname> and StandardContext<context-path-name>.
manager (org.apache.catalina.Manager)
Specifies the associated session manager.
managerChecksFrequency[*] (int)
Specifies the frequency of the session manager checks. The default is 6.
mappingObject (java.lang.Object)
Specifies the object used for mapping. Typically, this is the same object of the
managedResource.
C- 9
modified (boolean)
Specifies whether the web application has been modified.
resourceNames (java.lang.String[])
Specifies the Object names for the resources.
objectName (String)
Specifies the object name of this context.
override (boolean)
Indicates whether the settings in this context should override the corresponding
settings in the Default Context. The default is false.
parentClassLoader (java.lang.ClassLoader)
Specifies the parent class loader.
path (String)
Specifies the context path of the web application.
privileged (boolean)
Specifies that the web application is authorized to access internal NSJSP classes.
Specifies the associated realm.
reloadable[*] (boolean)
Indicates whether the NSJSP container should monitor and automatically reload
the web application when application changes are detected. The default is false.
saveConfig (boolean)
Enables the configuration to be serialized on startup as needed. The default is
true.
servlets (java.lang.String[])
Specifies the list of configured servlets in the web application.
startupTime (int)
Specifies the startup processing time for the web application.
state (int)
Specifies the current state.
C-10
Loader Object
stateManageable (boolean)
Enables state management support for this context. The default is true.
statisticsProvider (boolean)
Enables statistics support. The default is false.
staticResources (javax.naming.directory.DirContext)
Specifies the static resources associated with this context.
swallowOutput[*] (boolean)
Indicates whether to redirect the bytes output to System.out and System.err
by the web application to the web application's Logger. The default is false.
tldScanTime (int)
Specifies the time spent scanning jars for TLDs.
useNaming[*] (boolean)
Indicates whether the NSJSP container provides a JNDI naming context containing
preconfigured entries and resources corresponding to the requirements of the
J2EE specification. The default is true.
valveObjectName (javax.management.ObjectName[])
Specifies the associated valves.
welcomeFiles (javax.lang.String[])
Specifies the welcome files.
workDir (String)
Specifies the path name of the work directory.
Note. A Default Context object has all the properties indicated by the asterisk ( [*]).
Loader Object
A Loader object represents a web application class loader that provides the class
loading services for a particular Context object. The Loader object properties
supported are:
className (String)
the value is org.apache.catalina.loader.WebappLoader.
C-11
Logger Object
debug (int)
Specifies the level of debugging detail logged by this Loader object to the
associated Logger object. The default is 0 (zero).
delegate (boolean)
Enables the class loader to follow the standard java2 delegation model, and
attempt to load classes and resources from parent class loaders before looking
inside the web application. Otherwise, the class loader looks inside the web
application first. The default is false.
reloadable (boolean)
Indicates whether this class loader checks for modified classes and initiates
automatic reloads. This is automatically set from the reloadable property of the
corresponding Context.
repositories (java.lang.String[])
Specifies the extra repositories managed by this loader.
repositoriesString (String)
Specifies the extra repositories managed by this loader.
loaderRepositories (java.lang.String[])
Specifies the repositories set in the real loader.
loaderRepositoriesString (String)
Specifies the repositories set in the real loader.
Logger Object
A Logger object represents a component that stores debugging traces, error
messages, and any other logging-related information. Depending on their types,
different Logger objects may have a different set of properties. The
NSJSPFileLogger properties supported are:
className (String)
the value is com.tandem.servlet.catalina.logger.NSJSPFileLogger.
debug (int)
Specifies the level of debugging detail logged by this Logger. The default is 0.
verbosity (int)
The minimum verbosity level for messages to be written to this Logger object.
Messages written without a verbosity level are logged unconditionally. The
C-12
Manager Object
verbosity levels are: 0 (fatal messages only), 1 (errors), 2 (warnings), 3
(information), and 4 (debug). The default is 0.
directory (String)
The absolute or relative (to $NSJSP_HOME) path of the directory in which log files
are created. The default is logs.
prefix (String)
The string added to the beginning of generated log file names. The default value is
NSJSP_catalina.
suffix (String)
The string added to the end of generated log file names. The default is .log.
timestamp (boolean)
Specifies whether log messages should be date/time stamped. The default is true.
The NSJSPSystemLogger properties supported are:
className (String)
the name is
com.tandem.servlet.catalina.logger.NSJSPSystemLogger.
debug (int)
Specifies the level of debugging detail logged by this Logger. The default is 0.
verbosity (int)
The minimum verbosity level for messages to be written to this logger. Messages
written without a verbosity level are logged unconditionally. The verbosity levels
are: 0 (fatal messages only), 1 (errors), 2 (warnings), 3 (information), and 4
(debug). The default level is 0.
Manager Object
A Manager object represents a session manager that is associated with a particular
web application. Two manager object types exist: NSJSPStandardManager and
NSJSPPersistentManager.
The NSJSPStandardManager object properties supported are:
className (String)
The value is
com.tandem.servlet.catalina.session.NSJSPStandardManager.
C-13
Manager Object
name (String)
The descriptive name of this manager implementation. The default is
NSJSPStandardManager.
algorithm
The name of the Message Digest algorithm to calculate the Session identifiers it
The default is MD5.
checkInterval
The number of seconds between checks for expired Sessions.
debug (int)
Specifies the level of debugging detail logged by this manager object to the
associated Logger object. The default is 0 (zero).
distributable
Enables the session manager to enforce the restriction described in the Servlet
specification on distributable application. The default is false.
entropy (String)
A String value that is utilized when seeding the random number generator used to
create session identifiers. For a security-aware environment, use a long String
value. The default is a preset value.
maxActiveSessions (int)
Specifies the maximum number of active sessions allowed or specifies -1 for no
limit. The default is -1.
maxInActiveIntervel (int)
Specifies the maximum inactive intervel in seconds for sessions. The default is
1800.
sessionIdLength (int)
Specifies the session ID length in bytes. The default is 16.
randomClass
default is java.security.SecureRandom.
activeSessions (int)
Specifies the current active session count.
C-14
Manager Object
sessionCounter (int)
Specifies the total number of sessions ever created by this manager.
maxActive (int)
Specifies the high water mark of the active session.
rejectedSessions (int)
Specifies the total number of sessions rejected because the maxActiveSessions
has been reached.
expiredSessions (int)
Specifies the total number of sessions that have expired. This number does not
include those sessions that have been explicitly invalidated.
processingTime (int)
Specifies the time spent for performing housekeeping and session expirations.
duplicates (int)
Specifies the number of duplicated session ids generated.
The NSJSPPersistentManager supports the following additional properties:
className (String)
The value is
com.tandem.servlet.catalina.session.NSJSPPersistentManager.
maxIdleBackup (int)
The interval (in seconds) a session must be idle (time since last access to the
session) before the session can be persisted to the session store. A value of -1
disables this feature. The default is -1.
Note. The maxActiveSessions, minIdleSwap, and maxIdleSwap properties could override this
property value and swap out a session before it reaches its maximum idle time interval. If this
feature is enabled, the time interval specified should be less than the value specified for
maxIdleSwap.
minIdleSwap (int)
to the session) before the session is eligible to be persisted to the session store
and passivated out of the NSJSP Container's memory. A value of -1 disables this
feature. If this feature is enabled, the interval specified should be less than the
value specified for maxIdleSwap. The default is -1.
C-15
Resources
maxIdleSwap (int)
to the session) before the session is persisted to the session store and passivated
out of the NSJSP Container's memory. A value of -1 disables this feature. If this
feature is enabled, the interval specified should be equal to or longer than the
value specified for maxIdleBackup. The default is -1.
saveOnRestart (boolean)
Specifies whether all sessions should be saved to the store on shutdown. The
default is true.
Specifies the managed resource with which this MBean is associated.
Resources
Validate properties for Resource object are:
auth (String)
Specifies whether the web application code signs on the corresponding resource
manager programmically, or the container will sign onto the resource manager on
behalf of the application. The value must be Application or Container.
description (String)
Specifies the description of the resource.
name (String)
Specifies the name of resource.
scope (String)
Specifies whether connections obtained through this resource manager can be
shared. The value must be Sharable or Unsharable. The default is Shareable.
type (String)
Specifies the fully qualified Java class name used by the web application when it
performs a lookup for this resource.
C-16
Data Sources
NSJSP supports the following resources:
•
•
•
•
•
Data Sources on page C-17
Mail Sessions on page C-18
Environment Entries on page C-18
User Databases on page C-19
Resource Links on page C-21
Data Sources
A Data Source represents a database connection made available in the JNDI naming
context associated with a web application. The Data Source properties are:
name (String)
The JNDI naming context that identifies the data source.
url (String)
The Connection URL for accessing the data source.
driverClass (String)
The JDBC driver class name.
username (String)
The database username to use when establishing a JDBC connection.
password (String)
The database password to use when establishing a JDBC connection.
maxActive (int)
The maximum number of active sessions supported. The default is 4.
maxIdle (int)
The maximum number of idle connections allowed. The default is 2.
maxWait (int)
Specifies the maximum wait (in milliseconds) for a connection to be established.
The default is 5000.
auth (String)
Specifies the authorization requirement. The default is the Container.
C-17
Mail Sessions
scope (String)
Specifies the sharing scope. The default is Shareable.
type (String)
Specifies the resource type. The default is javax.sql.DataSource.
Mail Sessions
A Mail Session represents a standard resource factory that creates
javax.mail.Session session instances for web applications so that the application
is insulated from changes in the email server configuration environment. The Mail
Session properties are:
name (String)
The name of the Mail Session.
mail.smtp.host (String)
Points to a server that provides SMTP services.
auth (String)
Specifies the authorization requirement. The default is the Container.
scope (String)
type (String)
Specifies the resource type. The default is javax.mail.Session.
Environment Entries
An Environment Entry represents a named value made visible for web applications.
The Environment Entry properties are:
className (String)
Specifies the fully qualified class name.
Name (String)
The name of this entry.
type (String)
The data type of the value. Supported data types are: java.lang.Boolean,
java.lang.Byte, java.lang.Character, java.lang.Double,
C-18
User Databases
java.lang.Float, java.lang.Integer, java.lang.Long,
java.lang.Short, java.lang.String.
value (supported data type)
The value of the assigned entry.
override (boolean)
Indicates whether the same named entry specified in the web application's
deployment descriptor overrides this value. The default is true.
The description of this entry.
User Databases
A User Database is a database of user names and their corresponding passwords.
The User Database properties are:
name (String)
The name of the user database.
pathname (String)
The location of the memory user database file. The default location is
$NSJSP_HOME/conf/tomcat-users.xml.
factory (String)
The user database factory. Currently, only
org.apache.catalina.users.MemoryUserDatabaseFactory is supported.
The description of the user database.
auth (String)
Specifies the authorization requirement. The default is the container.
scope (String)
type (String)
Specifies the resource type. The default is
org.apache.catalina.UserDatabase.
C-19
User Databases
groups (java.lang.String[])
List of groups defined in this database.
roles (java.lang.String[])
List of roles defined in this database.
users (java.lang.String[])
List of users defined in this database.
Using JMX, the User Database’s subordinate objects such as User, Group, and Role
can also be managed. For more information about configuring the User Database, see
the Tomcat 5.0 Specification Version 5.0 at http://jakata.apache.org/tomcat/tomcat-5.0doc.index.html.
Group
Group is used to group a group of Users. The Group properties are:
Specifies the description of the Group.
groupname (String)
Specifies the name of the Group.
Lists roles assigned to this Group.
Role
Role represents a user role used in the application access authorization. The Role
properties are:
Specifies the description of the Role.
rolename (String)
Specifies the name of the Role.
Users
User represents a user. The User properties are:
fullName (String)
Specifies the full name of the user. This is used for user readable.
C-20
Resource Links
groups (java.lang.String[])
Lists groups in which the user belongs.
password (String)
Specifies the user’s password for user authentication.
username (String)
Specifies the name of the User.
Lists roles assigned to this User.
Resource Links
Resource Link is used to create a link to a global JNDI resource. Therefore, it exists
only inside a context. The Resource Link properties are:
global (String)
Specifies the name of the linked global resource.
name (String)
Specifies the name of the resource link.
type (String)
Specifies the fully qualified java class name expected by the web application when
it performs a lookup for this resource link.
Realm Object
A Realm object represents a database of information about authorized users, their
passwords, and their granted access roles. Many types of Realms are supported in the
NSJSP container. Property list varies for different types of Realms.
Below are the Realm objects and their associated properties.
JDBCRealm Properties
className (String)
The value is org.apache.catalina.realm.JDBCRealm.
connectionName (String)
Specifies the database username to use when establishing a JDBC connection.
C-21
Realm Object
connectionPassword (String)
Specifies the database password to use when establishing a JDBC connection.
connectionURL (String)
Specifies the connection URL to use when establishing a JDBC connection.
debug (int)
Specifies the level of debugging detail logged by this Realm to the associated
Logger. The default is 0.
digest (String)
Specifies name of the MessageDigest algorithm that encodes passwords in the
database, or specifies a zero-length string for no encoding. The default is no
digest.
driverName (String)
Specifies the fully qualified Java class name of the JDBC driver.
roleNameCol (String)
Specifies the name of the column in the User Roles table which contains the role
name. The default value is role_name.
userCredCol (String)
Specifies the name of the column in the Users table which contains the password
(encrypted or unencrypted). The default value is user_pass.
userNameCol (String)
Specifies the name of the column in both the Users and User Roles tables that
contains the username. The default value is user_name.
userRoleTable (String)
Specifies the name of the User Roles table which contains one row for each
security role assigned to a particular user. This table must contain the columns
specified by the userNameCol and roleNameCol properties.
userTable (String)
Specifies the name of the Users table which contains one row for each authorized
user. This table must contain the columns specified by the userNameCol and
userCredCol properties.
C-22
Realm Object
MemoryRealm Properties
className (String)
The value is org.apache.catalina.realm.MemoryRealm.
debug (int)
Logger object. The default is 0 (zero).
digest (String)
Specifies the name of the MessageDigest algorithm that encodes passwords in the
digest.
pathname (String)
The absolute or relative (to $NSJSP_HOME) pathname to the XML file containing
the user information. The default is conf/tomcat-users.xml.
JNDIRealm Properties
type (String)
The type is org.apache.catalina.realm.JNDIRealm.
connectionName (String)
Specifies the username used to establish a JNDI connection with the directory
server.
connectionPassword (String)
Specifies the password used to establish a JNDI connection with the directory
server.
connectionURL (String)
Specifies the directory server URL with which to establish a JNDI connection.
contextFactory (String)
Specifies the JNDI context factory used to acquire the InitialContext.
debug (int)
Logger object. The default is 0.
C-23
Realm Object
digest (String)
digest.
roleBase (String)
The base element for role searches. If not specified, the top-level element in the
directory context is used.
roleName (String)
The name of the directory server attribute which contains the role name.
roleSearch (String)
The LDAP search pattern to use for selecting roles in the JNDIRealm. This pattern
You may use {0} to substitute the distinguished name and {1} to substitute the
username of the user whose roles you are searching.
roleSubtree (boolean)
Specifies whether role searches search sub trees of the element selected by
roleBase. The default is false.
userBase (String)
The base element for user searches.
userPassword (String)
The directory-server attribute name (in the user element) that contains the clear
text or digested user password (depending on the setting of the digest attribute).
userPattern (String)
The pattern for the distinguished name (DN) of the user's directory entry, with {0}
marking where the actual username should be inserted. You can use this property
instead of userSearch, userSubtree, and userBase when the distinguished name
contains the username and is otherwise the same for all users.
userRoleName (String)
Specifies the name of an attribute in the user's directory entry containing zero or
more values for the names of roles assigned to this user. In addition, you can use
the roleName property to specify the name of an attribute to be retrieved from
individual role entries found by searching the directory. If userRoleName is not
specified, all the roles for a user derive from the role search.
C-24
Realm Object
userSearch (String)
Specifies the LDAP filter expression to use when searching for a user's directory
entry, with {0} marking where the actual username should be inserted. Use this
property (along with the userBase and userSubtree properties) instead of
userPattern to search the directory for the user's entry.
userSubtree (boolean)
Specifies if you want user searches to search sub trees of the element selected by
userBase. The default is false.
UserDatabaseRealm Properties
className (String)
The value is org.apache.catalina.realm.UserDatabaseRealm.
debug (int)
Logger object. The default is 0 (zero).
digest (String)
digest.
resourceName (String)
Specifies the JNDI resource name defined for the user database.
DataSourceRealm Properties
className (String)
The value is org.apache.catalina.realm.DataSourceRealm.
debug (int)
dataSourceName (String)
Specifies the JNDI DataSource name.
digest (String)
Specifies name of the MessageDigest algorithm used to encode passwords in the
database or specifies a zero-length string for no encoding. The default is no digest.
C-25
Realm Object
localDataSource (Boolean)
Specifies whether the JNDI lookup for the datasource is done in the web
application's local context. The default is false.
roleNameCol (String)
Specifies the name of the column in the user roles table which contains a role
name assigned to the corresponding user.
userCredCol (String)
Specifies the name of the column in the users table which contains the user's
credentials (for example, password). If a value for the digest attribute is specified,
this component assumes that the passwords have been encoded with the specified
algorithm. Otherwise, the passwords are assumed to be in clear text.
userNameCol (String)
Specifies the name of the column in the users tables and user roles tables that
contains the user's username.
userRoleTable (String)
Specifies name of the user roles table which must contain columns named by the
userNameCol and roleNameCol attributes.
userTable (String)
Specifies the name of the users table which must contain columns named by the
userNameCol and userCredCol attributes.
JAASRealm Properties
className (String)
The value is org.apache.catalina.realm.JAASRealm.
debug (int)
appName (String)
Specifies the name of the realm as configured in the login configuration file (JAAS
LoginConfig).
userClassNames (String)
A comma-separated list of user Principal class names.
C-26
Valve Object
roleClassNames (String)
A comma-separated list of role Principal class names.
useContextClassLoader (String)
Instructs JAASRealm to use the context class loader for loading the user-specified
LoginModule class and associated Principal classes. The default is true.
Valve Object
A Valve object represents a component that is inserted into the request-processing
pipeline. Different valves have distinct processing capabilities, such as providing
access logging and request filtering. The property list varies for different types of Valve
objects.
Below are the Valve objects and their associated properties.
RemoteHostValve Properties
The RemoteHostValve performs client host name filtering before accepting requests.
className (String)
The value is org.apache.catalina.valves.RemoteHostValve.
allow (String)
Specifies a list of remote hosts to be allowed access.
deny (String)
Specifies a list of remote hosts not allowed (denied) access.
debug (int)
Specifies the level of debugging detail logged by this Valve to the associated
Logger. The default value is 0.
containerName (javax.management.ObjectName)
Specifies the object name of the parent container.
AccessLogValve Properties
The AccessLogValve logs all access to the server.
className (String)
The value is org.apache.catalina.valves.AccessLogValve.
C-27
Valve Object
debug (int)
Specifies the level of debugging detail logged by this Valve object to the
associated Logger. The default is 0 (zero).
directory (String)
The absolute (or relative to $NSJSP_HOME) pathname of a directory in which log
files created by this valve are placed. The default value is $NSJSP_HOME/logs.
pattern (String)
The formatting layout identifying the various information fields from the request and
response to be logged.
prefix (String)
The prefix of the log file name. The default is access_log.
resolveHosts (boolean)
Indicates whether to convert the IP address of the remote host into the
corresponding host name using a DNS lookup. The default is false.
rotatable (boolean)
Indicates whether log rotation should occur. The default is true.
suffix - (String)
The suffix added to the end of each log file's name.The default is double quotation
marks (““).
RemoteAddrValve Properties
The RemoteAddrValve performs filtering of client IP addresses before accepting
requests.
className (String)
The value is org.apache.catalina.valves.RemoteAddrValve.
allow (String)
A comma-separated list of regular expression patterns that are compared to the
remote IP address. If this attribute is specified, the remote address must match for
this request to be accepted. If this attribute is not specified, all requests are
accepted unless the remote address matches a deny pattern.
C-28
Valve Object
deny (String)
A comma-separated list of regular expression patterns that are compared to the
remote client's IP address. If this attribute is specified, the remote address must
not match for this request to be accepted. If this attribute is not specified, request
acceptance is governed solely by the accept attribute.
RequestDumperValve Properties
The RequestDumperValve causes the client's HTTP requests to be logged to the
corresponding Logger object.
NOTE. The output from this valve object includes any parameters included with the request.
The parameters are decoded using the default platform encoding. Any subsequent calls to
request.setCharacterEncoding() within the web application have no effect.
className (String)
The value is org.apache.catalina.valves.RequestDumperValve.
debug (int)
Specifies the level of debugging detail logged by this Valve to the associated
Logger object. The default is 0.
SingleSignOnValve Properties
The SingleSignOnValve allows you to sign-on to any web application associated within
the same virtual host.
className (String)
The value is org.apache.catalina.valves.SingleSignOnValve.
debug (int)
Specifies the level of debugging detail logged by this Valve object to the
associated Logger object. The default is 0.
C-29
Valve Object
requireReauthentication (boolean)
Specifies whether each request needs to be reauthenticated to the security Realm.
If true, this Valve uses the cached security credentials (user name and password)
to reauthenticate to the Realm.
C-30
Glossary
This glossary defines terms used both in this manual and in other HP manuals. Both
industry-standard terms and HP-specific terms are included.
authentication. The process of identifying an individual, usually based on a username and
password. In security systems, authentication is distinct from authorization, which is
the process of giving individuals access to system objects based on their identity.
Authentication merely ensures that the individual is who he or she claims to be, but
says nothing about the access rights of the individual.
browser. A graphical user interface (GUI) used to access sites on the World Wide Web.
Netscape, Internet Explorer, Mosaic, and Lynx are commonly used browsers.
CCITT (International Telegraph and Telephone Consultative Committee). A division of
the United Nations International Telecommunications Union that coordinates
standards-setting activities.
CGI. See Common Gateway Interface (CGI)
CERN. The European Laboratory for particle physics. The originators of the HyperText
Transport Protocol (HTTP) and HyperText Markup Language (HTML) concepts.
CommerceNet. A consortium that was formed in Silicon Valley to promote electronic
commerce over the Internet.
Common Gateway Interface (CGI). A standard protocol used as the interface between
web servers and the programs these servers use to process requests from web clients.
connection. The path between two protocol modules that provides reliable stream delivery
service. In the Internet, a connection extends from a Transmission Control Protocol
(TCP) module on one machine to a TCP module on another machine.
cookie. A message given to a Web browser by a Web server. The browser stores the
message in a text file. The message is then sent back to the server each time the
browser requests a page from the server. The main purpose of cookies is to identify
users and possibly prepare customized Web pages for them.
deployment descriptor. The web.xml file that contain resource definitions such as MIME
types, mapping of requests to servlets, access control and servlet initialization
parameters.
disk files. Standard POSIX or Guardian style disk files. The file names of POSIX disk files
comply with the POSIX specifications.
distinguished name (DN). The complete name of a directory entry, consisting of the
Relative Distinguished Name (RDN) of the entry and the RDNs of its superior entries.
DN. See distinguished name (DN)
Glossary- 1
Glossary
DNS
DNS. See Domain Name Server (DNS).
Document Type Definition (DTD). A DTD states what tags and attributes are used to
describe content in an SGML document, where each tag is allowed, and which tags
can appear within other tags. For example, in a DTD one could say that LIST tags can
contain ITEM tags, but ITEM tags cannot contain LIST tags. In some editors, when
authors are inputting information, they can place tags only where the DTD allows. This
ensures that all the documentation is formatted the same way.
Domain Name Server (DNS). A method for naming resources. The basic function of the
DNS is to provide information about network objects by answering queries.
domain. In the Internet, a part of the naming hierarchy. Syntactically, a domain name
consists of a sequence of names (labels) separated by periods (dots).
DTD. ISee Document Type Definition (DTD).
EJB. ISee Enterprise JavaBeans (EJB)
Enterprise JavaBeans (EJB). Enterprise JavaBeans (EJB) is a Java API developed by
Sun Microsystems that defines a component architecture for multi-tier client/server
systems. EJB systems allow developers to focus on the actual business architecture of
the model, rather than worry about endless amounts of programming and coding
needed to connect all the working parts. This task is left to EJB server vendors.
Developers just design (or purchase) the needed EJB components and arrange them
on the server. Because EJB systems are written in Java, they are platform
independent. Being object oriented, they can be implemented into existing systems
with little or no recompiling and configuring.
Ethernet. A popular local area network (LAN) technology invented at the Xerox Corporation
Palo Alto Research Center. An Ethernet itself is a passive coaxial cable; the
interconnections all contain active components. Ethernet is a best-effort delivery
system that uses CSMA/CD technology. Xerox Corporation, Digital Equipment
Corporation, and Intel Corporation developed and published the standard for 10 Mbps
Ethernet.
File Transfer Protocol (FTP). The Internet standard, high-level protocol for transferring files
from one machine to another. Usually implemented as application-level programs, FTP
uses the TELNET and Transmission Control Protocol (TCP) protocols. The server side
requires a web client to supply a login identifier and password before it will honor
requests.
FTP. See File Transfer Protocol (FTP).
gateway. A special-purpose, dedicated computer that attaches to two or more networks and
routes packets from one to the other. In particular, an Internet gateway routes Internet
Protocol (IP) datagrams among the networks to which it is connected. Gateways route
packets to other gateways until they can be delivered to the final destination directly
Glossary- 2
Glossary
GESA
across one physical network. The term is loosely applied to any machine that transfers
information from one network to another, as in mail gateway.
GESA. See Gigabit Ethernet ServerNet Adapter (GESA).
Gigabit Ethernet ServerNet Adapter (GESA). A single-port ServerNet adapter that
provides Gigabit connectivity on a NonStop S-series server. The GESA installs directly
into an existing Ethernet port, and multiple GESAs are supported in a system
enclosure.
hierarchical routing. Routing based on a hierarchical addressing scheme. Most Internet
routing is based on a two-level hierarchy in which an Internet address is divided into a
network portion and a host portion. Gateways use only the network portion until the
datagram reaches a gateway that can deliver it directly. Subnetting introduces
additional levels of hierarchical routing
HyperText Markup Language (HTML). The tagging language used to format HyperText
documents on the World Wide Web. It is built on top of Standard Generalized Markup
Language (SGML).
HyperText Transport Protocol (HTTP). The communications protocol used for transmitting
data between servers and web clients (browsers) on the World Wide Web.
IEEE. See Institute of Electrical and Electronics Engineers (IEEE).
Institute of Electrical and Electronics Engineers (IEEE). An international industry group
that develops standards for many areas of electrical engineering and computers.
Internet address. The 32-bit address assigned to hosts that want to participate in the
Internet using TCP/IP. Internet addresses are the abstraction of physical hardware
addresses, just as the Internet is an abstraction of physical networks. Actually
assigned to the interconnection of a host to a physical network, an Internet address
consists of a network portion and a host portion. The partition makes routing efficient.
Internet Protocol (IP). The Internet standard protocol that defines the Internet datagram as
the unit of information passed across the Internet and that provides the basis for the
Internet connectionless, best-effort packet delivery service.
Internet. Physically, a collection of packet-switching networks interconnected by gateways,
along with protocols that allow them to function logically as a single, large, virtual
network. When written in uppercase, INTERNET refers specifically to the DARPA
Internet and the TCP/IP protocols it uses.
interoperability. The ability of software and hardware on multiple machines from multiple
vendors to communicate meaningfully.
IP.
See Internet Protocol (IP).
J2EE. See Java 2 Platform Enterprise Edition (J2EE)
Glossary- 3
Glossary
Java 2 Platform Enterprise Edition (J2EE)
Java 2 Platform Enterprise Edition (J2EE). J2EE is a platform-independent, Java-centric
environment from Sun for developing, building, and deploying Web-based enterprise
applications online. The J2EE platform consists of a set of services, APIs, and
protocols that provide the functionality for developing multitiered, Web-based
applications.
Java Database Connectivity (JDBC). The Java standard for access to relational
databases such as SQL/MP or SQL/MX.
Java Naming and Directory Interface (JNDI). A standard extension to the Java platform,
which provides Java technology-enabled application programs with a unified interface
to multiple naming and directory services.
JavaServer Page (JSP). A server-side technology, JavaServer Pages are an extension to
the Java servlet technology that was developed by Sun.
Java Thread. A part of a program that can execute independently of other parts. Operating
systems that support multithreading enable programmers to design programs whose
threaded parts can execute concurrently.
JDBC. See Java Database Connectivity (JDBC).
JNDI. See Java Naming and Directory Interface (JNDI).
Joint Photographic Expert Group (JPEG). An image format used to transmit graphics on
the World Wide Web (WWW).
JPEG. See Joint Photographic Expert Group (JPEG).
JSP. See JavaServer Page (JSP)
key database file. The file in which you maintain keys you generated using the keyadmin
command with either the -mkpair or -keydb argument. These are the keys you use to
generate certificates for software encryption. Compare WID keyfile.
Key Exchange Key (KEK). An encryption key used to encrypt other keys.
LDAP. See Lightweight Directory Access Protocol (LDAP).
Lightweight Directory Access Protocol (LDAP). A relatively simple protocol for updating
and searching directories running over TCP/IP.
local area network (LAN). Any physical network technology that operates at high speed
(usually from tens of megabits per second to several gigabits per second) over short
distances (up to a few thousand meters).
Netscape. See browser.
NonStop Kernel. The HP operating system, which consists of core and system services.
The operating system does not include any application program interfaces (APIs).
Glossary- 4
Glossary
NonStop Servlets for JavaServer Pages (NSJSP). NonStop Servlets for JavaServer
Pages (NSJSP) are platform-independent server-side programs that programmatically
extend the functionality of web-based applications by providing dynamic content from a
webserver to a client browser over the HTTP protocol.
nowait mode. In Guardian file-system operations and in some APS operations, the mode in
which the called procedure initiates an input/output (I/O) operation but does not wait for
it to complete before returning control to the caller. In order to make the called
procedure wait for the completion of the operation, the application calls a separate
procedure. Compare wait mode.
Open System Services (OSS). An open system environment available for interactive or
programmatic use with the NonStop Kernel operating system. Processes that run in
the OSS environment use the OSS application program interface (API); interactive
users of the OSS environment use the OSS shell for their command interpreter.
OSS applications. POSIX compliant applications.
OSS. See Open System Services (OSS).
packet. The unit of data sent across a packet-switching network. While some Internet
literature uses it to refer specifically to data sent across a physical network, other
literature views the Internet as a packet-switching network and describes IP datagrams
as packets.
PATHMON. The central controlling process for a NonStop TS/MP application.
Pathway. The former name of NonStop TS/MP, a product providing transaction services for
persistent, scalable, transaction-processing applications.
physical layer. Layer 1 in the OSI Reference Model. This layer establishes the actual
physical connection between the network and the computer equipment. Protocols at
the Physical Layer include rules for the transmission of bits across the physical
medium and rules for connectors and wiring.
process. A running entity that is managed by the operating system, as opposed to a
program, which is a collection of code and data. When a program is taken from a file
on a disk and run in a processor, the running entity is called a process.
protocol. A formal description of the message formats and rules two or more machines
must follow to exchange messages. Protocols can describe low-level details of
machine-to-machine interfaces (for example, the order in which the bits from a byte are
sent across a wire) or high-level exchanges between application programs (for
example, the way in which two programs transfer a file across the Internet). Most
protocols include both intuitive descriptions of the expected interactions and more
formal specifications using finite state-machine models.
QIO subsystem. A product that provides buffers and control blocks for protocol processes,
including TCP/IP, TLAM, and NonStop IPX/SPX running on the same processor.
Glossary- 5
Glossary
Request for Comments (RFC)
Request for Comments (RFC). The name of a series of notes that contain surveys,
measurements, ideas, techniques, and observations, along with proposed and
accepted Internet protocol standards. RFCs are edited but not referenced. They are
available across the Internet.
RFC. See Request for Comments (RFC).
sandbox. A protected memory space wherein a program cannot access outside resources
such as file or network services.
Secure Sockets Layer (SSL). A protocol for private communication on the World Wide
Web and authentication of a web server by a web client.
server. A process or set of processes that satisfy requests from web clients in a clientserver environment.
server class. A grouping of duplicate copies of a single server program, all of which
execute the same object program.
server process. A process that implements requests for an application and returns replies
to the requester.
server programs. In NonStop TS/MP, programs that handle the data manipulation and data
output activities for online transaction processing applications. Server programs are
designed to receive request messages from requester programs; perform the desired
operations, such as database inquiries or updates, security verifications, numerical
calculations, or data routing to other computer systems; and return reply messages to
requester programs.
servlet. A server-side Java program that any World Wide Web browser can access. It
inherits scalability and persistence from the Pathway CGI server that manages it. The
Java class named servlets executes in server environments such as World Wide
Web servers. The Servlet API is defined in a draft standard by Sun Microsystems.
Simple Mail Transfer Protocol (SMTP). The Internet standard protocol for transferring
e-mail messages from one machine to another. SMTP specifies how two mail systems
interact, and specifies the format of control messages the two mail systems exchange
to transfer mail.
SSL. See Secure Sockets Layer (SSL).
subnet address. An extension of the Internet addressing scheme that allows a site to use a
single Internet address for multiple physical networks. Outside of the site using subnet
addressing, routing continues as usual by dividing the destination address into an
Internet portion and local portion. Gateways and hosts inside a site using subnet
addressing interpret the local portion of the address by dividing it into a physical
network portion and host portion.
Glossary- 6
Glossary
subsystem
subsystem. The software and/or hardware facilities that provide users with access to a set
of communications services.
Transmission Control Protocol (TCP). The Internet standard transport-level protocol that
provides the reliable, full-duplex stream service on which many application protocols
depend. TCP allows a process on one machine to send a stream of data to a process
on another. It is connection-oriented, in the sense that before transmitting data
participants must establish a connection. Software implementing TCP usually resides
on the operating system and uses the Internet Protocol (IP) to transmit information
across the Internet. It is possible to terminate (shut down) one direction of flow across
a TCP connection, leaving a one-way (simplex) connection. The Internet protocol suite
is often referred to as TCP/IP because TCP is one of the two most fundamental
protocols.
TELNET. The Internet standard protocol for remote terminal connection service. TELNET
allows a user at one site to interact with remote timesharing systems at another site
just as if the user’s terminal is connected directly to the remote machine. That is, the
user invokes a TELNET application program that connects to a remote machine,
prompts for a login ID and password, and then passes keystrokes from the user’s
terminal to the remote machine and displays output from the remote machine on the
user’s terminal.
TLD. See Top-Level Domain (TLD)
Top-Level Domain (TLD). Refers to the suffix attached to Internet domain names. There
are a limited number of predefined suffixes, and each one represent a top-level
domain. Current top-level domains include:
•
•
•
•
•
•
com – Commercial businesses; this is the most common TLD
gov – U.S. government agencies
edu – Educational institutions, such as universities
org – Organizations (mostly nonprofit)
mil – Military
net – Network organizations
Unicode. The 16-bit character encoding used by Java for the char and java.lang.String data
types.
URL. Uniform Resource Locator.
wait mode. In the NonStop Kernel operating system, the mode in which the called
procedure waits for the completion of an input/output (I/O) operation before returning a
condition code to the caller. Compare nowait mode.
Web Container. a Java runtime environment that manages the lifecycle of servlets and
JSP.
Glossary- 7
Glossary
Web clients
Web clients. Programs that execute on IBM-compatible PC, Apple Macintosh, or Unix
platforms, among others. They provide a graphic user interface (GUI) for access to
documents and programs on the Web. A web browser is the most familiar example of a
web client.
Web server. Web servers are programs that execute on a variety of server platforms.
These include IBM-compatible servers, Apple Macintosh servers, Unix servers, and a
large number of proprietary hosts. Web server functions can be divided into two parts.
A file server part performs normal file server functions such as file transfer and
buffering. A message switching facility allows messages from web clients to be
forwarded to application programs.
WID keyfile. The file in which you maintain keys you generated using the keyadmin
command with the -websafegen argument. These are the keys you use to generate
certificates for hardware encryption. Compare key database file.
World Wide Web (WWW) protocols. The WWW protocols were first defined by the CERN
project in Switzerland and were later extended by a number of groups, most notably by
the National Center for SuperComputing Applications (NCSA) at the University of
Illinois. These WWW protocols were originally developed to improve communications
over the Internet by providing the ability to access and display web-client
hardware-independent documents that not only contained ASCII text but that also
contained pictures, graphics, and voice and video elements. In addition to accessing
documents, the WWW protocols can also be used to provide document searching
facilities and also interaction with user-written or vendor-provided servers.
WWW. See World Wide Web (WWW) protocols.
XML. Short for Extensible Markup Language, a specification developed by the W3C. XML is
a pared-down version of SGML, designed especially for Web documents. It allows
designers to create their own customized tags, enabling the definition, transmission,
validation, and interpretation of data between applications and between organizations.
Glossary- 8
Index
A
Abstract Windows Toolkit (AWT) 4-4
access control 1-4
active sessions, maximum 3-53/3-54
Admin Web Application
administering connector objects 4-19
administering context objects 4-20
administering default context
objects 4-21
administering host objects 4-20
administering logger object 4-22
administering realm objects 4-22
administering resources 4-26
administering server objects 4-16
administering service and engine
objects 4-17
administering user definition 4-28
administering valve objects 4-25
environment entries 4-27
login and security 4-12
mail sessions 4-27
resource links 4-27
user databases 4-27
algorithm
NSJSPPersistentManager
attribute 3-53
NSJSPStandardManager attribute 3-52
ALTER TABLE command 3-50
Apache Struts framework 4-10
Apache Tomcat
implementation 4-10
applications
directory 1-6
logic 1-3
setting behaviors of 3-11
subdirectory 3-20
arglist parameter 3-2
attributes
className 3-49
connectionURL 3-35
javax.servlet.ServletContext 1-9
of Host element 3-28
users file 3-30
authenticate() method 3-31, 3-35, 3-46
B
backup, of configuration files 3-2
base default contexts 1-6
BASIC authentication 3-31, 3-35
browser 1-3, 3-19
C
catalina.policy file 3-21
CATALINA_HOME environment
variables 3-21
CGI application 4-1
checkInterval
attribute 3-53
Store element attribute 3-55
classes
GenericServlet 4-4, 4-5
HttpJspBase 1-7
HttpServlet 4-4
HttpServletRequest 4-5
HttpServletResponse 4-5
java.security.MessageDigest 3-30,
3-37, 3-42, 3-44, 3-45, 3-52/3-53
java.security.SecureRandom 3-53,
3-55
java.text.MessageFormat 3-37
java.util.random 3-53, 3-55
JNDI API 3-35
NSJSPStandardManager 3-49
Index-1
Index
D
org.apache.catalina.realm.RealmBase
3-46
ServletRequest 4-5
ServletResponse 4-5
className
attribute 3-49
JDBCRealm attribute 3-33
JNDIRealm attribute 3-36, 3-42, 3-43,
3-45
Manager element attribute 3-51
MemoryRealm attribute 3-30
attribute 3-53
cleanup utility 6-4
client
application 1-3
certificate chain, for all secure
requests 4-8
request 1-7
web 1-3
client-side certificates 4-8
codeBase entry 3-21
component-based technology 1-4
configuration file
iTP_server.xml 4-32, 7-2
jdbc.config 7-2
nsjspadmin.config 4-31, 7-2
servlet.config 7-2
connectionName, JNDIRealm
attribute 3-36, 3-42, 3-43
connectionPassword, JNDIRealm
attribute 3-36
connectionURL
attribute 3-35
JNDIRealm attribute 3-37
Connector element 3-9
Considerations 8-1
Container objects
connector C-2
context and default context C-7
engine C-5
host C-6
loader C-11
logger C-12
manager C-13
realm C-21
resource C-16
server C-1
service C-2
valve C-27
container objects 4-9
Container/JVM process 3-49
context configuration 7-2
Context element 3-9, 3-29, 3-31, 3-35,
3-46/3-48, 3-51/3-52
controller 1-9
cookies 3-46
COPYOSS macro 2-2
CREATE TABLE command 3-50
cron job 5-20
D
deallocating resources 4-5
debug
JNDIRealm attribute 3-37
attribute 3-54
defaultHost attribute 3-28
deployment descriptor 1-4, 3-11
destroy() method 1-4, 2-7, 4-5
digest
JNDIRealm attribute 3-37, 3-42, 3-44,
3-45
Index-2
Index
E
digest algorithm 3-30, 3-33, 3-37, 3-42,
3-44, 3-45
digested user password 3-37, 3-45
Digest() method 3-46
DirContext 3-35
directives 1-10
directory
example 2-11
structure 1-6, 2-9
distinguished name (dn) attribute 3-35
distributable, Manager element
attribute 3-51
Djdbc.drivers optional argument 3-4
docBase attribute 3-20
doGet() method 4-5
doPost() method 4-5
driverName, JDBCRealm attribute 3-34
dynamic content 1-3
E
elements
additional ones not described
here 3-10
Connector 3-9
Context 3-9, 3-31, 3-35, 3-46/3-49,
3-51/3-52
distributable 3-51
Engine 3-9, 3-28, 3-31, 3-35, 3-46/3-48
Host 3-9, 3-28, 3-31, 3-35, 3-46/3-48
Logger 3-30/3-31, 3-33, 3-35, 3-52,
3-55
login-config 3-47
Manager 3-49, 3-51/3-53, 3-55
Realm 3-33, 3-42, 3-43, 3-44,
3-46/3-48
security-constraint 3-47
Server 3-9
Service 3-9
servlet-class 3-20
servlet-name 3-20
session-timeout 3-52
Store 3-52/3-53, 3-55/3-56
EMS
log 6-1
message 2-6, 6-8
Engine element 3-9, 3-28, 3-29, 3-31, 3-35,
3-46/3-48
entropy
attribute 3-54
environment variables
accessing 4-1
list of 4-6
error
information 4-5
tracking 6-1
execution threads, stopping 4-7
expiration time for session cookies 3-5
expired sessions 3-52/3-53
expressions 1-10
extra path information, appended to
URLs 4-1
F
features, new in NSJSP 2.0 1-14
filemap 3-10
FORM-based authentication 3-31, 3-35,
3-48
FTP 2-2
G
GenericServlet class 4-4, 4-5
getAttribute() method 4-5
getRequestDispatcher(String name)
method 1-10
graphical user interface (GUI) 4-4
GUI 1-3
Index-3
Index
H
H
J
header information 4-2
Host element 3-9, 3-28, 3-29, 3-31, 3-35,
3-46/3-48
hosting, virtual 3-28
HTML
clients 1-12
dynamic 1-4
forms 4-1
HTTP
cookies 3-48
protocol 1-1
resources 1-3
response headers 4-2, 4-5
sessions 3-48
HTTPD process 1-12, 2-6
HTTPS protocol 4-8
HttpServlet class 4-4
HttpServletRequest class 4-5
HttpServletRequest object 1-10
HttpServletResponse class 4-5
HttpServletResponse object 1-10, 3-19
J2EE
architecture 1-3
concepts 1-3
J2EE-compliant web server 1-5
JAR files
identifying directories with 3-4
Java
beans 1-5, 1-8
beans, invisible 4-4
bytecode 1-5
class files 1-6, 2-12
class garbage collection 3-3
code 1-10
Developer’s Kit 4-3
environment 4-4
language and tools 1-2
NonStop Server for 4-3
runtime arguments 3-3
runtime environment 1-3
security manager 3-21
source files 2-12
Java Database Connectivity (JDBC)
driver 3-29
Java Naming and Directory Interface (JNDI)
provider 3-29
Java Security Manager
debug logging 3-25
policy file setting 3-4
setting 3-4
Java Servlet 2.3 specification 1-1
Java threads
spawning from within a servlet or
JSP 4-6
Java Virtual Machine (JVM) 1-12
JavaServer Pages 1.2 specification 1-1
JavaServer Pages (JSP) 1-4
javax.servlet package 4-4
javax.servlet.http package 4-4
javax.servlet.request.X509Certificate 4-8
I
include directive 1-10
inconsistent conditions 4-30
init(ServletConfig) method 4-5
init() method 1-4
input stream, accessing 4-1
installation instructions 2-1
international character set 4-7
IPSetup 2-1
iTP Secure WebServer
creation of servlets 1-13
environment 1-2
processes 1-12
V6.0 SPR ABM 2-1
iTPWebSessionId cookie name 4-8
iTP_catalina.policy file 3-21
iTP_server.xml file 3-1, 3-10/3-11
Index-4
Index
L
java.io.Serializable interface 3-51
java.policy file 3-21
java.security.MessageDigest class 3-30,
3-37, 3-42, 3-44, 3-45, 3-52/3-53
java.security.SecureRandom class 3-53,
3-55
java.text.MessageFormat class 3-37
java.util.random implementation class 3-53,
3-55
JAVA_HOME environment variable 3-21
JDBC driver 3-31, 3-34
jdbcMx.jar file 3-56
JDBCRealm 3-29, 3-31
attributes 3-33
catalog 3-33
rules 3-35
container objects 4-9
JNDI
connection 3-36
provider 3-35
JNDI API classes 3-35
JNDIRealm 3-29, 3-35
JNDIRealm attributes 3-36, 3-42, 3-43,
3-44
JSESSIONID cookie name 4-8
JSESSIONIDSSO cookie name 4-8
JSP 1-4
code 1-7
files 1-4
layout 1-5
pages 1-7
static templates 1-9
JSP API 1.2 4-4
jspDestroy() method 1-7
jspInit() method 1-7
L
LDAP
protocol 3-29
provider 3-35
search pattern 3-37
LDAP search pattern 3-37
Lightweight Directory Access Protocol
(LDAP) directory server 3-29
load-on-startup element 3-11
log files 3-35, 6-1
creating 3-31
logger 3-54
Logger element 3-30/3-31, 3-33, 3-35,
3-52, 3-55
login-config element 3-47
M
make, rerunning 2-1
Manager element 3-49, 3-51/3-53, 3-55
accessing 5-1
application area 5-4
architecture 5-1
complete NSJSP status 5-16
deploy area 5-5
manager area 5-4
message box 5-3
NSJSP container status 5-7
NSJSP information area 5-5
NSJSP status command 5-7
security constraints 5-1
user interface 5-1
mapping
file 3-1
requests to servlets 1-4
maxActiveSessions
attribute 3-54
maxIdleBackup, NSJSPPersistentManager
attribute 3-54
maxIdleSwap, NSJSPPersistentManager
attribute 3-54
maxInactiveInterval, Manager element
attribute 3-52
Index-5
Index
N
Maxservers
attribute 4-6
server directive 3-2
MD5 3-45
memory allocation pool, maximum 3-3
MemoryRealm 3-28/3-29
attributes 3-30
rules of operation 3-31
message digest algorithm 3-52/3-53
methods
authenticate() 3-31, 3-35, 3-46
destroy() 1-4, 2-7, 4-5
Digest() 3-46
doGet() 4-5
doPost() 4-5
getAttribute() 4-5, 4-6
getRequestDispatcher(String
name) 1-10
init(ServletConfig) 4-5
init() 1-4
jspDestroy() 1-7
jspInit() 1-7
println() 1-10
service(HttpServletRequest) 4-5
service(HttpServletResponse) 4-5
service() 1-4, 4-6
ServletRequest 4-4
ServletResponse 4-4
setContentType() 3-19
where to find list of 4-4
_jspService() 1-7
middleware layer 1-3
migrating
configuration 7-2
directory structure 7-1
installation 7-1
MIME
mapping. 3-19
types 1-4, 1-6, 3-19
mime-types.config file 3-19
minIdleSwap, NSJSPPersistentManager
attribute 3-54
Model-View-Controller, architecture 1-3
multiple requests 4-7
Multipurpose Internet Mail Extensions
(MIME) types 3-19
multi-threading
NSJSP process 3-2
out-of-process servlet container 1-12
N
name, users file attribute 3-30
NonStop Kernel files 2-2
NonStop Server for Java (NSJ) 2-1, 4-3
NonStop SQL
catalog 3-58
catalog and table 3-49
database 3-49
database table 3-58
NonStop SQL Command Interpreter
(SQLCI) 3-32, 3-49
NonStop SQL JDBC-based store 3-58
NonStop SQL/MP databases 4-2
NonStop SQL/MX databases 4-2
NonStop TM/MP (TMF) audited data
volume 3-33
NonStop TS/MP
server class 4-2
server processes 1-13
NonStopSQLJDBCStore 3-55, 5-20
NSJSP
architecture 1-12
definition 1-1
installing 2-1
logger 6-4
Realm interface 3-31
sample page 2-6, 4-4
server process 3-2
ServerClass 3-1
servlet container 3-1
nsjspadmin.ssc 4-31
Index-6
Index
O
NSJSPPersistentManager 3-52
attributes 3-53
NSJSPStandardManager
attributes 3-52
class 3-49
implementation 3-52/3-53
nsjsp_cleanlogs options
-b backup_directory 6-5
-d log_file_directory 6-5
-n number_of_days 6-5
-s 6-5
-x log_file_extension 6-5
nsjsp_cleanlogs script 6-4
nsjsp_cleanSessionData script 3-57
nsjsp_stop script 2-6, 3-55
Numstatic
attribute 4-6
server directive 3-2
O
objects
HttpServletRequest 1-10
HttpServletResponse 1-10, 3-19
RequestDispatcher 1-10
OpenLDAP directory server 3-38
org.apache.catalina.Manager
interface 3-51
org.apache.catalina.realm.RealmBase
class 3-46
OSS
command 3-49
environment 2-1
P
page directive 1-10
page-based design 1-4
passwords 3-30
clear text 3-46
digested 3-46
storing 3-30, 3-33
password, users file attribute 3-30
PATHCOM utility 2-6
pathname, MemoryRealm attribute 3-30
Pathway CGI interfaces 4-7
PATH_INFO environment variable 4-1, 4-5
PATH_TRANSLATED environment
variable 4-1, 4-5
performance benefits 4-2
permissions, assigning additional to web
applications 3-21
persistence 4-2, 4-6
persistent data store 3-55
persistent session data
storing 3-49
persistent sessions
configuring 3-49
using 4-6
persistent store 3-53
presentation component, or View 1-9
pre-compiled JSPs 7-4
println() method 1-10
private files 1-6
Q
Query strings, appended to URLs 4-1
QUERY_STRING environment
variable 4-1, 4-5
R
random number generator 3-52, 3-54
randomClass
attribute 3-55
Readme file 2-1
realm
database 3-28
definition 3-28
Realm element 3-29, 3-33, 3-36, 3-42,
3-43, 3-44, 3-46
Realm element, example 3-34, 3-39
Index-7
Index
S
Region directive 4-7
reinstallation 2-9
reload support, automatic (not
recommended for production
applications) 3-11
reloadable attribute 3-11
request dispatcher 1-9
RequestDispatcher object 1-10
requests, sending 4-1
request-response relationship 1-3
response content 4-2
responses, receiving 4-1
restart script 2-6
role 3-32
role name 3-37
roleBase attribute 3-36
roleBase, JNDIRealm attribute 3-37
roleName attribute 3-36
roleNameCol, JDBCRealm attribute 3-34
roleName, JNDIRealm attribute 3-37
roles 3-32, 8-1
roleSearch, JNDIRealm attribute 3-36/3-37
roleSubtree, JNDIRealm
attribute 3-36/3-37
roles, users file attribute 3-31
rollover, log files 6-4
S
Safeguard 4-7
saveOnRestart, NSJSPPersistentManager
attribute 3-55
saving sessions to a persistent store 3-4
scalability 3-50, 4-2, 4-6
scaling, across multiple CPUs 1-12
script 5-22
scripting elements 1-10
scriptlets, Java 1-5, 1-10
scripts
nsjsp_cleanConfigBackups 5-22
nsjsp_cleanSessionData 3-57
nsjsp_stop 3-55, 3-58
stop 3-55, 3-58
secure network connection 3-48
security 4-7
security considerations 8-1
security manager 2-6, 3-21
security-conscious environment 3-52, 3-54
security-constraint element 3-47
Server element 3-9
Service element 3-9
service(HttpServletRequest) method 4-5
service(HttpServletResponse) method 4-5
service() method 1-4, 4-6
Servlet
API
runtime management 1-4
servlet 3-20
API
supported classes and
methods 4-4
using 4-4
instantiation 1-4
lifecycle 1-12
optional arguments
-Dbrowserdebug 3-3
-Djava.endorsed.dirs 3-4
-Djava.io.tmpdir 3-4
-Djava.security.manager 3-4
-Djava.security.policy 3-4
-Djdbc.drivers 3-4
-DSaveSessionOnCreation 3-4, 3-5
-DSessionBasedCookieExpiry 3-5
DSessionBasedLoadBalancing 3-5
-Xmx 3-3
-Xnoclassgc 3-3
-Xss 3-3
passing information 4-1
referring to in HTML document 4-1
Servlet API 2.3 4-3/4-4
Servlet API and JSP programs 1-3
Index-8
Index
S
servlet application programming interface
(API) 1-2
servlet initialization parameters 1-4
SERVLET ServerClass 3-2
ServletException class 4-5
ServletJSPConnector.jar class file 2-6
ServletRequest class 4-5
ServletRequest method 4-4
ServletResponse class 4-5
ServletResponse method 4-4
servlet-class element 3-20
servlet-name element 3-20
servlet.config file 3-1, 7-2
servlet_error.log file 2-6
SERVLET_JSP_HOME environment
variable 3-2
session
clean up 5-20
identifiers 3-52, 3-54
manager 3-51
manager, persistent 3-53
persistent 3-2
store 3-54
support 3-2
timeout value 3-48
tracking 4-6
sessionDataCol, Store element
attribute 3-57
sessionIdCol, Store element attribute 3-56
sessionLastAccessedCol, Store element
attribute 3-57
sessionMaxInactiveCol, Store element
attribute 3-57
sessionProcessNameCol, Store element
attribute 3-57
sessionRecNumberCol, Store element
attribute 3-57
sessionTable, Store element attribute 3-56
sessionValidCol, Store element
attribute 3-57
session-based load balancing 3-5, 4-6
session-timeout element 3-52
session_id
field 3-51
key 3-50
setContentType() method 3-19
setup script 2-4
setupjava script 2-3
SHA 3-45
shell 5-21
shell scripts 5-21
nsjsp_digestPassword 5-22
nsjsp_migrateSessionStore 5-21
signedBy entry 3-21
single sign-on 8-1
rules 3-48
support 3-46
SingleThreadModel interface 4-7
SQL
driver, identifying 3-4
script, location of sample 3-49
sqlmp.jar file 3-56
SQL/MP
connection URL 3-56
databases 4-3
driver name 3-34, 3-56
for Java 3-4, 4-3
specifying driver for 3-4
SQL/MX
connection URL 3-56
databases 4-3
driver name 3-34, 3-56
for Java 3-4, 4-3
stack size, maximum 3-3
standard error (STDERR) file 6-1
standard manager implementation 3-52
standard output (STDOUT) file 6-1
start script 2-6
stop script 2-6, 3-55
storage location, for session data 3-52
Store element 3-52/3-53, 3-55/3-56
stream behavior 4-7
Index-9
Index
T
string value 3-52
Sun Microsystems
Java Developer’s Kit 4-3
Java website, java.sun.com 1-7
T
TCP/IP
availability or automatic file
placement 2-2
running process required 2-6
templating 1-10
temporary directory 3-4
threading synchronization 4-7
three-tier model 1-3
TMF 4-4
U
Unicode set 4-7
uninstall script 2-8
URI 1-3
URL 1-3
user group element 3-36
userCredCol, JDBCRealm attribute 3-34
userNameCol, JDBCRealm attribute 3-34
userPassword attribute 3-36
userPassword, JNDIRealm attribute 3-37
userPattern, JNDIRealm attribute 3-37
userRole table 3-31/3-32
userRoleTable, JDBCRealm attribute 3-34
users file 3-30/3-31
users table 3-31
userTable, JDBCRealm attribute 3-34
USRGUIDE.PDF file 2-1
V
virtual host 3-28, 3-46
virtual hosts 8-1
W
WAR (web archive) files 1-4, 1-6
web 5-1
web applications
defined 1-5
logic for 1-3
web archive (WAR) files 1-6
web container
applications 1-4
class libraries 1-4
content 1-3
environment 1-12
for servlets 1-3
images 1-4
processes 3-2
resources 1-4
services 1-4
WEB-INF subdirectory 1-6, 2-12
web.xml file 1-4, 2-12, 3-1, 3-11
X
XML
file 3-9
XML-like tags and scriptlets 1-5
Xmx optional argument 3-3
Xnoclassgc optional argument 3-3
Xss optional argument 3-3
Special Characters
${catalina.home} property 3-21
${java.home} property 3-21
-b backup_directory nsjsp_cleanlogs
option 6-5
-d log_file_directory nsjsp_cleanlogs
option 6-5
-Dbrowserdebug option 3-3
-Djava.endorsed.dirs option 3-4
-Djava.io.tmpdir option 3-4
-Djava.security.manager option 3-4, 3-21
Index-10
Index
Special Characters
-Djava.security.policy option 3-4
-DSaveSessionOnCreation option 3-4, 3-5
-DSessionBasedCookieExpiry option 3-5
-DSessionBasedLoadBalancing option 3-5
-n number_of_days nsjsp_cleanlogs
option 6-5
-s nsjsp_cleanlogs option 6-5
-x log_file_extension nsjsp_cleanlogs
option 6-5
_ 1-7
_jspService method 1-7
Index- 11
Index
Special Characters
Index-12

NonStop Servlets for JSP System Administrator`s Guide

Transcription

Similar documents

fair posters

Media Kit - Nonstop Magazine

Windows XP Configuration

Cover

Compaq/New HP Business and NonStop Server Update

Mise en page 1

Portfolio Christoph Gerstner - game