test

Sun Java System Application Server 9.1 Release Notes

Samples

This section describes known and associated solutions related to the sample code included with the Application Server 9.1 product.

Documentation does not explicitly state that you need to create JMS resources Documentation does not explicitly state that you need to create JMS resources (6198003)

Description

Documentation does not explicitly state that you need to create JMS resources before running the MQ Failover Sample Application following the asadmin deploy instructions.

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.

Solution

Use the asant deploy target for the build.xml script, which creates the required JMS resources to run the application.

On Linux, a runtime error is displayed during certificate creation in web services/security samples (6198239)

Description

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.

Solution

Do one of the following:

After upgrade AS9.1 samples and JES5 portal samples compete on derby port 1527 (6574563)

Description

On Windows, after upgrading to Application Server 9.1, the samples and JES5 portal samples compete on Derby port 1527. Specifically, Application Server 9.1 automatically starts JavaDB on port 0.0.0.0:1527 with APP:APP, however the JES5 Portal JavaDB wants to bind to hostnameIP:1527 with portal:portal.

This bug describes an issue that was already seen for JES 5, Bug 6472173. The workaround for bug 6472173 is documented in the Sun Java Enterprise System 5 Installation Guide for Microsoft Windows.

Solution

Start the Derby database using the following command:


<JES installation dir>\appserver\bin\asadmin start-database --dbhome <JES installation dir>\portal\data\derby