- PR -

JNDI名の設定／指定箇所について

1
投稿者投稿内容
FZR
常連さん
会議室デビュー日: 2007/09/10
投稿数: 42
投稿日時: 2008-07-22 15:41
いつもお世話になっております。

DataSourceをJNDIからlookupして取得する際に、lookup名をどこに設定したり、どこでlookupされてますでしょうか？

現在Struts + PostgreSQLにて開発しているのですが、あるソースでAction毎にJNDI名を文字列で記述しているものを見たのですが、文字列なので例えJNDI名が変わってもEclipse等を使用すれば一発で置換できるとは言え冗長すぎる気がしてなりません。JNDI名そのものも、ソースにハードコーディングするのもどうかと思うので、web.xmlなりに記述すれば良いと思うのですが、web.xmlに記述するって言うのは時代遅れなのでしょうか？

JNDI名については個人的にはAppricationかSessionのスコープに保持しておけばよいと考えているのですが．．．

dbcpによるconnection-poolを使用しているので、Action毎にコネクションを取得するのは構わないと思うのですが、ServletFilter等に実装されている方はおられるのでしょうか？

かつのり
ぬし
会議室デビュー日: 2004/03/18
投稿数: 2015
お住まい・勤務地: 札幌
投稿日時: 2008-07-22 16:11
DIコンテナを使うなら、管理が簡単でいいのですが、
使っていないなら、データソースのラッパーを作成して、
コンストラクタの中でlookupしてみるのもよいかもしれません。
コード:
public class MyDataSource implements DataSource{

	private DataSource ds;

	//例外処理は省略
	public MyDataSource(){
		InitialContext context = new InitialContext();
		ds = (DataSource)context.lookup("java:comp/env/jdbc/XXXXXX");
	}

	public Connection getConnection() throws SQLException {
		return ds.getConnection();
	}
	
	//...以下委譲メソッドが続く
}

利用側は
コード:
DataSource ds = new MyDataSource();
Connection conn = ds.getConnection();

という感じになります。
FZR
常連さん
会議室デビュー日: 2007/09/10
投稿数: 42
投稿日時: 2008-07-22 16:43
かつのり様

メッセージありがとうございます。
DIコンテナは正直申し上げて、未だその利便性の実感が湧かないので利用していません。
これはまぁ、私の理解不足とは思うのですが．．．

ですので、もっぱらレガシー（？）な方法によるデータ取得をメインに作業しています。
確かにラッパークラス（及びそのコンストラクタ）で処理すれば、contextの取得から全て一元化できますね。このラッパークラスを作成する方法は他の方もよく利用されておられるかと思うのですが、このJNDI名をハードコーディングすると言うのは未だ一般的なのでしょうか？

いや、何を心配しているのかと申しますと、昨今では先ほどのDIコンテナでもそうですが、設定ファイルに何でも書いていくと言う流れがありますよね。なので環境に依存する部分は極力コードから除外すべきなのかどうかと言うところで悩んでいます。

JNDIの定数部分は"java:comp/env/jdbc/XXXXXX"だけですし、そのためにわざわざ設定ファイルにparamを設定し、それを取得して利用するコードを書くのが本筋なのか、それともプロジェクト事情に応じて適宜ハードコーディングも致し方なしとするのかと、今回はJNDIを例えに取りましたが皆さんはどのようにされているのかと気になった次第です。
かつのり
ぬし
会議室デビュー日: 2004/03/18
投稿数: 2015
お住まい・勤務地: 札幌
投稿日時: 2008-07-22 18:00
別にハードコーディングにしなくても、
それこそ文字列をPropertiesから取得してもよいのではないでしょうか。
あくまでも例なので・・・。
自分ならPropertiesから取得しますね。

環境に依存する文字列は極力コード内で直接取り扱わないのは、
いつでもあまり変わらないような気がします。
FZR
常連さん
会議室デビュー日: 2007/09/10
投稿数: 42
投稿日時: 2008-07-23 08:57
# かつのり様

唯一無二の方法があるならともかく、あまり「こうあるべき」と言うのに拘りすぎてもダメですね。

Propertiesを含め、今一度検討することにします。
どうもありがとうございました。

山本 裕介
ぬし
会議室デビュー日: 2003/05/22
投稿数: 2415
お住まい・勤務地: 恵比寿
投稿日時: 2008-07-24 23:19
JavaEE の習わしではルックアップする JNDI 名はハードコードするべき、ではないでしょうか。

その代わりに名前はグローバルな名前ではなく、アプリケーションローカルな名前(java:comp/env/..)を使います。
実際のリソース名とのマッピングは jboss-web.xml とか weblogic.xml とかに書きますので他のアプリケーションと利用する JNDI 名が衝突することを心配する必要はありません。

デプロイ担当者が環境にあわせてコード修正、リコンパイル、パッケージングをし直さなくてすむための仕組みがアプリケーションローカルな JNDI です。
JavaEE の仕様で、コンテナ側で用意されている仕組みをアプリケーション内で再度作るのは無駄ではないでしょうか？

もちろんルックアップする箇所が多く、タイプミスを防ぐためにどこかに final な定数を用意して参照させるのは良い心がけだと思いますが。

[ メッセージ編集済み 編集者: インギ 編集日時 2008-07-24 23:42 ]
FZR
常連さん
会議室デビュー日: 2007/09/10
投稿数: 42
投稿日時: 2008-07-25 09:39
# インギさん

なるほど、そんなところにもグローバルJNDI参照(jdbc/XXX)とローカルJNDI参照(java:comp/env/XXX)の使い分けに意味が出てくるんですね。ただ、今回はMETA-INF配下にcontext.xmlを作成し設定しているので、環境に合わせる必要がある場合には最低限パッケージングのやり直しが発生するようにしてしまっています．．．

Eclipse上で開発しておりプロジェクトのスケルトンを配布する時に、各自でリソース名とのマッピングを書いて貰わずに済むので便利なんでそうしたのですが、本義を正すとプロジェクト内のcontext.xmlで書いてしまうのは良くないかもしれませんね。

ローカルなJNDI参照はfinal定数で参照と言うのも、簡易且つ確実な方法ですね。
質問とは別にモヤモヤっとしていたところが晴れてきたような気がします。
ありがとうございました。
1

スキルアップ／キャリアアップ（JOB@IT）