Advisories for OGSA-DAI R4

The following advisories have been issued:

Exception in thread "main" java.lang.IllegalAccessError

The following error message will be logged:

Exception in thread "main" java.lang.IllegalAccessError: tried to access field
org.apache.xpath.compiler.FunctionTable.m_functions from class
org.apache.xml.security.Init at
org.globus.ogsa.impl.security.authentication.wssec.WSSecurityEngine.
(WSSecurityEngine.java:57).

This exception is probably caused by an incompatibility between the version of the xalan.jar shipped with the Globus Toolkit 3.2.x distribution and particular versions of the Java JDK. Some builds of Java version 1.4.2_05 and Java 1.5 are known to cause this error. Versions of the Java 1.4 JDK up to and including 1.4.2_04 are known to be okay.

Switching to an earlier Java version should solve this problem or you can use the Endorsed Standards Override Mechanism to install a newer version of Xalan. For more information on this bug take a look at the OGSA-DAI R6 User Documentation FAQ.

Previously working Client Toolkit applications fail with a perform document validation error

The following error message will be logged:

Unexpected DAIException: uk.org.ogsadai.client.toolkit.RequestException
The perform document does not validate against the expected XML schema.

If you have the source version of the release, you can correct this bug by changing the following method in the UniqueName.java file and rebuilding ogsadai.jar:

  • old version:
    /**
      * Returns a unique name based on a Hex timestamp seed
      * @return String
      */
    public synchronized String getName()
    {
        mCurrentName++;
        return Long.toHexString(mCurrentName);
    }
    
  • new version:
    /**
      * Returns a unique name based on a Hex timestamp seed, of the form
      * ogsadai-100033ad2a7.
      *
      * @return String
      */
    public synchronized String getName()
    {
        mCurrentName++;
        return \"ogsadai-\"+Long.toHexString(mCurrentName);
    }
    

We will be releasing a patch for binary releases soon, and this bug is corrected in Release 5.

The zipArchiveActivity fails when the STORED archiving method is used

The DEFLATED method should be used instead. In the next release of OGSA-DAI the zipArchiveActivity will only allow the DEFLATED method to be used.

Getting GridFTP to work

These instructions supplement those already available in existing documentation but they help clarify and provide additional information.

The main information is contained in:
http://www.ogsadai.org.uk/docs/R4.0/doc/clients/SecureEndToEndClient.html

Additional points to note in reference to the above link:

  • Steps 1 to 3 tell you how to construct a proxy certificate if one is not already available
  • Step 4 ensures that you have the client-config.wsdd file in your classpath or in the directory from which you run the client. It appears that the classpath approach does not work so you should ensure this file is in the directory from which you run the client.
  • In step 6 you need to include the -factory flag before the GDSF-GSH otherwise it will try to talk to the factory as a registry. So the line should be:
    java uk.org.ogsadai.client.Client -mls -factory <GDSF-GSH> <GDS-PERFORM>
    
  • In step 6 include the -demo flag, e.g.
    java uk.org.ogsadai.client.Client -demo -mls -factory <GDSF-GSH> <GDS-PERFORM>
    
    This pauses the program at various stages. The most important aspect of this is that it will pause before destroying the GDS. This is needed as a perform document that sends the output to GridFTP will be executed asynchronously so you need to give it time to finish before destroying the service.
  • The version of this client shipped with GT4 is incompatible with version 3.2.1 of the Globus Toolkit. This is because the client uses the following security options:
    authorization: none
    delegation: limited
    

    This 'authorization' parameter specifies which servers the client is allowed to talk to. None says it can talk to any server without checking the validity of that server. The other possible options for this parameter are 'host' and 'self'. With 'host' the host must have a certificate that correspond to the name of the server in the URL (e.g. myservice.mydomain.ac.uk). If the value is 'self' then the client will only talk to servers running with the same user certificate as the client (an uncommon situation in practice but sometimes useful when testing).

    Globus made a security change which states that you cannot use delegation unless you use self or host authorization. Thus the client needs to be changed to specific one of these authorizations. We have built a new version of the client that uses host authorization by default and self authorization if '-self' is specified on the command line.

  • This version is available in a new version of the ogsadai.jar.
  • If you are not using our client but instead using your own you should set the stub using code like:
    ((Stub) griddataservice)._setProperty( Constants.GSI_SEC_CONV,
    Constants.SIGNATURE );
    
    ((Stub) griddataservice)._setProperty( GSIConstants.GSI_MODE,
    GSIConstants.GSI_MODE_LIMITED_DELEG );
    
    ((Stub) griddataservice)._setProperty( Constants.AUTHORIZATION,
    SelfAuthorization.getInstance());
    
    ((Stub) griddataservice)._setProperty(GSIConstants.GSI_CREDENTIALS, cred );
    
  • An example to a GridFTP perform document us included here. You simply need to change the host, port and destination file parameters. We know there are a lot more parameters that you can set when using GridFTP to transfer a file, e.g. buffer size, number of streams etc.

News