ソーヤー効果についてはこちらのブログを見ると分かりやすいかも。

つまり、同じ作業であっても、

「報酬をあげるから、この作業をやってくれません？」

という見せ方と、

「この作業はすごく楽しい。お金払ったらさせてあげるよ」

という見せ方の２通りがあるということです。

前者が「仕事」であり、後者が「遊び」なわけです。ところが、全く同じ作業であっても「仕事だ」とおもってやっているとたのしく無いし、モチベーションも上がらない一方、「遊びだ」と認識できるととたんにモチベーションが上がってしまったりします。

うちの会社の開発業務でも取り入れられないかなぁなんて思ったのですが、例えばSubversionのリポジトリを監視していて、日々コミットしたソースコードの行数をレポートするような簡単なロボットがあって、「月間MVP」みたいなのが出てくるとか。

それは人事考課に影響するものではなくて、単なる「遊び」です。

だれかそういうの作ってませんかね？Subversionのリポジトリを監視するくらいのものであればコストもかからず簡単に導入できそうですし〜。

ちなみに、プログラムの価値は行数で評価されるものではないので、そんなもので給与が決まったらたまりませんが、遊びであれば問題ありません。逆に単なる行数なので、若手が上司に勝てたりする余地もあります。

もちろん上位になるために無駄なものをコミットしたりしてはいけません。そんな事をしたら「ダメなコードを書く人」として人事考課に影響します。そういうガードはかかっているので、暴走する危険はなさそうです。

こういった話は「ゲーミフィケーション」というネタで最近話題になっているようなので、しばらくウォッチしてみたいとおもいます。

そんな訳で必要なのが年賀状。我が社の「ウェブポ」ですが、今年もやります。

http://webpo.jp/top/

例年ご要望の多かった喪中はがきの印刷にも対応する予定です。

受付は11/1から。

乞うご期待！

• Apache Thrift 0.6.1〜0.7.0
• サーバサイドは Tomcat上で ServletとしてThriftの要求を受付
• トランスポート層はHTTPで、TBinaryProtocolを使用

という感じです。このJavaのサーバにC#のクライアントから接続できるかどうか、試してみたいと思います。

.NET版のThrift DLLを作る

MacOS X 上でビルドした Thriftコンパイラは、C#のコードを吐く事ができます。ただこれはあくまで自動生成部分です。Javaも ThriftのJarを Mavenで取ってきていましたが、.NET版の実際の動作にはThriftのDLLを準備する必要があります。

どこからかダウンロードできると良いのですが、公式サイトにはソースコードしかありません。Windows用のThrift Compilerは .exeが置いてあるんですがね、、、。

そんなわけで Visual Studio 2010を使ってソースからDLLをビルドします。

ソースを展開する

http://thrift.apache.org/download/ からソースコードをダウンロードします。執筆時点での最新版はthrift-0.7.0.tar.gz です。これを展開すると、いろいろファイルが出てきますが、目的のDLLのソースは、lib/csharp/src の中にあります。

このフォルダに Thrift.sln という VisualStudioのソリューションファイルがあるのですが、なぜかうまく開けません。「選択されたファイルは有効なソリューションファイルではありません。」というエラーが出てしまいます。

thrif-0.6.1でも thrift-0.7.0でもだめでした。海外のサイトにはあまり情報がないようなのですが、日本語のVisual Studio特有の問題なのでしょうか？

Visual Studioでビルドする

仕方がないので空のソリューションを作り、そこにソースを突っ込んでビルドします。手順は以下の通りです。

• VS2010を立ち上げ、「ファイル」-「新規作成」-「プロジェクト…」を選択します。
• 新規プロジェクトダイアログで「クラスライブラリ」を選択します。

• プロジェクト名は Thrift-0.7.0 にしてみました。
• プロジェクトができたら、ソリューションエクスプローラの上でThrift-0.7.0プロジェクトを右クリックし、プロパティを開きます。
• プロジェクトのプロパティで、使用する .NETフレームワークのバージョンを選択します。僕は「 .NET Framework 4.0」を選びました。「.NET Framework 4.0 Client Profile」というのもあるのですが、こちらだと、System.Webパッケージが使用できないため、Thriftをビルドできませんでした。
• プロジェクトを作成したら、thriftのlib/csharp/src の中身をドラッグ＆ドロップするなどしてプロジェクトに追加します。
• 「参照設定」を右クリックして「参照の追加…」メニューを開きます。
• 参照の追加で、.NETの System.Webを追加します。
• ここまでの状態で、プロジェクトは以下のようになっているはずです。

• 「ビルド」-「ソリューションのビルド」を選択してビルドします。設定に間違いがなければビルドに成功するはずです。
• ビルドに成功したら、プロジェクトディレクトリの中に obj/Debug/Thrift-0.7.0.dll が出来ています。今後はこのファイルをコピーして利用します。

CardServiceのクライアントプロジェクトを作成する

DLLが出来たところで、JavaのCardServiceサーバに接続するクライアントプログラムをC#で作ってみます。VS2010で「ファイル」-「新規作成」-「プロジェクト…」を選択し、今度は「コンソールアプリケーション」を選びます。GUIが得意な人は「Windowsフォームアプリケーション」などでも構いません。適宜読み替えてください。

プロジェクト名は「CardServiceClient」にしてみました。

ThriftのDLLを追加する

プロジェクトが出来上がったら、先ほど作成したDLLをプロジェクトに追加します。プロジェクトのトップに lib フォルダを作り、そこにコピーします。

これだとファイルをコピーしただけなので、実際にThrift-0.7.0.dllが使われるように、参照設定を変更します。「参照設定」を右クリックして「参照の追加…」を選択します。

ダイアログが開いたら「参照」タブを選択して、今プロジェクトにコピーした lib/Thrift-0.7.0.dll を選択します。

これでプログラムをビルドする準備が整いました。

C＃用のソースコードを生成する

Thriftコンパイラ(thriftコマンド)を使って CardServiceのC#用ソースコードを生成します。Javaのサーバ側を作ったときと同じ CardService.thriftファイルを用います。

CardService.thrift

#!/usr/bin/thrift

namespace java jp.ohnaka.thrift
namespace csharp Ohnaka.Thrift

struct Card {
  1: string id;
  2: string name;
}

exception TIllegalArgumentException
{
    1: string message
}

service CardService
{
        void addCard(1: Card card) throws (1:TIllegalArgumentException e);
        list<Card> getCards();
        Card getCardById(1: string id) throws (1:TIllegalArgumentException e);
}

ただし、Javaのコードを生成した時から一行だけ追記しています。C#用のネームスペースを宣言する部分です。

namespace csharp Ohnaka.Thrift

今回は、Ohnaka.Thriftとしてみました。お好みで書き換えてください。準備ができたら C#のコードを生成します。thriftコンパイラは MacOS X 上で作ったものをつかってみましたが、Windows用のThriftコンパイラ(thrift.exe)をダウンロードしてきてもOKです。

# thrift --gen csharp CardService.thrift

Javaのコードと同時に生成するのであれば、

# thrift --gen java --gen csharp CardService.thrift

としてください。

うまくいけば、gen-csharpというフォルダが作られますので、その中身をVisual Studioの CardServiceClientプロジェクトに追加します。

プロジェクトの設定を変更する

CardServiceClientプロジェクトの設定を少し変更する必要があります。というのも、Thrift-0.7.0.dllは、.NET Framework 4.0 を使ってつくられました。しかし、今作ったCardServiceClientはデフォルトで .NET Framework 4.0 Client Profieというものを使うように設定されています。ThriftのDLL は System.WebというClient Profileには入っていない namespaceのライブラリを使っているため、そのままでは動かないのです。

プロジェクトを右クリックして、プロパティを表示し、フレームワークを「.NET Framework 4.0」に変更してください。変更が終わったら、「参照設定」を右クリックし「参照の追加…」から System.Webを追加してください。

次のような画面になればOKです。

サーバを呼び出すコードを記述してみる

ひな形の mainメソッドがかかれた Program.cs というファイルがありますので、これを直接いじって、main()メソッドにコードを書いてみます。

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Thrift.Transport;
using Thrift.Protocol;
using Ohnaka.Thrift;

namespace CardServiceClient
{
    class Program
    {
        static void Main(string[] args)
        {
            // 接続先のURLを指定
            THttpClient transport = new THttpClient(new Uri("http://localhost:8080/thrift-test-server/card"));
            // バイナリプロトコルを使用（サーバ側と合わせる）
            TProtocol protocol = new TBinaryProtocol(transport);
            // クライアントスタブを作成
            CardService.Client client = new CardService.Client(protocol);

            try
            {
                transport.Open();

                // サーバ側のaddCardメソッドを呼び出す
                Card card1 = new Card();
                card1.Id = "1000";
                card1.Name = "ohnaka";
                card1.Test = new Test();
                client.addCard(card1);

                // もう一個カードを作ってみる
                Card card2 = new Card();
                card2.Id = "1001";
                card2.Name = "kuni";
                client.addCard(card2);

                // サーバ側のgetCardsメソッドを呼び出す
                List<Card> cards = client.getCards();
                System.Console.WriteLine("Num of cards: " + cards.Count);

                // サーバ側のgetCardメソッドを呼び出す
                Card retrievedCard = client.getCardById("1000");
                System.Console.WriteLine("Retrieved card id   = " + retrievedCard.Id);
                System.Console.WriteLine("Retrieved card name = " + retrievedCard.Name);

                // 不正な引数を渡してみる
                try
                {
                    client.addCard(null);
                }
                catch (Exception ex)
                {
                    // どんな例外が飛ぶか調べる
                    System.Console.WriteLine(ex.Message);
                }
                // IDが null なCardを渡してみる
                try
                {
                    client.addCard(new Card());
                }
                catch (Exception ex)
                {
                    // どんな例外が飛ぶか調べる
                    System.Console.WriteLine(ex.Message);
                }
            }
            catch (Exception ex)
            {
                System.Console.WriteLine(ex.Message);
                return;
            }
            finally
            {
                System.Console.WriteLine("End. Please Hit Any Key.");
                System.Console.ReadLine();
            }
        }
    }
}

