あぁ、普通にアプリケーションサーバー（Glassfish）にデプロイできる。今まで2年ほど出来ないと思ってた。
具体的にはwarアーカイブならば出来るということ。EJB-JarだとJTAとjta-data-source設定が必須で、それ以外はデプロイ時にはねられてしまう。普通JPA扱うときはEJB-JARで作るからずっと出来ないと思っていたよ。
あとはNetBeansはがわるいかGlassfishが悪いかしら無いけど、JPAがあるWarアーカイブを一度デプロイしてJPA起動させた後は、再デプロイしても新しい設定を認識できないという現象のおかげもあったかもしれない。アプリケーションサーバーを再起動させれば大丈夫だったけど。もしくは設定しだいでどうにかなるのかな。少なくともEJB-Jarは問題なく再配備等が綺麗に動く。
やっぱりWarだけだとどうしようもないのかな。JPAってデータソースと同様にアプリケーションより下位の層に配備されるものだからそのへんの問題かねぇ。TomcatのようにほとんどJavaSEな環境だとあくまでもいちライブラリという感じだけど。
とりあえず以前やったGuiceとJPAの連携はJTA必須だったけど、RESOURCE_LOCALも対応しておくか。というか、こっちをメインにするか。ついでにDIコンテナにも依存しないように。Guice以外にもSeasar2やSpringでも普通に動かしたいからね。もちろん、それぞれコンテナはJPAサポート用の環境はあったりするけど、JPA汎用でサポートして無いとか将来のバージョンアップが不透明だとかあるので。JPA2.0でたらすぐに2.0対応します！とはいかないだろうし。まぁSpringのほうはすぐやるだろうけどね。
とりあえずバージョンコントロールも含めて自分のペースで進めたい、細かいことも出来るのだろうけれども、複雑で大げさな仕組みはいらない、というのは大事かなと。
改めて思ったけど、JSFをやるのならEJBが相性はいいし、EJBをやるのならJPAは相性がいいということ。少なくとも開発効率はものすごくいいし。まぁ標準API同士で相性が悪かったらただの笑いものだけど。この中ではJSFだけアノテーションとかぜんぜんサポートしてなくて遅れてる感じが強いんだよなぁ。2.0で対応するけど、登場はまだ先だろうし。
[追記]
単なるサーブレットコンテナのTomcatだろうが、真っ当なアプリケーションサーバーだろうが最終的にはデータソース使ったほうが良いと思う。開発中は何をつかっても良いけど、最終的に出来上がるバイナリはテスト環境時と運用時とで1ビットも変えてはいけないと思うから。JPAに限らんけどね。
