Axis開発者ガイド

目次

はじめに

一般的ガイドライン

• Axisに特有の情報(CVSリポジトリへのアクセス、メーリングリストの情報など)は、Axisホームページにあります。
• Axisは、Jakartaプロジェクトガイドラインを利用しています。
• コードの変更は、「Javaプログラミング言語のコーディング規約」に適合するべきです。
• Axis Bugzillaにあるバグを直す時は、CVSのコミット時のメッセージにそのバグへのリンクを含めて下さい。
• 公開されているAxisインタフェースと互換性のない変更は、可能な限り避けられるべきです。変更が必要な場合、例えばメンテナンスや、Axisの全体的なモジュール性を改善するためであったりする場合は、ユーザへの影響を考慮されなければならず、好ましくは文書に記されなければなりません。
• もしあなたが相互運用性に影響するかもしれない大きな変更を行おうとしている場合、あなたの変更がさらなる互換運用性の破綻を招かないことを保証するために、echotest2 round 2 interop testを行って下さい。さらに、client_deploy.wsddも必要です。こちらには、夜間相互運用性テスト結果があります。

• ant - Javaベースのビルドツール。注意：バージョン1.5以上が必要
• junit - テスティングパッケージ
• xerces - XMLプロセッサ
• J2SDK 1.3.1以降のインストール

Axisのjarファイルは、xml-axis/java/build/libディレクトリにビルドされます。以下は、私がコード開発する際に使用するCLASSPATH例です：

D:\\xerces\\xerces-1_4_2\\xerces.jar
G:\\junit3.7\\junit.jar
G:\\xml-axis\\java\\build\\lib\\commons-discovery.jar
G:\\xml-axis\\java\\build\\lib\\commons-logging.jar
G:\\xml-axis\\java\\build\\lib\\wsdl4j.jar
G:\\xml-axis\\java\\build\\lib\\axis.jar
G:\\xml-axis\\java\\build\\lib\\log4j-1.2.4.jar
G:\\xml-axis\\java\\build\\classes

-Dhttp.proxyHost=proxy.somewhere.com -Dhttp.proxyPort=80 -Dhttp.nonProxyHosts="localhost"

プラグイン可能なコンポーネント

発見

org.apache.axis.components.<componentType>.<factoryClassName>

org.apache.axis.components.imageパッケージは、AXISで使用される異なる画像ツールにおけるファクトリとサポートするクラスの両方を説明しています。これは、外部ツール使用するプラグイン可能なコンポーネントの表現で、AXISの最小要件を満たすために制限されたインタフェースのみを提供するために、'薄い'ラッパをAXISに隠して分離します。これは、将来のデザイナや実装者に、これらのツールにおけるAXIS固有の要件の明示的な理解を得ることを許します。

ロギング/トレーシング

Logger SPIの使用

JavaクラスからJCL SPIを使うためには、以下のimport文を使います：

import org.apache.commons.logging.Log;
import org.apache.axis.components.logger.LogFactory;
 

public class CLASS
{
   private static Log log = LogFactory.getLog(CLASS.class);
   ...
 

メッセージは、priorityに対応するメソッドを呼び出すことにより、logのようなloggerにログ出力されます。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 - AXISサーバが終了してしまう原因となる重大なエラー。これらはすぐにコンソールに現れることが期待され、国際化されていなければなりません。

 
• error - その他の実行時エラーか予期しない状況。これらはすぐにコンソールに現れることが期待され、国際化されていなければなりません。

 
• warn - 推奨されないAPIの使用、APIの下手な使用、たいていのエラー、「間違っている」わけではないが、好ましくないか予期しないその他の実行時の状況。これらはすぐにコンソールに現れることが期待され、国際化されていなければなりません。

 
• info - 興味深い実行時のイベント(起動/停止)。これらはすぐにコンソールに現れることが期待され、国際化されていなければなりません。

 
• debug - システムを通した流れに関する詳細情報。これらは、ログにのみ書かれることが期待されます。これらは問題のない限り、国際化されている必要はありません。

 
• trace - さらに詳細な情報。ログにのみ書かれることが期待されます。これらは問題のない限り、国際化されている必要はありません。

Loggerの設定

JCLの振る舞いの設定は、使用するロギングツールキットに完全に依存します。JCL SPI(と、AXIS)は、Log4Jが(CLASSPATH内で)有効であれば、デフォルトでそれを使用します。

Log4J

システムプロパティやプロパティファイルを使用してLog4Jを設定します：

• log4j.configuration=log4j.properties

