SilverStream eXtend Director
Version 4.0
Release Notes

July 2002

Welcome to SilverStream extend Director Version 4.0.

These Release Notes include the following sections:

Installing Director 4.0 A listing of what is required before starting the Installation Wizard, and a description of the differences between typical and custom installations
Software and database requirements A listing of application servers, operating systems, databases, and browsers supported by this version of SilverStream extend Director
What's new in Version 4.0 A listing of the new features in this version of SilverStream extend Director
Getting started Directions to introductory documentation on using SilverStream extend Director
Upgrading existing Director applications Directions to information about converting SilverStream extend Director 3.0 applications to Version 4.0
Known issues Descriptions of known problems with this version of SilverStream extend Director, providing workarounds if available
Importing and exporting content management data Notes on best practices for importing and exporting content management data
XML/IPDR logging Information about two new logging providers that have been added to the existing logging system

Installing Director 4.0

This section discusses what you need to consider before running the Installation Wizard.

Before you install

Before installing SilverStream extend Director 4.0:

Understanding the differences between typical and custom installations

The Installation Wizard provides two installation options: Typical and Custom. If you choose the typical installation, all features of SilverStream extend Director are installed, including:

If you do not want to install one or more of these components, you can choose the custom installation and omit them.

Software and database requirements

Application servers supported by Version 4.0:

Operating systems supported by Version 4.0:

Databases supported by Version 4.0:

Web browsers supported by Version 4.0:

What’s new in Version 4.0

Getting started

The Getting Started section of the SilverStream extend Director online help provides an overview of Director capabilities, instructions on how to quickly build and deploy a Director application, and links to more information about Director. The Getting Started section includes these topics:

Welcome Provides a high-level summary of SilverStream extend Director features and some quick links to introductory information.
Where to Begin Describes the recommended paths to follow in the documentation based on your level of expertise and what you want to know about SilverStream extend Director.
Release Notes Opens these Release Notes.
Quick Start Serves as a primer for experienced J2EE programmers who want to begin using Director immediately. Provides instructions on how to create, deploy, and examine a complete Director application.
Help and Documentation Provides instructions on how to use SilverStream extend Director online help. Also includes SilverStream trademark and copyright information.
SilverStream Links Provides links to the SilverStream home page and the SilverStream DevCenter.

The Core Development Guide provides a more detailed presentation of Director functionality, architecture, and development environment and processes.

Upgrading existing Director applications

You can convert Director 3.0 applications to Director Version 4.0. For detailed information about planning and procedures required to upgrade existing applications, see the Upgrade Guide. Also see the first four entries in the Director functionality section under Known issues (next).

Known issues

Director 4.0 known issues are divided into the following sections:

Director functionality

Server issues—general

Using Director with SilverStream extend Application Server

Using Director with IBM WebSphere Server

Using Director with BEA WebLogic Server

Browser issues—general

Importing and exporting content management data

This section provides some notes on best practices for importing and exporting content management data.

For additional information on importing and exporting content management data, see the Known issues section of these Release Notes.

Planning for large-scale import/export operations

If you are planning to export or import a very large amount of content management data, it is important to keep the memory capacity of your machines in mind as you plan your operation.

During an import or export operation, all objects representing elements of the repository must be present in memory at the same time. Therefore the amount of available memory imposes a practical limit on the size of a repository you can process in a single operation.

The best way to approach a large-scale operation is to export or import your source repository in logical chunks. For example, you might export all your document types in one operation, your fields in another operation, and so on, ending with exporting or importing your document content in manageable chunks according to the folder structure of your repository.

Security considerations

The notes in this section apply primarily to importing content management data that has been exported from another repository.

Permissions to establish in the import target

The user who performs the export from the source repository must exist and must have the SearchAdmin WRITE permission in the target repository.

Users to create in the import target

You need to make sure that if any documents were checked out at the time of export, the users to whom they are checked out have been created in the repository into which you are importing.

If these users do not exist in the import repository, the import will fail.

XML/IPDR logging

Two new logging providers have been added to the logging system. These give you the ability to generate:

The behavior of the two new logging providers is very similar to the behavior of the existing logging providers.

You add the two logging providers by using one of the following methods:

To get the log object, you need to use the getLog() method on the EboLogFactory class, as shown below:

logXML = (EboLog) EboLogFactory.getLog( "XML Test" );
logIPDR = (EboLog) EboLogFactory.getLog( "IPDR Test" );

Both providers have templates for the log file format. For example, the format for an XML file might be:

<:?xml version="1.0"?>:
<:root>:${event}<:/root>:

When a new log file is created, the template is used to format the file. The ${} variable is replaced with the actual log strings. The value specified within the braces is also added as an enclosing element. For example:

<:?xml version="1.0"?>:
<:root>:<:event>:logString2<:/event>:
<:event>:logString2<:/event>:
<:/root>:

For IPDR logging, different templates should be used. For example:

<:IPDRDoc seqNum="6530" version="1.0">:
   <:IPDRRec info="SilverStream"/>:
   <:IPDR seqNum="${Sequence}" time="${Time}">:
      <:SS id="sms" service="bin">:
         <:SC>:
            <:v name="customer_id">:${WapID}<:/v>:
         <:/SC>:
         <:SE>:
            <:v name="service">:sms-bin<:/v>:
         <:/SE>:
      <:/SS>:
      <:UE>:
         <:v name="pnummer">:${pnummer}<:/v>:
      <:/UE>:
   <:/IPDR>:
