Description:
The patch can be downloaded from the TIBCO Support ftp server, support-ftp.tibco.com. Please use your eSupport username and password to access the server. After connecting, go to /available_downloads/ActiveMatrix/ActiveMatrixRegistry/2.0/HotFix-4/ActiveMatrixRegistry-2.0-hotfix4.zip to download the hotfix .

=========================== Readme.txt  ===================
Tibco Active Matrix Registry 2.0 - Cumulative Patch


This patch is intended to be used with buildtime
"TAMR-2.0-20071008-1919" or "TAMR-2.0-20071129-1514" (Two Way SSL
support update) or "TAMR-2.0-20080710-1328" of Tibco Active Matrix
Registry 2.0. You can check this inside startup logs and
conf/buildtime file inside installed Registry.

This patch will update buildtime to "TAMR-2.0-20081114-1321".



How to apply
------------

Three scenarios are possible:

A, Patch installed Registry that is not deployed to application server.
B, Patch installed Registry that is deployed to application server.
C, Patch installer .jar file.



A, Patch installed Registry that is not deployed to application server
----------------------------------------------------------------------

Assumptions:

You have installed Registry into directory that will be referred to as
REGISTRY_HOME (this directory contains subdirectories app bin doc etc
lib, not the directory with "registry" or "2.0" subdirectory). You
have unpacked patch archive along with this readme file and the
"patch" subdirectory. Copy the "patch" subdirectory into new
location. The new copy will be referred to as PATCH_DIR. This copy is
needed because there will be some changes to the files before applying
the update and the changes will be incompatible with update
installation option C. As a later step of update process the PATCH_DIR
will be copied over to current REGISTRY_HOME.

Steps to install:

1, Stop the Registry if it is running.

2, (Optional but recommended) Make a backup copy of REGISTRY_HOME
   directory.

3, BSC console configuration files are in the path
   REGISTRY_HOME/work/uddi/bsc.jar/conf These files have to be placed
   into bsc.jar archive "conf" archive subdirectory which is contained
   in PATCH_DIR/registry_2_0/app/uddi/bsc.jar so that after update,
   you will have both new functionality and old customized
   configuration.

4, Delete file PATCH_DIR/registry_2_0/app/uddi/conf/database.xml This
   file contains changes for Oracle RAC support but it does not
   contain your database account information which you want to retain
   in updated registry. You may use the old database.xml file without
   changes unless you want the new feature "Oracle RAC support"
   (enabled by custom connection strings) to be active after
   update. In the case you want this, edit
   REGISTRY_HOME/app/uddi/conf/database.xml and place empty tag
   &ltcustomConnectionString></customConnectionString> into database.xml
   inside "driverProperty" tag (which is contained in "database" tag).

5, Delete file PATCH_DIR/registry_2_0/app/uddi/conf/directory.xml This
   file contains additional property for client authentication in
   LDAP.  If you want to setup LDAP to use client authentication as
   described in updated documentation section "LDAP over SSL With
   Mutual Authentication", add property tag

    &ltproperty name="uddi.ldap.clientCertificateAuthentication" value="false"/>
  
   to the "user" tag in directory.xml and configure it according to
   updated documentation.

6, Delete file PATCH_DIR/registry_2_0/conf/serverconf.xml This file
   contains settings like HTTP and HTTPS port, SSL certificate
   details. You want to retain this file in update registry.  Registry
   after update offers an option for using encoded password for SSL
   certificate key. If you want to change clear text password to
   encoded password, run

      REGISTRY_HOME/bin/sslTool.sh encrypt --password "your password"
   or REGISTRY_HOME\bin\sslTool.bat encrypt --password "your password"

   The tool will print encoded password. Change tag "password" in the
   httpsPreferences tag inside the REGISTRY_HOME/conf/serverconf.xml
   file to new name "password_coded" and place encoded password in it.

7, Copy directory structure from PATCH_DIR/registry_2_0 into
   REGISTRY_HOME overwriting existing files.  Copy file
   PATCH_DIR/registry_2_0/dist/wsdl2uddi_client_v3.jar over
   REGISTRY_HOME/app/uddi/wsdl2uddi_client_v3.jar.

8, Delete REGISTRY_HOME/work/uddi/services, REGISTRY_HOME/work/system,
   REGISTRY_HOME/work/uddi/wsdl2uddi_client_v3.jar,
   REGISTRY_HOME/work/uddi/bsc.jar, and
   REGISTRY_HOME/work/uddi/web.jar files and directories if they
   exists. They will be recreated on next start.

9, Start the Registry again.

Note: if you have any custom modifications to some .jar files that are
also inside patch, you will have to reapply them for those .jar files.



B, Patch installed Registry that is deployed to application server
------------------------------------------------------------------

Assumptions:

