GT 4.2.1 Release Notes

Table of Contents

1. Introduction
2. Obtaining and Installing Software
3. Documentation
4. Support
5. Licensing
6. Usage Statistics
7. Summary of Changes Since 4.0.x
7.1. Common Runtime Components
7.1.1. Summary of Changes in Java WS Core Specification upgrade New command line tools New common command line options Standalone container changes GAR deployment/undeployment changes Simpler local invocation Other changes Updated 3rd party libraries Axis changes
7.1.2. Summary of Changes in C WS Core
7.1.3. Summary of Changes in XIO
7.1.4. Summary of Changes in C Common Libraries
7.1.5. Summary of Changes in CoG jGlobus
7.1.6. Changes Summary
7.2. Security
7.2.1. Summary of Changes in GSI
7.2.2. Summary of Changes in the Delegation Service
7.2.3. Summary of Changes in MyProxy
7.2.4. Summary of Changes in SimpleCA
7.2.5. Summary of Changes in GSI-OpenSSH
7.3. Data Management
7.3.1. Summary of Changes in RFT
7.3.2. Summary of Changes in GridFTP
7.3.3. Summary of Changes in RLS
7.3.4. Summary of Changes in WS RLS
7.3.5. Summary of Changes in Batch Replicator
7.3.6. Summary of Changes in Replication Client
7.4. Information Services
7.4.1. Summary of Changes in WS MDS Index Service
7.4.2. Summary of Changes in WS MDS Trigger Service
7.4.3. Summary of Changes in WS MDS Aggregator Framework
7.4.4. Summary of Changes in WebMDS
7.4.5. Summary of Changes in UsefulRP
7.5. Execution Management
7.5.1. Summary of Changes in GRAM4
7.5.2. Summary of Changes in GRAM2
7.5.3. Summary of Changes in GridWay
8. Release Notes by Component

1. Introduction

The GT development team is pleased to make its newest major release available for download.

Highlights of this release include:

  • Persistent HTTP/S connection support in Java WS Core
  • Dynamic deployment support in Java WS Core
  • JBOSS 4.0.x support in Java WS Core
  • An implementation of WS-ServiceGroup added to C WS Core
  • C command-line tools for WSRF operations
  • Support for GetResourceProperties and QueryResourceProperties in the Delegation Service
  • Added support for the OGSA-AuthZ Authorization Service to CAS
  • Server-side attribute-based authorization framework enhancements
  • Support for a pluggable Policy Decision Point (PDP) designed to minimize common authorization errors
  • Enhanced security descriptor framework
  • A Web service interface for the Replica Location Service (RLS)
  • Improved support for multiple TriggerRules in the Trigger Service
  • Improved configuration interface for the Trigger Service
  • Java API to assist in creating resource properties from external information sources
  • A new resource manager (RM) adapter API in GRAM4

GT4.2.1 contains an upgrade to the web services specifications used by the toolkit as well as new features in all services. New users are encouraged to use the 4.2.1 release. However, because of the specification upgrade the webservices are incompatible with the 4.0.x series. Existing 4.0.7 users may wish to evaluate the new software while maintaining their existing installations. Details on the spec upgrade are available in the Changes Summary below.

2. Obtaining and Installing Software

To download this release, go to the 4.2.1 Download page.

For information on installing this release, go to the 4.2.1 Installation Guide.

3. Documentation

Use the documentation which starts at here.


This release includes name changes:

  • WS GRAM is now referred to as GRAM4 and Pre-WS GRAM is now referred to as GRAM2.

  • Pre-WS Authentication and Authorization is now referred to as GSI C.

  • CoG jGlobus is referred to as GSI Java (please note we are still working on more complete documentation for GSI Java; in the meantime, you can use the documentation under CoG jglobus.)

