モナーコンバットプロジェクト
2009年3月26日木曜日
2008年4月6日日曜日
スタンドアロンなJMSクライアント(Sun Java System Application Serverに実装されてるJMS編)
テスト用にスタンドアロンで動くJMSクライアントを作ってみる。
JMSプロバイダは、
Java EE 5 SDKについてくるSun Java System Application Server(SJSAS)についてくるJMS実装(ややこしい)のiPlanet Message Queue for Java[tm] Software(iMQ)を利用する。
このiMQは、SJSASの管理コンソールからは、Sun Java System Message Queueブローカーと呼ばれてる。
ということは、Sun Java System Message QueueってiMQだったのか。
それはいいとして、
EclipseでJavaプロジェクトを作る。
以下のライブラリをパスに追加する。
${JAVA_SDK_HOME}/imq/lib/jms.jar
${SDK_HOME}/imq/lib/jms.imq.jar
${SDK_HOME}/imq/lib/jms.imq_ja.jar
ソースは以下のとおり。
import javax.jms.JMSException;
import javax.jms.Queue;
import javax.jms.QueueConnection;
import javax.jms.QueueConnectionFactory;
import javax.jms.QueueSender;
import javax.jms.QueueSession;
import javax.jms.TextMessage;
public class Sender {
public static void main(String[] args) {
// デフォルト設定(localhost:7676)で実行されているブローカーに対してTCPベースのキューを作成する
QueueConnectionFactory factory = (QueueConnectionFactory) new com.sun.messaging.QueueConnectionFactory();
QueueConnection connection = null;
QueueSession session = null;
Queue queue = null;
try {
connection = factory.createQueueConnection();
session = (QueueSession) connection.createQueueSession(false,QueueSession.AUTO_ACKNOWLEDGE);
// 自前でQueueオブジェクトを作成するためには、物理送信先を指定する
queue = session.createQueue("MyPhysicalQueue");
QueueSender sender = session.createSender(queue);
TextMessage msg = session.createTextMessage();
msg.setText("Send Text");
sender.send(msg);
sender.close();
session.close();
connection.close();
} catch(JMSException jmse) {
jmse.printStackTrace();
}
System.out.println("mission complete!");
}
}
■SJSASにJMSのキューを設定する
[設定]-[Javaメッセージサービス]-[物理送信先]から、
の画面を開く。
名前:MyPhysicalQueue
タイプ:javax.jms.Queue
で、了解を押して、物理送信先を作成する。
上記のプログラムを実行すれば"Send Text"というメッセージがMyPhysicalQueueという名前のキューにPUTされる。
JNDIを使ってキューを取得するには、APサーバ(JNDIプロバイダ)の設定が必要。
[リソース]-[JMSリソース]-[送信先リソース]から
の画面を開く。
JNDI名:jms/MyQueue
送信先物理名:MyPhysicalQueue
リソースタイプ:javax.jms.Queue
以下のプロパティを追加する
名前:Name
値:MyPhysicalQueue
で、了解を押す。
これで、"jms/MyQueue"という名前で、MyPyhsicalQueueという物理送信先が取得できる。
JMSプロバイダは、
Java EE 5 SDKについてくるSun Java System Application Server(SJSAS)についてくるJMS実装(ややこしい)のiPlanet Message Queue for Java[tm] Software(iMQ)を利用する。
このiMQは、SJSASの管理コンソールからは、Sun Java System Message Queueブローカーと呼ばれてる。
ということは、Sun Java System Message QueueってiMQだったのか。
それはいいとして、
EclipseでJavaプロジェクトを作る。
以下のライブラリをパスに追加する。
${JAVA_SDK_HOME}/imq/lib/jms.jar
${SDK_HOME}/imq/lib/jms.imq.jar
${SDK_HOME}/imq/lib/jms.imq_ja.jar
ソースは以下のとおり。
import javax.jms.JMSException;
import javax.jms.Queue;
import javax.jms.QueueConnection;
import javax.jms.QueueConnectionFactory;
import javax.jms.QueueSender;
import javax.jms.QueueSession;
import javax.jms.TextMessage;
public class Sender {
public static void main(String[] args) {
// デフォルト設定(localhost:7676)で実行されているブローカーに対してTCPベースのキューを作成する
QueueConnectionFactory factory = (QueueConnectionFactory) new com.sun.messaging.QueueConnectionFactory();
QueueConnection connection = null;
QueueSession session = null;
Queue queue = null;
try {
connection = factory.createQueueConnection();
session = (QueueSession) connection.createQueueSession(false,QueueSession.AUTO_ACKNOWLEDGE);
// 自前でQueueオブジェクトを作成するためには、物理送信先を指定する
queue = session.createQueue("MyPhysicalQueue");
QueueSender sender = session.createSender(queue);
TextMessage msg = session.createTextMessage();
msg.setText("Send Text");
sender.send(msg);
sender.close();
session.close();
connection.close();
} catch(JMSException jmse) {
jmse.printStackTrace();
}
System.out.println("mission complete!");
}
}
■SJSASにJMSのキューを設定する
[設定]-[Javaメッセージサービス]-[物理送信先]から、
新しい物理送信先
の画面を開く。
名前:MyPhysicalQueue
タイプ:javax.jms.Queue
で、了解を押して、物理送信先を作成する。
上記のプログラムを実行すれば"Send Text"というメッセージがMyPhysicalQueueという名前のキューにPUTされる。
JNDIを使ってキューを取得するには、APサーバ(JNDIプロバイダ)の設定が必要。
[リソース]-[JMSリソース]-[送信先リソース]から
新しい JMS 送信先リソース
の画面を開く。
JNDI名:jms/MyQueue
送信先物理名:MyPhysicalQueue
リソースタイプ:javax.jms.Queue
以下のプロパティを追加する
名前:Name
値:MyPhysicalQueue
で、了解を押す。
これで、"jms/MyQueue"という名前で、MyPyhsicalQueueという物理送信先が取得できる。
2008年4月1日火曜日
Javaの本とか
手持ちのJava関連の本を整理してみるテスト。
マスタリングJavaEE5 ★★★★★
和書でJavaEE5を一通り解説している唯一の本。JAX-WSやJAXB2.0も載っている。
EJB2.0とEJB3.0の比較を行うなど、解説は懇切丁寧。トランザクション制御などの話になると、簡略化されてしまっているところが残念。
後はJavaEE 5に準拠したアプリケーションサーバが充実するのを待つばかり。
早く対応して、WAS。JavaEE5の対応状況を考えると、OSSの開発速度はさすがと言うべきか。
Enterprise JavaBeans ★★★★★
これを読まずしてJ2EEは語れない。
論より現場のJ2EE入門 ★★☆☆☆
J2EEというか、EJBの本。解説が微妙。環境はJBoss3.x
まずは実際にEJBのコードを書いて動かしてみたい、という要望に唯一答えてくれる本。
(Web上ならそういった情報はたくさんありそうだけど)
EJBデザインパターン ★★★★☆
マスタリングEnterprise JavaBeansの第一章という位置づけ。
EJBであれこれ悩む前に、まずは目を通すことをお勧めする。
EJBアンチパターン ★★★★☆
明確な理由が無い限りこれは使うな、って否定はしてくれるんだけど、その根拠が明記されていない。
でも、EJBにおけるさまざまな気づきを与えてくれる良書。
EJBを使った方式の設計に関わるなら必読。
標準EJB3.0プログラミング ★★★☆☆
微妙・・・洋書だけどEnterprise JavaBeansの第5版を買うか
Javaメッセージサービス ★★★☆☆
入手困難、中古でやっと買った。
メッセージセレクタに指定できる条件とか、どのヘッダが自動的に付与されるとか、
キューの動的作成やら、セキュリティの話まで、非常にコンパクトにまとまっていて良い。
内容がJMS製品に依存しないため、読みながら実装していく、というスタイルが取るためには、
自分でJMS製品の使い方を調べていかないといけないのが難点か。
Java Message Service 導入ガイド ★★★☆☆
チュートリアル形式でJMSを解説している。が、環境が古い。J2EE 1.3のSDKベース。
(といっても、J2EE 1.3のSDKは今でも配布されているので大した問題ではない)
後半はAPIリファレンス。
Professional Apache Geronimo ★★★☆☆
Geronimo1.1の解説書。GBeanのアーキテクチャから、デプロイメント記述子の解説も載っている。
今となっては内容が古い。
Light Weight Java ★★★☆☆
JSFとかHibernateとかSpring、あるいはそれらの連携方法を手っ取り早く知りたい人のための本。
XMLとJavaによるWebアプリケーション開発 ★★★★☆
Webアプリケーション開発と銘打ってあるが、DOMやSAXの解説が充実しており、JavaでXMLを使う場面では重宝する。
StAXやJAXB2.0を取り入れて、改訂されることを期待。
Java Swing Hacks ★★★☆☆
こういうGUIが作りたいけど、どうしたらいいんだ、ってときに重宝する。
Swingの基礎についての解説は皆無。
あと、Java仮想マシンとか言語仕様とか、Effective JavaとかSpringとかSeasarとか、サーブレットとか、いろいろあったはずだけど、埋もれてる。
マスタリングJavaEE5 ★★★★★
和書でJavaEE5を一通り解説している唯一の本。JAX-WSやJAXB2.0も載っている。
EJB2.0とEJB3.0の比較を行うなど、解説は懇切丁寧。トランザクション制御などの話になると、簡略化されてしまっているところが残念。
後はJavaEE 5に準拠したアプリケーションサーバが充実するのを待つばかり。
早く対応して、WAS。JavaEE5の対応状況を考えると、OSSの開発速度はさすがと言うべきか。
Enterprise JavaBeans ★★★★★
これを読まずしてJ2EEは語れない。
論より現場のJ2EE入門 ★★☆☆☆
J2EEというか、EJBの本。解説が微妙。環境はJBoss3.x
まずは実際にEJBのコードを書いて動かしてみたい、という要望に唯一答えてくれる本。
(Web上ならそういった情報はたくさんありそうだけど)
EJBデザインパターン ★★★★☆
マスタリングEnterprise JavaBeansの第一章という位置づけ。
EJBであれこれ悩む前に、まずは目を通すことをお勧めする。
EJBアンチパターン ★★★★☆
明確な理由が無い限りこれは使うな、って否定はしてくれるんだけど、その根拠が明記されていない。
でも、EJBにおけるさまざまな気づきを与えてくれる良書。
EJBを使った方式の設計に関わるなら必読。
標準EJB3.0プログラミング ★★★☆☆
微妙・・・洋書だけどEnterprise JavaBeansの第5版を買うか
Javaメッセージサービス ★★★☆☆
入手困難、中古でやっと買った。
メッセージセレクタに指定できる条件とか、どのヘッダが自動的に付与されるとか、
キューの動的作成やら、セキュリティの話まで、非常にコンパクトにまとまっていて良い。
内容がJMS製品に依存しないため、読みながら実装していく、というスタイルが取るためには、
自分でJMS製品の使い方を調べていかないといけないのが難点か。
Java Message Service 導入ガイド ★★★☆☆
チュートリアル形式でJMSを解説している。が、環境が古い。J2EE 1.3のSDKベース。
(といっても、J2EE 1.3のSDKは今でも配布されているので大した問題ではない)
後半はAPIリファレンス。
Professional Apache Geronimo ★★★☆☆
Geronimo1.1の解説書。GBeanのアーキテクチャから、デプロイメント記述子の解説も載っている。
今となっては内容が古い。
Light Weight Java ★★★☆☆
JSFとかHibernateとかSpring、あるいはそれらの連携方法を手っ取り早く知りたい人のための本。
XMLとJavaによるWebアプリケーション開発 ★★★★☆
Webアプリケーション開発と銘打ってあるが、DOMやSAXの解説が充実しており、JavaでXMLを使う場面では重宝する。
StAXやJAXB2.0を取り入れて、改訂されることを期待。
Java Swing Hacks ★★★☆☆
こういうGUIが作りたいけど、どうしたらいいんだ、ってときに重宝する。
Swingの基礎についての解説は皆無。
あと、Java仮想マシンとか言語仕様とか、Effective JavaとかSpringとかSeasarとか、サーブレットとか、いろいろあったはずだけど、埋もれてる。
2008年3月20日木曜日
JavaEE 5 SDKを使ってみる
JMSのチュートリアルを読んでいたら、J2SE1.3のSDKをベースに書かれていたので、
それなら、とJavaEE 5 SDKを使ってみることにした。
だって、各アプリケーションサーバのJNDIのセッティング方法を調べるのが面倒なんだもん!
#実際、プラットフォームがごちゃごちゃな環境では、各APサーバごとに管理方法が異なるため、厄介な話なのだ。
(注意事項)
2008/3/21現在、JavaEE 5 SDK Update 4 は、英語版のみです。
日本語を含めた多言語をサポートした最新バージョンはJava EE 5 SDK Update 3です。
以下のインストール手順はJavaEE 5 SDK Update 4のスナップショットです。
ダウンロードするときは、くれぐれも間違えないように。
1.前提
・JDK 1.6がインストールされていること。
・Windows環境であること。
2.ダウンロード
JavaEEのSDKは以下のリンクからダウンロードする。
※ダウンロードには、SunDeveloperCenterのユーザアカウントが必要です。
http://sdc.sun.co.jp/java/javaee/downloads/index.html
日本語対応の多言語版は、ページの下のほうにあるので、注意してください。
3.インストール
2.でダウンロードした、「java_ee_sdk-5_04-windows-nojdk.exe」を起動する。
Step1. Welcome
「Next」を押す
Step2. Agreement
「Yes」を選択して、「Next」を押す
Step3.インストールディレクトリの指定
例ではC:\Sun\SDKとしている。お好きなところで。
Step4.JDKインストールディレクトリの指定
JDKをインストールしたディレクトリを指定する
Step5. 管理用の設定
・管理者のユーザ名、パスワードを設定する。
・管理機能を呼び出すごとにユーザ名・パスワードを求められるのは面倒なので、
「Don't Prompt for Admin User Name and Password」を選択する。
・ポートはデフォルトのままにしておく。
Step6. インストールオプションの設定
Step7. インストール内容の確認
「Next」を押す
Step8. インストール中
しばし待たれよ
Step9. ユーザ登録
登録しておくとパッチの情報とか貰えるらしいけど、
ちょこっと使うだけなので、「Skip Registration」を選択する。
Step10. インストール完了
サーバの起動は別途手動で行うので、
ここでは「Finish」を押して、インストールを完了する。
----------[インストール完了]-----------------
(おまけ)
3'. アンインストール
「プログラムの追加と削除」から「Java Platform, Enterprise Edition 5 SDK」を選択して、削除する。
一部のディレクトリは削除されないので、手動で削除。
4.サーバを起動する
JavaEE5SDKをインストールすると、漏れなく
Sun Java System Application Serverは、GlassFishをベースとしたAPサーバです。
IBMがGeronimoをベースとしてWAS-CEを作っているのと似ている。
今回使ってみて思ったけど、やっぱり標準サポートのSDKであり、日本語対応がされているという点は大きい。学習用にはもってこい。何よりJNDIの設定が簡単!
話が逸れましたが、サーバを起動するためには、
[スタートメニュー]→[Sun Microsystems]→[JavaEE SDK]→[Start Default Server]をクリックするか、
コマンドプロンプトにて、以下のコマンドを実行する。
asadmin start-domain
サーバが起動するので、ブラウザを使って管理コンソールにアクセスする。
URLは以下のとおり。
(インストール時に管理用コンソールのポートを別の番号にした場合は、そのポート番号を指定する)
http://localhost:4848/login.jsf
ユーザ名、パスワードは、インストール中に指定したものを入力する。
ログインすると、ユーザ登録がどうたら、と聞かれるので、
「Never Register」をクリックする。
で、いろいろとメニュー項目を眺めたりするんだけど、全部英語だYO!
まぁダウンロードするときにEnglishしか選べなかったので、わかっていたことですが。
そういえばJ2EE 1.4のSDKを使っていたときは日本語だったなぁ、と思い出して、調べたら多言語版があったよorz
というわけで、多言語版をインストールし直し・・・。
でもでも、日本語でConnectionFactoryを接続ファクトリと言われてもピンと来なくて、微妙だったりする(笑)
5.JMSの設定を行う
普通ならここでHelloWorld的なWebアプリケーションを作って終わるところだけど、
そんなこたぁ、どうでもいいんです!ルックアップがしたいのですよ!
まずは接続ファクトリの設定から。
管理コンソール画面の、左側にある共通操作ペインから、[リソース]→[JMSリソース]→[接続ファクトリ]を選択して、「新しいJMS接続ファクトリ」作成画面を開く。
「JNDI名」を「jms/QueueConnectionFactory」とする。
「リソースタイプ」を「javax.jms.QueueConnectionFactory」とする。
他の設定はデフォルトのまま、「了解」ボタンを押して登録する。
なんて簡単なんだ!
続いて、キューの設定を行う。
先ほどと同様に、管理画面左側のペインから、
[リソース]→[JMSリソース]→[接続リソース]を選択して、「新しい接続先リソース」作成画面を開く。
「JNDI名」は「jms/MyQueue」とする。
「物理送信先名」は「MyQueue」とする。(これは送信先リソースのNameプロパティの値になる)
「リソースタイプ」は「javax.jms.Queue」とする。
続いて、キューを作成する。
ここでの操作は、Sun Java System Message Queue 4.1に反映される。
今度は[構成]→[Javaメッセージサービス]→[JMSホスト]→[物理送信先]を選択する。
「新規」ボタンを押して、以下の設定でキューを作成する。
名前:MyQueue
タイプ:javax.jms.Queue
6.ルックアップを行う
スタンドアロンのアプリからメッセージをputしたい。
やり方は2つ。
まず1つ目は、JMSプロバイダが提供する接続ファクトリとキューを生成して、
宛先名やらキュー名やらを設定する方法。
2つ目は、JNDIでConnectionFactoryとQueueをルックアップして取得する方法がある。
1つ目の方法だと、JMSプロバイダガ提供する独自のクラスを生成する必要があり、
ソースコードの移植性が落ちる。
そこで2つ目の方法を使う。
JNDIを使うためには、まずInitialContextに環境定義を渡す必要がある。
InitialContextのAPIを見ると分かるが、やり方は
APサーバ上で実行されるAP(Webアプリケーション等)は、APサーバが環境定義を把握しているので、勝手にプロパティを読み込まれる。そのため、AP実装時に、InitialContextのコンストラクタに引数を渡す必要がない。
では、APサーバ上で実行しないAPはどうなるのか。
この場合、自前でプロパティを渡すしかない。
つまり、ソースコードにプロパティを記述して、それをInitialContextのコンストラクタ引数に渡すか、
クラスパス上にjndi.propertiesファイルを作成するか、だ。
以下、Sun Java Application Server上で、先ほど設定したQueueConnectionFactoryをJNDIで取得するためのサンプルだ。
import java.util.Properties;
import javax.jms.Queue;
import javax.jms.QueueConnectionFactory;
import javax.naming.Context;
import javax.naming.InitialContext;
public class JmsSender {
public static void main(String[] args) throws Exception {
Properties props = new Properties();
props.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.enterprise.naming.SerialInitContextFactory");
InitialContext context = new InitialContext(props);
System.out.println("context ok");
QueueConnectionFactory factory = (QueueConnectionFactory)context.lookup("jms/QueueConnectionFactory");
System.out.println("factory ok");
Queue queue = (Queue)context.lookup("jms/MyQueue");
System.out.println("queue ok");
}
}
Propertiesを生成して、値を自前で設定している。
put(Context.INITIAL_CONTEXT_FACTORY,"com.sun.enterprise.naming.SerialInitContextFactory");
Context.INITIAL_CONTEXT_FACTORYは、実際には「java.naming.factory.initial」という値である。
したがって、jndi.propertiesファイルを用意する場合は、
java.naming.factory.initial=com.sun.enterprise.naming.SerialInitContextFactory
という定義を記述すればよい。これでソースファイルの環境依存性が無くなる。
ただし、厄介なのがこのプロパティ。今回は、「com.sun.enterprise.naming.SerialInitContextFactory」というコンテキストファクトリを指定したが、
これは今回に限った話で、JNDIプロバイダが異なれば、設定が変わってくる。
しかも、どの値を設定していいのか、よく分からない。
実は、「com.sun.enterprise.naming.SerialInitContextFactory」という値を取得するために、
一度、Webアプリケーションを作成して、その上でInitialContextを生成して、
そこから環境定義を取得している。
これによってInitialContextの実体クラスを把握できたのだ。
public void doGet(HttpServletRequest req, HttpServletResponse res) throws IOException {
Context context = null;
PrintWriter pw = res.getWriter();
context = new InitialContext();
pw.println("get InitialContext: ok");
Hashtable table = context.getEnvironment(); // コンテキストの環境定義を取得する
pw.println(table.toString());
}
今回はJMSプロバイダとAPは同じホスト上で実行した。
そのため、本来指定しなければならない、Context.PROVIDER_URLの値(JNDIプロバイダのURL)は指定せずに済んだ(※)。
(※指定せずに済んだのは、コンテキストがSerialInitContextFactoryだったからというのもある)
このURLの指定も、APサーバの設定で異なる。
rmiregistryだったらrmi://localhostとか、LDAPを使うなら、ldap://ldapserver:900/o=myObjectsとか、ファイルシステムだったら、file:///C:/tempとか、
ActiveMQが提供するファクトリクラスなら、tcp://localhostだってOKだし、
CosNamingならiiop://とか。
とにかくJNDIを使うのは骨が折れるのだ。
JNDIは自前でbindを行ってしまえば、それで使える。
Properties props = new Properties();
props.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.rmi.registry.RegistryContextFactory");
props.put(Context.PROVIDER_URL, "rmi://localhost");
InitialContext context = new InitialContext(props);
context.rebind(JNDI名,オブジェクト);
こうすればコンテキストの生成時に、自分で把握しているプロパティを渡せるので、
今回のようにいちいち調べなくてもよくなる。
ただし、こうなるとAPサーバの管理コンソールに頼れなくなり、管理を全て自前で行う必要がある。
7.まとめ
Sun Java System Application Serverは無償ながら、
多言語にも対応しており、リソースの設定が楽。だけど・・・
JNDIプロバイダ(大抵はAPサーバ)ごとに、以下の情報が異なる。
Sun Java System Application Serverにもメニュー項目からそれが見当たらなかったので、また旅に出ます。
とにかくスタンドアロンのJNDIクライアントには厳しい世界です。
それなら、とJavaEE 5 SDKを使ってみることにした。
だって、各アプリケーションサーバのJNDIのセッティング方法を調べるのが面倒なんだもん!
#実際、プラットフォームがごちゃごちゃな環境では、各APサーバごとに管理方法が異なるため、厄介な話なのだ。
(注意事項)
2008/3/21現在、JavaEE 5 SDK Update 4 は、英語版のみです。
日本語を含めた多言語をサポートした最新バージョンはJava EE 5 SDK Update 3です。
以下のインストール手順はJavaEE 5 SDK Update 4のスナップショットです。
ダウンロードするときは、くれぐれも間違えないように。
1.前提
・JDK 1.6がインストールされていること。
・Windows環境であること。
2.ダウンロード
JavaEEのSDKは以下のリンクからダウンロードする。
※ダウンロードには、SunDeveloperCenterのユーザアカウントが必要です。
http://sdc.sun.co.jp/java/javaee/downloads/index.html
日本語対応の多言語版は、ページの下のほうにあるので、注意してください。
3.インストール
2.でダウンロードした、「java_ee_sdk-5_04-windows-nojdk.exe」を起動する。
Step1. Welcome
「Next」を押す
Step2. Agreement
「Yes」を選択して、「Next」を押す
Step3.インストールディレクトリの指定
例ではC:\Sun\SDKとしている。お好きなところで。
Step4.JDKインストールディレクトリの指定
JDKをインストールしたディレクトリを指定する
Step5. 管理用の設定
・管理者のユーザ名、パスワードを設定する。
・管理機能を呼び出すごとにユーザ名・パスワードを求められるのは面倒なので、
「Don't Prompt for Admin User Name and Password」を選択する。
・ポートはデフォルトのままにしておく。
Step6. インストールオプションの設定
- 「Upgrade from Previous Version」
- 前バージョンからの設定ファイルの移行は無いので、チェックを外す
- 「Enable Updatechecker Client」
- 勝手にバージョンチェックされるのも嫌なので、チェックを外す
- 「Create Desktop Shortcut to Autodeploy Directory」
- 便利だけど、これ以上デスクトップを汚したくないので、チェックを外す
- 「Add bin directory to PATH」
- パスは追加しておかないとね
- 「Create Windows Service」
- 手動でサーバ起動・停止を行うので、チェックは外しておく
Step7. インストール内容の確認
「Next」を押す
Step8. インストール中
しばし待たれよ
Step9. ユーザ登録
登録しておくとパッチの情報とか貰えるらしいけど、
ちょこっと使うだけなので、「Skip Registration」を選択する。
Step10. インストール完了
サーバの起動は別途手動で行うので、
ここでは「Finish」を押して、インストールを完了する。
----------[インストール完了]-----------------
(おまけ)
3'. アンインストール
「プログラムの追加と削除」から「Java Platform, Enterprise Edition 5 SDK」を選択して、削除する。
一部のディレクトリは削除されないので、手動で削除。
4.サーバを起動する
JavaEE5SDKをインストールすると、漏れなく
- Sun Java System Message Queue 4.1
- Sun Java System Application Server 9.1
Sun Java System Application Serverは、GlassFishをベースとしたAPサーバです。
IBMがGeronimoをベースとしてWAS-CEを作っているのと似ている。
今回使ってみて思ったけど、やっぱり標準サポートのSDKであり、日本語対応がされているという点は大きい。学習用にはもってこい。何よりJNDIの設定が簡単!
話が逸れましたが、サーバを起動するためには、
[スタートメニュー]→[Sun Microsystems]→[JavaEE SDK]→[Start Default Server]をクリックするか、
コマンドプロンプトにて、以下のコマンドを実行する。
asadmin start-domain
サーバが起動するので、ブラウザを使って管理コンソールにアクセスする。
URLは以下のとおり。
(インストール時に管理用コンソールのポートを別の番号にした場合は、そのポート番号を指定する)
http://localhost:4848/login.jsf
ユーザ名、パスワードは、インストール中に指定したものを入力する。
ログインすると、ユーザ登録がどうたら、と聞かれるので、
「Never Register」をクリックする。
で、いろいろとメニュー項目を眺めたりするんだけど、全部英語だYO!
まぁダウンロードするときにEnglishしか選べなかったので、わかっていたことですが。
そういえばJ2EE 1.4のSDKを使っていたときは日本語だったなぁ、と思い出して、調べたら多言語版があったよorz
というわけで、多言語版をインストールし直し・・・。
でもでも、日本語でConnectionFactoryを接続ファクトリと言われてもピンと来なくて、微妙だったりする(笑)
5.JMSの設定を行う
普通ならここでHelloWorld的なWebアプリケーションを作って終わるところだけど、
そんなこたぁ、どうでもいいんです!ルックアップがしたいのですよ!
まずは接続ファクトリの設定から。
管理コンソール画面の、左側にある共通操作ペインから、[リソース]→[JMSリソース]→[接続ファクトリ]を選択して、「新しいJMS接続ファクトリ」作成画面を開く。
「JNDI名」を「jms/QueueConnectionFactory」とする。
「リソースタイプ」を「javax.jms.QueueConnectionFactory」とする。
他の設定はデフォルトのまま、「了解」ボタンを押して登録する。
なんて簡単なんだ!
続いて、キューの設定を行う。
先ほどと同様に、管理画面左側のペインから、
[リソース]→[JMSリソース]→[接続リソース]を選択して、「新しい接続先リソース」作成画面を開く。
「JNDI名」は「jms/MyQueue」とする。
「物理送信先名」は「MyQueue」とする。(これは送信先リソースのNameプロパティの値になる)
「リソースタイプ」は「javax.jms.Queue」とする。
続いて、キューを作成する。
ここでの操作は、Sun Java System Message Queue 4.1に反映される。
今度は[構成]→[Javaメッセージサービス]→[JMSホスト]→[物理送信先]を選択する。
「新規」ボタンを押して、以下の設定でキューを作成する。
名前:MyQueue
タイプ:javax.jms.Queue
6.ルックアップを行う
スタンドアロンのアプリからメッセージをputしたい。
やり方は2つ。
まず1つ目は、JMSプロバイダが提供する接続ファクトリとキューを生成して、
宛先名やらキュー名やらを設定する方法。
2つ目は、JNDIでConnectionFactoryとQueueをルックアップして取得する方法がある。
1つ目の方法だと、JMSプロバイダガ提供する独自のクラスを生成する必要があり、
ソースコードの移植性が落ちる。
そこで2つ目の方法を使う。
JNDIを使うためには、まずInitialContextに環境定義を渡す必要がある。
InitialContextのAPIを見ると分かるが、やり方は
- プロパティを渡す
- jndi.propertiesファイルに設定しておく
APサーバ上で実行されるAP(Webアプリケーション等)は、APサーバが環境定義を把握しているので、勝手にプロパティを読み込まれる。そのため、AP実装時に、InitialContextのコンストラクタに引数を渡す必要がない。
では、APサーバ上で実行しないAPはどうなるのか。
この場合、自前でプロパティを渡すしかない。
つまり、ソースコードにプロパティを記述して、それをInitialContextのコンストラクタ引数に渡すか、
クラスパス上にjndi.propertiesファイルを作成するか、だ。
以下、Sun Java Application Server上で、先ほど設定したQueueConnectionFactoryをJNDIで取得するためのサンプルだ。
import java.util.Properties;
import javax.jms.Queue;
import javax.jms.QueueConnectionFactory;
import javax.naming.Context;
import javax.naming.InitialContext;
public class JmsSender {
public static void main(String[] args) throws Exception {
Properties props = new Properties();
props.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.enterprise.naming.SerialInitContextFactory");
InitialContext context = new InitialContext(props);
System.out.println("context ok");
QueueConnectionFactory factory = (QueueConnectionFactory)context.lookup("jms/QueueConnectionFactory");
System.out.println("factory ok");
Queue queue = (Queue)context.lookup("jms/MyQueue");
System.out.println("queue ok");
}
}
Propertiesを生成して、値を自前で設定している。
put(Context.INITIAL_CONTEXT_FACTORY,"com.sun.enterprise.naming.SerialInitContextFactory");
Context.INITIAL_CONTEXT_FACTORYは、実際には「java.naming.factory.initial」という値である。
したがって、jndi.propertiesファイルを用意する場合は、
java.naming.factory.initial=com.sun.enterprise.naming.SerialInitContextFactory
という定義を記述すればよい。これでソースファイルの環境依存性が無くなる。
ただし、厄介なのがこのプロパティ。今回は、「com.sun.enterprise.naming.SerialInitContextFactory」というコンテキストファクトリを指定したが、
これは今回に限った話で、JNDIプロバイダが異なれば、設定が変わってくる。
しかも、どの値を設定していいのか、よく分からない。
実は、「com.sun.enterprise.naming.SerialInitContextFactory」という値を取得するために、
一度、Webアプリケーションを作成して、その上でInitialContextを生成して、
そこから環境定義を取得している。
これによってInitialContextの実体クラスを把握できたのだ。
public void doGet(HttpServletRequest req, HttpServletResponse res) throws IOException {
Context context = null;
PrintWriter pw = res.getWriter();
context = new InitialContext();
pw.println("get InitialContext: ok");
Hashtable table = context.getEnvironment(); // コンテキストの環境定義を取得する
pw.println(table.toString());
}
今回はJMSプロバイダとAPは同じホスト上で実行した。
そのため、本来指定しなければならない、Context.PROVIDER_URLの値(JNDIプロバイダのURL)は指定せずに済んだ(※)。
(※指定せずに済んだのは、コンテキストがSerialInitContextFactoryだったからというのもある)
このURLの指定も、APサーバの設定で異なる。
rmiregistryだったらrmi://localhostとか、LDAPを使うなら、ldap://ldapserver:900/o=myObjectsとか、ファイルシステムだったら、file:///C:/tempとか、
ActiveMQが提供するファクトリクラスなら、tcp://localhostだってOKだし、
CosNamingならiiop://とか。
とにかくJNDIを使うのは骨が折れるのだ。
JNDIは自前でbindを行ってしまえば、それで使える。
Properties props = new Properties();
props.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.rmi.registry.RegistryContextFactory");
props.put(Context.PROVIDER_URL, "rmi://localhost");
InitialContext context = new InitialContext(props);
context.rebind(JNDI名,オブジェクト);
こうすればコンテキストの生成時に、自分で把握しているプロパティを渡せるので、
今回のようにいちいち調べなくてもよくなる。
ただし、こうなるとAPサーバの管理コンソールに頼れなくなり、管理を全て自前で行う必要がある。
7.まとめ
Sun Java System Application Serverは無償ながら、
多言語にも対応しており、リソースの設定が楽。だけど・・・
JNDIプロバイダ(大抵はAPサーバ)ごとに、以下の情報が異なる。
- イニシャルコンテキストのファクトリークラス
- プロバイダーURL
Sun Java System Application Serverにもメニュー項目からそれが見当たらなかったので、また旅に出ます。
とにかくスタンドアロンのJNDIクライアントには厳しい世界です。
2008年3月18日火曜日
JNDI(Java Naming and Directory Interface)
JNDI(Java Naming and Directory Interface)(※下書き中です)
JNDIとは、Javaにおけるネーミングサービス(名前付け)とディレクトリサービス(検索)を扱うためのインタフェースを規定したもの。
どこぞかしこでネーミングネーミングと言うので、ネーミング=検索機能のようなイメージが植付けられてしまっていたけど、よくよく考えたらnaming=名前付けだよなぁ。
それは置いといて、
JNDIの構成は、API(Application Programming Interface)とSPI(Service Provider Interface)から成る。
APIはアプリケーション実装者が使うインタフェース。
SPIはサービス提供者が使うインタフェース。
両者の間にはフレームワークなりアダプタなりが仲介する。
APIとSPIって語呂が似てるけど、
ProgrammingとProviderのところが違うよね。
どうせなら、Programmingに合わせてProvidingにするとか、ProgrammerとProviderにするとか。
回りくどい話はいいとして、本題に入る。
JNDIはオブジェクトと名前を紐付けて管理したり、名前からオブジェクトを検索できたりする。
例えばデータベースは、製品ごとにJDBCドライバが用意されている。
OracleとDB2では、それぞれ用意されているJDBCドライバが異なるので、ドライバのクラス名も当然異なってくる。
こんな感じ
Class.forName("org.gjt.mm.mysql.Driver")
そうなると、Oracle用のソースコードと、DB2用のソースコードを用意しなければならなくなる。
じゃあクラス名だけ外部ファイルに定義しておけばいいじゃないか、って話になる。
でも、2つのドライバを同時にロードしたいときは?ってなるとそれぞれコードを書かなきゃいけなかったり、いろいろと面倒。いろいろ、のところは各自の経験からあれこれと想像頂きたい。
そこで、JNDIの出番ですよ。ドライバクラスを直接ロードするのではなく、DataSourceを取得する方法をとる。
どういうことかというと、JNDIを使って予めドライバクラスをJNDIネームスペース(※)に登録しておく。
(※名前付けしたオブジェクトを保管しておく領域をJNDIネームスペースという)
で、検索キー(名前)を使ってJNDIネームスペースを検索して、ドライバを取得する。
そうするとDataSourceというオブジェクトが取得できるから、これを使ってさらにConnectionが取得できたりする。
他にもJMSとかいろいろ。
あー、書いてるのめんどくさくなった。とっとと次いこう。
JNDIの使い方よくわからん。おまえ何ぞや。と、思ったわけです。
でも、おかげで、RMIで使ってたrmiregistryは何故立ち上げておく必要があるのか、ようやく理解しました。
JNDIはAPIとSPIからなるものです。そんだけです。だからJNDIを具現化して、JNDIが規定した機能を提供する人が必要です。その人は、アプリケーションサーバだったり、rmiregistryだったり、あるいはファイルシステムだったりします。
基本的な使い方は以下のとおり。
InitialContext context = new InitialContext();
Hoge hoge = (Hoge)context.lookup("ルックアップ名");
まずコンテキストを生成して、そのコンテキストを通して、ルックアップ(検索)を行う。
lookupの引数には、登録したオブジェクトに紐づく名前を指定する。
Hogeは予め登録しておいたオブジェクト。
これで欲しいオブジェクトのインスタンスが取得できた。
基本のスタイルはこれだけ。
でも、これがきっちり出来るようになるためには、JNDIの仕組みをしっかり理解しておかないといけない。
なぜなら、実際は各製品ごとにJNDIの設定を行う事になるから。そして製品ごとに設定の仕方が異なる。
ルックアップ名の定義場所
1.コンテナの配下で動くアプリケーション:web.xml
2.スタンドアローンで動くアプリケーション:application-client.xml
1.はサーブレットやWebアプリケーションやエンタープライズアプリケーション等でJNDIを使いたいときに使う。通常はこちらの方法をとる。
2.は、単独で稼動するアプリケーション(要はmainメソッドがあるようなやつ)がJNDIを使いたいときに使う。ただし、こちらの方法はあまりお勧めはしない。何故なら、ルックアップ名に紐づく定義が変更されると、クライアントアプリケーションの設定(application-client.xml)を変更しなければならないからだ。
つまり、サーバとクライアントが1:Nの関係になっているとして、1箇所直すのか、複数個所直すのか、という運用の話。
そうはいっても、2.を使わなきゃいけないときもある。
何故なら、JMSやらJDBCやらのクライアントアプリケーションが、常にアプリケーションサーバなどのコンテナ上で稼動しているとは限らないからだ。
JNDIの利用シーンとして、JDBCとJMSを使用するときにJNDIを利用するとどうなるか、サンプルコードを示す。
あと、LDAPとか、ファイルシステムとか、java:comp/envとかiiopとかrmi:とかなんとかかんとか。
あ、あとEJBも!
まとまらないので、一時中断。
JNDIとは、Javaにおけるネーミングサービス(名前付け)とディレクトリサービス(検索)を扱うためのインタフェースを規定したもの。
どこぞかしこでネーミングネーミングと言うので、ネーミング=検索機能のようなイメージが植付けられてしまっていたけど、よくよく考えたらnaming=名前付けだよなぁ。
それは置いといて、
JNDIの構成は、API(Application Programming Interface)とSPI(Service Provider Interface)から成る。
APIはアプリケーション実装者が使うインタフェース。
SPIはサービス提供者が使うインタフェース。
両者の間にはフレームワークなりアダプタなりが仲介する。
APIとSPIって語呂が似てるけど、
ProgrammingとProviderのところが違うよね。
どうせなら、Programmingに合わせてProvidingにするとか、ProgrammerとProviderにするとか。
回りくどい話はいいとして、本題に入る。
JNDIはオブジェクトと名前を紐付けて管理したり、名前からオブジェクトを検索できたりする。
例えばデータベースは、製品ごとにJDBCドライバが用意されている。
OracleとDB2では、それぞれ用意されているJDBCドライバが異なるので、ドライバのクラス名も当然異なってくる。
こんな感じ
Class.forName("org.gjt.mm.mysql.Driver")
そうなると、Oracle用のソースコードと、DB2用のソースコードを用意しなければならなくなる。
じゃあクラス名だけ外部ファイルに定義しておけばいいじゃないか、って話になる。
でも、2つのドライバを同時にロードしたいときは?ってなるとそれぞれコードを書かなきゃいけなかったり、いろいろと面倒。いろいろ、のところは各自の経験からあれこれと想像頂きたい。
そこで、JNDIの出番ですよ。ドライバクラスを直接ロードするのではなく、DataSourceを取得する方法をとる。
どういうことかというと、JNDIを使って予めドライバクラスをJNDIネームスペース(※)に登録しておく。
(※名前付けしたオブジェクトを保管しておく領域をJNDIネームスペースという)
で、検索キー(名前)を使ってJNDIネームスペースを検索して、ドライバを取得する。
そうするとDataSourceというオブジェクトが取得できるから、これを使ってさらにConnectionが取得できたりする。
他にもJMSとかいろいろ。
あー、書いてるのめんどくさくなった。とっとと次いこう。
JNDIの使い方よくわからん。おまえ何ぞや。と、思ったわけです。
でも、おかげで、RMIで使ってたrmiregistryは何故立ち上げておく必要があるのか、ようやく理解しました。
JNDIはAPIとSPIからなるものです。そんだけです。だからJNDIを具現化して、JNDIが規定した機能を提供する人が必要です。その人は、アプリケーションサーバだったり、rmiregistryだったり、あるいはファイルシステムだったりします。
基本的な使い方は以下のとおり。
InitialContext context = new InitialContext();
Hoge hoge = (Hoge)context.lookup("ルックアップ名");
まずコンテキストを生成して、そのコンテキストを通して、ルックアップ(検索)を行う。
lookupの引数には、登録したオブジェクトに紐づく名前を指定する。
Hogeは予め登録しておいたオブジェクト。
これで欲しいオブジェクトのインスタンスが取得できた。
基本のスタイルはこれだけ。
でも、これがきっちり出来るようになるためには、JNDIの仕組みをしっかり理解しておかないといけない。
なぜなら、実際は各製品ごとにJNDIの設定を行う事になるから。そして製品ごとに設定の仕方が異なる。
ルックアップ名の定義場所
1.コンテナの配下で動くアプリケーション:web.xml
2.スタンドアローンで動くアプリケーション:application-client.xml
1.はサーブレットやWebアプリケーションやエンタープライズアプリケーション等でJNDIを使いたいときに使う。通常はこちらの方法をとる。
2.は、単独で稼動するアプリケーション(要はmainメソッドがあるようなやつ)がJNDIを使いたいときに使う。ただし、こちらの方法はあまりお勧めはしない。何故なら、ルックアップ名に紐づく定義が変更されると、クライアントアプリケーションの設定(application-client.xml)を変更しなければならないからだ。
つまり、サーバとクライアントが1:Nの関係になっているとして、1箇所直すのか、複数個所直すのか、という運用の話。
そうはいっても、2.を使わなきゃいけないときもある。
何故なら、JMSやらJDBCやらのクライアントアプリケーションが、常にアプリケーションサーバなどのコンテナ上で稼動しているとは限らないからだ。
JNDIの利用シーンとして、JDBCとJMSを使用するときにJNDIを利用するとどうなるか、サンプルコードを示す。
あと、LDAPとか、ファイルシステムとか、java:comp/envとかiiopとかrmi:とかなんとかかんとか。
あ、あとEJBも!
まとまらないので、一時中断。
2008年3月16日日曜日
WAS-CEでJNDIとか
WAS-CEをインストールした
WASの面影が無い
まさにgeronimoだった
それはいいとして、WAS-CEでJDBCプロバイダってどうやって作成するんだ・・・
というわけで、セッティング。
【環境】
WebSphere Application Server Community Edition 2.0.0.1
DB2 9.5
開発環境にEclipseを使うならWAS-CEのサーバアダプタをインストールしておこう!
update siteはこちら。
http://download.boulder.ibm.com/ibmdl/pub/software/websphere/wasce/updates/
(注意)
Geronimoをインストールしている場合、環境変数「GERONIMO_HOME」を外しておくこと。
WAS-CEがGERONIMO_HOMEにあるgeronimoを見に行ってしまう。
#WAS-CEを初回起動したとき、コンソール画面がそのまんまGeronimoで思わず突っ込みを入れてしまった。
正しい画面を開いても、Geronimoそのままって感じですが。
(※見た感じはGeronimoの青い画面が紫になっただけ)
【前提】
DB2とWAS-CEはインストールしておいて、立ち上げておく。
DB2にはsampleデータベースをインストールしておく。
【手順】
WAS-CEの管理コンソールから「Database Pools」の管理画面を開く。
「Using the Geronimo database pool wizard」というリンクから、
新規にデータベースプールを作成する。
Create Database PoolのStep1画面が開くので、とりあえず、以下のように設定する。
Name of Database Pool:DB2Pool
Database Type:DB2
次のページ(Step2)に移ると、JDBCドライバを選択する画面になる。
しかし、DB2 9.5用のドライバが見当たらない。
「Download a Driver」というリンクボタンを押しても、DB2 9.5用のダウンロード先が出てこない。
そこで、DB2 9.5のインストール先からjarファイルをコピーする。
まず、9.5用のディレクトリを以下の場所に作成する
{WAS-CEのインストールホーム}/repository/com/ibm/db2/db2jcc/9.5
上記ディレクトリに、以下のdb2jcc.jarファイルをコピーして、「db2jcc-9.5.jar」という名前にリネームする。
{DB2 9.5のインストールホーム}/java/db2jcc.jar
↓
{WAS-CEのインストールホーム}/repository/com/ibm/db2/db2jcc/9.5/db2jcc-9.5.jar
で、もう一度、先ほどのCreate Database PoolのStep2画面に戻る。
すると、Dirver Jar一覧の中に、先ほどコピーした9.5用のドライバが出現するので、それを選択する。
あとはDB2の設定環境をそのまま入力。
DBのユーザ名、パスワードを入れて、
ホストやポートの設定をおこなう。
設定が終わったら、次のページ(Step 3)に行く。
ここでは、Final Pool ConfigurationとしてDBの接続テストを行う。
何も気にせず、「Test Connection」ボタンを押せばいい。
成功すると、以下のような画面が出る。
Deployボタンを押したら、設定完了。
設定が完了したところで、登録されたかどうかを確認する。
Geronimo、もといWAS-CEの管理コンソールより、「JNDI Viewer」を開く。
Search Textと書いてあるボックスに、先ほど設定したデータベースプール名「DB2Pool」を入力して、Findボタンを押す。
すると、「ResourceAdapterModule」という項目の配下に、
console.dbpool/DB2Pool/1.0/rar
という項目が出てくる。ちなみにrarというのはリソースアダプタ。決して圧縮解凍ではない。
次は、管理コンソールから離れて、Eclipse上で作業を行う。
新規プロジェクトで、[Web]-[動的 Web プロジェクト]を選択して、プロジェクトを作成する。
ここでは、プロジェクト名を「wasce_jndi_sample」とする。
ターゲットランタイムは「IBM WASCE v2.0 デフォルト構成」とする。
※一覧になければ、右側の新規ボタンを押して、「新規サーバ・ランタイム画面」から選択する。
「新規サーバ・ランタイム画面」になければ、その画面右上にある「追加サーバ・アダプターのダウンロード」リンクを押して、WASCEv2.0のアダプタをダウンロードする。
プロジェクトを作成したら、WEB-INF/web.xmlに以下を追加する。
次に、geronimo-web.xmlを編集する。
編集しようとすると、Geronimo配備プラン・エディターという画面に切り替わるので、
画面下にある「ネーミング」タブを選択する。
左上に「リソース参照」という項目が出るので、その中の「追加」ボタンを押して、
以下の設定で登録する。
参照名:jdbc/DB2DataSource
リソース・リンク:DB2Pool
次に、「デプロイメント」タブを押して、依存関係の設定を行う。
追加ボタンを押して、以下の設定で登録する。
グループID: console.dbpool
アーティファクトID: DB2Pool
バージョン:
Artifact Type:
これで環境面の設定は一通り完了。
ようやくネーミングを行うソースの作成に入れる。長い・・・。
DSLookup.javaを追加する。ソースの中身は以下のとおり。
ここまでで、必要な資材は準備完了。
Eclipseのプロジェクト・エクスプローラ画面から、wasce_jndi_sampleプロジェクトを右クリックして、
[エクスポート]-[WARファイル]を選択する。
適当なディレクトリに「wasce_jndi_sample.war」をエクスポートする。
次に、WAS-CEの管理コンソールより、「Deploy New」画面を開く。
Archive:は先ほど出力したwarファイルを選択する。
Plan:は、Eclipseのwasce_jndi_sample内にあるgeronimo-web.xmlを選択する。(先ほど編集してたやつね)
Start app after install のチェックをつけて、「install」ボタンを押す。
これで、デプロイ完了。
あとはブラウザからサーブレットにアクセスする。
web.xmlの編集にて、サーブレット名をlookupと指定したので、アクセスURLは以下のようになる。
http://localhost:8080/wasce_jndi_sample/lookup
こんな感じの画面が表示されれば成功!
brタグが余計だったorz
WASの面影が無い
まさにgeronimoだった
それはいいとして、WAS-CEでJDBCプロバイダってどうやって作成するんだ・・・
というわけで、セッティング。
【環境】
WebSphere Application Server Community Edition 2.0.0.1
DB2 9.5
開発環境にEclipseを使うならWAS-CEのサーバアダプタをインストールしておこう!
update siteはこちら。
http://download.boulder.ibm.com/ibmdl/pub/software/websphere/wasce/updates/
(注意)
Geronimoをインストールしている場合、環境変数「GERONIMO_HOME」を外しておくこと。
WAS-CEがGERONIMO_HOMEにあるgeronimoを見に行ってしまう。
#WAS-CEを初回起動したとき、コンソール画面がそのまんまGeronimoで思わず突っ込みを入れてしまった。
正しい画面を開いても、Geronimoそのままって感じですが。
(※見た感じはGeronimoの青い画面が紫になっただけ)
【前提】
DB2とWAS-CEはインストールしておいて、立ち上げておく。
DB2にはsampleデータベースをインストールしておく。
【手順】
WAS-CEの管理コンソールから「Database Pools」の管理画面を開く。
「Using the Geronimo database pool wizard」というリンクから、
新規にデータベースプールを作成する。
Create Database PoolのStep1画面が開くので、とりあえず、以下のように設定する。
Name of Database Pool:DB2Pool
Database Type:DB2
次のページ(Step2)に移ると、JDBCドライバを選択する画面になる。
しかし、DB2 9.5用のドライバが見当たらない。
「Download a Driver」というリンクボタンを押しても、DB2 9.5用のダウンロード先が出てこない。
そこで、DB2 9.5のインストール先からjarファイルをコピーする。
まず、9.5用のディレクトリを以下の場所に作成する
{WAS-CEのインストールホーム}/repository/com/ibm/db2/db2jcc/9.5
上記ディレクトリに、以下のdb2jcc.jarファイルをコピーして、「db2jcc-9.5.jar」という名前にリネームする。
{DB2 9.5のインストールホーム}/java/db2jcc.jar
↓
{WAS-CEのインストールホーム}/repository/com/ibm/db2/db2jcc/9.5/db2jcc-9.5.jar
で、もう一度、先ほどのCreate Database PoolのStep2画面に戻る。
すると、Dirver Jar一覧の中に、先ほどコピーした9.5用のドライバが出現するので、それを選択する。
あとはDB2の設定環境をそのまま入力。
DBのユーザ名、パスワードを入れて、
ホストやポートの設定をおこなう。
JDBC Driver Class: | |
---|---|
See the documentation for your JDBC driver. | |
Driver JAR: | |
The JAR(s) required to make a connection to the database. Use CTRL-click or SHIFT-click to select multiple jars. The JAR(s) should already be installed under GERONIMO/repository/ (or ) | |
DB User Name: | |
The username used to connect to the database | |
DB Password: | |
Confirm Password: | |
The password used to connect to the database | |
Driver Connection Properties | |
Typical JDBC URL: | jdbc:db2://{Host}:{Port}/{Database} |
Port: | |
A property used to connect to DB2. May be optional (see JDBC driver documentation). | |
Host: | |
A property used to connect to DB2. May be optional (see JDBC driver documentation). | |
Database: | |
A property used to connect to DB2. May be optional (see JDBC driver documentation). |
設定が終わったら、次のページ(Step 3)に行く。
ここでは、Final Pool ConfigurationとしてDBの接続テストを行う。
何も気にせず、「Test Connection」ボタンを押せばいい。
|
Create Database Pool -- Step 3: Final Pool Configuration |
成功すると、以下のような画面が出る。
|
Create Database Pool -- Step 4: Test Connection |
Deployボタンを押したら、設定完了。
設定が完了したところで、登録されたかどうかを確認する。
Geronimo、もといWAS-CEの管理コンソールより、「JNDI Viewer」を開く。
Search Textと書いてあるボックスに、先ほど設定したデータベースプール名「DB2Pool」を入力して、Findボタンを押す。
すると、「ResourceAdapterModule」という項目の配下に、
console.dbpool/DB2Pool/1.0/rar
という項目が出てくる。ちなみにrarというのはリソースアダプタ。決して圧縮解凍ではない。
次は、管理コンソールから離れて、Eclipse上で作業を行う。
新規プロジェクトで、[Web]-[動的 Web プロジェクト]を選択して、プロジェクトを作成する。
ここでは、プロジェクト名を「wasce_jndi_sample」とする。
ターゲットランタイムは「IBM WASCE v2.0 デフォルト構成」とする。
※一覧になければ、右側の新規ボタンを押して、「新規サーバ・ランタイム画面」から選択する。
「新規サーバ・ランタイム画面」になければ、その画面右上にある「追加サーバ・アダプターのダウンロード」リンクを押して、WASCEv2.0のアダプタをダウンロードする。
プロジェクトを作成したら、WEB-INF/web.xmlに以下を追加する。
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" id="WebApp_ID" version="2.5">
<display-name>wasce_jndi_sample</display-name>
<welcome-file-list>
<welcome-file>index.html</welcome-file>
<welcome-file>index.htm</welcome-file>
<welcome-file>index.jsp</welcome-file>
<welcome-file>default.html</welcome-file>
<welcome-file>default.htm</welcome-file>
<welcome-file>default.jsp</welcome-file>
</welcome-file-list>
<servlet>
<servlet-name>lookup</servlet-name>
<servlet-class>DSLookup</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>lookup</servlet-name>
<url-pattern>/lookup</url-pattern>
</servlet-mapping>
<resource-ref>
<res-ref-name>jdbc/DB2DataSource</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Shareable</res-sharing-scope>
</resource-ref>
</web-app>
次に、geronimo-web.xmlを編集する。
編集しようとすると、Geronimo配備プラン・エディターという画面に切り替わるので、
画面下にある「ネーミング」タブを選択する。
左上に「リソース参照」という項目が出るので、その中の「追加」ボタンを押して、
以下の設定で登録する。
参照名:jdbc/DB2DataSource
リソース・リンク:DB2Pool
次に、「デプロイメント」タブを押して、依存関係の設定を行う。
追加ボタンを押して、以下の設定で登録する。
グループID: console.dbpool
アーティファクトID: DB2Pool
バージョン:
Artifact Type:
これで環境面の設定は一通り完了。
ようやくネーミングを行うソースの作成に入れる。長い・・・。
DSLookup.javaを追加する。ソースの中身は以下のとおり。
import java.io.IOException;
import java.io.PrintWriter;
import java.sql.Connection;
import java.sql.SQLException;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.sql.DataSource;
public class DSLookup extends HttpServlet {
DataSource ds = null;
public void doGet(HttpServletRequest req, HttpServletResponse res) throws IOException {
Context context = null;
PrintWriter pw = res.getWriter();
try {
context = new InitialContext();
pw.println("get InitialContext: ok
");
}
catch(NamingException ne) {
pw.println("get InitialContext: ng
");
ne.printStackTrace(pw);
}
try {
ds = (DataSource)context.lookup("java:comp/env/jdbc/DB2DataSource");
pw.println("get DataSource: ok
");
Connection conn = ds.getConnection();
pw.println("get Connection: ok
");
} catch(NamingException ne) {
pw.println("get DataSource: ng
");
ne.printStackTrace(pw);
} catch (SQLException se) {
pw.println("get Connection: ng
");
se.printStackTrace(pw);
}
}
}
ここまでで、必要な資材は準備完了。
Eclipseのプロジェクト・エクスプローラ画面から、wasce_jndi_sampleプロジェクトを右クリックして、
[エクスポート]-[WARファイル]を選択する。
適当なディレクトリに「wasce_jndi_sample.war」をエクスポートする。
次に、WAS-CEの管理コンソールより、「Deploy New」画面を開く。
Archive:は先ほど出力したwarファイルを選択する。
Plan:は、Eclipseのwasce_jndi_sample内にあるgeronimo-web.xmlを選択する。(先ほど編集してたやつね)
Start app after install のチェックをつけて、「install」ボタンを押す。
これで、デプロイ完了。
あとはブラウザからサーブレットにアクセスする。
web.xmlの編集にて、サーブレット名をlookupと指定したので、アクセスURLは以下のようになる。
http://localhost:8080/wasce_jndi_sample/lookup
こんな感じの画面が表示されれば成功!
get InitialContext: ok
get DataSource: ok
get Connection: ok
brタグが余計だったorz
2007年8月4日土曜日
Google Analytics
Googleが提供するアクセス解析。
JavaScriptのタグを挿入するだけで、自動でアクセス解析をしてくれます。
Blog等では使えるサイトと使えないサイトもありますんで気をつけましょう。
GoogleAnalytics と検索すると直ぐに使えます、ただで。
世界規模のアクセス解析が可能。
データ収集に皆さんご協力お願いしますm(_ _)m
JavaScriptのタグを挿入するだけで、自動でアクセス解析をしてくれます。
Blog等では使えるサイトと使えないサイトもありますんで気をつけましょう。
GoogleAnalytics と検索すると直ぐに使えます、ただで。
世界規模のアクセス解析が可能。
データ収集に皆さんご協力お願いしますm(_ _)m
登録:
投稿 (Atom)
参加ユーザー
今月の本
- 臆病者のための株入門
- TSPガイドブック:リーダー編
- 夜明けの街で
- 詳解Oracleアーキテクチャ
- Ajax イン・アクション
- 実践Ajax
- すごい「実行力」
- More Effective C++
- 母子関係の理論
- コンピュータアーキテクチャのエッセンス