| Oracle® WebCenter Content Content Server開発者ガイド 11gリリース1(11.1.1) B66702-01 |
|
 前へ |
 次 |
ホーム > Content Server開発者ガイド > IdcCommandユーティリティを使用したコンテンツ・サーバーへのアクセス
| Oracle® WebCenter Content Content Server開発者ガイド 11gリリース1(11.1.1) B66702-01 |
|
前へ |
次 |
ホーム > Content Server開発者ガイド > IdcCommandユーティリティを使用したコンテンツ・サーバーへのアクセス
この章では、IdcCommandユーティリティを使用して、他のアプリケーションからOracle WebCenter Content Serverサービスにアクセスする方法について説明します。
この章では、次の項目について説明します。
IdcCommandユーティリティは、コンテンツ・サーバー・サービスを実行するスタンドアロンのJavaアプリケーションです。コンテンツ・サーバーのブラウザ・インタフェースまたは管理アプレットから実行可能なほとんどのアクションは、IdcCommandから実行できます。
プログラムは、サービス・コマンドおよびパラメータを含むコマンド・ファイルを読み取り、指定されたサービスをコールします。ログ・ファイルには、コールの実行時間、サービスの実行の成否および実行エラーの有無を記録できます。
|
注意: IdcCommandユーティリティは、コマンドの成否に関する情報のみを返します。対話型セッションでOracle WebCenter Content Serverから情報を取得するには、Microsoft Windowsプラットフォームで使用可能なJava COMラッパーIdcCommandXを使用します。 |
IdcCommandユーティリティを実行するには、コマンドラインまたはintradoc.cfg構成ファイルで次のパラメータを指定する必要があります。
サービス・コマンドおよびパラメータを含むコマンド・ファイル
コールされるサービスを実行する権限を持つユーザーのコンテンツ・サーバー・ユーザー名
ログ・ファイルのパスおよびファイル名
接続モード(auto、serverまたはstandalone)
特定のコマンドは、standaloneモードでは実行できません。一般に、サーバーは、これらのコマンドをバックグラウンド・スレッドで非同期に実行します。これは、検索索引の更新または再構築で発生します。
カスタム・コンポーネントにおけるサービスの使用については、第9章「コンテンツ・サーバーのコンポーネントの開始」およびOracle WebCenter Contentサービス・リファレンス・ガイドを参照してください。
IdcCommandを設定するには、次の2つのものを指定する必要があります。
コマンド・ファイル。実行するサービスおよびサービス・パラメータを指定します。
構成オプション。コマンド・ファイルおよび他のIdcCommand情報を指定します。IdcCommand構成オプションは、次の2か所で設定できます。
構成ファイルで、例21-1に示されているように、名前/値のペアを使用します。
IdcCommandの実行時に、コマンドラインで、次のようなオプション・フラグを指定します。
|
注意: コマンドライン構成オプションは、構成ファイル内の設定をオーバーライドします。 |
IdcCommandは、コマンドラインから実行されます。コマンドラインから、または構成ファイルで、構成オプションを指定できます。詳細は、第21.3項「IdcCommandの実行」を参照してください。
コマンド・ファイルは、IdcCommandユーティリティによって実行されるサービス・コマンドおよびパラメータを定義します。コマンド・ファイルは、構文、優先順位、および特殊タグと特殊文字に関するルールに従う必要があります。
コマンド・ファイルでは、HDA (ハイパーデータ・ファイル)構文を使用してサービス・コマンドを定義します。
実行する各サービスは、パラメータとともに@Properties LocalDataセクションに指定します。
一部のサービスについては、@ResultSetセクションを使用して追加情報を指定します。
コマンド・ファイルの1つのセクションのデータは、次のセクションに持ち越されることはありません。セクションごとに、コマンドの完結したデータ・セットが含まれるようにする必要があります。
サービス名およびパラメータでは、大/小文字が区別されます。
例21-3では、ADD_USERサービスを実行し、2人の新規ユーザーの属性を定義するコマンド・ファイルを示します。
例21-3 ADD_USERサービスのコマンド・ファイル
<?hda version="5.1.1 (build011203)" jcharset=Cp1252 encoding=iso-8859-1?> # Add users @Properties LocalData IdcService=ADD_USER dName=jsmith dUserAuthType=Local dFullName=Jennifer Smith dPassword=password dEmail=email@example.com @end @ResultSet UserAttribInfo 2 dUserName AttributeInfo jsmith role,contributor,15 @end <<EOD>> @Properties LocalData IdcService=ADD_USER dName=pwallek dUserAuthType=Local dFullName=Peter Wallek dPassword=password dEmail=email@example.com @end @ResultSet UserAttribInfo 2 dUserName AttributeInfo pwallek role,contributor,15,account,marketing,7 @end <<EOD>>
IdcCommandでは、優先順位を使用して、コマンド・ファイルのLocalDataセクション内の名前/値のペア間の競合を解決します。標準の名前/値のペアが解析される場合、それらは@Properties LocalDataタグ内にあると想定されます。セクションにHDAタグが含まれる場合、標準の名前/値のペアは、@Properties LocalDataタグ内の名前/値のペアに優先します。
たとえば、foo=xが標準の名前/値のペアであり、foo=yが@Properties LocalDataタグ内にある場合、foo=xという名前/値のペアがタグ外にあるため、このペアが優先されます。
次の特殊タグと特殊文字は、コマンド・ファイルで使用できます。
| 特殊文字 | 説明 |
|---|---|
| IdcService=service_name | コマンド・ファイルの各セクションには、コールするサービスの名前を指定する必要があります。 |
| <<EOD>> | データ終了マーカー。コマンド・ファイルには、1つ以上のセクションを、データ終了マーカーで区切って含めることができます。例については、第21.2.1.1項「コマンド・ファイルの構文」を参照してください。 |
| # | 行の先頭にあるシャープ文字は、その行がコメントであることを示します。 |
| \ | バックスラッシュは、エスケープ文字です。 |
| @Include filename | このタグを使用すると、@Includeタグがある場所に別のファイルのコンテンツをインクルードできます。このタグは、HDAファイル全体または共有の名前/値のペアのインクルードに使用できます。このインクルードでは、指定されたファイルのコンテンツがそのまま取得され、@Includeタグの場所に配置されます。ファイルは、必要な回数だけインクルードでき、インクルードされるファイルに他のファイルをインクルードすることも可能です。ただし、循環インクルードは許可されていません。 |
IdcCommandユーティリティを実行するには、コマンドラインまたはDomainHome/ucm/cs/bin/intradoc.cfg構成ファイルで次のパラメータを指定します。
| パラメータ | 必須かどうか | コマンドラインの構文 | 構成ファイルの構文 |
|---|---|---|---|
| コマンド・ファイル |
あり |
|
|
| ユーザー |
あり |
|
|
| ログ・ファイル |
なし |
|
|
| 接続モード |
なし |
|
|
|
注意: コマンドライン構成オプションは、構成ファイル内の設定をオーバーライドします。 |
サービス・コマンドおよびパラメータを含むコマンド・ファイルの名前を指定する必要があります。コマンド・ファイル・パラメータには、フルパス(C:/command_files/command.txtなど)、または相対パスを指定できます。詳細は、第21.2.1項「コマンド・ファイルの指定」を参照してください。
IdcCommandログ・ファイルのパスおよびファイル名を指定できます。各コマンドが実行されると、メッセージがログ・ファイルに送信されます。ログ・ファイルには、コマンドの実行時間および成功または失敗のステータスが記録されます。ログ・ファイルがすでに存在する場合は、新しいメッセージで上書きされます。ログ・ファイルを使用して、処理に関する情報をユーザーに表示することができます。
実行されたアクションが成功した場合は、成功を示すメッセージがログ・ファイルに書き込まれます。
実行されたアクションが失敗した場合は、エラー・メッセージがログ・ファイルに書き込まれます。
ログ・ファイルが指定されていない場合、情報は画面にのみ表示されます。
IdcCommandサービスを実行するための接続モードを指定できます。
IdcCommandを実行する手順は次のとおりです。
新しいIdcCommand作業ディレクトリを作成します。
このディレクトリは、コマンド・ファイルおよび構成ファイルに使用します。
作業ディレクトリにコマンド・ファイルを作成して、必要なサービス・コマンドを指定します。
intradoc.cfg構成ファイルをDomainHome/ucm/cs/binディレクトリから作業ディレクトリにコピーします。
|
重要: IntradocDirまたはWebBrowserPathの情報を削除しないでください。 |
例21-4に示されているように、IdcCommandオプションを作業ディレクトリ内のintradoc.cfgファイルに追加します。
例21-4 intradoc.cfgファイルにおけるIdcCommandオプション
IdcCommandFile=newfile.hda
IdcCommandUserName=sysadmin
IdcCommandLog=C:/domain/newlog.txt
詳細は、第21.2.2項「構成オプションの指定」を参照してください。
DomainHome/ucm/cs/binディレクトリからIdcCommandユーティリティを実行します。
IdcCommand.exe
ランチャは、Windows環境でのサービスの管理やJava VMのコマンドライン引数および環境設定の構成に使用されるネイティブのC++アプリケーションです。
ランチャの主な動作は、構成ファイルを検出して読み取り、特殊な値を計算した後、構成したコマンドラインで実行可能ファイルを起動することです。構成ファイルは、Bourne Shellのような置換をサポートしています。置換はすべてドル記号($)で始まり、英数字の識別子または中カッコ({})で囲まれた式が続きます。
ランチャ実行可能ファイルは、DomainHome/ucm/native/platform/bin/Launcherにインストールされます。UNIXシステムでは、Launcher.sh(ランチャ実行可能ファイルを実行するBourne Shellラッパー)へのシンボリック・リンクがbinディレクトリに作成されます。このラッパーの目的は、プラットフォームに適したバイナリのランチャ実行可能ファイルを見つけることです。ランチャという用語は、ここでは、ネイティブのランチャ実行可能ファイルまたはBourne ShellスクリプトLauncher.shを指すために使用されます。
ランチャまたはLauncher.shへのシンボリック・リンクは、有効なintradoc.cfg構成ファイルがあるディレクトリ内に存在し、起動されるJavaクラス・ファイルと同じ名前(大/小文字を区別)である必要があります。ランチャは、この名前を使用して環境変数STARTUP_CLASSを設定します。
Windowsでは、この名前は、GetModuleFileName()をコールして計算されます。UNIXシステムでは、argv[0]を調べて計算されます。PLATFORM変数は、プラットフォームのコンテンツ・サーバー識別子に設定されます。BIN_DIR変数は、ランチャがあるディレクトリに設定されます。
ランチャは、BIN_DIRからintradoc.cfgという名前のファイルを読み取ります。このファイルには、IntradocDirの値が含まれています。IntradocDirディレクトリは、相対パスを解決するためのベース・ディレクトリとして使用されます。このドキュメントでの非修飾パスはすべて、IntradocDirに対して相対的であるとみなされます。コンテンツ・サーバーの将来のリリースでは、これらの変数名は変更または削除される可能性があります。
intradoc.cfgファイルにIdcResourcesDirの値が含まれていない場合、ランチャによって、IdcResourcesDirが$IntradocDir/resourcesに設定されます。ランチャがWindowsサービスを起動する場合、IS_SERVICEは1に設定されます。また、設定されていない場合は、PATH_SEPARATORがプラットフォームに適した文字に設定されます。
ランチャは、まずintradoc.cfgファイルを読み取って構成ファイルの場所を検索し、次に使用可能なすべての構成ファイルを次の順番で読み取ります。
$IdcResourcesDir/core/config/launcher.cfg
$BIN_DIR/../config/config.cfg
$IntradocDir/config/config.cfg
$IntradocDir/config/config-$PLATFORM.cfg
$IntradocDir/config/state.cfg
$IdcResourcesDir/core/config/launcher-$PLATFORM.cfg
$BIN_DIR/intradoc.cfg
$BIN_DIR/intradoc-$PLATFORM.cfg
-cfgオプションを使用してコマンドラインに指定されたすべてのファイル
|
ヒント: -cfgオプションNAME=VALUEを使用して、コマンドラインで直接、変数値を割り当てることができます。 |
ランチャは、Bourne Shellのような引用符のルールを使用します。文字列を二重引用符(")で囲むと、空白をエスケープできます。バックスラッシュ(\)を任意の文字の前に置くと、その文字そのものを指定できます。最終的なコマンドラインが計算されると、ランチャは、そのコマンドラインを引用符なしの空白ごとに区切ります。その後、各文字列は、コマンドのargv配列のエントリとして引用符なしで使用されます。
構成ファイルを読み取った後、ランチャは、変数置換を処理します。一部の変数では、ディレクトリまたはファイルを検証する、コマンドライン引数リストを作成する、PATHのような変数を構成するなどの追加の計算を行うことができます。
これらの特殊な計算は、変数に対してそのタイプに基づいて実行されます。変数のタイプを設定するには、前述のどの構成ファイルでもTYPE_variable_name=typenameを設定します。
ランチャの変数タイプは次のとおりです。
file
例21-5では、fileタイプの変数を示します。
例21-5 fileランチャ変数
TYPE_PASSWD_FILE=file PASSWD_FILE_sys5=/etc/passwd PASSWD_FILE_bsd=/etc/master.passwd
このタイプは、ファイルを検索します。variable_nameの値が既存ファイルへのパスである場合は、その値が保存されます。そうでない場合は、variable_name_で始まるすべての変数がチェックされます。既存ファイルへのパスである最後の値が、variable_nameの新しい値に使用されます。
この例では、PASSWD_FILEは、/etc/master.passwdが存在する場合は/etc/masterに設定され、/etc/passwdが存在する場合は/etc/passwd</span>に設定されます。それ以外の場合、PASSWD_FILEは定義されません。
directory
例21-6では、directoryタイプの変数を示します。
例21-6 directoryランチャ変数
TYPE_JDK=directory JDK_java_home=$JAVA_HOME IdcNativeDir=$IdcHomeDir/native DEFAULT_JDK_DIR=$OS_DIR/$PLATFORM JDK_legacy142=$DEFAULT_JDK_DIR/j2sdk1.4.2_04 JDK_default=$DEFAULT_JDK_DIR/jdk1.5.0_07
この例では、JDKは、ディレクトリを示す最後のJDK_変数と同じ値に設定されます。通常これは、Oracle Fusion MiddlewareとともにインストールされたJDKを指します。JDK_java_homeは$JAVA_HOMEを参照することに注意してください。変数がどの構成ファイルにも定義されておらず、環境に定義されている場合は、環境の値が使用されます。
executable
例21-7では、executableタイプの変数を示します。
例21-7 executableランチャ変数
TYPE_JAVA_EXE=executable JAVA_EXE_default=java$EXE_SUFFIX JAVA_EXE_jdk_default=$JDK/bin/java$EXE_SUFFIX
executableタイプは、実行可能ファイルを検索します。これは、fileタイプと非常によく似た動作をしますが、各候補値について$PATH内のすべてのディレクトリを調べます。この例では、JAVA_EXEは、JDK内のJava実行可能ファイルが存在する場合は、そのファイルに設定されます。それ以外の場合は、PATH内の最初のJava実行可能ファイルに設定されます。
list
例21-8では、listタイプの変数を示します。
例21-8 listランチャ変数
TYPE_JAVA_OPTIONS=list
JAVA_MAX_HEAP_SIZE=384
DEFINE_PREFIX=-D
JAVA_OPTIONS_BIN_DIR=${DEFINE_PREFIX}idc.bin.dir=$BIN_DIR
JAVA_OPTIONS_maxheap=${JAVA_MAX_HEAP_SIZE+-Xmx${JAVA_MAX_HEAP_SIZE\}m}
JAVA_OPTIONS_service=${IS_SERVICE+$JAVA_SERVICE_EXTRA_OPTIONS}
listタイプは、実行可能ファイルのオプションのリストを計算します。variable_name_で始まる各値が引用符付きのオプションになり、variable_nameにはリスト全体が設定されます。この例では、JAVA_OPTIONSは次の文字列に設定されます。
"-Didc.bin.dir=/intradocdir/bin/" "-Xmx384m"
path
例21-9では、pathタイプの変数を示します。
例21-9 pathランチャ変数
IdcResourcesDir=${IdcResourcesDir-$IdcHomeDir/resources}
BASE_JAVA_CLASSPATH_source=$IdcResourcesDir/classes
BASE_JAVA_CLASSPATH_serverlegacy=$SharedDir/classes/server.zip
BASE_JAVA_CLASSPATH_server=$JLIB_DIR/idcserver.jar
pathタイプは、パスのような値を計算します。variable_name_で始まる各変数の値が、PATH_SEPARATORの値で区切られてvariable_nameに追加されます。この例では、BASE_JAVA_CLASSPATHは、非常に長いクラスパスに設定されます。
lookupstring
例21-10では、lookupstringタイプの変数を示します。
例21-10 lookupstringランチャ変数
TYPE_VDK_PLATFORM=lookupstring
PARAMETER_VDK_PLATFORM=${PLATFORM}_${UseVdkLegacySearch+vdk27}
VDK_PLATFORM_aix_vdk27=_rs6k41
VDK_PLATFORM_aix_=_rs6k43
VDK_PLATFORM_hpux_vdk27=_hpux11
VDK_PLATFORM_hpux_=_hpux11
VDK_PLATFORM_freebsd_vdk27=_ilnx21
VDK_PLATFORM_freebsd_=_ilnx21
VDK_PLATFORM_linux_vdk27=_ilnx21
VDK_PLATFORM_linux_=_ilnx21
VDK_PLATFORM_solaris_vdk27=_ssol26
VDK_PLATFORM_solaris_=_ssol26
VDK_PLATFORM_win32_vdk27=_nti40
VDK_PLATFORM_win32_=_nti40
lookupstringタイプは、2番目のパラメータを使用して最終的な値の検索キーを構成します。2番目のパラメータとは、$PARAMETER_variable_nameの値です。この値が定義されていない場合は、variable_nameの現在の値が検索キーとして使用されます。この例では、PARAMETER_VDK_PLATFORMは、UseVdkLegacySearchの値に応じて、${PLATFORM}_または${PLATFORM}_vdk27の値となります。
この値はその後、変数VDK_PLATFORM_${PARAMETER_VDK_PLATFORM}の値の検索に使用されます。検索された値は、引用符で囲まれてVDK_PLATFORMに割り当てられます。
lookuplist
例21-11では、lookuplistタイプの変数を示します。
例21-11 lookuplistランチャ変数
TYPE_STARTUP_CLASS=lookuplist STARTUP_CLASS_version=Installer --version STARTUP_CLASS_installer=Installer STARTUP_CLASS_WebLayoutEditor=IntradocApp WebLayout STARTUP_CLASS_UserAdmin=IntradocApp UserAdmin STARTUP_CLASS_RepositoryManager=IntradocApp RepositoryManager STARTUP_CLASS_Archiver=IntradocApp Archiver STARTUP_CLASS_WorkflowAdmin=IntradocApp Workflow STARTUP_CLASS_ConfigurationManager=IntradocApp ConfigMan
lookuplistタイプは、2番目のパラメータを使用して最終的な値の検索キーを構成します。2番目のパラメータとは、$PARAMETER_variable_nameの値です。この値が定義されていない場合は、variable_nameの現在の値が検索キーとして使用されます。
lookupstringとは異なり、lookuplistは、最終的な値を引用符で囲みません。この例では、STARTUP_CLASSの現在の値はversionです。STARTUP_CLASSは、Installer --versionという値に置き換えられます。
計算される設定の処理後、ランチャは、文字列EXPORT_で始まるすべての変数に対して繰り返し適用されます。各変数の値は、環境変数の名前として使用されます。環境変数の名前には、EXPORT_変数の後半の値が割り当てられます。たとえば、EXPORT_IDC_LIBRARY_PATH=LD_LIBRARY_PATHは、IDC_LIBRARY_PATH変数の値をLD_LIBRARY_PATHという名前でエクスポートします。
変数JAVA_COMMAND_LINEは、コマンドラインの取得に使用されます。使用されていないランチャに対するコマンドライン引数はすべて、コマンドラインに追加されます。UNIXシステムでは、コマンドラインが解析され、引用符は付けられず、execvがコールされます。Windowsでは、シャットダウンのミューテックスが作成され、CreateProcessがコマンドラインを使用してコールされます。CreateProcessではバックスラッシュを付ける処理を元に戻すことはできないため、注意する必要があります。
ランチャをデバッグするための主な方法は、最終的なコマンドの引数の前に-debugフラグを追加することです。$BIN_DIR/debug.logというファイルを作成することもできます。このファイルは、デバッグ・モードをトリガーしてデバッグ出力を格納します。
ランチャは、動作を制御するために設定または使用される次の構成エントリを認識します。これらの構成変数は、コンテンツ・サーバーの将来のリリースで変更または削除される可能性があることに注意してください。
IDC_SERVICE_NAME: サービスの登録、登録解除、起動および停止に使用されるwin32サービスの名前。
IDC_SERVICE_DISPLAY_NAME: サービスの登録に使用されるwin32の表示名。
IntradocDir: 相対パス名のベース・ディレクトリ。
IdcBaseDir: IntradocDirの代替名。
IdcResourcesDir: 特に定義されていない場合は、$IdcHomeDir/resourcesに設定されます。
IdcNativeDir: 特に設定されていない場合は、デフォルトで$IdcHomeDir/nativeに設定されます。
PATH_SEPARATOR: 特に設定されていない場合は、コロン(:)またはセミコロン(;)のいずれかに設定されます。
STARTUP_CLASS: ランチャ実行可能ファイルの名前に設定されます。
MUTEX_NAME: win32でシャットダウンのミューテックスを作成するために使用される名前。
BEFORE_WIN_SERVICE_START_CMD: 設定された場合、win32サービスの起動前に実行されるコマンドラインになります。
UseRedirectedOutput: 設定された場合、win32上のランチャにJava VMからの出力をファイルにリダイレクトするように指示します。
ServiceStartupTimeout: Javaプロセスがwin32で正常に起動するのを待機するために使用されるタイムアウト。
|
ヒント: Launcher.exeを使用してstatus.datファイルを変更し、JVMコマンドラインの値を変更すると、理論上は、どのJavaプログラムもWindowsサービスとして実行できます。この方法は、通常の使用にはお薦めしませんが、こうすることで、ランチャのいくつかの構成方法が明らかになります。 |
ランチャのUIは、起動するアプリケーションと同じです。たとえば、ランチャの名前をIntradocAppに変更した場合、Webレイアウト・エディタを起動するには、次のコマンドライン引数を指定します。
IntradocApp WebLayout
これにより、Webレイアウト・エディタは、スタンドアロン・アプリケーションとして起動されます。
デフォルトでは、アプリケーションはコンソール出力なしの状態で起動されます。ただし、IdcServer、IdcAdmin、IdcCommandXまたはInstallerを起動すると、Java出力が画面に表示されます。その他の場合はすべて、出力はクリーナ・インタフェースに対して表示されません。
バッチ・ローダーやリポジトリ・マネージャなど、アプリケーションによっては、アプリケーションからのJava出力を表示するほうが望ましいものがあります。ランチャがJava出力を画面にダンプするようにするには、次のように-consoleフラグを使用します。
IntradocApp RepMan -console
これで、リポジトリ・マネージャの起動元のコンソールに出力が書き込まれます。
ランチャの名前をIdcServer、BatchLoader、SystemProperties、または追加パラメータを必要としないその他の任意のJavaクラスに変更すると、ダブルクリックするだけで起動できます。その他の場合は、ショートカットを使用すると、ダブルクリックで起動できます。
ランチャを使用するには、まず、Launcher.exeファイルの名前を変更して、起動するクラス・ファイルと同じ名前の実行可能ファイルにします。一般的な例としては、IdcServer.exeやIntradocApp.exeなどがあります。
|
注意: カスタム・アプリケーションを作成する場合、カスタム・ディレクトリを作成し、Launcher.exeファイルの名前を、起動するサービスに変更する必要があります。有効なintradoc.cfgファイルが実行可能ファイルと同じディレクトリに存在している必要があります。必須パラメータはIntradocDirのみです。ただし、他のエントリを追加してJavaアプリケーションの起動方法を変更できます。 |
実行する必要のあるアプリケーションの構成ファイルを変更できます。例21-12に、ほぼすべてのコンテンツ・サーバー・アプリケーションを起動するのに十分な構成ファイルのエントリを示します。
例21-12 コンテンツ・サーバー・アプリケーションの構成ファイルのエントリ
<?cfg jcharset="Cp1252"?>
#Content Server Directory Variables
IntradocDir=C:/domain/idcm1/
BASE_JAVA_CLASSPATH_source=$IdcResourcesDir/classes
BASE_JAVA_CLASSPATH_serverlegacy=$SharedDir/classes/server.zip
BASE_JAVA_CLASSPATH_server=$JLIB_DIR/idcserver.jar
Oracle WebCenter Content: Inbound Refineryなどの他のアプリケーションでは、クラスパスにクラスを追加する必要があります。このファイルを変更して、別のJava仮想マシンを使用してコンテンツ・サーバーを実行できるようにすることも可能です。
CLASSPATHは、リストされたエントリの順にクラス・ファイルを検索するように設計されています。つまり、ランチャは、DomainHome/ucm/idc/nativeディレクトリ全体を検索してから、resourcesディレクトリまたはserver.zipファイル内を調べます。これは、ZIPファイルにパッチを適用せずにJavaクラスをオーバーロードする場合に適しています。
さらに、Javaアプリケーションがランチャとの通信に適したAPIに準拠している場合は、ランチャを使用して、Javaアプリケーションのインストール、アンインストールおよび実行をWindowsサービスとして行うことができます。ランチャを使用してJavaアプリケーションをWindowsサービスとして実行できるようにする方法の詳細は、IdcServer.javaまたはIdcAdmin.javaのソース・コードを参照してください。
COMPUTEDCLASSPATHは、ランチャが使用するCLASSPATHにクラス・ファイルを追加するために使用されます。クラス・ファイルを追加するには、このフラグをオーバーライドします。
|
注意: intradoc.cfgファイルは通常、インストール時に、特定のデータベースに対するJDBCドライバの場所を含むように変更されます。別のJDBCドライバを使用する場合は、ドライバをコンテンツ・サーバーのIdcHomeDirディレクトリの外部(IntradocDir)に配置し、intradoc.cfgファイル内のJDBC_JAVA_CLASSPATH_customjdbcエントリをドライバの場所に変更します。 |
例21-13では、Windowsオペレーティング・システム上でIBM仮想マシンを使用してコンテンツ・サーバーを実行するコマンドを示します。
カスタムJVMを使用する場合は、使用するJava実行可能ファイルへのフルパスを指定します。
|
注意: JVMコマンドラインのオーバーライドは避けてください。カスタム・クラス・ローダーのため、カスタマイズはより複雑なものになります。JVMコマンドラインをオーバーライドする場合は、$IdcHomeDir/resources/core/config/launcher.cfgファイルから始めます。 |
構成ファイル内のJAVA_COMMAND_LINE_SELECTIONエントリは、idcclassloaderまたはtraditionalに設定できます。
使用しているJVMを変更するとき、そのJVMにすべての標準Sun SDK JARファイルがある場合は、J2SDK構成エントリを使用してSDKディレクトリのルート・ディレクトリを再配置する方が、JAVA_EXEを使用してJava実行可能ファイルの場所を指定する(この方法はIBM VMには適用できません)よりも適切です。
J2SDK変数は、Sun SDKライブラリ(tools.jarなど)があるディレクトリを変更します。JAVA_EXEエントリを設定せずにこのエントリを変更すると、Java実行可能ファイルはJ2SDKのパスのbinディレクトリ内にあるとみなされます。J2SDKのデフォルト値は、...\shared\os\win32\j2sdk1.4.2_04です。
JAVA_OPTIONSに値を追加するには、JAVA_OPTIONS_server=-serverまたは別の同様の値を使用します。
次の表に、一般に使用されるコマンドライン・オプションを示します。アスタリスク(*)が付けられたオプションは、Windows オペレーティング・システムでのみ使用できます。マークが付けられていないオプションは、WindowsまたはUNIXオペレーティング・システムで使用できます。
| オプション | 説明 |
|---|---|
-console |
* Java出力およびエラー・ストリームがコンソールに表示されるように、Windowsコンソール・ウィンドウを開いたままにするようランチャに指示します。 |
-debug |
起動時に使用されたパスと変数、および起動時のエラーを表示します。また、これが繰り返された場合は、コンテンツ・サーバーでのJavaデバッグを可能にします。これにより、詳細レベルが上がります。 |
-fileDebug |
-debugオプションと似ていますが、このオプションは、デバッグ・データをデバッグ・ログ・ファイルにダンプします。これは通常、Windowsサービスをデバッグするために、intradoc.cfgファイルのJAVA_OPTIONSまたはJAVA_SERVICE_EXTRA_OPTIONSでのみ設定されます。 |
-install |
* ランチャによってWindowsサービスとしてみなされるJavaアプリケーションをインストールするために使用されます。 |
-install_autostart |
* -installオプションと似ていますが、このオプションは、サーバーの起動時に起動するアプリケーションをインストールします。 |
-uninstall |
* ランチャによってWindowsサービスとしてみなされるJavaアプリケーションをアンインストールするために使用されます。 |
-remove |
* -uninstallと同じです。 |
-dependent service-name |
* Windowsサービスが、service-nameサービスも実行されているかどうかに依存するようにします。
このコマンドは、サービスごとに依存コールを行う場合に便利です。 たとえば、コンテンツ・サーバーの起動前にデータベースが起動されるようにする場合、コンテンツ・サーバーの起動がデータベースの起動に依存するように指定できます。 |
-dependent user password |
* -installとともに使用され、userによって指定されたユーザーの資格証明とパスワードpasswordを使用してサービスをインストールします。
このコマンドは、資格証明に関係なくユーザーをチェックしますが、サービスをインストールしないことがあります。自動起動によってサービスが自動的に実行されるように、ユーザーの資格証明をサービスにまで拡張する必要があります。 Inbound Refineryなどの特定のサービスには、サービスがより高い権限で実行されるようにするために最後のフラグが必要です。ユーザー名は、一般的なMicrosoft形式であるDOMAIN\Userにする必要があります。ユーザーがパスワードを変更すると、サービスは、ログインできなくなるため、実行されません。 |
-help |
ランチャの使用に関する詳細な情報を表示します。 |
-version |
ランチャのバージョン番号を表示して終了します。 |
-asuser user password |
* インストール時に、指定されたpasswordを持つ指定されたuserとしてサービスをインストールするために使用されます。 |
-exec path _name |
argv[0]の設定をオーバーライドします。シンボリック・リンクのターゲットはソースを認識しないため、ターゲットのpath_nameを指定するためにLauncher.shによって使用されます。 |
-cfg configfilename |
計算される設定を特定する前に読み取る、追加の構成ファイルを指定します。 |
-idcServiceName servicename |
* Windowsサービスの名前を指定します。これは、(たとえば、インストール・ディレクトリ全体が削除された場合に)-removeとともに使用して、コンテンツ・サーバーのランチャを使用せずに別のコンテンツ・サーバー・サービスをアンインストールできます。 |
|
ヒント: クラスパスをカスタマイズして、Oracle.dllファイルをロードするようにシステム・パスを変更するには、次のようにパスを設定します。
IDC_LIBRARY_PATH_customfiles=/path-to-customfiles カスタムの共有オブジェクトおよび |
カスタムの.dllファイルをロードする場合は、それらをIdcHomeDir/native/win32/libディレクトリに配置します。
リモートでサービスを使用するには、リモート・システムに次のファイルが必要です。
DomainHome/ucm/cs/bin/IdcCommand.exe
DomainHome/ucm/cs/bin/intradoc.cfg (Oracle WebCenter Content Server上のファイルと同じ)
IntradocDir/config/config.cfg
さらに、リモート・システム上のconfig.cfgファイルの#Additional Variablesセクションに、次の構成エントリを定義する必要があります。
IntradocServerPort=4444
IntradocServerHostName=IP or DNS
