自分は，JSPが好きかキライかっていうと...
例えば，pageディレクティブのpageEncodingで，
<%@page pageEncoding="Windows-31J" %>
にしておかないと，JSP中にハードコードした機種依存文字がtranslation-timeんときに化けるとか，
JSPの文字化けポイントは，
- JSPにハードコードした文字（pageディレクティブのpageEncodingで解決）
- サーバからJSPに貼り付ける文字（pageディレクティブのcontentTypeで解決）
- クライアントからサーバに送る文字（JSPプロパティグループのinput-charsetで解決）
だったはず。
includeディレクティブで読み込まれるJSPは，拡張子を「*.jsp」以外にしていないと，JSPのプリコンパイルで痛い目を見るとか，
JSPのプリコンパイルは，問答無用で「*.jsp」を総ナメしていくんで，それ単体では動かないJSPは，拡張子を変えてプリコンパイルの対象外にしておかないといけない。
例えば「JSPフラグメント」という意味で「*.jsf」とかする。
JSPプロパティグループで，url-patternに否定形を指示できたらいいのにとか，
あらかじめ出来合のJSPを提供しちゃったんで，それらをinclude-prelude, include-codaの除外対象にしたいんだけど，置いた場所が悪くて後の祭りだった。
タグファイルはとっても便利なんだけど，再配布がめんどくせーなぁとか，
カスタムタグやELファンクションみたく，jarファイルに入れとくわけにはいかんからなぁ。
というか，タグファイル程度のものは，現場が必要に応じて作るモンなんだろう。
あとタグファイルのリファレンスって，どうやって作っておくといいの？
式言語がアクセサ中心のため微妙に不便だったりとか，
とあるオブジェクトをc:forEachに参加させたくて，
<c:forEach var="it" items="${hoge.iterator}" >と書くために"
getItetrator()"なんて，しょっぱいメソッドを作ってみたり。
同様に，式言語で代入ができないので，微妙に不便だったりとか，
代入のためだけに，JSTLのsetタグを使うのは，なんかかっこわるい。
<c:set var="count" value="${count + 1}"/>
カスタムタグの属性には，式言語の評価結果が渡されるとか，
当然，rtexprvalueがtrueってのが前提。
<x:tag value="${foo}" />ってやると，value属性には「${foo}」の評価結果が渡される（「${foo}」って文字列が渡されるわけじゃない）。でも，TLDに属性の型を指定しとくと，文字列以外でももらえる。
なんで，JSTLのforEachのitems属性は，<c:forEach var="it" items="${list}">って書けるし，それで動く（itemsの型はObjectになってる）。
＃この微妙さが分かるか？
逆にVariableResolver使って，タグ内で式言語を評価したいと思っても，属性値を式言語のままタグに渡す方法を知らない。
だって，rtexprvalueをfalseにすると，式言語そのものが書けなくなるんだもの。
ディレクティブとタグの評価場所を，なかなか理解してもらえなかったりとか，
<jsp:include page="${hogehoge}" />はOKだけど，
<%@include file="${hogehoge}" %>はNG.
＃これはJSPのせいではなくて，利用者の理解の問題か...
ディレクティブ，カスタムタグ，式言語が入り乱れるのがイヤだから，思い切ってJSP Document（*.jspx）を使ってみようかなって思っても，誰も知らなかったり，
＃そうゆう，自分もよく知らんのだが。:-D
（微妙に追加）カスタムタグの属性名に「class」って書くと，実装系によっては動かなかったり，
知ってる範囲だと，WebLogicはOKでTomcatはNG．
理由は簡単．Introspector経由で，プロパティ情報（PropertyDescriptor）を取得すると分かる．
＃Object.getClass()が邪魔してくれるのだ．
JSPの暗黙変数にコンテキストパスも入れて欲しかったな，とか，
結構よく使うし，こうゆうおまじない書くのもアレだなぁって．
<c:set var="ctx" value="${pageContext.request.contextPath}" />
カスタムタグのrelease()メソッドをマジメに実装しないと，タグキャッシュで痛い目にあうとか，
＃よくわからなくても，release()でプロパティの初期化はしておいたほうがいい．
TryCatchFinallyって，すごいインターフェイスだよね，とか，
＃これはただの感想．:-)
なんで，J2EE1.4のJavadocは英語のままなの，とか，
＃J2EE1.3はあるんだけどね（Sunの日本サイトのJava技術情報から辿れる）．
＃→http://sdc.sun.co.jp/java/docs/j2ee/sdk_1.3/ja/techdocs/api/index.html
...てな具合に文句や愚痴が言えるのだから，ホントにキライなワケはないんだろうな。
＃これってツンデレ？
Webコンテキストの初期化には，ServletContextListenerを使うのが吉
恥ずかしながら，つい最近までServlet.init()を使っておりました（load-on-startupで調整して）。
ServletContextListener自体は，Servlet2.3んときから華麗にスルーしてたんだけど，フレームワークの初期化で結構使われているみたい。んで，知りたてほやほやなんだけど，Servlet2.4から起動タイミングが
サーブレット 2.4 仕様に従い、サーブレットの初期化前に、ServletContextListener が呼び出されるようになりました。
http://edocs.beasys.co.jp/e-docs/wls/docs90/notes/new.html#1225559
となったそうな。
Servlet2.4の仕様書（SRV.S.20）にも，こんな記述が...
Listener order vs. servlet init()/destroy() clarification(ServletContextListener javadoc change)
最近，自分はJ2EE1.3脳で止まっているなぁと自覚することばかりだ。ちょうど良い機会だから，今のウチにJ2EE1.4脳（正確にはServlet2.4/JSP2.0脳）にスイッチしようっと。
Servlet2.4からWEB-INFの中にJSP置けるようになったの？
Servlet2.4の仕様書で該当箇所を見つけられてないんだけど，WebLogic9.0のドキュメントに気になる記述が...
WEB-INF ディレクトリは、アプリケーションのパブリック ドキュメント ツリーの一部ではありません。WEB-INF ディレクトリ内には、コンテナによってクライアントへ直接提供されるファイルはありません。ただし、WEB-INF ディレクトリのコンテンツは、ServletContext に対する getResource および getResourceAsStream メソッド呼び出しを使用するサーブレット コードから認識でき、RequestDispatcher 呼び出しを使用して公開されることがあります。
http://edocs.beasys.co.jp/e-docs/wls/docs90/notes/new.html#1225559
WebLogic8.0（Servlet2.3）までは，WEB-INF内のJSPに対してRequestDispatcherを取得することは出来なかったんだけど，WebLogic9.0（Servlet2.4）だとできるってこと？
＃ちなみに，Tomcatは昔からできた。
これが，Servlet2.4の仕様で明言されたってんだったら，すごい事なんだけど，どこに書いてるんだろう...
あとWebLogic9.0が手元にないんで試せない。:-(
（追記）書いてあるとこ見つけた（太字の下線部がそう）。
Servlet2.4 - SRV.9.5 Directory Structure
The Java Community Process(SM) Program - communityprocess - final
The WEB-INF node is not part of the public document tree of the application. No file contained in the WEB-INF directory may be served directly to a client by the container. However, the contents of the WEB-INF directory are visible to servlet code using the getResource and getResourceAsStream method calls on the ServletContext, and may be exposed using the RequestDispatcher calls. Hence, if the Application Developer needs access, from servlet code, to application specific configuration information that he does not wish to be exposed directly to the Web client, he may place it under this directory.
でも，Servlet2.3だとこう書いてる。
Servlet2.3 - SRV.9.5 Directory Structure
The Java Community Process(SM) Program - communityprocess - first
The WEB-INF node is not part of the public document tree of the application. No file contained in the WEB-INF directory may be served directly to a client by the container. However, the contents of the WEB-INF directory are visible to servlet code using the getResource and getResourceAsStream method calls on the ServletContext. Hence, if the Application Developer needs access, from servlet code, to application specific configuration information that he does not wish to be exposed to the web client, he may place it under this directory.
ふーん，Servlet2.4からはWEB-INFの下にJSP置いてもいいのかな...
＃「may be」ってのが，とっても気になるけど。:-P
web.xmlがデプロイメントデスクリプタって名前だって事を知ってる人はどれくらいいるんだろう？
イヤ，名前を知ってることが重要なのではない。
プロジェクトの参加者のうち，WARやらEARを構成するのきに，どの配置記述子にどんなことを書けばいいのか把握できてる人が，どれほどいるのだろう。
あたしのまわりだと，１〜２割もいれば上出来な感じなんだが，他はどうなのかなぁって。
＃これって，ジョエル・テストに入れてもいい？
