アプリケーションサーバがない場合のデータソース

JNDIはまずJavaEEだけではなくJavaSEでも使えますよね．Javaの基本となるAPIだけに相性が悪いという環境は考えにくい．それに通常Web開発をしていてたとえばデータソースを取得したい場合サーバー側で設定しますよね．

JNDIのAPIは、JavaSEにはいっているけど、JNDIの実装は入っていないから、JNDIで値を設定するってのがつらいと思うけどね。
アプリケーションサーバ側のデータソースを使うときは、JNDIに設定するけど、JUnitでテストするときなどアプリケーションサーバで動かさないときは、JNDIから取得できない(WebLogicだとリモートでもデータソースを取得できるけど)わけです。

だから、アプリケーションサーバで動かすときはJNDIから取得するし、アプリケーションサーバ以外で動かすときには、ローカルのコネクションプール(S2DBCP移植)から取得するようにするわけです。

アプリケーションサーバで動かすときにはJNDIから取得

ごめんなさい。昨日のサンプルは、slim.ds.jndiの設定が空でした。

#slim.ds.user=

#slim.ds.password=

#slim.ds.driverClassName=

#slim.ds.url=

slim.ds.jndi=datasource/oracle

アプリケーションサーバ以外で動かすときにはローカルのコネクションプールから取得(slim_env_ut.properties)

slim.ds.user=scott

slim.ds.password=tiger

slim.ds.driverClassName=oracle.jdbc.driver.OracleDriver

slim.ds.url=jdbc:oracle:thin:@xxx:1521:xxx

# slim.ds.jndi=

バッチもアプリケーションサーバ以外で行なう場合が多いですね。
このアプリケーションサーバがない場合のデータソースの扱いは、Slim3に限らず重要な問題です。

というのは開発時と運用時でバイナリを分けるべきではないと思ってるから．手動でいじってビルドしなおすということは，バイナリがまた変化したわけで，このバイナリはまた一から検証しなおしになると思う．

WARをいじる必要ありませんよ。
パワーポイントの資料だと

slim.envの値はWARに手を入れることなくコンテキストパラメータで変更が可能

Tomcatならアプリケーション名.xmlのParameterタグ<Parameter name="slim.env" value=""/>

Systemプロパティも使える

コンテキストパラメータのほうが優先