Axisシステム統合ガイド

  Logging/Tracing
  Configuration
  Handlers
  Internationalization
  Performance Monitoring
  Encoding
  WSDL Parser and Code Generator Framework --> 目次

はじめに

アーキテクチャガイドには、読者に有用な基礎情報があるかもしれません。

プラグイン可能なAPI

コンポーネント

一般的な戦略

• コンポーネントインタフェースの実装を開発します。

 
• サービス定義ファイルを生成するか(望ましい)、システムプロパティを設定することによって、実装クラスをAXISへ定義します。
  
  
  • 望ましい: サービス定義ファイルを生成するためには:
  • サービス定義ファイルの名前は、サービスを実装/継承するインタフェースや抽象クラスから決められる:
          /META-INF/services/<コンポーネントパッケージ>.<インタフェース名>.
  • サービス定義ファイル自体によって、完全修飾されたクラス名を行に設定する。
  
  
  • システムプロパティを設定:
    • システムプロパティ名は、インタフェース名です。
    • システムプロパティ値は、実装名です。
    • オプションのシステムプロパティ名(以下のテーブルを参照)も使用されるかもしれません。
    
     
    • 全てのアプリケーションに渡る指示を強要するため、特にJ2EEやその他のアプリケーションホスト環境では、システムプロパティの設定は望まれません。これは、適切な振る舞いかもしれないし、そうでないかもしれません。これを行うと、実行時のWebアプリケーションの内部で行われることは決してありません。
  
  
• Package the implementation class and, if used, the service definition file in a JAR file and/or place it where it can be picked up by a class loader (CLASSPATH).

Example 1

• An implementation of the Compiler interface is already provided for the Jikes compiler.

 
• Create the service definition file named:
        /META-INF/services/org.apache.axis.components.compiler.Compiler

 
• Add the following line to the service definition file:
        org.apache.axis.components.compiler.Jikes

 
• Since org.apache.axis.components.compiler.Jikes is packaged with AXIS, all that needs to be done is to ensure that the service definition file is loadable by a class loader.

Example 2

• Provide an implementation of the SocketFactory interface, for example your.package.YourSocketFactory

 
• Set the system property named
        org.apache.axis.components.net.SocketFactory
  to the value
        your.package.YourSocketFactory
  

  This can be done by using the JVM commandline
        -Dorg.apache.axis.components.net.SocketFactory=your.package.YourSocketFactory
   

• Ensure that the implementation class is loadable by a class loader.

Reference

• 正当化/原理的説明 - なぜこのプラグポイントが必要なのか？仕様に準拠しているか？
• インタフェース
• メカニズム
• ライフサイクル
• 例外ハンドリング - 一般的に、プラグインは例外をスローすべきではありません - ランタイムは無視するのか？ログは？)
• マルチスレッドはサポートしているか？すなわち、同期化が必要なのか？
• 設定/再設定
• プラグインされない場合のデフォルトの振る舞い。
• サンプル

ロギング/トレーシング

正当化/原理的説明

統合

• org.apache.commons.logging.Log

Logインタフェースは、ログに対してログ/トレースメッセージを書くのに使用される次のメソッドを定義します：

log.fatal(Object message);
log.fatal(Object message, Throwable t);
log.error(Object message);
log.error(Object message, Throwable t);
log.warn(Object message);
log.warn(Object message, Throwable t);
log.info(Object message);
log.info(Object message, Throwable t);
log.debug(Object message);
log.debug(Object message, Throwable t);
log.trace(Object message);
log.trace(Object message, Throwable t);
 
log.isFatalEnabled();
log.isErrorEnabled();
log.isWarnEnabled();
log.isInfoEnabled();
log.isDebugEnabled();
log.isTraceEnabled();


これらのメソッドの意味は、メッセージの重要度の高い方から低い方に対して、以下が期待されます：

• fatal - コンソールとシステムログへロギングされると思われます。
• error - コンソールとシステムログへロギングされると思われます。
• warn - コンソールとシステムログへロギングされると思われます。
• info - コンソールとシステムログへロギングされると思われます。
• debug - 必要であれば、システムログへログ出力されます。
• trace - 必要であれば、システムログへログ出力されます。

 

