Cactus needs to have a few entries set in the web.xml file (redirector definition and mappings mostly). The application to test also needs its own entries. What would be nice would be to be able to use the same web.xml file in the build process for both application testing and deployment to production.

Cactus では web.xml ファイルの中に 2,3 記述する項目を 追加する必要があります。（大抵はリダイレクタの定義とそのマッピング） テストすべきアプリケーションもまたそれ自身の記述項目を持ちます。 アプリケーションのテスト及び本稼動の運用環境の両方の構築プロセスで 同じ web.xml ファイルを使えるようにするには、何か良い 手立てはあるでしょうか。

Here's how I accomplished conditional inclusion of Cactus web.xml configuration. My web.xml file is capable of working standalone without requiring any filtered copy to work. In Ant I'm doing this:

ここに、どのように私が状況も考慮した Cactus の web.xml の設定を 成し遂げたかを示します。 私の web.xml ファイルは実行させるのに別のフィルタリングされた コピーを一切必要とせず、それ単独で動作可能となっています。 Ant で私は以下のようにしています：

<!-- Activate the Cactus web.xml configuration -->
<!-- web.xml での Cactus の 設定を有効にする。 -->
<copy todir="${admin.build.dir}/WEB-INF"
      file="web/admin/WEB-INF/web.xml"
      overwrite="yes">
  <filterset>
    <filter token="start.cactus.config" value="--&gt;" />
    <filter token="end.cactus.config" value="&lt;!--" />
  </filterset>
</copy>

In web.xml I have this:

web.xml では以下のようにしています:

<!-- Cactus configuration
Note: Do not place any XML comments in this Cactus configuration section
(Ant's filtered copy is used to activate this configuration when the test
web application is built)
-->
<!-- Cactus の設定
注意: この Cactus の設定部分の XML のコメントはどれもさわらない事。
(Ant のフィルターコピー機能がテスト時の Web アプリケーションをビルド
する時にこの設定を有効にするのに使われています。)
-->
<!-- Begin Cactus Configuration @start.cactus.config@
<servlet>
  <servlet-name>ServletRedirector</servlet-name>
  <servlet-class>org.apache.cactus.server.ServletTestRedirector</servlet-class>
</servlet>

<servlet>
    <servlet-name>JspRedirector</servlet-name>
    <jsp-file>/somewhere/jspRedirector.jsp</jsp-file>
</servlet>

<servlet-mapping>
    <servlet-name>ServletRedirector</servlet-name>
    <url-pattern>/ServletRedirector/</url-pattern>
</servlet-mapping>

<servlet-mapping>
    <servlet-name>JspRedirector</servlet-name>
    <url-pattern>/JspRedirector/</url-pattern>
</servlet-mapping>

@end.cactus.config@ End Cactus Configuration -->

This exception results when client-side Cactus code attempts to talk to a misconfigured installation of Cactus on the server side. The reason for the obscure exception is this: Cactus makes two requests to the server. In the first, the client-side test runner requests that such-and-such a test be run on the server (an oversimplification, please see: XXXX). Immediately after the response from the server the client code makes a second request, this time for the results of the server-side test. Cactus is supposed to send back a serialized Object containing the results. Cactus then attempts to deserialize this Object from the input stream in the response. If Cactus is installed properly on the server, this process works transparently. If not (for instance the second request does not even arrive at a Cactus redirector) then the response to the second request (which very well may be a 404 or 500 error) will not contain the object that client-cactus expects. This leads to the StreamCorruptedException.

この例外は クライアント側の Cactus のコードがサーバー側で設定に不備 があるままインストールされた Cactus とやり取りしようとした結果です。 この良く分からない例外の理由はこうです：Cactus は二種類のリクエスト をサーバーに送ります。最初は クライアント側で実行中のテストはつまり いわいる test をサーバー上で実行するように要求します。（単純化しす ぎですね。XXXX の部分を見てください）サーバーからレスポンスが返って きてすぐにクライアント側から第二のリクエストが、この時はサーバー側 のテストの結果の為に発せられます。Cactus では シリアライズされたオ ブジェクトにテストの結果を入れて返すようになっています。Cactus は それからレスポンスの入力ストリームからこのオブジェクトをシリアライ スより復元しようとします。もし Cactus が正常にサーバーにインストー ルされているなら、このプロセスは素直に上手く行きます。もしそうで ないなら（例えば２番目のリクエストが Cactus のリダイレクタにすら届 いていないとか。）２番目のリクエストへのレスポンス（多分に 404 か 500 のエラーでしょう。）はクライアント側の Cactus が期待したオブジ ェクトを含んでいません。こうして StreamCorruptedException が発生し ます。

When troubleshooting this error, the most likely prospect is that the requests from client-Cactus are not even reaching server-Cactus. This can happen when the cactus.properties contains a bad entry. For instance, I have run into this problem when building several different testing-applications. I tried to run my tests against http://localhost/webapp1/ServletRedirector/ when I needed to be running against http://localhost/webapp2/ServletRedirector/. This can also happen if your web.xml file contains an error, or does not properly map the URLs contained in cactus.properties to the Cactus redirectors.

このエラートラブル対策時に、最もそれらしく見込みのあるのはクライアント 側の Cactus からのリクエストがサーバー側に届いていない事でしょう。 これは cactus.properties が間違った設定を含んでいる時に 発生します。例えば幾つかの異なったテスト用のアプリケーションを構築し ている時にこの問題にはまってしまいました。正確には http://localhost/webapp2/ServletRedirector/ に対して実行 していなければならないのに、http://localhost/webapp1/ServletRedirector/ に対してテストを実行していたのです。この件はまた、web.xml ファイルに 誤りが含まれている時や cactus.properties に含まれる Cactus のリダイ レクタへの URL が正しくマップされていない場合にも発生する事があります。