  Log4Jの設定ファイルの名前を指定するために、このシステムプロパティを使用します。指定されない場合は、log4j.propertiesがデフォルトの設定ファイルとなります。log4j.propertiesファイルは、axis.jarで提供されています。

  このプロパティファイルは、同名のファイルを置くことによって、CLASSPATHでaxis.jarの前に来るようにすることで上書きすることができます。しかし、正確な振る舞いは、その時に使用しているクラスローダに依存するので、この方法は、お勧めではありません。

  プロパティファイルを上書きする安全な方法は、axis.jar内のプロパティファイルを置き換えることです。しかし、特に不必要なログ項目を除去するデバッグセッション中にプロパティを微調整したい場合などでは、この方法は非常に不便です。もっと便利な方法は、プロパティファイルの指定に絶対ファイルパスを使用することです。この方法では、Webアプリケーションやクラスローダのプロパティファイルであっても無視します。そのため、例えばLinuxでは、システムプロパティを指定しまう：

  log4j.configuration=file:/home/fred/log4j.props
  

• log4j.debug log4jが設定をどこから取得するかを設定する良い方法は、このシステムプロパティを設定することで、標準出力でメッセージを見ます。
   
• log4j.rootCategory=priority [, appender]* デフォルト(ルート)ロガーの優先度を設定します。
   
• log4j.logger.logger.name=priority 名前付きのロガーとそのロガーよりも階層的に下に位置する全てのロガーの優先度を設定します。 logger.nameは、LogFactory.getLog(logger.name)のパラメータに対応し、ロガーのインスタンスを生成するために使用されます。優先度は、DEBUG、INFO、WARN、ERROR、FATALのいずれかです。

  Log4Jは、階層的な名前を理解し、パッケージや高レベルの修飾子による制御を可能にします。log4j.logger.org.apache.axis.encoding=DEBUGは、org.apache.axis.encodingとorg.apache.axis.encoding.serの両方にある全てのクラスで、デバッグメッセージを有効にします。同様に、log4j.logger.org.apache.axis=DEBUGの設定は、全てのAXISのクラスに対してデバッグメッセージを有効にしますが、他のJakartaプロジェクトのものについてはそれを行いません。

  設定の組み合わせにより、興味のあるログイベントのみを表示し、その他を非表示にすることができます。例えば、以下の組み合わせでは、

  log4j.logger.org.apache.axis=DEBUG 
  log4j.logger.org.apache.axis.encoding=INFO
  log4j.logger.org.apache.axis.utils=INFO
  log4j.logger.org.apache.axis.message=INFO
  

  1回の要求で生成されるログ項目数を管理可能な数へ減らします。
   
• log4j.appender.appender.Threshold=priority Log4Jのappenderは、異なる出力装置に対応します：コンソール、ファイル、ソケットなど。appenderのしきい値がメッセージの優先度以下なら、メッセージはそのappenderによって出力されます。これはログ出力レベルによって、別のログ出力先にすることが可能になります。

