METAREAL

あとでブログに書こうと思って残しておいた ViewVC の設定メモ。今日、仕事中に思わず、ファイルを上書きしてしまった。

ネタはその日のうちに書いておけ、という教訓。

もっとも、インストールや設定自体は、ほぼ INSTALL ファイルの手順どおりでいけたので、ブログに書くまでもない気がする。気をつける部分といえば、セキュリティ的な理由から、Apache の DocumentRoot 以下にはインストールしないことくらいだろうか（INSTALL ファイルにも書いてあるけど）。

これだけじゃなんなので、httpd.conf も載せておく（パスなどは変えてある）。要点は：

• mod_python で動かしている
• 付属の .htaccess は使っていない
• /viewvc でアクセスできるように ScriptAlias を使う

LoadModule python_module modules/mod_python.so
<VirtualHost *:80>
  ServerName svn.metareal.org
  DocumentRoot /sites/viewvc

  ScriptAlias /viewvc /sites/viewvc/viewvc.py
  <Directory "/sites/viewvc">
    DirectoryIndex viewvc.py
    AddHandler python-program .py
    PythonHandler handler
    PythonDebug On

    AllowOverride None
    Order allow,deny
    Allow from all
  </Directory>
</VirtualHost>

ここ数週間、サイトに Subversion へのインターフェースを追加しようとしていた。それは Apache に倣い svn.metareal.org として公開され、個人的プロジェクトのレポジトリとして機能するはずだった。公開に向けて、暇をみてはコンパイルとインストールを繰り返していた。

そして、待っていたのは挫折の連続だった。

まずは、Trac に挑戦してみた。これは流行っているし、仕事でも使っているので安心感がある（仕事では同僚がインストールしてくれたので、まさか、あれほど多くのライブラリが必要だとは夢にも思わなかったのだ）。

しかし、延々とつづく configure, make, make install がやっと終わったと思ったら、結局動かない。

mod_python にしようが、mod_fastcgi, mod_fcgi にしようが結果は同じ。それはとにかく動かないのだ（ちなみに、遭遇した問題は Ticket:2969 で報告されているものと同様だが、DarwinPort ではなく、すべてソースからコンパイルした）。

Trac は諦めて、SVN::Web を試してみる。SVN::Web を選んだ理由は単純で、見た目が Trac と同じだったから。見た目重要。

しかし、こいつも依存モジュールのいくつか（WWW::Mechanize と Template::Plugin::Clickable::Email）がインストールできずに断念。CPAN しか試してないけど、それ以上追求する根気がない。

なんだかんだで、最終的には ViewVC に落ち着いた（いや、インストールできたのがこれだけなんですけどね）。他にも色々設定しないといけないけど、今日はとりあえず公開だけしておしまい。

あー、疲れた。

ユニットテストの実行に XML パーサが必要になった。

org.xml.sax.helpers.XMLReaderFactory.createXMLReader() を使っているので、SAX2 に準拠したパーサが必要だ。

また、ユニットテストのためだけに Xerces のような横綱級ライブラリを含めたくはない。パーサのライブラリは軽くなくてはいけない。

探してみると、条件に当てはまりそうなライブラリがふたつ見つかった。

• NanoXML
• Piccolo

.jar の容量だけでいえば NanoXML の圧勝。

SAX サポートを追加するための nanoxml-sax-2.2.3.jar を含めても、40KB に満たないコンパクトさだ（なお、NanoXML Lite というバージョンもあり、こちらは 6KB 以下）。ただ、残念なことに SAX 2 が実装されていないようだった。

他方、Piccolo では SAX2 が実装されているようなので、こちらを使うことにする。ドキュメントをよると、 開発に構文解析器 (JFlex)とコンパイラ・コンパイラ (BYACC/J) を用いているのがユニークな点らしい。