Javaで書いたクライアントのコードをほとんどそのままコピペした感じです。ここまで同じに書けるとは思いませんでした。

実行結果はこんな感じ。

うまくJavaのサーバと通信する事ができました！例外もきちんと飛んできています。

C#版のバグ？

リクエストがタイムアウトする

実は最初に試した時にTHttpClientのリクエストがタイムアウトしてエラーになってしまうという問題に悩まされました。色々調べてみたところ、次のバグ報告に行き着きました。

https://issues.apache.org/jira/browse/THRIFT-1260

When calling the server more than 16000 times, an exception is being thrown – “An operation on a socket could not be performed because the system lacked sufficient buffer space or because a queue was full” its because the stream is not being closed.

streamがクローズされていない正で、サーバを16000回以上呼び出した時に「バッファ領域が不足しているか、キューがいっぱいでソケット上の操作が完了できません」という例外がスローされる。

僕が遭遇したのはこの現象ではなかったのですが、streamがクローズされていないというのはかなり怪しい感じがします。試しこのページに添付されていたTHttpClient.csをダウンロードして、thrift-0.7.0.dllを作り直してみました。すると無事にエラーが起こらなくなりました。

この手のバグに簡単に遭遇したというところからして、ThriftはあまりC#上で使われていないのではないかという気がします。Thriftがサポートしているプログラミング言語は多岐に及びますが、枯れている言語と枯れていない言語がありそうで、注意が必要です。

SSL接続がタイムアウトする

試しに接続先を https://〜 にして、SSLでの接続を試みたのですが。見事に失敗しました。サーバに接続しようとしても何も応答が返ってこず、タイムアウトしてしまったのです。

原因を調べていたら以下のサイトが見つかりました。

http://stackoverflow.com/questions/5653868/what-makes-this-https-webrequest-time-out-even-though-it-works-in-the-browser

Using Microsoft Network Monitor, I found that HttpWebRequest would get stuck at a stage where it’s supposed to send back a client key exchange. It simply didn’t. The server duly waited for it, but it never came.

Microsoft Network Monitorを使って調べたところ、HttpWebRequestがクライアント鍵交換を行なう段階でスタックする事を発見しました。単に何もしていないのです。サーバは正しくそれを待っているのですが、返事は来ません。

この問題は、次の方法で回避できるそうです。

What fixed it was forcing HttpWebRequest to use SSL3 instead of TLS (even though TLS is supposed to automatically turn into SSL3 if necessary)

HttpWebRequestがTLSではなくSSL3を使うように強制するとこの問題が直ります（TLSは本来必要があれば自動的にSSL3になるはずなのですが)

この方も良く理由は分からないらしいのですが、TLSを使わずにSSL3を使う事を強制するとうまく接続できるようになるそうです。そのためには、接続前に以下のコードを実行すればOKです。

 ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3; 