  例えば：INFO(とそれよりも重要な)レベルだけをコンソールに出力しながら、DEBUG(とそれよりも重要な)レベルの情報をログファイルに出力することが可能です。

設定プロパティ

この中心点アクセスの使用により、1つのJVMで複数のAXISエンジンを良好にサポートするように、グローバルな設定システムを再設計することができます。

例外ハンドリング

これらのガイドラインは、基本的にプログラミング言語に依存しません。これらは経験を元にしていますが、長年に渡って無垢な人(?)に目を向けさせるために、適切なクレジットはScott MeyersによるMore Effective C++にしておいて下さい。

最後に、これらはガイドラインです。これらのガイドラインに対する例外があった際は常に、(これらのガイドラインどおり)質問される全ての事項がコード内にコメント形式で書かれています。

• 主要ルール: 何をすべきか分かっている場合だけ例外をキャッチすること

コードで例外をキャッチする場合、プログラムのその位置で何を処理しているのかを分かっているべきです。このルールにおける任意の例外は、良好な理由と共に文書化されていなければなりません。コードレビュー者が、彼らのコンドルのくちばしで突かれることになります。

このルールに対するいくつかの推論があります。

• インナコード内で特定の例外を操作

インナコードは、プログラム内部の深いコードです。例外が解決でき、正常処理がコードへ復帰できる場合に限り、このようなコードは、特定の例外をキャッチするか、(例外階層の親で)例外の分類をすべきです。このソートの振る舞いは、非対話式コードと対話式ツールで非常に異なるかもしれないので注意して下さい。

• 制御の最も外側の処理で全ての例外をキャッチ

最終的に、全ての例外は、1レベルか否かで扱われなければなりません。コマンドラインツールでは、コンポーネントへの入口点です。AXISでは、AxisServletと同等のものです。

内部的に解決可能な特定の例外をキャッチした後、最も外側のコードは、全ての内部的に生成された例外がキャッチされ操作されることを保証しなければなりません。一般的にできるとすればその程度で、少なくともコードは、例外をログ出力すべきです。ロギングについてさらに言えば、AXISサーバは、AxisFaults内に全てのこのような例外をラップし、クライアントコードへそれを返します。

これは、主要ルールに反すると思われるかもしれませんが、実際には、AXISがこの型の例外で何をすれば良いのか分からないと言えます：潔く終了するくらいです。

• 例外をキャッチしてログ出力

例外がコンポーネント境界(クライアント/サーバ、システム/業務といったロジック)を越える場合、例外は投げるコンポーネントによってキャッチされ、ログ出力されなければなりません。例外は再度投げられるか、以下に記載されているようにラップされるかもしれません。

疑わしい場合は、例外をログ出力します。

• キャッチとスロー

例外がキャッチされて(未解決で)再度投げられると、例外のロギングは、コード記述者とレビュー者に委ねられます。任意のコメントがログ出力されると、例外もログ出力されます。

疑わしい場合は、例外と例外の完全な文脈を特定するのみ役立つ関連するローカル情報をログ出力します。

例外が解決できなかったり、不当なエラーとして知られている場合、エラー(log.error())として例外をログ出力し、その他の場合は、情報レベル(log.info())としてログ出力します。

• キャッチとラップ

例外eがキャッチされ、新しい例外wにラップされた場合、wを投げる前に例外eをログ出力します。

例外が解決できなかったり、不当なエラーとして知られている場合、エラー(log.error())として例外をログ出力し、その他の場合は、情報レベル(log.info())としてログ出力します。

• キャッチと解決

例外eがキャッチされ、解決された場合、例外のロギングは、コード記述者とレビュー者に委ねられます。任意のコメントがログ出力されると、例外もログ出力されます。

多くの場合では、例外を無視することが適切かもしれないことに注意して下さい。

• コンポーネント境界の考慮

このガイドラインには、複数の解釈があります。一方で、これは、業務ロジックはシステムロジックから分離すべきであることを意味し、他方で、クライアントは、サーバの実装詳細に制限された公開/可視性を持っています - 特にサーバが外部パーティに公開された場合。これは、良好に設計されたサーバインタフェースであることを暗に意味します。

• 業務ロジックからシステムロジックを分離

AXISランタイムによって生成された例外は、可能であれば、AXISランタイム内で操作されるべきです。最悪の場合、例外の詳細は、AXISランタイムによってログ出力され、一般的に記述された例外が、ビジネスロジックで発生します。

業務ロジックで発生した例外(これには、サーバとAXISハンドラを含みます)は、クライアントコードへ伝達されなければなりません。

• ユーザコードからのシステムコードの保護

制御できないユーザ業務ロジックからAXISランタイムを保護します。AXISでは、動的に設定可能なhandlers、providers、および、その他のユーザが制御可能な接続位置は、catch(Exception ...)によって保護されていなければなりません。ユーザコードによって生成され、システムコードによってキャッチされた例外は、以下を行うべきです：
• ログ出力
• クライアントプログラムへの伝達

• クライアントからのサーバ内の可視性の分離

特定の例外は、サーバサイドでログ出力され、さらに一般的な例外はクライアントへ投げられるべきです。これは、サーバの性質(ハンドラ、プロバイダなど)の手がかりのクライアントコードへの漏洩を防ぎます。考慮すべきAXISコンポーネント境界は、以下です：
• クライアントコードe <--> AxisClient
• AxisClient <--> AxisServlet (AxisServer/AxisEngine)
• AxisServer/AxisEngine <--> Webサービス

• コンストラクタ内での例外のスロー

コンストラクタ内で例外を投げる前に、オブジェクトによって所有される任意のリソースがクリーンアップされていることを保証します。リソースを握ったオブジェクトに対して、これは、コンストラクタ内で呼び出されたメソッドによって投げられた全ての例外のキャッチ、クリーンアップ、例外を再度投げることを要求します。

コンパイルと実行

• compile -> ソースをコンパイルし、xml-axis/java/build/lib/axis.jarを生成
• javadocs -> xml-axis/java/build/javadocsにJavadocを生成
• functional-tests -> コンパイルして機能テストを実行
• all-tests -> コンパイルして全てのテストを実行

 

cd xml-axis/java
ant compile

cd xml-axis/java
ant functional-tests

新しいコードを挿入する前に、ant functional-testsとant all-testsを実行して下さい。

国際化

開発者ガイドライン

1. テキスト文字列は、プロパティとしてresource.propertiesファイル(xml-axis/java/src/org/apache/axis/i18n/resource.properties)に追加されるべきです。いくつかのユーティリティアプリケーション(例えば、tcpmon)は、独自のリソースプロパティファイル(tcpmon.properties)を持っていることに注意して下さい。

 
2. resource.propertiesファイルは、翻訳と使用方法の指示を含んでいます。 メッセージリソースファイルの項目は、<key>=<message>形式です。 以下は、メッセージの例です：

sample00=My name is {0}, and my title is {1}.
 

1. sample00は、コードがこのメッセージにアクセスするために使用するキーです。
2. = 以降のテキストはメッセージテキストです。
3. {number}構文は、挿入される場所を定義します。

3. コードは、スタティックメソッドorg.apache.axis.i18n.Messages.getMessageを使用して、テキストを取得して挿入を追加するべきです。使用例は以下です：

Messages.getMessage("sample00", "Rich Scheuerle", "Software Developer");
 

4. プロパティファイルの全てのキーは、<string><2-digit-suffix>構文を使用するべきです。

 
1. プロパティファイルのメッセージテキストを変更してはいけません。メッセージはコード内の複数個所で使用される場合があります。また、翻訳は新しいキーにおいてのみ行われます。