SAX パーサは java コマンドに -D オプションで指定するのが一般的だが、今回は System.setProperty で指定した。Piccolo の SAX2 パーサは com.bluecast.xml.Piccolo になる。

System.setProperty("org.xml.sax.driver", "com.bluecast.xml.Piccolo");
...

これで無事、ユニットテストが動作した。

Java で XML-RPC の開発をしている。

動作確認は UNIX コマンドの curl で手軽にすませているのだが、突然、すべての curl コマンドで Premature end of file. というエラーが出るようになった。

[Fatal Error] :-1:-1: Premature end of file.

このエラーには見覚えがある。たしか、XML の絡んだ通信で接続状態が悪くなり、通信が途絶えた場合などに ぼろぼろ出ていたやつだ。つまり、XML が不完全なのだろう。

しかし、curl の POST で送っているデータをいくら調べてもおかしい部分が見つからない。 問題になりがちな改行を取り除いても、コンソールのエンコーディングを変更しても同じ。

しかたがないので、デバッガでブレークポイントを設定し、動作を追ってみた。

その結果、リクエストオブジェクトの入力ストリームから読み出す時点でデータが空なことが判明。つまり、curl で POST したデータを読みだせていないわけだ。

では、何が原因でデータを読みだせていないんだろう？　curl の -v オプションの出力を眺めているうちに気がついた。

POST /api/xmlrpc HTTP/1.1
User-Agent: curl/7.13.1 (powerpc-apple-darwin8.0) libcurl/7.13.1 OpenSSL/0.9.7l zlib/1.2.3
Host: example.com
Pragma: no-cache
Accept: */*
Content-Length: 123
Content-Type: application/x-www-form-urlencoded

application/x-www-form-urlencoded で POST しているせいだ。

Content-Type が application/x-www-form-urlencoded だと、HttpServletRequest がパラメータとして解析するために先に入力を読みだしてしまうので、HttpServletRequest#getInputStream() から読みだすときは空なわけだ。

次のように POST すれば、正常に動作した（--data-ascii の XML は省略）。

% curl -v -H "Content-Type: text/xml" --data-ascii "..." "http://example.com/api/xmlrpc"

どうやら、昨日まではちゃんと -H オプションで Content-Type を指定していたのだが、一日寝ると忘れてしまったようだ。

だから、ブログに書いている。

Apache Web Services Project の一環として開発されている Apache XML-RPC は Web に紹介記事も多く、もっとも利用されている印象を受ける。

実際、これまで仕事でも XML-RPC クライアントとして Apache XML-RPC を使用していた。他の選択肢を知らなかった、というのもあるが、Apache というブランドの影響も大きいと思う。

しかし、不満がないわけではない。

特に、クラス階層が複雑なのには手こずった。動作をカスタマイズしたいときなど、あるクラスがどのインターフェースを実装し、どのファクトリで生成されるかを調べるだけでも大変だ（RequestProcessorFactoryFactory インターフェースまでくると、もう冗談のように思えてくる）。

実例をあげよう。

RPC の結果として不正な XML が返ってきた場合のエラー処理。 たとえば、XML 宣言の前に PHP のエラーが出力されている、なんてことはざらにある（現実とはそういう世界なのだ）。こういうときでも、XML 宣言以降は正当な XML なので、できるだけ XML をパースして処理の結果を拾いたい。

そして、このリカバリ処理自体は難しくない。例外をキャッチして、結果の文字列を XML 宣言までスキップして、再度パースしてみるだけだ。

だが、結局、その処理をするためには、ダウンロードした Apache XML-RPC のソースコードから既存のクラスをコピーして別のクラスを作成する必要があった。どうしてだろう？　もしかすると、他にエレガントな解決方法があったのかもしれない。だが、発見できなかった。

そして、いま、サーバサイドの XML-RPC サービスを実装しているのだが、今度は出力エンコーディングを設定する方法が分からない。きっとどこかで、エレガントな解決方法が、発見されるのを待っているのだろう。