• org.apache.commons.logging.LogFactory

必要であれば、org.apache.commons.logging.LogFactoryインタフェースのデフォルト実装をオーバライドでき、JDK 1.3サービスプロバイダ発見処理にアプリケーションのニーズを指定するLogFactoryを位置付け、生成します。詳細は、LogFactoryImpl.javaのJavadocを参照して下さい。

メカニズム

• ライフサイクル

JCLのLogFactory実装は、ロギングツールキットへの接続/切断や、ロギングツールキットのインスタンス化/初期化/破棄の責任を負っているかもしれません。
 

• 例外ハンドリング

JCLのLogインタフェースは、操作される任意の例外を指定せず、実装は、任意の例外をキャッチするかもしれません。
 

• マルチスレッド

JCLのLogやLogFactoryの実装は、ロギングツールキットで要求される任意の同期化を保証しなければなりません。

ロガーの設定

• Log

JCLで提供されているデフォルトのLogFactoryは、org.apache.commons.logging.Logプロパティを設定することによって、org.apache.commons.logging.Logインタフェースの特定の実装をインスタンス化するために設定できます。このプロパティは、システムプロパティか、CLASSPATHに含まれなければならないcommons-logging.propertiesファイルで指定できます。
 

• プラグインされない場合のデフォルトのロガー

Jakarta Commons Logging SPIは、org.apache.commons.logging.Logシステムプロパティで指定されるorg.apache.commons.logging.Logインタフェースを使用します。プロパティが設定されないか、クラスが利用可能でない場合、JCLは、以下の優先順位のツールキットのためにCLASSPATHを検索することによってデフォルトのロギングキットのアクセスを提供します：
• Log4J
• JDK 1.4
• JCL SimpleLog

設定

• 正当化/原理的説明 - なぜこのプラグポイントが必要なのか？仕様に準拠しているか？
• インタフェース
• メカニズム
• ライフサイクル
• 例外ハンドリング - 一般的に、プラグインは例外をスローすべきではありません - ランタイムは無視するのか？ログは？)
• マルチスレッドはサポートしているか？すなわち、同期化が必要なのか？
• 設定/再設定
• プラグインされない場合のデフォルトの振る舞い。
• サンプル

ハンドラ

• 正当化/原理的説明 - なぜこのプラグポイントが必要なのか？仕様に準拠しているか？
• インタフェース
• メカニズム
• ライフサイクル
• 例外ハンドリング - 一般的に、プラグインは例外をスローすべきではありません - ランタイムは無視するのか？ログは？)
• マルチスレッドはサポートしているか？すなわち、同期化が必要なのか？
• 設定/再設定
• プラグインされない場合のデフォルトの振る舞い。
• サンプル

国際化

• 正当化/原理的説明

英語圏以外の読者がAXISを快適に使用できるように、AXISで使用される文字列を変換できるメカニズムを提供しています。AXISでは、任意の翻訳を提供しません。単に、トランスレータが翻訳を簡単にプラグインできる方法を提供するだけです。
 
• インタフェース

AXISは、標準のJava国際化クラスを使用しています： PropertyResourceBundle。このクラスを使いやすくするために、リソースバンドルのメッセージを取得するために使用されるJavaUtilsに多くのメソッドがあります。

public static java.util.ResourceBundle getMessageResourceBundle();

public static String getMessage(String key) throws java.util.MissingResourceException;

public static String getMessage(String key, String var) throws java.util.MissingResourceException;

public static String getMessage(String key, String var1, String var2) throws java.util.MissingResourceException;

public static String getMessage(String key, String[] vars) throws java.util.MissingResourceException;

AXISプログラマは、JavaUtils.getMessageResourceBundleを直接呼ぶことによりリソースバンドルを使用することができますが、getMessageメソッドは、2つの理由の代わりに使用されます：
 

1. ショートカットです。
JavaUtils.getMessage("myMsg00");
は、以下を呼ぶよりも綺麗です。
JavaUtils.getMessageResourceBundle().getString("myMsg00");
2. getMessageメソッドは、メッセージを可変にできます。

getMessageメソッド

