トップページ⇒tech
223コメント84KB

EJB(初心者歓迎） ２

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさんNGNG
1000を超えたので、新たにスレたてました。

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

前スレ
http://pc2.2ch.net/test/read.cgi/tech/1017240849/
0002デフォルトの名無しさんNGNG
2GET
0003デフォルトの名無しさんNGNG
また初心者歓迎かよ(;´Д`)

0004デフォルトの名無しさんNGNG
前スレで 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 ファイルだ。





0005デフォルトの名無しさんNGNG
開発時の話について。

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

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

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

0006デフォルトの名無しさんNGNG
>>4-5
ありがとう！ようやく分かりました！
感謝いたします。
0007デフォルトの名無しさんNGNG
>>4-5
最初から素直に回答していれば荒れずに済むんだ。
0008デフォルトの名無しさんNGNG
実際に開発された方に質問です。
実際のプロジェクトでは、
いろいろなクラスから使用される、ビジネスロジックをまとめた共通（Utility）クラスが抽出されると思われますが、

I.どのように共通クラスを提供しましたか？
　　１．SessionBean
　　２．通常のクラス（JavaBeans)＋ＩＦ
　　３．その他？

Ⅱ．通常のクラスで作成した場合、パッケージングはどうされましたか？
　　１．Utilクラスを利用している全てのWar、ejb-jarに詰め込む。
　　２．ＡＰサーバのCLASSPATHに追加し、War、ejb-jarには含まない。
　　３．その他？
0009デフォルトの名無しさんNGNG
今回は、良スレの 予 感 ！！
0010直リンNGNG
http://homepage.mac.com/yuuka20/
0011デフォルトの名無しさんNGNG
"ejb-client"という名称に惑わされがちだが、平たい話がcorbaでいうスタブの類。
0012デフォルトの名無しさんNGNG
J2EEと同等の仕組みをCで実装してみました。すっごい速いです。
0013デフォルトの名無しさんNGNG
>8
>３．その他？

別のjarにまとめ、EARに一緒にいれる。
warやejb-jarから見えるように、MANIFEST.MFのClasspath:にそのjarへのパス(EAR内の相対パス）
を書いておく。
これが一番自然、かつ無駄がない。
0014デフォルトの名無しさんNGNG
>>13

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

こちらでは、MANIFEST.MFに書くのは外部から提供されているjarファイル
に対して使うことが多いです。
0015デフォルトの名無しさんNGNG
実際にアーキテクトとしてプロジェクト開発した方に質問です。

１．EntityBeanを使用する際にＢＭＰ、ＣＭＰ選択基準とはなんでしょうか？
　　使い分ける基準って言うのはあるのでしょうか？

２．CMPは基本的に１テーブル＝１エンティティBeanにしかできないのでしょうか？
0016デフォルトの名無しさんNGNG
>>15
1. 参照系は基本的にBMP。テーブル結合があるので。

2. そのはず。
0017デフォルトの名無しさんNGNG
>>16
対ViewでCMPしたり、CMR使ったりするよりBMPでごりごりのほうがいいのですか？
0018デフォルトの名無しさんNGNG
>>17
よかないよ。仕方なくという感じ。
EJB2.0に完全準拠してる製品使ってないから。
理想通りの使い方するにはもう少し時間がかかると思う。
0019デフォルトの名無しさんNGNG
おれはむしろＢＭＰとセッションＢＥＡｎの
切り分けかたを聞きたい。ＣＭＰはコード書かないだけ
メリットあるかもしれんがＢＭＰでＳＱＬ書くなら
あまりセッションＢＥＡＮにＳＱＬ書くのと代わらないような気がする
それとベンダーによるＥＪＢの設定の違い。
なんとかする気はないのか
write onece run anwherが泣いているぞ
0020デフォルトの名無しさんNGNG
＞ベンダーによるＥＪＢの設定の違い。
＞なんとかする気はないのか
この秋に出るJ2EE1.4ではデプロイヤAPIが共通化されるそうだが、
実際どんなもんだろうね。ちょっと期待。
0021デフォルトの名無しさんNGNG
ついでにだめだめのＩＤＥを何とかしろ。
何回１日にフリーズするんだ。
（誤）write once run anywhere
0022デフォルトの名無しさんNGNG
>>15-17
参照系ではEntityBeanを使う必要はないでしょう。
SessionBean＋DAO（DACB)で実装した方が、性能、メモリ効率を考えると全然いいと思う。

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

２．そうでしょう。
　　だからあまり粒度の小さいテーブル使ってしまうと、
　　多重EntityBean問題が発生して辛いかも。
　　そう思うと、ここでBMPを使うべきなんかなぁ
0023デフォルトの名無しさんNGNG
>>19
永続化コード（SQL文）とビジネスロジックの切り分けでしょう。

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

BMPで実装すると、ビジネスロジックと永続化コードが分離され、
永続化コードはBMP＋DAOで隠蔽＋局所化されるので、
メンテナンス性は向上するんじゃない。
Entity更新したければ、BMPを更新するだけなので。
0024デフォルトの名無しさんNGNG
だーかーら、CMP2.0が出たのと実際の現場で使うのとでは大きなタイムラグがあるんだってば。
0025デフォルトの名無しさんNGNG
>>24
確かにCMP1.Xの時代にはBMPを使うしか選択肢がなかったと思う。
ただ現状はもうAPサーバがCMP2.0を実装してきているので、
もはやBMPは捨ててもいいのでは？
めんどくさいし。
0026デフォルトの名無しさんNGNG
>>25
今からはじめるならEJB2.0が良いのだろうね、きっと。
でも、俺の場合今やってるEJB1.1のプロジェクト1～2年続く予定なので、
2.0に実務で触れることができるのは相当先なんだよな。
J2EE変化早すぎて、ついていけねえよ。と思っているのは
俺だけじゃないはずだ。
0027デフォルトの名無しさんNGNG
＞ J2EE変化早すぎて、ついていけねえよ。と思っているのは
＞ 俺だけじゃないはずだ。
特にEJB使うようなプロジェクトは期間も長いからね。
0028デフォルトの名無しさんNGNG
つまらん質問だが
セッションビーズでclass.forname(・・・
と使ってはいけないのか？
0029デフォルトの名無しさんNGNG
>>28
そんなアーティストはいない
0030デフォルトの名無しさんNGNG
なぜじゃ・・・
なんでじゃ
どうしてじゃ
0031デフォルトの名無しさんNGNG
個人的にはJ2EE2.1対応のアプリケーションサーバが出揃うまでCMPは待ちかなという感じなのですが。
皆さんはいかがですか。
そんなに永続化フレームワークに困窮してますか。
0032デフォルトの名無しさんNGNG
何年後の話でつか？
>J2EE2.1
0033デフォルトの名無しさんNGNG
Strutsでいいじゃん。
0034デフォルトの名無しさんNGNG
>>33
EJBの代わりになるのか？
Strutsってなんだか知ってる？
0035デフォルトの名無しさんNGNG
RMI＋JDOはだめかなぁ？
0036デフォルトの名無しさんNGNG
あ、トランザクションが無理か・・・
0037デフォルトの名無しさんNGNG
じゃ CORBA+JDOってことで
0038デフォルトの名無しさんNGNG
JTAサーバってないかねえ
0039デフォルトの名無しさんNGNG
結局ＥＪＢは不可分散び部分はロードバランサでカバーできるから
分散トランザクションぐらいしかメリットはみえないが
再利用はうまくいっているようにはみえないが（ｗ
0040デフォルトの名無しさんNGNG
EJBって、RMIのラッパーとして便利、という程度じゃ導入理由にならんのかな？
0041デフォルトの名無しさんNGNG
メリットは分散トランザクションだけか（ｗ
0042曲尾NGNG
うんこ
0043デフォルトの名無しさんNGNG
EJBQL書かなあかんのやったら
BMPでいいじゃん
EJBQL覚えるんだったら
SQLに精通したほうがまだマシ
余計にややこしくして何考えてんだよ
それから、EJBに限らんがDDに頼りすぎだよ
DDの設定がこうも多いと
DD書いてんのかプログラム書いてんのかわかんねーよ
わけわからんよこの仕様

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

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



0044デフォルトの名無しさんNGNG
これがEJBのすべてだ
http://cgi.members.interq.or.jp/hokkaido/asato/upload/jam3ddr/OB000694.jpg
0045デフォルトの名無しさんNGNG
すいません教えてください
CMPをやってみたんですが
なぜ、EJBコンテナをシャットダウンすると
データベースのデータも消そうとするのでしょうか？
せっかく入れたデータが台無しですよ
っていうかejbRemoveをコンテナが呼んだときは
そういう仕様になってるんですか？
なんでそうなってるのか教えてください
まったく理解できない
データベースのデータが消えたら何にもなんないと思うんですが・・・
0046デフォルトの名無しさんNGNG
> っていうかejbRemoveをコンテナが呼んだときは
> そういう仕様になってるんですか？

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

bean.remove()でデータが消えるのは当たり前のことだと思うのだが。
0047デフォルトの名無しさんNGNG
>>45
> データベースのデータが消えたら何にもなんないと思うんですが・・・

まぁそりゃそうだ。
ところで「永続化」って言葉、聞いたことない？
0048無料動画直リンNGNG
http://homepage.mac.com/norika27/
0049デフォルトの名無しさんNGNG
初心者です。
同じオブジェクトが各サーバにありアプリケーションサーバがそれを
不可分散に応じて選択。ただしロードバランスと違うのは
分散トランザクション機能がある。これがＥＪＢのメリットなんですか？
他にメリットありますか？
0050デフォルトの名無しさんNGNG
>49

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

PetStoreのソースでもよめ。
0051デフォルトの名無しさんNGNG
（　´,_ゝ｀） ﾌﾟｯ
0052デフォルトの名無しさんNGNG
ＥＪＢで使われるパターンはプログラミングで参考になる事も多い。
0053デフォルトの名無しさんNGNG
ということは技術者のマスターベーションがＥＪＢなんですね（ｗ
005445NGNG
>>46 >>47
データベースのデータも消えてしまうんだったら
一度立ち上げたAPサーバ一回も、とめること出来ない
と思うんですが・・・
デプロイアンデプロイもできなくなっちゃう
0055デフォルトの名無しさんNGNG
>>54
あ～俺も疑問だ
remove()呼び出しが
クライアントだけならデータ消しても当然だが
コンテナシャットダウンしたとき、
モジュールデプロイしたときも
勝手に呼び出されて
DBのデータ消されるもんな
ずーっと、DB内にデータだけ残しておきたいときって
どうすんだろ
0056デフォルトの名無しさんNGNG
ejbRemove()に削除を実装してるのか？
005745NGNG
>>56
いえ、空っぽのままです
だから、何もしないようにしたいんですが
どうすればいいのかわからないので・・・
空っぽのやつを定義しておけば
何もやらない（DBのデータ削除しない）と思ってるんですが
違うんですか？
005845NGNG
CMPです
0059デフォルトの名無しさんNGNG
ほほう、findByPrimaryKey（）は見つからなければ
例外出すが
自分で定義したfinderメソッドは
例外出さないのか・・・
ちょっと勉強になった
0060デフォルトの名無しさんNGNG
>>45
ひょっとしてSunのJ2EESDKを使っている？
deploytoolのEntityBean設定には、アンデプロイする時に
テーブルも同時に削除するオプションがあって、
デフォルトでオンになっています。
0061デフォルトの名無しさんNGNG
>>60
いえ、JBossです
J2EESDKも以前やりました、結果は同じでした
こういう指定は、DDでやるのですか？
DDの書き方教えていただけると幸いです
どの解説書もそんな設定のこと書いてないので・・・

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

0062デフォルトの名無しさんNGNG
<defaults>
<datasource>java:/PostgresDS</datasource>
<datasource-mapping>PostgreSQL 7.2</datasource-mapping>
<create-table>true</create-table>
<remove-table>true</remove-table>←ココ
</defaults>
0063デフォルトの名無しさんNGNG
>>61
いえ、DDでやるわけではありません。
EJBの仕様には含まれていませんし、
普通の製品（WebLogicやWebsphere）などでは、
そういったオプションはなかったと思います。
J2EESDKのその機能は、どっちかといえばサンプルアプリを
簡単に動かすための付加機能ととらえるべきでしょう。
実業務でそんなことするはずがありません。
JBossは触ったことはありませんが、おそらく同じ理由で
そういう機能が付いているんじゃないでしょうか。
多分、オプションをはずすことが出来ると思いますので、
マニュアル読んで自分で対処して下さい。
0064デフォルトの名無しさんNGNG
>>62が答えだしてます
0065デフォルトの名無しさんNGNG
>>60
明らかにおかしいだろ？
そういうときは、だいたい自分が間違えてるんだよ
0066デフォルトの名無しさんNGNG
>>61

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

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

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

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

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


0067デフォルトの名無しさんNGNG
>>66
その考え方はいくらなんでも違うだろ。
0068デフォルトの名無しさんNGNG
>> 67

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

評価でサーバの動作を確認するとき、DB上のテーブル設定とその削除を
ユーザがやらなくていいと考えるのが普通ですかね。
0069デフォルトの名無しさんNGNG
>>66
その考え方はおかしい。永続化という意味を分かっていない。

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

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

それは>>62の方が回答を書いていますが、
EJBコンテナ独自のＤＤに
「デプロイやAPサーバシャットダウンのときにテーブルを削除する」
に設定しているから。
「勝手に」削除しているわけではありませんよ。
0070デフォルトの名無しさんNGNG
ま、どっちにしても「削除」は
開発段階に便利であるが
実運用では絶対にやらんな
0071デフォルトの名無しさんNGNG
>>66
お前の世界はメモリだけなのか。
オブジェクトが生きる世界はそんなに狭くはない
0072デフォルトの名無しさんNGNG
>>66

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

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

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

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

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

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

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

EJB以前に永続化、さらにはオブジェクト指向が理解できていない人には
無理な話よ。
0073デフォルトの名無しさんNGNG
　ああもっとなじって　庶民たちよ
　君たちには本質が見えないのだろう
　私はちーさまの声に音に凌辱され姦淫された奴隷なのだ
　苦しい，でも幸せ
　絶望だから快楽
　それが鬼ちーワールド
0074デフォルトの名無しさんNGNG
>>71

この世界は、JBOSSの寿命で決まっているのさ。
0075デフォルトの名無しさんNGNG
JBossのソースコード理解できるか？
それとＪｂｏｓｓ４のアスペクト指向てなんだ？
0076デフォルトの名無しさんNGNG
アスペクト指向　＝　オブジェクト指向でなしえなかった部品の再利用
だと、漏れは勝手に判断した。
0077デフォルトの名無しさんNGNG
物事を concern で捉え、concern 単位のソースの断片をあちこちにばら撒く
・・・ように見える。
0078デフォルトの名無しさんNGNG
>>75
要はユースケースで共通に現れる基盤部品を別のクラスにしようぜ！
って言うあたりまえのことをえらそうに名前を付けただけ。
0079デフォルトの名無しさんNGNG
要するにトリガーてこと
トリガー＝＝アスペクト
0080デフォルトの名無しさんNGNG
>>79
>>トリガー＝＝アスペクト
納得
0081デフォルトの名無しさんNGNG
>>76-80
全然とはいわないが、まったく本質をとらえてないよ。

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

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

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

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

0082デフォルトの名無しさんNGNG
＞全然とはいわないが、まったく本質をとらえてないよ。

・・・全然とまったくの違いがわかりまつぇん
0083　NGNG
過去ログからのコピーです。http://natto.2ch.net/mass/kako/974/974478132.html

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

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

　ちなみに私が盗聴されはじめたのは、芸能人にストーカーされ始めてからでした。
　そこからマスコミに広がって行った。
　だから余計「妄想」とか思われそう。
　友人に話したら完全に病気扱いされた。ストーカーって言葉がない時代だったしね。
　書いておいておいた小説のネタが、他人の原作でドラマ化されたときにはきれまくっ
たなあ。（一度や二度のことじゃないけど）
0084デフォルトの名無しさんNGNG
おまえらＥＪＢはoracle9iAS
だこれできまりだな。
値段は安いしＪｄｅｖｅｌｏｐｅｒまでついてくる。
他はだめだな（ｗ
0085デフォルトの名無しさんNGNG
>>84
俺はJBoss + Eclipse + Lomboz で充分なのだが
0086デフォルトの名無しさんNGNG
>>84
しかも、US OTN 版を使えば開発用途には只！！
0087デフォルトの名無しさんNGNG
oracle9iASって何気に高機能なんだけどあまり使われないね。
0088デフォルトの名無しさんNGNG
>>87
OC4Jの中途半端な実装がちょっとな。
0089デフォルトの名無しさんNGNG
OC4J、EJB周りの独自路線突っ走りまくりがなんとかなったら
結構いけてると思うのだが。
軽いし。
009088NGNG
>>89
うん俺も基本的には気に入ってるよ。珍しくpure Javaなサーバだし、
軽いから開発するときは手軽で良いと思う。
0091デフォルトの名無しさんNGNG
2,3年でＢＥＡは合併吸収されるでしょう
ＢＥＡ殺しのＯＲＡ９ＡＳとＪＢＯＳＳ。
時代は
ＯＲＡＶＳＷＡＳなのだ
ところでＢＥＡの××ＳＨＯＰ（ＶＢの連中がスピンアウトしてつくった）
つかいかたわからんのよ。だから１時間でけしました（ｗ
0092デフォルトの名無しさんNGNG
社員降臨？
0093デフォルトの名無しさんNGNG
ＯＲＡ９ＡＳはうんこ
0094デフォルトの名無しさんNGNG
昔はＡＰサーバと言えばOWASといういう時代もあったのだが。
いまだにＸＸカードリッジみたいな方式なのかな。
PL/SQLカートリッジなんておっそろしくて使えるかっての。
0095_NGNG
http://yomi.kakiko.com/hiroyuki/jaz_b01.html
0096デフォルトの名無しさんNGNG
EJBを勉強できるサイトありませんか？
初心者です。
0097デフォルトの名無しさんNGNG
EntityBeanを使わなきゃいけない場面てありますか？

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

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

さらにEntityBean使うと、
■めんどい
■メモリを食う
■性能が悪い（CMPだとそんなことないかな・・・）
といったようなデメリットしか思い浮かばないのですが・・・
0098デフォルトの名無しさんNGNG
>>97
実際にどの程度のことが出来るのかはおいといて、理想は
「ストレージの形態を隠蔽する」ことじゃないかねえ。

最終的にはRDBじゃなくてもいいように「したい」んだと思われ。
0099デフォルトの名無しさんNGNG
ここでいいかわからないのですが教えてください。
今までTomcatで勉強してたんですけどJ2EEでもjspが動くことがわかり
J2EEの/public_htmlへjspファイルを移動しました。
しかし、DBConnectionPool.classをどこへ移動すればよいかわかりません。
どこへ、移動したらよいのでしょうか？
010099NGNG
すみません。できました。
J2EEサーバーを再起動しないといけなかったんですね。
0101デフォルトの名無しさんNGNG
>>99
何度も書かれているが、"J2EE"とは仕様・規格を指す。
あんたの言う"J2EE"とはJ2EE Reference Implementation （J2EE RI）のことだろうと推測して回答。

JSPファイルもclassファイルも配置はJ2EEの仕様に沿っていればOK。
その書き方だとおそらくJSPファイルをそこに置いて動いてしまっているは
いいが、どうしてそこに配置すると動いているのかわかっていなさそうだな。
設定・デプロイ方法はTomcatと同じだ。というかJ2EE RIはTomcatを含んでいる。
server.xmlにContextの設定はしたか？
010299NGNG
J2EEにTomcatが入っていたのかー
WebLogicとかになったらまた違うのかなー
面倒だなー
0103デフォルトの名無しさんNGNG
ここで聞いちゃってもいいですかな。JBoss 3.0 使ってる人いますか？

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

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

なんとか初期化されずに済むような方法はないですかね。
0104デフォルトの名無しさんNGNG
>>103
初期化されないアプ鯖ってあるの？
0105デフォルトの名無しさんNGNG
コンパイルしなおしてデプロイしたんだろ？
なんで前のが残ってるんだ（ｗ
0106デフォルトの名無しさんNGNG
>104-105
ホットデプロイって知ってる？君たち。
0107デフォルトの名無しさんNGNG
>>97-98
っつーことは、
ストレージがＲＤＢ固定だったら、
EntityBeanは使う意味がないって事ですかねぇ
どなたかストレージがRDB固定の時にO-Rマッパー（JDO等）よりEntityBeanが優れている点を
説明できる方居ませんか？
0108デフォルトの名無しさんNGNG
EntityBeanの方がノウハウが進んでるし、多分管理も楽（それでも十分難しいと思うが）
JDOだとCastorだろうか？XMLとの統合もいい。
ってOracleも同じか。
0109デフォルトの名無しさんNGNG
>>106
EJBのインスタンスが存在している状態で
ホットデプロイするとどうなるの？
0110デフォルトの名無しさんNGNG
次に生成されたインスタンスから
変更となる
0111デフォルトの名無しさんNGNG
>>110
新旧入り混じるとシステム的に整合性が
取れないことは無いでつか？
0112デフォルトの名無しさんNGNG
あるはずのクラスが無くなったりメソッドのシグニチャとか変わったらどうなるんだろう？
0113デフォルトの名無しさんNGNG
>>107
EJBの方がトランザクション管理とかやりやすいでしょ？
0114デフォルトの名無しさんNGNG
（ビジネスロジック面で）システム整合性が
とれないような場合はAP鯖止めてからデプロイし、
起動したほうがいいね。
あくまで、AP稼働中にクラスモジュールを
入れ替えることが可能ということで、
ビジネス上の整合については
自己（運用者）責任だよ。
0115デフォルトの名無しさんNGNG
>>114
そゆことか。ｻﾝｽｺ！
011697NGNG
>>108
最近のフレームワークではEntityクラスを簡単に自動生成してくれるので、
ノウハウはいらないと思います。
むしろEntityBeanの余計な排他制御等の知識等のほうがめんどくさいのでは？

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

１．SessionBean＋EntityBean
２．SessionBean＋O-Rマッパーで作成したEntityクラス

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

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

個人的にはEntityBeanは廃れていくんじゃないかなぁと思っています。
どなたか反論（１．パターンの優れている点）をお待ちしています。
0117デフォルトの名無しさんNGNG
俺もCORBAよりEJBの方が面倒が無い、という理由でEJB良いと思う。
が、EntityBeanは使わない。
Javaのおかげでにわかにオブジェクト指向が脚光を浴びてきて
OODBに移行していくと思ってたんだけど、全然アテが外れた。
0118デフォルトの名無しさんNGNG
1.4のJ2EE Tutorialでも見てみ。EJBの扱いが突然小さくなってるぞ。
0119デフォルトの名無しさんNGNG
＞OODBに移行していくと思ってたんだけど、全然アテが外れた。
同じく（ｗ
0120デフォルトの名無しさんNGNG
＞＞1.4のJ2EE Tutorialでも見てみ
まだ出てないだろ。夏ぐらい？
0121デフォルトの名無しさんNGNG
>>120
まだ完成版じゃないけど
http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html
0122デフォルトの名無しさんNGNG
>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の部分はコピー＆ペーストされるよ。


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

Oracleだって今の信用？を得るまでは、おもちゃ扱いだったんでは？
0124デフォルトの名無しさんNGNG
データベース中心に考えると
JDOとか標準になったら
EJBの特筆点は分散技術だけになってしまうのか？

それと、やったことないがメーッセージドリブンBeanってこの先伸びるの？
0125デフォルトの名無しさんNGNG
でもさぁ、パフォーマンスとかデザインパターンとか
考えるのでやってて面白いけどな
0126デフォルトの名無しさんNGNG
難しい話題になると敬遠するな
JavaやってるやつでEJBまで理解してるやつっていないのかな？
さすが、入門言語
0127デフォルトの名無しさんNGNG
入門用じゃねーよ(;´д`)
エキスパート用だよ(;´д`)
0128デフォルトの名無しさんNGNG
>>126
さすがにお前の頭も分散技術ってことだな
0129デフォルトの名無しさんNGNG
>>124
Enterprise-MessageQueueのラッパですよ。
MQ自体は需要ありまくりですよ。
0130デフォルトの名無しさんNGNG
確かにMDBは需要有りまくりでしょう。
楽にメッセージ受信側が実装できるし。

なんか話を聞いてるとSFSBとEntityBeanだけ取り残されてる気がします。
0131デフォルトの名無しさんNGNG
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です

0132デフォルトの名無しさんNGNG
>131
JBossって、デプロイされてできたクラスのソースコードを見ることはできないのかい？
WebSphereとかだと、デプロイメント後、自動生成されたクラスのソースも見ることができて、
実際のSQLのイメージがなんとなくわかるようになっているのだが。
0133デフォルトの名無しさんNGNG
>>131
ソースコード落してきてデバッグ実行。オプソマンセー。
0134デフォルトの名無しさんNGNG
Stateless SessionBeanにインスタンス変数持ってる例を見かけたんだけど、それってアリなの？
ユーザーごとに変わる値でなければ別に構わないのかな？(参照EJBのHomeとか)
0135デフォルトの名無しさんNGNG
>>134
セッション基準に見たら無意味だが、ありなんでわ。
単純にSLSB自体のIDがほしいとか。何につかうかｼﾗﾝｹﾄﾞ。
0136デフォルトの名無しさんNGNG
>>131
プライマリーキークラスのフィールドは、publicという点も中尉。
0137デフォルトの名無しさんNGNG
すいませんが質問させてください
エンティティBeanの
ejbCreateの戻り値についてなんですが
return null;となってる解説書と
return primarykey;となっている解説書があるんですが
いったいどっちが本当なんでしょうか？
どっちも正常に動くんですが
どうなってるんでしょうか・・・？
0138デフォルトの名無しさんNGNG
>>137
CMP→Null
BMP→主キー
（J2EE TutorialのP119を参照）
0139デフォルトの名無しさんNGNG
>>138
レスさんくす
ということは、CMPなのに主キーが返ってる解説書は
糞ということでいいですか？
本のタイトル書いたろかな
0140デフォルトの名無しさんNGNG
>>139
CMP1.1はどうだか忘れたけど、
CMP2.0でそんなことやっている解説書は糞です。
本のタイトル載せてください。
0141デフォルトの名無しさんNGNG
EJBのファインダーの戻り値は
java.util.Collectionとなってる例が多いんですが
ListとかVectorじゃダメなんですか？
0142デフォルトの名無しさんNGNG
>>141
順序に意味が「ない」という意思表示なのでわ。
0143デフォルトの名無しさんNGNG
>>142
ん～でも、OrderByで取得したいときって
やっぱ、Collectionだとダメですよね？
0144デフォルトの名無しさんNGNG
>>138-140
return null; でも return primarykey; でも、どっちでもOKなんですが...
ただ、return primarykey; としたとしても、そのprimarykeyは使われない
というだけで...。
0145デフォルトの名無しさんNGNG
EJBやっていると
例外をthrowする場面が多くなると思うんですが
どの辺りまで引っ張ってくればいいんでしょうか？
いちおう、いまのところ
クライアントの手前に例外のフィルターみたいな役割のクラスを置いて
そこで、とりあえずすべてキャッチするようにして
あとは、例外でたことをクライアントにしらせる
って言うやり方してるんですが
こういうやり方でよいのかどうか判断つきません

とくに、どこまで引っ張ってくれば（throw）よいのか？
っていうのがわかりません
クライアントに知らせることが出来るなら
なにもthrowしなくてもフラグやメッセージさえ
わたせばいいのかな？とも思いますし・・・
この辺に関しての標準的な考え（パターンとか）ってありますか？
0146デフォルトの名無しさんNGNG
上げ忘れましたすいません
0147デフォルトの名無しさんNGNG
＞ なにもthrowしなくてもフラグやメッセージさえ
＞ わたせばいいのかな？とも思いますし・・・
フラグやメッセージの取り決めしなきゃならんだろ。
プロジェクトによってバラバラだったりで毎回決めなきゃならん。
ひどいときはシステムのあちこちで統一性のないフラグやメッセージの
使い方がまかり通ることもある。

そんなことしなくてもいいのが例外処理の利点じゃないか。
0148デフォルトの名無しさんNGNG
>>145
サーバ側で処理する必要がないなら、RemoteExceptionのサブクラス作って
そいつにラップしてクライアントに丸投げ、サーバの処理は全部ロールバック、
あとはクライアント側でどうにでも、が一番楽なんじゃないかねえ。
0149デフォルトの名無しさんNGNG
>>145
「どこまで引っ張ってくれば（throw）よいのか？」と書いてるところを見ると、
システムを層に分けてるだろうから、自分の層で処理できるものだけcatchして
メッセージなり戻り値なりに置き換えればいいんじゃないの?
最終的には（どの層も処理できない例外は）、フィルター的なもので処理することに
なるだろうけど（Strutsにもそういう仕組みがあるし）。
0150145NGNG
レスサンクスALL

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

システム例外はそのままWebのコンテナにServletExceptionとして
throwすることにしました
0151デフォルトの名無しさんNGNG
すいません教えてください
EJBの数が多いので
ejb-jar.xmlファイルなどのDDファイルがすごく長くなります
とくに、CMPだとフィールドとかも書かなければならないので・・・
なので、それぞれ別々のJARファイルにまとめて
それらをWEBコンポーネントと一緒にEARとかにまとめても
大丈夫でしょうか？
0152デフォルトの名無しさんNGNG
EJBとEJBクライアントで発生する例外を次のように分類する。
　(1)EJBのシステム例外
　(2)EJBのアプリケーション例外
　(3)Webアプリのシステム例外
　(4)Webアプリのアプリケーション例外
システムが直面するエラー状況を次のように分類する。
　(A)入力値エラー
　(B)アプリケーションエラー
　(C)システムエラー

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

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

そもそもCMRとか使用すると同一ejb-jarじゃなきゃいけないってこともあるぞ。
0154デフォルトの名無しさんNGNG
EJBって何がエンタープライズなのかと思ったら、
EJBの仕組みその物がエンタープライズなんですね！
0155デフォルトの名無しさんNGNG
>>151
まさか、いまどきDDを手で書いてるの??
0156デフォルトの名無しさんNGNG
>>155
じゃあどうやって書くんだ？ん？
0157デフォルトの名無しさんNGNG
>>156
アプリサーバに付属のデプロイツールとか使わないの？
もちろん、初めて学習するときには仕組みや設定内容を理解するために
テキストエディタ等使って手で書くことも必要かもしれないが、
一度やってみれば手書きは限界に近いものだと誰でも悟ると思うよ。
EJB使うってだけで大半は大規模アプリ。
大規模アプリのDDを全部手書きでメンテするのは大変でしょ。
0158151NGNG
いや、いちおうXDoclet使ってますけど
DDがこんなに長くていいのかなぁ～と思ったわけです
みんなどうしているのかなぁと・・・
一枚でいいのなら（それが標準なら）それでいいんですけど
0159デフォルトの名無しさんNGNG
>>158
JBuilder Ent版 の EJBデザイナを使えば、全部自動で作成してくれる。
もちろん主要なサーバーに対応してるし。
0160デフォルトの名無しさんNGNG
>>159
多毛絵よ！
0161デフォルトの名無しさんNGNG
>158
DDが長くなるのはしょうがない。みんなそうだ。気にするな。
0162デフォルトの名無しさんNGNG
159>>さんに質問！
全自動で作ってもコンパイルはantでするんですか？
ＩＤＥはいまいち信頼性がなくＪＢも情報が少なすぎ。
（特に他のＡＰＳ使う場合）
0163デフォルトの名無しさんNGNG
>>162
>全自動で作ってもコンパイルはantでするんですか？
いいえ。
0164デフォルトの名無しさんNGNG
すいません教えてください
ＥＪＢのＱＬに渡すパラメータって
intやlongなどのプリミティブ型はダメなんでしょうか？
java.lang.Integerやjava.lang.Longに変換して渡さないといけないんでしょうか？
0165デフォルトの名無しさんNGNG
>164
Spec読め。
0166デフォルトの名無しさんNGNG
↓>>164のPCのスペックがこの辺に。
0167デフォルトの名無しさんNGNG
＞＞多毛絵よ！
キージェネがあるだろ
0168デフォルトの名無しさんNGNG
IDEは使い物なりのか？
0169デフォルトの名無しさんNGNG
ejbCreateの引数ってなんでオブジェクトなんですか？
int や　booleanはそのまま使えないんでしょうか？
いちいち、取り出してキャストするのがめんどくさいんですけど
理由がわかりません
0170_NGNG
http://homepage.mac.com/hiroyuki44/
0171デフォルトの名無しさんNGNG
>169
intで返すならjava.lang.Integerでいいじゃん。
そんなに変わらんでしょ。
0172デフォルトの名無しさんNGNG
>>159
XDocletもおすすめやで～日本語マニュアル少ないけど
0173デフォルトの名無しさんNGNG
>>171
は？言ってる意味がわからん
キャスト発生するじゃん？
0174デフォルトの名無しさんNGNG
>>169
ちったぁ頭使えよ。
0175デフォルトの名無しさんNGNG
>>169
オブジェクト指向って知ってる?
こういう奴にはsmalltalkの刑だ。
0176デフォルトの名無しさんNGNG
DTO（VO）とかを使わないで、ただ単に
文字の配列をDTOとして使うのは
あまり良くないことですか？

返り値のデータ量が非常にコンパクト
（データベースから条件に相当する2～3文字を引っ張ってくる）なので
わざわざ、DTOのインスタンス作るの馬鹿らしいんですけど
0177デフォルトの名無しさんNGNG
>>176
当然そうするべきです
0178デフォルトの名無しさんNGNG
>>177
すいません

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

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣
0180山崎 渉NGNG

　__∧＿∧_
　|（　　＾＾ ）|　＜寝るぽ（＾＾）
　|＼⌒⌒⌒＼
　＼ |⌒⌒⌒~|　　　　　　　　　山崎渉
　　 ~￣￣￣￣
0181デフォルトの名無しさんNGNG
MessageDrivenBean って使ってる人いる？どんな感じで使うのかなー
0182デフォルトの名無しさんNGNG
>>181
MessageDrivenBean のほうが使い勝手あるらしいが
おれもどういうときに使うのかよーわからん
でも、覚えるのは簡単だよ
0183デフォルトの名無しさんNGNG
っていうかよースレの順番逆転してないか？
「age」進行の山崎 渉 にやられたのか

びっくりしたよ、起きたら別の板かと思ったよ
で慌てて玄関の表札確認したよ
0184デフォルトの名無しさんNGNG
>182
使い勝手があるというより、
J2EEでは他に大体手段がないのだから、
（ユーザーアプリの中で、別スレッドでキューを監視しつづけるなんてことはできないから）
使わざるを得ない。
0185デフォルトの名無しさんNGNG
CMPのEntityBeanをつかってカッチリO-RマッピングしてRelationまでつかってるような開発って実際どのくらいあるのかな。だれか実際開発してる人いますか？
0186デフォルトの名無しさんNGNG
>>185
私が関ったシステムでは、CMPオンリーで、Relationもバリバリ使ってますよ。
0187デフォルトの名無しさんNGNG
earやwarの圧縮の話で盛り上がっていたことで気になること。
全部ひとつのearにまとめてしまえば楽じゃね？
0188デフォルトの名無しさんNGNG
>>187
ヴァカかおまえは。
圧縮の話しなんか誰もしてないが。字が読めないならプログラミングなんて無理じゃないのか?
0189デフォルトの名無しさんNGNG
>>182
MDBはトランザクションを即効で終わらせたいときに便利。
DB負荷も少なくてすむ。
0190デフォルトの名無しさんNGNG
>>186
どのくらいの規模ですか？
何エンティティくらいあるのですか？
0191デフォルトの名無しさんNGNG
>>187
バグ等で入れ替えることまで考えると１つのEarファイルなんか無茶だと思うが・・・
一人で開発しているならともかく。
0192デフォルトの名無しさんNGNG
> バグ等で入れ替えることまで考えると１つのEarファイルなんか無茶だと思うが・・・

だから、EARはアプリケーションの論理的な単位でまとめろって。
運用上の都合で分けるのは、素人仕事だぞ。
0193デフォルトの名無しさんNGNG
EJBは再利用コンポーネントだ。
.ear ファイルにまとめちまうということは、
その中の一部を入れ替えるだけでもサービスの停止が必要になるということだ。

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

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

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

0194デフォルトの名無しさんNGNG
>>193
earにまとめとかないと、参照渡しによる高速化ができなくねぇ？
0195デフォルトの名無しさんNGNG
>193

それこそ、運用上の都合だ。そいうことは運用、またはトポロジー（クラスタリング）でカバーしろ。
運用上の都合をアプリケーションに持ち込むのは素人仕事。
0196デフォルトの名無しさんNGNG
運用無視してつくられたアプリケーションの面倒なんか見てられねーよ。
それこそ素人仕事もいいところだ。
ただ動くアプリケーションなんか誰でも作れるんだよ。
動かしつづけられるアプリケーションつくってくれよ。
0197デフォルトの名無しさんNGNG
>>195みたいなやつは、
「データ不整合が起きたらリカバリに1週間かかります」
みたいなシステムを作るんだろうな。
0198デフォルトの名無しさんNGNG
てか、サービスまったく止めないで運用しているのが存在するのか？
0199デフォルトの名無しさんNGNG
>>193のネタって重要だよね。J2EEアプリが、オブジェクトがどこにある
どのバージョンのクラスファイルに基づいて作成されるのかを把握しづら
いのは、どうにかナランかねえ。
0200デフォルトの名無しさんNGNG
>>193

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

2台のマシンをクラスタリングして、1台目のマシンに ear をデプロイして、
完了したら2台目のマシンにデプロイさせてやるってふうにすれば、
サービスとして停止はないのじゃないですかね。もちろん変更内容にも
よるでしょうけど。
0201_NGNG
http://homepage.mac.com/hiroyuki44/hankaku04.html
0202デフォルトの名無しさんNGNG
>193
>.ear ファイルでまとめられていると、無駄なサービス停止が生まれてしまうのだ。

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

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

そうすれば、ひとつのearに含まれるejb-jarを更新したところで、
もうひとつのearには何の影響もない。
0203デフォルトの名無しさんNGNG
>>193は、だからearのまとめ方を考えろといってるんじゃないの。
ひとつにまとめるんじゃねえよﾓﾙｧって
0204デフォルトの名無しさんNGNG
どこでまとめようがそんなの知らんよボケェ
まとめたっていいじゃんいいじゃん
っていうかよ、Classファイル入れ替えの機能ってついてないのか？
高級なお値段のAP鯖には？
0205デフォルトの名無しさんNGNG
>>204
適当にClass入れ替えたら何が起きるか想像してみろよ。
0206デフォルトの名無しさんNGNG
>>200
普段はクラスタで動いてて、デプロイ時にはクラスタの
メンバーからはずしてってことを言ってるんだよな？

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

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


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

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

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


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

そのとおり。
EARはあくまでそれ自体で完結しているアプリケーションの単位。
必要なライブラリは全てEAR内に含めるのが基本。
0210デフォルトの名無しさんNGNG
ここで話題を提供
日経コンピュータでそろそろＪａｖａで大規模なシステムを作る
計画が急速に進んでいるがどう思う？
成功すると思う？
俺は成功すると思うが。代わりがないからね（ｗ



0211デフォルトの名無しさんNGNG
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
　　 ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
　　|||||||||||||||||||||||||||~~~~~~~~~||||||||||||||||||||||||||||||||
　 ||||||||||||||||||||||||||||　　　　　　||||||||||||||||||||||||||||||||
　||||||||||||||||||||||||||| |　　　　　　|| |||||||||||||||||||||||||||||
　|||| ||| ||||||||||| | | ||　　　　　　| | ||||| ||||||| ||||||||| |||
　|||| | || ||| ||| |||| |　|　　　　　　||| || | || |||| |||| || ||||
　|||| | || | |||| | | | ||　　　　　　　||　| || | | ||　|| || |||
　||| || |||_|＿|_|＿|J　 ，ハ、　ι|_|＿|＿|＿|| |　|||
　(＾|　　|　　。　　 |ヽ　　　　　/| 　　。　　|　　|＾)
　(e|　　L_＿＿＿』　|　　　　|　L_＿＿＿』　　|3)
　(　||　　￣￣￣　　　|　　　|　　　￣￣￣　　 ||，)
　｜||　　　　　　　　　 |　　|　　　　　　　　　　||｜
　 ｜||　　　　　　　　　 | 　|　　　　　　　　　　||｜　　／￣￣￣￣￣￣￣￣￣
　　＼|、　　 _＿　＿< |　|　>＿　_＿　　　，|／　　＜　ローン！！メンピンイーペードライッチョー！！　　　　　　
　　　 -| ｌ　　↑￣　　 ヽ__／　　￣↑　　//　　　　　＼＿＿＿＿＿＿＿＿＿
　　　　　| ｌ　　　＼┼┼┼┼┼／　　//
　　　　　ヽｌ　　　　￣￣￣￣￣　　　//
　　　　　　＼　　　‘￣￣￣￣'　　　／
　　　　　　　＼　　　　　　　　　　　／
　　　　　　　　＼　　　　　　　　　／
　　　　　　　　　　＼＿＿＿＿／






0212デフォルトの名無しさんNGNG
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
　　 ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
　　|||||||||||||||||||||||||||~~~~~~~~~||||||||||||||||||||||||||||||||
　 ||||||||||||||||||||||||||||　　　　　　||||||||||||||||||||||||||||||||
　||||||||||||||||||||||||||| |　　　　　　|| |||||||||||||||||||||||||||||
　|||| ||| ||||||||||| | | ||　　　　　　| | ||||| ||||||| ||||||||| |||
　|||| | || ||| ||| |||| |　|　　　　　　||| || | || |||| |||| || ||||
　|||| | || | |||| | | | ||　　　　　　　||　| || | | ||　|| || |||
　||| || |||_|＿|_|＿|J　 ，ハ、　ι|_|＿|＿|＿|| |　|||
　(＾|　　|　　。　　 |ヽ　　　　　/| 　　。　　|　　|＾)
　(e|　　L_＿＿＿』　|　　　　|　L_＿＿＿』　　|3)
　(　||　　￣￣￣　　　|　　　|　　　￣￣￣　　 ||，)
　｜||　　　　　　　　　 |　　|　　　　　　　　　　||｜
　 ｜||　　　　　　　　　 | 　|　　　　　　　　　　||｜　　／￣￣￣￣￣￣￣￣￣
　　＼|、　　 _＿　＿< |　|　>＿　_＿　　　，|／　　＜　ローン！！メンピンイーペードライッチョー！！　　　　　　
　　　 -| ｌ　　↑￣　　 ヽ__／　　￣↑　　//　　　　　＼＿＿＿＿＿＿＿＿＿
　　　　　| ｌ　　　＼┼┼┼┼┼／　　//
　　　　　ヽｌ　　　　￣￣￣￣￣　　　//
　　　　　　＼　　　‘￣￣￣￣'　　　／
　　　　　　　＼　　　　　　　　　　　／
　　　　　　　　＼　　　　　　　　　／
　　　　　　　　　　＼＿＿＿＿／






0213デフォルトの名無しさんNGNG
>
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
　　 ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
　　|||||||||||||||||||||||||||~~~~~~~~~||||||||||||||||||||||||||||||||
　 ||||||||||||||||||||||||||||　　　　　　||||||||||||||||||||||||||||||||
　||||||||||||||||||||||||||| |　　　　　　|| |||||||||||||||||||||||||||||
　|||| ||| ||||||||||| | | ||　　　　　　| | ||||| ||||||| ||||||||| |||
　|||| | || ||| ||| |||| |　|　　　　　　||| || | || |||| |||| || ||||
　|||| | || | |||| | | | ||　　　　　　　||　| || | | ||　|| || |||
　||| || |||_|＿|_|＿|J　 ，ハ、　ι|_|＿|＿|＿|| |　|||
　(＾|　　|　　。　　 |ヽ　　　　　/| 　　。　　|　　|＾)
　(e|　　L_＿＿＿』　|　　　　|　L_＿＿＿』　　|3)
　(　||　　￣￣￣　　　|　　　|　　　￣￣￣　　 ||，)
　｜||　　　　　　　　　 |　　|　　　　　　　　　　||｜
　 ｜||　　　　　　　　　 | 　|　　　　　　　　　　||｜　　／￣￣￣￣￣￣￣￣￣
　　＼|、　　 _＿　＿< |　|　>＿　_＿　　　，|／　　＜　ローン！！メンピンイーペードライッチョー！！　　　　　　
　　　 -| ｌ　　↑￣　　 ヽ__／　　￣↑　　//　　　　　＼＿＿＿＿＿＿＿＿＿
　　　　　| ｌ　　　＼┼┼┼┼┼／　　//
　　　　　ヽｌ　　　　￣￣￣￣￣　　　//
　　　　　　＼　　　‘￣￣￣￣'　　　／
　　　　　　　＼　　　　　　　　　　　／
　　　　　　　　＼　　　　　　　　　／
　　　　　　　　　　＼＿＿＿＿／






0214デフォルトの名無しさんNGNG
>
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
　　 ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
　　|||||||||||||||||||||||||||~~~~~~~~~||||||||||||||||||||||||||||||||
　 ||||||||||||||||||||||||||||　　　　　　||||||||||||||||||||||||||||||||
　||||||||||||||||||||||||||| |　　　　　　|| |||||||||||||||||||||||||||||
　|||| ||| ||||||||||| | | ||　　　　　　| | ||||| ||||||| ||||||||| |||
　|||| | || ||| ||| |||| |　|　　　　　　||| || | || |||| |||| || ||||
　|||| | || | |||| | | | ||　　　　　　　||　| || | | ||　|| || |||
　||| || |||_|＿|_|＿|J　 ，ハ、　ι|_|＿|＿|＿|| |　|||
　(＾|　　|　　。　　 |ヽ　　　　　/| 　　。　　|　　|＾)
　(e|　　L_＿＿＿』　|　　　　|　L_＿＿＿』　　|3)
　(　||　　￣￣￣　　　|　　　|　　　￣￣￣　　 ||，)
　｜||　　　　　　　　　 |　　|　　　　　　　　　　||｜
　 ｜||　　　　　　　　　 | 　|　　　　　　　　　　||｜　　／￣￣￣￣￣￣￣￣￣
　　＼|、　　 _＿　＿< |　|　>＿　_＿　　　，|／　　＜　ローン！！メンピンイーペードライッチョー！！　　　　　　
　　　 -| ｌ　　↑￣　　 ヽ__／　　￣↑　　//　　　　　＼＿＿＿＿＿＿＿＿＿
　　　　　| ｌ　　　＼┼┼┼┼┼／　　//
　　　　　ヽｌ　　　　￣￣￣￣￣　　　//
　　　　　　＼　　　‘￣￣￣￣'　　　／
　　　　　　　＼　　　　　　　　　　　／
　　　　　　　　＼　　　　　　　　　／
　　　　　　　　　　＼＿＿＿＿／






0215デフォルトの名無しさんNGNG

　　 ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
　　|||||||||||||||||||||||||||~~~~~~~~~||||||||||||||||||||||||||||||||
　 ||||||||||||||||||||||||||||　　　　　　||||||||||||||||||||||||||||||||
　||||||||||||||||||||||||||| |　　　　　　|| |||||||||||||||||||||||||||||
　|||| ||| ||||||||||| | | ||　　　　　　| | ||||| ||||||| ||||||||| |||
　|||| | || ||| ||| |||| |　|　　　　　　||| || | || |||| |||| || ||||
　|||| | || | |||| | | | ||　　　　　　　||　| || | | ||　|| || |||
　||| || |||_|＿|_|＿|J　 ，ハ、　ι|_|＿|＿|＿|| |　|||
　(＾|　　|　　。　　 |ヽ　　　　　/| 　　。　　|　　|＾)
　(e|　　L_＿＿＿』　|　　　　|　L_＿＿＿』　　|3)
　(　||　　￣￣￣　　　|　　　|　　　￣￣￣　　 ||，)
　｜||　　　　　　　　　 |　　|　　　　　　　　　　||｜
　 ｜||　　　　　　　　　 | 　|　　　　　　　　　　||｜　　／￣￣￣￣￣￣￣￣￣
　　＼|、　　 _＿　＿< |　|　>＿　_＿　　　，|／　　＜　ローン！！メンピンイーペードライッチョー！！　　　　　　
　　　 -| ｌ　　↑￣　　 ヽ__／　　￣↑　　//　　　　　＼＿＿＿＿＿＿＿＿＿
　　　　　| ｌ　　　＼┼┼┼┼┼／　　//
　　　　　ヽｌ　　　　￣￣￣￣￣　　　//
　　　　　　＼　　　‘￣￣￣￣'　　　／
　　　　　　　＼　　　　　　　　　　　／
　　　　　　　　＼　　　　　　　　　／
　　　　　　　　　　＼＿＿＿＿／






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

これで「複数企業や業界にまたがる共同インフラの構築」なんて案件がいくつもあれば完璧だろう。
実際に構築しているところも知ってるし。
0217デフォルトの名無しさんNGNG
>>216
何が完璧なんだ？
何のためのコマがそろったんだ？
0218デフォルトの名無しさんNGNG
>>Linux が OSの仮想化を促し、
意味ふめい　
0219デフォルトの名無しさんNGNG

池田大作大先生はかって

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

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

ttp://society.2ch.net/test/read.cgi/koumei/1057065225/
0220デフォルトの名無しさんNGNG
http://www-6.ibm.com/jp/servers/eserver/zseries/server/z990/index.html
とかのことか？
0221デフォルトの名無しさんNGNG
>>220
それはLinuxがOSの仮想化を促しているのではなく、
メインフレームH/WとVMがLinuxの仮想化を促しているのだ。

>>216は夢見すぎ
0222山崎 渉NGNG
（＾＾）
0223山崎 渉NGNG
　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン
■ このスレッドは過去ログ倉庫に格納されています