2010年1月30日土曜日

GlassFishV3 OSGi でのJNDIにバグあり

内部JMS.ConnectionPoolへのlookupが成功したり失敗したりするので、どうもおかしいなと思って調べていたら、ここにバグとして出ていた。

* 1度以上OSGi以外からlookupしていれば見つかるが、そうでないとだめ。
* 3.0.1で修正の見込みの模様

ただし、外部リソースへのlookupは問題ないようだ。

2010年1月27日水曜日

GlassFish(V3) での JMS-MQ(Embeded)

OSGiからJNDI/JMSを利用していてトラブったのでメモ:

GFでEmbedモードの時は、ConnectioFactoryは1つしか作成できない模様。
正確にいうと、作成できるが使用できるのが一つとなる模様。
なぜこれに気づいたかというと、JNDIの一覧を見ていて、4つ作成したCFの中でまともに登録されているのが最初の1つだけだったことから思いついた。
 複数指定していたCFの設定を1つにまとめたところ、嘘のように動作した。

その他のトラブル:

OSGiでは、Thread.currentThread().getContextClassLoader() で返ってくるのが独自のものになる、そのためにContextClassLoaderを利用している部分があると、クラスが見つからなかったり、CASTできなかったりというトラブルが発生する。これは、Activatorのstart(BundleContext bc) などの時も同じであり、そのまま使用するとはまる。

さらに、JMXから呼び出した場合や、JMSのListenerのThreadからonMessage()された場合もやはり異なっているようで注意が必要だ。

残っている問題:

JMS/MessageListener の登録とThreadを完全に消去する方法が不明:
setMessageListener(null); だと、OracleAQではエラーになる。
完全はThreadの停止方法が知りたい!

Class AQjmsConsumer のJavaDocによると、AQjmsConsumer#close()は、ブロックする仕様となっている。

This call blocks until a receive or message listener in progress has completed. A blocked message consumer receive call returns null when this message consumer is closed.