Cette section décrit les problèmes connus liés au code de l'exemple compris dans le produit Application Server 9.1 ainsi que les solutions associées.
La documentation ne signale pas, de façon explicite, que vous devez créer des ressources JMS avant d'exécuter l'exemple d'application de basculement MQ suivant les instructions de déploiement de asadmin.
L'erreur générée est la suivante :
/opt/SUNWappserver/domains/domain1/config/sun-acc.xml -name MQFailoverTestClient -textauth -user j2ee -password j2ee Nov 18, 2004 10:50:17 PM com.sun.enterprise.naming.NamingManagerImpl bindObjects SEVERE: NAM0006: JMS Destination object not found: jms/durable/TopicA Nov 18, 2004 10:50:18 PM com.sun.enterprise.naming.NamingManagerImpl bindObjects SEVERE: javax.naming.NameNotFoundException javax.naming.NameNotFoundException |
La documentation n'indique pas, de façon explicite, que des ressources JMS doivent être créées manuellement lorsque vous procédez au déploiement manuel à l'aide de la commande asadmin deploy, ni que vous devez utiliser les cibles ant fournies pour déployer l'exemple d'application.
Utilisez la cible asant deploy pour le script build.xml afin de créer les ressources JMS nécessaires à l'exécution de l'application.
Lors du déploiement de l'exemple rép_install/samples/webservices/security (basicSSl) sous Linux, le certificat n'est pas créé et une erreur similaire à celle présentée ci-dessous est générée :
generate_certs: [echo] ***Exporting certificate from NSS database [exec] Result: 1 [echo] ***Generating Java Keystore from generated certificate [exec] keytool error: java.lang.Exception: Input not an X.509 certificate [exec] Result: 1 [echo] ***Generating Java trust store from generated certificate [exec] keytool error: java.lang. Exception: Input not an X.509 certificate [exec] Result: 1 . . . generate_certs: [echo] ***Exporting server certificate from NSS database to a PKCS12 certificate file [exec] /opt/sun/appserver/lib/pk12util: /usr/lib/ libnss3.so: version `NSS_3.9' not found (required by /opt/sun/appserver/lib/ pk12util) [exec] /opt/sun/appserver/lib/pk12util: /usr/lib/libnss3.so: version `NSS_3.6' not found (required by /opt/sun/appserver/lib/pk12util) [exec] /opt/sun/appserver/lib/pk12util: /usr/lib/libnss3.so: version `NSS_3.7' not found (required by /opt/sun/appserver/lib/pk12util) [exec] Result: 1 |
Le problème est que les bibliothèques NSS ne se trouvent pas dans les mêmes emplacements sous Linux et Solaris. Lors du déploiement sous Linux, assurez-vous que le chemin LD_LIBRARY_PATH correspond à celui des bibliothèques NSS appropriées. Définissez la variable LD_LIBRARY_PATH dans votre environnement ou dans le script wrapper install_dir/bin/asant.
Effectuez l'une des opérations suivantes :
Définissez LD_LIBRARY_PATH=/opt/sun/private/lib.
Ajoutez la ligne ci-dessous au script install_dir/bin/asant :
LD_LIBRARY_PATH=$AS_NSS:$LD_LIBRARY_PATH;export LD_LIBRARY_PATH |
Sous Windows, après la mise à niveau d'Application Server 9.1, les exemples de base et ceux du portail JES5 entrent en conflit sur le port Derby 1527. D'une manière plus spécifique, Application Server 9.1 lance automatiquement JavaDB sur le port 0.0.0.0:1527 avec APP:APP, cependant JavaDB du portail JES5 cherche également à s'associer au hostnameIP:1527 avec portal:portal.
Ce problème a déjà été soulevé pour JES 5, sous la référence n° 6472173. La solution correspondante est présentée dans le Sun Java Enterprise System 5 Installation Guide for Microsoft Windows.
Démarrez la base de données Derby à l'aide de la commande suivante :
<JES installation dir>\appserver\bin\asadmin start-database --dbhome <JES installation dir>\portal\data\derby |