As we continue to evolve the GT documentation, we've added new features as of 4.2.0:

  • Starting with 4.2.0, GT will start release documentation for each point release.

  • Left sidebar on all pages allows you to access documentation for all technologies from any page.

  • Customized TOCs at the top, domain and technology level.

  • Each guide is its own book with its own url. For example, you can find the GridFTP Admin Guide at

  • More PDFs are available - both at the technology-level and guide-level.

  • Introducing the top-level GT Developer's Guide and GT User's Guide.

  • Adding more indices. This will be improved with each point release.

Feel free to offer any suggestions or feedback using Bugzilla (the "Documentation" component). Or use the documentation feedback box at the bottom of each page (please note that this box is intended for feedback and suggestions, but not support - support information follows.)

4. Support

An overview on GT support can be found here.

5. Licensing

The Globus Toolkit is distributed and licensed for use under the terms of the Apache License, Version 2.0.

To view the licenses of the 3rd party software used by the developers of the Globus Toolkit, click here.

6. Usage Statistics

For full information about usage statistics collected by GT 4.2.1 and how to opt-out, see Usage Statistics Collection by the Globus Alliance.

7. Summary of Changes Since 4.0.x

7.1. Common Runtime Components

7.1.1. Summary of Changes in Java WS Core Specification upgrade
  • Support for WS Addressing version 1.0
  • Support for Web Services Resource Framework version 1.2
  • Support for Web Services Notification version 1.3

A migration guide for porting services to the new specification is available here. New command line tools New common command line options
  • -t, --timeout option is used to configure the client-side timeout value. Standalone container changes
  • A new -i command line option was added to globus-start-container to force the container to bind to the specified network address.
  • globus-start-container now performs a JVM version check to ensure that at least Java 1.4 JVM is used to start the container.
  • The OutOfMemoryError error handling was improved in the standalone container. All ResourceHome caches will now be automatically cleared on OutOfMemoryError error.
  • SOAP requests containing attachments will now be handled correctly by the container.
  • The globus-start-container-detached, and globus-stop-container-detached tools now support options for specifying alternative log and pid file locations.
  • Adjusted the number of threads used by the container in standalone and embedded mode. By default the container in standalone mode will now have a minimum of 2 threads and a maximum of 20. The container in embedded mode will now have a minimum of 1 thread and maximum of 3 threads. GAR deployment/undeployment changes
  • globus-deploy-gar will NOT overwrite the existing GAR deployment by default now. The existing deployment must be undeployed first or the GAR must be deployed with -overwrite option.
  • During GAR deployment the service configuration files such as .wsdd files, jndi-config.xml file, and security deployment descriptors will now be automatically validated.
  • Client-side type mapping will now be properly removed during GAR undeployment.
  • Both GAR deployment and undeployment operations now explicitly check if the container is currently running. If so, the operation is aborted. The container must be off before deploying or undeploying GAR files.
  • globus-deploy-gar and globus-undeploy-gar tools can now deploy or undeploy a GAR file directly from Apache Tomcat with the -tomcat option.
  • The command line syntax of the globus-deploy-gar and globus-undeploy-gar tools has changed. The tools now expect the options first followed by the required arguments. Simpler local invocation
  • It is now easier to make local invocations. Axis' MessageContext does not need to be associated with the current thread anymore and the stub does not need to be configured in any way to make local invocations. Other changes
  • A new MessageContextHelper API were added to help in associating an arbitrary MessageContext object with the current thread of execution.
  • A new EPRResourceContext API was added to help obtaining ResourceKey, ResourceHome, or the resource object associated with a given WS-Addressing endpoint.
  • GLOBUS_TCP_SOURCE_PORT_RANGE environment property is now supported.
  • The test framework was extended to allow for execution of a specific test suite or a specific set of test cases within a test suite (Bug 3668).
  • A new Version API were added to obtain Java WS Core version information programmatically.
  • A new JNDIUtils.getInitialContext() method was added to obtain the right JNDI registry. This is now the preferred way of getting the InitialContext as it will work correctly on any application server with other JNDI implementations present.
  • Added support for Sun Java SE 6 RC.
  • Added init.d start/stop script for the standalone container. Please see the Configuring Java WS Core for details.
  • A resource cache can now be configured with a size limit (in addition to a timeout).
  • A persistent resource object (when used with ResourceHomeImpl) can now have a private or protected no-argument constructor.
  • The factory parameter for simple Java Bean resources declared in the jndi-config.xml files is now optional. By default, the factory class will be used if the factory resource parameter is not specified.
  • A launch script for the myproxy Java command line tool will now be created on Windows.
  • Added error codes to all error messages generated by Java WS Core.
  • The setTerminationTime() function can now throw a TerminationTimeRejectedException if the new termination time cannot be accepted by the service.
  • Changed the timestamp format of the container log file to ISO 8601 complaint format. The new format has the following syntax: YYYY-MM-DDThh:mm:ss,sss[+-]hh:mm. It uses local time with UTC time zone offset. Updated 3rd party libraries
  • CoG JGlobus (see the CoG JGlobus Release Notes for more details)
  • Apache Xerces 2.7.1
  • OpenSAML 1.1
  • BouncyCastle 1.31
  • Apache Log4j 1.2.15
  • Apache Commons Logging 1.1
  • Apache Commons CLI 2.0 (latest snapshot)
  • Switched to JNDI Naming library from the Apache Directory Project.
  • Post 1.4 version of Apache Axis. Please see Axis changes for details.
  • Apache Commons Collection 3.2
  • Apache Addressing Library has been imported into Globus CVS and a modified version of the library that support only WS Addressing 1.0 namespace has been added to the toolkit. The package names have been modified to avoid any conflicts and the toolkit does not ship with Apache Addressing library. Axis changes

