と思ったけど、やっぱSlim3の中をちょっとだけ読んでみた。

sa-strutsの簡単な流れをいうと、
diconとかその辺の設定はちゃんとなっているとして、

…あれ？俺よくsa-strutsがどう動いているかしらないなぁ。

convention.diconにroot.pacakgeを記述
↓
ソースディレクトリにroot.packageと同じパッケージを掘る。
↓
その下にaction(formとかserviceとかもたいてい切るけど)パッケージを切る。
↓
ブラウザからアクセスする。
↓
URLからいい感じに対応するActionがターゲットとして選ばれる。
↓
実行し、JSPのパス？を返す
↓
いい感じにJSPにforwardされる
↓
画面出る。

いい感じというのはすべて命名規則によって成り立っている（？）。

というのを踏まえてSlim3を読んでみたら意外と簡単だった。

とりあえずパッケージ内を見てみたら、
IndexControllerって言うのがあった。
Indexというくらいだから、/のときに呼ばれるのだろう。
じゃぁ誰が…ここであまり知識が無いので迷ったのだが、まぁweb.xmlだろう。
中を見るとFilterがいくつかある。
HotReloadingFilterが、うーむこれはHotDeployは使えないけど、
Actionだけは出来るようにした　とかいうやつだろう。

DatastoreはBigtableを使うやつかな？まだそこまで行っていないからいいや。

そうするとFrontController。
ははーん、これだなｗ
中を見る。
ぁぁ(゜Д゜)わからねぇｗ

よーし、デバッグしよう。
ブレークポイント…無視、(´；ω；｀)

ここがJAVAとかEclipseを中途半端にしか分かっていないせいなんだけど、
Tomcatとかは基本Debugモードで動いているじゃまいか。
本ちゃんモードもあるけど。
なのでGoogleのWEBサーバーもそうなのかと思ったけど、
実行から起動しているからデバッグにならないだけで、
デバッグから起動すればデバッグできるのねー。

FrontControllerのFilterのdoFilterに対してブレーク。
中を根気よく除いていったら、newInstance発見。
Seasar2系はリフレクションばっかだもんで、これで決まりだｗ
んでControllerのrunを呼び、ユーザーのIndexControllerのrunが呼ばれて、
JSPのパスが書いてあるNavigationが返ってくる。
それをまた根気よく掘り進んでいくと、
ServletContextからforwardしているところがあるので、
これにてJSPとつながりました。

なるほど、こうやって動いているのですなぁ。

次は、JSPからどうやって変数を参照しているのかを見て、
実際にSlim3を使ってみよう。

結局、sa-strutsと同じだった、そりゃそうか。