A good way to check whether your requests are reaching a Cactus redirector is to manually enter in the URLs for all of the redirectors you use into the navigation bar of your web-browser. Actually the Cactus redirectors provide a URL just for that : http://localhost/webapp/ServletRedirector?Cactus_Service=RUN_TEST (this also works for the other redirectors).

リクエストが Cactus のリダイレクタへ届いているかどうかを確認する 為の良い方法は Web ブラウザのナビゲーションバーに利用する全ての リダイレクタの URL を打ち込んで見ることです。実際に Cactus の リダイレクタは単に次のような URL で呼び出すようになっています: http://localhost/webapp/ServletRedirector?Cactus_Service=RUN_TEST (これは他のリダイレクタも同様に動きます。)

If you call http://localhost/webapp/ServletRedirector directly, you'll get a 500 error and get a stack trace (in the log or along with your error page) that says Missing service name parameter [] in HTTP request.. This is because the Cactus redirector expects HTTP parameter from the Cactus client side.

もし http://localhost/webapp/ServletRedirector を直接呼び 出した場合には、500 番のエラーと以下のようなスタックトレース（ログの中 にか、エラーページにか）が得られるでしょう。 Missing service name parameter [] in HTTP request.. これは Cactus のリダイレクタは Cactus クライアントからの HTTP パラメータ を受け取るようになっているからです。

Another likely error is that your server-side classpath does not contain a copy of the cactus.jar. (Cactus is effectively not present on the server.) According to e-mails on the Cactus user list, the StreamCorruptedException could also result when you are using the wrong version of the servlet.jar in some area (any version prior to 2.2, or using servlet.jar 2.2 with a Cactus-2.3 installation).

他のよくあるエラーとしてはサーバー側のクラスパスが cactus.jar を 含んでいないことです。（サーバー上で Cactus が有効な状態になって いない。）Cactus の ユーザーリストの e-mail によれば StreamCorruptedException は servlet.jar の間違った バージョンのものを使ったばあいにも発生するそうです。

Let's imagine that I have one servlet that performs an HTTP redirect to a JSP page (or to another servlet). How do I test it with Cactus ?

Short answer : you don't !

手短に：やめましょう。

Long answer : Cactus is meant to be a unit testing tool, meaning it lets you perform tests for a given method and then it lets you assert the result from that method.

長めに答えると： Cactus は 単体テスト用のツールとして見なされています。 それはある一つのメソッドのテストを実行してそれからそのメソッドからの 結果を表明させます。

In the above scenario, a typical Cactus test will consist in verifying that the return HTTP response is an HTTP redirect (by checking the HTTP response code - 302 - in the endXXX() method) and possibly also checking the URL of the redirect page.

上のシナリオでは、典型的な Cactus のテストにで 戻ってきた HTTP レスポンスが HTTP リダイレクトである事（ endXXX() メソッドの中で HTTP レスポンスのコードが 302 であるのをチェックす る事で）そして、また良くある事ですがリダイレクトページの URL を 検証する物があります。

Then, as a second test, you could (if you wish) verify that calling the URL of the JSP does return such HTML content (using HttpUnit integration for example). Note that this second test is rather a functional test than a unit test but it can still be viewed as unit testing the doGet() method of the JSP ...

それから、２番目のテストとしては（もし望むなら）JSP の URL を呼び出 すことで その HTML のコンテンツが返ってくる事を検証できるでしょう。 （例えば HttpUnit と統合する事で ）注意すべきなのは２番目のテストは 単体テストと言うよりむしろ機能テストなのですが、JSP の doGet() メソッドの単体テストとして見なす事もできるのです。

When I use the runservertests Cactus custom Ant task, it starts my server allright but then hangs and the tests are not executed. What is happening ?

Cactus 用の 拡張 ant タスクである runservertests を実行 した時にすぐにサーバーが起動するのですが、それから動かなくなりそして テストが実行されません。何が起きたのでしょうか。

It means that the testURL attribute you've specified in runservertests is not a valid URL. It must be a URL that is valid when the server is up. To diagnosis the problem simply open a browser once your server is started (i.e. when the task hangs) and type the URL in your browser. An alternative to debug is also to run Ant in debug mode (ant -debug [your target]).

これは runservertests の中で定義する testURL が正しい URL でない事を意味します。それはサーバーが起動した時に必ず有効 な URL でなければいけません。この問題を簡単に診断するにはサーバーが起動 した時（つまりタスクが動かなくなった時に）にブラウザを開き、ブラウザに その URL を打ち込んでみる事です。デバッグのための別の手段としては ant を デバッグモードで立ち上げる事です。 (ant -debug [your target]).

With Cactus 1.3, the correct URL to call is the following, which is always valid : http://localhost:8080/webapp/ServletRedirector?Cactus_Service=RUN_TEST. Of course replace webapp by your webapp context and replace the port by the one you're using.

Cactus 1.3 では呼び出す正しい URL は次のようになっており、これは常に有効となっています。 http://localhost:8080/webapp/ServletRedirector?Cactus_Service=RUN_TEST. もちろん webapp の部分は実際の Web アプリのコンテキストに置き換え、 ポート番号も実際に利用している物に置き換えてください。