GT 4.2.1 release contains a newer version of Apache Axis. The following changes have been noted in Axis:

  • xsd:group handling has changed. A Java Bean will NOT be generated now for a xsd:group type. See AXIS-1525 for more details.
  • The ordering of the parameters of the constructors of the generated Java Beans has changed once again. It is recommended to avoid the full constructors of the generated Java Beans. Use individual setter functions to set the values of the Bean instead.
  • An error will now be raised by BeanSerializer when serializing a null value that is not optional or non-nillable. This behavior can be disabled by setting BeanSerializer.errorOnNullWithNonNillableElement system property to false. Example:

  • WSDL2Java will not generate Java Beans for certain array objects. The -w option must be passed to WSDL2Java to force it to generate the Java Beans for such types. This change is transparent to the users of the build scripts provided by Java WS Core.
  • MTOM attachments are now supported.

7.1.2. Summary of Changes in C WS Core

Other than bugfixes, no changes have occurred for C WS Core since the last stable release, 4.0.x.

7.1.3. Summary of Changes in XIO

The only significant change to Globus XIO in this release is the addition of "string attributes". The previous method of handling attributes still works in an entirely backward compatible way, but the string attributes adds a much needed convenience. Drivers can now provide a list of key=value pairs. A user can then specify these options at the command line and at runtime. This makes run time configuration much more flexible.

A driver can choose to expose parameters in a string form. This feature makes dynamically setting driver-specific options much easier. A user can then load the driver by name and set specific options by name all at runtime with no object module references. For example, a TCP driver can be loaded with the string tcp and the options can be set with the string port=50668;keepalive=yes;nodelay=N.

This would set the port to 50668, keepalive to true and nodelay to false. The particular string definition is defined by the TCP driver. This is done by creating a globus_i_xio_attr_parse_table_t array within the driver's source code. See the TCP driver source code for an example. Each row of the array is 1 option. There are 3 sub-members of each row entry: key, cmd, and parse function. The key is a string that defines what option is to be set. In the above example, string port would be a key. cmd tells the driver what cntl is associated with the key. In other words, once the string is parsed out it converts the key into a driver-specific control enum. XIO then uses that enum as it would if a driver-specific option was set in the source code. For more information on controls, see globus_xio_attr_cntl.

