The following bugs in Service Registry 3.1 are related to compatibility.
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.
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.
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"/>
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.
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.
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:
In the directory /opt/sun/appserver/lib, create a subdirectory named endorsed.
Copy the file /opt/sun/javadb/lib/derby.jar into the directory /opt/sun/appserver/lib/endorsed.