This chapter describes known documentation problems.
The following documentation issues have been added to this chapter since this document was published on the Solaris 9 Documentation CD and in the Installation Kiosk on the Solaris 9 Installation CD.
The LDAP package SUNWlldap is not included in "Solaris 9 Operating Environment Package List" in Solaris 9 Package List. The SUNWlldap package is included in the Solaris 9 operating environment, and is included in the Core, End User, Developer, Entire, and Entire+OEM metaclusters.
The sysidcfg(4) man page and Solaris 9 12/02 Release and Installation Collection instruct you to use only an IPv4 address as a value for the default_route keyword in the sysidcfg file. However, you can also use NONE as a value for the default_route keyword.
In the Solaris CIM schema, the following classes and properties are tagged with the Deprecated qualifier.
Solaris_LogRecord class
Solaris_LogService class
Solaris_LogServiceSetting class
Solaris_LogServiceSetting class
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 operating environment, 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 operating environment.
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:
appserv/domains/domain1/server1/applications/j2ee-apps/helloworld_1
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:
appserv/domains/domain1/server1/applications/j2ee-apps/helloworld_1
appserv/domains/domain1/server1/applications/j2ee-apps/helloworld_2
The second deployment of helloworld would be deployed under helloworld_2.