  コードの変更がメッセージの変更を必要とする場合は、数字2桁のサフィックスを増加させた新規項目を作成します。
 
2. 全ての新規項目は、翻訳を簡単にするためにファイルの最後に置かれるべきです。

 
3. 古いデータのプロパティファイルを削除したい場合があるかもしれませんが、これはメジャーリリースでのみ行われるべきです。

実例

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

項目をorg/apache/axis/i18n/resource.propertiesに追加します：

       noOperation=No operation name specified.

読み込むためにコードを変更します：

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

インタフェース

public static java.util.ResourceBundle getResourceBundle();

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プログラマは、Messages.getResourceBundle()を呼び出すことによってリソースバンドルを直接操作することができますが、2つの理由からgetMessage()メソッドを代わりに使用します：

1. ショートカットです。
   Messages.getResourceBundle().getString("myMsg00");
   を呼び出すよりも
   Messages.getMessage("myMsg00");
   を呼び出す方が簡潔なため。
   
2. getMessageメソッドは、メッセージに変数を埋め込むことができるだめ。

getMessageメソッド

myMsg00=This is a string.

Messages.getMessage("myMsg00");

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

Messages.getMessage("myMsg00","name", "Russell");

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

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

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

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

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

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

メッセージファイルの拡張

テストケースの追加

テストとサンプル構造も参照して下さい。

Axisを変更した場合、その変更を使用するテストを追加して下さい。それはなぜでしょう?

• テストは、あなたの新しいコードが動作するか検証します。
• テストは、将来のコード変更によって生じるバグからあなたの変更を守ります。
• テストは、Axisの機能のユーザへの例となります。
• テストは、新しい開発の開始地点として使用されることもできます。

いくつかの一般的な原則：

• テストは、自己説明的であるべきです。
• テストは、多量の出力を生成するべきではありません。
• テストは、既存のJUnitのフレームワークへフックするべきです。
• 各テストや関連するテストのグループは、xml-axis/java/testディレクトリ内に独自ディレクトリを持つべきです。

テストをビルドする1つの方法は、既存のテストをカットアンドペーストして、あなたの要求に合うようにテストを変更することです。このアプローチはテスト種類の増加に従い、複雑さを増します。

参照するための"非WSDL"の良好なテストは、test/saajです。

1. xml-axis/java/test/wsdl/sequenceディレクトリを生成。


2. Webサービスを定義しているSequenceTest.wsdlを生成。


3. Javaファイルを生成するためにWsdl2javaのエミッタを実行：

java org.apache.axis.wsdl.Wsdl2java -t -s SequenceTest.wsdl


1. -tオプションは、テストハーネスへのフックとなる*TestCase.javaファイルを、エミッタに生成させます。このファイルは変更を追加することなく実行可能です。*TestCase.javaファイルを、あなたのWSDLファイルと同じディレクトリにコピーして下さい。(理想的には、あなたのディレクトリには変更されたJavaファイルのみが必要となります。したがって、このファイルは必要とされませんが、テストケースを実行するためには、あなたの<wsdl2java ...>節を変更することを確認して下さい(以下で説明します)。
2. -sオプションは、エミッタに*SOAPBindingImpl.javaを生成させます。このJavaファイルはそのサービスのための空のメソッドを含みます。あなたは多分、あなた独自のロジックでそれらを埋めたいでしょう。あなたのWSDLファイルと同じディレクトリに、*SOAPBindingImpl.javaファイルをコピーして下さい。(このJavaファイルに変更が必要ない場合は、それを保存する必要はありません。しかし、<wsdl2java ...>節がスケルトンを生成することを確認する必要があります)。
3. 変更を必要としない全てのJavaファイルを削除します。したがって、あなたのディレクトリには3つのファイルがあることになります(WSDLファイル、*TestCase.java、*SOAPBindingImpl.java)。私のシーケンステストでは、私が必要とするいくつかの追加ロジックのために、その他のファイルがあります。


4. test/wsdl/sequence/build.xmlファイルは、このテストのビルドを制御します。"compile"ターゲットを探して下さい。Wsdl2javaコードを実行する節を追加します。test/wsdl/roundtrip/build.xmlファイルを参照すると良いでしょう(wsdl2javaやjava2wsdlを多く呼び出しています)。SequenceTestのためのものを示します：

    <!-- Sequence Test -->
    <wsdl2java url="${axis.home}/test/wsdl/sequence/SequenceTest.wsdl"
               output="${axis.home}/build/work"
               deployscope="session"
               skeleton="yes"
               messagecontext="no"
               noimports="no"
               verbose="no"
               testcase="no">
        <mapping namespace="urn:SequenceTest2" package="test.wsdl.sequence"/>
    </wsdl2java>
新しいbuild.xmlファイル内のrunターゲットが可能です。execute-Componentターゲットと(直ぐに導入するなら)execute-Simple-Testターゲットから選択する必要があります。execute-Componentは、テストを実行する前にTCPサーバとHTTPサーバをセットアップし、必要となるサービスや配備を同様に操作します。execute-Simple-testは、単純に生のテストクラスファイルを呼び出します。



5. 終わりです。検証するためにant functional-tests を実行して下さい。あなたのテストをチェックインして下さい。

 

テスト構造

Axis 1.0 RC1以降で、"コンポーネント化された"テスト構造へと移行されました。1つの高次レベルの大きな再帰的関数を持つ代わりに、test/**配下やsamples/**配下の末端レベルに小さくて単純な"コンポーネント"build.xmlファイルがあります。

これらの"コンポーネント"ファイルは、共通のレイアウトを持ちます。主なターゲットには、以下があります：

• clean - build展開先をリセット
• compile - javac、wsdl2java、java2wsdlの指示
• run - テストの"実行"

"サンプル"テストのXMLファイルは、test/templateTestにあります。

ソースコードチェックの追加

規約を正規表現として表現できる場合、java/test/utils/TestSrcContent.javaを更新することでビルド時にチェックを強制することができます。

必要なことの全ては、パターンにスタティックなFileNameContentPattern配列を追加することです。各パターンには、3つのパラメータがあります：

1. 確認するファイル名の適合させるパターン
2. 選択されたファイルを検索するためのパターン
3. パターンを使用するかを指定するboolean(一般的に、指定しない場合はfalseになります)

正規表現記法の分かりやすい要約は、Jakarta OROのjavadocで提供されています。

デバッグ

機能テストをモニタするためのtcpmonの使用

functional-tests(あるいは、all-tests)を実行している間に、メッセージをモニタする簡単な方法を示します。
tcpmonがポート8080をリッスンするようにして開始し、異なるポートへフォワードします。

java org.apache.axis.utils.tcpmon 8080 localhost 8011

ant functional-tests -Dtest.functional.SimpleAxisPort=8011 -Dtest.functional.fail=no

tcpmonは、AXISユーザガイドに詳しく説明されています。

機能テストをモニタするためのSOAPモニタの使用

(Tomcatなど)Webアプリケーションサーバを使用するWebアプリケーションとして実行しているコードをデバッグする際、SOAPの要求メッセージと応答メッセージを見るためのSOAPモニタユーティリティも使用することができます。
WebブラウザのウィンドウでSOAPモニタアプレットをロードすることによってSOAPモニタユーティリティが開始されます：

http://localhost:<port>/axis/SOAPMonitor

SOAPモニタの詳細は、AXISユーザガイドで説明されています。

単一機能テストの実行

java org.apache.axis.transport.http.SimpleAxisServer -p 8080

java org.apache.axis.client.AdminClient deploy.wsdd

java junit.swingui.TestRunner -noloading test.wsdl.multithread.MultithreadTestCase

デバッグ出力の作動

• Log4Jプロパティのオーバライド

log4j.propertiesファイルは、適度なデフォルト設定でaxis.jarにパッケージ化されています。次の項目は、これらの設定を変更することを仮定しています。複数のオプションが開発者に公開されており、それらのほとんどはaxis.jarからlog4j.propertiesを抽出して、適切に変更します。

• コマンドラインかスクリプトファイルからjavaプログラムをビルドして実行する場合、JVMのオプションを含めます。-Dlog4j.configuration=yourConfigFile
• CLASSPATHの中で、あなたが使うバージョンのlog4j.propertiesが、axis.jarよりも前に来るように設定します。
• antを使用してあなたのプログラムをビルドして実行する場合(これはAXISのビルドとそのテストの実行を含みます)、環境変数ANT_OPTSに-Dlog4j.configuration=yourConfigFileを設定します。
• AXISをビルドする場合、src/log4j.propertiesを直接変更できます。あなたの変更をコミットしないで下さい。



• 全てのデバッグ出力の作動

• log4j.rootCategoryの優先度をDEBUGに設定します。
• appenderの優先度のしきい値をDEBUGに設定します(AXISのlog4j.propertiesファイルは、2つのappenderを定義しています。CONSOLEとLOGFILEです)。



• 選択的なデバッグ出力

• log4j.rootCategoryの優先度をINFO以上に設定します。

• あなたの興味のあるロガーについて、log4j.logger.logger.nameの
• 優先度
をDEBUGにセットします。
• appenderの優先度のしきい値をDEBUGにセットします(AXISのlog4j.propertiesファイルは、2つのappenderを定義しています。CONSOLEとLOGFILEです)。
• 必要以上の情報が出力されている場合、ログ出力からあなたの興味のある情報を抽出するために他のツールを使う必要があります。ログメッセージで適切なキーワードを使用し、grepなどのツールで、それらをログメッセージの中から検索して下さい。

一時出力の記述

開発者は、システムをデバッグしたり解析している際に、System.out.printlnを使用したい思うかもしれません。もしその方法を選んだら、util/TestSrcContentテストを無効にする必要があります。このテストは、System.out.printlnとSystem.err.printlnの回避を強制します。あなたがコードをチェックインして戻す前にそれらの文を削除する必要があることになります。

一方で、我々はあなたに、少し時間を取ってデバッグ文を使うことを強く勧めます：log.debug("reasonably terse and meaningful message")。もし、デバッグメッセージが問題を理解するために有用であれば、将来もあなたや仲間によって有用となるでしょう。

JAX-RPC互換性テストの実行

このキットは、zipファイルを指定ディレクトリに解凍することで利用できます。インストール方法は、docsディレクトリにあるJAX-RPCリリースノート文書に書かれています。Webブラウザでdocsディレクトリ内のindex.htmlファイルを開けば、このキットで供給されている全ての文書の一覧を見ることができます。

このキットには、互換性テストを実行するために使用するJavaTestテストハーネスが含まれていることに注意して下さい。

このテストを実行するための詳細な情報が必要であれば、ここに追加して下さい。

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