Service Registry 3.1 Release Notes

Compatibility Issues

This section describes the following issues related to compatibility:

Features Nearing End of Life

User Registration Mechanism

This release of Service Registry relies on its own user management and authentication mechanism. The plan is to update the Registry at a future release to a SAML-based mechanism (as specified in the ebXML Registry standard, of which this component is an implementation).

Bugs Related to Compatibility

The following bugs in Service Registry 3.1 are related to compatibility.

6422192: `NullPointerException` When Using Service Registry 3.1 Admin Tool with Service Registry 3.0

Problem Summary: If you use the Service Registry 3.1 Admin Tool with a deployed Service Registry 3.0, commands such as cp and rm result in a NullPointerException.

Workaround: Use the Service Registry 3.1 Admin Tool only with Service Registry 3.1, and use the Service Registry 3.0 Admin Tool with Service Registry 3.0.

6463868: Client Program or Server That Uses JDK 1.6 Results in Errors

Problem Summary: If a JAXR client program runs in a JDK 1.6 environment, or if Service Registry is deployed on a system that is running JDK 1.6, runtime errors result when the program performs a query or publish operation. The underlying problem is that JDK 1.6 uses version 1.3 of the SOAP with Attachments API for Java (SAAJ), while Application Server uses version 1.2.

Workaround: There are two types of workarounds required, one for the client system and one for the server.

If the client is running JDK 1.6 and the server is running JDK 1.5, follow the steps in To Perform the Client System Workaround.
If the client is running JDK 1.5 and the server is running JDK 1.6, follow the steps in To Perform the Server System Workaround.
If both the client and server are running JDK 1.6, follow the steps for both workarounds.

To Perform the Client System Workaround

The client system workaround is required if the client system is running JDK 1.6. This workaround involves the following tasks:

Adding the SAAJ 1.3 JAR files to the classpath if they are not already present
Setting four system properties in the Ant build file for the client program

Make sure that your classpath includes the following JAR files:

On Solaris OS:

/usr/share/lib/saaj-api.jar
/usr/share/lib/saaj-impl.jar

On Linux and HP-UX systems:

/opt/sun/share/lib/saaj-api.jar
/opt/sun/share/lib/saaj-impl.jar

For example, if your Ant targets for a Linux system include a setting like the following, your classpath is correct:

<path id="classpath">
  <fileset dir="/opt/sun/share/lib">
    <include name="*.jar"/>
  </fileset>
  ...
</path>

Add the following <sysproperty> tags to the <java> targets in your build.xml files:

<sysproperty key="javax.xml.soap.MessageFactory" 
   value="com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl"/>
<sysproperty key="javax.xml.soap.MetaFactory" 
   value="com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl"/>
<sysproperty key="javax.xml.soap.SOAPConnectionFactory" 
   value="com.sun.xml.messaging.saaj.client.p2p.HttpSOAPConnectionFactory"/>
<sysproperty key="javax.xml.soap.SOAPFactory" 
   value="com.sun.xml.messaging.saaj.soap.ver1_1.SOAPFactory1_1Impl"/>

To Perform the Server System Workaround

The server system workaround involves the following tasks:

Putting the SAAJ 1.3 JAR files in the Application Server lib directory
Adding two JVM options to set system properties
Stopping and restarting Application Server

Change to the Application Server lib directory.

On Solaris OS: cd /opt/SUNWappserver/appserver/lib

On Linux and HP-UX systems: cd /opt/sun/appserver/lib

Make backup copies of the two SAAJ JAR files in the Application Server lib directory. For example:
cp saaj-api.jar saaj-api.jar.v1.2 cp saaj-impl.jar saaj-impl.jar.v1.2

Copy the SAAJ 1.3 JAR files to the Application Server lib directory.

On Solaris OS:

cp /usr/share/lib/saaj-api.jar .
cp /usr/share/lib/saaj-impl.jar .

On Linux and HP-UX systems:

cp /opt/sun/share/lib/saaj-api.jar .
cp /opt/sun/share/lib/saaj-impl.jar .