変数がないメッセージの場合、
myMsg00=This is a string.
単に以下を呼びます
JavaUtils.getMessage("myMsg00");


変数があるメッセージの場合、"{X}"シンタックスを使用します。ここで、Xは、0から始まる変数の番号です。例えば：

myMsg00=My {0} is {1}.
となっていた場合、
JavaUtils.getMessage("myMsg00", "name", "Russell");
を呼んだ結果の文字列は、"My name is Russell."となります。

String配列のgetMessageを呼ぶこともできます：

JavaUtils.getMessage("myMsg00", new String[] {"name", "Russell"});


String配列版のgetMessageは全てに適用できますが、ほとんどのメッセージの変数は0、1、もしくは、2つなので、その他のgetMessageメソッドは、String配列版の複雑さを避けるための利便性として提供されています。

リソースが見つからない場合、getMessageメソッドは、MissingResourceExceptionをスローすることに注意して下さい。そして、引数の数よりも{X}エントリが多い場合、ParseExceptionがスローされます。これらの例外は、RuntimeExceptionなので、呼び出し元は明示的にキャッチすべきではありません。

リソースバンドルのプロパティファイルは、org/apache/axis/utils/resources.propertiesです。
 

• メカニズム

Java国際化メカニズム - すなわち、プロパティファイルによって返されるResourceBundle - および、java.text.MessageFormatクラスは、我々のニーズに十分です。

プロパティファイルのエントリは、パターンに従わなければなりません：<string><2桁の接尾辞>。

プロパティファイル内のエントリは、キーがアルファベット順になっている必要があります。

プロパティファイル内のエントリは、変更されることがないようにしなければなりません。コードの変更によりメッセージの変更が必要な場合、既存のメッセージは変更しません。代わりに新しいエントリを生成し、2桁の接尾辞を増やします。これは、2つの理由があります。1.他の箇所でメッセージが使用されているか分からないため。2.トランスレータは新しい文字列のみ知っており、変換するため。この制限がないと、トランスレータに常に変換するためのプロパティファイルが与えられ、常に全ての文字列を変換しなければならなくなります。

 
時には、古いデータのプロパティファイルをトリムしたくなるかもしれませんが、これはメジャーリリースでのみ行われます。
 
• デフォルトの振る舞い

与えられたロケールに対する変換されたファイルが存在しない際に何が起きるかという、デフォルトの振る舞いは、英語のプロパティファイルにたよるためです。そのファイルが存在しない場合(何かが重大に悪くなければありそうもないが)、AXISは、英語の理由のメッセージを持つ例外を投げます。
 
• サンプル

org.apache.axis.client.Call.invokeには、以下の文があります：

        if ( operationName == null )
            throw new AxisFault( "No operation name specified" );

org/apache/axis/utils/resources.propertiesへエントリを追加しなければならないでしょう。例えば：

noOperation=No operation name specified.

そして、読み込むコードを変更します：

        if ( operationName == null )
            throw new AxisFault(JavaUtils.getMessage("noOperation"));

パフォーマンス監視

• 正当化/原理的説明 - なぜこのプラグポイントが必要なのか？仕様に準拠しているか？
• インタフェース
• メカニズム
• ライフサイクル
• 例外ハンドリング - 一般的に、プラグインは例外をスローすべきではありません - ランタイムは無視するのか？ログは？)
• マルチスレッドはサポートしているか？すなわち、同期化が必要なのか？
• 設定/再設定
• プラグインされない場合のデフォルトの振る舞い。
• サンプル

エンコーディング

• 正当化/原理的説明 - なぜこのプラグポイントが必要なのか？仕様に準拠しているか？
• インタフェース
• メカニズム
• ライフサイクル
• 例外ハンドリング - 一般的に、プラグインは例外をスローすべきではありません - ランタイムは無視するのか？ログは？)
• マルチスレッドはサポートしているか？すなわち、同期化が必要なのか？
• 設定/再設定
• プラグインされない場合のデフォルトの振る舞い。
• サンプル

本ドキュメントは、日本Apache XMLプロジェクト(石神覚司)により翻訳されました。
翻訳に対するコメントは、jaxmldev@xml.gr.jpに送って下さい。