>>433

いくつかフレームワークを検討してきたが、
採用を決定する前にFit/Gapの検証は十分にすべき。
# これはどんなフレームワークに対しても言える事だけれど

楽々FWは画面構成を含めて､かなりの部分のViewまでを規定
する。ツール&自動生成を使用してJSPを生でコーディングする
ようなことをさせない作りだ、といえばイメージがわくかな?
(なおJSP使わない。つまりServlet内部でprintしている)

つまるところ、あなたが望んでいる「フレームワークの抽象度」が
キーポイントだろう。
オリジナルフレームワーク作成のためのフレームワークといって
良いぐらいの抽象度の高いStrutsにくらべてかなりその度合いが低い。
思い通りの画面構成・部品をつくりたい、凝った画面構成を実現したい…
というならその時点でアウトになってる恐れがある。

まあ個人的には…楽々FWはあまり勧めない。
J2EEも1.3になろうかという時期にアーキテクチャが古いのが
どうしても将来性の観点で気になった。具体的に少し挙げるなら、

DB接続のコネクションプーリングをアプリケーションサーバの
DataSouceではなく自前で実装していたり(理由はあるんだろうが
色々な意味でもはや利点はなくむしろ有害な場合もでてくるだろう)

サーブレット呼び出しをURLマッピングではなくクラス名呼び出しで
行うようになっているなど(フレームワークとしてそうなっている!)。

特に後者は言いようの無い不安を感じる。Invokerサーブレットによる
クラス名実行は既にdeprecatedとなる方向にある(少なくとも
一般的には本番環境ではdisableにするべき、とされている設定だろう)ことに加え、
ServletAPI2.3からのFilterが使えないことにつながってしまうからだ。

そうそう､言い忘れていたがStrutsのActionServletのような窓口となる
サーブレットではなく、1処理(1画面)1サーブレットの形態をとっている。

こんなところかな。