GT 4.1.0 Release Notes: for Java WS Core
Prev Part . GT 4.1.0: Java WS Core Next

GT 4.1.0 Release Notes: for Java WS Core

Table of Contents

1. Component Overview
2. Feature Summary
3. Changes Summary
4. Bug Fixes
5. Known Problems
6. Technology Dependencies
7. Tested Platforms
8. Backward Compatibility Summary
9. Associated Standards
10. For More Information

1. Component Overview

The Java WS Core is an implementation of the Web Services Resource Framework (WSRF) and the Web Service Notification (WSN) family of standards. It provides APIs and tools for building stateful Web services.

2. Feature Summary

New Features in the GT 4.1.0 release

  • Persistent HTTP/S connection support (client and server side)
  • Support for SOAP with Attachments (DIME, MIME, and MTOM formats). See the SOAP Attachements section for details.
  • Dynamic deployment support for the standalone container. See the Java WS Core Container Dynamic Deploy Design Document for more information.
  • JBOSS 4.0.x support
  • Updated 3rd party libraries

Other Supported Features

  • A standalone and embeddable container
  • Tomcat 4.1, 5.0, and 5.5 support
  • Basic API for resource persistence and recovery
  • Persistent subscriptions support
  • Automatic service and ResourceHome activation on startup
  • Operation providers

Deprecated Features

  • None

3. Changes Summary

The following changes have occurred for Java WS Core since the last stable release, 4.0.2:

3.1. New command line tools

  • The globus-validate-descriptors command line tool is used to validate the Web Services Deployment Descriptor (.wsdd) files, JNDI configuration files (jndi-config.xml), and security descriptors for all services.
  • The globus-check-environment command line tool is used to display component version information and to validate JVM version.

3.2. New common command line options

  • -t, --timeout option is used to configure the client-side timeout value.

3.3. 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.

3.4. 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.

3.5. 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.

3.6. 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 were 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 org.globus.wsrf.jndi.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 Beta.
  • Added init.d start/stop script for the standalone container. Please see Configuring for details.
  • A resource cache can now be configured with a size limit (in addition to a timeout).

3.7. Updated 3rd party libraries

  • Apache Xerces 2.7.1
  • OpenSAML 1.1
  • BouncyCastle 1.31
  • Apache Log4j 1.2.13
  • 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.

3.8. Axis changes

GT 4.1.0 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: 

    export GLOBUS_OPTIONS="-DBeanSerializer.errorOnNullWithNonNillableElement=false"

  • 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.

4. Bug Fixes

  • Bug 2926: Local transport does not work without a current MessageContext
  • Bug 4117: ReflectionResourceProperty throws Exception
  • Bug 4126: Wrong method invoked when Delegation Service is used
  • Bug 4204: WorkManagerImpl incorrectly implements the WorkManager.schedule(...) method
  • Bug 4209: globus-start-container-detached log and pid file selection
  • Bug 4324: ServiceContainer reports failed startup at incorrect severity
  • Bug 4325: Exceptions of type 'expectedType' could be more useful

5. Known Problems

The following problems and limitations are known to exist for Java WS Core at the time of the 4.1.0 release:

5.1. Limitations

  • WS-Notification support:

    • Only the Simple topic dialect is supported (others can be added)
    • Only flat topic spaces are supported (architecture does allow for more advanced structures)
    • Actions on the precondition, selector and policy fields in a subscription are not supported
    • When a resource is removed its subscriptions are not removed automatically
  • Only XPath resource property queries are supported (others can be added)
  • A resource might not get destroyed at the exact time as indicated by the scheduled termination time. A sweeper thread that removes expired resources runs periodically (every 1 minute by default) so an expired resource might not get removed until the next time the sweeper thread runs.

5.2. Known Bugs

  • Bug 2471: Message security signature verification issues
  • Bug 2445: Same input and output messages in WSDL confuse Axis
  • Bug 2921: Support for TerminationTimeChangeRejectedFault (will be fixed in GT 4.2)
  • Bug 3113: Processing by the WSDLPreprocessor produces output different depending on the JVM
  • Bug 3482: wsa:From is not set correctly when service calls another service
  • Bug 3483: xsd:anyType not serialized correctly
  • Bug 4227: QueryResourceProperites xpath dialect doesn't handle namespaces (will be fixed in GT 4.2)
  • Bug 4432: SimpleTopic.notify(SOAPElement element) drop child elements

6. Technology Dependencies

Java WS Core depends on the following GT components:

Java WS Core depends on the following 3rd party software:

Please see Java WS Core Technical Dependencies Details for details.

7. Tested Platforms

Java WS Core should work on any platform that supports J2SE 1.4.1 or higher.

Tested platforms for Java WS Core:

  • Linux (Debian 3.1)
  • Windows XP
  • Solaris 9

Tested JVMs for Java WS Core:

JVM notes:

  • GCJ is not supported.
  • If using IBM JVM 1.4.1 please see bug 2828 for more information.

Tested containers for Java WS Core:

  • Java WS Core container
  • Tomcat 4.1.31
  • Tomcat 5.0.30
  • Tomcat 5.5.15
  • JBoss 4.0.2

8. Backward Compatibility Summary

Protocol changes since GT version 4.0.2

  • No changes.

API changes since GT version 4.0.2

Schema changes since GT version 4.0.2

  • No changes.

Other changes since GT version 4.0.2

9. Associated Standards

Associated standards for Java WS Core:

10. For More Information

Please see Java WS Core for more information.

Prev Up Next
Part . GT 4.1.0: Java WS Core Home GT 4.1.0 Java WS Core : System Administrator's Guide