2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

EJB(初心者歓迎) 2

1 :デフォルトの名無しさん:03/05/31 14:00
1000を超えたので、新たにスレたてました。

EJBを勉強しています。
かなり複雑です。
そこでマッタリとEJBを語りましょう。
特にプログラミング技法など)

前スレ
http://pc2.2ch.net/test/read.cgi/tech/1017240849/


2 :デフォルトの名無しさん:03/05/31 14:05
2GET

3 :デフォルトの名無しさん:03/05/31 14:22
また初心者歓迎かよ(;´Д`)



4 :デフォルトの名無しさん:03/05/31 14:38
前スレで ejb-client.jar を知りたがってたやつのために一肌脱ぐ。

EJB は Home インタフェース、コンポーネントインタフェース、実装 Bean クラスで構成されている。
前 2 つのインタフェースは、EJB を呼び出すときにソースコードに書く必要がある。
逆に実装 Bean クラスの呼び出しは EJB コンテナが自動生成するクラスが行うから書く必要がない。
つまり、EJB の利用側には前 2 つのインタフェースさえクラスパス上に存在すればよい。

じゃあ次に、インタフェースのメソッドシグネチャについて考える。
たとえば、価格を計算して PriceInfo クラスを返す EJB のメソッド calculate があるとする。
お金じゃ買えない価値がある場合には PricelessException をスローする。
 public PriceInfo calculate() throws PricelessException
これを使うには、クラスパスに PriceInfo クラスや PricelessException も必要になる。

EJB コンテナと Servlet コンテナは、異なるクラスローダを持つ。
加えて、Web アプリも独自のクラスローダを持つ。
これらは同じ JVM 上の異なるクラスローダかもしれないし、そもそも JVM が異なるかもしれない。
クラスローダが異なるということは、クラスパスも異なるということだ。

Webアプリ上で、上で説明した EJB を利用するには、クラスパス上に次のものがあればよい。
 ・Home インタフェース
 ・コンポーネントインタフェース
 ・PriceInfo クラス
 ・PricelessException クラス
これらをまとめて .jar にしたのが ejb-client.jar ファイルだ。







5 :デフォルトの名無しさん:03/05/31 14:44
開発時の話について。

EJBを呼び出す側のクラスを記述するとき、どうにかしてコンパイルしなければならない。
このとき、EJBの実装Beanクラスが完成していなくても、ejb-client.jar さえあればコンパイルすることができる。

EJBメソッドシグネチャさえ変えなければ、
どれだけ実装Beanクラスの内容を変えようとも呼び出し側には何の影響もない。

つまり ejb-client.jar は、コンパイルのために必要なクラスを集めた .jar ファイルということだ。



6 :デフォルトの名無しさん:03/05/31 17:58
>>4-5
ありがとう!ようやく分かりました!
感謝いたします。


7 :デフォルトの名無しさん:03/05/31 18:21
>>4-5
最初から素直に回答していれば荒れずに済むんだ。

8 :デフォルトの名無しさん:03/05/31 19:03
実際に開発された方に質問です。
実際のプロジェクトでは、
いろいろなクラスから使用される、ビジネスロジックをまとめた共通(Utility)クラスが抽出されると思われますが、

I.どのように共通クラスを提供しましたか?
  1.SessionBean
  2.通常のクラス(JavaBeans)+IF
  3.その他?

U.通常のクラスで作成した場合、パッケージングはどうされましたか?
  1.Utilクラスを利用している全てのWar、ejb-jarに詰め込む。
  2.APサーバのCLASSPATHに追加し、War、ejb-jarには含まない。
  3.その他?

9 :デフォルトの名無しさん:03/05/31 19:10
今回は、良スレの 予 感 !!

10 :直リン:03/05/31 19:13
http://homepage.mac.com/yuuka20/

11 :デフォルトの名無しさん:03/05/31 19:15
"ejb-client"という名称に惑わされがちだが、平たい話がcorbaでいうスタブの類。


12 :デフォルトの名無しさん:03/05/31 19:23
J2EEと同等の仕組みをCで実装してみました。すっごい速いです。

13 :デフォルトの名無しさん:03/05/31 22:16
>8
>3.その他?

別のjarにまとめ、EARに一緒にいれる。
warやejb-jarから見えるように、MANIFEST.MFのClasspath:にそのjarへのパス(EAR内の相対パス)
を書いておく。
これが一番自然、かつ無駄がない。

14 :デフォルトの名無しさん:03/06/01 02:53
>>13

EARファイルに入れるなら、ejb-jarと一緒にjarで固めても良いのでは?

こちらでは、MANIFEST.MFに書くのは外部から提供されているjarファイル
に対して使うことが多いです。

15 :デフォルトの名無しさん:03/06/01 21:40
実際にアーキテクトとしてプロジェクト開発した方に質問です。

1.EntityBeanを使用する際にBMP、CMP選択基準とはなんでしょうか?
  使い分ける基準って言うのはあるのでしょうか?

2.CMPは基本的に1テーブル=1エンティティBeanにしかできないのでしょうか?


16 :デフォルトの名無しさん:03/06/01 21:48
>>15
1. 参照系は基本的にBMP。テーブル結合があるので。

2. そのはず。

17 :デフォルトの名無しさん:03/06/01 22:15
>>16
対ViewでCMPしたり、CMR使ったりするよりBMPでごりごりのほうがいいのですか?

18 :デフォルトの名無しさん:03/06/01 22:20
>>17
よかないよ。仕方なくという感じ。
EJB2.0に完全準拠してる製品使ってないから。
理想通りの使い方するにはもう少し時間がかかると思う。

19 :デフォルトの名無しさん:03/06/01 22:40
おれはむしろBMPとセッションBEAnの
切り分けかたを聞きたい。CMPはコード書かないだけ
メリットあるかもしれんがBMPでSQL書くなら
あまりセッションBEANにSQL書くのと代わらないような気がする
それとベンダーによるEJBの設定の違い。
なんとかする気はないのか
write onece run anwherが泣いているぞ


20 :デフォルトの名無しさん:03/06/01 22:44
>ベンダーによるEJBの設定の違い。
>なんとかする気はないのか
この秋に出るJ2EE1.4ではデプロイヤAPIが共通化されるそうだが、
実際どんなもんだろうね。ちょっと期待。

21 :デフォルトの名無しさん:03/06/01 22:44
ついでにだめだめのIDEを何とかしろ。
何回1日にフリーズするんだ。
(誤)write once run anywhere

22 :デフォルトの名無しさん:03/06/01 22:44
>>15-17
参照系ではEntityBeanを使う必要はないでしょう。
SessionBean+DAO(DACB)で実装した方が、性能、メモリ効率を考えると全然いいと思う。

1.CMP2.0が出た今はBMPは必要ないと思います。
  懸念点はEJB-QLがしょぼいという点があるけど、それもそのうち解消されていくし、
  そこらへんはAPサーバベンダーが上手いことやっているから、問題ないでしょう。
  そのうちBMPは消えていくんでは?

2.そうでしょう。
  だからあまり粒度の小さいテーブル使ってしまうと、
  多重EntityBean問題が発生して辛いかも。
  そう思うと、ここでBMPを使うべきなんかなぁ


23 :デフォルトの名無しさん:03/06/01 22:49
>>19
永続化コード(SQL文)とビジネスロジックの切り分けでしょう。

SessionBean+JDBCで実装した場合、
ビジネスロジックにSQL文が混ざって、メンテナンス性がひどいことになる。
いろいろなSessionBeanに一つのEntityBean更新ロジックが混ざりこんでしまう。

BMPで実装すると、ビジネスロジックと永続化コードが分離され、
永続化コードはBMP+DAOで隠蔽+局所化されるので、
メンテナンス性は向上するんじゃない。
Entity更新したければ、BMPを更新するだけなので。

24 :デフォルトの名無しさん:03/06/01 22:56
だーかーら、CMP2.0が出たのと実際の現場で使うのとでは大きなタイムラグがあるんだってば。

25 :デフォルトの名無しさん:03/06/01 22:58
>>24
確かにCMP1.Xの時代にはBMPを使うしか選択肢がなかったと思う。
ただ現状はもうAPサーバがCMP2.0を実装してきているので、
もはやBMPは捨ててもいいのでは?
めんどくさいし。

26 :デフォルトの名無しさん:03/06/01 23:39
>>25
今からはじめるならEJB2.0が良いのだろうね、きっと。
でも、俺の場合今やってるEJB1.1のプロジェクト1〜2年続く予定なので、
2.0に実務で触れることができるのは相当先なんだよな。
J2EE変化早すぎて、ついていけねえよ。と思っているのは
俺だけじゃないはずだ。

27 :デフォルトの名無しさん:03/06/01 23:45
> J2EE変化早すぎて、ついていけねえよ。と思っているのは
> 俺だけじゃないはずだ。
特にEJB使うようなプロジェクトは期間も長いからね。

28 :デフォルトの名無しさん:03/06/02 03:19
つまらん質問だが
セッションビーズでclass.forname(・・・
と使ってはいけないのか?

29 :デフォルトの名無しさん:03/06/03 03:57
>>28
そんなアーティストはいない

30 :デフォルトの名無しさん:03/06/03 04:34
なぜじゃ・・・
なんでじゃ
どうしてじゃ

31 :デフォルトの名無しさん:03/06/03 06:51
個人的にはJ2EE2.1対応のアプリケーションサーバが出揃うまでCMPは待ちかなという感じなのですが。
皆さんはいかがですか。
そんなに永続化フレームワークに困窮してますか。

32 :デフォルトの名無しさん:03/06/03 07:41
何年後の話でつか?
>J2EE2.1

33 :デフォルトの名無しさん:03/06/03 08:01
Strutsでいいじゃん。

34 :デフォルトの名無しさん:03/06/03 09:58
>>33
EJBの代わりになるのか?
Strutsってなんだか知ってる?

35 :デフォルトの名無しさん:03/06/03 10:03
RMI+JDOはだめかなぁ?

36 :デフォルトの名無しさん:03/06/03 10:03
あ、トランザクションが無理か・・・

37 :デフォルトの名無しさん:03/06/03 23:45
じゃ CORBA+JDOってことで

38 :デフォルトの名無しさん:03/06/04 02:19
JTAサーバってないかねえ

39 :デフォルトの名無しさん:03/06/04 02:40
結局EJBは不可分散び部分はロードバランサでカバーできるから
分散トランザクションぐらいしかメリットはみえないが
再利用はうまくいっているようにはみえないが(w

40 :デフォルトの名無しさん:03/06/04 02:54
EJBって、RMIのラッパーとして便利、という程度じゃ導入理由にならんのかな?

41 :デフォルトの名無しさん:03/06/04 22:10
メリットは分散トランザクションだけか(w

42 :曲尾:03/06/04 22:12
うんこ

43 :デフォルトの名無しさん:03/06/05 03:27
EJBQL書かなあかんのやったら
BMPでいいじゃん
EJBQL覚えるんだったら
SQLに精通したほうがまだマシ
余計にややこしくして何考えてんだよ
それから、EJBに限らんがDDに頼りすぎだよ
DDの設定がこうも多いと
DD書いてんのかプログラム書いてんのかわかんねーよ
わけわからんよこの仕様

EJBは仮名で書くと「いーじぇいびい」
自信満々で偉そうで、腹が立つ
「おら、どうだ、すげーだろ?」的な態度がむかつく
ティンティンデカイだけで自信もってる男性と一緒だ

その点SQLは「えすきゅーえる」
すごく腰がひくく、やさしそう。女ならお嫁さんにしたい感じ
「ども。ぼくSQLです。がんばりますのでよろしくお願いします。」
すごくいい感じ、いしょうけんめいやってくれれば
女性にも母性本能が沸いてくるよ
基本は愛情があるかないかってこと





44 :デフォルトの名無しさん:03/06/05 04:25
これがEJBのすべてだ
http://cgi.members.interq.or.jp/hokkaido/asato/upload/jam3ddr/OB000694.jpg

45 :デフォルトの名無しさん:03/06/06 13:45
すいません教えてください
CMPをやってみたんですが
なぜ、EJBコンテナをシャットダウンすると
データベースのデータも消そうとするのでしょうか?
せっかく入れたデータが台無しですよ
っていうかejbRemoveをコンテナが呼んだときは
そういう仕様になってるんですか?
なんでそうなってるのか教えてください
まったく理解できない
データベースのデータが消えたら何にもなんないと思うんですが・・・


46 :デフォルトの名無しさん:03/06/06 20:49
> っていうかejbRemoveをコンテナが呼んだときは
> そういう仕様になってるんですか?

この辺の、日本語がよくわからない。なにを言いたいの?

bean.remove()でデータが消えるのは当たり前のことだと思うのだが。

47 :デフォルトの名無しさん:03/06/06 21:12
>>45
> データベースのデータが消えたら何にもなんないと思うんですが・・・

まぁそりゃそうだ。
ところで「永続化」って言葉、聞いたことない?


48 :無料動画直リン:03/06/06 21:13
http://homepage.mac.com/norika27/

49 :デフォルトの名無しさん:03/06/06 22:27
初心者です。
同じオブジェクトが各サーバにありアプリケーションサーバがそれを
不可分散に応じて選択。ただしロードバランスと違うのは
分散トランザクション機能がある。これがEJBのメリットなんですか?
他にメリットありますか?

50 :デフォルトの名無しさん:03/06/06 22:59
>49

メリット、メリットうるさいよ。
この小心者。

PetStoreのソースでもよめ。

51 :デフォルトの名無しさん:03/06/07 00:07
( ´,_ゝ`) プッ

