新しい『Solaris WBEM 開発ガイド』の付録 A では、以前『Solaris WBEM SDK 開発ガイド』で言及されていた MOF ファイルに関する記述が更新されたとあります。新しい 『Solaris WBEM 開発ガイド』の Solaris_DMGT1.0.mof および Solaris_VM2.0.mof ファイルに関する記述は誤りです。これら 2 つのファイルは、今回のリリースには含まれません。
新しい『Solaris WBEM 開発ガイド』の付録では、以前『Solaris WBEM SDK 開発ガイド』で言及されていた MOF ファイルに関する記述が更新されたとあります。しかし、新しい 『Solaris WBEM 開発ガイド』と『Solaris 9 4/03 オペレーティング環境の概要』の Solaris_DMGT1.0.mof ファイルおよび Solaris_VM2.0.mof ファイルに関する記述は誤りです。これら 2 つのファイルは、今回のリリースには含まれません。
Solaris CIM スキーマでは、次のクラスおよび属性に Deprecated 修飾子のタグが付いています。
Solaris_LogRecord クラス
Solaris_LogService クラス
Solaris_LogServiceSetting クラス
Solaris_IPProtocolEndpoint クラスの OptionsEnabled プロパティ
これらの推奨されないクラスおよび属性には、適切な代替クラスおよび属性を使用してください。適切な代替クラスおよび属性かどうかを判別するには、クラスの Description 修飾子を参照してください。
「クライアントプログラムの記述」では、javax.wbem.client API で RMI プロトコルを使用する WBEM クライアントを作成する場合に必要な情報を記載しています。 Solaris 8 オペレーティング環境を実行しているサーバーに接続する場合は、クライアントの CLASSPATH に /usr/sadm/lib/wbem/cimapi.jar ファイルを指定する必要があります。cimapi.jar ファイルには、Solaris 8 オペレーティング環境を実行しているサーバーとの通信に必要な com.sun.wbem クラスが指定されています。
このマニュアルはインデックスが付いた配備ディレクトリだけに関係します。
配備済みアプリケーションのディレクトリ名に付加されるインデックス番号は、インデックス作成機構として実装されています。 この機構により、開発者は配備済みアプリケーションに関連する JAR ファイルやクラスファイルを修正することが可能です。 Windows プラットフォームでは、ロードしたファイルを上書きすると、共有違反が発生するため、この機構は特に重要です。Windows はロードしたファイルをロックします。セッションが開始されると、ファイルはサーバーインスタンスや IDE (統合開発環境、Integrated Development Environment) にロードされます。共有違反が発生した場合は、次の 2 つの回避方法が可能です。
更新されたクラスファイル (元は JAR ファイルの一部) をコンパイルし、クラスパスに置くことで、古いクラスファイルより前にロードさせます。次に、再ロードがアクティブであれば、Sun ONE Application Server に対してアプリケーションの再ロードを許可します。
JAR ファイルを更新し、EAR ファイルを新しく作成して、アプリケーションを再配備します。
Solaris プラットフォームでは、ファイルをロックするという制約がないため、アプリケーションを再配備する必要はありません。
Windows プラットフォーム上で IDE を起動するか、ANT ファイルをコピー、コンパイルなどして、配備済みアプリケーションを変更すると、ほかの箇所にも変更が発生することに注意してください。ファイルロックによる制約を回避するために、ディレクトリ名に増分したインデックス番号が付加されて、新しいディレクトリ名が作成されます。たとえば、Solaris プラットフォームの場合、J2EE アプリケーションの helloworld は、Sun ONE Application Server の次のディレクトリに格納されます。
appserv/domains/domain1/server1/applications/j2ee-apps/helloworld_1
ディレクトリ名の変更は、配備済みアプリケーション(例: HelloServlet.java) を構成するサーブレットにも適用されます。Sun ONE Studio IDE を起動し、サーブレットのソースファイルを変更した後、前述のディレクトリを指定して javacでコンパイルします。ソースファイルを適切なロケーションでコンパイルし、アプリケーションで再ロードするファイルがあると、server.xml ファイルの reload フラグが True にセットされます。アプリケーションを再度アセンブルして、再配備しなくても、サーバーインスタンスを実行するだけで変更内容が反映されます。
Windows プラットフォームの場合、ファイルがロックされるため、JAR ファイルとクラスファイルは変更およびアップデートができません。そのため、Windows プラットフォームでの解決には、次の 2 つの方法があります。
変更したソースファイルをコンパイルし、クラスパスにクラスファイルまたは JAR ファイルを付加し、ソースファイルの変更内容を有効にします。
helloworld のソースを変更し、アセンブルした後、古い helloworld を削除せずに、配備しなおします。
配備済みアプリケーションのディレクトリ名に増分したインデックス番号が付加されるため、2 番目の方法が推奨されています。2 つ目の helloworld アプリケーションを配備すると、ディレクトリ構造は次のようになります。
appserv/domains/domain1/server1/applications/j2ee-apps/helloworld_1
appserv/domains/domain1/server1/applications/j2ee-apps/helloworld_2
2 番目の helloworld は helloworld_2 に格納されます。
「ルート (/) のミラー化に関する特殊な考慮事項」では、ルート (/) をミラー化する場合に必要な代替起動デバイスへのパスを記録する例を記載しています。SPARC 版の例で、一部の新しい Sun ハードウェアでは、/devices ディレクトリ名を sd@ や dad@ から disk@ に変更する必要があります。
一部の X Window System 関係の日本語翻訳マニュアルページは、内容が最新ではありません。
回避方法: 日本語マニュアルページは参考とし、最新の情報は英語版マニュアルページを参照してください。(例 : % env LANG=C man XtAddCallback)