トップページ⇒tech
1001コメント360KB

EJB(初心者歓迎）

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさんNGNG
EJBを勉強しています。
かなり複雑です。
そこでマッタリとEJBを語りましょう。
特にプログラミング技法など）
0237デフォルトの名無しさんNGNG
２３２＞＞WebObjectsと
JBでもできるんだけど
0238233NGNG
>>235
いや、知らないも何も、プロジェクトで使ってから
三年くらいになりますが・・・

>>236
J2EE仕様が最初に発表されてから５年くらいたちますが、
どのアプリケーションサーバベンダーも、いつまでたっても
パフォーマンス面の不安を解消できていません。
そのことについてどう思います？
特に、EJBのCMPは仕様自体に無理があると感じることはありませんか？
0239デフォルトの名無しさんNGNG
>EJBのCMPは

どの辺に無理があると思うの？
0240233NGNG
>>239
データベースのテーブルとのマッピングです。
テーブルのJoinをうまく表現できてないように思えます。
結局、１テーブルに単純に一行挿入したり、更新したりするのは
簡単にできますし、パフォーマンス的にも悪くないのですが、
複雑な構造をもったテーブルの検索にはうまく対処できません。

0241デフォルトの名無しさんNGNG
>>237
JBuilder Enterpriseと、WebObjectsを比べてるのか。
開発効率と実用的な運用まで考えたらJBは、WOに遙かに及ばないよ。
知名度と技術者確保に関しては、WOはJBに遙かに及ばないけど（ｗ
0242デフォルトの名無しさんNGNG
>218
うちのプロジェクトがまさにそう。
開発やってる人間にDDのここの設定
直してください。
って言っても、ﾊｧ?って答え。

その辺も面倒見れるだけの、人数が
基幹チームにいればいいだが、
どうしても手が足りないところとか、
力作業は開発にお願いすることになり、
結局なにもわかってない人相手にするのは
疲れるわけで。
嫁とはまだやってないわけで。
0243デフォルトの名無しさんNGNG
>>240
なんでもかんでも、
・複雑なテーブル構造
・SQL文
で解決しようと考えていることが間違い。
0244デフォルトの名無しさんNGNG
>>243
だからといって、EJBが最適とは言い切れないだろうけどな。
0245デフォルトの名無しさんNGNG
WebObjectsそんなにいいのか
WIN版ないの
0246デフォルトの名無しさんNGNG
Winでも使える
0247デフォルトの名無しさんNGNG
>>240
更新系はCMP-EB、参照系はSLSBからDAOコールというのが、
EJBの定石らしいぞ。まあ、通信に伴うネゴシエーションが
時間コストの大部分だということが分かっていれば、そう
するのが当たり前だという結論には当然達するはずだが･･･

なんで、そうしないヤツラがおおいんだろうね？
0248247NGNG
>>240

あと、EJB2.0のCMP仕様は、RDBのOuterJoinをCMPで表現
するらしいぞ。試してみたら？
0249デフォルトの名無しさんNGNG
みんな、EJBを開発する時の、開発者ローカルPC上での稼動確認はどうしてる？
EJBコンテナ環境とか、呼び出す為のクライアントとか。

やっぱJ2EE RIだのJBossだのフリーで軽いAPサーバを各開発PCに入れてそこでデプロイして、
わざわざドライバ作ってそこからアクセス？

0250デフォルトの名無しさんNGNG
>>248
この前のJavaOneで、そのあたりの話があってたね。
（結局良くわからんかったけど。）
0251デフォルトの名無しさんNGNG
>>249
そーだす。
0252デフォルトの名無しさんNGNG
>>249
私は JBuilder Ent版 を使っているので、付属のBorland Enterprise Server
をJBuilderIDE内から起動しています。
0253デフォルトの名無しさんNGNG
>>247
OptionAというものもあるようですね
http://bdn.borland.com/article/0,1410,29074,00.html
http://bdn.borland.com/article/images/29074/transaction_commit_options.pdf
0254デフォルトの名無しさんNGNG
質問があるのですが。

BorlandEnterpriseServerで、WebserviceパーティションにWebServiceを配布して
StandardパーティションにEJBのjarを配布させて、WebServiceからEJBを呼ぶ際に
Log4j.propertiesが見つからないってなExceptionが発生するんですが。
あと、CORBAのBAD_PARAMってなExceptionも。

すげー困ってるんでわかる方、教えてください。
BESの設定の問題？
とりあえずwarに、必要なライブラリは含めて配布してます。

0255デフォルトの名無しさんNGNG
>>254
C:\BorlandEnterpriseServer\var\servers\yourhost\adm\properties\partitions\standard\partition.properties
に、container.auto.expand.wars=true という行を追加しましょう。
webservicesパーティションにはこの行が追加されていることに注目しましょう。

この行があると、
C:\BorlandEnterpriseServer\var\servers\yourhost\partitions\standard\tmp
に、展開用のディレクトリが作成されます。

あと、
http://info.borland.com/devsupport/bes/faq/5.0/webfacilities/web_container.html#no_cgi
にも、目を通してください。
0256デフォルトの名無しさんNGNG
>>254
「CORBAのBAD_PARAMってなException」は、何が例外が出るようなことを
しているのでは?
0257デフォルトの名無しさんNGNG
>>254
ちと勘違いしました。
Log4j.propertiesが見つからないというのは、ApacheAXISの設定の問題ですね。
ApacheAXISのマニュアルなどを参考にしてください。
0258デフォルトの名無しさんNGNG
>>255-257
貴重なアドバイスありがとうございます！

warを解凍して実行するプロパティはTrueを指定したつもりだったのですが
もう一度確認してみます。

CORBAのExceptionの方がよくわからないのですが、EJBもWebServiceの
クラスもSerializableインターフェースを実装させているのですが、
そーいうたぐいのエラーなのでしょうか？

ちなみにJBuilder上でTomcatを起動している場合はEJBの呼び出しも、すべて
うまくいっています。

Log4jの件も、Axisのマニュアルを確認してみます。

ありがとうございます！
0259デフォルトの名無しさんNGNG
>>258
Log4j.properties の件は、AXISのライブラリをwarに含めるのではなく、
パーティションのlibディレクトリに置いたほうが良いかもしれません。

また、CORBAのException の件は、パーティションのクラスローダの設定
が関係しているかもしれません。
http://info.borland.com/devsupport/bes/faq/5.0/webfacilities/web_container.html#classcast
が参考になるかも。
0260デフォルトの名無しさんNGNG
>>259
問題の件は無事に解決させてきました。
非常に参考になり助かりました。

ありがとうございました！
0261デフォルトの名無しさんNGNG
google にでもどうぞ。
0262デフォルトの名無しさんNGNG
DD書く時に出てくるJNDI名とかJNDI名の参照って何ですか？ejb/xxxxxって書かせるヤツ。
あれ登録すると何がどうなるの？今は参考書の言われるままになんとなく書いているんだけど。
あれ書くとコードの中で"ejb/xxxxxx"とか直打ちしてるのが必要なくなるとか？
0263デフォルトの名無しさんNGNG
>>262
> DD書く時に出てくるJNDI名とかJNDI名の参照って何ですか？
EJBを(名前を付けて)登録してるの。

> コードの中で"ejb/xxxxxx"とか直打ちしてるのが必要なくなる

なくならないよ。その名前で呼びだせるようになるだけ。つうか、その
直打ちは、client側のコードでしょ。
0264デフォルトの名無しさんNGNG
>>262
コードの中に直打ちしたJNDI名がそのまま使われると、
あとでJNDI名の変更がやりにくいから、DDでマッピングする
仕組みが導入されたんだと思われ。
0265264NGNG
あれ？EJB参照の話をしているのかと思ってたけど勘違いだったか？
0266263NGNG
>>265
漏れが勘違いしたかも。。。
0267262NGNG
どもです。
確かJNDIを意識する必要があるのが、
・JAR自体につけるJNDI
・WARでつけるJNDI参照
・EARでつけるJNDI参照
・クライアントの直打ち
の4箇所だったと思うんだけど、
「JAR自体にJNDI名をつけてJNDIに登録して、クライアントからその名前で呼ぶ・・・というのは
分かるんだけど、WARやEARにJNDI参照をつけるのには何か意味があるのかなー？って
思ったわけです。コンテナがこの情報を使って何をしてるのかが分からないんです。
これって特に指定しなくても動作するものなのですか？

あと、リソース参照というのも分かりません。JDBCのDataSourceとかもここに登録するの？
今はコードのlookupで"jdbc/xxxxx"を決め打ちしてて、これで特に問題ないから気にしてないんだけど、
DDに記述すると何か挙動が変わるんでしょうか？

うーんどうやら根本的な知識が不足しているようだ。

0268263NGNG
>>267
少し遠まわりになるけど、
http://www.wakhok.ac.jp/%7Emaruyama/j2ee/j2ee/
とかで少し勉強することをおすすめする。
ちみなら、3〜4時間もあれば読み終る。
0269デフォルトの名無しさんNGNG
コード中で
lookup(java:comp/env/jdbc/hogeDatasource)
でルックアップしている場合は、そのENC(環境ネーミングコンテキスト）内の
jdbc/hogeDataSource
はDDの中で宣言しておかなければいけないのよ。

そのjdbc/hogeDataSource を、実際のアプリケーションサーバーで定義されているDatasourceの
JNDI名(myappli/fooDataSource)とbindingしなければいけないのよ。

jdbc/hogeDataSource -> myappli/fooDataSource

bindingの仕方はアプリケーションサーバーによって異なるのよ。

直接、lookup(jdbc/hogeDatasource)
のようにするのは、もう古いやりかたなわけよ。
0270262NGNG
>>268殿、>>269殿
大変参考になります。当方たった1人でJ2EEの調査やらされてるもので。
で、あまり頭よくないお馬鹿さんなので、もう少し質問させてください。
教えていただいたサイトはとりあえずJNDIの項目だけ読みました。
自分なりに以下のような手順になるのかな？と考えたんだけど、これであってますか？
（たぶん間違ってるだろうなぁ）

１．まずDDにJNDI名とその実体をバインディングするように記述する。
　　EJBであればEJB-JARのDDに、実体クラス名「samplepackage.HogeHogeHome」とJNDI名「ejb/HogeHoge」のマッピングを登録する。
　　JDBCであれば??????のDDに、定義Datasource名「sampledatasouece/HogeHogeDB」とJNDI名「jdbc/HogeHoge」のマッピングを登録する。
２．続いてDDにJNDI名と参照するクライアント側の変換マッピングを記述する。
　　EJBであればWARとEARに、使用するJNDI名「ejb/HogeHoge」とLookup名「sampleapp/ejb/HogeHoge」のマッピングを登録する。
　　JDBCであれば???????に、使用するJNDI名「jdbc/HogeHoge」とLookup名「sampleapp/jdbc/HogeHoge」のマッピングを登録する。
３．コードの中ではLookup名でNamingContextからオブジェクトを取得する。
　　EJBであれば、lookup( "sampleapp/ejb/HogeHoge" )とする。
　　JDBCであれば、lookup( "sampleapp/jdbc/HogeHoge" )とする。

??????の部分は分かりませんでした･･･

0271263NGNG
>>270
JDBCドライバをJNDI名にバインドするのは、各アプリケーションサーバによって違う。
基本的にはサーバの設定ファイルか、APIで設定する
0272262NGNG
どもです。>>271
そういえばJDBC設定はJ2EE RIではconfファイルに、WASでは管理コンソールからリソース設定した記憶があります。勘違いですｽﾐﾏｾﾝ。
「jdbc:oracle:thin:servername:sid|jdbc/HogeHogeDB」とかいうヤツですよね？

てことは１のステップでどこかにJDBC設定を行う必要はないってことですか？（APサーバとして既に設定されているから）
で、２のステップが、
「JDBCであればEJB-JARに、使用するJNDI名「jdbc/HogeHoge」（APサーバに登録済）とLookup名「sampleapp/jdbc/HogeHoge」のマッピングを登録する。」
となるんでしょうか？

0273263NGNG
>>272
良く見ると微妙に勘違いしてそう。基本は、jndi名でlookupするんだけど。
あと、earのDD(application.xml)ではJNDIの設定なんて無いけど。
0274デフォルトの名無しさんNGNG
あのう、突然でしかも根本的な質問なんですが…

sunのドキュメントとかネットの解説ページのEJBのサンプルって有りますよね。
あれってほとんどが同じVM上でクライアントのプログラムを実行してるじゃないですか

で、そのクライアントプログラムを別のVM上で実行しようとしてるんですが
それについての詳しい資料がみつかりません。

ネットで探したり本屋で立ち読みしたり（金がないんで）してどうやら環境変数を
設定して実行すればいいのかなとは思ったんですが（java -D…って感じで）
もう少し詳しい資料、もしくは環境変数の設定のし方を教えていただけませんか？
0275262NGNG
> 良く見ると微妙に勘違いしてそう。基本は、jndi名でlookupするんだけど。

あれ？そうなんですか？JDBCの話ですよね？
てゆうか今は実際にAPサーバに登録しているJNDI名をクライアントコードに
ハードコードして呼び出しているんだけど、
>>269では「直接書くのは古いやり方なのでDDでマッピングしたものを使うべき」
のようなコメントがあったので、むりやりそうしてみたんですけど。

> あと、earのDD(application.xml)ではJNDIの設定なんて無いけど。

「リソース参照」とかいうところがJDBC Datasourceのそれなのかなぁ？って思ってました。
これから会社に行ってもう一度見直してみます・・・。

0276デフォルトの名無しさんNGNG
DDのなかで宣言しておくのは、あくまで、コードの中で使われる仮の名前。
その仮の名前を実際のアプリケーションサーバーで定義されているJNDI名にマッピングさせるのがbinding。

bindingの方法はアプリケーションサーバーによって、異なる。
SUN J2EE RI なら sun-j2ee-ri.xml （だったっけ？）にその情報は書かれるし、
WebSphere なら ibm-ext-bnd.xmi に書かれる。
0277デフォルトの名無しさん ◆MSEEFfect2 NGNG
OREILLYの、J2EE読んでるけど、EJB1.0までしか書かれていないんです。（正確にはベータ）
「DD」の意味とか調べたいのですが、何を参考にされていますか。
よろしくだｺﾞﾙｧ
0278デフォルトの名無しさんNGNG
結局EJBって何なのですか？
本当に必要なんでしょうか？
どういった時に必要、もしくは威力を発揮するのでしょうか？
0279デフォルトの名無しさんNGNG
中小規模案件にEJB適用すると、
無駄にコストがかさむような気がするな。。。必要以上に複雑になるような。
メンテ性に悪い気もする。
0280デフォルトの名無しさんNGNG
>>279
279さんが書くコードよりはメンテナンス性は良いし、拡張性も良いと思います。
0281デフォルトの名無しさんNGNG
効率は上がるよ。
分かってる人が適切なツール使ってれば。
不勉強な人がviとか秀丸で作業してるようならお勧めできないが。
0282わかりません ◆MSEEFfect2 NGNG
>>278
分散環境で動かすビジネスロジックBean
>>279
メンテ性はEJBDocletに期待。と逝ってみるテスト
0283デフォルトの名無しさんNGNG
お前らがEJBやJ2EE適用してる案件って、どの程度の規模なんですか？
単純にServlet+JSP+JDBCでやったほうが効率いい場合ってありますよね？
0284EJBわかりません ◆MSEEFfect2 NGNG
>>283
EJBのパフォーマンスについては既出なのでsage
0285デフォルトの名無しさんNGNG
>>284
パフォ悪いってことでつか？
0286デフォルトの名無しさんNGNG
>>283
まさかとは思いますが、あなたは効率のみに注目しているのですか?
0287デフォルトの名無しさんNGNG
>>277
じゃ、OREILLYのEJB第３版はどうよ。
0288デフォルトの名無しさんNGNG
EJB で以下のようなメソッドがあった時、
処理異常で RemoteException を返すのはよいとして、
obj の値の組み合わせによって作業を継続できないような場合、
何を返すのが妥当なんでしょう？

public Object[] getXxx(Object obj)
0289デフォルトの名無しさんNGNG
よくわからんが。。。

　　呼ぶ前に例外がでないように検証する。
or RemoteException派生クラスを送出。
or RemoteExceptionを送出。
or nullを返す。
0290デフォルトの名無しさんNGNG
>>288
RemoteException を EJB内からthrowしちゃだめ。
これ常識。
ユーザー例外 か EJBException をthrowしましょう。
0291デフォルトの名無しさんNGNG
>>289
RemoteException派生クラスなんてもってほか。
ユーザー例外は、RuntimeExceptionやRemoteExceptionから派生しちゃだめ。
0292288NGNG
>>289さん、290さん、291さん

教えていただいたことで検索してみました。
EJB から throw した EJBException をコンテナが RemoteException に置き換える(らしい)から
RemoteException を使うのはだめ。
EJBException は RemoteException に置き換えられる(らしい)から
特定の例外を返すには向いていない気がしました。
となると、java.lang.Exception を継承した ユーザ例外を作成するのが
よいんでしょうか。
0293デフォルトの名無しさんNGNG
>>292
はい。java.lang.Exception を継承したユーザ例外を作成してください。
0294デフォルトの名無しさんNGNG
>>292
ただし、ユーザ例外の場合には自動的にはRollbackが掛からないから
気をつけてください。最終的にはEJBExceptionで包んだほうが良いかも。
0295デフォルトの名無しさんNGNG
>>292
ユーザー例外をthrowする前に、EJBContext#setRollbackOnly() を呼ぶという
のもオススメです。
0296289NGNG
おお、いらん恥かきつつも言ってみるもんだ。
どもです。勉強になりますた。
0297288NGNG
>>293さん、294さん、295さん、289さん、

コンテナ上で返す例外は、色々気をつけなければいけない事があるのですね。
勉強になりました。ありがとうございます。
0298デフォルトの名無しさんNGNG
ちょっと前に話題にのぼったJNDIのことなんだけど、
結局、EJBが持つデフォルトのJNDI名をそのまま使って呼び出しても問題はないわけね？

というか、今作っているシステムはそのまま素のJNDI名前でlookupかけていて、
WARからEJB参照は一切記述していないんだけど。
そもそもそのJNDI名自体が普遍的で変わることなんてなさそうだから。
（そもそもわざわざ別名をつける必要があるほど名前がコロコロ変わるシチュエーションなんてあるの？）

それによってパフォーマンスが落ちるとかはないんでしょ？

0299デフォルトの名無しさんNGNG
>>298
やめとけ。
悪い癖とわかっていながら、なぜそれを続ける？
名前が変わるからとかそんな単純な理由だけではないぞ。

NamingContextがDistributedなApplication Serverの場合、対応できないぞ。
そもそもSpecで直接lookupするやり方は完全にDepｒecatedとされている。
0300デフォルトの名無しさんNGNG
>>274
あなたの環境は知らないがだいたいやることは。
・クライアント用JDNINamingContextFactoryが入ったjarを入れる。（アプリケーションサーバについてるぞ）
・EJBのスタブを入れる。（インターフェースだけでも結構です）
・InitialContextのコンストラクタにJndiのパラメータを突っ込んでnewする。（アプリケーションサーバ依存）

あとはおんなじ。
PotableRemoteObject.narrow()でキャストすんのを忘れんなよ！

0301デフォルトの名無しさんNGNG
>>299
そんなに悪い癖では無いとおもうよ。
EJBのクラスタリングに対応出来る可能性が大きいしね。
0302274NGNG
>>300
ありがとうございます。
InitialContextのコンストラクタに引数を与えるということをしていませんでした
どこかの本にInitialContextには引数を与えないほうがいいみたいなことが書いて
あったような気がして（勘違いかも）…

とりあえず300ｹﾞﾄおめでとうございます
0303デフォルトの名無しさんNGNG
>>301
逆だろ？
対応できなくなる可能性があるぞ。
0304　NGNG
JNDIってEJB以外でも使いますか？
EJBを極めるにはJNDIをEJBとは個別に勉強しなきゃならないの？
0305デフォルトの名無しさんNGNG
＞JNDIってEJB以外でも使いますか？

J2EE専用の技術ってわけじゃないよ。
名前とリソースの関係を扱う一般的な技術。

一応チュートリアル貼っとく。
http://java.sun.com/products/jndi/tutorial/getStarted/index.html
0306デフォルトの名無しさんNGNG
>>303
詳しく説明してください
0307デフォルトの名無しさんNGNG
>>302
確かにコンテナ内でEJBがInitialContextを呼び出すときは、デフォルトコンストラクタを使うのが良いです。
まず問題ないし、ポータビリティが増すからね。
対してEJBクライアント単体ではどのコンテナにつなぐかわからないから、引数つきでも良いんだと解釈しています。
実際そうしないしないと、呼べないし（藁）。
0308デフォルトの名無しさんNGNG
>>306
クラスタ環境だと、deploy時に特別なJNDI名とbindingしなければいけないってことはよくあることだよ。
例をあげると、WebSphere V5の場合
cell/cluster/clustername/ejb/yourHome
のようにね。
アプリケーションサーバー依存のこういうことを、
コード中で意識したくはないでしょ。
0309デフォルトの名無しさんNGNG
>>308
WebSphere V5 以外には?
0310デフォルトの名無しさんNGNG
>>308
へー。
ちなみに Borland Enterprise Server だと、
・JNDI名直接
・java:comp/env/ejb/XXXX による環境変数
のどちらでも、勝手にクラスタリングやフェイルオーバーが掛かりますね。
特別なJNDI名にしなきゃいけないのは使えないですね。
0311デフォルトの名無しさんNGNG
>>310
BESってCORBAだと実績のあるVisiBrokerベースだし、
WASより使い勝手いいと思うんだけど、普及しないね。

やっぱ某の営業がヘタだからかな(藁
0312デフォルトの名無しさんNGNG
JNDI名直接でやりたいって言っている人たちって、ようするに
直すのがめんどくさいだけなんでしょ。
勝手にすればいいじゃん。
0313　NGNG
アホなスレ・・・
0314デフォルトの名無しさんNGNG
>>313
どこが?
0315288NGNG
ユーザ例外は作成したのですが、
int 値は基本データ型なので、クライアントに送信できますが、
String は参照型なので、セットする XxxException(String code) のような
コンストラクタでセットした値は null になってしまいました。
この String をクライアントに送信するにはどうすればよいのでしょうか？
0316デフォルトの名無しさんNGNG
>>315
どのようなユーザー例外を作成したのですか?
具体的に書きましょう。
0317288NGNG
御助言をお願いします。
以下のように実装されている Exception に対し XxxException(Throwable , int) でインスタンスを生成した時、
EJBを呼び出しているクライアントで getCode() をすると、設定した int 値を返すのですが、getCause() は null を返すのです。
EJB の中でこの Exception を catch した後に getCause() した時は Exception を取得できます。

public class XxxException extends Exception {

  private Exception detail;
  private int code = NULL;

  public XxxException() {}

  public XxxException(Exception e) {
    this.detail = e;
  }

  public XxxException(Exception e, int code) {
    this.detail = e;
    this.code = code;
  }

  public int getCode() {
    return code;
  }

  public Exception getCause() {
    return detail;
  }
}
0318288NGNG
切抜きだったのでゴミが入っていますが、NULL は 定数の -1 です。
0319デフォルトの名無しさんNGNG
>>317
> private int code = NULL;
NULLとはなんですか?
正確に書きましょう。
0320288NGNG
お手数をおかけして申し訳ないです。
int型の定数の -1 です。

private static int NULL = -1;
0321デフォルトの名無しさんNGNG
>>317
Borland Enterprise Server 5.1 にて試しましたが、以下のようになりました。
うまく行っているようです。

---- EJB実装 --------
try {
... // lookupを意図的に失敗させる
} catch (Exception ex) {
throw new mypack.MyException(ex, 99);
}

---- EJBクライアント --------
try {
remote.foo(); // EJBを呼び出す
} catch (MyException ex) {
System.err.println(ex.getCause()); // javax.ejb.ObjectNotFoundExceptionと表示
}
0322288NGNG
>>321
結論からいうと、うまく動きました。
321さん。深く感謝します。

うまく動いていないと思ったのは、
EJB から返ってきた XxxException を JSP でデバック出力していたのですが
デバック出力するスタックトレースが失敗して発生していた例外と、
Servletで表示していた getCause() の例外を見誤っていた。
コーディングミスで throw new XxxException(e) したのを再 catch していたみたいで
思っていたエラーが表示されない→XxxException が動いていない、
と思ってしまったのが原因でした。
0323デフォルトの名無しさんNGNG
ちょっと前の話になるけど、EJBを作る際の例外の扱い方について確認していいですか？

・EnterpriseBeanからRuntimeException／RemoteExceptionおよびそれを継承した例外をスローしてはならない。
・EJBExceptionはEJBコンテナによってRemoteExceptionに置き換えられる。
・基本はEJBExceptionをスローすることだが、EJBExceptionだけでは自由度が高くない為、Exceptionを継承したカスタム例外クラスを作るとよい。その場合、カスタム例外クラスはRemoteExceptionから派生してはならない。

以上を受けて…

・Homeインターフェイスについては、CreateExceptionとRemoteExceptionをスローする。
・Remoteインターフェイスについては、RemoteExceptionまたはカスタム例外をスローする。
・EnterpriseBeanについては、EJBExceptionまたはカスタム例外をスローする。
・但しコンテナがコールバックするメソッド（ejbXXXX）はRemoteExceptionをスローする。（ejbCreateのみCreateExceptionとEJBExceptionをスローする）
・EnterpriseBeanからカスタム例外をスローする場合（つまりEJBExceptionをスローしない場合）は、rollback処理を自己責任で実装する。（EJBContext#setRollbackOnlyを呼ぶ等）

こんな認識で合ってます？

0324JNDIﾜｹﾜｶﾗﾝNGNG
今までJNDIにEJBバインドを行っていなかったのだけど、最近のスレを読んでJNDIを登録してみようと思った。
（使っているのはWebSphereだが、まずJ2EE RIから確認してみようと思っている）

で、まずEARのsun-j2ee-ri.xmlに以下を記述。

<enterprise-beans>
　<ejb>
　　<ejb-name>HogeHogeBean</ejb-name>
　　<jndi-name>sample/HogeHoge</jndi-name>
　　　：
　</ejb>
</enterprise-beans>

これでHogeHogeBeanがsample/HogeHogeという名前でJNDIに登録されるようになる（はず）。
次にWARのweb.xmlに以下を記述。

<ejb-ref>
　<ejb-ref-name>ejb/HogeHoge</ejb-ref-name>
　<ejb-ref-type>Session</ejb-ref-type>
　<home>test.sample.HogeHogeHome</home>
　<remote>test.sample.HogeHoge</remote>
</ejb-ref>

これでWAR内のプログラムからejb/HogeHogeという名前で呼び出せるようになる（はず）。
0325JNDIﾜｹﾜｶﾗﾝNGNG
続き

最後にEARのsun-j2ee-ri.xmlに以下を記述。

<web>
　<ejb-ref>
　　<ejb-ref-name>ejb/HogeHoge</ejb-ref-name>
　　<jndi-name>sample/HogeHoge</jndi-name>
　</ejb-ref>
</web>

これでWAR内のプログラムからejb/HogeHogeをlookupすればsample/HogeHogeにバインディングされて登録されているEJBが呼び出せる（はず）。
なのに実行するとjavax.naming.NameNotFoundExceptionがでてしまう。
なんか設定間違ってる？
JNDI関係はマニュアルが少ないからよく分からん。
0326デフォルトの名無しさんNGNG
>324
ejb/HogeHogeというのはweb.xmlとsun-j2ee-ri.xmlを結びつけるためのもので、
lookupすべきはsample/HogeHogeかと。

>323
た、多分それで…
0327デフォルトの名無しさんNGNG
>>323

>・Homeインターフェイスについては、CreateExceptionとRemoteExceptionをスローする。
CreateExceptionとRemoteException だけとは限らないですよね?

>・Remoteインターフェイスについては、RemoteExceptionまたはカスタム例外をスローする。
RemoteExceptionまたはカスタム例外 だけとは限らないですよね?

>・EnterpriseBeanについては、EJBExceptionまたはカスタム例外をスローする。
EJBExceptionまたはカスタム例外 だけとは限らないですよね?

>・但しコンテナがコールバックするメソッド（ejbXXXX）はRemoteExceptionをスローする。
RemoteException だけとは限らないですよね?
0328デフォルトの名無しさんNGNG
>>327

可能かどうか？ではなく、それが推奨されているかどうか、EJB作法として一般的かどうか？
について考察しているから、「〜だけに限らない」のであれば、その「限らない」ものが何か？
そしてそれがどのくらい一般的で意味のあるものかどうかを書かなければ相手にされませんぞ。

0329デフォルトの名無しさんNGNG
>>328
「限らない」=「いくらでもある」ということでは?
0330デフォルトの名無しさんNGNG
興味あるので具体例ｷﾎﾞﾝﾇ
0331デフォルトの名無しさんNGNG
>>326
>ejb/HogeHogeというのはweb.xmlとsun-j2ee-ri.xmlを結びつけるためのもので、
>lookupすべきはsample/HogeHogeかと。

話の流れとはあまり関係ないが、lookupする名前はejb/xxxxxxにして、実際に登録する名前をsample/xxxxxxにするのが良いと聞いたことがある。
PetStoreもJNDI名はestore/xxxxxxにしてlookupはejb/estore/xxxxxxみたいな感じだったよね？
勘違いならｽﾏｿ
0332デフォルトの名無しさんNGNG
別掲示板とのマルチポストでスマンが、
Stateless Session Beanで、リクエストの実行数を制御することは可能？

具体的には、１つ１つのStateless Session Beanに対して、
・デフォルトで実体化されていてリクエストを待ち受けているインスタンス数を設定する
・大量リクエスト要求による負荷アクセス時に、最大同時リクエスト処理数（＝インスタンス数）の
上限を設定しておき、残りのリクエストについてはキューイングする

といったことが行いたいのだけど、こういうのってEJBコンテナの設定で可能なのかなぁ？

0333デフォルトの名無しさんNGNG
>>332
Stateless Session Beanって、最大リクエスト数=インスタンス数には
ならないのではないでしょうか。
たいていはスレッド数の上限を設けることで制限すると思うけど、
個々のBean毎にそれが設定できるアプリケーションサーバは
あんまり見たことないような。私が知っているものは限られているので
あるのかもしれませんが。
っていうか、そういうことってマニュアルに書いてないですか？
0334デフォルトの名無しさんNGNG
>>332
できるよ。
InfoCenterみてみなよ。
0335ageNGNG
Session Bean使う場合って、Stateful Session Beanって本当に必要？
よくショッピングカートを例にして「カートはStateful Session Beanにしましょう」なんていってるサンプルあるけどさ。
そんなのすべてStatelessにしてデータを取得したら全てVOにしてServlet側のSessionに格納したほうがはるかに便利じゃない？
0336デフォルトの名無しさんNGNG
>>335
WebApplication作るときにもHttpSession使わず、Statelessな仕組み
のみで行くの?
■ このスレッドは過去ログ倉庫に格納されています