JNDIはまずJavaEEだけではなくJavaSEでも使えますよね．Javaの基本となるAPIだけに相性が悪いという環境は考えにくい．それに通常Web開発をしていてたとえばデータソースを取得したい場合サーバー側で設定しますよね．
というのは開発時と運用時でバイナリを分けるべきではないと思ってるから．手動でいじってビルドしなおすということは，バイナリがまた変化したわけで，このバイナリはまた一から検証しなおしになると思う．
この分離はソースとリソースの分離とかと感覚的に近いと思ってる．プログラムを変更せずともPCGデータやBGM，SEを変更したいことは十分ありえる．また，環境によって違う場合それをテキストファイルで書き出すのと同じ．warファイルというのはプログラムと静的なリソースも含むバイナリなわけで，動的に入れ込む場所じゃないと思う．
さまざまな環境によるリソースを分離したい場合，EJB-jarにそのリソースを集中してパッケージングしておいて，環境ごとにそのejb-jarを変えるという使い方をしたことがあるけど，これのほうがシンプルでいいとおもう．結果的にはJNDIを使うことにはなるし，JavaEEサーバーが必要になるけど，warファイルに環境を書くくらいならばはるかにまし．それがいやなら外部テキストファイルでサーバーのどこかにおいておいたほうがいい．そしてそのファイルのフルパスをサーバーに設定してあげるとか．
slim3はそのパターンをあらかじめ設定しておいてそれを選択できるというだけではちょっと使わないかなぁと思った．JNDIが使えるから別にいいんだろうけど．選択が意味があるのはSMART DEPLOYの切り替え程度かなぁと．そしてそれは以前（Hot DeployとNetbeansとの相性がすこぶるよい）で軽くやりました．
話がいつものようにそれたような気がするけど，いいたいことはひとつ．
デプロイされるバイナリは出来るだけそのバイナリが想定されていない場所でも動くようにしたい．
あらかじめパターンを作っておいても，それに合わない場所にデプロイすることはたまにあるから．テストしたいんでここに急遽デプロイしてとか，IDとパスワードが実は変わっていたとか．手元にソースがないけど，バイナリだけは手元にあるとか．たぶん大規模なアプリ開発ばかりしているひがさんはこういう事態に出会ったことがないんだろうなぁと思いました．小規模な現場では理不尽なことがいくらでも起こると思うのです．
データソースとトランザクションだけのためにでもアプリケーションサーバーを選択するというのは非常にメリットがあると感じてるんだけど，世の中そうではないのかな．アプリケーションサーバーが非常に重くて有料が普通だった時代はとっくに過ぎ去ったというのに．一方でTomcatは管理ツールが6.0から削除されましたね．5.5まではあったのに．
そもそもHotDeployで開発するならアプリケーションサーバーへのデプロイが重かったとしても問題はないと思うんだけれども．むしろ相性がよいことをアピールすべき．
