J2EEは，カオスの中に現れた新秩序

>>21
久しぶりに覗いてみれば、、、
JPetStore このソースって何使って作ってるの？
// ----- BEGIN: FIELDS LOCKED BY POOL_LOCK -----
よく全部つくったなー。関心。
Dao,JDBC,DAOTransaction似た奴全部、発案＋半端な実装なら経験あるよ。
すげー勉強になる。このぐらいのパフォーマンスチューンでもいいのかー。
ソース読みやすいしすげーよ。

25 ：アフォ：02/09/26 00:12

>>21
公開中ソースにバグ発見。StaticBeanProbe
public static void setField(Object object, String name, Object value)
throws BeansException {
try {
Field field = object.getClass().getField("name");
field.set(object, value);
} catch (Exception e) {
throw new BeansException(e.toString());
}
}
これって、getField(name)じゃないのか。＆キャッシュしなくていいのか。
これで、十分なのか。
俺、ちゃんと新人でも理解できるように例外処理しなくていいソース書けって
よく言われて鬱になっているんだが、こういうふうにパッケージごとに例外
定義しちゃうのも手かもしれないね。
この辺りで止めるのが読みやすいし、開発も楽だし。目から鱗だね。

26 ：デフォルトの名無しさん：02/09/26 00:14

こんな時間にエキサイトせんでも。(w
寝られなくなるぞ。

27 ：デフォルトの名無しさん：02/09/26 00:19

>>25
早いな、読むの。漏れ今解凍したばかりだ。
何か急に良スレの予感（ｗ

28 ：デフォルトの名無しさん：02/09/26 00:21

com.ibatis.common系のソースがあればいいんだけどねえ。

29 ：27：02/09/26 00:22

風呂に入ってから、漏れはまず開発者ガイドを読んでみるよ。

30 ：27：02/09/26 00:23

>>28
それって、
http://www.ibatis.com/common/common.html
の奴でいいんだよな。漏れはそっちから見ていこうと思ってたYO

31 ：28：02/09/26 00:27

>>30
おお、そっちにあったのか。ありがと。

32 ：アフォ：02/09/26 00:36

じゃぁ、俺いまから飲みにいきます。また明日。

33 ：アフォ：02/09/26 01:56

ただいまっす。読み直してるよ。
凄いね。setFieldなんて使ってなかったよ。全然。

34 ：デフォルトの名無しさん：02/09/26 02:05

>>33早！！

35 ：デフォルトの名無しさん：02/09/26 02:53

悲しいくらい役に立たなかった（鬱
時間の無駄。

アフォってひょっとしてクライアントサイドJavaのスレで
自分のライブラリ晒した奴か？

まさにそれくらいのレベルだな、これ自体。

36 ：27：02/09/26 03:04

風呂から帰ってきたYO

>>35そうなの？　どの辺が駄目っぽいのか教えてくれ。
明日読もうかと思ってたんだが、出来れば時間の無駄は避けたい（ｗ

37 ：デフォルトの名無しさん：02/09/26 03:08

もし上記のアフォなら、スレの趣旨を無視して話を進める。
ライブラリのネタ集めなら自分のサイトでやるように。

まあ、J2EEのネタ自体難しいけどね。

38 ：27：02/09/26 03:17

>>37よくわからんがスレ違いだから止めれってことはわかった。
とりあえず明日コードを読んでみるわ。というわけで寝る。

39 ：デフォルトの名無しさん：02/09/26 03:24

基本はStrutsをベースにしている。
実装方法はStrutsと同じ。

独自なところはDAO部分のみといっても過言ではない。
定義とクエリーをxmlに出す、というのが趣旨。

40 ：デフォルトの名無しさん：02/09/26 03:25

27のレスの後だった．．．（さらに鬱

41 ：27：02/09/26 03:33

>>39-40すまん。漏れのカキコがまずいのかと思ったんだ。
ありがとう。漏れはDAOのところから読もうと思ってたので
読む甲斐があるかも知れない。

漏れは、J2EEがややこしくなっている理由は、EJBにあると思ってる。
極論RDBの上にRDBを作ろうとしている気がするんだ。
JTAとかJDBCを上手く使うことで、十分にJ2EEの標準化の価値はあると
思ってる。

だから.NETと比較する場合も、ADO.NETに合わせた軽いもので比較しないと
駄目だと思うし、元記事に書いているようなシステムであっても、
必ずしも分散トランザクションなんているわけじゃないと思うんだ。

規格が整備されることと、それをどこまで利用するかというのは、また別だと思われ。
というわけで、DAOの部分は非常に気になるので読んでみるよ。
Strutsは好きじゃないので読まないようにしておくわ（ｗ

ともあれ、ありがとうな。感謝！

42 ：デフォルトの名無しさん：02/09/26 04:30

>>41
同意。

実際世の中では、EJBを必要とする規模の方が
圧倒的に少ないと思われ。
むしろ小・中規模では開発効率に悪影響を及ぼす。
その意義は認めるけどね。

ちなみに.NETのDataSetはある程度魅力を感じる。
複数のテーブルとそのリレーションを保持できるのはおいしい。
しかし、結局は同時更新の問題を常に孕むことになるが。
と書きつつ、DataSetのその機能を使うところがあまり思い
つかなかったりもする。

JDOも気になっているけど、おいらは業務アプリ屋なので、
結局あそこまでは逆に使えない。

ちなみにDAO部分は定義とxml部分を外部に出すと書いたが、
おいらはxmlに出せば出すほど、管理が増える
（自動生成だとしても）と考えているから、けっこうイヤンな実装。
もしそのリスクを背負うなら、こなれたものは他にあるしね。
だいたい、おいらの実装よりひどいので鬱だった。

43 ：デフォルトの名無しさん：02/09/26 11:54

.NET PetShopのストアド使いまくりはいかがなものか。

44 ：アフォ：02/09/26 13:14

>>35
すまないね。俺もDAOの部分しか必要としてない。
NetscapeApplicationServer3を思い出した。ただそれだけ。

45 ：アフォ：02/09/26 13:15

>>39
>>基本はStrutsをベースにしている。
>>実装方法はStrutsと同じ。
>>
>>独自なところはDAO部分のみといっても過言ではない。
>>定義とクエリーをxmlに出す、というのが趣旨。
作者たん？違ったら笑える。

46 ：アフォ：02/09/26 13:40

うーん。>>41 は参考になるけど。 >>42 は参考にならないな。
一体全体何が「同意」なのかよくわからん。こんなSEよくいるね。

47 ：アフォ：02/09/26 14:29

放置された・・・

48 ：27：02/09/27 16:21

ちょっと見てみた。漏れはへたれなのでDAOは結構参考になった。
簡単なサンプルを作ってみたんだが、そこそこ良い感じで使えそうな
感じがした。これをベースにちょっと色々と試行錯誤してみるよ。

49 ：デフォルトの名無しさん：02/09/27 20:44

tarbinみたいに、
webコンテナ上でEJB並みの機能を
実現しようとしているフレームワークを
使うぐらいなら
EJBつかったほうがいいようにおもった

50 ：デフォルトの名無しさん：02/09/27 20:48

ageるなよ。こんなスレ。

51 ：デフォルトの名無しさん：02/09/28 05:15

>>49
その根拠は?

52 ：アフォ：02/10/05 03:48

TorqueでTransaction管理どうすればいい？
Torque, RollBack で検索しても何も見つからんぞ。

53 ：　：02/10/05 04:21

java.lang.Object
|
+--org.apache.torque.util.Transaction

http://jakarta.apache.org/turbine/torque/apidocs/org/apache/torque/util/Transaction.html

54 ：デフォルトの名無しさん：02/10/05 04:30

J2EEの話題を期待してたのに
単発の質問はこっち
http://pc3.2ch.net/test/read.cgi/tech/1032944246/l50

55 ：デフォルトの名無しさん：02/10/05 11:03

>>51
同じことを使用とするなら、実績があって
実質標準になっているEJBの方がよくない？
わざわざ似たような機能を実現するために、
新しいこと覚えるのやだな。
EJBだと
お金とパフォーマンスの問題はあるけど

56 ：デフォルトの名無しさん：02/10/05 13:25

つまらん質問なんだけどなんでJPETSTOREはコードが
本家のPETSHOPより短いんだ？
まだDLしてないからわからないけど。
NETならコンポーネントつかってるからだとおもうんだけど

57 ：デフォルトの名無しさん：02/10/05 13:31

> 実績があって実質標準になっている

おめでてーな

58 ：デフォルトの名無しさん：02/10/05 13:33

>>55
日本には、プライドだけ高くて世の中の流れについては無知な企業が、
客を囲い込む為という浅ましい発想でそういうものを雨後の竹の子の
ようにあちこちで作りまくってます。

標準が存在することのメリットを理解できないバカがナゼこんなに多
いのでしょうか？J2EEは仕様でしかないのだから、技術オナニーがし
たいならせめてAPIだけでもJ2EEにあわせればいいのに、外部インタ
ーフェイスから全て俺様ルールで開発しているヤツラは、一体どういう
脳みその構造をしているのでしょう･･･

59 ：デフォルトの名無しさん：02/10/05 13:35

サバサイドJavaでは「珍妙なフレームワーク」を使いこなすことが美徳ですが何か？

60 ：デフォルトの名無しさん：02/10/05 13:52

EJBではThread操作は禁止されていますが、
非同期駆動をしたいときは、

1. JMSでメッセージをおくる（その後は、Message-Driven Beanで処理）

くらいしか、方法はないでしょうか？

EJB2.1 では、Timer Service が使えるのですが...。
現状のJ2EE1.2 or 1.3 では他に方法はない？

この需要は多いと思うのだけど。

61 ：アフォ：02/10/05 16:45

>>53
Torque で、 Transaction できるの？
Customer c = new Customer(); c.setName("abc"); c.save();
Book b = new Book(); c.setName("book"); c.save();
これをRollbackするときはどうする？

62 ：デフォルトの名無しさん：02/10/05 22:40

>58
EJBを使ってるんだけど、結局StatelessのSessionBeanで
再利用性も０に近いつくりをしていて、
なおかつ俺様・大企業様フレームワークで開発を強いられることが
多いです。
つまりEJBを使う必要なんてないんですが、
ほとんど自社サーバーを売るため・実績を作るだけに
EJBを採用しているのが理由でしょう。
EJBの機能をもっと使いこなせば良いのになと思ってしまいます。

63 ：デフォルトの名無しさん：02/10/05 23:32

フレームワークを使うと必要な部品ははじめからほとんど揃ってて、
コードも誰が書いても同じような書き方しかできなくなり、
それこそ1～2年目の奴でも作業ができてしまう。

J2EEは所詮次世代COBOLプログラマーを大量に生み出すだけで、
こんなもんを必死でやっても気がつけば自分が安売りされて使い捨てられるだけ。
踊らされてる奴も分かってて踊ってる奴もご苦労なこった。

64 ：アフォ：02/10/06 00:19

>>63
必死にならなくてすむのが、フレームワークの利点では？
去年5000万円のと同規模でも今年は1000円万でもNGなんて話を聞いたけど。
人数が減るっていう事じゃないかな？
ただ俺個人に限れば、20～50画面のプロジェクトから、いきなし200画面の
プロジェクトにまわされて、フレームワークいくつか弄っていて良かった。
と思ってるよ。

65 ：デフォルトの名無しさん：02/10/06 00:43

>>63
っていうか、中規模～大規模のシステムを構築する場合、
そのレベルの人間でも作業できるようにしないと作業者が足りないと思うがね。

安売り云々に関しては、
そもそもそれがJ2EE・フレームワークに限定される問題でもないでしょ。

66 ：デフォルトの名無しさん：02/10/06 01:38

>>63
JavaがCOBOLの後継であることは死滅系スレで既出

67 ：デフォルトの名無しさん：02/10/06 02:13

それにしてもEJB使わないねー。

68 ：デフォルトの名無しさん：02/10/06 02:37

Javaの案件はいくつかこなしてきたけど、次世代COBOLというのもうなづける。
こんなのばっか。

package F01;

public class F01-001A extends ～

69 ：デフォルトの名無しさん：02/10/06 02:41

あーあ

70 ：デフォルトの名無しさん：02/10/06 02:43

>>68
もしてかして、日○生命関係？

71 ：デフォルトの名無しさん：02/10/06 02:46

KE2

72 ：デフォルトの名無しさん：02/10/06 02:51

それがあなたの望んだ世界なのよ

73 ：デフォルトの名無しさん：02/10/06 05:05

>>68
Javaでなくても.NETの場合であっても同じなのでは？

74 ：：02/10/06 05:20

>>73
>>68のあれは、もとはといえばＶＢ時代の負の遺産だろうな。

75 ：デフォルトの名無しさん：02/10/06 10:33

COBOL要員が負の遺産になったように
Java要員は負の遺産になるんだろうな・・・

76 ：名無しさん＠Ｅｍａｃｓ：02/10/06 12:40

>>75
VB要員もね

77 ：デフォルトの名無しさん：02/10/06 12:51

Java要員って使い道無さそう。
あの程度で学習とまってるし、みょうちきりんなフレームワークを
ハシゴするだけでなにも成長してないし。

78 ：デフォルトの名無しさん：02/10/06 12:57

それでいてプライドだけは異様に高い。
流行の言葉には敏感だが中身は分かってない。
M$製品を使おうとすると露骨に嫌な顔をする。
それなのにWindowsしか使えない。(w

79 ：名無しさん＠Ｅｍａｃｓ：02/10/06 13:03

> M$製品を使おうとすると露骨に嫌な顔をする。
> それなのにWindowsしか使えない。(w

この2つがtrueになる人間は見た事がありませんが？

80 ：デフォルトの名無しさん：02/10/06 13:06

>>79
telnet経由でコンソールを使っただけでUNIXマスター気取りのヤシなんていっぱいいるぞ。

81 ：名無しさん＠Ｅｍａｃｓ：02/10/06 13:24

>>68, 73
上で命名規則作ってるやつがバカなんだよ。
俺もそんなんばっか見てきたけど。

パッケージ名
"ドメイン名を逆から"."プロジェクト名"."サブシステム名"."機能種類名"
クラス名
"サブシステム名"+"機能種類名"+"シーケンス番号"+"機能名"+"サフィックス"

サフィックスは、EJBのホームインターフェイスなら、Home、サーブレットなら
Servletなど。機能名は、もちろん日本語をローマ字にした物。

クラス名は作った奴さえ覚えてない("サブシステム名"+"機能種類名"
までしか、思い出せない)。
もちろん設計にはOOのかけらすら無い。

この手のプロジェクトは言語とは無関係に存在するだろう。

82 ：デフォルトの名無しさん：02/10/06 14:10

その点、日本語名が使えるVB最強！

Namespace 見積機能

　　Public Class 見積作成画面
　　　　Inherits System.Web.UI.Page

83 ：デフォルトの名無しさん：02/10/06 15:20

>>67
単に使い方知らないんでしょ?

84 ：デフォルトの名無しさん：02/10/06 15:22

つまんねえ煽りだな。

85 ：デフォルトの名無しさん：02/10/06 23:35

>>83氏ってることは全部使いたがる厨ﾊｹｰﾝ

86 ：デフォルトの名無しさん：02/10/07 09:33

EJB使っている奴の殆どが、「EJBを使う上での罠」を理解していないと、
効率的なEJBを作れないというのが、ｺﾏｯﾀﾓﾝﾀﾞね。
「J2EEパターン」なんてモノをつくらなければならなかったのは、
そもそも分散アプリケーションが持つ根本的な難しさを、ミドルで
完全に回避することはできないからだよね。

うちの馬鹿は、クライアントからの1トランザクションで25のリモート
EJBコールを行っていて、「遅いからチューニングして」となきついて
きた。当たり前だろバカ。すこしは基本を勉強しろよ･･･

87 ：デフォルトの名無しさん：02/10/07 09:45

CORBA/CCMを理解せずにEJBだの言ってるのはダメだろ。

そしてそれはおれのことなのさ～

88 ：デフォルトの名無しさん：02/10/07 12:31

>>68
俺もそんなんばっか。
でもPGとかにクラス名をつけさせると、
統一が取れないってものあるかな～。
クラス名の頭にパッケージ名がついてるのは
無駄だなーとは思うけど

89 ：デフォルトの名無しさん：02/10/14 18:40

JMSでEJBにMsg送りたい。どうすればいい？

90 ：デフォルトの名無しさん：02/10/14 21:08

>>89
EJBにもいろいろあるけど...

91 ：デフォルトの名無しさん：02/10/15 01:11

>>89
EJB2.0では、たしかメッセージドリブンなEJBってあるはずだよ。

92 ：　：02/10/15 01:16

>>1
く　だ　ら　ん

「秩序」＝「これまでどおり自分もよくわからない不要なものを売りつける商売を維持できる」

ということなら同意。

93 ：デフォルトの名無しさん：02/10/15 01:22

オブジェクト指向わかってないバカはいらない。
オブジェクト指向わかったつもりになってるバカもいらない。

virtualのないC++プログラムを作ってる君は
かなりのバカです。

javaでinterface使ってない君もかなりのバカです。

ポリモーフィズムぐらいわかってよね。

94 ：　：02/10/15 01:23

>>93
>virtualのないC++プログラムを作ってる君は
>かなりのバカです。
>javaでinterface使ってない君もかなりのバカです。
>ポリモーフィズムぐらいわかってよね。

君も最初から勉強しようよ。

95 ：デフォルトの名無しさん：02/10/15 01:42

>91
Drive = ドライブ
Driven = ドリブン？

91は、あほか？　

96 ：91じゃないが：02/10/15 02:00

>>95
Message-Driven Beanのことだろ？　あほか？ってのがわからん。

97 ：デフォルトの名無しさん：02/10/15 02:28

>>96
受信するコードは書けたけど。
どうやって送信するのか、文献が無いよー。
以上。

98 ：デフォルトの名無しさん：02/10/15 04:43

http://neverbird.sourceforge.jp/manual/fancy/ch08s32.html

99 ：91じゃないが：02/10/15 10:59

>>97
まずはスレ違いを正せ。

EJB(初心者歓迎）
http://pc3.2ch.net/test/read.cgi/tech/1017240849/l50

100 ：95：02/10/15 16:13

いままでずっと Message-Drive Bean (メッセージドライブビーン) だと
思い込んで喋ってきました。ショポーン。

101 ：デフォルトの名無しさん：02/10/15 16:34

>>100
マッサージドライバーイヤン

102 ：デフォルトの名無しさん：02/10/15 17:15

イベントドライブ。おべんとドライブ。
可愛い子におべんとを作ってきてもらってドライブ・・・してぇぇぇ！！

103 ：デフォルトの名無しさん：02/10/15 17:21

可愛くないけどとりあえずガマン

104 ：デフォルトの名無しさん：02/10/15 21:42

>>103
貴様！それは、おべんと作ってくれる女の子とドライブ出来るということなのか？

105 ：デフォルトの名無しさん：02/10/17 00:41

別にEJBだけがJ2EEじゃないからなー。
ServletにせよJTAにせよ、規格化されているってのは
やっぱり便利だよ。何使っても（概ね）同じコードで済むし。

106 ：デフォルトの名無しさん：02/10/21 23:02

HSP が最強です

107 ：デフォルトの名無しさん：02/10/21 23:29

クロスプラットフォームだしな＞H.S.P

108 ：デフォルトの名無しさん：02/10/29 18:52

Javaまんせー

109 ：デフォルトの名無しさん：02/10/29 20:08

「J2EEは，カスオの中に現れた新秩序」に見えたよ。

110 ：デフォルトの名無しさん：02/11/14 21:56

つまんねえ煽りだな。

111 ：デフォルトの名無しさん：02/11/15 01:25

>>110
この死にスレに命を与えたその「つまんねえ煽りだな。」に
お前のじょおねつを感じるYO！！

112 ：デフォルトの名無しさん：02/11/30 15:44

JMSでEJBにMsg送りたい。どうすればいい?

113 ：名無しさん＠Ｅｍａｃｓ：02/11/30 16:08

RMSがDJBにMsg送りたい。どうすればいい？

114 ：デフォルトの名無しさん：02/11/30 21:19

J2EEは，苦悩から生まれたはぐれ者

115 ：デフォルトの名無しさん：02/12/01 06:31

今日の朝ご飯はEJBとみそ汁ってお母さんが言ってた。
僕、EJBって苦手なんだよね。ほら、ちょっと苦いでしょ。
だからいつも砂糖をまぶして食べるんだ。

そういえば兄ちゃんが昨日J2EEを買ったんだ。
自慢げにJ2EEに乗って遊びにいっちゃった。
僕も12歳になったら買ってもらうんだぁ。

じゃぁね。