This section describes known and associated solutions related to the sample code included with the Application Server 8.2 product.
From install_dir\samples\ee-samples\failover\apps\mqfailover\docs\index.html, if you run the following commands:
Console 1
cd install_dir\samples\ee-samples asant start-mq-master-broker1 |
Console 2
cd install_dir\samples\ee-samples asant start-mq-cluster-broker1 |
Console 3
cd install_dir\samples\ee-samples asant start-mq-cluster-broker2 |
Console 4
cd install_dir\samples\ee-samples asadmin start-domain domain1 |
If you have already executed asant setup-one-machine-cluster-without-ha or asant setup-one-machine-cluster-with-ha for any other Enterprise Edition sample, then execute asant configure-mq otherwise execute asant setup-one-machine-cluster-and-configure-mq. In this case, the command appears to succeed:
start_nodeagent: [echo] Start the node agent cluster1-nodeagent [exec] Command start-node-agent executed successfully. |
But then the system hangs indefinitely.
None at this time. This problem similarly affects all Enterprise Edition samples that use this ant target on Windows. A workaround is to Ctrl+C out of the hung process and then rerun it.
The error thrown is as follows:
/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 |
The documentation does not explicitly state that JMS resources must be manually created if manual deployment is done using asadmin deploy commands, and that the provided ant targets to deploy the sample application should be used.
Use the asant deploy target for the build.xml script, which creates the required JMS resources to run the application.
When deploying the install_dir/samples/webservices/security sample (basicSSl) on Linux, the certificate is not created and an error similar to the following is thrown:
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 |
The problem is that NSS libraries are in different locations on Linux installations than on Solaris installations. You need to make sure that the LD_LIBRARY_PATH points to the proper NSS libraries when deploying on Linux. Either set LD_LIBRARY_PATH in your environment, or set it in the install_dir/bin/asant shell wrapper script.
Do one of the following:
Set LD_LIBRARY_PATH=/opt/sun/private/lib.
Add to the following line to the install_dir/bin/asant script:
LD_LIBRARY_PATH=$AS_NSS:$LD_LIBRARY_PATH;export LD_LIBRARY_PATH |
After updating from Application Server Platform Edition 8.0 to Application Server Enterprise Edition 8.2, you may receive an HTTP 404 “File not found” error when attempting to access the samples page.
Copy the sample documents from the 8.0 domains to the 8.2 domains.
If Application Server Enterprise Edition 8.2 is installed in a Solaris Global zone, and a Application Server domain is subsequently installed in a Sparse local zone, you may encounter problems running the sample applications if the file permissions for the domain in the Sparse zone are not sufficiently open during the deployment process.
During the deployment process, make sure the Application Server can retrieve the client JAR file, xmsClient.jar, and copy it into the sample location, (/usr/SUNWappserver/appserver/samples/webservices/security/ejb/apps/xms/xmsClient.jar. This is normally done automatically by the sample harness, but it will fail if the permissions on xmsClient.jar are not open.