7.1.4. Summary of Changes in C Common Libraries

No significant changes have happened for C Common Libraries since GT 4.0.x. See Feature Summary for some minor changes.

7.1.5. Summary of Changes in CoG jGlobus

No new changes have been made since last stable release, 4.0.x

7.1.6. Changes Summary

The addition of the XioSocket API; this is almost interchangable with the Python socket API and it uses XIO drivers to provide transport/GSI authentication.

7.2. Security

7.2.1. Summary of Changes in GSI


7.2.2. Summary of Changes in the Delegation Service

No changed have been made since last stable release, 4.0.x.

7.2.3. Summary of Changes in MyProxy

No changes have occurred for MyProxy since the last stable release, 4.0.x.

7.2.4. Summary of Changes in SimpleCA

Other than bugfixes, no changes have occurred for SimpleCA since the last stable release, 4.0.x.

7.2.5. Summary of Changes in GSI-OpenSSH

7.3. Data Management

7.3.1. Summary of Changes in RFT

  • New in RFT 4.2 is a connection caching feature. This allows internal GridFTP connections to be internally cached globally across all service requests. This has shown to be a vast performance increase in the case where a single user wishes to transfer many URLs, but instead of transferring them in a single request, they put each URL in a separate request. Caching helps this case specifically, and is a general optimization for other cases.
  • The backoff algorithm has been modified. To start with, all errors in communicating with GridFTP servers are considered transient. In the past we considered authorization failures and DNS lookup failures, as well as other similar things, as fatal. We have since recognized that even those shall pass, and in some environments those should be expected as a means of controlling load.
  • Additionally, how we back off is different. If a failure is detected, we do not try to communicate with the given GridFTP server for a specified amount of time, or until some other transfer completes successfully with that server. This allows for optimal use of GridFTP servers that only allow a fixed number of connections at once, and it helps make optimal use of our connection cache.

7.3.2. Summary of Changes in GridFTP

  • Added GFork master plugin to allow dynamic backend configuration.
  • Added -pp option to globus-url-copy to allow pipelining of data transfers (ie, several transfers can be processed without waiting for each transfer to finish before starting the next one.)
  • The GridFTP Admin Guide has been updated to include more information on advanced configuration, configuring security and tuning/performance recommendations.

7.3.3. Summary of Changes in RLS

  • An embedded database (using SQLite) and ODBC libraries are now included in the RLS Server installation. A default installation of GT will include a fully configured RLS Server that requires no database installation or configuration by the end user. Advanced users can still use their own database without changes.
  • The RLS now includes a new Java client API written entirely in Java. It does not require the C client libraries and allows for Java client support on 64-bit platforms. The new API is fully backwards compatible. Users need not make any changes to existing code to take advantage of the new library.
  • The RLS Admin Guide has been completely rewritten to account for the embedded database support and to streamline the installation procedures. In addition, a large help section has been added based on an analysis of ODBC and database installation procedures and their compatibility with the RLS.
  • Client tools support for bulk operations has been improved. The globus-rls-cli can now read input parameters from a file, and a new script also simplifies repetitive procedures involving bulk operations.
  • Bug fixes up through the GT 4.0.6 release are also included in this release.

7.3.4. Summary of Changes in WS RLS

WS RLS has been updated to conform to the Java spec upgrade (bug 5495) and Security restructuring (bug 5559) for Java WS Core.

7.3.5. Summary of Changes in Batch Replicator

The Batch Replicator has been updated to conform to the Java spec upgrade (bug 5495) and Security restructuring (bug 5559) for Java WS Core.

7.3.6. Summary of Changes in Replication Client

Narrative description of changes (summarize what was done and why).

7.4. Information Services

A new MDS Admin Guide has been created that describes configuring MDS as a whole.

7.4.1. Summary of Changes in WS MDS Index Service

Loop detection (preventing an index server from registering to itself, or two from registering to each other) has been improved somewhat since 4.0.x.

