This chapter describes known documentation problems. For documentation issues identified too late to be included in these release notes, refer to theSolaris 9 12/03 Release Notes at http://docs.sun.com/db/doc/817-2706.
The following documentation issues have been added to this chapter since this document was published on the Solaris 9 12/03 Documentation CD and in the Installation Kiosk on the Solaris 9 12/03 Installation CD.
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.
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.
In the Solaris CIM schema, the following classes and properties are tagged with the Deprecated qualifier:
OptionsEnabled property in Solaris_IPProtocolEndpoint class
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.
“Writing a Client Program” provides information about creating WBEM clients that use the RMI protocol with the javax.com.sun.client 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.
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:
Compile the updated class file (originally part of that JAR file) and place it first in the classpath in order to be loaded before the older classes. Then allow for the Sun ONE Application Server to reload this application (as long as reload is active).
Update the JAR file, create a new EAR file, and redeploy the application.
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, HelloServlet.java). 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:
Compile the changed source file and prepend the class file or JAR in the classpath in order to make the source changes effective.
Make the changes to the helloworld source, assemble it, and redeploy it without undeploying the previous deployment of helloworld.
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.