<:/IPDRDoc>:

The name of the template is specified as a tag in the log string. Each variable in the template should also be specified in the log string, unless it is one of the built-in properties (see Built-in properties below):

logIPDR.audit("aaaaa1")

Both kinds of templates should be placed in the Director\library\FrameworkService\FrameworkService-conf directory within a Director EAR project.

Built-in properties

The following built-in properties have been added to support XML and IPDR logging. Each of these properties can be set in the config.xml file for the Framework subsystem, or by calling a method on the EboLog class:

Property Description Value EboLog method
logFileTemplate The log file template to be used. The name of a template placed in the Director\library\FrameworkService\FrameworkService-conf.
Default value: xml-file.tpl		 setLogFileTemplate (String logFileTemplate)
addLogDateInfo Indicates whether a log Date should be added to the log string. true/false.
Default value: true		 setAddLogDateInfo (String addLogDateInfo)
logDateFormatMask The mask to use for the log Date information. java.text.SimpleDateFormat mask.
Default value: dd/MM/yy HH:mm:ss		 setLogDateFormatMask (String logDateFormatMask)
addLogTimeInfo Indicates whether a log Time should be added to the log string. True/false.
Default value: true		 setAddLogTimeInfo (String addLogTimeInfo)
logDateFormatMask The mask to use for the Date info (mainly used for the IPDR template). java.text.SimpleDateFormat mask.
Default value: yyyy-MM-dd'T'HH:mm:ss'Z'		 setLogTimeFormatMask (String logDateFormatMask)
addLogSequenceInfo Indicates whether a unique Sequence should be added to the log string. True/false.
Default value: true		 setAddLogSequenceInfo (String addLogSequenceInfo)

Sample portal component using XML and IPDR logging

package test.ipdr;
// potential useful imports

import com.sssw.portal.api.*;
import com.sssw.fw.api.*;
Import com.sssw.fw.exception.*;
//Import com.sssw.cm.api.*;
//Import com.sssw.re.api.*;
Import com.sssw.fw.log.*;

/**
 *    IPDR
 */
public class IPDR implements com.sssw.portal.api.EbiPortalComponent
{
        private com.sssw.fw.log.EboLog log;
        private com.sssw.fw.log.EboLog log2;

    /**
     * Initializes an Component object.
     *
     * @param  context  a wrapper around the request and response
     * @param  params   a map that contains parameters
     */
    public void initialize( com.sssw.portal.api.EbiPortalContext context, java.util.Map params ) throws com.sssw.fw.exception.EboUnrecoverableSystemException {
    }

    /**
     * Gets the component data (in HTML or XML format) at run-time.
     *
     * @param  context  a wrapper around the request and response
     * @param  params   a map that contains parameters
     */
    public void getComponentData( com.sssw.portal.api.EbiPortalContext context, java.util.Map params ) throws com.sssw.fw.exception.EboUnrecoverableSystemException {
        StringBuffer sb = new StringBuffer();
        // set the type of data being returned, html, xml, dom, non-visual
        //context.setContentType( com.sssw.portal.api.EbiComponentConstants.MIME_TYPE_NONVISUAL );
        //context.setContentType( com.sssw.portal.api.EbiComponentConstants.MIME_TYPE_DEVICE_PROFILING );
        //context.setContentType( com.sssw.portal.api.EbiComponentConstants.MIME_TYPE_XML );
        //context.setContentType( com.sssw.portal.api.EbiComponentConstants.MIME_TYPE_XMLDOM );
        //context.setContentType( com.sssw.portal.api.EbiComponentConstants.MIME_TYPE_HTML );
        context.setContentType( com.sssw.portal.api.EbiComponentConstants.MIME_TYPE_HTML_UTF8 );
        // build up the component return data, buffers are best
        //sb.append( "IPDR data goes here" );
        // place the content into the context

        log = (EboLog) EboLogFactory.getLog( "XML Test" );
        log.addLoggingProvider(EboUniqueXMLFileLoggingProvider.class.getName());
        log.audit("This is Jeff's event");

        log.removeLoggingProvider(EboUniqueXMLFileLoggingProvider.class.getName());

        log2 = (EboLog) EboLogFactory.getLog( "IPDR Test" );
        log2.addLoggingProvider(EboUniqueIPDRFileLoggingProvider.class.getName());
        log2.audit("555123455");

        log2.removeLoggingProvider(EboUniqueIPDRFileLoggingProvider.class.getName());

        sb.append("IPDR Test done for now.");
        context.setComponentContent( sb.toString() );
    }

    /**
     * Process request.
     *
     * @param  context  a wrapper around the request and response
     * @param  params   a map that contains parameters
     */
    public void processRequest( com.sssw.portal.api.EbiPortalContext context, java.util.Map params ) throws com.sssw.fw.exception.EboUnrecoverableSystemException {
        //process incoming items on the request object
        //String parm = context.getEbiRequest().getParameter("parm-name");
    }

}