SAStrutsコードリーディング #0 準備編

クラスが少なくて小さいと何が嬉しいのか？
[中略]
内部構造の見通しが良くて把握しやすいため、各プロジェクト、各企業で独自拡張しやすい
StrutsからSAStrutsへ　〜 Seasar Conference 2008 Spring 出羽さん資料〜

全く同感です。といいつつ・・・
SAStrutsについては、たまに訳文をコミットしてるのですが、実はコミットされた差分を見るのも精一杯で、元のコードをちゃんと読んでない！ということを最近痛感しつつあります。よって、ぼちぼち勉強と称して改めて読みつつ、だらだらエントリすることにします。題して「脱・コミットログストーカー計画」。

エントリポイント：どこから読んだらよいか

いつぞや描いた図を再掲します。(あ、これドキュメントに追加しようと思ってたんだった)

SAStrutsはStrutsをベースに拡張されており、そのStrutsはServletベースのWebアプリとして動くものなので、結局Servletのエントリポイントたるweb.xmlから読んでいけばいいことになります。
見ると、いくつかのfilterとservletが登録されていますが、パッケージ名を見ると、SAStrutsに特徴的なクラスは、org.seasar.strutsで始まるパッケージの「RoutingFilter」「S2ModuleConfigFactory」だとわかります。

このうちS2ModuleConfigFactoryのソースを見ると、これはStruts標準のModuleConfigに関連したクラスのようです。どうも、struts-config.xmlに何も書かなくていい代わりに、このクラスが基点となって、アクションの情報をStrutsに初期登録しているように見えます。

一方、RoutingFilter#doFilter()のほうを見ると、実際にリクエストがあったタイミングで、パスに基づいていろんな判定を行っていて、その結果によって呼ばれるべきアクションを組み立てなおしてforwardされています。

何か動作を調べたい場合は、これらの２つのクラスが起点になりそうです。

頻出コード例

以下の短いコードは、細部は異なりますが、あちこちに出てきます。

if (container.hasComponentDef(sb + names[i] + "Action")) {
 String actionPath = RoutingUtil.getActionPath(names, i);
 String paramPath = RoutingUtil.getParamPath(names, i + 1);

これはパスをnamesという配列に分解した後、パスに相当するアクションのコンポーネントがS2コンテナに存在するかどうかを、１行目で確認しています。存在した場合、そこまでをアクションのパス、それ以降をパラメタとして取り扱う、といった具合です。
//でいいんだっけと思いながら書きました。あとでもしかしたら直します。
以上！寝なきゃいけないので尻切れトンボ御免です。

次回

次回は、RoutingFilterの中身を追っていき、パスがどのようにアクションやメソッドに対応づけられているのかを見ていきます。
もし次回があるとしたらの話ですが^^;