これはどうやらグローバルな設定のようなので、どこかで一回やればOKなんだと思いますが、念のため、THttpClientのCreateRequestメソッドの頭に突っ込んでみました。

        private HttpWebRequest CreateRequest()
        {
            // TLSを使わずに強制的にSSLを使うように指示。そうしないとタイムアウトしてしまう
            ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3;
            HttpWebRequest connection = (HttpWebRequest)WebRequest.Create(uri);

うーむ。いろいろありますね。

自己署名の証明書を持つサーバにSSL接続する場合

Javaでもよくありますが、第三者に署名されていないいわゆる「オレオレ証明書」のサーバに接続する場合、「証明書が署名されてないぞ！」とエラーになってしまいます。僕はちゃんとした証明書を持っているのでこの問題にはあたりませんでしたが、もしこの問題にあたった方は以下の方法で回避できるそうです。

http://stackoverflow.com/questions/560804/how-do-i-use-webrequest-to-access-an-ssl-encrypted-site-using-https

やはり、ServicePointManagerに手を入れるようです。

ご参考まで。

プラットフォームを跨いでRPCを行なう場合、各プラットフォーム上で値クラスや例外を定義するのが煩雑になります。Apache Thriftの良いところはこれらのコードまでふくめて、各プラットフォームのRPC層のソースコードを自動生成してくれるところにあります。

ただ、Thriftが生成したクラスをビジネスロジック層で使ってしまうのはいささか抵抗があります。

Thriftが生成したクラスはどの範囲で使うべきか

過去の調査で「CardService」というRPCを題材として用いてThriftを動かしてきました。CardServiceの例では、Thriftで  Cardクラスという値クラスを定義し、そのオブジェクトをクライアントとサーバの間でやりとりしています。また、サーバ上で発生した例外をクライアントにも伝わるように、TIllegalArgumentExceptionという例外を定義し、それを throwしてみるテストを行ないました。

しかし、このCardクラスと TIllegalArgumentException例外は、どのレイヤまで利用して良いのでしょうか？

• CardをDBに永続化する場合、永続化層に渡す引数として、Thriftが生成したCardクラスを渡しても良いものか？
• ThriftによるRPC以外に、JAX-RSなどでRESTfulインターフェースも平行して提供したい場合、JAX-RS層でもThriftが生成したCardクラスを使っても良いか？
• ビジネスロジック層で引数のエラーが発生した時に、TIllegalArgumentExceptionを throwしてもよいか？つまり、ビジネスロジック層のメソッドに throws TIllegalArgumentExceptionが現れても良いか？

「レイヤ間の依存性を極力下げる」という考えからすれば、これらは全てNGです。つまり、Thriftが自動生成してくれたクラスや例外は、あくまでRPC層のみで用い、他のレイヤに渡す時は別のオブジェクトに変換してやる必要がありそうです。

これは嬉しいような嬉しく無いような、、。

それでもThriftはメリットがある

「自動生成されたコードが限定的にしか使えないなんて、それってお自動生成した意味あるの？」

という気持ちになってきますが、僕は「意味はある」と思っています。理由は２つあります。

まず一つ目の理由。例えば、ちょっとしたメンテナンスツールを作りたい場合などに、使い慣れた環境から簡単にRPCを呼び出せると嬉しい場合があります。このクライアントコードは半ば使い捨てのようなものなので、レイヤ間の依存性などをいちいち気にする必要がない場合が多いでしょう。このようなツールを作る場合に、値クラスや例外が自動生成されるのはとても嬉しいです。

もう一つの理由は、「XMLやJSONをパースするよりは簡単にコードが書ける」というものです。自動生成された値クラスが無い場合はどうしていたかというと、サーバからXMLが帰ってきて、それをパースしてビジネスロジック層のオブジェクトに詰め込んでいたのです。つまり、Thriftが生成したCardクラスをTCard、ビジネスロジック層のCardクラスをBCardとすると、

今まで：

XML ---パース---> BCard

Thrift：

TCard ---コピー---> BCard

というように対比できます。前者のコードより、後者のコードの方が圧倒的に簡単です。うまくプロパティ名などを合わせれば、全自動でコピーを行なう事もできます。

実際、僕はReflectionを使って TCardから BCardへプロパティをコピーするトランスレータを自作しましたが、とてもうまく動いています。

例外はどうする？

ThriftはRPCなので、例外は一方通行、つまりサーバ側で発生した例外がクライアントに渡る方向しかありません。メソッドの引数に問題があった時にArgumentExceptionを送出する、というシチュエーションを例にして図示してみます。クライアントにビジネスロジックがある場合も考えると、例外は次のように変換されるべきです。

クライアントビジネスロジック層            クライアントRPC層                 サーバRPC層                  サーバビジネスロジック層
      BCArgumentException  <=変換= TArgumentException <==Thrift/HTTP== TArgumentException <=変換=  BSArgumentException

これをベタにやろうとすると、例えばサーバRPC層とサーバビジネスロジック層との間で次のようなコードを書く事になります。

try {
    bService.someMethod(arg1, arg2);
} catch( BSArgumentException e) {
    throw new TArgumentException(e.getMessage);
}

あー、、、。こういうコードを全てのメソッドの呼び出しに書くのは骨が折れます。

実は、こういった「全てのメソッドの呼び出しに◯◯する」というのはアスペクト指向プログラミング(AOP)という考え方を使うとうまく解決できます。Javaは言語仕様としてはメソッドの呼び出しをフックする仕組みを持っていませんが、Proxyクラスを使うと実現できます。また、Javaassistやcglibというツールを使う方法もあります。

今回僕はサーバサイドにSpringフレームワークを使っていたので、SpringのAOP機能を使って例外を変換する方法を紹介します。

TServletの使い方を少し変えて、Springを利用する

Thriftに付いてくる TServletというクラスを用いると、ThriftのRPCをJavaのサーブレットとして動かす事ができます。前回紹介した時は次のようなコードにしました。

import jp.ohnaka.thrift.CardService;

import org.apache.thrift.protocol.TBinaryProtocol;
import org.apache.thrift.server.TServlet;

/**
 * CardServiceサービスへの呼び出しを受け付けるサーブレット
 */
public class CardServiceServlet extends TServlet {
    private static final long serialVersionUID = 1L;

    public CardServiceServlet() {
        // Binary Protocolを扱うサーブレットとして初期化する
        super(new CardService.Processor(new CardServiceHandler()), new TBinaryProtocol.Factory());
    }
}

このコードでは、CardServiceの実装クラスであるCardServiceHandlerを直接 new していますが、Springから取得するように変更してみます。

import jp.ohnaka.thrift.CardService;

import org.apache.thrift.protocol.TBinaryProtocol;
import org.apache.thrift.server.TServlet;

/**
 * CardServiceサービスへの呼び出しを受け付けるサーブレット
 */
public class CardServiceServlet extends TServlet {
    private static final long serialVersionUID = 1L;

    private CardService.Iface getHandler() {
        return (CardService.Iface) applicationContext.getBean("cardServiceHandler");
    }

    public CardServiceServlet() {
        // Binary Protocolを扱うサーブレットとして初期化する
        super(new CardService.Processor(getHandler()), new TBinaryProtocol.Factory());
    }
}

applicationContextは SpringのApplicationContextのインスタンスです。このオブジェクトはSpringの初期化時に作ったものですが、環境によって取り方はいろいろあります。ひとまずどこかに保存しておいた者を取ってきたものと思ってください。

このようにする事で、new CardServiceHandler() となっていた部分が無くなり、Springによってインスタンスを作るようになります。

Springの設定をする

springの設定ファイルには次のような記述を書きます。

 <!-- CardServiceのハンドラ。例外変換の為に Porxyを使って ThriftExceptionMapperAdviceをinjectしている -->
 <bean id="cardServiceHandler" class="org.springframework.aop.framework.ProxyFactoryBean">
  <property name="proxyInterfaces" value="jp.ohnaka.thrift.CardService$Iface"/>
  <property name="interceptorNames">
   <list>
    <value>thriftExceptionMapperAdvice</value>
   </list>
  </property>
  <property name="target">
   <bean class="jp.ohnaka.thrift.CardServiceHandler"/>
  </property>
 </bean>

 <bean id="thriftExceptionMapperAdvice" class="jp.ohnaka.thrift.ThriftExceptionMapperAdvice"/>

通常のBeanであれば、

<bean id="cardServiceHandler" class="jp.ohnaka.thrift.CardServiceHandler"/>

と書くだけなのですが、なんだか長ったらしくなっています。実は、Springの ProxyFactoryBeanというものを使って、CardServiceHandlerにちょっとした仕掛けを仕込めるようにしています。これが「アスペクト指向プログラミング」の考え方です。
では、プロパティの意味を順に説明します。

proxyInterfaces

このBeanの持っているインターフェースを列挙します。今回のCardServiceHandlerは CardServiceクラスの内部インターフェース であるIfaceインターフェースを実装していますので、”jp.ohnaka.thrift.CardService$Iface” としています。なお、複数列挙する時は<list>を使えばいいみたいです。

interceptorNames

proxyInterfacesで定義したインターフェースの各メソッドを呼び出す時にどういう「仕掛け(Proxy)」を仕込むのかを定義しています。ここでは thriftExceptionMapperAdviceというものを指定します。これは後ろで定義しているBeanの idと対応しています。

target

この「仕掛け」をかます対象のBeanです。refで外部の Beanを参照しても良いですが、ここではその場で定義しています。定義している Beanは今までソースコード内で newしていた jp.ohnaka.thrift.CardServiceHandlerです。

これで何が起こるの？

このようにして作られた cardServiceHandlerというIDの Beanは、CardService$Ifaceの各メソッドを呼び出す時に、thriftExceptionMapperAdviceを経由して呼び出されるようになります。この ThriftExceptionMapperAdviceは、次のようなクラスです。

package jp.ohnaka.thrift;

import org.springframework.aop.ThrowsAdvice;

/**
 * サービス層で発生したIllegalArgumentExceptionを Thrift層の TIllegalArgumentExceptionに変換する。
 * SpringのAOPを使って、CardServiceHandlerの各メソッドにこの Adviceを injectしている。
 * @author ohnaka
 */
public class ThriftExceptionMapperAdvice implements ThrowsAdvice {
    public void afterThrowing(IllegalArgumentException e) throws Throwable {
        throw new TIllegalArgumentException(e.getMessage());
    }
}

ThriftExceptionMapperAdviceは Springの ThrowsAdviceというインターフェースを実装したクラスです。ThrowsAdviceは「メソッドの呼び出しで例外が発生したときに処理を仕込みたい」という事をSpringに教える為のマーカインターフェースです。

ThrowsAdviceをマーカインターフェースをして実装した上で、afterThrowing()というメソッドを定義します。この例のように afterThrowing(IllegalArgumentException e) と定義すると、CardServiceHandlerで IllegalArgumentExceptionが発生した時に、呼び出し元に例外が渡る前にこのメソッドを呼び出してくれるようになります。

つまり、CardServiceHandlerの全てのメソッドの呼び出しに、

try {
} catch(IllegalArgumentException e) {
   throw new TIllegalArgumentException(e.getMessage());
}

というコードを付け足したのと同じ効果が得られるわけです。afterThrowing(HogeHogeException e) というのを定義すれば、別の例外 HogeHogeExceptionに対してフックを仕掛けることもできます。

ちなみに、afterThrowing()メソッドの中で、「どのメソッドが呼び出されたのか」を知りたい場合は次のような書き方もできます。

public void afterThrowing(Method m, Object[] args, Object target, IllegalArgumentException ex)

これでThriftのRPC層とビジネスロジック層で例外を変換できるようになりました。めでたしめでたし。

補足

本文中では適当に飛ばしてしまった Springの ApplicationContextの取り方ですが、僕はこんな風にしています。

まず、web.xmlで Springの SpringContextLoaderListenerというリスナを定義します。そのリスナの後に、自作のContextListenerを定義します。

web.xml

 <listener>
  <listener-class>org.jboss.resteasy.plugins.spring.SpringContextLoaderListener</listener-class>
 </listener>

 <listener>
  <listener-class>jp.ohnaka.web.MyContextListener</listener-class>
 </listener>

順番は必ずSpringContextLoaderListenerが先にくるようにしてください。

MyContextListenerは次のようにします。

public class MyContextListener implements ServletContextListener {

    public void contextInitialized(ServletContextEvent arg0) {
        WebApplicationContext wac = WebApplicationContextUtils.getRequiredWebApplicationContext(arg0.getServletContext());
        MyApplicationContext.getInstance().setApplicationContext(wac);
    }
}

このようにすると、SpringContextLoaderListenerが先に起動するので、MyContextListenerの contextInitializedが呼ばれた時には、Springの初期化が終わっており、Servlet Contextに ApplicationContextがセットされています。そのApplicationContextは WebApplicationContextUtilsを使って取得できます。

WebApplicationContextUtilsのgetRequiredWebApplicationContextメソッドは、staticメソッドなのでどこからでも呼べるのですが、引数に ServletContextが必要なので、先ほどの CardServiceHandlerなどからは呼び出せません。そこで MyContextListenerの contextInitializedメソッドの中で呼び出しておき、自作のシングルトンクラス(MyAppliationContext)にセットしておいて、どこからでも取れるようにしています。

こうすると、CardServiceHandlerでは、

MyApplicationContext.getInstance().getApplicationContext();

というような感じで、AppliationContextを取得できるようになります。

ただ、前回のものだとXML-RPCなどの他の言語非依存のRPC技術と大差のない単なるメソッド呼び出しになってしまっていました。

Apache Thriftの真骨頂は、intや stringといったプリミティブ型だけでなく、構造体(クラス)や例外までもがプラットフォームを超えて共用できるというところにあります。

今回は構造体や例外も含めて、もう少し実際のサービスに近いレベルでテストをしてみたいと思います。

Cardの管理を行なうサービスを定義する

JAX-RSでRESTfulサービスを定義する記事と同じく、名刺(Card)を追加したり一覧を取ったりする事のできるサービスを考えてみます。

メソッドとしては次の３つを考えました。

CardService.thrift

service CardService
{
        void addCard(1: Card card);
        list<Card> getCards();
        Card getCardById(1: string id);
}

addCard()はCardを追加するメソッド、getCards()は全てのCardを取得するメソッド、getCardByIdはIDを指定してCardを取得するメソッドです。ここで、前回までの記事では出てこなかった要素が２つあります。

１つ目は、list型です。Thriftでは複数の要素を扱う入れ物(Container)として、list, set, mapがデフォルトで用意されています。これらはJavaのGenerics、C++のTemplateと同じような表記で、型の指定が可能です。

詳細を公式サイトから引用します。

• list<type>
• 順序の決まった要素のリストです。C++ではSTLのvectorクラス、JavaではArrayList、その他のスクリプト言語では標準の配列にマッピングされます。
• set<type>
• 順序の決まっていない、ユニークな要素の集合です。C++ではSTLのsetクラス、JavaではHashSet、Pythonではsetクラスにマッピングされます。PHPはsetをサポートしないため、Listのように扱われます。
• map<type1,type2>
• 厳密にユニークなキーとそれに対応する値のマップです。C++ではSTLのmap、JavaではHashMap,PHPでは連想配列、PythonやRubyでは dictionaryにマッピングされます。

２つ目は引数や返り値の型として使っているCardというクラスです。これはThriftがデフォルトで持っている者ではありません。自分で定義する必要があります。CardService.thriftに以下の定義を追加しましょう。

CardService.thrift

struct Card {
  1: string id,
  2: string name
}

まさにC言語の構造体です。ですが、フィールドの先頭に1: や 2: という数字が付いています。これはField IDというもので、フィールドを一意に指定するIDとして利用されます。IDLの定義としてはオプションなので、無くてもコンパイルはできるのですが、「下位互換性を保つ為には定義しておいた方が無難だよ」というwarningが出ます。

たとえば、リリース後に nameというフィールドを firstname に変更したい場合があったとします。そのような場合でもフィールドIDを同じにしておけば古いクライアントともきちんと通信できるようになるのだろうとおもいます（試してません）。

外部に公開するAPIを考えると下位互換性の問題は避けて通れません。注意して設計するようにしましょう。

ちなみに、Cの構造体やJavaのクラスのように、フィールドの区切りをコンマ(,)の代わりにセミコロン(;)にする事もできます。IDL上はどちらでも良いようです。

CardService.thrift (セミコロンバージョン)

struct Card {
  1: string id;
  2: string name;
}

パッケージの宣言を追加する

このままThriftでコード生成をしても良いのですが、Javaのクラスがデフォルトパッケージの(package宣言が無い)クラスとして生成されてしまうのはちょっとかっこわるい感じがありました。

実は thriftファイルにはパッケージ名を指定する方法がちゃんとあります。この宣言を頭に足しておいてください。

CardService.thrift

namespace java jp.ohnaka.thrift

この宣言は、「Javaのコードを生成する時は jp.ohnaka.thriftパッケージにしてね」という意味になります。もちろんC++や他の言語でも個別に指定できます。

ただし、一つのthriftファイル内では namespace宣言は１つしかする事はできません。すなわちCardクラスとCardServiceクラスは必ず同じパッケージになってしまうという事です。まあ仕方ないんでしょうかね。

CardServiceのサーバサイド実装

それでは実際にCardServiceクラスを実装してみます。

詳細は以前説明したもの同じなので省略しますが、ビジネスロジックを実装するCardServiceHandlerと、Servlet化するためのCardServiceServletを実装すればOKです。

CardServiceHandler.java

import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

import jp.ohnaka.thrift.Card;
import jp.ohnaka.thrift.CardService;

import org.apache.thrift.TException;

/**
 * CardServiceのサーバサイド実装
 */
public class CardServiceHandler implements CardService.Iface {

    static private Map<String, Card> cardDb_ = new HashMap<String, Card>();

    @Override
    public void addCard(Card card) {
        cardDb_.put(card.getId(), card);
    }

    @Override
    public List<Card> getCards() {
        return new ArrayList<Card>(cardDb_.values());
    }

    @Override
    public Card getCardById(String id) {
        return cardDb_.get(id);
    }

}

DBの代わりにstaticな Map<String,Card>を用意して、そこにストアするようにしてあります。本当のサービスであればMyBatisなどを使ってDBにストアするようなイメージです。

CardServiceServlet.java

import jp.ohnaka.thrift.CardService;

import org.apache.thrift.protocol.TBinaryProtocol;
import org.apache.thrift.server.TServlet;

/**
 * CardServiceサービスへの呼び出しを受け付けるサーブレット
 */
public class CardServiceServlet extends TServlet {
    private static final long serialVersionUID = 1L;

    public CardServiceServlet() {
        // Binary Protocolを扱うサーブレットとして初期化する
        super(new CardService.Processor(new CardServiceHandler()), new TBinaryProtocol.Factory());
    }
}

前回の記事と同じで、TServletを継承して使用するプロトコルを明示するだけです。

web.xml

サーブレットを /card に配置するために、web.xmlは以下のようにしました。

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" id="WebApp_ID" version="2.5">
  <display-name>thrift-test-server</display-name>

  <servlet>
  <servlet-name>CardServiceServlet</servlet-name>
  <servlet-class>CardServiceServlet</servlet-class>
  </servlet>

  <servlet-mapping>
  <servlet-name>CardServiceServlet</servlet-name>
  <url-pattern>/card</url-pattern>
  </servlet-mapping>
</web-app>

これで完成です。

明示的に例外を投げるようにする

CardServiceHandlerの実装では引数のチェックなどを一切していません。addCard()に nullが渡されたり、Cardオブジェクトのidがnullだったりした場合に、内部でRuntimeExceptionが発生してしまいます。NullPointerExceptionなどのRuntimeExceptionが発生すると、HTTPの500 Internal Server Errorとなってクライアント側に問題が発生した事が伝えられます。

そういう仕様でもいいのですが、クライアントからするといったいなぜ500 Internal Server Errorになったのか原因を特定する事ができず困ってしまいます。

そこで、TIllegalArgumentExceptionという例外を定義して、明示的に例外を投げるようにしてみます。Javaであればjava.lang.IllegalArgumentExceptionを投げるのが一般的ですが、他の言語で理解できない例外なので、例外もきちんと Thrift上で定義してあげる必要があります。

ちょっと細切れになってきたので、CardService.thriftの全体を示します。

CardService.thrift

#!/usr/bin/thrift

namespace java jp.ohnaka.thrift

struct Card {
  1: string id;
  2: string name;
}

exception TIllegalArgumentException
{
    1: string message
}

service CardService
{
        void addCard(1: Card card) throws (1:TIllegalArgumentException e);
        list<Card> getCards();
        Card getCardById(1: string id) throws (1:TIllegalArgumentException e);
}

exception TIllegalArgumentExceptionというところが例外を定義しているところです。文法は構造体の定義と同じで、structの部分を exceptionに変えただけです。

このように例外を定義すると、サービスのメソッドにthrows節を書けるようになります。throwsの意味はJavaと同じですが、1: というフィールドIDと例外変数の名前として”e”という名前を明示する必要があるところがちょっと変わっています。詳細は未調査ですが、これも後方互換性のためでしょうか。

例外を追加したので、CardServiceHandlerも以下のように修正します。

CardServiceHandler.java

import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

import jp.ohnaka.thrift.Card;
import jp.ohnaka.thrift.CardService;
import jp.ohnaka.thrift.TIllegalArgumentException;

/**
 * CardServiceのサーバサイド実装
 */
public class CardServiceHandler implements CardService.Iface {

    static private Map<String, Card> cardDb_ = new HashMap<String, Card>();

    @Override
    public void addCard(Card card) throws TIllegalArgumentException {
        if (card == null) {
            // クライアントサイドに飛ばす例外にはjava.lang.IllegalArgumentExceptionは使えない
            // ので、独自に定義した例外を利用する
            throw new TIllegalArgumentException("Argumnent shouldn't be null");
        }
        if (card.getId() == null) {
            // クライアントサイドに飛ばす例外にはjava.lang.IllegalArgumentExceptionは使えない
            // ので、独自に定義した例外を利用する
            throw new TIllegalArgumentException("Card ID shouldn't be null");
        }
        cardDb_.put(card.getId(), card);
    }

    @Override
    public List<Card> getCards() {
        return new ArrayList<Card>(cardDb_.values());
    }

    @Override
    public Card getCardById(String id) throws TIllegalArgumentException {
        if (id == null) {
            throw new TIllegalArgumentException("Argumnent shouldn't be null");
        }
        return cardDb_.get(id);
    }

}

クライアントサイドを実装する

サーバサイドの準備ができたので、これを呼び出すクライアントサイドを実装してみます。

Client.java

import java.util.List;

import jp.ohnaka.thrift.Card;
import jp.ohnaka.thrift.CardService;

import org.apache.thrift.TException;
import org.apache.thrift.protocol.TBinaryProtocol;
import org.apache.thrift.protocol.TProtocol;
import org.apache.thrift.transport.THttpClient;

public class Client {

    public static void main(String[] args) throws Exception {
        // 接続先のURLを指定
        THttpClient transport = new THttpClient("http://localhost:8080/thrift-test-server/card");
        // バイナリプロトコルを使用（サーバ側と合わせる）
        TProtocol protocol = new TBinaryProtocol(transport);
        // クライアントスタブを作成
        CardService.Client client = new CardService.Client(protocol);

        try {
            transport.open();

            // サーバ側のaddCardメソッドを呼び出す
            Card card1 = new Card();
            card1.setId("1000");
            card1.setName("ohnaka");
            client.addCard(card1);

            // もう一個カードを作ってみる
            Card card2 = new Card();
            card2.setId("1001");
            card2.setName("kuni");
            client.addCard(card2);

            // サーバ側のgetCardsメソッドを呼び出す
            List<Card> cards = client.getCards();
            System.out.println("Num of cards: " + cards.size());

            // サーバ側のgetCardメソッドを呼び出す
            Card retrievedCard = client.getCardById("1000");
            System.out.println("Retrieved card id   = " + retrievedCard.getId());
            System.out.println("Retrieved card name = " + retrievedCard.getName());

            // 不正な引数を渡してみる
            try {
                client.addCard(null);
            } catch (Throwable t) {
                // どんな例外が飛ぶか調べる
                t.printStackTrace();
            }
            // IDが null なCardを渡してみる
            try {
                client.addCard(new Card());
            } catch (Throwable t) {
                // どんな例外が飛ぶか調べる
                t.printStackTrace();
            }
        } catch (TException te) {
            te.printStackTrace();
        }
    }

}

実行結果

クライアントコードを実行した結果です。

Num of cards: 2
Retrieved card id   = 1000
Retrieved card name = ohnaka
TIllegalArgumentException(message:Argumnent shouldn't be null)
	at jp.ohnaka.thrift.CardService$addCard_result.read(CardService.java:972)
	at jp.ohnaka.thrift.CardService$Client.recv_addCard(CardService.java:110)
	at jp.ohnaka.thrift.CardService$Client.addCard(CardService.java:85)
	at Client.main(Client.java:47)
TIllegalArgumentException(message:Card ID shouldn't be null)
	at jp.ohnaka.thrift.CardService$addCard_result.read(CardService.java:972)
	at jp.ohnaka.thrift.CardService$Client.recv_addCard(CardService.java:110)
	at jp.ohnaka.thrift.CardService$Client.addCard(CardService.java:85)
	at Client.main(Client.java:54)

カードを２つ作ったので、Num of cardが 2と帰ってきています。また、IDを指定して正しくCardオブジェクトを取得する事ができています。

addCard()メソッドに不正な引数をあたえた場合も、TILlegalArgumentExceptionがスローされている事がわかります。エラーになった理由がメッセージに含まれていて理由もよくわかりますね。

気になるポイント

なかなか強力ですね。いままでRPC上に構造体を流すのに苦労していたのが嘘のようです。Apache Thriftの強力なコード生成能力は構造体や例外を定義してこそと言えるかもしれません。

ただ、ちょっと気になる記述を公式サイト(http://wiki.apache.org/thrift/ThriftTypes)で見つけてしまいました。

Structs

Thrift structs define a common object — they are essentially equivalent to classes in OOP languages, but without inheritance. A struct has a set of strongly typed fields, each with a unique name identifier. Fields may have various annotations (numeric field IDs, optional default values, etc.) that are described in the ThriftIDL.

” but without inheritance”の部分です。継承が利用できないという事のようですが、これが本当だとすると、Cardクラスを継承したJapaneseCard, EnglishCardなどを作って addCard()メソッドで統一的追加処理を扱う事ができません。

もう少し調査が必要なようです。

今回はクライアントサイドです。こちらもJavaで動かしてみたいと思います。

ThriftでJavaのコードを生成するところは、前回でも前々回でも解説したので、今回は省略します。

# thrift --gen java TinyCalc.thrift

ってやって、TinyCalc.javaが生成できているつもりで読んでください。

Eclipseのプロジェクトを作る

今回もEclipseのプロジェクトとして作ります。通常のJavaアプリケーションプロジェクトを作ってください。プロジェクト名はthrift-test-clientとしました。

毎度ですが僕はMavenを使っているので、以下のpom.xmlを用意しました。

pom.xml

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 <modelVersion>4.0.0</modelVersion>

 <groupId>jp.ohnaka.thrift</groupId>
 <version>1.0.0-SNAPSHOT</version>
 <artifactId>thrift-test-client</artifactId>
 <name>Apache Thrift test Server</name>

 <dependencies>
  <dependency>
   <groupId>org.apache.thrift</groupId>
   <artifactId>libthrift</artifactId>
   <version>0.6.1</version>
  </dependency>

  <!-- Logging -->
  <dependency>
   <groupId>org.slf4j</groupId>
   <artifactId>slf4j-api</artifactId>
   <version>1.6.1</version>
  </dependency>
  <dependency>
   <groupId>ch.qos.logback</groupId>
   <artifactId>logback-core</artifactId>
   <version>0.9.16</version>
  </dependency>
  <dependency>
   <groupId>ch.qos.logback</groupId>
   <artifactId>logback-classic</artifactId>
   <version>0.9.16</version>
  </dependency>

  <!-- Testing -->
  <dependency>
   <groupId>junit</groupId>
   <artifactId>junit</artifactId>
   <version>4.8.1</version>
   <scope>test</scope>
  </dependency>
 </dependencies>

 <build>
  <plugins>
     <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>2.1</version>
    <configuration>
     <encoding>UTF-8</encoding>
     <source>1.6</source>
     <target>1.6</target>
    </configuration>
   </plugin>
  </plugins>
 </build>
</project>

Thrift本体のjarと、slf4jのライブラリなどを足しています。依存ライブラリとして httpclientなども入ります。最終的にMavenが解決したライブラリは以下のようになりました。

プロジェクトが生成できたら、Thriftが生成した TinyCalc.javaをソースフォルダにコピーしてください。

クライアントサイドからサービスを呼び出す

それでは早速、クライアントからサーバサイドのサービスを呼び出すコードを書いてみます。

Client.java

import org.apache.thrift.TException;
import org.apache.thrift.protocol.TBinaryProtocol;
import org.apache.thrift.protocol.TProtocol;
import org.apache.thrift.transport.THttpClient;

public class Client {

    public static void main(String[] args) throws Exception {
        // 接続先のURLを指定
        THttpClient httpClient = new THttpClient("http://localhost:8080/thrift-test-server/calc");
        // バイナリプロトコルを使用（サーバ側と合わせる）
        TProtocol protocol = new TBinaryProtocol(httpClient);
        // クライアントスタブを作成
        TinyCalc.Client client = new TinyCalc.Client(protocol);

        try {
            httpClient.open();

            // サーバ側のsumメソッドを呼び出す
            double sum = client.sum(1.0, 2.2);
            System.out.println("1.0 + 2.2 =" + sum);
            // サーバ側のsubtractメソッドを呼び出す
            double sub = client.subtract(5.3, 3.4);
            System.out.println("5.3 - 3.4 =" + sub);
            httpClient.close();

        } catch (TException e) {
            e.printStackTrace();
        }
    }

}

まずトランスポート層として、THttpClientを作ります。その際、接続先URLとして、サーバサイドで作成したサーブレットのURLを指定する必要があります。今回は http://localhost:8080/thrift-test-server/calc となります。

次に、THttpClientのオブジェクトをプロトコルハンドラに渡します。今回はサーバサイドをTBinaryProtocolにしたので、クライアント側もTBinaryProtocolを使って作成しています。

最後にThriftが生成した TinyCalc.Clientをnewします。

生成されたTinyCalc.ClientオブジェクトはTinyCalc.Ifaceを実装したクラスなので、サーバサイドで定義したTinyCalcHandlerと同じ sum()メソッドと subtract()メソッドを持っています。もうお分かりだと思いますが、クライアント側のsum()メソッドを呼び出すと、サーバ側のsum()メソッドが呼び出されるわけです。

なお、実際に呼び出す為には、THttpClientのopen()メソッドを呼んでおき、必要がなくなったらclose()する必要があります。

実行結果

Eclipseの実行メニューから Clinet.javaをJavaアプリケーションとして起動してください。

コンソールに足し算と引き算の結果が表示されました！

めでたしめでたし。

感想

動かしてみた感想ですが、導入にビルドが必要だったり、ちょっと敷居が高いかなという印象はあります。しかし、今後、さまざまな有名サービスが、「うちのAPIはこれです」といって Thriftの定義ファイルを公開するのがトレンドになるかもしれません。

もしそういう時代になったら、「エンジニアが手元に Thriftをインストールしておくのは常識」と言われるようになるかもしれませんね。

僕は今までRPCを作る時は、XML-RPCを使う事が多かったです。XML-RPCもプラットフォーム非依存なRPCなのですが、実際にはXML−RPCの拡張モードを使わないと、オブジェクトや例外の伝送ができません。僕はクライアントもサーバもJavaだったということもあって、 拡張モードを使ってしまっていたのですが、これだと他の言語から呼び出すのは難しくなります。

Thriftではプリミティブ型だけでなく、構造体も定義できるようなので、互換性を失わずにXML-RPCの拡張モードのような事ができます。また、コード生成のサポートがあるので、構造体に対応した値クラスの定義などを言語ごとにいちいち作る必要もありません。

次回はこの構造体のあたりや例外の扱いを試してみたいと思います。

今回は実際に生成されたコードを動かしてみたいと思います。Thriftを使えばいろんな言語のコードが生成できるのですが、まずは僕のメイン言語であるJavaのコードを生成して、サーバとして動かしてみたいと思います。

ちなみにThriftを解説したページを探すと、JavaサーバとしてTomcatなどのサーブレットコンテナを使わず、Thriftが用意しているTThreadPoolServerクラスなどを使ってスタンドアロンアプリとして動かす方法が多く見受けられます。

ちょっとしたテストには良いと思うのですが、本番サービスで使うには運用面などで不安があります。SSLにしたい場合はどうすればいいんでしょう？証明書は？できるのかもしれませんが、蓄積した運用ノウハウが行かせません。

それに、専用のポートをThriftのサーバで占有されるのも困ります。ロードバランサなども個別に設定する必要が出てきます。

本記事では、ThriftのサーバサイドコードをServletとして動かす方法を解説します。

Javaのコードを生成する

前回の記事の最後の部分ですが、おさらいです。

まずは、Thriftの定義ファイルを書きます。前回同様、木村俊也氏のブログ記事「Thriftが便利すぎる」からお借りします。

TinyCalc.thrift

#!/usr/bin/thrift

service TinyCalc
{
        double sum(1: double param1, 2: double param2)
        double subtract(1:double param1, 2:double param2)
}

メソッド名を見てお分かりの通り、２つの実数の「加算」と「減算」をするサービスを定義しています。

ではThriftでJavaのコードを生成します。

# thrift --gen java TinyCalc.thrift

上記コマンドを実行すると、gen-javaというサブディレクトリが生成され、中にTinyCalc.javaというファイルが生成されます。

Eclipseのプロジェクトを作る

たぶんみなさんEclipseを使っていると思うので、Eclipse上で動かしてみましょう。まずは、Dynamic Web Projectを生成します。プロジェクト名は thrift-test-serverとしました。

僕はEclipseのプロジェクトもMavenで管理するのが好きになってしまったので、次のようなpom.xmlをプロジェクトのルートに置き、Dependency ManagementをONにします。

pom.xml

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 <modelVersion>4.0.0</modelVersion>

  <groupId>jp.ohnaka.thrift</groupId>
 <version>1.0.0-SNAPSHOT</version>
 <artifactId>thrift-test-server</artifactId>
 <packaging>war</packaging>
 <name>Apache Thrift test Server</name>

 <dependencies>
  <dependency>
   <groupId>org.apache.thrift</groupId>
   <artifactId>libthrift</artifactId>
   <version>0.6.1</version>
  </dependency>

  <!-- Servlet -->
  <dependency>
   <groupId>javax.servlet</groupId>
   <artifactId>servlet-api</artifactId>
   <version>2.5</version>
  </dependency>

  <!-- Logging -->
  <dependency>
   <groupId>org.slf4j</groupId>
   <artifactId>slf4j-api</artifactId>
   <version>1.6.1</version>
  </dependency>
  <dependency>
   <groupId>ch.qos.logback</groupId>
   <artifactId>logback-core</artifactId>
   <version>0.9.16</version>
  </dependency>
  <dependency>
   <groupId>ch.qos.logback</groupId>
   <artifactId>logback-classic</artifactId>
   <version>0.9.16</version>
  </dependency>

  <!-- Testing -->
  <dependency>
   <groupId>junit</groupId>
   <artifactId>junit</artifactId>
   <version>4.8.1</version>
   <scope>test</scope>
  </dependency>
 </dependencies>

 <build>
  <plugins>
     <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>2.1</version>
    <configuration>
     <encoding>UTF-8</encoding>
     <source>1.6</source>
     <target>1.6</target>
    </configuration>
   </plugin>
   <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-war-plugin</artifactId>
   </plugin>
  </plugins>
 </build>
</project>

ようは Thrift本体のjarと、Thriftによって生成されたコードが使用している slf4jのライブラリを追加しているだけです。Mavenを使っていない人はそれらの jarを手動でプロジェクトに追加してください。

プロジェクトの設定が終わったら、生成されたTinyCalc.javaをソースフォルダにいれます。生成されたコードはディフォルトパッケージに所属しているので、必要があればリファクタリングしましょう。今回はそのままにしておきます。

サーバサイドの実装を記述する

Apache Thriftがコードを自動生成してくれるといっても、あくまでインターフェースや通信制御の部分であって、実際の処理は自分で書く必要があります。

Thriftが生成してくれたTinyCalcというJavaクラスの中には、TinyCalc.Ifaceという内部インターフェースが定義されています。サーバサイドの処理は、このインターフェースを実装したクラスに書きます。

ここでは、TinyCalcHandlerというクラスにします。

TinyCalcHandler.java

import org.apache.thrift.TException;

/**
 * TinyCalcのサーバサイド実装
 */
public class TinyCalcHandler implements TinyCalc.Iface {

    /**
     * 2つの引数を足してその値を返します。
     */
    @Override
    public double sum(double param1, double param2) throws TException {
        return param1 + param2;
    }

    /**
     * 1つ目の引数から2つ目の引数を引いてその値を返します。
     */
    @Override
    public double subtract(double param1, double param2) throws TException {
        return param1 - param2;
    }
}

TinyCalcServlet.java

次に、このサービスへの呼び出しを受け付けるサーブレットを用意します。最新のThriftにはTServletというクラスが用意されていて、それを継承すると簡単にサーブレットを作る事ができます。

import org.apache.thrift.protocol.TBinaryProtocol;
import org.apache.thrift.server.TServlet;

/**
 * TinyCalcサービスへの呼び出しを受け付けるサーブレット
 */
public class TinyCalcServlet extends TServlet {
    private static final long serialVersionUID = 1L;

    public TinyCalcServlet() {
        // Binary Protocolを扱うサーブレットとして初期化する
        super(new TinyCalc.Processor(new TinyCalcHandler()), new TBinaryProtocol.Factory());
    }
}

TServletを継承したら、上記のようにデフォルトコンストラクタを実装し、TServletのコンストラクタを呼び出します。

super()の第一引数には、サービスの実処理を渡します。つまり先ほど記述したTinyCalcHanderなのですが、直接 TinyCalcHandlerを渡すのではなく、Processorでラップして渡します。ProcessorクラスもThriftによって生成された TinyCalc.Processorクラスを用います。

super()の第二引数には、プロトコルファクトリを渡します。これによってThriftのクライアントとの通信をどういうプロトコルで行なうかが決まります。プロトコルと言ってもHTTPとかFTPとかではなく、HTTPの上にどういうデータを流すか、という意味です。

Thriftが用意しているプロトコルには以下のようなものがあります。(Wikipediaより引用)

• TBinaryProtocol
• A straight-forward binary format encoding numeric values as binary. It is faster than the text protocol but more difficult to debug.
• 数値をバイナリフォーマットで直接的に表現するプロトコル。数値をテキストで表現するプロトコルよりも高速ですが、デバッグが難しくなります。
• TCompactProtocol
• Very efficient, dense encoding of data.
• とても効率的に、濃密にデータをエンコードするプロトコル。
• TDebugProtocol
• Uses a human-readable text format to aid in debugging.
• デバッグのしやすさのために、ヒューマンリーダブル(人間が読みやすい)なテキストフォーマットを用いるプロトコル。
• TDenseProtocol
• Similar to TCompactProtocol, striping off the meta information from what is transmitted.
• TCompactプロトコルにしていますが、転送データからメタ情報を除去したものです。
• TJSONProtocol
• Uses JSON for encoding of data.
• データのエンコーディングにJSONを用いるプロトコル
• TSimpleJSONProtocol
• A write-only protocol using JSON. Suitable for parsing by scripting languages.
• スクリプト言語でパースするのに適した、JSONを用いた書き込み専用のプロトコル。

今回は最初のTBinaryProtocolを用いましたが、別のものを用いても大丈夫です。ただし、クライアント側とプロトコルを合わせるのを忘れずに。

web.xml

サーブレットの 準備ができたら、実際に配備してみましょう。今回は /calcというパスに配備してみました。

web.xmlはこんな感じになります。

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" id="WebApp_ID" version="2.5">
  <display-name>thrift-test</display-name>

  <servlet>
  <servlet-name>TinyCalcServlet</servlet-name>
  <servlet-class>TinyCalcServlet</servlet-class>
  </servlet>

  <servlet-mapping>
  <servlet-name>TinyCalcServlet</servlet-name>
  <url-pattern>/calc</url-pattern>
  </servlet-mapping>
</web-app>

配備して実行する

念のため、EclipseのProject Explorerのスクリーンショットを載せておきます。

すべてのファイルが準備できたら、Tomcatなどのサーブレットコンテナに配備して起動してみて下さい。エラーが出なければひとまずOKです。

次のエントリで、実際にクライアントから繋いでみましょう。

いったいどんな事ができる技術なんでしょうね？

「習うより慣れろ」

ということで、とにかく動かして雰囲気を見てみましょう。

僕もちょっと触ってみただけですが、情報が分散していてわかりにくかったので、自身のメモを兼ねて、動かすまでの手順を書いてみたいと思います。

Apache Thriftってなに？

Thrift自体はいろいろな方がその特長を書かれているのでこちらをどうぞ。

• Wikipedia「Thrift (プロトコル)」
• Thriftが便利すぎる
• @IT 「巨大SNSを支える多言語混在RPC開発フレームワーク“Thrift” 」

簡単に言えば、

「Java, C++, Python, Ruby…などなど、さまざまな言語で相互にサービスを呼び合う事のできるRPCフレームワーク」

って感じでしょうか？

Thriftが生まれた背景

最近のトレンドとして、WebサービスがAPIを公開するといえば「RESTful」がお約束です。情報の取得、作成、更新、削除をHTTPのGET,POST,PUT,DELETEで行なおうという者です。

そのおかげで、とにかくHTTPさえ叩ければいろんなサービスのAPIを繋いであれこれできちゃう世の中になった訳ですが、問題が無い訳ではありません。

いかに「RESTfulなAPI」といってもすぐに呼び出せる訳ではありません。理由は、HTTPの上を流れるデータフォーマットがサービスによってまちまちな為です。そのため、サービスごとに使用を調べ、パースしたり生成したりするコードを書く必要があります。

そういうところをかっちり決めなくていいところが緩くて嬉しいわけですが、「サービスAは独自のXMLで、サービスBはATOMで、サービスCはJSONで、、、」となっていると、結構大変です。実際には、それぞれのサービス提供事業者がAPIアクセス用のライブラリを提供してくれているので、それをダウンロードしてきて組み込めばよいようになっているのが普通です。

でも、自分が使いたい言語のライブラリを提供してくれているとも限らないのが痛いところ。

「この処理はPythonで書けばあっという間なのに、クライアントライブラリが PerlしかないからPerlで書くか、、、」

といった残念なシチュエーションが生まれている訳です。

そこで出てきたのがThriftです。

「だったらAPIの呼び出しライブラリは自動生成しちゃえば？サーバだって自動生成しちゃうよ。そうすればサービスロジックの作成に専念できるじゃない」

という考え方がThriftの発想です。

ちなみにThriftはHTTPを使いますが、RPCの発想（メソッド呼び出し）なので、いわゆるRESTfulなサービスとは異なる事に注意してください（たぶん）。

Thriftの開発環境をMacOS Xにインストールする

Thriftはコードを自動生成してくれるわけですが、その自動生成用のプログラムをビルドしてインストールする必要があります。ここでは、Thrift-0.6.1をMacOS X 10.6.8にインストールする手順を示します。

Xcodeのインストール

MacOS XにCコンパイラが入っている必要があります。これはAppleから配布されているXcodeを入れれば入ります。入れていない人はまずこれを入れましょう。

MacOS X Lionの人ならばMac App Storeから Xcodeを無料でインストールできます。

boostライブラリのインストール

boostライブラリと言うのはC++で便利にプログラミングする為のライブラリです。これが無いとC++用のコードが生成できないようなので、まずはこれを入れましょう。

http://www.boost.org/ から最新のソースコードをダウンロードしてください。執筆時の最新版は、1.47.0です。ここでは、boost_1_47_0.tar.gzをダウンロードして、適当なフォルダで展開します。

# tar zxvf boost_1_47_0.tar.gz

展開されたディレクトリに移動します。

# cd boost_1_47_0

boostのビルドのお約束コマンド、bootstrap.shを実行しましょう。

# ./bootstrap.sh

すると、カレントディレクトリにb2というコマンドがつくられます。これを実行するとビルドが走ります。

# ./b2

これで終わりではありません、さらにbjamというコマンドを走らせます。

# ./bjam
Performing configuration checks

    - has_icu builds           : no
warning: Graph library does not contain MPI-based parallel components.
note: to enable them, add "using mpi ;" to your user-config.jam
    - ../config//has_gcc_visibility builds : yes
    - ../config//has_long_double_support builds : yes
warning: skipping optional Message Passing Interface (MPI) library.
note: to enable MPI support, add "using mpi ;" to user-config.jam.
note: to suppress this message, pass "--without-mpi" to bjam.
note: otherwise, you can safely ignore this message.

こんなメッセージが出て止まってしまいました。指示通り、user-config.jamを修正します。

# vi tools/build/v2/user-config.jam

最後の行に、以下の設定を追加します。

using mpi ;

改めて bjam コマンドでビルドを進めます。

# ./bjam

うまくビルドできたらインストールします。ルート権限が必要なので、sudoを付けるのを忘れずに。

# sudo ./bjam install

Apache Thriftのビルド

Apache Thriftのサイトから最新版(0.6.1)のソースコードをダウンロードしてきて、展開します。

# tar zxvf thrift-0.6.1.tar.gz

中に入って、、

# cd thrift-0.6.1

こんふぃぎゅあー。

# ./configure

2011/9/1 追記。
thrift-0.7.0が出ていたのでビルドしようとしたら configureに実行可能フラグが立っておらず、ビルドできませんでした。どうもアーカイブか壊れている気がします。他のファイルも怪しいです。
install-shも実行可能になってませんね。以下のコマンドで修正してください。
chmod +x configure install-sh

めーく。

# make

あらら、、、

/usr/libexec/gcc/powerpc-apple-darwin10/4.2.1/as: assembler (/usr/bin/../libexec/gcc/darwin/ppc/as or /usr/bin/../local/libexec/gcc/darwin/ppc/as) for architecture ppc not installed
Installed assemblers are:
/usr/bin/../libexec/gcc/darwin/x86_64/as for architecture x86_64
/usr/bin/../libexec/gcc/darwin/i386/as for architecture i386
src/protocol/fastbinary.c:1203: fatal error: error writing to -: Broken pipe
compilation terminated.
lipo: can't open input file: /var/folders/n0/n07PPobvF1uOeeW-ljfg8U+++TI/-Tmp-//ccSB6lR0.out (No such file or directory)
error: command 'gcc-4.2' failed with exit status 1
make[3]: *** [all-local] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
Exit 2

コンパイルが止まってしまいました。ググってみたところ、こんなページが見つかりました。

どうやらXcode4になって、PowerPC用のアセンブラが無くなってしまったらしく、そのせいで止まっているようです。Intel Macなので、Intel用のコードだけ作ってくれれば良いのですが、CPUのアーキテクチャタイプを正しく検出していないためにPowerPCのコードもビルドしようとしているようです。

先ほどのサイトには Thriftのtrunkに対するパッチも提供されているので、次のバージョンくらいではうまくビルドできるようになっているかもしれませんが、当面は以下の対症療法で回避してください。

# cd lib/py
# sudo ARCHFLAGS="-arch x86_64" python setup.py install

これがうまく動いたら、Thriftをインストールしましょう。元のディレクトリに戻ってください。

# cd ../..
# make
# sudo make install

さて、これで /usr/local/bin あたりに thriftというコマンドがインストールされたはずです。thriftコマンドを起動してみましょう。パスが通っているか確認して実行してみてください。tcshを使っている人はrehashしたりするのを忘れずに、、、。

# thrift
Usage: thrift [options] file
Options:
  -version    Print the compiler version
  -o dir      Set the output directory for gen-* packages
               (default: current directory)
  -I dir      Add a directory to the list of directories
                searched for include directives
  -nowarn     Suppress all compiler warnings (BAD!)
  -strict     Strict compiler warnings on
  -v[erbose]  Verbose mode
  -r[ecurse]  Also generate included files
  -debug      Parse debug trace to stdout
  --gen STR   Generate code with a dynamically-registered generator.
   :
   :

こんな感じでヘルプが表示されたら成功です。

Thriftを使ってJavaのコードを生成してみる

僕のメイン言語はJavaなので、ひとまずJavaのコードを生成してみます。木村俊也氏のブログ記事「Thriftが便利すぎる」のインターフェース定義をお借りして、コードを生成してみました。

適当なフォルダに以下の定義ファイルを作成します。

TinyCalc.thrift

#!/usr/bin/thrift

service TinyCalc
{
        double sum(1: double param1, 2: double param2)
        double subtract(1:double param1, 2:double param2)
}

簡単な足し算と引き算をするサービスです。

この定義ファイルを使ってJavaのコードを生成します。

# thrift --gen java TinyCalc.thrift

実行すると、gen-javaというフォルダが作成され、その中にTinyCalc.javaというファイルが１つ出来ています。実はこのソースコード、これ一つでクライアントサイドとサーバサイドで必要な全てのコードが入っています。中身を見てちょっとびっくりしてしまったんですが、1つのTinyCalcクラスの中に、7個の静的クラスと2つのインターフェースが盛り込まれています！

このクラスを使って実際にRPCの呼び出しをしてみたいと思いますが、ちょっと長くなってきたので、次のエントリで解説します。

エディタ内の文字サイズは環境設定から変える事ができますが、そこじゃなくて、タブに表示される文字のサイズや、パッケージエクスプローラのツリー表示などで使用されているシステム文字です。

僕は日本語版のFlashBuilderを使っているのですが、どうもシステム文字の大きさがアンバランスで、デザイン的に間抜けな感じに見えてしまいます。FlashBuilderのベースとなっているEclipseの方は英語版を使っているのですが、こちらは違和感ありません。以前Eclipseを日本語化した時も似たような違和感を感じた事があったので、日本語フォント特有の問題なのかと思っていました。

FlashBuilderの初期化ファイルにちょっと手を入れると、引き締まったフォントサイズにする事ができます。

「Adobe Flash Builder 4.5.app」を開く

アプリケーションフォルダにFlashBuilderをインストールしているのであれば、まず、「アプリケーション」フォルダの中の、「Adobe Flash Builder 4.5」というフォルダを開きましょう。その中に、いつも起動しているAdobe Flash Builder 4.5.appというアプリケーションがあります。

それを右クリック（もしくはCtrl + クリック）し、「パッケージの内容を表示」というメニューを選択します。

「Adobe  Flash Builder 4.5.ini」を編集する

パッケージの内容を開いたら「Contents」というフォルダが出てくるのでそれを開きます。

さらに「MacOS」というフォルダを開くと「Adobe Flash Builder 4.5.ini」というファイルが見えてきますので、それを右クリックして、「テキストエディット」などのアプリケーションで編集します。

よくわからない場合は、「ターミナル」アプリケーションで以下のコマンドを入力しましょう。

open -a /Applications/TextEdit.app /Applications/Adobe\ Flash\ Builder\ 4.5/Adobe\ Flash\ Builder\ 4.5.app/Contents/MacOS/Adobe\ Flash\ Builder\ 4.5.ini

プロパティを追加

Adobe Flash Builder 4.5.iniが開けたら、最後の行に、以下の記述を追加します。

-Dorg.eclipse.swt.internal.carbon.smallFonts

全体では次のような感じになります(バージョンによって多少違うかもしれません)。

-nl
ja_JP
-startup
../../../eclipse/plugins/org.eclipse.equinox.launcher_1.1.0.v20100507.jar
--launcher.library
../../../eclipse/plugins/org.eclipse.equinox.launcher.cocoa.macosx_1.1.1.R36x_v20100810
--launcher.defaultAction
openFile
-showsplash
../../../assets/fb_splash_premium.png
-vmargs
-Xms256m
-Xmx512m
-XX:MaxPermSize=256m
-XX:PermSize=64m
-Xdock:name=Flash Builder
-Xdock:icon=../Resources/fb_app.icns
-XstartOnFirstThread
-Declipse.product=com.adobe.flexbuilder.standalone.producte36
-Declipse.application=com.adobe.flexbuilder.standalone.FlashBuilderApplication
-Dorg.eclipse.swt.internal.carbon.smallFonts

これでフォントが少し小さくなります。

比較

変更前

右上の「Flashデバッグ」パースペクティブのタブが、文字が入りきらずに「Flashデバ…」みたいになってしまってます。

変更後

変更後はちゃんとタブの中に収まっています。ツリー表示も引き締まっていていい感じですね。

ただ、ちょっとしたデバッグUIを作りたい時など、Strutsだとちょっと大げさな感じになってしまいます。そんなわけで「軽量フレームワーク」と言われるApache Wicketをちょこちょこと試しています。

Wicketの入門はCodeZineとかマイコミジャーナルとかに詳しく載っています。

このあたりのチュートリアルに従って簡単なアプリを作ってみたのですが、一番最初にびっくりしたのが「URLがきもちわるい！！」という事でした。

たとえば、あるスタティックなページのURLが、

http://localhost:8080/wicket-test/?wicket:bookmarkablePage=:jp.ohnaka.wicket.SubPage

こんな感じになってしまうのです。長いし、パッケージ名やクラス名までまるわかりだし、これを見た時に「やっぱりやめようかな、、、」とまで思ってしまったのですが、大丈夫、ちゃんと好みのスタイルに変更する事ができました。

以下そのメモです。

Wicketで簡単なアプリを作る

まず、IndexページとSubページの２つからなるwicket-testという簡単なアプリを作ります。

なお、Wicketは1.4.17を使っております。Wicketはバージョンが変わると前のバージョンの機能がすぐに使えなくなったりするので、この情報もすぐに古くなってしまうかもしれません、、、。悪しからず。

web.xml

まずはweb.xmlから。Strutsなどと同じように、Wicketも Servlet Filterとして動作します。フィルタを /* に対して設定しているため、このWebアプリケーションはパス全体がWicketの配下に入りますが、 /debug/* などに変更すれば、特定のパス以下だけでWicketを動作させる事もできます。

Servlet Filteraのinit-paramにはアプリケーションクラス名を設定してください。今回はjp.ohnaka.wicket.TestApplication クラスにしました。

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" id="WebApp_ID" version="2.5">
  <display-name>wicket-test</display-name>

  <filter>
   <filter-name>wickletFilter</filter-name>
   <filter-class>org.apache.wicket.protocol.http.WicketFilter</filter-class>
   <init-param>
    <param-name>applicationClassName</param-name>
    <param-value>jp.ohnaka.wicket.TestApplication</param-value>
   </init-param>
  </filter>

  <filter-mapping>
   <filter-name>wickletFilter</filter-name>
   <url-pattern>/*</url-pattern>
  </filter-mapping>

</web-app>

jp.ohnaka.wicket.TestApplication クラス

Wicketで作るWebアプリの大元、メインクラスです。

getHomePage()メソッドでは、コンテクストルートにアクセスした場合に表示するページ(今回はIndexPage)を返すようにしています。

package jp.ohnaka.wicket;

import org.apache.wicket.Page;
import org.apache.wicket.protocol.http.WebApplication;

public class TestApplication extends WebApplication {

    @Override
    protected void init() {
        super.init();
    }

    @Override
    public Class<? extends Page> getHomePage() {
        return IndexPage.class;
    }

}

jp.ohnaka.wicket.BasePageクラス

２つのページの基底クラスとなるクラスです。基底クラス無しで直接書いても良いのですが、IndexPage.htmlとSubPage.htmlの共通部分をBasePage.htmlに抜き出したいので、対応するJavaクラスの方も基底クラスを作るようにしています。

package jp.ohnaka.wicket;

import org.apache.wicket.markup.html.WebPage;

public class BasePage extends WebPage {
    public BasePage() {
    }
}

jp.ohnaka.wicket.IndexPageクラス

IndexPageのロジックです。SubPageへのリンクを埋め込んでいます。

package jp.ohnaka.wicket;

import org.apache.wicket.markup.html.link.BookmarkablePageLink;

public class IndexPage extends BasePage {
    public IndexPage() {
        // SubPageへのリンクを作成する
        add(new BookmarkablePageLink<Void>("linkToSubPage", SubPage.class));
    }
}

jp.ohnaka.wicket.SubPageクラス

SubPageのロジックです。IndexPageに戻れるように、IndexPageへのリンクを埋め込んでいます。

package jp.ohnaka.wicket;

import org.apache.wicket.markup.html.link.BookmarkablePageLink;

public class SubPage extends BasePage {
    public SubPage() {
        // IndexPageへのリンクを作成する
        add(new BookmarkablePageLink<Void>("linkToIndexPage", IndexPage.class));
    }
}

/jp/ohnaka/wicket/BasePage.html ファイル

IndexPageとSubPageのHTMLの共通部分を抜き出したファイルです。<wicket:child/>の部分がサブクラスのHTMLと差し変わります。

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html xmlns:wicket="http://wicket.apache.org/">
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <title>Wicket Test</title>
</head>
<body>
    <wicket:child/>
</body>
</html>

/jp/ohnaka/wicket/IndexPage.html ファイル

IndexPageのHTMLです。BasePage.htmlの<wicket:child/>タグがこの<wicket:extend>の内容と置き換わります。

<wicket:extend>

<a href="#" wicket:id="linkToSubPage">SubPageへ</a>

</wicket:extend>

/jp/ohnaka/wicket/SubPage.html ファイル

SubPageのHTMLです。IndexPageとほとんど同じですね。

<wicket:extend>

<a href="#" wicket:id="linkToIndexPage">IndexPageへ</a>

</wicket:extend>

デフォルトのページURLのスタイル

早速配備して動かしてみました。http://localhost:8080/wicket-test/ にアクセスするとIndexPageが表示されます。

SubPageへのリンクをクリックすると、SubPageに遷移します。

ブラウザのアドレス部を見て頂ければわかりますが、冒頭に書いたように、非常に長いURLになっています。SubPageクラスのFQCNがもろに見えている形になっていて、美しくありません。パッケージ名をリファクタリングしたらURLも変わってしまいますし、何より、実装がエンドユーザに見えてしまうのはあまり良い事ではないです。

ページのURLを固定する

SubPageのURLを http://localhost:8080/wicket-test/sub というURLにしてみたいと思います。具体的には、TestApplicationクラスを以下のように修正します。

package jp.ohnaka.wicket;

import org.apache.wicket.Page;
import org.apache.wicket.protocol.http.WebApplication;

public class TestApplication extends WebApplication {

    @Override
    protected void init() {
        super.init();
        mountBookmarkablePage("/sub", SubPage.class);
        // mountPage("/sub", SubPage.class);  //Wicket 1.5系の場合
    }

    @Override
    public Class<? extends Page> getHomePage() {
        return IndexPage.class;
    }

}

変わったのは init()メソッドの中です。

mountBookmarkablePage("/sub", SubPage.class);

という記述が増えています。

メソッド名に「mount」とありますが、このようにページのURLを変ええる操作はWicketでは「ページをマウントする」と言うようです。UNIXでもディスクドライブをあるパスに配備する事を「マウント(mount)」と言いますが、それと同じような感じで、SubPageというクラスを /sub というパスにマウント(配備、設置)するわけです。

この「マウント」という名前(概念)に行き着くまでに時間がかかってしまい、検索するのに結構苦労しましたがもう大丈夫です。「wicket mount」などで検索すると、他にもいろいろな応用技が見つかります。

• WicketのURLをcoolにする
• Wicketが生成するアドレスを今風(?)にする

ただ、Wicketのマウントの仕様はバージョンごとに少しずつ変わっているので、古いバージョンの情報の通りには動かない事があります。その場合は本家サイトでmountというキーワードを頼りにドキュメントを探してみてください。

【追記】Wicket 1.5系の場合

おおたさんよりコメントのあった通り、1.5系では mount系のメソッドが大きく変わっているようです。

今回のコードに関しては、以下のようにmountBookmarkablePageメソッドを mountPageメソッドに置き換える事で1.5対応ができました(1.5-RC5.1で確認)。

mountPage("/sub", SubPage.class);