Cette rubrique décrit les problèmes suivants liés à la compatibilité :
Cette version de Service Registry met en œuvre son propre mécanisme d'authentification et de gestion des utilisateurs. Cela consiste à mettre à jour Registry dans une version ultérieure en un mécanisme SAML (tel que spécifié dans ebXML Registry standard dont ce composant est une implémentation).
Les bogues suivants dans Service Registry 3.1 sont liés à la compatibilité.
Problème : Si vous utilisez l'outil d'administration de Service Registry 3.1 avec Service Registry 3.0 déployé, des commandes telles que cp et rm entraînent une NullPointerException.
Solution : Utilisez l'outil d'administration de Service Registry 3.1 avec Service Registry 3.1 uniquement, et utilisez l'outil d'administration de Service Registry 3.0 avec Service Registry 3.0.
Problème : Si un programme client JAXR est exécuté dans un environnement JDK 1.6 ou si Service Registry est déployé sur un système exécutant JDK 1.6, des erreurs d'exécution surviennent lorsque le programme exécute un requête ou une opération de publication. Le problème sous-jacent est tel que JDK 1.6 utilise la version 1.3 de SOAP with Attachments API for Java (SAAJ) alors que Application Server utilise la version 1.2.
Solution : Il existe deux types de solutions requises : une pour le système client et une pour le serveur.
Si le client exécute JDK 1.6 et que le serveur exécute JDK 1.5, suivez les étapes de la rubrique Pour appliquer la solution du système client.
Si le client exécute JDK 1.5 et que le serveur exécute JDK 1.6, suivez les étapes de la rubrique Pour appliquer la solution du serveur.
Si le client et le serveur exécutent JDK 1.6, suivez les étapes des deux rubriques.
La solution du système client est requise si le système client exécute JDK 1.6. Cette solution implique les tâches suivantes :
Ajout des fichiers JAR SAAJ 1.3 au chemin de classe s'ils n'existent pas
Configuration de quatre propriétés système dans le fichier de version Ant du programme client
Veillez à ce que le chemin de classe comprenne les fichiers JAR suivants :
Sous SE Solaris :
/usr/share/lib/saaj-api.jar /usr/share/lib/saaj-impl.jar
Sous Linux et HP-UX :
/opt/sun/share/lib/saaj-api.jar /opt/sun/share/lib/saaj-impl.jar
Par exemple, le chemin de classe est correct si les cibles Ant d'un système Linux comprennent un paramètre similaire au suivant :
<path id="classpath"> <fileset dir="/opt/sun/share/lib"> <include name="*.jar"/> </fileset> ... </path>
Ajoutez les onglets <sysproperty> suivants aux cibles <java> des fichiers build.xml :
<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"/>
La solution du serveur implique les tâches suivantes :
Placement des fichiers JAR SAAJ 1.3 dans le répertoire lib d'Application Server
Ajout de deux options JVM pour définir des propriétés système
Arrêt et redémarrage d'Application Server
Accédez au répertoire lib d'Application Server.
Sous SE Solaris : cd /opt/SUNWappserver/appserver/lib
Sous Linux et HP-UX : cd /opt/sun/appserver/lib
Effectuez des copies de sauvegarde des deux fichiers JAR SAAJ dans le répertoire lib d'Application Server. Exemple :
cp saaj-api.jar saaj-api.jar.v1.2 cp saaj-impl.jar saaj-impl.jar.v1.2 |
Copiez les fichiers JAR SAAJ 1.3 dans le répertoire lib d'Application Server.
Sous SE Solaris :
cp /usr/share/lib/saaj-api.jar . cp /usr/share/lib/saaj-impl.jar . |
Sous Linux et HP-UX :
cp /opt/sun/share/lib/saaj-api.jar . cp /opt/sun/share/lib/saaj-impl.jar . |
Connectez-vous à la console d'administration d'Application Server tel que décrit dans la rubrique To Use the Application Server Admin Console du Service Registry 3.1 Administration Guide.
Développez le nœud Configurations.
Développez le nœud du serveur, server-config (Admin Config).
Cliquez sur Paramètres JVM.
Cliquez sur l'onglet Options JVM.
Cliquez sur Ajouter une option JVM.
Dans la zone de texte, saisissez comme suit :
-Djavax.xml.soap.MessageFactory=com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl |
Cliquez de nouveau sur Ajouter une option JVM.
Dans la zone de texte, saisissez comme suit :
-Djavax.xml.soap.MetaFactory=com.sun.xml.messaging.saaj.soap.SAAJMetaFactoryImpl |
Cliquez sur Enregistrer.
Suivez les instructions de la rubrique To Stop and Restart the Application Server Domain for the Registry du Service Registry 3.1 Administration Guide.
Problème : Si vous avez installé et utilisé la version précédente de Service Registry (à partir de Java ES 2005Q4) et que vous mettez maintenant votre système à niveau vers la version Java ES 5 d'Application Server sans passer à la version Java ES 5 de Service Registry, une erreur de connexion se produit lorsque vous essayez d'utiliser le certificat que vous avez précédemment créé dans la console Web.
Solution : Modifiez le fichier web.xml et le fichier de stratégies de sécurité de Service Registry.
Pour arrêter le domaine Application Server de Registry et modifier le fichier web.xml, suivez les étapes suivantes :
Accédez au répertoire d'installation de Service Registry :
Sous SE Solaris : cd /opt/SUNWsoar/install
Sous Linux et HP-UX : cd /opt/sun/SUNWsoar/install
Arrêtez le domaine Application Server de Registry :
Ant-base/ant -f build-install.xml appserver.domain.stop
Accédez au répertoire RegistryDomain-base /domains/registry/applications/j2ee-modules/soar/WEB-INF/ .
Ouvrez le fichier web.xml dans un éditeur de texte.
Dans l'onglet <security-constraint>, après l'onglet </web-resource-collection>, insérez comme suit :
<auth-constraint> <role-name>have.client.cert</role-name> </auth-constraint>
Après l'onglet </security-constraints>, insérez comme suit :
<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>
Enregistrez et fermez le fichier web.xml.
Pour modifier le fichier de stratégies de sécurité et redémarrer le domaine, suivez les étapes suivantes :
Accédez au répertoire suivant :
Solaris : cd /var/opt/SUNWsoar/domains/registry/config
Sous Linux et HP-UX : cd /var/opt/sun/SUNWsoar/domains/registry/config
Ouvrez le fichier server.policy dans un éditeur de texte.
Ajoutez les autorisations suivantes au fichier :
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"; };
Enregistrez et fermez le fichier server.policy.
Redémarrez le domaine Application Server de Registry :
Ant-base/ant -f build-install.xml appserver.domain.start
Ouvrez votre navigateur Web et accédez à l'URL http://localhost:6060/soar . Vous devez désormais pouvoir vous connecter et publier.
Problème : Si vous avez installé et utilisé la version précedente de Service Registry (à partir de Java ES 2005Q4) sur un système HP-UX et que vous mettez maintenant votre système à niveau vers la version Java ES 5 de Service Registry, l'installation échoue et un message d'erreur indiquant que le problème se situe au niveau de la base de données haute disponibilité (HADB) s'affiche. Le problème tient au fait que les packages HADB ont été installés dans ce que le programme d'installation de Java ES 5 considère comme un emplacement non configuré par défaut.
Ce problème se produit également si vous désinstallez la version Java ES 2005Q4 d'Application Server avant d'installer les versions Java ES 5 de Service Registry et d'Application Server.
Solution : Si vous avez désinstallé Application Server, vous devez supprimer les packages sun-hadb avant de procéder à la réinstallation.
Si vous effectuez directement une mise à niveau de la version Java ES 2005Q4 de Service Registry vers la version Java ES 5, les étapes sont plus compliquées :
Supprimez les packages sun-hadb.
Installez les versions Java ES 5 de Service Registry et d'Application Server.
Modifiez le fichier /opt/sun/appserver/config/asenv.conf comme suit :
Dans le répertoire /opt/sun/appserver/lib, créez un sous-répertoire nommé endorsed.
Copiez le fichier /opt/sun/javadb/lib/derby.jar dans le répertoire /opt/sun/appserver/lib/endorsed.