J2EEを語ろう

こんなサーブレット作ったぞと言ったような自慢、
こんなことをしたいんだがと言ったような希望、
〜は〜だといったような評価をするスレ。
ではどうぞ。

ｷﾀｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｰｯ

質問ですが、
J2EEを素早く習得するに当たって、お勧めの本を教えてください。

初めてjava使ってから1ヶ月でﾁｬｯﾄ作った漏れはどうよ？

J2SEとかJ2MEとかあるけど、あれはなに？

>>5
J2EE 早い話が、分散コンピューティングをするためにある。
エンタープライズコンピューティングをするためにある。動かすにはJ2SEが必要。

J2ME 携帯電話開発用。動かすにはJ2SEが必要。

J2SE　これがなければ話にならない。これがなければJavaプログラミングすることができない。

J2EEの中核をなす、もっとも重要な部分であるEnterpriseJavaBeansもよろしく。

EJB(初心者歓迎） ２
http://pc2.2ch.net/test/read.cgi/tech/1054357210/

　

J2SEが中核で、J2EEやJ2MEはそれの発展形(?)ということ？

>>3
翔泳社の『標準J2EEテクノロジー (2) 基礎から学ぶJSP/サーブレット』を俺は買った。
本は、その場で自分に分かりやすいやつを選んだほうがいいと思う。

>>4
天才やな！

Ｊ２ＥＥネタはマジでヤバいって。

>>9
J2SEﾀﾞｳｿして、サーバ関係なら次にJ2EEﾀﾞｳｿ。
携帯とか組み込み式関係だったらJ2MEﾀﾞｳｿ。
まぁ、それ以外はほとんどJ2SEでまかなえると。

>>11
やっぱり書くと思った。(w

>>12
なるほど。J2EEやJ2MEは拡張キットみたいなものなんだ。
じゃあJavaを勉強するだけならJ2SEだけでいいんだ。

>>11
ﾜﾗﾀ
どうﾔｳﾞｧｲと？

つかＪ２ＥＥ的スレ多くね？

>>14
ｿﾀﾞﾈ。

>>17
ありがとうございました。

>>16
>>1いわく、自慢や希望を書けと自己ﾏｿのスレなんだろ、ここ？

>>19
自己満か
ああ　そうさ、そのとおりさ。

今度、javaでサーバ関係のプログラムを書くアルバイトに行くことになったんだけど、
普通のjavaと違うところってなんですか？

>>15
アホアンチ自爆事件があったのよ。スレ大荒れ。

>>22
ﾜｻﾞﾜｻﾞｱﾘｶﾞﾄｩ

>>21
TCP/IPの知識も必要になる。

ありがとうございます。<<24
クグって、本買って独学していきます。

J2EE とかって、JavaScript とは全然違うんだな。
Web上のスクリプトしてた漏れはてっきり同じものだと（ｒｙ

>>26
JavaScriptは、
書き方は似てるかもしれないがJavaとは別物と良く耳にする。

>>26 >>27
技術評論社『パソコン用語辞典』　一部引用。
JavaScript[ｼﾞｬｳﾞｧｽｸﾘﾌﾟﾄ]
【言語】米国ネットスケープ社と米国SunSoft社が共同開発したスクリプト言語。
HTML文書中に"<script>"というタグを指定することにより直接書き込む。
名前にJavaとはついているが、Javaとの共通点は少なく、開発当初はLiveScriptといった。

ｯﾄｻ；

それって常識じゃないのか

>>22
> >>15
> アホアンチ自爆事件があったのよ。スレ大荒れ。
愚痴をはきたければこちらへどうぞ。

.net と J2ee
http://pc2.2ch.net/test/read.cgi/tech/1045399051/

>>26
とんでもないアフォだ。
ダウンロードしてから実行するものとサーバ側で実行してからダウンロードするものとの
区別がつかないとは。　

>>31
専門領域が違うだけなのに、自分の方が偉いと
勘違いしていませんか?

>>32 禿同
ま、専門分野以外は見えてこないのが当然だと思われ

J2EE と Java2 とどう違うのか教え（ｒｙ

レベル低っｗ

>>34 わからんが J2までは同じでは

J2EE=EJB と思っている香具師は多いだろ？
JSP, Servlet も J2EE だぞ。

>>34
J2SE = Java 2 Platform, Standard Edition (J2SE)
http://java.sun.com/j2se/index.html
J2EE = Java 2 Platform, Enterprise Edition (J2EE)
http://java.sun.com/j2ee/
J2ME = Java 2 Platform, Micro Edition (J2ME)
http://java.sun.com/j2me/

ってことで、みんなJava2！
J2SE 1.2以降、Java2と呼ぶようになった。

PerlとjavaどっちがCGIを書くのに適しているんだろう？

CGIの意味しってっか？

むぅ・・・レベル低っ

Perl=ﾒﾓﾘ消費大、java=あんまりﾒﾓﾘ食わない。
perl=効率が悪い,java=効率が良い。
ﾄ　漏れは、勝手に判断した。

>40 ｸｸﾞｯﾃﾐﾀﾖ
Common Gateway Interface
Webﾌﾞﾗｳｻﾞからの要求をｻｰﾊﾞが処理してHTMLなどの形式で返す仕組み自体のこと。
>41
ｽﾏｿ
>42
ｻﾝｸｽ

すさまじいレベルの低さだ

>42
まじで？

>>42
間違っちゃいないが正確でもない
単純に言えばJavaはメモリ食うよ。
たとえば、1リクエストを単純に処理するのみだったら
JavaよりPerlのほうがメモリ消費は少ない。
でも、同時に大量のトランザクションを処理するのだったら
Javaのほうが効率が良く、メモリ消費が少ない。
大量になればなるほどJavaのほうが有利。
同時処理の数が増えてもメモリをはじめとしたりソースの消費が
直接比例して増大しない。
Perlなんかだともろに増大するね。

JMS 1.1が試せる無償の環境ってまだないんでしょうか？

Ｊ２ＥＥとＥＪＢは別物？
それともＪ２ＥＥ⊃ＥＪＢ？

Ｊ２ＥＥってワカンネ。
サーブレットとかはそうなの？

J2EEは
Servlet,JSP,EJB,JNDI,JMS,JCA,JavaMail等を含む仕様・規格のこと。

>>1-50
やっぱＤＱＮ・ＪＡＶＡ厨は全員ＷＥＢｐｇ板に隔離すべきだな
みていて吐き気がするオェ〜!

JavaMailってJava製のメーラー？

>>52
この辺でも見ておけ
http://java.sun.com/products/javamail/FAQ.html

>>51
そういうオマエは何厨なのだ？

>>52
Java のメール API

じゃあそれを使えばJavaでメールサーバをつくれるんだ？

>>55 それがApache JAMESではないか。

J2EEスレとは思えないレベルの低さだ!!

>>55
つくれるよ

>>47に誰か答えられんのか(俺は知らん)

＞３９

わざわざjavaでCGIかく理由ってなんなんだ？
普通にservletとかjspとかでやったほうがいいと思うんだが.....

毎回毎回forkしなければいけない世界ならperlで書いたほうが早いと思うんだが、興味
あるなら実験してみたらどうよ？

ここでレベル低いとか吼えてる奴は、現実では文句ばっかり言ってて
何の生産物も生み出せないタイプなんだろ？

>>61
オマエモナー

昔、javaの起動コマンドを書き込んだシェルをCGIにしてみた事があった。
ほんとわれながら馬鹿だと思った。

このスレ見て思ったけど、
こんなに敷居高い言語なら技術者集まらないから使えないな。

>>64
だから、Servlet、JSPくらいならまだしも、
EJBやJMSが広まらない
規格も実装もこなれてないというのもあるけど

JavaBeansなんてふざけた名前のせいだろう。

分散オブジェクトという点ではEJBはとてもいいと思う。
CORBAよりもお手軽だし。
ただCMPやCMRまで使おうとすると苦労しそう。

ServletはCGI「みたいなもの」であってCGIではないだろうが。
それとも何か、>>39はシェルで
java Hello.class
とか書いて、それを呼び出すようにしたいのか？

>>68
Exception in thread "main" java.lang.NoClassDefFoundError: Hello/class

servlet=javaでのcgiという事で話を進めたほうが・・・。
俺の非力マシンで>>63と同じ子とやったけど、JVMが10個程度しか
立ち上がらなかった。
ほんと意味無し。

ああ悪かったよ、漏れが厨だよ（藁
java Hello
な。回線切って首吊って寝るわ

>>ﾚﾍﾞﾙが低い言う香具師
最初はなんでも簡単なとこからするもんさ。
public class MyFirstJava{
public static void main(String args[]){
System.out.println("モナー");
}
}

Perlだってmod_perlとか使うと、CGIオーバヘッドはかなり解消されるし
比較が「普通のCGIによるPerl」とServletではフェアではないと思われ。

>>73
正論だな。
厨は比較対照がしたいだけだろう。
気にすんな。

>>64言語の敷居は高くない。J2EEという規格の敷居が高いだけだ。
>>65必要性が低いからだろ。何でも使えばいいってもんじゃない。
>>67RMIでいいだろ。分散トランザクションまで含めて初めてEJBの価値がある。

>>73
CGI処理系の標準としてそういう動作が保証されてる訳ではないからね。
mod_perl も単なる Apache 拡張だし。

Servlet なら、Webコンテナの動作の標準にあるから、どの処理系でもスレッドで動く。

>>73
それだけ進化してたら
毎秒数千トランザクションのチケット販売サイトとかも
今ならPerlで実装できる？俺はJavaしか無いと決めてかかってたよ。

だからあれほどCGIにはRubyを使えと(ry

どうでもいいが、「普通のCGIによるPerl」は逆じゃないか？
「普通のPerlによるCGI」じゃないか？

>>76
>>39はそういう難しい話をしたいのではないと思うぞ（ｗ
そういう意味でCGIを書きたいというなら、
最初からJavaと比較するわけないだろうしな。
要するにHTML吐き出す処理のコードの書きやすさだろ。

それにしたってJavaでも色んなフレームワークあるし、
PerlでもCPAN行けば色々と便利なものがあるわけで、
好みとしか言いようがないと思うがどうよ。

漏れjavaでﾁｬｯﾄを作りたいんだけど、どんなことを学べばよいのでしょうか？
Linuxでapacheは立ち上げてあるから、プログラムを完成させるだけなんだよな。
ちなみに、J2EEもインストール済み。

>>77

mod_perlの何が「それだけ進化」なのかと(ry

ていうか、レベル引く杉。
WebLogicとかWebSphereとかふつうに使ってるやついないの?
WebProg板に逝っちゃってるのか?

ＣＯＲＢＡってなくなるんじゃないの？
仕様がでかすぎたとか使えないとかで
どうせ持ち上げてるのもうＳＵＮだけでしょ？

>>78
Rubyも良いﾅ。
漏れはRubyにﾆｹﾞﾙ。

>>83　そういう香具師が>>1を見てカキコするとは思えん（ｗ

perlで大規模なものを作ったことないから分からないが
javaの方がトランザクションの管理とかが楽な気がする
DBwrapperとかが用意されてればの話だが

クラスが継承できる分大規模なシステムでの構築に向いている
逆に対して規模の大きくないシステムであれば
perlやPHPの方が向いてるんじゃないかと思う

>>81
ソケット通信の勉強がいいんじゃないか？
そこに転がってるJ2EEってのは無駄に
なるかも知れんがな

>>88
ソケット通信ですね。
クグって勉強します。
ｱﾘｶﾞﾄｳ。

J2EEのターゲットは大企業向け基幹システム。
つまり、現行COBOLで組まれているレガシーシステムを
Javaで置き換える方向に持っていきたい、っていうのがSUNの思惑だと思われ。
だから、チャットとかそういうの作るためには仕様が重すぎる。
素直にPerlなりPHPなり使うべし。
単に勉強のためっていうのならばいいけどね。

>>87

そういうこと書くと、今度はシステム設計やる人間のレベルでとか
言い出す奴出てきそうだから、比較ネタはそろそろやめれ。

比較ネタはこちらへどうぞ↓

【Java PHP CGI mod_perl】の使い分け for プロ
http://pc2.2ch.net/test/read.cgi/php/1010257796/l50

そろそろ「J2EEを語ろう」ぜ。後恥ずかしいからageるの止めないか（ｗ

>>90
要するに、Javaは大げさってことよね

>>91
結構WebProg板に出入りしているつもりだが、そのスレ初めて見たぞ。

>>92ﾜﾗﾀ

ﾏｼﾞﾚｽするとJ2EEは確かに大げさだ。
Java自体は別に普通だよ。

>>90
COBOLで動いてるものを置き換えるつーのも結構無理あがるんじゃないの？
いやどうもjava=web系のアプリが多いし
自分がやった案件はweb系でもバッチはcとかが多かった(実行速度の問題等で)

基幹をjava系に置換しようとすると
メインフレームから離れちゃうわけだから企業としても勇気がいりそうだな

#IBMのメインフレームでlinuxが複数動くが日本であれを使ってる企業とか有るのかな？

>>95　だってメインフレームからSolarisに乗り換えさせるためのJ2EEなんだから（ｗ

要するにJ2EEを理解するには、
システム構築におけるサーバサイドの技術を理解していないとできないっつーこった。
サーバサイドの技術って分散オブジェクト、トランザクション、ネーミングサービス、非同期呼出、Web技術等。

まあServlet、JSPだけなら、CGI作れる程度のWeb技術＋Javaのコーディング技術があれば
できると思うが。
EJB、JMSやろうとすると上記のようなことを知らないとできないでしょう。

>>91
いやそんなに長く比較ネタを続けようとはおもわんけど（ｗ

>>96
そういう魂胆なんだ。

>>99　SunFire売りたいんだろ（ｗ

100ｹﾞﾄ？

>>95
時代的にはメインフレームは収束の方向だから、
J2EEはこれからの基幹に入っていくんでねーの?
現状は既存のメインフレームには手を入れずにWebのインタフェースを
くっつけるだけだろうけど。
＃Linuxはメインフレームと考え方が正反対な気がするんだが、ほんとに基幹に入っていくのか?

>>96
しかしSolaris上でWebSphereを使わせればIBMの逆転勝ち。

>>100
あのめちゃくちゃ格好いいやつか!!

>>96
> だってメインフレームからSolarisに乗り換えさせるためのJ2EEなんだから（ｗ

いやまあそうなんだけどさ
自分の仕事しているところとかでは
sunがメインのプロジェクトってみたことないからさ

sun自体が
「メインフレームからハイエンドUNIX機にリプレースしましょう！！」とか客に提案するならまだしも
かなり大きいところでもそんな冒険はしたくないんじゃないかなと

>>102
しかしというか、それが普通、という罠(w

>>101　LinuxもSolarisと同じくUNIX陣営だからな。素人から見れば。
>>102　SUNはハードが売れればそれでいいと思ってるに1000ペリカ。
>>103　あれは中に人間が入ってるんだ。ちゃんと食事入れてやってくれ。
>>104　まあ不景気だからな。

>>106
SunFireの中の人も大変だな

いや不景気っつーか
あそこら変まで行くとハード売って保守料とかでもうけたりする感じがあるから
sun自体がやらないと誰もがんばらないだろうね
ふつうのシステム屋がメインフレームを進めたりしないよね
結局ベンダーにもうけが行っちゃうから

日本ではその手の案件がないだけなのかもしれないが

いや、以外とSunの戦略は実を結びつつあるんじゃないかと
思う今日この頃。
最初はJDBC、Servlet、JSPあたりであんまり信頼性要求が
高くないWebシステムを大企業に導入させて、それなりの
実績作っている。その上で、次のステップとして基幹に
入り込もうとしている状況が今何じゃないかな。
とはいっても、現行のEJBの仕様じゃまだまだ先の話のような
気がするんだけどね・・・

何かすごい勢いでスレが伸びてるわけだが
>>11はある意味神だな（ｗ

>>106
こうやって大量レスかますのは
かまって君な >>1

こうやってレスして>>1を喜ばせてあげるのは
かまってあげたい君な>>110

もしや名ｽﾚ！？

>>112
なるかﾓﾅｰ

このスレいこごちいいな。

>>90
perlのチャットはあまりにもおせーよ。
Servlet + Appletで動くチャットサイコー

>>92
.NETも大げさだね

>>115
Perlだから遅いわけじゃないよ。UDP使えば何だって同程度にはなる。

それとな、Javaと比較するならC#だ。J2EEと.NETなら比較の対象だ。

.net と J2ee
http://pc2.2ch.net/test/read.cgi/tech/1045399051/l50

J2EEってどんなことができるんですか？

>>117
サーバーの膨大なリソースを使い果たすこと

>>117
ますこのスレと、このスレにリンクされたJ2EE関連スレを全部読み返してください。

ｻｰﾊﾞの無駄遣いって意味で？
それとも、有効利用って意味で？

>>120
だからスレを全部読んでから質問しろとってるだろ

>>120
ﾝｼﾞｬ全部ﾖﾑ。

J2EEは、乱暴な言い方をすると分散コンピューティングをするためにある、
とオライリーの本には書いてあった。

J2EEはなんのために、あるかというと
みんなが各地で勝手にJ2EEのような仕組みをつくらないようにするためだ。

J2EEの一番のメリットは、それが仕様だということ。
標準化されているというこれ以上のありがたみはないよ。
いろんなアプリケーションサーバーを使用しているとマジに思うよ。

アプサバ間の互換性はまったくないけど、J2EEという考え方があてはまるのはイイ！
互換性がないから作り直しがおおいけど、それでもイイ！

漏れは、ｹﾞｲﾂが嫌いじゃ。
だからsunに走るのみ！

>>126
正直、それは正しい選択かがなじょ

ｹﾞｲｼ嫌いは別にｶﾏﾜﾝｶ・・・ﾞ

javaの技術を追求して、
漏れが、ｽﾝの明日を切り開く！
俺について来い（ﾌﾟｯ

>>122
なんて素直なやつなんだ。偉いぞ。

>>122
みたいな奴が増えて欲しいもんだ・・・

口だけだろ。

>>131
なんて素直でないやつなんだ。酷いぞ。

>>132
思ったことを素直に口にしてるんじゃないか。

>>133そうか！なるほど！

>>131
なんて素直なやつなんだ。酷いぞ。

>>131
みたいな奴が増えて欲しくないもんだ…

　　　彡川川川三三三ﾐ〜
　　　川｜川／　　＼｜〜　ﾌﾟｩ〜ﾝ
　　‖｜‖　◎---◎｜〜 　　　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　川川‖　　　　3　　ヽ〜　　　　　　＜ (*´д｀*)ﾊｧﾊｧﾊｧ
　　川川　　　　∴）д（∴）〜 　　　　　 ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　川川　　　　　　〜　/〜　カタカタカタ
　　川川‖　　　　〜　/‖　＿＿＿＿＿
　川川川川＿＿＿／‖　 |　　|￣￣＼　＼ ←>>1-1000
　　　／　　　　　　　＼＿＿|　　|　　　　|￣￣|
　　/　　＼＿＿＿　　　 　 |　　|　　　　|＿＿|
　　|　＼　　　　　　|つ　　　|＿_|＿＿／　／
　 /　 　　￣￣　　|￣￣￣￣|　　〔￣￣〕
　｜　 　　　　　|￣

J2EEでもっとも簡単な分野といえばなんだと思う？

漏れはJSPだと思う。

JavaMail

JDBC

>>137
実装担当にとっては、EJBをインプリするのがいちばん簡単だろう。
設計担当には地獄だが。

仕事で作るときの難しさか。
習得や慣れるにはそうもいかないような・・・。
初心者は、他人が作ったものが信用できなくて、
どうなっているのかドキュメントやソースコードを見ようと必死に
解析するのでは？

＞ 初心者は、他人が作ったものが信用できなくて、
＞ どうなっているのかドキュメントやソースコードを見ようと必死に
＞解析するのでは？

よくあるね。
せっかく実装とインタフェース分けてるのに実装クラスを見たがったり。

>>142
ちょっとまて。それは初心者の特性なの？？？

おいらは良く、Jakartaのソースを読んで、変な場所があったらパッチ
提案してるけど…

>>143
それはあなたが初心者だということでは？

>>144
そうか、JakartaのCommiterは初心者なのね。ﾘｮｳｶｲ。

そりゃ初心者だな。確定。
次いってみよ〜

>>138
そのjavamailの使い方というかやり方はどこを探せばよいと？

>>147
そんぐらいぐぐれよな
http://java.sun.com/products/javamail/FAQ.html
http://java.sun.com/j2ee/1.3/docs/
http://java.sun.com/products/javamail/javamail-1_2.html

ぐぐるよりもsun.comの検索使った方がはやいとおもうけど。

interfaceを使っているからといってもオブジェクトの依存度が
低くなるとは限らない。
これは経験者なら痛いほどわかると思う。
それをモデリングする段階での完成度がモノをいうわけだが。
実装を見たがるのは仕方がない。

http://homepage.mac.com/hiroyuki44/jaz02.html

>>150
だね。抽象クラスのほうがよかったりね。

ここはデザインパターンやアーキテクチャパターンを学ぶしかないと。

J2EEぱたーんですか

J2EEパターンてのは、性能上の理由から行われる、ぶっちゃけマヌケモデリング
ですよ。

ValueObjectだのSessionFacadeだの、オブジェクト指向のあるべき姿から
はかけはなれてますが、分散オブジェクトで性能出すためにはしかたないん
ですよ。

>>153
君、EARレベルでのJ2EEアプリ書いたことないだろ？
各Tierにきちんとわけたアプリのデザインしたことないだろ？

SessionFacadeやValueObject（いまはTransferObjectっていう）は何も性能のためだけではないよ。
不必要な結合を減らすという意味では重要だよ。

J2EEとApacheは連携できるんですか？　

ここまで苦労するくらいなら、おとなしくTPモニタで
アプリケーション書いたほうがいいなあ。
苦労はたいしてかわらず、性能や信頼性はけた違い。
IMSとかCICSとかさ。
EJBがもうちょいこなれてからでいいよ。

>>155
J2EEとは仕様や規格を指す用語だが？
もしかしたらJ2EE RIのことか？

>>154
ウソツキ。少なくともValueObjectは便宜の一手段でしかないよ。
おいらは、性能要件によってはクライアント側にDelegateクラス
作って完全にラップしますよ。

>>157
J2EEサーバのことでは？
Tomcatになぞらえていってるんだろうよ。

>>159
J2EEサーバってなんだ？
J2EE RIのことか？
J2EE準拠のアプリサーバ製品全般のことを言っているのか？

>>155
EJBサーバとHTTPサーバは、直接は関係無いな。

ServletからEJB呼ぶのは、良くやることで、別にかまわない。

>>158
うそじゃないと思うけど・・・
ValueObjectは分散システムじゃなくても、Tier間や
サブシステム間で依存性を減らすのに有効な手段だよ。
オブジェクト指向的でないことは認めるけど、
オブジェクト指向のあるべき姿に向かって突き進むと、
大規模システムではクラス間の依存性が高すぎて
作業の分担ができないと思う。

>>162
依存性をなくしたいだけなら、Mapのインスタンスでも投げあってればええんでわ。

ValueObjectが有用なこと自体は言うまでも無いんだが。
シリアル通信の頃にも、オレ様プロトコルでメッセージフォーマットに従って
データ塊を投げ合っていたよ。通信コストの関係で。

通信コストのかからないローカルアプリケーションで階層化を行いたい場合に、
データ塊を投げ合うかと言えばそうじゃない。小さな単位でデータを交換しあう
のが普通だろ。dll間だって、class間だってそう。
関連性が密でないデータをまとめて送りあうなんて、通信コスト以外に何の
メリットがあるんだ？
疎結合を目指すなら、#163の言うようにmapを投げ合うしか無かろうが。

>>164
J2EEの開発で、Servlet,JSPを担当するチームと、
ビジネスロジックを担当するチームで分けたりすることはない？
そいうった感じでチーム間でインターフェースの取り決めを
する必要がある時に、小さい単位でデータの交換しあっていると、
インターフェースがやたら増えて、折衝が大変になるでしょ。
だから、インターフェースをなるべく少なくして、
一つのメソッドでなるべく多くのデータを渡したいことって
あると思うんだけど。
ビジネスロジック担当側で作った、複雑な階層構造を持った、
小さなオブジェクトをそのままServlet側に渡していたら、
インターフェースの変更の影響が大きすぎて収集がつかなくなるんじゃない?

あと、MapをやりとりするのとValueObjectをやりとりすることに、
そんなに差があるか?
Mapなら、確かにクライアント側が型を知らなくていいという
メリットはあるけど、KeyとValueをお互いで取り決めしとかなきゃならないし、
コンパイルによるチェックが入らないしで、
大変さはそれほどかわりないような気がするが。
変更が入ったら、どちらもリコンパイルしなきゃならんのは同じだし。

>>164
EJBでインターフェイス定義を配布しないのか？どんな開発してんだ？
それに、「インターフェイスの数を減らすため」に、余計なものも纏
めて送るなんて、まともじゃないぞ。
>>165
Mapでリコンパイルが必要になるってのはどういうことだ？

どうも、あんたの職場がカタワバカのにおいがするな。

>>167
何故にそう、煽り口調で話すのかね・・・
普通に議論できないの?まあ、いいや。2ちゃんだし。

>EJBでインターフェイス定義を配布しないのか？どんな開発してんだ？
そもそも分散システムじゃないときに、
ValueObjectが価値があるかどうかっていう話をしているわけで、
EJBを何故ここで持ち出すのかよく分からない。
多人数でシステム開発する時は、なるべくインターフェースが
少なくなるようにするのが鉄則だと思っていたんだけど、
あんたの職場では違うのか?他の人たちはどうよ?

あと、Mapでもリコンパイルが必要になるっていうのは勘違い。スマソ。
リコンパイル不要の場合もあるわな。
でも、普通Mapで渡すデータが変更されたら、
受け側のプログラムも変更しないといかんだろ。

XMLでやりゃあいいじゃん。

>>156
EJBはIMSやCICSより信頼性がけた違いに落ちるのか？
その程度のものなのか。。。

J2SEの間違いだろ？

半年前の沢村はJavaをあまり触ったことがないと聞いたが。

>>168
そんなこといったら、もっとも優秀なインターフェイスは

interface GeneralInterface{
Object invoke(Object target,Object[] param);
}

ってことか？
おいおい、見通しがよくなるのに必要なだけのインターフェイスを
作るのが鉄則ですよ。アプリケーション開発のレイヤーでこんな
インターフェイスしか定義していないプロジェクトがあったら、
設計者を張ったおすけどな。

>>173
「少なく」って漠然と書いてしまったから誤解されてしまったようですが、
俺が言っている、「インターフェースを少なく」っていうのは、
1個のユースケースについて1〜3個くらいのインターフェース、
くらいの意味合いです。
依存関係を減らすために一枚ファサードかまして、
クライアント側が直接Modelを操作しないよう、
やりとりするデータはValueObjectで値渡しにするっていうイメージ。
そういう意味で、ValueObjectもMapもXMLも、データのやりとりを
値渡しにして、依存関係を減らすと言う意味で、
あんまり違いを感じません。

>>174
だから、サーバーからクライアントにVOを投げるんじゃなくて、
クライアントにサーバのプロキシを置くという解決法もあるでし
ょがって前から言ってんだけど。IBMのDW逝ってBusinessDeleg
ateで検索掛けてくれ。

あと、VOを否定しているわけじゃ全然ない。「便宜」の仕様で
あって設計上の理想じゃないっていってるだけなんだが。

最近はValueObject(VO)じゃなくて、
DataTransferObject(DTO)って言うらしいけど、
いったい誰が定義してるんだろうね。

オブジェクトの内容が
Stringとかintの場合、
VOの変わりに、JMSでメッセージ駆動型Beanに処理してもらうやり方は
バカですか？
いまいち、どこでメッセージ駆動型Beanを使っていいのかわからないもので・・・

あぼーん

>>177
原因と結果に関連がないが、何でそんなことをするのだね。

>>175
読んでみたよ。ここであってる?
http://www-6.ibm.com/jp/developerworks/java/030110/j_j-ejb1022.html

で、BusinessDelegateパターンってメソッドの引数、戻り値に
VO使わないのですか?

>>180
最早データのキャッシュがクライアントにあるので、VOもヘッタクレ
もないでそ。プロキシ＜＞EJBサーバ間でVO使って通信しているかも
しれんが、そんなことはクライアントの知ったことじゃない(隠蔽され
ている)っていう構造だよん。

そういう構造になっていれば、クライアントサイドのプロキシが細粒度のアクセサ
持っていても何の問題もない。という話。
時と場合によってはいい方法だけど、時と場合によってはダメダメ。

>>181
うーん、ちょっと考えてみたのですけど、
VOを直にクライアントに渡して、そのアクセサ呼んでもらうのに比べて、
プロキシにアクセサもたすことにどういうメリットがあるのでしょうか。
教えてクンで申し訳ないが、もう少し教えてくらさい。

>>183
メリットは２つでしょう。
１．EJB開発者とServlet開発者を分けられる。
　プロキシにEJBの通信部分（lookup、RemoteExceptionの処理）を隠蔽することでクライアントは裏にEJBがあることを
　意識しなくて済む。下手するとEJBにアクセスせずにキャッシュデータを返却することも可能。
　（プロキシはEJB開発者が提供）

２．EJBが完成されなくても、プロキシをスタブとすることで試験が可能。

>>184
いや、質問の意図はそうではなくて、
BusinessDelegateを使用した場合、プロキシに定義するインターフェースと
してVOをそのまま返すメソッドを提供するのに比べて、
プロキシ内部にVOをキャッシュしておいて、
プロキシ自体に細かい粒度のアクセサを用意する
（>>182はそういう意味で捉えていたのだけど、間違っている？）
ことのメリットが何かを知りたいのです。

>>185
VOの存在を隠蔽できるのはメリットじゃないのかね。
毎回VOのサイズの、本来必要ないデータもくっついたカタマリデータを
毎回サーバから呼び出すより、好き勝手にキャッシュできる分効率いい
こともあるでしょ。

VOの場合は、そのVOが持つ値を何時まで使いまわすかは、クライアントの
実装者の責任になってまう。クライアントサイドプロキシなら、プロキシ
実装者(おそらくサーバーサイド実装者の責任範囲)がコントロールできるな。

>>186,187
うーん、それがメリットだと感じられるのが、俺にはどうしてもわからない。
どうせキャッシュしているのなら、VO丸ごと返した方が、
プロキシのインターフェースも少なくて済むし、
同じようなアクセサ（VOにも定義するよね）をあちこちに
書かなくても済むと思うんだけど。
あと、VOの値をいつまで使い回すかっていう話も、
プロキシが返すのが値のコピーである以上は、
プロキシ実装者がコントロールできるなんてことはありえないと
思うのだが。

といいつつも、なんか不毛な議論になりつつあるような気がするので、
面倒だったら答えなくていいよ。俺もそろそろ寝ます。

>プロキシが返すのが値のコピーである以上は、
>プロキシ実装者がコントロールできるなんてことはありえないと
>思うのだが。

IBM DWの記事をいろいろ読め。賢い人たちがいろいろ挑戦しとるがな。

>>189
はい、読んでみます。
質問につきあってくれてありがと。おやすみ。

よくよく考えると、なんか折れ他人のふんどしｵﾝﾘｰで偉そうだな。
鬱打詩嚢…

ｵｳｩ、J2EE系のアルバイトにまわされることになった（ﾂﾕﾀﾞｸ

J2SEとどう違うか教えてくれ、たのむ！

できれば、どんな本を買えばよいか教えてくれ！

漏れはjava暦は2ヶ月だ！大体の内容は把握してるつもりなんだー

>>192
J2EEはおおざっぱに言うとWebシステムを組むためのAPI群。
覚えるべきAPIや技術がたくさんある。
他言語でもWeb系のプログラム組んだことある？
無いとクッキーやHTTPの仕組みとかセッション管理の概念もわからないと思うから苦労するかも。
・Servlet
・JSP
・JavaBeans
・EJB（5種類ある）
・JavaMail
・JMS
・JAXP
・JCA
・JTA
・JNDI
標準技術だけをざっと挙げてもこんな感じ。
あとはJakartaプロジェクト関連のライブラリとか
アプリケーションサーバの製品固有の使い方とか

>>192
アルバイトとはいえ、そんな状態で仕事できるのか・・・
いや、煽りじゃなくて・・・
プログラマって意外といいかげんでも出来るんだろか・・・
助けてくれる人がいれば何とかなるのか・・・・
おれ、プロじゃないんでその辺のことわからんけどさ

なる

業界はアホであふれかえっている
実質、多少インテリな事務仕事

>>193
Web系のプログラムはRubyで組もうとしてた矢先だったんだ。
だからぜんぜん組んだことが無い。＜HTMLでHPならけっこう作った。
最初は教育をうけさせるって事になってるらしいけど・・
漏れは覚えが遅いから今のうちから努力を。
その単語を一つ一つくぐって把握していくことにする。
レスｻﾝｸｽ！
>>194
すまん、頑張りを期待されたなりゆきなんだ・・・。
基本情報とソフ開の資格はもってるから、基礎はあると認識されたんだろうな。
早く身に付けて役に立つ人材になってみせる。
>>195
なるべくｱﾎと呼ばれないように努力するよ。

なにげに192はいいやつ。教えて上げたくなるな。

>>197
「全然」（真田広之風に）

素直なﾔﾂは得すると思うぞ。
裏切られることもあるだろうが。

>>192
へっへっへっへ・・・

推薦図書スレで聞いたんですがレスがつかなかったので、
ここで重複質問させて下さい。

J2EEについて勉強しなくてはならなくなりました。
自分JAVAは一応結城浩のJava言語プログラミングレッスン上下を読了してます。
サーバサイドの基礎も無く非常に弱っております。
それくらいのレベルの人間がまぁがんばりながら勉強できるJ2EEの本て無いですか？
自分的には

何せタイトルに惹かれて
EJB・Servlet・JSP わかりやすいJ2EEのしくみ
http://www.amazon.co.jp/exec/obidos/ASIN/4883731650/qid=1055869791/sr=1-5/ref=sr_1_2_5/249-8553102-3707562

これが一番かなぁと思ってるんだけど、
某所でJSPから入るのが楽だと読んだので躊躇。EJBから入ってます。
J2EEチュートリアル??The Java series
http://www.amazon.co.jp/exec/obidos/ASIN/4894716917/qid=1055869791/sr=1-8/ref=sr_1_2_8/249-8553102-3707562

装丁がイカスってだけでこれも。
標準J2EEテクノロジー〈1〉基礎から学ぶEJB??Super Java Books
http://www.amazon.co.jp/exec/obidos/ASIN/4798103780/qid=1055869836/sr=1-19/ref=sr_1_2_19/249-8553102-3707562

の三点。
それとも
http://www.atmarkit.co.jp/fjava/rensai/index/index.html
ここら辺でことは足りるのでしょうか？ご教授願います。

192への援護射撃になるか？

>>192
>>201

難しいよなあ。

新人がJSPやServletの開発にまわされることも多いが、
それはフレームワークなり設計・開発手法のお膳立てが用意された上で作業ができるから。

Javaの範囲の効率化、Webアプリとしての効率化だけでもあらゆる手法がある。
Web層の範囲の効率化手法が、Web層＋EJB層をターゲットにした場合にはそれが使えないこともある。
またWeb経由サーバサイドアプリとしての設計手法も存在する。

勘所を分かっている人間ならば、最初からターゲットをもとにした設計や開発を行える。
しかし>>192や>>201のような感じなら、試行錯誤にならざるを得ない。

アサインされたのが勉強プロジェクト(=時間に余裕があってやり直しが効く)であることを祈る。
タイトなスケジュールであったり、事前の検証期間を確保できないような場合は……合掌でございます。
スレ上では応援するぞ。がんがれ。

まずは時間が許す限り濫読しろ。
あふれるくらいに知識を詰め込んで、実装作業で整理しろ。

そうこうしているうちに、J2EE 1.4の足音がヒタヒタと、、、。
勉強には切りがないね。

>>193-203ありがとうございます。
くぐりながら。
大まかな概要はわかってきた気がします。
あとは、>>201さんのお勧めの本を買って、
スキルを磨きつつアルバイトに備えることにします。
では、今から本屋へ。

>204
藻前ｲｲﾔﾂ
age

このスレいこごちいいな。

http://homepage.mac.com/hiroyuki44/

（＾＾）

　　　 (⌒V⌒)
　　　│ ＾ ＾ │＜これからも僕を応援して下さいね（＾＾）。
　　⊂|　　　　|つ
　　　（＿）（＿）　　　　　　　　　　　　　　　　　　　　　　山崎パン

PerlとjavaどっちがCGIを書くのに適しているんだろう?

>>210
CGIの目的によるんだと思う。
熟練したCプログラマなら、CでCGIを書くしね

>>210　なぜ>>39を蒸し返すのか（ｗ

J2EEのソースファイル(J2SEで言う所のsrc.zip)ってどこにあるの？
<J2EE_HOME>\lib\*.jarはクラスファイルばっかりだったし･･･。
Eclipseで宣言を開いた時にソース表示したくて調べています。

>213
J2EE1.3.1を使っています。

>213
jakartaにある
ttp://cvs.apache.org/builds/jakarta-servletapi-4/nightly/

>>215
それはServlet APIでは。。。

>>215
ｦｲｦｲ・・・

y=ｰ( ﾟдﾟ)･∵.　ﾀｰﾝ

>213
Sunのサイトのどこかにあるはずだ．
別途ダウンロードする必要があるはず．（経験あり）
探しまくれ．

>219
ありがとう。探してみます。

>219
ttp://java.sun.com/j2ee/sdk_1.3/faq.html#source
を見ると

Q5: When will the source code for the J2EE 1.3.1 SDK be available?
The source code for the J2EE SDK 1.3.1 is to be available soon after the J2EE SDK final release.

とあるが、これは以前の話で既に公開されている？
それとも219は別の版をダウンロードしたのかな？

>221
ごめんなさい。
1年以上前のドキュメントでした。
もう少し頑張って探してみます。

J2EE1.3.1のソースダウンロードできました。
219さんありがとう。

J2EEの方式の選択等が載っている書籍はなんかないですか？
J2EEパターンやEJBパターンをもう少しパワーアップさせたような、
Servlet、EJBの仕様やソースの説明等ではなく、
ＸＸＸＸの場合はEntityBeanではなく、
Servlet＋JavaBeans（JDBC）でやる等の説明が記述されているような本です。

>>224への自己レスです。
「実践J2EE システムデザイン」が良さそうですね。
私はまだ呼んだ事無いですが・・・・
どなたか読んだ方感想をいただければ幸いです。

>>225
読む価値のあるいい本だと思うけど、前提知識をある程度持っていないと
厳しい本。
ちなみに、訳はあまり良いほうでは無いと思う。
他に難点としては、高いことと物理的に重いこと。

>>225

まさに、

>ＸＸＸＸの場合はEntityBeanではなく、
>Servlet＋JavaBeans（JDBC）でやる等の説明が記述されている

ような本ですね。

ていうか、EntityBean使う気が失せる本というべきか。(^^;

>>226,>>227
回答ありがとうございます。
時間ができたら本屋で見てみることにします。

JBOSSを使おうかJ2EEをダウンロードして使おうか迷っているのですが
JBOSSにはJ2EEが丸ごと入っているんですか？

>>229
「J2EEとは」
から勉強してこい。

>>214
いや、
http://java.sun.com/j2ee/download.html
からダウンロードできるJ2EEとJBOSSどっちを使うかを迷っているんですが

ほっとぞぬのせいで
レス番号がずれている。
>>230へのレス　

>>231
紛らわしいから「J2EE」というのやめれ。
「J2EE」は仕様のことだ。
「J2EE RI」と家。

>>231
だから、まずは>>230のいうとおりにしろ

>>231
「J2EE」はソフトウェアではないのでダウンロードできません。
「J2EE」とは規格・仕様のことです。

広義のソフトウェアには、プロトコル、規格、仕様、マニュアル、ドキュメント等が含まれる

J2EE 1.4 Released
ttp://java.sun.com/j2ee/1.4/download-dr.html

こっちのほうがいいかな？
ttp://java.sun.com/j2ee/download.html

うちは「じぇいに」って略してます。

>>229
とりあえず、J2EE RI　は、

http://java.sun.com/j2ee/sdk_1.3/1.3_01/faq.html#licensing

を読めばわかると思うけど、
The J2EE SDK is free to you if you are using it for development only.

ということなんで、勉強とかのためだけに使うならかまわないんだろうけど、

If you need to deploy your application into a production environment,
you will need to use a J2EE compatible commercial application server.

つうことなんで、仕事でサーバを構築するとかなら、
JBoss を使うしかないと思います。

>>240
つまり研究目的にもオッケーということだね

J2EEはWS-Securityもろくにサポートしてないから糞だな。(ﾌﾟｯ
こんな糞でまともなウェブサービスなんか本当に作れると思ってるのか？(ﾌﾟﾌﾟﾌﾟ

セキュアでリライアブルなウェブサービスは現状では.NETしか選択肢がないね

>>243
その通り

いや、いくらなんでもそんなバレバレな。

J2EE1.4のウェブサービスでどうやってセキュリティを確立するんですか？
答えてください。

>>246
Java WSDPでも使え

つまりEA版レベルしかないということだな。
.NETの圧勝だな。

J2EEは永遠に.NETには勝てない。

本当にセキュリティ面でもJ2EEは.NETに勝てないの？

JSFなんてASP.NET以下だな。しかも今頃になって登場かよ。ﾀﾞｾｰw

>>246
繋がない。

ってか、「教えてください」じゃなくて、
「答えてください」かよ、偉そうなやつ。

>>250
http://www.atstake.com/research/reports/eval_ms_ibm/

>>251
まだEA版です。ASP.NETは2.0になってさらに先を行ってます。
Javaは時代遅れです。

>>253
Linux上で動かしただけのサンプルじゃJ2EEのセキュリティと全然関係ないやん

つーか、ASP.NETなんというおもりゃごときとJ2EEとをくらべられてもね。

JSFのどこがASP.NET対抗だよ。(ﾌﾟｯ
コーディングレスでコントロールが作れるのかよ？
デザインタイムビヘイビアを定義できるのかよ？
外部XMLがないと動かないなんて糞以下だな。(ﾌﾟﾌﾟ
欠陥言語で作られた中途半端な欠陥仕様に踊らされるなんて馬鹿以下だな。(ｹﾞﾗ

猿真似もできない倒産寸前の惨はもうだめぽ

JCPは公正な団体です。
惨の一言ですべてが決まります。www

そりゃあビル女医も辞めるわな。(ｷﾞｬﾊ

EJBは死にかけのCORBAを無理やり使ったせいで全然普及しなかった。www
ビジネスロジックと本来全く関係のないCORMA Marshalエラーで動きもしない。
惨の独断で技術が死んでしまった好例だな。

EJBQLなんて中途半端な糞使うくらいならSQL使った方がマシだよな。
こっちの方がはるかに標準だし。

SOAP Headerもまともに操作できないJAX-RPCなんてゴミ誰が使うんだ？(ﾌﾟﾌﾟ

test

このスレは.NETとは関係ないから.NETの話題はこっちでやれ。
.NETの話題でスレを荒らすなよクズども

.net と J2ee
http://pc2.2ch.net/test/read.cgi/tech/1045399051/

何といってもJAXPは仕様じゃなくてSunのXML実装だからな。(嘲笑激藁

.NETってJavaより優れてるの？

JAXP以外にJavaでXML使えるAPIを知らない馬鹿(>>266)がいるぞw

>>268
突っ込みどころはそこじゃないだろ。w
馬鹿な奴

.NETはすべてにおいてJavaより優れています。
その証拠に、このスレで書かれた.NETが優れている事実に誰も反論できていません。

M$信者の連続愚痴発言にたいする突っ込みどころはくさるほどあるけど

>>270
なんでキミはお経みたいに同じことをなんどもいうかねえw
精神的に病んでいるでしょチミw

.NETはWinFXでさらに進化します。
Javaはもうライバルでも何でもありません。
張り合ってた頃が懐かしいですね。

WinFXにIndigoで.NETのウェブサービスはさらに進化します。
Javaはどうやって対抗できるのでしょう？
それ以前にIBM + BEA組とSunの言い分が全く噛み合っていません。
どのWS-*仕様を採択するつもりなのでしょう。

あなたはそれでもJavaでウェブサービスをやるつもりですか？

ひとりでなにいってんだこいつ。
J2EEは糞だの.NETマンセーだの。
M$の工作員か

SOAP1.1しかサポートしていないJavaのウェブサービスなんて化石だな。(ﾌﾟﾌﾟﾌﾟ

具体的に.NETがJ2EEよりどう優れているかを説明できないようでは話になりません。

>>276
WSDLについてもっと勉強して来いや。
SOAPはIBMの社員が糞だっていっているらしいからなw

具体的にJ2EEが.NETよりどう優れているかを説明できないようでは話になりません。

WSDLについて解説してみろ。
できないだろうけどな。(ｷﾞｬﾊ

>>273
WinFXとJ2EEは比べられるももではありません。
GUIレベルのAPIだけ必死になっているだけで他はほとんどJ2EEには勝てません。
オープン系の選択肢としてどちらを選べばいいかと
J2EE vs. .NET　で張り合っていたころが懐かしいですね。

>>280
じゃ、先にSOAPについて解説してみろ。
できないだろうけどな。(ｷﾞｬﾊ

>>278
低脳なチミではSOAPの糞さが説明できないんだろ？(ﾌﾟﾌﾟﾌﾟﾌﾟ

>>281
WinFXはGUI APIではありませんよ。w
君ひょっとして初心者ﾌﾞﾋﾞ厨？(ｷﾞｬﾊ

Javaはやっぱり時代遅れだな

.NETは永遠にJ2EEには勝てない。

>>242
WS-Securityというものが何であるか説明してみろ。
できないだろうけどな。(ｷﾞｬﾊ

WinFXに対抗できる技術がJavaにはないね。
終わったな

>>283
低脳なチミではSOAPの糞さどころかWSDLの糞さも説明できないんだろ？(ﾌﾟﾌﾟﾌﾟﾌﾟ

J2EEに対抗できる技術がWinFXにはないね。
終わったな

アホアンチの鸚鵡返しが始まった。帰ろ

>>243
> セキュアでリライアブルなウェブサービスは現状では.NETしか選択肢がないね

で、その.NETの主要な機能がWindowsでしか使えないとはサーバOSとしては
セキュリティ脆弱で本末転倒というわけだが。

以下、アホアンチの電波(ﾌﾟｯ

↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓

過去の遺産を引きずっている.NETはやっぱり時代遅れだな

アホアンチがまたスレ荒らしてるな

>>261-262
ﾌﾟ　お前EJBで普通のSQL使えることを知らないわけじゃなかろうな。
EJBが流行らなかったなんていってるお前って赤っ恥ないているぞ(藁
現実をみろよw ハイエンド企業ではJ2EEは.NETよりも圧倒的に流行ってるぞ(藁

>>251
> JSFなんてASP.NET以下だな。しかも今頃になって登場かよ。ﾀﾞｾｰw
ﾌﾟ　お前はJSFしか知らないのか。
ASP.NETをやりすぎてWebデザインしか考えることしか能がなくなったDQNM$房か(ﾜﾗ

StrutsもVelocityもTapestryも知らない餓鬼だろお前　ﾌﾟ

独自のプロトコルに依存するSOAPはいずれ時代遅れになる運命だということを知らんとは
M$厨も恥の上塗りだなw

アホアンチって人、あまりJavaを知らないのでは？

何を今さら

思想なんてどうでも良い。
どっちも使って給料を稼ぐ俺の一人勝ち。

無職アホアンチの完敗ですね

サーバサイドはJavaの１人勝ちであることは明白。
M$厨うざい。

おまえらwebプログラム板でやれ。アホ

>>304
Webプログラムという言い方は負け惜しみですか？
いまやWebの向こうで動作する、
エンタープライズ・アプリケーションこそが主戦場ですが何か？

Ｍ＄厨はドットネットとやらでクライアントアプリを
シコシコ書いてろよ（ｗ

M$厨はASP.NET以外のスキルが無いんだろw
エンタープライズといっても何も答えたれない低脳だからw

わざわざJ2EEスレで.NETの話を持ち込もうとは
よほどJ2EEの人気っぷりが気になる見たいですな。

もうすぐ正月だぞ。


　　　　　／＼⌒ヽﾍﾟﾀﾝ
　　　 ／　 ／⌒)ﾉ ﾍﾟﾀﾝ
　 ∧＿∧ ＼ （(　∧＿∧
　（； ´Д｀））'　））（・∀・ ；）
　/　　⌒ノ　（ ⌒ヽ⊂⌒ヽ
.（O　　 ﾉ　)￣￣￣(）__ 　 ）
　）_）＿） （;;;;;;;;;;;;;;;;;;;）（＿（

その前にクリスマス

メリークリトリス

J2EEには先がない。特にWebService関連。

JavaはUNIXにとっては役立ったんじゃないの？
Windowsにとっては何もいいことなかったけどな。

>>311の詭弁を鵜呑みにするのもどうかと。

「WebServicesには.NETが(ry」とか言い出すんだろうけど。
.NETもSOAPがなきゃJ2EEよりも先が無いって。
SOAPの先がどこまでつづくやらね。

J2EEははSOAPがあっても.NETより先が無いけどな。(嘲笑激藁

は？
J2EEははSOAP?

ははSOAP？

>>314
具体的なソースは？　

J2EEは、マーケティング面では、極度に成功したプラットホームである。
なぜなら、各種業界の５０以上のベンダーからなる産業界全体が、
挙げてマーケティングに従事しているからである。
この独立した企業からなるネットワークは、
仮想的なマーケティングのマシーンを形成している。
そしてその結果J2EEに対するマーケットの感触は、
誠に素晴らしいものとなっている。

おまえらwebプログラム板でやれ。アホ

ばかじゃないのおまえらあ
氏ねぇぇぇぇぇ

>>318
Webプログラムという言い方は負け惜しみですか？
いまやWebの向こうで動作する、
エンタープライズ・アプリケーションこそが主戦場ですが何か？

Ｍ＄厨はドットネットとやらでクライアントアプリを
シコシコ書いてろよ（ｗ

お前らよJBossがJ2EE　RI同等の機能を有することにあと何年かかると思う？

>>321
んん？JBossに何が足りない？

JMXとか微妙に異なるだろ。
設定ファイルもJ2EEE RIなどと互換性がない。

J2EEとは具体的に何を指しているのでしょうか？

http://ash.jp/java/j2ee.htm
などを見ても
JSPとかサーブレットとかごちゃごちゃしてよく分からないのですが

逆に言えばJSPを勉強すれば自動的にJ2EEの一部を勉強することになるのでしょうか？

>>323
設定方法が違うと、同等の機能がないことになるのか？
設定ファイルの互換性が無い？どの設定ファイルだ？
J2EEの仕様で規定されている設定ファイルにも互換性がないのか？
J2EE仕様で規定されていない設定ファイルに互換性がないのはある意味当然なのだが？
よくわからん

>>324
JSP, Servlet, EJB, JMX, JDBC, JavaMail, JTX,・・・・etc ⊂ J2EE
ということで。

ＥＪＢ勉強したほうがJ2EEの一部を勉強した気になると思われ。
JSPだけではTomcatでもできるし。

>>326
ありがとうございます

つまり
クライアントとDBサーバを繋ぐミドルウェアの総称ってこと？
実際動かすのはEJBとかJSPとかであって
J2EE自体に具体的なものはないってこと？

どうもJSPなどを勉強してきても
J2EEとJ2EEじゃない区別がいまいちよく分かりません

>>325
まあ揚げ足取りなんかせず、
JBossとJ2EE RIには違いがあるんだから。

>>327

> つまり
> クライアントとDBサーバを繋ぐミドルウェアの総称ってこと？
それはJDBCやEJBの一部の機能です。

わからないなら実際にJ2EE RIをインスコしてみてはどうかなと。
それかJBossでも。


J2EEとはぶっちゃけ分散コンピューティングをするためにある、ともいうんだそうだ。
オライリーの「J2EEクイックリファレンス」にそう書いてある。

J2EEはCOBOLで作られたオープン系技術に変わる技術といわれている。

J2EEは後発の.NETと競合している。
が、現状ではJ2EEのほうが圧倒的に優勢。

>>328
違うこと＝同等の機能がない ではないでしょう？

>>327
＞ 実際動かすのはEJBとかJSPとかであって
＞ J2EE自体に具体的なものはないってこと？
うん、そんな感じ。
J2EEは、JSP、Servlet、EJB、JavaMail、JTA、JCA、etc・・・を含んだ
仕様・規格・アーキテクチャの総称。

＞ J2EEとJ2EEじゃない区別がいまいちよく分かりません
サーバーサイドのJava技術はほぼJ2EEに含まれていると考えていいんじゃないかな。
J2EEじゃないものは、SwingとかAWTとかJavaアプレットとか・・・・

>>1-331はうんこ。

j2eesdk-1_4-dr-windows-eval.exeをインストールしましたが
Developer ReleaseからはJ2SEも包含されているんですね？
「C:\Sun\AppServer\jdk」にJ2SEがインストールされたっぽいです。
ってことは、JAVA_HOMEは「C:\Sun\AppServer\jdk」でいいとして
J2EE_HOMEはどこに設定すればいいんでしょうか？
「C:\Sun\AppServer」かな？

J2EEの書籍はいろいろ読んでみましたが、J2EE1.4仕様の翻訳ってないものでしょうか?
とりあえず読みたいところだけ訳して公開したり。

>334
言い出しっぺの法則により>334がその仕事を責任を持って完遂すること

>>335
りょーかーぃ
しばらくひっそりやってみてたんですけどね。

JBossを語ればJ2EEを語ることにもなるんだな？

>>333
それ（"j2eesdk-1_4-dr-windows-eval.exe"）をダウンロードするSUNのサイトに、
包含されているものリストで「J2EE 1.4 SDK Samples」ってあるけど、Samplesって
どういうことよ？機能制限版ってこと？

>>338
サンプルアプリケーションだろ

J2EE用のリッチクライアント
http://www.nexaweb.co.jp/

　　　　　　　　　　　　　　 ∧＿∧
ｵﾂｶﾚﾁｬ━━━━━━━━（*^∀ﾟ　）━━━━━━ｿ!!!!!
　　　　　　　　　　　　　　/　　　　　ヽ
　　　　　　　　　　　　　/　人　　　＼＼ 　　彡
　　　　　　　　　　　⊂´_/　　）　　　ヽ__｀⊃
　　　　　　　　　　　　　　　　/　人　（
　　　　　　　　　　　　　　　（＿ﾉ （＿）

ttp://www.amazon.co.jp/exec/obidos/ASIN/0764558315

だって。

詳しいことは知らないがだれかがWebSphere用にパッチつくってないのか？

Tomcat5.0.27リリースage

人気無いねえ、J2EE。
難しい過ぎるのかなあ？

というより、J2EEとしてひとくくりに話す話題がない。
サーブレットJSPなら、それぞれの話題だし、EJBはそれはそれで、まぁそれ自体人気ないし。
JavaMailとかは、話すほどのネタもないし、JavaMailに関してJ2EEとして語るのもアレだ。

じゃあ、ここはDelphiスレとして再利用しよう

なんでやねん。
せめてVisualJ#

JBossかJakartaで分断されちゃってるし、日本はJBossは全然流行ってないし．．．

お寒い状況の原因は、

�@オブジェクト指向技術に習熟する前にデザインパターンが来てしまった。
しかも、デザインパターンは基礎的ものでなく複合タイプのJ2EEパターン。
なので着いていくのが厳しくなった。

�A殆どのドキュメントが英語なので水準以上の英語力が必要。

�B逃げ道としてマイクロソフトの.NETが用意されている。

こんな感じ？

>>349
っていうか、そもそもEJBが使えないってのが一番かと。
ここでJ2EEっていってるのは主にEJBのことだよね。

だからSpringだとか、Hibernateだとかが注目されるわけで。

>>350
アナタはすでに「J2EE Development Without EJB」を読んだ人ですか？

EJBも3.0になったら流行るかな

>>351
読んでねぇです・・・

ジェロニモできたら、使ってみるかな。
JBossは、フリーと言ってもサポートが必要になりかねない仕掛けが気に入らん。
実際、海外で本格的に使ってる連中は何らかのサポートを受けてるようだし．．．

サポートが必要になりかねない仕掛け
とはどういったことを指していらっしゃるのでしょうか？

EJBが必要なレベルの仕事と考えればTomcatレベルとは
サポートは必要になる可能性が段違いになるんじゃないの？

Tomcatだって情報がこれだけあるから扱いやすいわけで
新しいバージョンが出たばかりのときは誰だって多少苦労するだろう

大幅に人が増えて情報が飛び交いそうなEJB3待ちが正しそうだ

>>355
本当に知りたい情報が出てこないんじゃないかなあ。
JBossもサポートで稼いでる訳で、ヘビーに使い廻そうとすると何らかのサポートが必要になってもおかしくないね。

>>356
EJB3って何時でるのよ？
で、何が良いわけ？

weblogic のコンソール画面が立ち上がらないのですが、何かこういった現象をご存知の方、いらっしゃいますでしょうか？
ちゃんとデプロイはされているようです。（アプリはうごきました。
コンソール画面だけが動かないのです。

win xp pro + weblogic 8.1 sp3
win xp pro + weblogic 7.0 sp4
どの組み合わせでも動きません。今まで何台も設置してきたのですが
こんなことは初めてで、とても戸惑っております。
識者の方、よろしくお願いいたします。

それはBEAに電話したほうが早いと思われ。

>>359
windows　ｘｐのfirewallがポートを塞いでんじゃないのか？

firewall は切ってあります。
うーん、一晩眠っても解決策は思い当たらず。。。

なぜにデプロイは可能で、アプリは動くのに、コンソールだけは表示されないのか。
xx/console で、ログイン画面すらでてこない（"表示するページなし" になる）んですよ。

サポートしてもらえるのかなぁ。

なあ、J2EEって相互運用性ってある？

相互運用性がどういう意味で使われてるのかわかりませんが、
j2ee 準拠なサーバであれば同一モジュールが
どんなサーバ上であろうと動きます。

コンソールが動かない問題に関してです。

http://localhost:7001/ ←動く
http://localhost:7001/console ←動かない
https://localhost:7002/ ←動く
https://localhost:7002/console ←動く

よくよく調べてみると上記のようになっていることがわかりました。
SSL の方のコンソールでだましだまし使おうかな。。。

>>365
それはJ2EEとは関係ないだろ。製品付属のツールの話だ。

そのようなスレが見つからなかったため。
うっとおしい人には申し訳ないと言っておきます。

>367
消えうせろ。@ITででも聞け

付属ツールだとだめって、別にいいじゃないか。

weblogic社，ドンドン人が辞めてるね。

Javaバブルなんてとっくに弾けたからだろ

BEAってWebLogicに改名でもしたの?

アプリケーションサーバもコモディティ化が進んで儲けの種にならなくなってきたからなあ。
IBMみたいに周辺のツールからソリューションからで囲い込まないとやってけないか?

技術屋のオナニーはもうやめます、コンサル業に専念します
みたいな発表してたきがする

オプソが産業を崩壊させる好例。

産業は崩壊してない。
会社が崩壊しただけ。

IBMは一揃い持ってるからなあ
対抗できるのはMSぐらいか

IBMはEclipseとかオープンソース使った商売巧いよな
今度はCloudscapeだっけ

実はMSとやってることは一緒
ソース出してるかどうかだけで。
無料でばらまいて囲い込み

会社が崩壊⇒産業も崩壊
オプソ連中も、ソース公開は信念としていいとして、
せめて商売すればもうちっとはマシになるんだが

実質オプソ＝フリーソフト

なのが問題、
資金の流れを止めるようなシステムがあると、どんな産業でも崩壊してしまいます。

本屋と流通だけ儲かる悪寒

本屋が儲かるって嘘。目に見える範囲だけで書くなよ。

>>379
古い会社が崩壊して、新しい会社が興ってるだけ。
産業構造がかわってきただけ。

最近仕事で覚えなきゃいけないんだが
なんかわかりずらいよな。。。用語が多すぎて。
わざとわかりずらくしてるんかいな

servlet 内で設定ファイルのXML を読みに行きたいんですが、
コンテナ内にXML を入れた場合のアクセス方法がわかりません。
コンテナ外部のパス指定をした場合は読み込めるのですが、
相対パスにてコンテナ内を指定したいのです。
resourceBundle なら(jp.co.hoge.settings) とかで指定できるのですが、
ファイルを読み込む場合はどう指定すればよいのでしょうか？
/WEB-INF
--classes
----settings\xxx.xml
たとえばこの場合は？

>>384
http://java.sun.com/j2ee/sdk_1.3/ja/techdocs/api/javax/servlet/ServletContext.html#getRealPath(java.lang.String)

>>385
キミは優しいな。
>384の低レベルさでは後10回くらいはこの手のアフォな質問攻撃がありそうな予感。

>>385 レス感謝！
リンク先より
> .war アーカイブにより提供されている場合など、なんらかの理由でサーブレットコンテナが
> 仮想パスを実際のパスに変換できない場合、このメソッドは null を返します。

。。。war ファイルなのですが。。。
コンテキストルートからなどの相対パス等、そういった指定方法はないのでしょうか？

是非とも>>386 さんに教えてほしいなぁ。

つーかそのツリーがclassの下とすればクラスパスにいれてるほうがなんじゃね？

> ほうがなんじゃね？
？

classes の下です。
struts でもproperties ファイルはこの下にフォルダをほって配置しますよね。

ようはクラスパスからのリソース取得を勉強しろということだ
これはJ2EE以前の問題な

>>387
ClassLoader#getResourceAsStreamを使う。
＃これもFAQだねえ

いや、classes 配下のファイルは基本的に取りようがないんじゃないか？
htdocs の方は普通にコンテキストルートから指定できるが。
できるならおれも教えてほしい。

お前ら、よく考えて欲しい。
お前らがスレをageると俺のスレが一つ下がる。
これは何を意味するか？
お前らはスレをageるなということだ。

>>393
WEB-INF/classesはそのWebアプリケーションのローカルクラスパスに入ります。
Javadocよーく読んで、試してみてください。プロパティファイルを使うときの常套手段ですよ。

>>393
ｵｲｵｲ

おっぱいを取得したいのですが、どこを見ればいいですか？

>>397
ttp://www.kirei.com/QA/show/d199702150002.html

>>395
javadoc のどこに書いてあるのでしょうか？
ローカルクラスパスで具具っても数件しかひっかからないし。。。

>>399
ttp://www.jajakarta.org/tomcat/tomcat5.0/ja/docs/tomcat-docs/class-loader-howto.html
ほれ！

>>395
「Javadocに書いてある」のは、ClassLoader#getResourceAsStreamのことです。

>>400
それはjavadocとは言わんな。

>>401
自分に回答してどうする:-) >>399の間違いです。

ClassLoader#getResourceAsStream
がとる引数、つまりパスの記述方法がわからんのだろうな。あはは。

私もこれ、わからないんですけど、どういう書き方をすれば取得できるのでしょう？

>>405
WEB-INF/classesに置いたファイルをリソースとして取得するのであれば、
WEB-INF/classes以下にあるクラスからなら、

InputStream stream = getClass().getClassLoader().getResourceAsStream("ファイル名");

で取得できます。

WebLogicとかにデータソースを定義してDBにアクセスする場合、
JTAを使うのとJDBCドライバのローカルトランザクション使うのって、
性能は結構違うものなのでしょうか？

あと、EJBを使わずサーブレット上からWebLogig上のデータソースを使う場合、
JTAを使わずJDBCのローカルトランザクションを使うのってありなのかな？

大阪（西梅田）、新宿（JR駅前）のそれぞれ一等地に
拠点を構えるソフトウェア開発会社
グリーンシステムを応援するＨＰです。
http://www.geocities.jp/grs_hp/

こちらのスレの住人のかたがたのようなレベルの高いかたに
ピッタリだと思いますので、是非一度ご覧下さい。

JSTL使ってるかい。

うん。
ふつう。

EJBはよほどの理由が無い限りは使うべきではない。
そんな言葉を何かの本で見たんだが・・・。

>>411
男は黙ってスクリプレットだ。
タグライブラリは、もはやJavaではない。完全に別言語だ。
あれを有難がってちゃ、Javaプログラマとしての成長は望めない。
HTMLとJavaコードの複雑な絡み合いを、瞬時に読み取る技能は大切だ。
ゆとり教育みたいに読解力がなくなる。

>>414
ネタなのかマジレスなのかわからん・・・

>>413
J2EE 5.0を待ちましょう。

>>414
男はだまって、java.net.SocketでWebアプリケーション構築だよ。
サーブレットなんかを有難がってちゃ、Javaプログラマとしての成長は望めない。
HTTPプロトコルとJavaコードの複雑な絡み合いを、瞬時に書き表す技能は大切だ。
ゆとり教育みたいに実装力がなくなる。

>>414
とてもわかるぞ。おまえの言ってる事。オレは。

JDBCで1万件とか全件取得のSQL書いて、カーソル回して10件だけ
取得したときってメモリ消費量は10件だけだと思ってるんですが、
これで問題が出るケースってありますか？

>>418
メモリの使い方とかDBの種類によって動作は異なるだろうね
できるものであれば10件を意識して絞ったりしたほうがいい

通常はフェッチサイズ単位で取得されるからクライアントは問題にならないだろうけどね

>>418
ま*と*もなDBなら大丈夫と思われ。

>>419-420
サンクス！前から結構疑問だったんでスッキリしました。
DBサーバの負荷はDBの出来次第。
クライアントはJDBCドライバがまともならメモリ食わない。
ということに自分の中で解決しておきます。
limitの書式がDBによって違うのってウザいよなぁ･･･。

>>421
前にPostgreSQLのlibpqのソース見たときびっくりしたもん。
普通に結果セット取って来ようとすると、二次元配列的な
感じで全部メモリにがばっと確保してた。

JDBCドライバもそんな作りっぽかったけど、あんまり
憶えてないや。今はどうなってるんだろ？

お行儀のよいJDBCドライバだとResultSet回した時に、
Statement#getFetchSize()の単位で取得してくんだろうね。

J2EEとあんま関係ないんでスレ違いですな。

JDBCでもオプショナルパッケージはJ2EE

JNDIって単体テストでジャマじゃね？
使っていいことひとつもない。

>>424
「JUnit in Action」 嫁。

>>425
高いよあの本。

上の人に「J2EEでの業務に入ってくれ」と言われたけど
おいらはTomcat+J2SE(Ver1.4.0)でしかServletを作ったことが無いんだけど
そんなおいらでも大丈夫かな？((((；ﾟДﾟ))))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ


因みにJ2EEと
Eclipsのイントラマートのプラグインを併用するそうだ

↑失礼、「上の人」っていうより先輩でした。
失礼をば・・・

TomcatってJ2EEの部分的なリファレンス実装だぞ

>>427
ServletとEJBの違いが分かっている君なら、何を勉強したらいいのか知っているだろうから
安心して頼めるんだろうと思う

J2EEで、って言ってる時点でたいしたことがない罠。
サーブレットでメール送信とかやった時点で、J2EEのメジャーな部分はかなり使ってるわけで。

俺なんかJDBCも使っちゃてるぞ

普通に使ってるJDBCはJ2SEなわけで。

ど素人で未経験の俺が4月からJ2EEの開発の案件に携わることになったのだが、
何を勉強したらいいのかさぱーり分かりません。
JSP/サーブレット/Bean + Eclipseで簡単なプログラムなら作れます。
JSTL/EJB/デザインパターン/WebSphereなどの知識は全くありません。
ELとかJSTLとか最近勉強してるのだが、する意味ないだろうか・・・。
↑何から手をつけたらいいか誰か教えてくらさい。

あと、struts/Antとかさぱーりなのですが、そっちの勉強が先でしょうか？

JSTLとかELとかは、使えて当たり前なので、案件で使ってなくてもやっとけ。難しいもんでもないし。
デザインパターンは、Web開発の末端でわざわざ使うようなパターンはないし、あとまわし。
EJBは案件で使ってないならわざわざ勉強するものでもない。EJB3を待て。
Strutsは変に気合入れず、入力チェックのためのもんだと思ってその程度やっておけばOK。
Antは気が向いたら。

まずは、その案件がどんな技術を使ってるのか勉強しろ。

>>436
ありがとうございます。
まずJSTL、ELからすることにします。

>EJBは案件で使ってないならわざわざ勉強するものでもない。
EJB3を待て。
今は勉強しない方がよいのですね。

何度も聞いて申し訳ないのですが、あとCVSとかHibernate
とかってどうなんでしょうか？それが何かもよく分かっていないのですが。
勉強しておくべきですか？

4月まで時間があるので、有効に使いたいんです。

CVSは、プロジェクトに入って使い方聞くだけでOK。
Hibernateは、余力があれば。
JSTL+EL→Struts→Ant+XDoclet→Hibernate→Spring→そのころ正式版のEJB3
のパスがお勧めかなぁ。

>>438
おぉっ。丁寧にありがとうございます。
何をしたらいいのか分からず悩んでたので嬉しいです。
JSTL+EL→Struts→Ant+XDoclet→Hibernate→Spring→そのころ正式版のEJB3
の予定で勉強してみます。

>>439
おい、その前にその案件の方式がある程度決まってないのか？
ひととおり勉強するのはいいけど、そこで使う技術は最低限必要だろ。

開発未経験で就職したもので、もちろん小さな規模の案件だと
思いますが、上に聞いたところ、J2EE関係とできればWebSphere
とかを勉強しておくよう言われたんです。
その案件、EJBは使ってないようなんですが、J2EEって言われても
幅広くて何から手をつけていいか分からなかったもので・・・。
案件の方式・・・そうですよね。聞いてみます。

J2EE関係という時点で、その「上」はJ2EEが何かをわかってない。
そのわかってない「上」にやれてるってことは単なるサーブレット/JSPである確率が高い。
使っててStrutsか。

良くSUNでリリースしている
J2EEのAPI見ていたら
Tomcatでお馴染みのパッケージ群が有るから
すんなり上手く行きそうな感じがする。

って事は、J2EEでもServretは作れるって事で桶？

＞J2EEでもServretは作れるって事で桶？

「J2EE」がなんだかよくわかってない発言だな。
「J2EE」というソフトウェアやモノがあるわけじゃない。
「J2EE」という仕様があるだけだ。Tomcatは、J2EE仕様の一部である、
Servlet仕様やJSP仕様の実装だ。

というか、各種APIのバージョンをそろえるためにできたのがJ2EE

>>445
なんだ、それ？
とも思ったが、少しなるほどとも思った。

>>443
Sun の J2EE RI は本番で使うなよ。

>>446
J2EEは、各社まちまちだった各機能のバージョンの、最低限サポートするものをまとめることで、サーバーの比較・移行をやりやすくするために決められた

混乱させるかもしらんが、Servlet開発するんでも
J2EE SDKは必要ない。俺はSEでやってる。

９９％の人はJ2EESDKいれてないとおもわれ

CosminexusではじめてJ2EEに触ったよ
トラウマです

運び屋　あ

どっちを買えばいいか悩むぜ！！！
おまいら的にどっちがお勧め？
サーブレット/JSP+DBをちょこっとかじったことがあって、Webアプリ特有の設計を出来るようにしたいなと


実践J2EEシステムデザイン
ロッド・ジョンソン (著)
ttp://www.amazon.co.jp/exec/obidos/ASIN/4797322888/qid=1117122004/sr=1-4/ref=sr_1_10_4/249-3461948-7557963


J2EEパターン―明暗を分ける設計の戦略
ディーパック・アラー (著)
ttp://www.amazon.co.jp/exec/obidos/ASIN/4894714345/qid=1117122004/sr=1-5/ref=sr_1_10_5/249-3461948-7557963
※第２版が出ている

あのなぁ、案件も判らずに答えられるワケねぇだろ、タコ。

両方買いまショウ！

>>454
案件なんて無いよ
ただJ2EEを勉強しようとおもっただけ

>>456
LightWeightJavaがおすすめ。

>>457
あれってSpringとかのフレームワークでしょ
それはまだいいや

>>458
選ぶ本といい　あんた時代遅れですよ
EJB3.0からDIの思想が取り入れられる
JSFもJavaの標準仕様だし457の言うこと聞いとけ
俺も1ヶ月前に買った
最初は軟派な本だと思いつつ買ってみたら結構いけるではないか

>>459
そんな言い方されると状況説明をして弁解する気も起きないな

すまん、しかし本音だ

そうですか
そこまで言われると気になってしまいますね
両方買ってみます
J2EEのスタンダードなところが知りたかったもので、HibernateだのSpringは後回しでいいかなって思ってたから

>>453 は人の10歩後を歩いて、レガシー厨と罵られるタイプ。

>>462
J2EEというかEJB2は手順がめんどくさすぎで流行らなかったからね。
そこらへんのことがSpring+Hibernateやってみればよくわかる。
それでもEJB2やりたいなら、NetBeans4.1がおすすめ。英語版だけど。

そうなんだ。
けど実務で使うわけじゃないんだよなぁ。
大学でWebアプリの実習があるだけで、MVCモデルとかを意識した設計が出来るようになりたいってだけだから。
それにJ2EEの基礎をやってからSpring+Hibernateって感じがあったし。
EJB2が流行らなかったとか、もうその時点でわかんね。そんな風になってんのね。

さらに、EJB2のときの「MVCモデルを意識した設計」が流行ってないんだよね。

>>466
え！？嘘！？そうなの！？
これは相当ショックですよ。
ってことはStrutsも駄目になってきているんだ？かなり興味出てきましたよ。
うーん、そうなってくると実践J2EEって結構痛い出費だなぁ。
もっと安くてJ2EEがわかる本を探すか・・・。
あとLight weight Javaは絶対買うわ、かなりよさげだね。

いや、StrutsはEJB2のときの「MVCモデル2」とは全然関係なくて、ただ入力値をBeanに格納してくれるだけだから。
そう割り切ってMVCとか言わずに使う分には、便利だし悪くないと思う。

単純にEJBは敷居が高かったのだと思う
Javaそこそこできる奴でも「EJBはちょっと知りません」とかいって、
結局プロジェクトに導入されなかったり
「別にEJBじゃなくていいじゃん」というプロジェクトばっかりだったし
大手企業の基幹システム作ったときにメッセージ駆動型Beanを使ったぐらいかな

しかし自宅でやってたJBoss2.4+Tomcat3+MySQLでのEJBの勉強は
今の開発にも役に立っているので無意味だとも言い切れない
特にトランザクションの考え方など

Light weight Javaに関しては最後のJMeterの解説がイイ
あれだけ使い方詳しく書いてある書籍はなかったように思うし
今後、積極的に利用しようという気になる

なんとなくピントがずれてる人だな

>>469
JBossの勉強は何使った？

>>471
何ってJBossだけど・・・
本のことか？
ttp://www.amazon.co.jp/exec/obidos/ASIN/4774117498/qid=1117285645/sr=1-2/ref=sr_1_10_2/250-7349066-6756209
ttp://www.amazon.co.jp/exec/obidos/ASIN/4822280969/qid=1117285673/sr=1-3/ref=sr_1_10_3/250-7349066-6756209
ttp://www.amazon.co.jp/exec/obidos/ASIN/4774117226/qid=1117285673/sr=1-6/ref=sr_1_10_6/250-7349066-6756209
↑DB複合キー使うときのBeanの書き方に誤りがあるっぽい

あと、SunのJ2EEの日本語の仕様書PDFを紙に印刷して読んでたりとか

あのさ、MVCモデルに基づいた設計をやっていて、
JSP 1.2を使ってて、JSTLなんて使わなくて、
JavaBeansの作り方や設計のコツとか、なんかもう超わかりやすいサーバサイドの入門書って無いかな？

MVCとかJSP1.2とかJSTL使わないとか、設計のコツが必要なJavaBeans使ってて超わかりやすくなるわけもなく、時代遅れな本はない。

でもシンプルにしたほうがいいってのもあるからなぁ

>>474
そうなのかぁ
古い書籍を漁ってくるか

MVCはモデルが重くなりすぎてシンプルじゃないからね。
処理は層を分けて、プロパティだけを持つJavaBeansで値を受け渡すようにするほうが、ほとんどの場合シンプルにできる。

>>473
単なるJSP入門書みたいなのって、そんなのじゃない？
スクリプトレットかきまくりで、「太郎」と打ち込んだら「こんにちは。太郎さん。」と表示されるとか。

MVCモデルに基づいているってどの程度の話？　ビーン使ってりゃいいのか？
Servlet使ってもいいのか？

>>472
JBoss入門くらいしか無いんだね
近々海外で作ったシステムのバージョンアップの仕事するんだけどJBossなんだよなあ
これで英語まみれは決定的だな、鬱．．．

>>473

JSFでアプリ作る。
それをStrutsに移植してみる。
さらにServlet+JSPのみに移植してみる。

JSP 2.0ならELも使えるし、業務系みたいな行編集のないアプリ
(入力ボックスと次へ程度の奴)なら簡単に移植を試せる。

StrutsのActionはJSFのactionListenerとactionが混ざったもの、
Backing BeanなんてServlet+JSPな環境でもほとんどそのまま
使うことができる。そんな逆な方法で覚えて行くのもいいかもね。

業務系のほうが操作うるさいと思われ
参照が多いのならいいが、入力系では正直WEBを使うこと自体話しにならんのだがね

ここにも頭悪いのが来てるな

>>481
そんなあなたにリッチクライアント

>>429
つーかそも、そもその頃の本ではいまのJBossには対応できんだろね

Domain StoreをHibernateでやったことある人いる？

NECがJBossなど4社と提携、オープンソースのサポート拡充
http://www.atmarkit.co.jp/news/200506/01/nec.html

あのさーhibernate使ったときってDAOがhibernateになんのかな。

>>487
違う。DAOは基本的には自分で作るもの。（自動生成するツールもあるが）
Hibernateが何なのか、どう使うのか全くわかってない発言だな。

DAOがわかってないだけ、というか、DAOの定義が違うだけに見えるけど。

JBoss、EJB 3.0対応の「JBoss Application Server 4」などを発表
ttp://headlines.yahoo.co.jp/hl?a=20050622-00000007-cnet-sci

したら、 >>488 サンの定義に合わせるとして、488サンはDAOにビジネスロジックを入れる?
DAOと別にビジネスロジック用Serviceクラス作るとしたらDAOはhibernate呼ぶだけのクラスにならない?
BissunessDelegete よりはマシだけど処理を委譲するだけの層のよーな。

>>491 基本的にはその通り。
DAOとは別にビジネスロジックを実装するServiceクラスを作る。
Hibernate固有のAPIはDAOでカプセル化。
ビジネスロジックからはHiberanteかどうかは意識しないように作る。

>>492
そしたら、DAO層の意味は?トランザクション管理?
ストラテジパターンでOracleでもmysqlでも切り替え可能にしたぜってのはHibernateが実現するだろうし、実際あんま意味ないし。
ORMを切り替え可能にする?後でアスペクト入れ込むための保険?

>>493
ORMうんぬんを二回書いて変な文章になってしまった。ごめんなさい。

英語の綴りもろくに書けないのがのたくってるな

>>493
トランザクション管理はServiceレイヤーだ。

ServiceクラスとDAOクラスは
SessionBeanとEntityBeanのHomeオブジェクトの関係だよ。

>>493
サンクス。
dao = DAO.create();
って感じか。ってことはファクトリ?springとか使えば消してもOKな層になるのかな･･･。
でも実務やweb上で見てきたDAOたちはみなselect(),insert()とかCRUDな感じだったので
更にわからん。J2EEパターン本読んで出直した方がいいですか俺?
ってか最近のDIコンテナ+ORMにしたときのモアベターな設計パターンを知りたいのに
EJB系の視点のJ2EEパターン本読んで参考になるかな･･･

>>497
うーん、チョット勘違い入っている感が否めないのだが・・

DIコンテナ+ORMだったらこの2冊を併せて読むことをおすすめする
「Light weight Java―JSF/Hibernate/SpringによるフレームワークでWebアプリケーションの開発効率向上」
http://www.amazon.co.jp/exec/obidos/ASIN/4839917779/
「Java・J2EE・オープンソース Spring入門 ~より良いWebアプリケーションの設計と実装」
http://www.amazon.co.jp/exec/obidos/ASIN/4774123412/

J2EEでもEoD - EJB 3.0対応JBoss、JavaOneにあわせて登場へ
http://pcweb.mycom.co.jp/news/2005/06/23/016.html

>>499
AnnotationでDIってのは頂けないなぁ〜。
ソース直さなきゃいけないんでしょ？

>>500
構わんと思うが。

本番のソースは、コメントすらそう簡単には直せないよ

いやな職場だね。

>>502
ソースのコメントは直せなくて、XMLなら直していいのか？

相変わらずレベル低いのが粘着してるな

>>500とかね。

うん。あと>>501, >>503 とか。

ようするに、>>507のことだね。
つっこみが入ったらレベルが低いのに粘着されてることにすれば、人生楽だろう。

深夜にこっそり減らず口を叩くバカ。
哀れだな

>>500
　>>504
以上

つまり、XMLなら自社の規約から逃れて自由に編集できるのに、Annotationでソースに埋め込まれると編集できなくなるから困るってことか。

相変わらずバカすぎ。
業界知識０の解答が、あまりに悲惨

答えに窮してわめいてるようにしか見えないのが悲惨だな。

バカが一人前のため口を聞くな。

おまえのバカさ加減は
「自社の規約から逃れて自由に編集できる」
という言葉に集約されている。

それは企業のローカルルールなどではなく、
基幹システム全般の運用ルールだという事に気付け。

ついでに言っとくと、設定をXMLファイルに外出しした場合でも、
運用中に勝手にXMLファイルを変更するような事は、
通常の運用ルールでは禁止するのが妥当である。

それでは、ソース変更と、設定ファイル変更の相違は何か？

ソース変更であれば、ほとんどの場合開発グループに修正依頼をし、再テストを実施する必要があるので、
些細な変更に莫大な工数がかかる。

設定ファイル変更の場合、設定ファイルとソースの分離が適切かつ安全に行われていれば、
運用グループだけで対応できる可能性が高い。すなわち、工数, コスト, 期間的に有利である。

業界知識０の粘着素人のために、もう一つ言っておくと、
設定ファイル変更の場合でも、テストを省略できるわけではない。

粘着素人相手に説明するのは、本当に手数がかかって大変だ。

まあどうせここに粘着してるバカは、
>>514-516読んで一つ賢くなったと勘違いして、
他のスレで >>514-516を金科玉条のごとく強弁し始めるであろうことは、
想像に難くない。

こいつは煽って解答引き出して、それを他所で煽りの材料にする常習犯だからな。

結局、自分とこの体制のゆがみの話をしてるだけでしょ。
うちは内容が同じでも.javaと.xmlを編集するときに手間がこれだけ違いますよ、っていうだけの話。
.xmlにJavaソース書いて実行時にクラスファイル生成する仕組みがあれば、運用チームだけでできる作業が増えていいね

EJB3のアノテーション部分が外だしになってても、その部分に変更がある場合は運用グループで対応できるとは思わんが。

>>518
なんだ、ふつーの企業の体制を知らないっつう事は
趣味か零細企業でサーバやってる人か。
なんか可哀想になってきた。

>>519
おれもﾜﾗﾀ

>>519
きっと脳内企業で脳内サーバを運用してる脳内オペレータじゃないか？
俺の所に>>518みたいなのが来たら、さっさとペナルティを課して追い出す

>>518 結局、自分とこの体制のゆがみの話をしてるだけでしょ。

ﾜﾗﾀ。俺の知っている範囲では、国内大手メーカ、外資大手メーカは大抵どこでもそうだな。
IBMとは基礎研のプロトタイプ・レベル製品の導入〜試行運用しかやったことないから、
まぁその範囲では例外的に設定変更/ハードウェア交換の嵐だったけど（ｗ

.xmlに書いてあれば「設定」で.javaに書いてあれば「プログラム」なんだね。
で、xmlなら運用グループが触れて、.javaなら開発グループがさわる。
.xmlに書く内容が多い方が運用グループの権限が増えてｳﾏｰ

あほらし。
自分のところがふつーで自分のところがやってることを金科玉条のごとく強弁してるだけにしか見えんが。

EJB3のアノテーションは、DIのxmlファイルから、運用グループがさわるべき「設定」と開発グループがさわるべき「プログラム」をわけてくれるようにも見えるんだがな。

アンタは、DIやAnnotationを最近知って、その知識を他人に自慢したくてしょうがない厨房だろ？
本当に哀れな奴だ

>>522
大手がやってれば正しいって判断基準なのね。

99 名前： 非決定性名無しさん 投稿日： 2005/06/30(木) 18:40:50
　昔のログ見てたら自称プログラマーがプログラムの事で徹底的にやられてるログ発見
　http://tmp5.2ch.net/test/read.cgi/tubo/1117805574/
　-----
　803 名前： ◆Rb.XJ8VXow 投稿日：04/06/01 08:52
　>>797
　つまらんな。
　私の残していたネタを勝手に暴くんじゃねぇ！！！！！！

　ボケがぁ！
　遊べなくなるじゃんけ！！！

　806 名前： ◆Rb.XJ8VXow 投稿日：04/06/01 08:55
　ってことで、390君は、どうやら元々判ってたうえで嘘を吐き私を陥れようとし
　墓穴を掘りそうになったので「軌道修正」して逃げ出したと言う訳だ。

　愚かな奴決定だな（爆笑！
　-----
　>>803 で追い詰められすぎて口調が変わってるのが笑える
　その後806で相手を愚かな奴呼ばわりして体面保とうとしたけど、もう遅すぎですからー

100 名前： 非決定性名無しさん 投稿日： 2005/07/01(金) 20:59:04
　p84bedc.osaknt01.ap.so-net.ne.jp

101 名前： 非決定性名無しさん 投稿日： 2005/07/02(土) 21:23:08
　ついでに、運営板に沸いて出た時の負け虫ﾃﾞｭｱﾙ糞のリモホ。
　http://qb5.2ch.net/test/read.cgi/sec2chd/1115205599/
　154 名前：雑音 pd3fc89.osaknt01.ap.so-net.ne.jp　投稿日：2005/05/07(土) 01:07:48 ID:oW/NSQrd
　164 名前：雑音 p84bfc5.osaknt01.ap.so-net.ne.jp　投稿日：2005/05/07(土) 12:19:01 ID:MzCt9tXW

>>524
ｼﾞｴﾝするほどの厨房じゃないけどね。

>>525
だからぁ。
業界知識もろくになく、
アスペクト指向スレでも大々的に荒らしやってた
２ちゃん依存症のクズが、でかい口効くなって。
片腹痛いわ、おまえのハッタリは

>>528
かわいそうな頭の持ち主ですね。

ひがちゃん、こーゆー低レベルな粘着にはどう対応したらいい？

>>530
運用にゆがみがあるんじゃねーの？って指摘に煽りか大手がやってるってことでしか答えれない低レベルなやつは、放置がいいかと。

>>531 さっさと死ね

まあ、普通にJavaサーバやってれば、
Javaサーバはほとんど最初っから
プロパティ・ファイルで設定を分離できてた事は
周知の事実なんだが。

DIとAnnotationで、初めて設定の分離が可能になったかのような
幻想を持っているあたりが、ど素人の証拠

>>519-521のｼﾞｴﾝといい、>>533の頭悪そうな指摘といい、一回病院行ったほうがよくね？
早く行かないと、昼休み終わるよ。

まあ、普通に掲示板を長年やってれば、
掲示板で煽ったり粘着したりする奴はほとんど
論点をずらしながら煽ってくるだけで、
一貫した主張などまるっきりない空っぽな人間である事は
周知の事実なんだが。

皆が知ってる「設定の分離」を
後から自分が発見したかのように強弁して、
それが通じると幻想を持っているあたりが、厨房の証拠

>>534
なんだ？デザパタスレで煽られて、またﾌｧﾋﾞｮってるのか。
キチガイ病院に早く戻れよ。自宅療養してたら悪化するよ、あんたの精神病は

>>504
>>511
>>518
>>523

こっちは一貫してるから、相手のほうが「空っぽ」ってことだね。
そういえば、いつのまにか「設定の分離」の話に論点ずらしてるし。

終始一貫したバカ。

基礎研にもいねぇな、こんなバカは

>>538
昼休み終わりだよ。
あ、無職ヒキコモリには関係ないか。

じゃああんまり哀れだから、聞きたくねぇけど聞いてやるよ。

>>511, >>518, >>523
お前の所では、どうやってるんだ？

>>523など、一段落目の世間の常識を、二段落目で否定し、三段落目で一段落目と同じ主張をする、
という痛々しい詭弁を弄してくるくらいだから、ほとんど解答は期待していないがな

>>539
おまえやっぱり無職引き篭もりなのか。
>>511, >>518, >>523見て、随分子供じみた駄々を捏ねる奴だと思ったが、
やっぱ社会不適応者なのね。哀れ

>>518-541 レス削除でいいな

>>542
レスがないとダダこねるかまってちゃんだな。
>>523の1段落目と3段落目が同じに見えるのは、そうとう目か頭が悪いとしか思えん。

=================================================================
キチガイスレ
=================================================================
まぁ悔しかったら、>>540に答えて見なさいってこった

設定的なものは運用チームが変えて、プログラム的なものは開発チームが変える。
どっちが変えるかをファイルの拡張子で単純に判断しない。

はーい、>>515をよく学習しまちたね。
えらいえらい。ぱちぱちぱち

>>545
人の意見と自分の意見は違うんだと暴れまくって周囲に迷惑をかけ、
なだめて詳細を聞いてやると結局同じ意見を言うって、
単なる職場のトラブルメーカーやん、おまえさん

ろくすっぽ就業した事ないだろ、おまえ

アノテーションでDIに関することをソースに記述しても、運用チームがやることと開発チームがやることに変化がないところが違う。

子供の喧嘩レベルの他愛ない言い争いにもううんざり

運用はどういう手順が正しいかよりも
手順が守られているかのほうがよっぽど重要
と煽ってみるテスト

煽る前に、

対立点が何なのか1度纏めてはくれまいか？

別のプロジェクトで再利用する為にアノテーション書き直すわけ？ﾌﾟｹﾞﾗｗｗｗ

とうとう壊れたか。

>>552
書き直す必要がありそうなアノテーションって、具体的になに？

DI

結局、EJB3にどんなアノテーションがあるかも知らずに煽ってるだけか。

@CallBackListener @Interceptorあたりかな

そのアノテーション書くようなクラスを、そのまま再利用するとは思えんが

>>556がその方法を教えてくれるみたいです^^;

結局、アノテーションっていう得体のしれないものに拒否感を覚えてるおっさんがわめいてるだけだから、気にするな。

２ちゃんは脳味噌からっぽの空間

ちょっと聞きたいんだけどweb.xmlとかstruts-config.xmlとかって
みんな手書きor XDocletで書くものなの？
なんかStrutsのForm名とかって片方だけ書き換えて
片方だけ書き換えないまま、とかやっちゃってそうで不安なのだけど、
みんなどーやってんのかしら。
・そうそう書き換えるもんじゃないから手書き＆問題なし
・書き換え漏れが無いように頑張る
・なんかいいツールがある
とかそーいう感じかな。

＞手書きor XDoclet
＞ 片方だけ書き換えないまま、とかやっちゃってそうで不安なのだけど、
XDocletが何をするのかわかってるのか？

>>563
一応わかってるつもりだったんだけどなあ。
俺XDoclet使ってんだけどActionForm側に名前を書いて、
Action側でも使用するActionFormの名前を書いてるんだけど、
こーいう2度書きみたいなのをやらずにすむ方法があったりするの？

eclipseのrenameで対応してくれると助かるなあ、とか思ってんだけど
そもそも二度書きの必要が無いのであれば教えてくれると助かる。

>>564
知ってるけど教えてあげない
こっちで聞いてください

△△まだまだStrutsの良さを教えてくださいSession4
http://pc8.2ch.net/test/read.cgi/tech/1109465052/

あーあるんだ
それだけ聞ければ自分で調べてみる
あんがと

>>564
自分でお好みのStrutsモジュール作れば問題ナス

XDocletなんてつかったことねー
なぜなら、意味無いから
アノテーションで事前にチェックしてくれるわけでもないし
へんな@書いても警告無しで単純に無視するだけだし

それって、「意味無い」理由になってない。

DIやAOPをJavaEEやJavaSEで標準化する動きって無いのかな？
JSFやEJB3が部分的にDI採用してるけど、どうも中途半端な感が否めない

>>570
そのあたりをひがさんが頑張ってるのかな・・・

いつの間にJava EEなんて呼ぶようになったんだよ。
呼びにくいじゃないか。

こないだのJavaOneから

>>572
EE Jump みたいでかっちょ悪いよ

オブ脳で、オブジェクト指向ではオブジェクト指向向けに
テーブル設計をするって書いてあったんだけど・・
これってモデルを先に決めながら、後（もしくは同時？）にテーブル設計をする。
テーブルはあくまでそれを永続化するためのものでしかないって事かな。
それって従来型のようなテーブルの論理設計や正規化やらをしなくても
いいって事？あーバカにも分かりやすく説明してちょ。

誤爆・・OTL

>>575
どこに誤爆したかしらんけど、業務アプリではオブジェクト指向設計自体をほとんど行わない。
複雑な構造をもったデータじゃなければ、今までどおりERで設計
RDBMSを使うときは性能や生産性が結局RDBMSにひっぱられるので、RDBMS主体で設計。

テーブルの論理設計や正規化は物理的な性能にも影響があるわけで。
RDBMSを使う以上は絶対に考慮する必要がある。

>>577
言いたいことは大体合ってる

が、オブジェクト指向がいらないのは業務ロジックな部分であって
しかも再利用が出来ないのがほとんど
再利用できてもライセンスの問題で作り直しもあるわけで

でもオブジェクト指向があるからこそServletとかフレームワークが生かせるわけだし
便利なライブラリ群もある

業務ロジックを作る部分ではいらないけど、ライブラリ整備したりする人は必要な技術

オブジェクト指向は、そういうライブラリとかフレームワークの設計のための技術で、アプリケーション部分では必要ないっていいたかった。
補足蟻が�d

初めてJ2EEを勉強しようと思うのですが
何か参考になる本などあれば教えていただけないでしょうか？
ちなみにJAVAの知識もJDBCの知識もほぼゼロに近い状態です。
よろしくお願いします

J2EEでなにがしたいのか？

>>581
まずは「独習Java」か「やさしいJava」だな。
J2EEの前に基本文法・コアAPI・オブジェクト指向の基礎を勉強汁。

やさしいJavaじゃコアAPIやオブジェクト指向の勉強できないでしょ。

>>584
だから「まずは」なのでは？
基本文法・コアAPI・オブジェクト指向の基礎がこれですべてOK!と言っているわけではないような・・・

「やさしいJava」は先につながらない本だから、薦めれない。
やさしいことしか書いてないから、基本文法もままならないよ。

みなさんいろいろ御教授ありがとうございます。
まずは｢独習JAVA｣を買って勉強してみようと思います。
ありがとうございました。

Java初心者から始まってJ2EEに到るまでの道のりは、嶮しくて大変だなあ
ハッキリ言って転職した方がよくね

>>588
今、整理してる途中だからな。
整理が終わってスッキリすれば
それほど大変じゃなくなるよ。

>>589
おまい、もしかしてEJB3に期待してんのか？
あんまし夢観んなよ

EJB3はすげーよ。バカにすんなよ。

EJB3っはPOJOっぽく書ける、っていうけど、@のオマジナイだらけ。
今まで通りに書いた方が分かりやすい気が・・・

アノテーションはxDocletとは随分違うぞ
アプリ実行中もリフレクションを使ってメタデータ情報を取得できるから、本当に設定ファイルがいらなくなる

しかしそれでもEJBのSessionBeanは最早必要ないと思う
O/Rマッピング記述方法の標準としてjavax.persistenceパッケージが広まるぐらいじゃないだろうか

EJB3 + NetBeansに期待だ。

>>594
その組み合わせ何かいいことあるの？

>>595
EJB3のお手軽作成の説明にNetBeans使われてるよ

EJBとかなにも意識しないで作れるようだ

NetBeans4.1でもEJB2に対応してるけど、EJB2は生成されたコードが難しすぎる。
EJB3だったら生成されたコードも難しくないし、NetBeansが今もってる機能がEJB3に対応すればすごく楽になりそう。

Java技術者の枯渇?

EEJump自体忘れてたよ
あの弟はEJB2のように消えていったな

EclipseにもJSR220-ORMプラグインってあるね。

APサーバはEJB2.xではDeployment DescriptorさえみてればどれがEJBのclassかとか判ったけど、EJB3になったらJAR内の全てのclassを覗かないといけなくなるんじゃない？
デカいアプリを作ると、デプロイが激重になりそうな気がする

>>601
普通はDD見ないとわからないようなクラスの命名はしないけどな

ああすまん。EJBコンテナがクラスを見つけるときの話しだったのね

みなさんの開発スタイル教えて下さい。

C++やperlでCGIプログラムを書いたりPHPなどで開発する時は、
開発サーバを用意してSamba経由でエディタ使って開発してました。

ですが、J2EEへの移行を考え始めたらどうもwebappsをリモートに置いた開発を行うと
ツール関係が非常に重い事に気づいてどうしようか悩んでます。(LANは1000BASE)

開発サーバ(Linux)を中心に置いてチーム開発を行うパターンで有効な開発環境ってあるのでしょうか？
有償ツールも視野に入れてます。

よろしくです。

J2EEアプリでは、開発者個人のマシンに開発環境作るのが一般的だな。
Windows上で開発してUNIXやLinuxサーバでテスト・運用できる程度の
マルチプラットフォーム性はあるのがJavaのメリットだし。

>604 はEclipseとか使ったこと無さそーなJava素人なﾖｶｰﾝ

ツール関係が非常に重いってのはどういうことだろ？

ま、とりあえずNetBeansダウンロードして、Webプロジェクト作って実行させてみろ、と。

>>605
やっぱローカルPCが主流なのか、、
主にデカいECサイトのシステムを扱う事が多いんだけど普通のPCでは対処できないんですよ。
本番がPower Edge 1850クラスタとかなんでローカルでも同等のマシンで開発しないと追い付かない。。
(UnitTestで3分以上処理時間かかる。この時間浪費はさすがにツラい)

開発用に使ってるPCは普通のDELL製PCなんですよ、トホホ。

>>607
Eclipse3.0でTomcatプラグインのプロジェクト作って、

1 .Ant使ってリモートサーバにSCPでWARファイルをデプロイして設置開始
2. 1分ぐらいウンとも言わなくなって忘れた頃に転送完了になる。
3. しかもTomcatがリロードするまで微妙に時間かかる。

代替手段を探して、Subversion経由で

1. ローカルでWARファイルをコミット
2. LinuxのシェルからそのWARファイルをチェックアウト
3. Tomcatがそのうちリロード

したけどこれも効率悪すぎる。

結局いまの所RHEL3上でgcjとmake使ってガリガリやるスタイルになってしまってます。
あまりにも原始的過ぎる、、

>>608
でかいECサイトっていっても、それなりに分割できるんじゃないの？

シェルからAntを呼び出して、Antスクリプトは
1. CVS(SVN)からチェックアウト(アップデート)
2. Tomcat上に必要なりソースをコピー
3. TomcatのリロードコマンドをAntから叩く
という感じで作っておくと、

1. ローカルでソース編集してCVS(SVN)にコミット
2. Linuxからシェルを叩く
3. 完了。

でいいんじゃね？
開発中にわざわざWAR化する意味もわからん。

でかいECサイトを適切にモジュール化できてないことがそもそもの敗因だな。

>>611
その通りだね。オブジェクト間の依存関係を疎にできていないから
ユニットテストもままならないのだろう。

EJBっていうですか？
役割ごとに作業を分担して実装してサーバ上で結合すればよいっていう解釈で合ってますでしょうか。

>シェルからAntを呼び出して、Antスクリプトは
>1. CVS(SVN)からチェックアウト(アップデート)
>2. Tomcat上に必要なりソースをコピー
>3. TomcatのリロードコマンドをAntから叩く
>という感じで作っておくと、
>
>1. ローカルでソース編集してCVS(SVN)にコミット
>2. Linuxからシェルを叩く
>3. 完了。
>
>でいいんじゃね？
だとSubversionでやってる事と差がないですよね。

>開発中にわざわざWAR化する意味もわからん。
Lombozプラグインのデプロイ作業がいったんコンテキストとWARを削除して
新しいWARを置くっていう流れになってたからマネしてみました。

>>613
EJBはここでは関係ないね。

EJB3だと開発が楽になる分、デプロイが激オソになり、テストが進まね〜、とか、アプリの入れ替えに時間がかかってスケジュールオーバーになるとか
懸念してたけど、そうでもないのかな？
EJB3マンセーと考えていい？

>>616
そこまで極端でもないだろうに。

ただ、アノテーションを含んだオブジェクトはPOJOなのか？
というのが最近の俺の疑問。
確かにコーディングは楽だけど、ユニットテストはEJBコンテナが
無いとできないのでは？？？
そうじゃないのなら誰か教えてーー

>>617
アノテーションを含んだらPOJOではない、っていう理由がない。
クラス自体の機能にはアノテーションがついてもつかなくても違いがないから。
アノテーションを含んだらPOJOではないっていう理由はいくつかあるけど、それはだいたいアノテーションなしのクラスにも当てはめることができる。
特定コンテナに依存するとか特定ライブラリに依存するとかね。

>>616
Hibernateの場合はアノテーションを使わずに設定ファイルを書いたほうが起動が遅い。
JBossでも内部的にはHibernateが使われるわけだから、実装の問題ではあるけどアノテーションの方が遅いということにはならないだろうね。

>>618
＞ アノテーションを含んだらPOJOではない、っていう理由がない。
すまん、ここの意味がよくわからない。何を言いたいのか。
つまり、EJB3のセッションBeanやエンティティBeanは
POJOではないと言いたいのか？POJOだと言いたいのか？

POJOとは、特定ライブラリや特定API・特定コンテナに依存しないクラスってことでしょ？
EJBコンテナがないとコンパイルもできない・動作もしない、
EJB3のアノテーションを含んだクラスはPOJOではないってことでOK？

> 特定ライブラリや特定APIに依存しない

Jakarta Commonsのライブラリを使ったらPOJOじゃないのか？
プロジェクト内のユーティリティクラスを使ったらPOJOじゃないのか？

> EJBコンテナがないとコンパイルもできない・動作もしない、
> EJB3のアノテーションを含んだクラスはPOJOではないってことでOK？

EJB3で使う予定のまったくない、HelloWorldクラスに@Entityにつけたとして、EJBコンテナがなくてもアノテーションのjarは単独で用意されているからコンパイルには問題ない。
実行時にはそのjarがなくても実行できる。

それから、コンテナ依存はアノテーションがあってもなくても依存するものはする。
ようするに、アノテーションがあるかどうかはPOJOかどうかの基準にならない。

これってどうよ？

hibernateを利用してはいけない５つのシチュエーション
ttp://www.everes.net/145

@Entity等の、O/Rマッピングを司るアノテーションのパッケージjavax.persistenceは
最近になってJava EE5から分離された
つまりJavaSEもその対象になるということだろう
HibernateもToplinkもS2Dao後継もこれをサポートする予定だし、@Entity関連についてはPOJOと言っても差し支えないと思う

>>625
> @Entity等の、O/Rマッピングを司るアノテーションのパッケージjavax.persistenceは
> 最近になってJava EE5から分離された

いつのまに・・・
EJB3から分離されただけのはずだが。


> @Entity関連についてはPOJOと言っても差し支えないと思う

基準がわからん。

>>626
失礼、発表だとEJB3からの分離だった。
JavaEEから独立してJavaSEでも利用できると書いているところが多かったので、それに倣った。

＞基準がわからん。
サーブレットコンテナやEJBコンテナなど、特定の環境で「しか」動かない前提のライブラリを利用しているものは
POJOとは言えないのではないだろうか？
たとえば、Servlet-API関連のオブジェクトを密に利用しているStrutsのActionクラスやActionFormはPOJOとは言えないと思う
そう考えれば、EJB3のアノテーションを利用しているクラスも厳密にはPOJOとは言い難いのでは？

>>627
それはアノテーションは関係ない。
前に書いたように、@StatelessアノテーションをHelloWorldにつけると、コンパイル時には名前解決のためにライブラリが必要になるけど実行時には必要ない。
だから、アノテーションを使うと密に依存するとはまったくいえない。

POJOの定義は、なんのextendsもimportも強要しないという文法的な意味にしたほうが混乱がない。
つうか、オレ定義で「xxxはPOJOじゃない」とか言われても困る。

>>628
実行時には必要ないって？

>>629
このプログラムはコンパイル時にはEJB3にクラスパス通す必要あるけど実行時はEJB3がないところで動く。
@Stateless
public class Hello{
　public static void main(String[] args){
　　System.out.println("a");
　}
}

EJB3のアノテーションがついたからといってEJB3に依存するわけではない。

>>628
たしかにメソッドを普通に実行するだけなら無くても大丈夫だけど
リフレクションでgetAnnotasions()とかやるとエラーになる
@Remoteや@Statelessなどのアノテーションは@Retention(value=RUNTIME)指定されてるから
本来なら、実行時にもアノテーションにアクセス出来るし

「必須」ではないが、無いと動作に制限が出るのは確か
「xxxはPOJOじゃない」じゃなくて「厳密にはPOJOとは言い難い」と言ってるのは
アノテーションの微妙な制限のことを意識して言ってるのを理解して欲しかったのだが

そういう意味でも、javax.persistenceがEJB3から外れた意義は大きい
EJB3を意識せず、JavaSEの環境でどんどん@Entityのアノテーションを使っていいということだし

>>631
そりゃgetAnnotationのところでえらーになるだけじゃねーの？
アノテーションをつけたクラスがエラーになるわけじゃない。
アノテーションがついたクラスに、アノテーション固有の微妙な制限はないよ。

だいいち、>>631が自分定義のPOJOで話してるのに「厳密なPOJO」とか言われても困る。

誤解してた
getAnnotationsで他のアノテーションを読み込もうとしたときにライブラリがないとエラーがでるってことね。

ただ、特定ライブラリが必要になるとPOJOじゃないって定義自体に賛同しかねる。
Jakarta commons使ったらPOJOじゃないのか？
プロジェクトのユーティリティクラス使ったらPOJOじゃないのか？

もともとはPOJOにはEJB2のEntityBeanじゃないオブジェクトっていう程度の意味しかないので、議論しても意味がない気がしてきたので降ります。

>>634
元々EJBに対するアンチテーゼとしてPOJOという言葉が生まれた
ようするに、POJOの反対が旧EJBともいえる。
じゃあ旧EJBがどんなものだったかというと、SessionBeanやEntityBeanを実装し
無意味なメソッドを実装しなくてはならず、Homeオブジェクトなどの余計なクラスが必要となり
定義ファイルも必要になり、かつEJBコンテナ上でしか意図するようには動かないものだった。

新しいEJBはめんどくささがかなり解消されたが、アノテーションがEJBのライブラリに依存すると
「EJBのライブラリがある環境」に依存するという問題点が残ることになる。
それでも、2.1に比べりゃかなりの進歩だけど

つまり、特定ライブラリに依存することを問題視してるんじゃなくて、
EJBやServlet-API等の「特殊な環境でのみ動かすことを前提としているライブラリ」に依存することを問題視している。

元々自分が「@EntityはPOJOと言っても差し支えない」と言ったことに対しての質問への回答だったから
細かな枝葉の話になってしまったことは確かだね。EJB3を頭から否定したいわけじゃない

>>636
結局アプリケーションは特定環境で動かすわけで、アノテーションがあってもなくても依存するのではないかと。
それでもテスト時にコンテナ外で動かすのはかなりやりやすいはず。
ただ、privateフィールドにインジェクションする場合はどうやってテストするのか疑問だ。

コンテナ依存はいやだな

Servlet・JSPのようにコンテナかえてもちゃんとうごくような標準技術だといい

じゃぁEJB3で・・・ということじゃないの？

DTOとEntityの違いがよく分からないんですが
データベースにアクセスする場合はEntity？DTOでも問題ないような気がする
Entity･･･DBの項目（POJOみたいなもの？）でDB層で使用
DTO・・・Entityに近いけども、どっちかっていったらロジック層で使用
ってな感じですか？
どうもいまいちぴんと来ない

>>639
ビジネスロジック層以下が何層にもなっている複雑・大規模な
アプリケーションだったらそんな感じに近づくのだろうけど、
明確に区別している人は少ないんじゃないかな？

「EntityオブジェクトをDTOとして使う」ぐらいの感覚かな。

>>640
なるほど
今の現場のDTOを見てる限りだと
各プログラムに特化したようなDTOになってて
尚且つ似たようなSQL文（抽出条件同じで選択する列が違う）をそれぞれ
定義してて、それならEntityでいんじゃないかと思ってネットで違いを調べてたんだけど
だいたい概要は分かりました

weblogicでearをデプロイすると、その中身はどっかで展開されているんですか。

セッションビーンはエンティティビーンを返すのではなくて、
DTOに詰めなおしてからDTOを返すようにしなさい。

というのが、EJB 2.0 までのバッドノウハウ(別名J2EEデザインパターン)。

そうなるとセッションにはPOJOを返すようにしてるな〜

そんな殺生なあ

J2EEっておそろしく覚える事多いような
気がするんだけど、これって基本的には
全般の概念だけを理解して、あとは必要に
応じて調べるスタイルでいいのかね。
具体的な実装レベルまで完全網羅しようと
したら時間がいくらあっても足りないんだが・・・

サーブレット/JSPプログラミングテクニック→Struts1.2
とりあえず２冊が必修で後は好み。

>>646
というか、J2EEに何が含まれるか知るのに一苦労。

>>648
アレもコレも含まれてキリはない。だから、基礎だけカッチリ
押さえたら後は好み。

全部網羅しようとか、最新に追い着かねばとか、余計なこと
考えると一歩も踏み出せない。
今更と思うかもしれないけど、>>647の手順でやってみ。

> サーブレット/JSPプログラミングテクニック

高くて値段分の価値がない本だと思う。
なんか、リファレンスを羅列してるだけだから、ネットで充分だと思った。
つか、JSP1.2だから、古いよ。
せめてELとJSTLの解説がないと。

もっと安い本の入門書でいいような。

StrutsとEL・JSTLって面倒じゃなかったっけ？

つうか、それじゃあフロントエンドだけじゃねえの

>>651
いや、むしろJSTL/ELがないStrutsのほうが面倒。
いまさらlogicタグとか使ってられんでしょ。

今のStrutsのバージョンじゃStruts-ELを入れないとダメだったかな？
サンプル見た限りじゃ、無理やりな感じがするし
JSFとStrutsが統合？（するか分からないけど）まで待つしかないんじゃない？
StrutsFaceはどうなの？

StrutsFacesはかなり無理矢理。とても使えるシロモノではない。

＞ JSFとStrutsが統合
次期バージョンのStrutsで実現。
現在はStruts Shaleというコードネームで開発が進んでいる。
中身は、JSF + Commons Chain + Spring + Tiles + Coomons Validaor

newInstance()とかで呼ばれるのではなくて、
普通にnewしてインスタンスを生成しているクラスで、
javaVMが最初にクラスをロードした後に
classファイルをコンパイルして更新しなおすと、
次にnewするときは、更新したクラスが生成されるのでしょうか。

>>654
> 今のStrutsのバージョンじゃStruts-ELを入れないとダメだったかな？

ふつうにいける。

>>656
マルチうざい。

940 名前： デフォルトの名無しさん [sage] 投稿日： 2005/10/12(水) 23:20:09
newInstance()とかで呼ばれるのではなくて、
普通にnewしてインスタンスを生成しているクラスで、
javaVMが最初にクラスをロードした後に
classファイルをコンパイルして更新しなおすと、
次にnewするときは、更新したクラスが生成されるのでしょうか。
941 名前： デフォルトの名無しさん [sage] 投稿日： 2005/10/12(水) 23:42:37
>>940
newInstance() でも new でも一旦ロードされれば同じだろ。厳密にはちゃうけど。
Tomcat とか AP サーバならクラス再ロード検知を有効にしれ。
942 名前： デフォルトの名無しさん [sage] 投稿日： 2005/10/13(木) 00:06:15
>>940
されない。
いったんロードされたクラスオブジェクトからインスタンスが生成されるだけ。
クラスをロードし直さない限り反映されないよ。

>>657
今日試しにやったらいけますた
Struts-ELって一体・・・Strutsタグ使う必要ないんじゃないかと思った

Tomcat4とかのJSP1.2環境だと必要だけどね。

ear,warはweb.xmlに設定したinitialパラメータで設定情報が取れますが、
xx-ejb.jarではweb.xmlに変わる、全体のパラメータ格納場所みたいなものはあるのでしょうか。

ejb-jar.xml?

>>663
そんなのないっすよね・・

EJBコンテナ定義
JNDI

EJB使わない開発で、オブジェクトとRDBの
テーブルのマッピングっておまいらどうしてる？

>>666
その状況の時と、EJBを使った開発の時で別に違いはないのでは？

>>666
悪魔のしるし

>>666
Hibernate

今月のJavaWorkdにJ2EE5の特集見たけど
なんだかオープンソースの技術がすごいあるけど便利そうになってるね

でもアノテーション理解するのが激しく面倒そう

セッションビーン呼び出しで、RemoteExceptionが発生しますが、
セッションビーン側でのアプリケーションエラー時も
呼び出し元ではRemoteExceptionで帰ってきます。
呼び出し元で、アプリケーションエラーか、リモート呼び出しエラー(ネットワークなど)を
判別することはできるでしょうか。
今は、RemoteExceptionのtoStringの結果で、業務アプリケーションがあるかで判断しています。

＞ セッションビーン側でのアプリケーションエラー時も
＞ 呼び出し元ではRemoteExceptionで帰ってきます。

その設計が糞だな。
業務エラーだったら業務例外を投げるように実装しろよ。

getCauseもわすれずにな

>>672
>>673
本当はそうしたいのですが、量が膨大であきらめました。
修正でへんなデグレするのも怖いので。
catchしてから、throw (Exception)e.getCause() で
業務エクセプションを再スローしてます。
struts使用しているので、actionまでリモートのエクセプションを帰したくて。

みなさん、どんなＩＤＥ使ってるんですか？

秀丸

Emacs

eclipseで充分だろ、アドインあるし

NetBeansで充分だろ。インストールした状態でTomcatまでセットアップされてるし。

>>679
使ってる奴シラネ

NetBeans4.1はTomcatどころかアプリ鯖まで標準で入れること出来るからな
EJBも含めての開発なら便利だろうな

12月あたりに出る次バージョンではJBOSSとかも対応するからかなり便利になりそうだ

>680
電話会社系SI屋に派遣に行ったやつが使ってるとこ見たらしい。

>681
4.1でもアップデートセンターからプラグインおとしたら一応JBoss使えるよ。

>>682
おまい電話会社系SIから契約終了食らうかもな。

>>683
話がぜんぜんつながらんのだけど。

>>683
もっと詳しく