7.4.2. Summary of Changes in WS MDS Trigger Service

New Features:

  • Multiple triggers per data source aggregation is now supported. Each trigger's Matching Rule will be evaluated against the incoming message.
  • Support for XML Namespace resolution in the Matching Rule Xpath statement. This allows namespace prefixes to be specified in the TriggerRule XPath matching rule string parameter.


  • Triggers are now created/configured in a completely different manner from previous versions. They are created dynamically, as needed.
  • Some parameter names have been changed, added, or removed.

7.4.3. Summary of Changes in WS MDS Aggregator Framework

  • The mds-servicegroup-add command no longer requires the dummy -s or -e arguments

  • The mds-set-multiple-termination-time command has been added to aid in management of service group entry resources created via mds-servicegroup-add

  • The QueryAggregatorSource and SubscriptionAggregatorSource now attempt to detect when the data source EPR is local to the current container instance and, if so, set the connection properties to use local transport.

  • Added a service level configuration option for suppressing the publication of aggregator configuration elements in aggregator service group registry entries. In other words, the Service Group Entry Content Resource Property will contain only the aggregated data.

  • Due to changes in the final version of the WS-ServiceGroup specification, the XML structure of a ServiceGroupEntry's Content Resource Property is no longer directly mapped to the AggregatorContent type. Instead, the AggregatorContent type is now represented as a child element of the WS-SG Content element.

7.4.4. Summary of Changes in WebMDS

  • Error handling has improved -- error pages now include a summary and not just a Java stack trace.
  • The service group summary view now has an option to periodically refresh the display.
  • WebMDS now supports optional user-specified Xpath queries.
  • WebMDS now supports the use of user-specified namespace mappings with user-specified Xpath queries.
  • Entries in the service group summary view are now sorted.
  • The service group summary view is now easier to update to support local data types.

7.4.5. Summary of Changes in UsefulRP

The RPProvider configuration file format has changed slighty. The ResourcePropertyProviderConfigArray structure contains an array of xml elements of the type resourcePropertyProviderConfig. In 4.0.x, the element name for each array item was "configArray"; in 4.2.x, the name has been changed to "resourcePropertyProviderConfiguration".

Structurally, the ResourcePropertyProviderConfigArray and its child elements have not been modified in any other way. Therefore, a search and replace for all instances of "configArray" with "resourcePropertyProviderConfiguration" should be all that is necessary to make 4.0.x RPProvider configuration files compatible with 4.2.x versions.

7.5. Execution Management

7.5.1. Summary of Changes in GRAM4

There are significant enhancements in this release to improve reliabilty of GRAM4 audit logging. Database errors are handled better. If the audit database is unavailable, job records are written to local disk and later inserted. In addition, there are a number of other bug fixes.

7.5.2. Summary of Changes in GRAM2

Only minor changes and bugfixes have occurred for GRAM2 since the last stable release.

7.5.3. Summary of Changes in GridWay

GridWay version shipped with GT4.2.1 is based on GridWay 5.4, a new stable version with increased functionality, including support to access the NorduGrid infrastructure, new bindings for DRMAA and support for DAGMAN workflows.

New to 4.2.1:

Integration with major Grid Infrastructures

Following the trend from previous releases, GridWay is capable of integrate with another major infrastructure: NorduGrid. Drivers for Execution and Transfer are included in this release.

New DRMAA bindings for scripting languages

Previous GridWay releases come with support for C and Java bindings implementing the DRMAA standard. Scripting languages are interesting from the point of view of rapid application prototyping among others. From we believe this to be an interesting aspect, and that is why GridWay includes bindings to access the DRMAA standard from scripting languages such as Perl, Ruby and Python.

Support for DAGMAN workflows

There is an increasing interest from the scientific community to be able to run complex workflows on a Grid environment. An almost de-facto standard to represent DAG workflows is Condor DAGMAN. In this development release GridWay includes a new workflow launcher (gwdag) that handles this kind of workflows.