52 :デフォルトの名無しさん:03/06/07 00:17
EJBで使われるパターンはプログラミングで参考になる事も多い。

53 :デフォルトの名無しさん:03/06/07 00:27
ということは技術者のマスターベーションがEJBなんですね(w

54 :45:03/06/07 01:12
>>46 >>47
データベースのデータも消えてしまうんだったら
一度立ち上げたAPサーバ一回も、とめること出来ない
と思うんですが・・・
デプロイアンデプロイもできなくなっちゃう


55 :デフォルトの名無しさん:03/06/07 02:42
>>54
あ〜俺も疑問だ
remove()呼び出しが
クライアントだけならデータ消しても当然だが
コンテナシャットダウンしたとき、
モジュールデプロイしたときも
勝手に呼び出されて
DBのデータ消されるもんな
ずーっと、DB内にデータだけ残しておきたいときって
どうすんだろ

56 :デフォルトの名無しさん:03/06/07 03:28
ejbRemove()に削除を実装してるのか?

57 :45:03/06/07 03:48
>>56
いえ、空っぽのままです
だから、何もしないようにしたいんですが
どうすればいいのかわからないので・・・
空っぽのやつを定義しておけば
何もやらない(DBのデータ削除しない)と思ってるんですが
違うんですか?

58 :45:03/06/07 03:48
CMPです

59 :デフォルトの名無しさん:03/06/07 04:08
ほほう、findByPrimaryKey()は見つからなければ
例外出すが
自分で定義したfinderメソッドは
例外出さないのか・・・
ちょっと勉強になった

60 :デフォルトの名無しさん:03/06/07 07:38
>>45
ひょっとしてSunのJ2EESDKを使っている?
deploytoolのEntityBean設定には、アンデプロイする時に
テーブルも同時に削除するオプションがあって、
デフォルトでオンになっています。

61 :デフォルトの名無しさん:03/06/07 10:28
>>60
いえ、JBossです
J2EESDKも以前やりました、結果は同じでした
こういう指定は、DDでやるのですか?
DDの書き方教えていただけると幸いです
どの解説書もそんな設定のこと書いてないので・・・

実際に重要な情報(たとえば商品購入のリスト)
が消えたら意味ないじゃん?と、思いました
クライアントコードからremove呼んだらDB上の
データも削除されるのはわかる
しかし、デプロイやAPサーバシャットダウンのときも
コンテナによって勝手に削除されるっていうのが
納得いきません。だってそれだったら普通のクラスと
変わらないんじゃ・・?なんのためにDBに保存しているのか
理解できません



62 :デフォルトの名無しさん:03/06/07 10:53
<defaults>
<datasource>java:/PostgresDS</datasource>
<datasource-mapping>PostgreSQL 7.2</datasource-mapping>
<create-table>true</create-table>
<remove-table>true</remove-table>←ココ
</defaults>

63 :デフォルトの名無しさん:03/06/07 10:59
>>61
いえ、DDでやるわけではありません。
EJBの仕様には含まれていませんし、
普通の製品(WebLogicやWebsphere)などでは、
そういったオプションはなかったと思います。
J2EESDKのその機能は、どっちかといえばサンプルアプリを
簡単に動かすための付加機能ととらえるべきでしょう。
実業務でそんなことするはずがありません。
JBossは触ったことはありませんが、おそらく同じ理由で
そういう機能が付いているんじゃないでしょうか。
多分、オプションをはずすことが出来ると思いますので、
マニュアル読んで自分で対処して下さい。

64 :デフォルトの名無しさん:03/06/07 11:06
>>62が答えだしてます


65 :デフォルトの名無しさん:03/06/07 11:31
>>60
明らかにおかしいだろ?
そういうときは、だいたい自分が間違えてるんだよ

66 :デフォルトの名無しさん:03/06/07 11:54
>>61

まずオブジェクトありき、という純粋なオブジェクト指向の発想で、実装を考えます。

オブジェクト(インスタンス)がこの世(メモリ上)から消えたら、
そのオブジェクトをDB上に永続化した残骸も消すって
わからなくもないですよね。

オブジェクトがこの世に存在していないんだから、DB上にそのデータが
あるのはおかしいと、考えられなくはないと。

まその場合確かに普通のクラスと変わらないようにみえるけど、
DBだと排他制御とかトランザクション管理とかできるでしょ。

まず、DBありきの業務システムの発想だと、理解できないかも。




67 :デフォルトの名無しさん:03/06/07 12:03
>>66
その考え方はいくらなんでも違うだろ。

68 :デフォルトの名無しさん:03/06/07 12:07
>> 67

ま、たしかに。むりやりこじつけてみただけです。

評価でサーバの動作を確認するとき、DB上のテーブル設定とその削除を
ユーザがやらなくていいと考えるのが普通ですかね。

69 :デフォルトの名無しさん:03/06/07 12:17
>>66
その考え方はおかしい。永続化という意味を分かっていない。

問題はejbremove()がどうのではなくて、
「デプロイやAPサーバシャットダウンのときも
コンテナによって勝手にテーブルが削除されるのか?」という事でしょう。

結論は「そんなEJBの仕様はありません。」
そんな仕様だったら誰も使わないでしょう。

それは>>62の方が回答を書いていますが、
EJBコンテナ独自のDDに
「デプロイやAPサーバシャットダウンのときにテーブルを削除する」
に設定しているから。
「勝手に」削除しているわけではありませんよ。

70 :デフォルトの名無しさん:03/06/07 12:58
ま、どっちにしても「削除」は
開発段階に便利であるが
実運用では絶対にやらんな

71 :デフォルトの名無しさん:03/06/07 16:06
>>66
お前の世界はメモリだけなのか。
オブジェクトが生きる世界はそんなに狭くはない

72 :デフォルトの名無しさん:03/06/07 17:24
>>66

> オブジェクト(インスタンス)がこの世(メモリ上)から消えたら、

言いたいことはわかる。でも「(メモリ上)」は余計だね。

> オブジェクトがこの世に存在していないんだから、DB上にそのデータが
> あるのはおかしいと、考えられなくはないと。

EJBにおけるDBは、オブジェクトを永続化するための一手段だからね。

> まその場合確かに普通のクラスと変わらないようにみえるけど、
> DBだと排他制御とかトランザクション管理とかできるでしょ。

これらはオブジェクトレベルの話ではなく、それを永続化するのに
使っているDB上で起こる不都合を回避するためのものと捉えるべき
でしょう。
現実的ではないが、DB以外のものを永続化の手段として使うことも
理屈の上では可能。だからこういったことはコードではなくDDに書く。

> まず、DBありきの業務システムの発想だと、理解できないかも。

EJB以前に永続化、さらにはオブジェクト指向が理解できていない人には
無理な話よ。


73 :デフォルトの名無しさん:03/06/07 17:27
 ああもっとなじって 庶民たちよ
 君たちには本質が見えないのだろう
 私はちーさまの声に音に凌辱され姦淫された奴隷なのだ
 苦しい,でも幸せ
 絶望だから快楽
 それが鬼ちーワールド

74 :デフォルトの名無しさん:03/06/07 18:43
>>71

この世界は、JBOSSの寿命で決まっているのさ。

75 :デフォルトの名無しさん:03/06/07 23:26
JBossのソースコード理解できるか?
それとJboss4のアスペクト指向てなんだ?

76 :デフォルトの名無しさん:03/06/08 00:35
アスペクト指向 = オブジェクト指向でなしえなかった部品の再利用
だと、漏れは勝手に判断した。

77 :デフォルトの名無しさん:03/06/08 01:00
物事を concern で捉え、concern 単位のソースの断片をあちこちにばら撒く
・・・ように見える。

78 :デフォルトの名無しさん:03/06/08 01:51
>>75
要はユースケースで共通に現れる基盤部品を別のクラスにしようぜ!
って言うあたりまえのことをえらそうに名前を付けただけ。


79 :デフォルトの名無しさん:03/06/08 03:23
要するにトリガーてこと
トリガー==アスペクト

80 :デフォルトの名無しさん:03/06/08 07:23
>>79
>>トリガー==アスペクト
納得

81 :デフォルトの名無しさん:03/06/08 15:21
>>76-80
全然とはいわないが、まったく本質をとらえてないよ。

アスペクト指向自体は、Cross Cutting Concernという
プログラミングに関わる本質的問題を解決しようという試み。

ただ、アスペクト指向プログラミングを実現する代表的実装のaspectjがまだそれほど
枯れていない、満足できないものなので、

アスペクト指向 = トリガー、プリプロセッサ

みたいな見方しかされていないのが大方の現状。



82 :デフォルトの名無しさん:03/06/08 18:12
>全然とはいわないが、まったく本質をとらえてないよ。

・・・全然とまったくの違いがわかりまつぇん

83 : :03/06/08 18:13
過去ログからのコピーです。http://natto.2ch.net/mass/kako/974/974478132.html

489 名前: 文責:名無しさん 投稿日: 2001/04/11(水) 17:25
 一般人なのに盗聴される、じゃなくて、「一般人だから盗聴される」んじゃないのかな?
 基本的にネタ集めのためにやってんなら、有名人のネタを盗むと、有名人は告発できるし、
そんなことされても当たり前だと思われるので告発しても信じてもらえる。
 そうでない人は、ここの途中の書き込みにもあったように「電波」扱いされるだけ。

 ただで、ネタを仕入れるんなら、一般人に限るでしょう。
 マスコミは自分らの無能さを恥じてほしいです。

 ちなみに私が盗聴されはじめたのは、芸能人にストーカーされ始めてからでした。
 そこからマスコミに広がって行った。
 だから余計「妄想」とか思われそう。
 友人に話したら完全に病気扱いされた。ストーカーって言葉がない時代だったしね。
 書いておいておいた小説のネタが、他人の原作でドラマ化されたときにはきれまくっ
たなあ。(一度や二度のことじゃないけど)


84 :デフォルトの名無しさん:03/06/08 22:15
おまえらEJBはoracle9iAS
だこれできまりだな。
値段は安いしJdeveloperまでついてくる。
他はだめだな(w

85 :デフォルトの名無しさん:03/06/08 22:23
>>84
俺はJBoss + Eclipse + Lomboz で充分なのだが

86 :デフォルトの名無しさん:03/06/09 00:19
>>84
しかも、US OTN 版を使えば開発用途には只!!

87 :デフォルトの名無しさん:03/06/09 00:31
oracle9iASって何気に高機能なんだけどあまり使われないね。


88 :デフォルトの名無しさん:03/06/09 00:39
>>87
OC4Jの中途半端な実装がちょっとな。


89 :デフォルトの名無しさん:03/06/09 00:41
OC4J、EJB周りの独自路線突っ走りまくりがなんとかなったら
結構いけてると思うのだが。
軽いし。

90 :88:03/06/09 01:03
>>89
うん俺も基本的には気に入ってるよ。珍しくpure Javaなサーバだし、
軽いから開発するときは手軽で良いと思う。

91 :デフォルトの名無しさん:03/06/09 04:15
2,3年でBEAは合併吸収されるでしょう
BEA殺しのORA9ASとJBOSS。
時代は
ORAVSWASなのだ
ところでBEAの××SHOP(VBの連中がスピンアウトしてつくった)
つかいかたわからんのよ。だから1時間でけしました(w


92 :デフォルトの名無しさん:03/06/09 04:37
社員降臨?


93 :デフォルトの名無しさん:03/06/09 07:07
ORA9ASはうんこ

94 :デフォルトの名無しさん:03/06/09 09:46
昔はAPサーバと言えばOWASといういう時代もあったのだが。
いまだにXXカードリッジみたいな方式なのかな。
PL/SQLカートリッジなんておっそろしくて使えるかっての。

95 :_:03/06/09 09:47
http://yomi.kakiko.com/hiroyuki/jaz_b01.html

96 :デフォルトの名無しさん:03/06/10 09:34
EJBを勉強できるサイトありませんか?
初心者です。

97 :デフォルトの名無しさん:03/06/11 01:56
EntityBeanを使わなきゃいけない場面てありますか?

SessionBeanとO-R Mapperで十分だと思うんですが。

大体EJBのメリットってリモート呼び出し+トランザクション管理くらいしか
無さそうなので、SessionBeanでそれをやってしまえばおしまいじゃんと思うのですが。

さらにEntityBean使うと、
■めんどい
■メモリを食う
■性能が悪い(CMPだとそんなことないかな・・・)
といったようなデメリットしか思い浮かばないのですが・・・


98 :デフォルトの名無しさん:03/06/11 01:58
>>97
実際にどの程度のことが出来るのかはおいといて、理想は
「ストレージの形態を隠蔽する」ことじゃないかねえ。

最終的にはRDBじゃなくてもいいように「したい」んだと思われ。

99 :デフォルトの名無しさん:03/06/11 15:50
ここでいいかわからないのですが教えてください。
今までTomcatで勉強してたんですけどJ2EEでもjspが動くことがわかり
J2EEの/public_htmlへjspファイルを移動しました。
しかし、DBConnectionPool.classをどこへ移動すればよいかわかりません。
どこへ、移動したらよいのでしょうか?

100 :99:03/06/11 15:59
すみません。できました。
J2EEサーバーを再起動しないといけなかったんですね。

101 :デフォルトの名無しさん:03/06/11 16:00
>>99
何度も書かれているが、"J2EE"とは仕様・規格を指す。
あんたの言う"J2EE"とはJ2EE Reference Implementation (J2EE RI)のことだろうと推測して回答。

JSPファイルもclassファイルも配置はJ2EEの仕様に沿っていればOK。
その書き方だとおそらくJSPファイルをそこに置いて動いてしまっているは
いいが、どうしてそこに配置すると動いているのかわかっていなさそうだな。
設定・デプロイ方法はTomcatと同じだ。というかJ2EE RIはTomcatを含んでいる。
server.xmlにContextの設定はしたか?

102 :99:03/06/11 16:05
J2EEにTomcatが入っていたのかー
WebLogicとかになったらまた違うのかなー
面倒だなー

103 :デフォルトの名無しさん:03/06/11 20:34
ここで聞いちゃってもいいですかな。JBoss 3.0 使ってる人いますか?

Stateful SessionBean を使用する Web アプリケーションをつくりまして、
EJB とセットして EAR 形式でデプロイさせています。

例えば JSP やプロパティファイルを修正して EAR を作りなおしてデプロイす
ると正常にデプロイされますが、デプロイ前のセッションが初期化されてしま
うようで参照できません。

なんとか初期化されずに済むような方法はないですかね。


104 :デフォルトの名無しさん:03/06/11 20:48
>>103
初期化されないアプ鯖ってあるの?

105 :デフォルトの名無しさん:03/06/11 21:17
コンパイルしなおしてデプロイしたんだろ?
なんで前のが残ってるんだ(w

106 :デフォルトの名無しさん:03/06/11 21:29
>104-105
ホットデプロイって知ってる?君たち。

107 :デフォルトの名無しさん:03/06/11 22:50
>>97-98
っつーことは、
ストレージがRDB固定だったら、
EntityBeanは使う意味がないって事ですかねぇ
どなたかストレージがRDB固定の時にO-Rマッパー(JDO等)よりEntityBeanが優れている点を
説明できる方居ませんか?

108 :デフォルトの名無しさん:03/06/11 23:03
EntityBeanの方がノウハウが進んでるし、多分管理も楽(それでも十分難しいと思うが)
JDOだとCastorだろうか?XMLとの統合もいい。
ってOracleも同じか。

109 :デフォルトの名無しさん:03/06/11 23:05
>>106
EJBのインスタンスが存在している状態で
ホットデプロイするとどうなるの?

110 :デフォルトの名無しさん:03/06/11 23:14
次に生成されたインスタンスから
変更となる

111 :デフォルトの名無しさん:03/06/11 23:21
>>110
新旧入り混じるとシステム的に整合性が
取れないことは無いでつか?

112 :デフォルトの名無しさん:03/06/11 23:28
あるはずのクラスが無くなったりメソッドのシグニチャとか変わったらどうなるんだろう?


113 :デフォルトの名無しさん:03/06/11 23:29
>>107
EJBの方がトランザクション管理とかやりやすいでしょ?

114 :デフォルトの名無しさん:03/06/11 23:29
(ビジネスロジック面で)システム整合性が
とれないような場合はAP鯖止めてからデプロイし、
起動したほうがいいね。
あくまで、AP稼働中にクラスモジュールを
入れ替えることが可能ということで、
ビジネス上の整合については
自己(運用者)責任だよ。

115 :デフォルトの名無しさん:03/06/12 00:13
>>114
そゆことか。サンスコ!

116 :97:03/06/12 03:06
>>108
最近のフレームワークではEntityクラスを簡単に自動生成してくれるので、
ノウハウはいらないと思います。
むしろEntityBeanの余計な排他制御等の知識等のほうがめんどくさいのでは?

>>113
トランザクション管理はもちろんSessionBeanで行います。
ここで言っているのは

1.SessionBean+EntityBean
2.SessionBean+O-Rマッパーで作成したEntityクラス

で、1の方が勝っている点がおいらの知識ではわからないのです。
2の方が勝っている点については>>97に書きました。

EJBのメリットってリモート呼び出し+トランザクション管理+オブジェクトライフサイクル管理くらいだから、
そこらへんは全てSessionBeanでカバーできると思っているので、
EntityBeanの必要性は感じません。

個人的にはEntityBeanは廃れていくんじゃないかなぁと思っています。
どなたか反論(1.パターンの優れている点)をお待ちしています。


117 :デフォルトの名無しさん:03/06/12 03:19
俺もCORBAよりEJBの方が面倒が無い、という理由でEJB良いと思う。
が、EntityBeanは使わない。
Javaのおかげでにわかにオブジェクト指向が脚光を浴びてきて
OODBに移行していくと思ってたんだけど、全然アテが外れた。

118 :デフォルトの名無しさん:03/06/12 07:06
1.4のJ2EE Tutorialでも見てみ。EJBの扱いが突然小さくなってるぞ。

119 :デフォルトの名無しさん:03/06/12 13:09
>OODBに移行していくと思ってたんだけど、全然アテが外れた。
同じく(w


120 :デフォルトの名無しさん:03/06/12 20:36
>>1.4のJ2EE Tutorialでも見てみ
まだ出てないだろ。夏ぐらい?

121 :デフォルトの名無しさん:03/06/12 20:42
>>120
まだ完成版じゃないけど
http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html

122 :デフォルトの名無しさん:03/06/12 21:51
>118

Note: With the exception of timer beans,
Enterprise JavaBeans technology will be covered in the next release of the tutorial.

が読めないのかい?

もともとJ2EE1.3チュートリアルへの補完として今のJ2EE1.4チュートリアルがつくられているんだよ。
いずれJ2EE1.3チュートリアルから、EJBの部分はコピー&ペーストされるよ。




123 :デフォルトの名無しさん:03/06/12 23:41
>>118-119
データベースシステムの移行ってのは兎角スムーズにはいかんだろ。
OODBってまだ信頼性に問題あるのおおいし。保守できる奴殆どいないし。

Oracleだって今の信用?を得るまでは、おもちゃ扱いだったんでは?

124 :デフォルトの名無しさん:03/06/13 17:15
データベース中心に考えると
JDOとか標準になったら
EJBの特筆点は分散技術だけになってしまうのか?

それと、やったことないがメーッセージドリブンBeanってこの先伸びるの?

125 :デフォルトの名無しさん:03/06/13 17:17
でもさぁ、パフォーマンスとかデザインパターンとか
考えるのでやってて面白いけどな

126 :デフォルトの名無しさん:03/06/13 22:07
難しい話題になると敬遠するな
JavaやってるやつでEJBまで理解してるやつっていないのかな?
さすが、入門言語

127 :デフォルトの名無しさん:03/06/13 22:19
入門用じゃねーよ(;´д`)
エキスパート用だよ(;´д`)

128 :デフォルトの名無しさん:03/06/13 22:22
>>126
さすがにお前の頭も分散技術ってことだな

129 :デフォルトの名無しさん:03/06/13 23:14
>>124
Enterprise-MessageQueueのラッパですよ。
MQ自体は需要ありまくりですよ。

130 :デフォルトの名無しさん:03/06/13 23:26
確かにMDBは需要有りまくりでしょう。
楽にメッセージ受信側が実装できるし。

なんか話を聞いてるとSFSBとEntityBeanだけ取り残されてる気がします。


131 :デフォルトの名無しさん:03/06/15 11:52
CMP2.0で、コンポジットプライマリキーは使えるんでしょうか?
BMPでは成功したんですが、CMPではできません
いちおう、ejb-jarのDTD見たんですが
<primary-key>要素を使うな としか書いてありませんでした
一応そうやってるのですが・・・・
エラーの内容としては、SQLExceptionが出て
「”FROM”付近の入力が間違っている」みたいなSQLの文法が間違っているみたいです
プライマリキークラスは、intと、Stringの2つのフィールドがあって
きちんと、ハッシュコードもイコールもオーバーライドしています
ただ、SQL文のエラーっぽいので、うまく2つの値が分解されていないのかな?と思います
BMPではその辺は自分でコーディングできるんですが
CMPだと、すべて任せてしまうので中でどんな処理してるのか僕の入る余地がないのです
一番いいのはデバッグすればいいんですが、EJBコンテナのデバッグツールってあるのですか?
たとえば、EclipseのTomcatプラグインのようなものがあれば一番いいんですが・・・
DBの方のログファイルにも詳細まで書かれていません。
また僕はログに関してはあまり詳しくないので
こういうふうにすれば、中で何やってるかわかるよ」みたいなアドバイスくれれば幸いです

環境は、JBoss3.0.7+PostgreSQL7.2.2です



132 :デフォルトの名無しさん:03/06/15 14:29
>131
JBossって、デプロイされてできたクラスのソースコードを見ることはできないのかい?
WebSphereとかだと、デプロイメント後、自動生成されたクラスのソースも見ることができて、
実際のSQLのイメージがなんとなくわかるようになっているのだが。

133 :デフォルトの名無しさん:03/06/16 01:10
>>131
ソースコード落してきてデバッグ実行。オプソマンセー。

134 :デフォルトの名無しさん:03/06/16 23:07
Stateless SessionBeanにインスタンス変数持ってる例を見かけたんだけど、それってアリなの?
ユーザーごとに変わる値でなければ別に構わないのかな?(参照EJBのHomeとか)

135 :デフォルトの名無しさん:03/06/16 23:09
>>134
セッション基準に見たら無意味だが、ありなんでわ。
単純にSLSB自体のIDがほしいとか。何につかうかシランケド。

136 :デフォルトの名無しさん:03/06/16 23:20
>>131
プライマリーキークラスのフィールドは、publicという点も中尉。


137 :デフォルトの名無しさん:03/06/16 23:43
すいませんが質問させてください
エンティティBeanの
ejbCreateの戻り値についてなんですが
return null;となってる解説書と
return primarykey;となっている解説書があるんですが
いったいどっちが本当なんでしょうか?
どっちも正常に動くんですが
どうなってるんでしょうか・・・?

138 :デフォルトの名無しさん:03/06/17 00:26
>>137
CMP→Null
BMP→主キー
(J2EE TutorialのP119を参照)

139 :デフォルトの名無しさん:03/06/17 01:39
>>138
レスさんくす
ということは、CMPなのに主キーが返ってる解説書は
糞ということでいいですか?
本のタイトル書いたろかな

140 :デフォルトの名無しさん:03/06/17 23:32
>>139
CMP1.1はどうだか忘れたけど、
CMP2.0でそんなことやっている解説書は糞です。
本のタイトル載せてください。

141 :デフォルトの名無しさん:03/06/17 23:34
EJBのファインダーの戻り値は
java.util.Collectionとなってる例が多いんですが
ListとかVectorじゃダメなんですか?


142 :デフォルトの名無しさん:03/06/17 23:37
>>141
順序に意味が「ない」という意思表示なのでわ。

143 :デフォルトの名無しさん:03/06/17 23:43
>>142
ん〜でも、OrderByで取得したいときって
やっぱ、Collectionだとダメですよね?


144 :デフォルトの名無しさん:03/06/18 01:15
>>138-140
return null; でも return primarykey; でも、どっちでもOKなんですが...
ただ、return primarykey; としたとしても、そのprimarykeyは使われない
というだけで...。

145 :デフォルトの名無しさん:03/06/18 20:00
EJBやっていると
例外をthrowする場面が多くなると思うんですが
どの辺りまで引っ張ってくればいいんでしょうか?
いちおう、いまのところ
クライアントの手前に例外のフィルターみたいな役割のクラスを置いて
そこで、とりあえずすべてキャッチするようにして
あとは、例外でたことをクライアントにしらせる
って言うやり方してるんですが
こういうやり方でよいのかどうか判断つきません

とくに、どこまで引っ張ってくれば(throw)よいのか?
っていうのがわかりません
クライアントに知らせることが出来るなら
なにもthrowしなくてもフラグやメッセージさえ
わたせばいいのかな?とも思いますし・・・
この辺に関しての標準的な考え(パターンとか)ってありますか?

146 :デフォルトの名無しさん:03/06/18 20:00
上げ忘れましたすいません

147 :デフォルトの名無しさん:03/06/18 21:58
> なにもthrowしなくてもフラグやメッセージさえ
> わたせばいいのかな?とも思いますし・・・
フラグやメッセージの取り決めしなきゃならんだろ。
プロジェクトによってバラバラだったりで毎回決めなきゃならん。
ひどいときはシステムのあちこちで統一性のないフラグやメッセージの
使い方がまかり通ることもある。

そんなことしなくてもいいのが例外処理の利点じゃないか。

148 :デフォルトの名無しさん:03/06/18 22:59
>>145
サーバ側で処理する必要がないなら、RemoteExceptionのサブクラス作って
そいつにラップしてクライアントに丸投げ、サーバの処理は全部ロールバック、
あとはクライアント側でどうにでも、が一番楽なんじゃないかねえ。

149 :デフォルトの名無しさん:03/06/19 11:42
>>145
「どこまで引っ張ってくれば(throw)よいのか?」と書いてるところを見ると、
システムを層に分けてるだろうから、自分の層で処理できるものだけcatchして
メッセージなり戻り値なりに置き換えればいいんじゃないの?
最終的には(どの層も処理できない例外は)、フィルター的なもので処理することに
なるだろうけど(Strutsにもそういう仕組みがあるし)。


150 :145:03/06/19 18:57
レスサンクスALL

俺がやってるのはクライアントがサーブレットなんだが
とりあえず、アプリケーション例外は呼び出し元で処理して、
そこで、なんらかの復旧作業

システム例外はそのままWebのコンテナにServletExceptionとして
throwすることにしました

151 :デフォルトの名無しさん:03/06/20 23:59
すいません教えてください
EJBの数が多いので
ejb-jar.xmlファイルなどのDDファイルがすごく長くなります
とくに、CMPだとフィールドとかも書かなければならないので・・・
なので、それぞれ別々のJARファイルにまとめて
それらをWEBコンポーネントと一緒にEARとかにまとめても
大丈夫でしょうか?

152 :デフォルトの名無しさん:03/06/21 01:03
EJBとEJBクライアントで発生する例外を次のように分類する。
 (1)EJBのシステム例外
 (2)EJBのアプリケーション例外
 (3)Webアプリのシステム例外
 (4)Webアプリのアプリケーション例外
システムが直面するエラー状況を次のように分類する。
 (A)入力値エラー
 (B)アプリケーションエラー
 (C)システムエラー

(1)-(4)を(A)-(C)のどれに対応させるかについて、ちゃんと設計しておいたほうがいいよ。
(A)は例外発生ではなく、カスタムのエラーオブジェクトをハンドリングするような設計になるかもしれない。
(StrutsはActionErrorというカスタムのエラー型を定義している)



153 :デフォルトの名無しさん:03/06/21 03:44
>151
ejb-jarの分割方針はそんな管理上の面倒くささで決めるのではなくて、
あくまでもアプリケーションの意味上で決めるべきだろ。

そもそもCMRとか使用すると同一ejb-jarじゃなきゃいけないってこともあるぞ。

154 :デフォルトの名無しさん:03/06/21 05:32
EJBって何がエンタープライズなのかと思ったら、
EJBの仕組みその物がエンタープライズなんですね!

155 :デフォルトの名無しさん:03/06/22 02:06
>>151
まさか、いまどきDDを手で書いてるの??


156 :デフォルトの名無しさん:03/06/22 02:43
>>155
じゃあどうやって書くんだ?ん?

157 :デフォルトの名無しさん:03/06/22 02:48
>>156
アプリサーバに付属のデプロイツールとか使わないの?
もちろん、初めて学習するときには仕組みや設定内容を理解するために
テキストエディタ等使って手で書くことも必要かもしれないが、
一度やってみれば手書きは限界に近いものだと誰でも悟ると思うよ。
EJB使うってだけで大半は大規模アプリ。
大規模アプリのDDを全部手書きでメンテするのは大変でしょ。

158 :151:03/06/22 03:15
いや、いちおうXDoclet使ってますけど
DDがこんなに長くていいのかなぁ〜と思ったわけです
みんなどうしているのかなぁと・・・
一枚でいいのなら(それが標準なら)それでいいんですけど

159 :デフォルトの名無しさん:03/06/22 14:57
>>158
JBuilder Ent版 の EJBデザイナを使えば、全部自動で作成してくれる。
もちろん主要なサーバーに対応してるし。

160 :デフォルトの名無しさん:03/06/22 15:41
>>159
多毛絵よ!

161 :デフォルトの名無しさん:03/06/22 17:04
>158
DDが長くなるのはしょうがない。みんなそうだ。気にするな。


162 :デフォルトの名無しさん:03/06/22 19:56
159>>さんに質問!
全自動で作ってもコンパイルはantでするんですか?
IDEはいまいち信頼性がなくJBも情報が少なすぎ。
(特に他のAPS使う場合)

163 :デフォルトの名無しさん:03/06/23 11:05
>>162
>全自動で作ってもコンパイルはantでするんですか?
いいえ。

164 :デフォルトの名無しさん:03/06/23 15:57
すいません教えてください
EJBのQLに渡すパラメータって
intやlongなどのプリミティブ型はダメなんでしょうか?
java.lang.Integerやjava.lang.Longに変換して渡さないといけないんでしょうか?

165 :デフォルトの名無しさん:03/06/23 19:27
>164
Spec読め。

166 :デフォルトの名無しさん:03/06/23 20:36
>>164のPCのスペックがこの辺に。

167 :デフォルトの名無しさん:03/06/23 21:05
>>多毛絵よ!
キージェネがあるだろ

168 :デフォルトの名無しさん:03/06/23 21:51
IDEは使い物なりのか?

169 :デフォルトの名無しさん:03/06/25 04:25
ejbCreateの引数ってなんでオブジェクトなんですか?
int や booleanはそのまま使えないんでしょうか?
いちいち、取り出してキャストするのがめんどくさいんですけど
理由がわかりません

170 :_:03/06/25 04:39
http://homepage.mac.com/hiroyuki44/

171 :デフォルトの名無しさん:03/06/25 04:48
>169
intで返すならjava.lang.Integerでいいじゃん。
そんなに変わらんでしょ。


172 :デフォルトの名無しさん:03/06/25 04:57
>>159
XDocletもおすすめやで〜日本語マニュアル少ないけど

173 :デフォルトの名無しさん:03/06/25 10:39
>>171
は?言ってる意味がわからん
キャスト発生するじゃん?


174 :デフォルトの名無しさん:03/06/25 21:18
>>169
ちったぁ頭使えよ。

175 :デフォルトの名無しさん:03/06/25 21:59
>>169
オブジェクト指向って知ってる?
こういう奴にはsmalltalkの刑だ。

176 :デフォルトの名無しさん:03/06/26 06:46
DTO(VO)とかを使わないで、ただ単に
文字の配列をDTOとして使うのは
あまり良くないことですか?

返り値のデータ量が非常にコンパクト
(データベースから条件に相当する2〜3文字を引っ張ってくる)なので
わざわざ、DTOのインスタンス作るの馬鹿らしいんですけど


177 :デフォルトの名無しさん:03/06/26 06:50
>>176
当然そうするべきです

178 :デフォルトの名無しさん:03/06/26 08:36
>>177
すいません

「当然そうするべきです」
っていうのはどっちなんでしょうか?
どっちとも取れる答えなので・・・すいません

179 :山崎 渉:03/07/15 10:30

 __∧_∧_
 |(  ^^ )| <寝るぽ(^^)
 |\⌒⌒⌒\
 \ |⌒⌒⌒~|         山崎渉
   ~ ̄ ̄ ̄ ̄

180 :山崎 渉:03/07/15 14:13

 __∧_∧_
 |(  ^^ )| <寝るぽ(^^)
 |\⌒⌒⌒\
 \ |⌒⌒⌒~|         山崎渉
   ~ ̄ ̄ ̄ ̄

181 :デフォルトの名無しさん:03/07/15 16:33
MessageDrivenBean って使ってる人いる?どんな感じで使うのかなー


182 :デフォルトの名無しさん:03/07/15 16:50
>>181
MessageDrivenBean のほうが使い勝手あるらしいが
おれもどういうときに使うのかよーわからん
でも、覚えるのは簡単だよ

183 :デフォルトの名無しさん:03/07/15 16:55
っていうかよースレの順番逆転してないか?
「age」進行の山崎 渉 にやられたのか

びっくりしたよ、起きたら別の板かと思ったよ
で慌てて玄関の表札確認したよ

184 :デフォルトの名無しさん:03/07/15 22:11
>182
使い勝手があるというより、
J2EEでは他に大体手段がないのだから、
(ユーザーアプリの中で、別スレッドでキューを監視しつづけるなんてことはできないから)
使わざるを得ない。

185 :デフォルトの名無しさん:03/07/17 19:11
CMPのEntityBeanをつかってカッチリO-RマッピングしてRelationまでつかってるような開発って実際どのくらいあるのかな。だれか実際開発してる人いますか?


186 :デフォルトの名無しさん:03/07/18 00:36
>>185
私が関ったシステムでは、CMPオンリーで、Relationもバリバリ使ってますよ。

187 :デフォルトの名無しさん:03/07/18 13:21
earやwarの圧縮の話で盛り上がっていたことで気になること。
全部ひとつのearにまとめてしまえば楽じゃね?

188 :デフォルトの名無しさん:03/07/18 13:43
>>187
ヴァカかおまえは。
圧縮の話しなんか誰もしてないが。字が読めないならプログラミングなんて無理じゃないのか?

189 :デフォルトの名無しさん:03/07/19 04:57
>>182
MDBはトランザクションを即効で終わらせたいときに便利。
DB負荷も少なくてすむ。

190 :デフォルトの名無しさん:03/07/21 23:55
>>186
どのくらいの規模ですか?
何エンティティくらいあるのですか?


191 :デフォルトの名無しさん:03/07/21 23:57
>>187
バグ等で入れ替えることまで考えると1つのEarファイルなんか無茶だと思うが・・・
一人で開発しているならともかく。

192 :デフォルトの名無しさん:03/07/22 00:18
> バグ等で入れ替えることまで考えると1つのEarファイルなんか無茶だと思うが・・・

だから、EARはアプリケーションの論理的な単位でまとめろって。
運用上の都合で分けるのは、素人仕事だぞ。


193 :デフォルトの名無しさん:03/07/22 00:22
EJBは再利用コンポーネントだ。
.ear ファイルにまとめちまうということは、
その中の一部を入れ替えるだけでもサービスの停止が必要になるということだ。

たとえば従業員を示す EmployeeEntityBean を Employee.jar としてまとめる。
EmployeeEntityBeanを利用して給与計算する SalarySessionBean を Salary.jarとしてまとめる。
Salary.jarのクライアントとなる給与表作成アプリを salary-view.war としてまとめる。

EntityBeanも、SessionBeanも、Webアプリも、すべて何らかの修正が発生する可能性がある。
.ear ファイルでまとめられていると、無駄なサービス停止が生まれてしまうのだ。

小さなアプリだけ作ってる分には分からないだろうが、
大規模になればなるほど、
24h*365dに近いサービスが求められるほど、
ミッションクリティカルになるほど、
重要な設計要素となる。



194 :デフォルトの名無しさん:03/07/22 04:50
>>193
earにまとめとかないと、参照渡しによる高速化ができなくねぇ?


195 :デフォルトの名無しさん:03/07/22 18:56
>193

それこそ、運用上の都合だ。そいうことは運用、またはトポロジー(クラスタリング)でカバーしろ。
運用上の都合をアプリケーションに持ち込むのは素人仕事。

196 :デフォルトの名無しさん:03/07/23 00:59
運用無視してつくられたアプリケーションの面倒なんか見てられねーよ。
それこそ素人仕事もいいところだ。
ただ動くアプリケーションなんか誰でも作れるんだよ。
動かしつづけられるアプリケーションつくってくれよ。

197 :デフォルトの名無しさん:03/07/23 08:30
>>195みたいなやつは、
「データ不整合が起きたらリカバリに1週間かかります」
みたいなシステムを作るんだろうな。


198 :デフォルトの名無しさん:03/07/23 10:55
てか、サービスまったく止めないで運用しているのが存在するのか?

199 :デフォルトの名無しさん:03/07/24 01:26
>>193のネタって重要だよね。J2EEアプリが、オブジェクトがどこにある
どのバージョンのクラスファイルに基づいて作成されるのかを把握しづら
いのは、どうにかナランかねえ。

200 :デフォルトの名無しさん:03/07/24 18:09
>>193

これってやっぱしクラスタリングで対応するのではないですかね。

2台のマシンをクラスタリングして、1台目のマシンに ear をデプロイして、
完了したら2台目のマシンにデプロイさせてやるってふうにすれば、
サービスとして停止はないのじゃないですかね。もちろん変更内容にも
よるでしょうけど。


201 :_:03/07/24 18:14
http://homepage.mac.com/hiroyuki44/hankaku04.html

202 :デフォルトの名無しさん:03/07/24 20:00
>193
>.ear ファイルでまとめられていると、無駄なサービス停止が生まれてしまうのだ。

違うでしょ。
全てをひとつのearにまとめるからそうなるのでしょ。

アプリケーションを独立させたいのなら、
earをわけろよ。

そうすれば、ひとつのearに含まれるejb-jarを更新したところで、
もうひとつのearには何の影響もない。


203 :デフォルトの名無しさん:03/07/24 22:06
>>193は、だからearのまとめ方を考えろといってるんじゃないの。
ひとつにまとめるんじゃねえよモルァって

204 :デフォルトの名無しさん:03/07/24 22:18
どこでまとめようがそんなの知らんよボケェ
まとめたっていいじゃんいいじゃん
っていうかよ、Classファイル入れ替えの機能ってついてないのか?
高級なお値段のAP鯖には?

205 :デフォルトの名無しさん:03/07/24 22:21
>>204
適当にClass入れ替えたら何が起きるか想像してみろよ。

206 :デフォルトの名無しさん:03/07/24 22:29
>>200
普段はクラスタで動いてて、デプロイ時にはクラスタの
メンバーからはずしてってことを言ってるんだよな?

それって単純だと思う?
漏れにはとても単純には思えないんだが。
片側止めてる最中にトラぶったらどうする?

ちょっともとめられないような場合は切替までちゃんと設計するし、
そのときには代理のパスを準備するもんだ。


>>193がいってるのはサンプルとして不適切だと思うんだが。
クリティカルな部分でアプリが替わったんならさすがにとめなきゃだめだろ。

安全にバックアップするために毎日とめてくださいってのは開発側のエゴかもしれんが
明日から途中流れるデータが変わるのでしばらくとめてくださいってのは当たり前。

207 :デフォルトの名無しさん:03/07/24 22:33

一緒になってるかバラバラになってるか関係ないじゃんバカァ
どうせ止めなきゃ何もできないんだ
どうせ止めなきゃ何もできないんだ
どうせ止めなきゃ何もできないんだ
どうせ止めなきゃ何もできないんだ
どうせ止めなきゃ何もできないんだ
どうせ止めなきゃ何もできないんだ

208 :デフォルトの名無しさん:03/07/25 00:10
独立して運用できる単位でearにまとめるのが普通じゃないの。
大きいシステムなら、普通サブシステムに分割されているだろ。
1つのサブシステムをさらに細かくearに分けることは、
あんまり意味がないと思う。
ところで、J2EEのアーキテクチャだと、earっていうのは
いくつかの再利用可能なEJBコンポーネントやWebコンポーネントを
アセンブルした後のアプリケーションのことであって、
再利用の単位じゃないと思うんだけど、違ったっけ。




209 :デフォルトの名無しさん:03/07/25 00:45
>208
> ところで、J2EEのアーキテクチャだと、earっていうのは
> いくつかの再利用可能なEJBコンポーネントやWebコンポーネントを
> アセンブルした後のアプリケーションのことであって、
> 再利用の単位じゃないと思うんだけど、違ったっけ。

そのとおり。
EARはあくまでそれ自体で完結しているアプリケーションの単位。
必要なライブラリは全てEAR内に含めるのが基本。

210 :デフォルトの名無しさん:03/07/25 02:16
ここで話題を提供
日経コンピュータでそろそろJavaで大規模なシステムを作る
計画が急速に進んでいるがどう思う?
成功すると思う?
俺は成功すると思うが。代わりがないからね(w





211 :デフォルトの名無しさん:03/07/25 02:18
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
   ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
  |||||||||||||||||||||||||||~~~~~~~~~||||||||||||||||||||||||||||||||
  ||||||||||||||||||||||||||||      ||||||||||||||||||||||||||||||||
 ||||||||||||||||||||||||||| |      || |||||||||||||||||||||||||||||
 |||| ||| ||||||||||| | | ||      | | ||||| ||||||| ||||||||| |||
 |||| | || ||| ||| |||| | |      ||| || | || |||| |||| || ||||
 |||| | || | |||| | | | ||       || | || | | || || || |||
 ||| || |||_|_|_|_|J  ,ハ、 ι|_|_|_|_|| | |||
 (^|  |  。   |ヽ     /|   。  |  |^)
 (e|  L____』 |    | L____』  |3)
 ( ||   ̄ ̄ ̄   |   |    ̄ ̄ ̄   ||,)
 |||          |  |          |||
  |||          |  |          |||  / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  \|、   __ _< | | >_ __   ,|/  < ローン!!メンピンイーペードライッチョー!!      
    -| l  ↑ ̄   ヽ__/   ̄↑  //     \_________
     | l   \┼┼┼┼┼/  //
     ヽl     ̄ ̄ ̄ ̄ ̄   //
      \   ‘ ̄ ̄ ̄ ̄'   /
       \           /
        \         /
          \____/








212 :デフォルトの名無しさん:03/07/25 02:19
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
   ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
  |||||||||||||||||||||||||||~~~~~~~~~||||||||||||||||||||||||||||||||
  ||||||||||||||||||||||||||||      ||||||||||||||||||||||||||||||||
 ||||||||||||||||||||||||||| |      || |||||||||||||||||||||||||||||
 |||| ||| ||||||||||| | | ||      | | ||||| ||||||| ||||||||| |||
 |||| | || ||| ||| |||| | |      ||| || | || |||| |||| || ||||
 |||| | || | |||| | | | ||       || | || | | || || || |||
 ||| || |||_|_|_|_|J  ,ハ、 ι|_|_|_|_|| | |||
 (^|  |  。   |ヽ     /|   。  |  |^)
 (e|  L____』 |    | L____』  |3)
 ( ||   ̄ ̄ ̄   |   |    ̄ ̄ ̄   ||,)
 |||          |  |          |||
  |||          |  |          |||  / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  \|、   __ _< | | >_ __   ,|/  < ローン!!メンピンイーペードライッチョー!!      
    -| l  ↑ ̄   ヽ__/   ̄↑  //     \_________
     | l   \┼┼┼┼┼/  //
     ヽl     ̄ ̄ ̄ ̄ ̄   //
      \   ‘ ̄ ̄ ̄ ̄'   /
       \           /
        \         /
          \____/








213 :デフォルトの名無しさん:03/07/25 02:20
>
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
   ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
  |||||||||||||||||||||||||||~~~~~~~~~||||||||||||||||||||||||||||||||
  ||||||||||||||||||||||||||||      ||||||||||||||||||||||||||||||||
 ||||||||||||||||||||||||||| |      || |||||||||||||||||||||||||||||
 |||| ||| ||||||||||| | | ||      | | ||||| ||||||| ||||||||| |||
 |||| | || ||| ||| |||| | |      ||| || | || |||| |||| || ||||
 |||| | || | |||| | | | ||       || | || | | || || || |||
 ||| || |||_|_|_|_|J  ,ハ、 ι|_|_|_|_|| | |||
 (^|  |  。   |ヽ     /|   。  |  |^)
 (e|  L____』 |    | L____』  |3)
 ( ||   ̄ ̄ ̄   |   |    ̄ ̄ ̄   ||,)
 |||          |  |          |||
  |||          |  |          |||  / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  \|、   __ _< | | >_ __   ,|/  < ローン!!メンピンイーペードライッチョー!!      
    -| l  ↑ ̄   ヽ__/   ̄↑  //     \_________
     | l   \┼┼┼┼┼/  //
     ヽl     ̄ ̄ ̄ ̄ ̄   //
      \   ‘ ̄ ̄ ̄ ̄'   /
       \           /
        \         /
          \____/








214 :デフォルトの名無しさん:03/07/25 02:21
>
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
   ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
  |||||||||||||||||||||||||||~~~~~~~~~||||||||||||||||||||||||||||||||
  ||||||||||||||||||||||||||||      ||||||||||||||||||||||||||||||||
 ||||||||||||||||||||||||||| |      || |||||||||||||||||||||||||||||
 |||| ||| ||||||||||| | | ||      | | ||||| ||||||| ||||||||| |||
 |||| | || ||| ||| |||| | |      ||| || | || |||| |||| || ||||
 |||| | || | |||| | | | ||       || | || | | || || || |||
 ||| || |||_|_|_|_|J  ,ハ、 ι|_|_|_|_|| | |||
 (^|  |  。   |ヽ     /|   。  |  |^)
 (e|  L____』 |    | L____』  |3)
 ( ||   ̄ ̄ ̄   |   |    ̄ ̄ ̄   ||,)
 |||          |  |          |||
  |||          |  |          |||  / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  \|、   __ _< | | >_ __   ,|/  < ローン!!メンピンイーペードライッチョー!!      
    -| l  ↑ ̄   ヽ__/   ̄↑  //     \_________
     | l   \┼┼┼┼┼/  //
     ヽl     ̄ ̄ ̄ ̄ ̄   //
      \   ‘ ̄ ̄ ̄ ̄'   /
       \           /
        \         /
          \____/








215 :デフォルトの名無しさん:03/07/25 02:21

   ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
  |||||||||||||||||||||||||||~~~~~~~~~||||||||||||||||||||||||||||||||
  ||||||||||||||||||||||||||||      ||||||||||||||||||||||||||||||||
 ||||||||||||||||||||||||||| |      || |||||||||||||||||||||||||||||
 |||| ||| ||||||||||| | | ||      | | ||||| ||||||| ||||||||| |||
 |||| | || ||| ||| |||| | |      ||| || | || |||| |||| || ||||
 |||| | || | |||| | | | ||       || | || | | || || || |||
 ||| || |||_|_|_|_|J  ,ハ、 ι|_|_|_|_|| | |||
 (^|  |  。   |ヽ     /|   。  |  |^)
 (e|  L____』 |    | L____』  |3)
 ( ||   ̄ ̄ ̄   |   |    ̄ ̄ ̄   ||,)
 |||          |  |          |||
  |||          |  |          |||  / ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
  \|、   __ _< | | >_ __   ,|/  < ローン!!メンピンイーペードライッチョー!!      
    -| l  ↑ ̄   ヽ__/   ̄↑  //     \_________
     | l   \┼┼┼┼┼/  //
     ヽl     ̄ ̄ ̄ ̄ ̄   //
      \   ‘ ̄ ̄ ̄ ̄'   /
       \           /
        \         /
          \____/








216 :デフォルトの名無しさん:03/07/25 02:30
Linux が OSの仮想化を促し、
Java がアプリケーションの実行環境を仮想化する。
XML がデータの抽象化を推進する。
ネットワークやストレージも仮想化されてる。
これらすべてがオープンな標準として実績を築いている。
駒は揃ってきたよね。

これで「複数企業や業界にまたがる共同インフラの構築」なんて案件がいくつもあれば完璧だろう。
実際に構築しているところも知ってるし。


217 :デフォルトの名無しさん:03/07/25 08:58
>>216
何が完璧なんだ?
何のためのコマがそろったんだ?

218 :デフォルトの名無しさん:03/07/25 16:07
>>Linux が OSの仮想化を促し、
意味ふめい 

219 :デフォルトの名無しさん:03/07/25 16:21

池田大作大先生はかって

「国立戒壇の建立こそ、悠遠六百七十有余年来の日蓮正宗の宿願であり、また創価学会の唯一の大目的なのであります」

といってますが、今はどうなんですか?

ttp://society.2ch.net/test/read.cgi/koumei/1057065225/


220 :デフォルトの名無しさん:03/07/25 20:31
http://www-6.ibm.com/jp/servers/eserver/zseries/server/z990/index.html
とかのことか?

221 :デフォルトの名無しさん:03/07/25 21:47
>>220
それはLinuxがOSの仮想化を促しているのではなく、
メインフレームH/WとVMがLinuxの仮想化を促しているのだ。

>>216は夢見すぎ

222 :山崎 渉:03/08/02 02:19
(^^)

223 :山崎 渉:03/08/15 16:31
    (⌒V⌒)
   │ ^ ^ │<これからも僕を応援して下さいね(^^)。
  ⊂|    |つ
   (_)(_)                      山崎パン

65 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)