Log in to the Application Server Admin Console as described in To Use the Application Server Admin Console in Service Registry 3.1 Administration Guide.

Expand the Configurations node.

Expand the server node, server-config (Admin Config).

Click JVM Settings.

Click the JVM Options tab.

Click Add JVM Option.

In the text field, type the following:

-Djavax.xml.soap.MessageFactory=com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl

Click Add JVM Option again.

In the text field, type the following:

-Djavax.xml.soap.MetaFactory=com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl

Click Save.

Follow the instructions in To Stop and Restart the Application Server Domain for the Registry in Service Registry 3.1 Administration Guide.

6475651: Java ES 2005Q4 Service Registry Login Fails After Application Server Upgrade

Problem Summary: If you installed and used the previous version of Service Registry (from Java ES 2005Q4), and you now upgrade to the Java ES 5 version of Application Server but do not upgrade to the Java ES 5 version of Service Registry, a login failure occurs if you try to use the same certificate you previously created with the Web Console.

Workaround: Edit the web.xml file and the security policy file for Service Registry.

To stop the Application Server domain for the Registry and edit the web.xml file, follow these steps:

Change to the Service Registry install directory:

On Solaris OS: cd /opt/SUNWsoar/install

On Linux and HP-UX systems: cd /opt/sun/SUNWsoar/install
Stop the Application Server domain for the Registry:

Ant-base/ant -f build-install.xml appserver.domain.stop
Change to the directory RegistryDomain-base/domains/registry/applications/j2ee-modules/soar/WEB-INF/.
Open the file web.xml in a text editor.
Inside the <security-constraint> tag, after the </web-resource-collection> tag, insert the following:
```
<auth-constraint>
  <role-name>have.client.cert</role-name>
</auth-constraint>
```

After the </security-constraints> tag, insert the following:

<error-page>
  <error-code>400</error-code>
  <location>/registry/thin/AuthenticateError.jsp</location>
</error-page>
<security-role>
  <description>all subjects who have client certificates</description>
  <role-name>have.client.cert</role-name>
</security-role>

Save and close the web.xml file.

To edit the security policy file and restart the domain, follow these steps:

Change to the following directory:

On Solaris OS: cd /var/opt/SUNWsoar/domains/registry/config

On Linux and HP-UX systems: cd /var/opt/sun/SUNWsoar/domains/registry/config
Open the file server.policy in a text editor.

Add the following grants to this file:

grant codeBase "file:${com.sun.aas.instanceRoot}/applications/j2ee-modules/soar/WEB-INF/lib/-"{
       permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

grant codeBase "file:${com.sun.aas.instanceRoot}/generated/jsp/j2ee-modules/soar/-" {
      permission java.lang.reflect.ReflectPermission "suppressAccessChecks";
};

Save and close the server.policy file.
Restart the Application Server domain for the Registry:

Ant-base/ant -f build-install.xml appserver.domain.start
Open your web browser to the URL http://localhost:6060/soar. You should now be able to log in and publish.

6491246: Upgrade Fails on HP-UX Platform

Problem Summary: If you installed and used the previous version of Service Registry (from Java ES 2005Q4) on an HP-UX system, and you now upgrade to the Java ES 5 version of Service Registry, the installation fails with an error message stating that the problem is with HADB (High Availability Database). The problem is that the HADB packages were installed in what the Java ES 5 installer sees as a non-default location.

The problem also occurs if you uninstall the Java ES 2005Q4 version of Application Server and then install the Java ES 5 versions of Service Registry and Application Server.

Workaround: If you uninstalled Application Server, you must remove the sun-hadb packages before you reinstall.

If you are upgrading directly from the Java ES 2005Q4 version of Service Registry to the Java ES 5 version, the steps are more complicated:

Remove the sun-hadb packages.
Install the Java ES 5 versions of Service Registry and Application Server.

Edit the file /opt/sun/appserver/config/asenv.conf as follows:

Change the line

AS_ANT="/opt/sun/share/lib/ant/bin"

AS_ANT="/opt/sun/bin"