You have installed Registry into directory that will be referred to as
REGISTRY_HOME (this directory contains subdirectories app bin doc etc
lib, not the directory with "registry" or "2.0" subdirectory). You
have deployed Registry into registry.war/ear file and deployed the
file to application server. Application server unpacked file into some
internal directory that will be referred to as REGISTRY_AS_HOME (this
directory also contains subdirectories app bin doc). You have unpacked
patch archive along with this readme file and the "patch"
subdirectory. Copy the "patch" subdirectory into new location. The new
copy will be referred to as PATCH_DIR. This copy is needed because
there will be some changes to the files before applying the update and
the changes will be incompatible with update installation option C. As
a later step of update process the PATCH_DIR will be copied over to
current REGISTRY_HOME or REGISTRY_AS_HOME.


There are three places where old versions may reside:

Place 1, Inside of the REGISTRY_HOME directory.

Place 2, Inside of war/ear file which is located somewhere under
   REGISTRY_HOME/conf/porting/ directory depending on application
   server kind and version.

Place 3, Inside application server directory there is a place where
   Registry is unpacked, the REGISTRY_AS_HOME directory.



Note that some configuration data (like BSC configuration and
customization) are present only in deployed registry and changes to
some configuration data the registry administrator has made via
Registry Console Management are only in deployed registry too. If you
want to redeploy .war file and persist changes you have to backup
configuration files inside REGISTRY_AS_HOME/app/uddi/conf and
REGISTRY_AS_HOME/work/uddi/bsc.jar/conf so you can restore them after
redeployment.

Steps to install patch in place 1 are described in section A.

Steps to install patch in place 2:
1, Apply patch to REGISTRY_HOME as described in section A, but do not
   start Registry as last step.
2, Run setup, select "Deploy" option and fill-in values used last time
   (they are remembered except for passwords).
3, New war/ear file is available in the usual location.
4, This war/ear file does not contain old configuration data. Copy the
   backup of them to the war/ear file. The backup of
   REGISTRY_AS_HOME/app/uddi/conf should go to WARFILE/app/uddi/conf
   and the backup of REGISTRY_AS_HOME/work/uddi/bsc.jar/conf should go
   to WARFILE/app/uddi/bsc.jar/conf.

Steps to install patch in place 3:

1, (Optional but recommended) Make a backup copy of REGISTRY_AS_HOME
   directory.
2, Install patch in place 2 as described above.

3, Undeploy original WAR/EAR in application server, then deploy the
   new one. Just using redeploy or update option of application server
   might not be enough, because application server may leave old
   REGISTRY_AS_HOME/work directory there.

Alternatively it is possible to patch in place without redeploying:

1, Stop the Registry if it is running.
2, (Optional but recommended) Make a backup copy of REGISTRY_AS_HOME
   directory.
3, Make changes described in section A step 3 to step 5 (inclusive)
   but use REGISTRY_AS_HOME instead of REGISTRY_HOME.
4, Copy directory structure from PATCH_DIR/registry_2_0 into
   REGISTRY_AS_HOME overwriting existing files. You can skip "etc" and
   "lib" directories which have no counterpart in target location.
5, Copy directory structure from PATCH_DIR/deployed into
   REGISTRY_AS_HOME overwriting existing files.  Copy file
   PATCH_DIR/registry_2_0/dist/wsdl2uddi_client_v3.jar over
   REGISTRY_HOME/app/uddi/wsdl2uddi_client_v3.jar.
6, Delete REGISTRY_AS_HOME/work/uddi/services,
   REGISTRY_AS_HOME/work/system,
   REGISTRY_HOME/work/uddi/wsdl2uddi_client_v3.jar,
   REGISTRY_AS_HOME/work/uddi/bsc.jar, and
   REGISTRY_AS_HOME/work/uddi/web.jar files and directories if they
   exists. They will be recreated on next start.
7, Start the Registry again.

Note: if you have any custom modifications to some .jar files that are
also inside patch, you will have to reapply them for those .jar files.



C, Patch installer .jar file
----------------------------


Assumptions: You either have file commander that can enter .jar
archive and replace file inside or you know command-line jar tool.
The "patch" directory has not been modified by update installation
options A or B.

1, Make a backup of the installer .jar file.

2, Enter the installer .jar file and patch archive.

3, Overwrite all files in installer .jar with the content of the
   "patch" directory in update archive. Files and directories in patch
   should match structure of installer .jar. Namely "com" directory in
   installer .jar should be overwritten with "com" directory from
   patch and "registry_2_0" directory inside installer .jar should be
   overwritten with "registry_2_0" directory from patch. Skip
   "deployed" directory which has no counterpart in installer.

All new features and fixes provided by this update will be enabled in
Registries installed with the patched installer.

======================================================================