Solaris 9 12/03 Release Notes

Documentation Errata

Document Affected: Solaris 9 12/03 Installation Guide

Example 41-8, “Installing With Local CD Media,” incorrectly indicates that you can specify a secure HTTP URL as the location of the wanboot-cgi program. The value of the bootserver variable must be an HTTP URL, in the format: http:/ip-address/path/wanboot-cgi.

Document Affected: “Administering DHCP (Task)” in System Administration Guide: IP Services

The section, “Creating DHCP Options and Macros for Solaris Installation Parameters”, should include the following information regarding DHCP Vendor Options Size Limitations:

Note that the sum total of the values assigned to all the options in a macro must not exceed 255 bytes, including the option codes and length information. This limit is dictated by the DHCP protocol.

Generally, you should pass the minimum amount of vendor information needed. You should use short path names in options that require path names. If you create symbolic links to long paths, you can pass the shorter link names.

Document Affected: Sun WBEM SDK Developers Guide

In the Solaris CIM schema, the following classes and properties are tagged with the Deprecated qualifier:

Use suitable alternatives to these deprecated classes and properties. Refer to the class description qualifiers to determine the correct class and the correct property alternatives.

Document Affected: “Writing Client Applications” in Sun WBEM SDK Developers Guide

“Writing a Client Program” provides information about creating WBEM clients that use the RMI protocol with the API. If you want to connect to a server that is running the Solaris 8 software, you must include the /usr/sadm/lib/wbem/cimapi.jar file in the client's CLASSPATH. The cimapi.jar file includes the com.sun.wbem classes that are required to communicate with a server that is running the Solaris 8 software.

Document Affected: Sun ONE Application Server 7 Developer's Guide

Note –

This documentation pertains to the use of indexed deployment directories.

The numbering scheme part of a deployed application's directory name has been implemented as an indexing mechanism. This mechanism enables a developer to modify a JAR or class file associated with the deployed application. This mechanism is significant to the Windows platform because of a sharing violation error that occurs during an attempt to overwrite a loaded file, Windows places a file lock on the loaded file. The file is loaded into the server instance or the IDE during session startup. With the sharing violation error, two options are possible:

Note –

Redeployment of the application on the Solaris platform is not necessary because no file-locking constraints exist.

When changing an already deployed application on the Windows platform for IDE setup, ANT file copy, or compile or other operations, be aware of another change. A new directory is created with an incremented index number as the workaround for the file-locking constraint. For example, on the Solaris platform the J2EE application, helloworld, is deployed to the Sun ONE Application Server with the following directory structure:


A change is then to be made to a servlet that is part of this deployed application (for example, The Sun ONE Studio IDE is started, the source file for this servlet is changed and compiled with the javac target set to the previously mentioned directory. With the source compiled in the proper location, a reload file exists for this application. The reload flag in server.xml is set to true, and with the server instance running, the changes become effective without reassembly of the application and redeployment.

For the Windows platform, the JAR or class file cannot be altered and updated because of the file-locking issue. Therefore, you can resolve this issue on Windows in one of two ways:

The second option is the preferred method because this option results in the use of the incremented index number appended to the deployed application's directory name. After a second deployment of helloworld, the directory structures would resemble the following:



The second deployment of helloworld would be deployed under helloworld_2.