と、強がってはいるものの、やはりガチガチすぎるとも感じてます。
例えば、「データTABLEを縦ではなく横にしたい」だけなのに、異様なほどたくさんのコードとAPIを駆使しなければなりません。
案件によっては、JSFの採用を見送る場合が出てくると思う。

で、そんな中、GrailsとWicketがそれぞれEJB3との統合に動き出してるという記事がありました。

・Grails + EJB Domain Models Step-by-Step

将来GrailsがHibernate依存をやめてくれたら、ぜひとも使いたい組み合わせです（個人的にはHibernateは捨てたい）。

最近は コンポーネント指向Webフレームワーク ばかりが隆盛してますけど、やっぱり、URL-メソッドバインディングなフレームワークが必要なのではないかと思います。簡単で、しかもWeb・HTTPとしての自由度がある。Rails系はそういうフレームワークなんですよね。

ただ、Java6 ScriptingやJRubyが盛り上がってる中、Groovyの存在意義って、持続するのか？このあたりが、もう一つの悩みどころです。

・wicket-contrib-javaee

Wicketはデータ層で競合してるわけではないので、素直にJPAと連携できるとは思うのですが、なぜかわざわざこんな記事ができてました。要は、「意識してるよ！」という宣言なのかもしれません。

Wicketも悪くはないのですが、同系統なら、Clickの方が好き。サイトをみると、サンプルも豊富で、スグにでも使いたくなります。
今現在、「作りやすいもので作る」ことだけを考えると、Clickを選ぶだろうと思います。でも、マイナーなんだろうな。

小生、山形という、Javaの普及はこれからであろう土地で仕事をしています。プロジェクトメンバーがJava初心者１０人、だとしたら、JSFで直ぐにプロジェクトを開始できるだろうか？私には自信がありません。

でもJSFの代替、どれを選ぶのが確実なのか、混沌としている。
Strutsを選んだころは、それしかなかったし、幸運にもデファクトになってくれたので良かったのですが、今はどれを選べば「５年もつ」のでしょうか。

いつ消えるかもしれないフレームワークよりは、多少苦労しても、JSFを選ぶべきか。限られたリソースで、めっちゃ効率良く、長く使えるシステムを作るには・・・

・・・う～ん・・・。