【DI】Java Spring Framewoｒｋを語るスレ 2.0

前スレ
ttp://pc10.2ch.net/test/read.cgi/tech/1077465099/

公式
ttp://www.springframework.org/

Rod Johnson著「実践J2EE システムデザイン」
ttp://www.amazon.co.jp/exec/obidos/ASIN/4797322888/

TheServerSide.com - Introducing the Spring Framework
ttp://www.theserverside.com/resources/article.jsp?l=SpringFramework

Rod Johnson著「J2EE Development without EJB, Expert One-on-One」2004年5月発刊予定
ttp://www.amazon.co.jp/exec/obidos/ASIN/0764558315/

SourceBeatの電子出版書籍「Spring Live」
ttp://www.sourcebeat.com/TitleAction.do?id=7

「Spring Live」サポート用Blog
ttp://www.sourcebeat.com/roller/page/[email protected]/Weblog?catname=Spring%20Live

Struts + Hibernate + Spring Framework のWebアプリ 作者は「Spring Live」の著者
ttp://raibledesigns.com/wiki/Wiki.jsp?page=AppFuse

Spring Frameworkを使用したJDBCプログラミングチュートリアル(作成途中)
ttp://www.buggybean.org/tutorials/Spring_JDBC_tutorial.pdf

eclipseプラグイン「Spring UI for Eclipse」
ttp://springui.sourceforge.net/

Spring FrameworkのWiki「Spring Pad」
ttp://wiki.bmedianode.com/Spring/?FrontPage

Spring Frameworkを利用した蔵書検索アプリケーション
ttp://www.commentout.com/people/takai/memos/booksearch-1.0-alpha-1/

PicoContainerのプレゼンテーション資料日本語版(IoCの説明がわかりやすい)
ttp://cvs.picocontainer.codehaus.org/viewcvs.cgi/*checkout*/site/presentations/JavaPolis2003_ja.ppt?rev=1.1&root=picocontainer

コネクションプールからEntityManagerのDI生成するのは常識だろ
NetBeans＋glassfishとか全部自動でやってくれるぜ

TomcatからしかやらないようなレベルならDIコンテナも（DBによっては）コネクションプールもいらないかもしれないけどな

DI生成するってどういう意味？
DIって言葉の使い方がおかしい希ガス。

注入コードってことだな

>コネクションプールからEntityManagerのDI生成する
いみふ

>TomcatからしかやらないようなレベルならDIコンテナも（DBによっては）コネクションプールもいらないかもしれないけどな
これもいみふ

スレ違いだがglassfishて運用に耐えるクオリティなのか？

>>3
言葉は正しく使おうな。
脳内で勝手に進化させないように。
>>6
まったく同じこと思いました。わけわかんないね。

>>7
Tomcatを運用で使える程度の要件ならおｋ。

EntityManagerのDI？
DI生成する？
しかもコネクションプールから？

氏んでいいよ。

>>9
sunが9.0はまだプラットフォーム版しか出してないからな
これがスタンダード版やエンタープライズ版もだしてくるようだと大丈夫と思われ

どちらにせよ開発はglassfishで運用はsunやIBM,WebLogicの商用版ってところだろうが
どこが最初にJavaEE5対応の商用版出してくるか見もの

>>11
goodなコメントThanx.

>>3
nonsense

　　　　　　　　 ﾊ,,ﾊ
　　　　　 　 ('(ﾟ∀ﾟ∩_　おいらをどこかのスレに送って！
　　　　　　／ヽ 　 〈／＼　お別れの時にはお土産を持たせてね！
　　　　 ／|￣￣￣|.＼／
　　　 　 　| .ﾓﾂ煮..|／
　　　　　　 ￣￣￣
現在の所持品：カスラックカスラックカスラックカスラックカスラックカスラック
カスラックカスラックカスラックカスラックカスラックカスラックカスラックカスラック
カスラックカスラックカスラックカスラックカスラックカスラックカスラックカスラック
カスラックカスラックカスラックカスラックカスラックカスラックカスラックカスラック
ＪＡＳＲＡＣが73歳おじいちゃんに音楽を演奏したんだから840万払えと告訴
判決懲役１０月、執行猶予３年（求刑・懲役１０月）
日本音楽著作権協会（JASRAC）が、名古屋の飲食店経営のおばちゃんに、
音楽を演奏したんだから1,600万円払え、と告訴し、おばちゃんは逮捕。
http://ex17.2ch.net/test/read.cgi/news4vip/1169551677/

>>3 のアレは煽りのつもりなのか何なのか。
ようやく変な人が出てくるくらいに普及し始めたのだと
前向きにとららえることにした。

ところで DIxAOP コンテナとして紹介されるけど
AOP を意識してる人ってどのくらい居ます？
トランザクション管理とかで間接的には使ってるんだけど。

spring使うからにはAOP使わないと意味ないだろー！！！


ってぐらい意識してる

>>15
どんなことに使うの？

Japan Spring User Groupにある導入事例見てみるといいよ。
ほとんどがトランザクション管理とかトレースとか一般的な使い方だったよ。
今さ、S2DxoをSpringで使えるように移植してるんだけど、AOPってこういう使い方もあるんだって勉強になる。
HibernateとかもAOPでエンハンスしてるんだよね？

Jythonって完成度高い？Pythonの勉強に使ってみようかと思ってるんだけど。

JRubyは完成度高かった。

javaでWeb開発やってるが、strutsとかFWをまったくつかったことがない。
オブジェクト指向がわかってないし、javaもわかってて使ってるのかも怪しい。
勉強なんかはまずしない。

こんな連中にSpringを使わせるのは危険かな？
Hibernateは無理だろうからとりあえずiBatisかDbUtilあたりから入ってみようと思ってる。

そんな連中にソフトウェア開発させるのが危険ｗ
でも、そういった連中に指導・指示・教育できるのならspring導入は問題ないのでは？

> javaでWeb開発やってるが、strutsとかFWをまったくつかったことがない。
自社製フレームワークとかすらも無いわけ？
プロジェクト毎にゼロから書きなおしてるとか？

他はどうとうでもなるが
＞勉強なんかはまずしない。
これは話にならんな。
知らんものは調べれば済むんだが調べようとしないのでは。

やっぱ無理だよね。
仮に使えるようになってもspringの何がいいの？設定ファイルうざくね？ってなるのがオチだな。
ﾊｧ。もっとまともなレベルの会社に行きたい。

みんなありがと。

むしろ>>20みたいな環境でこそspringが役に立つと思うが。

>>24
プロジェクトとしてSpringを使うことは可能。

連中にはinterfaceだけはとにかくきちんと定義することを徹底させて
(interfaceがきちんと機能を表現できてるかはお前さんがチェックする。)
実装は好き勝手にしやがれ、単体テストだけは完璧に通せと言う。
設定ファイルうざくね？とか言われたら
じゃぁお前がフレームワーク作るか？といえば黙る。

Springそのものの仕様・実装でうまく行かないところとかは
全部お前さんが調べてお前さんが直す。

これでどうにかなる。
他のメンバーの10倍以上の負担をお前さんが背負うことになるが
闇雲に突き進むより数段マシな結果が得られる。
あとコードレビューは最低週１回以上はやった方がいい。

>>26
同意。
ほっとくとゴミを量産されて、10倍どころの負担じゃ効かなくなる。

>>25
おれもそう思ったんだが、なかなか・・・

>>26
interfaceの存在は知っていても自分で宣言したことはないであろう人々だからなぁ。
やっぱ俺が使うって言ったら俺が面倒みなきゃなんないんだよな。
客と打ち合わせして、ドキュメント作って、環境構築しに行って(運用もやるので)、
コードレビュー・・・。手が回らん気がする。俺も実装やらなきゃいけないだろうし。

Springスーパーサンプルとかいう本を全員に読ませれば少しはましになるかな？
簡単だけどWebアプリの作り方が１からのってるし。
新人(そこまで馬鹿じゃないと思うが)にspringつーかjavaを理解させるのにどういうことから教えますか？

＞手が回らん気がする。
この状況はSpring使わない従来の作り方だと解消されるの？
であるならば従来のやり方でやったらいいんじゃないかな。

いずれにせよ一人は辛い。もう一人で良いから理解ある人を連れてくるべき。

＞どういうことから教えますか？
開発環境だけ整備してやって、あとは実地でやれでいいんじゃないの？
分からないところあったら質問に来いで十分。あなただってそうだったでしょ？

これはもうマ板の話題だと思うんだが。

ｔｈｘ。そろそろ引っ込みます。

>>28
インタフェースは全部あなたがつくってみんなに配ればいいじゃない。

んで、内製のクラスはnew禁止にする。
これでOKじゃね？

何か１つ業務選んで、Spring使ったプロトを作って、それをひたすら真似させたら？

ロジックを実装しているクラスをActionSupport実装クラス内で使いたいのですが、
インスタンスを取得するのにgetBean()をするのと、setterインジェクションを使用するのではどちらがよいのでしょうか。
もしかしたらどちらもおかしいのかもしれませんが、一般的？な方法を教えていただけないでしょうか。

お好きな方で♪

インジェクション！インジェクション！

異論反論インジェクション！！！

>>2


> eclipseプラグイン「Spring UI for Eclipse」
> ttp://springui.sourceforge.net/


これってSpring IDEよりもいいの？

Spring IDEと重複しても問題ない？
コンフリクトでEclipseが壊れるのが怖いんだけど。
なんどもEclipseを再インストールしている身分ですので

>>37
あれ？
名称変更された同一プロダクトじゃなかったっけ？
間違ってたらｽﾏﾝ。

>>37
URLが
http://www.springide.org/
にかわっとるね

見ると、Spring IDEという名前に変わってるね

>>34-36
どっちでもいいってことですか？すみません。
なんかからかわれてるようにもみえるのですが・・・

setter injectionを使うのが一般的。

半々かな

>>41
ごめん。からかってみた。

俺敵にはセッターインジェクションで。
Springに依存したコードでいいならgetBeanも選択肢って程度。

ちょっと書いてみればいい。
getBean だと疲れるよ。

すみません。質問させてください。
ログイン管理をするインターフェースが用意されていて、それを私が実装することになりました。
login(id, password)
logout()
のようなメソッドがあり、id,passが正しかったらセッションに情報を格納しようとしたのですが、
どう考えてもセッションのインスタンスが取得できません。setterインジェクションとかでどうにかなるものなのですか？

セッションのインスタンスってなに？

>>46
＞どう考えてもセッションのインスタンスが取得できません。
できないことないけど、無理してやるメリットがない。
login(context, id, password)
こうしとけ

login(userのbean, id, password)
のほうがいいけど。

contextってなんだ？ｗｗｗ

やっぱSpringかな？
時期的にも

>>50
でもこのスレ見る限りまともに使えてそうな奴も居ない現実

>>51
Strutsとかと違って、下手を引き上げるためのもんじゃないしな。
上手が楽するためのもんだから。

Strutsだってマトモに使えるやつ（ｒｙ

やっとstruts + spring + jpa の maven環境できた・・・

>>46
聞くならもう少し詳しく。
その説明じゃ、セッションにバインドされるクラスなのか、
セッションを扱うクラスなのか、何も分からんじゃないか。

そんなまじにならなくてもｗ
既に解決して用済みかもしれないしｗｗｗ

つかSpring2.0ならセッションスコープのインジェクションできなかったけ。

連投スマソ。

1.0系の時はServketFilterでHttpServletRequestを全部ThredLocal変数にいれて、
使う側、たとえばログインサービスなんかはThredLocal変数を保持したHolderクラスかなんかをインジェクションしてたな。

まあ>>46の場合はまともに考えたら、

interface LoginService {
User login(String id, String password);
void logout(User user);
}

とかなって、セッションにデータを保存なんて、
このインターフェースでやる事じゃないと思うが…。

Acegi

ThreadLocalって便利だよな。気をつけないと乱用してしまいそうだ。

>>58
まさにその状態です。＋ログイン済みならtrueを返すメソッドがあります。画面遷移毎に呼ばれるそうです。
で、私のやることはUserDaoを実装して、id,passwordをチェックして、正しければなんからかの形でログインしている状態を保持します。
いろいろ調べてみたのですが、HttpSessionを取得してBooleanかなんかで保持するのが一番簡単なのではと思いました｡
ちなみにまだ解決してません。。。
ThreadLocalを調べてみます。

設計がおかし・・・

LoginServiceはAction(Page)で使用してるんじゃないの？
サービスから取得したUserインスタンスをAction(Page)で保存させて
Filterでチェックが筋だと思うけど

あとBooleanで保持してるだけだとログインしているUserIdはどうやって
取ればいいのでしょうか？って俺速攻聞くよ

とーしろにAnA実装させるなんて怖いシステムになりそうだなｗｗｗ

spring2入門を参照しながらacegiでやればいいじゃない

ThreadLocal 使ってウハウハと思いきや
サーブレットコンテナでスレッドの使い回しがされてて
なんかうまく動かねーやとか言うわけだ。

>>46の話聞く限り、設計おかしいよね…。

おかしいかどうかでなくていみわかんね

Webアプリだとは一言も言ってないのに話が通じてるのが恐ろしい。
確定したのは61でHttpSessionと書いてからだ。

質問以前の何かが欠けてる。

まぁ、活気のないスレに書き込みがあるだけで俺は楽しいわけで。

Springの参考書にWebアプリのサンプル載ってたが、ログイン処理も載ってるかもよ。

ここでまともな会話求めるほうがおか・・・

>>66
その場合はspring自体もｗ

よし
Spring勉強しよ

>>73
一緒にべんきょしよ♪

だがお断りだ

勉強とかぬかしてる時点で負けｗｗｗ

Spring導入してるとこって少ないのか?

まだ少ないとは思う。案件で使うにはそれなりに使える、アーキがわかってるやつがいないと地獄みるからな。
一度暴走すると保守できなくなるし。
Strutsの時もそうだった。

少ないことないよ。
新規の案件でSpring使わないところは、はっきりいって単に「ついていけてない」ことを意味する段階に入っている。
（もちろん「敢えて」使わないことを選択できる技術力が高いところは除いて、の話だが。）

人員の自転車操業ばっかしてる業界だから
「質が安定しない」のがFrameworkがStrutsに偏る理由。

Web層のフレームワークは未だにStruts使ってるところは多いだろうなってのは同意するとして、
＞「質が安定しない」のが
が良く分からん。

毎度毎度フレームワークの使い方から覚える奴でなりたってるから

フレームワークの使い方云々より日本語の使い方を覚える必要がありそうだな

おまえが？話がかみ合わないなら無駄なレスせんでええ。

かなりカチンときたようだな　(　´,_ゝ｀)ﾌﾟｯ

そもそも>>77のネタフリから
>>80で突如Web層の話になる理由が分からん。

seasarのほうが使われているのかね？

日本でもSpringの方が多いんじゃない？

シーさースレ見る限りあまり使わんほうがいい気がするなしーさーは

それでもS2Daoは良いものだという話だ。

Sesarスレはまぁ一昔前のRubyスレがあんな感じだったじゃない。
日本語プロダクトはいろいろな人が湧くんだよ。
いい意味でも悪い意味でも。

久しぶりにSpring1.1.xのプロジェクトをメンテして
<property name="hoge" ref="fuga"/>
が動かなくて小一時間無駄にした。
1.2.xになるまでは
<property name="hoge">
　<ref bean="fuga"/>
</proerty>
と書くことに気がついたときは泣きそうになった。

Spring Lint使えばすぐに教えてくれたのにね☆

俺の回りでは断然springの方が多いな。
また、俺の回りではDI使ってないプロジェクトの方が断然多いなｗ

これはあくまで印象（というかむしろ偏見）だが、
Seasarは同じ日本人が作ってるからかファウンデーション内のごたごた感が気になってしまって、
「プロダクトまでグダグダ・仕様が右に左にフラフラ」という印象になってしまった。
実際そうなのかどうかは問題じゃなくて、
俺個人がそう思い込んでしまったんだから、この不信感はどうしようもない。

とりあえず、Springはトランザションマネージャが気になってしまう。
まぁ、単一DBしか接続しないなら全く問題ないんだけどね。

Hibernate3 が出た頃、Transaction Manager 絡みで
Spring と Hibernate の両コミュニティがやや険悪になってた気がする。

国産プロダクトだからって使いやすいかっていうとそうでもない。
俺は基本的に日本人が作ったもの信用してないからどうしてもSpringを使ってしまうんだよ。

開発者の国籍なんてどうでもいい。
重要なのはその道具が俺にとって役立つかどうかだ。

>>96
と朝から2chやるような使えない奴が言っています

>>97
7:22って朝だよね？ｗｗｗ

>>98
ゆとりか？

またいみふな奴が出てきた
springが普及し始めたということか？

>>99
何が言いたい？

> 普及し始めたということか？
知名度は上がってきてる。
ただ実際の使用はまだ限定的だねえ。

予算握ってるオッサン連中説得するのが大変だもん。
ていうか絶望的に不可能な場合が多数。

現実は厳しいのねん。

ORMやWebフレームワークは、その必要性が明確なんだよな。
「使わなければぐちゃぐちゃになる。使わなくても結局スクラッチすることになる。」

DIコンテナは「使わなくても出来るけど」が説明についてくる。

AOPによる宣言的トランザクションあたりは説得材料にならないか？
バグが減る・使わないとぐちゃぐちゃになるとかなんとか言って。

短期的に見れば、宣言的トランザクションはDI&AOP導入の大きな魅力になるからね。
ただ、それを頭の固いオヤジに理解させるのが一苦労ｗ

宣言トランザクションを理解させる段で諦める

>AOPによる宣言的トランザクションあたりは説得材料にならないか？
かな〜りなる気がする。
結局は以下を責任を持って実施できるかどうかじゃない？
・Spring導入に関するメリットを上司に説明できる。
・Springについては実開発で使えるくらい検証済みである(もちろんテスト工程も含む)。
・メンバへの教育も問題ない。
・Spring導入したことによる問題は自分が全責任を負うと公言できる。

これができないなら上司を説得するのは難しいだろうし、
Spring導入しても失敗するだけかも？
上記をやっても納得してもらえないなら、上司の頭が余程固いか自分がまだ信頼されるようなエンジニアではないのどちらかでは？

「new がないんだが？」
「setter 書いとけばコンテナが勝手にやってくれますよ。」
「でも new ないんだよ？」
「設定に従ってコンテナが勝手に探し出して set しますから。」
「でも設定面倒じゃね？」
「その分 new が減ってますから。」
「でも面倒だよね？」
「その変わり設定変えるだけで実装を切り替えられますから。」
「実装なんて切り替える必要ないだろ？」　　　　　　　　　　　　　　　←この辺りからおかしくなる
「単体テストの時にモック差し替えていろいろ試したりとか、
　問題調査の時にデバッグ版に切り替えたりとか、結構便利ですよ。」
「モック差し替えって・・・リリース時と違う状態でテストすんのか？」　←そもそもブラックボックステストを理解してない
「・・・？　そうですけど。」
「馬鹿なこと言っちゃいかんよ、君。リリースと同じじゃなきゃテストにならんだろ！」
「いや、だから単体テストだからインターフェースさえ守ってればそこは・・・」
「いかん、いかんぞ、これは。今までそんないい加減に仕事していたのか！」
「の入り口と出口さえ厳密に決まってれば、中身なんてどうでもいいじゃないですか。」 ←やや誤解される表現
「どうでもいいとはなんだ！そもそもプログラミングと言うものはだな云々」 ←大昔を語りだす

※ このやり取りはフィクションであり、実在の上司・オッサンとは一切関係がありません。

部下の発言が説得力ないねｗ

図解入りでプレゼン資料提示したり
実際に架空案件でも開発して工数比較したりしないと
新しいツールなんてそう簡単に導入に持ち込めないでしょ。
でもそんなことやってる時間は普通無い罠。
結局デカいベンダのそういうおもちゃで遊んでる部門からでも話が流れてくるのを松鹿内。

>新しいツールなんてそう簡単に導入に持ち込めないでしょ。
そういうこと。
個人の力でできる人もいるだろうけど、難しい人もいるだろうね。
いずれにせよ、行動しなければ松鹿内。

ソフトウェアアーキテクチャを握っていない立場なら確かに松鹿内なｗ
そうでないならプロジェクトにSpringを新規導入できるだけのアーキテクトがいるかどうかだろ？
そんな人材がいなければ残念ってこと。
Seasar導入できるアーキテクトでもよくてよｗ

>でもそんなことやってる時間は普通無い罠。
>>111の会社ではアーキテクトはあまり評価されてないんだろうなｗｗｗ

なんで個人攻撃しようとするかなｗ
アーキテクトなんて職種は中小ベンダじゃほとんどいないでしょ。
俺はツール売り込んでる方の人間だから悩みはいっしょなのよね。
最近は昔みたいに
「生産性上げたら人月取れなくなるからツールなどいらん」
っていう豪快な管理者がめっきりいなくなったけどね。

アーキテクトなんて肩書きがあるケースは少ないだろうけど、中小企業でもプロジェクトでアークテクチャを担当しなければならいケースは少なくはないでしょ。
そういった立場の奴がプライベートな時間を使ってまで新規ツールの検証をするかどうか。
現状がかなりひどいか、新し好きものの変態じゃなければしないだろうな。
どうぜ評価は変わらないのだろうから。

名刺の肩書きで「アーキテクト」は見たことないなｗ


中小だと、アーキテクチャは天の声で指定されることが多いんだよ。
俺「XXXフレームワーク使って良いですか？」
発注元「実績がないので駄目です。」

>>116
> プライベートな時間を使ってまで新規ツールの検証
この時点で「アーキテクチャを担当」とは言えないのでは。
>>117の言うとおり、「天の声」で決まるケースがほとんどでしょう。
で、それは>>111の言う「遊んでる部門」に決定権があったりすると。

Spring導入するくらいで、いちいち聞かなきゃよくね？

勇者あらわる。

言い訳なんて何でもよくね？

「DIコンテナ入れない場合UnitTest出来ないですけど、それでいいですか？」
「APサーバのリファレンスに、Springを使用しろと書いてありますが。」

豪胆だなｗ
俺は嘘ついてまで導入させようとする勇気はないなぁ…

UTできないわけでも、APサーバが求めてるわけでもないってことが、もし後でばれたら…

そんなことチマチマ調べる管理職にお目にかかったことがないので、
ばれない

顧客のためになることだから、独断でガンガン行くべし

StrutsやHibernateとかの必須ライブラリとか言っておけばいいんじゃね？ｗ

>>122
まるっきりの嘘でもないでしょ。
というか、良かれと思ってやってるのに「勇気がない」って。。

もし失敗したら責任取らないといけないからだろ。

大抵のことはよかれと思って始められるが、その結果が常によいとは限らない。

っていうかさ、必要なモノを作らずに利用するってだけじゃん。
そういうアプローチで説得していけばいいんじゃね？

自分以外にもSpringを使える奴がいないと難しいかもナ。
あとあと改修とか保守とか考えると

基本的な機能つかうだけならものすごく簡単だとおもうんだけど。。
struts-configを読めて、bean定義の読み方わからない奴なんていないとおもうぞ。

>>129
それはその時に担当が勉強・・・って考え方は駄目かなｗ

>>131
駄目に決まってんだろ。突然トラブったらどうすんだよ。「勉強中なので対応できません」？

DIコンテナ部分だけ使ってる限りにおいては
勉強とか一瞬だと思うんだが。

>>125
＞「DIコンテナ入れない場合UnitTest出来ないですけど、それでいいですか？」
POJOだけで作ってれば、DIじゃなくてもUTは出来る。
モック作るのが面倒かもしれんが、出来ないわけじゃない。

＞「APサーバのリファレンスに、Springを使用しろと書いてありますが。」
俺は、リファレンスに「Spring使わなければ駄目」って書かれてるAPサーバを知らない。
Spring必須のSPサーバってのがあるの？

×Spring必須のSPサーバってのがあるの？
○Spring必須のAPサーバってのがあるの？

>>134
そういうことじゃなくて、
よくわかってない連中をそうやって言いくるめちまえ！ってことだろ。
真に受けるなよ。コミュニケーション能力のない奴だな。

まるっきり嘘じゃねぇか。

でも少しずつ広まりつつあるのは感じられるなあ。

DIなんて知らね
↓
DIの良さがわからね　← 半年前のこのスレでこんな奴がいた
↓
導入しようとしたら拒否られた　←　今ここ
↓
普通使ってるでしょ
↓
DI古すぎ。これからはアレの時代。

確かに。
大手SIerなんかは、Springベースの自社フレームワーク作ってるところ多いんじゃないかな。
ただ、現場の部課長に「フリー（オープンソース）のソフトなんか信用ならねぇ」とか拒否ってるのがいたりする。

>>139
一昔前にStrutsがはやり始めたとき、大手SIerにはOSSを忌避して、
自社独自のWebフレームワークをスクラッチしたところが少なくなかったよな〜

結局、フレームワークのバージョンアップコストと、
（極端な例え話だが）アウトソーシングするたびに教育が必要になるから、
Strutsベースで作り直すトコが出始めた。

だが、途中からでもOSSベースに乗り換えたトコはましだった。
いまだに自社フレームワーク使ってるところは、バージョンアップがままならないばかりか、
好き勝手に拡張されたフレームワークを使ってる。
だから別の部門に移ると、同じフレームワークと思えないほど変形してることすらある。

もう、そろそろ学習しろよと思うんだよな。

>>136みたいなやつがリーダーのプロジェクトって
ほとんど火を吹くんだよな。最新技術オタク。

>>141
そういう話をしてるんじゃないだろ。話がずれてる。

むしろおまえみたいに叩くのが目的で
ずれた議論をしたがる奴がいるほうが迷惑。




火は吹くんじゃなくて、噴くんだよw

>まるっきりの嘘でもないでしょ。
がなければ、話の筋は通ったんだがな。
これでは知識不足にしか思えん。

要するに、冗談も通じずに叩きネタばかりつっこむ奴がいるとやっかいということか。

>>143
ホントだｗ
嘘も方便ってことなのに。
だから>>141みたいな粘着が沸いてきちゃうんだよｗ

自分は中小企業をいくつか経験しているが、
ここ読んでいると自分はかなり恵まれているのだと実感したｗ
給料はそんなに高くないけど、責任を負う気持ちがあればチャレンジできる環境に多謝。

>>146
ちょっとｳﾗﾔﾏｼｽ。
まぁ、何の責任も無しに高給貰うほうがうれしいけどなｗｗｗ

>何の責任も無しに高給貰うほうがうれしいけどな
確かにｗ

>ちょっとｳﾗﾔﾏｼｽ。
弊社に是非。
今ならStruts, Spring2, JPAプロジェクトにすぐにアサインですよｗ

ごめん。今更Strutsなんて使いたくないんだ。

と、>>147でない俺が答えてみる。

では、Web framework 何使ってるの？

んー、Strutsは要件次第ではまだいけると思うんだ。
なによりも成熟してるし実績が無数にある。

JSF・リッチ・テンプレ系は強力だし、
いつでも使えるといいんだけど人的リソースの確保がなかなか…

>>151
同意

>>149だけど、Wicket使ってるよ。
設定ファイルを書かなくていいからもう他のは使えない体だ・・・

でも、結局Spring使ってるからXMLは書くんだけどなｗ

最近よく耳にするWicketかあ。
プロジェクトの規模は何人くらい？
数名とか小規模なんだよね？

Viewは使いどころにもよると思うが、今はStrutsだろな。
JSFは開発する側はラクだが、使う側からしたら微妙に思う。
Wicketはまだ開発者集めれる段階ではない。


>「フリー（オープンソース）のソフトなんか信用ならねぇ」
こういうの言われるといつも思うんだが、自社製ソフトも信用ならねぇ。バグだらけ。
とつくづく思う。

新規に作ったほうが工数がかかり、多くのバグを仕込むことになることにやつらは気付かないのか？

作るやつと作らせるやつの感覚が違うのが問題
自分が作るつもりで考えないと生産性なんて
得られないおー

バグの無いプロダクトなんて無いからな。
管理職の考えてるのは「落とし前のつけ方」なんだよね。
フリーでいいソフトありますー採用しましたー失敗しましたー
ってなったときに部下に責任なすりつけて逃げていいんなら採用できるけど。

そういっていまだにＣ言語やってそう

>>158
Ｃ言語って何？
おじさん世代？

知ったかぶったガキンチョかｗ

会社じゃポジションがないおっさんかｗｗｗ

いまさらながら>>125について解説しておくと、

[UnitTestの件]
UnitTestするにはPOJOで実装する必要がある。
↓
DIなしでPOJOをアセンブルするにはファクトリが必要
↓
ファクトリなんか書くはずない。めんどくさすぎ。
↓
newしまくりで実装
↓
最下層のクラスがコンテナとくっつく
↓
テスト不能

[APサーバの件]
WebLogicのトランザクションを使用
↓
WebLogicはネストトランザクションを未サポート
↓
「WebLogic ネストトランザクション」で検索
↓
dev2dev内のページがヒット
↓
dev2dev「Springのトランザクションマネージャで出来るよ。」

>>162
すれが活発なのはいいけど、ばかがふえた?

UnitTestするには多くの場合、POJOが望ましいが
POJOである必要はない。
何らかの手段で依存オブジェクトを交換できるように
なっていないPOJOだとテストはやりづらい。

ネストしたトランザクションなんかほとんど使わないよ。
必要だと思っても処理を見直せば何とかなる。

>>162
んなことわかってるけど、上司にどう言い訳するかってはなし

ごめん
>>162じゃなくて
>>163

素朴に疑問なんだけど、Spring使って開発楽になった人っている？

キレイになったとか、テスト用意だったとかじゃなく、あくまで結果楽になった人。

ていしえ：テスト容易

まだまだチーム全体で経験不足なので、楽になったとは言えない。ただ、可読性とかはあがったと思う。
トレースログとか、トランザクション周りを排除できるだけでも使う価値はあるとおもう。
トランザクションの設定はわかるやつが統率して更新したほうがいいよ。

新しいこととか流行の物を使わせるとモチベーションが上がるやつもいる。
そういうやつはそこそこ使えるからいいけど、なんで新しいものおぼえなｋｙ（ｒｙってやつには不評だね。
前者 -> メリットとか関係なく新しいものがつかればいい
後者 -> メリットとか関係なく勉強するのがやだ
俺も年取ると後者になるんだろうなぁ。今はちょうど中間にいるってかんじ。
Ajax系のライブラリも乱立するし、SpringMVCだとか余計なのもでてくるし、次から次へと新しいのがでてくることに飽きたというかうんざりというか。

.NETにようこそ

>>168
Seasarにいらっしゃ〜い（三枝風）

>>168 に近い感覚。

工エェェェ（´д｀）ェェェエ工

昨年末に買ったSpring2.0入門やっと読破したｗ
いいねこの本

>>173
だんな乙
なんて言わないですよ
だってここはSeasarスレではないのですからｗ

>>168

なるほどねぇ。
いやぁ、私もSpring使った開発に足つっこんじゃってて。

正直、使う前に予測してた弊害にモロにやられてるから。
ノウハウが足りないってのもあるけろ。



改めて思うのは、DI自体にそこまで価値あるのかしらっていう。

>>トレースログとか、トランザクション周りを排除できるだけでも使う価値はあるとおもう。
激しく同意だけど、これってAOP的要素なんだよね。

オブジェクトの疎結合によるメリットはまだイマイチ感じれないなぁ。

ただ導入すればメリットをえられると思っている単細胞には、ﾅﾆを使ってもメリットは得られないだろうねぇ
そういうヤツは何も考えずにゴリゴリ書いてガッツリ結合したプログラムを、またゴリゴリメンテナンスするのが
日常だから、考えてプログラム作ること自体がデメリットになっちゃうんだよね
そういう奴らが主導権を握ったプロジェクトだと、こっちまで巻き添えくうから困る

>>175
使う前に予測してた弊害って何？

疎結合そのものにメリット感じられないなら
DI使ったプロジェクトには来ないで欲しいよ・・

って言うか、オブジェクト指向言語使った開発全般に（ｒｙ

>>175
まずは依存関係逆転の原則でググれ。

>>175
>> 激しく同意だけど、これってAOP的要素なんだよね。
そうなんだよね。AOPを使ってトランザクション制御を書かなくていいんだ！ってのは理解してもらえるんだよ。
try,catch,finally close()とかはみんな煩わしいと思ってるし。
問題はDIの部分なんだよね。
setterインジェクションでDaoとか渡さなくても自分でnewすればいいじゃんてなる。
やれInterface書くのめんどくさくないの？とかsetter書くのがめんどいだのいうわけよ。
Daoなんか1個実装すれば終わりだし、ORMが途中で変わるわけないだろとか。
うちの人間は極端にリソースが増えるのを嫌がるからなぁｗ わからなくもないんだけどね。

Interface書くのがめんどくさいとかいうヤツは
コボルでもやってりゃいいんだよ

>>181
そういう奴らの方がよっぽどめんどくさい事を一生懸命やっているっていう事実を
当人達が気が付いていないのが笑える

>>181
自分でnewして良いかどうか、
JUnitでテストケースかいてみりゃ一発でわかるだろ。

PGレベルのやつはspring意識しなくて良いから「勉強ダルい」なんてことはないと思われ。
上でもあるが、トランザクションやログなど、アプリケーションの動作をプログラムから排除することで、
オブジェクト指向設計したメソッド呼び出しのみに注力することができるので見通しが良くなる。

蜜結合大好きならスクリプト言語の世界へどうぞ。

宣言的トランザクションを利用する場合も
TransactionManager, DataSourceなどをBean定義ファイルで設定してるよね？
あれってDIだよね？ｗ
これはkiddingだけど、
DIの価値がよくわからなければnewすることからはじめてもいいのでは？
それで問題がなければＯＫだし、その過程でDIの良さを理解できるかもしれないし。
一気にモジュールを作成してUnit Testをせずに
結合して単体テストするという文化ではnewでいけるのかも？

飲み過ぎだろ・・・常識的に考えてｗｗｗ

誤爆しましたｗ

あなたの常識って何ですか？東国原

＞DIの価値がよくわからなければnewすることからはじめてもいいのでは？
＞それで問題がなければＯＫだし、その過程でDIの良さを理解できるかもしれないし。

単に、問題の存在に気づかないだけだとおもう。

かもなｗ

>>191
問題って何？

理解力不足と、そう思われるのがイヤで
難癖付けるヤツ

自分自身のこと？ｗ

あと、空気読めないガキ

なんか現状に不満みたいだねｗ

>>191-197
これがSpringを導入するかしないかで繰り広げられる会話か。

うあ。大反響だ。

この中で実際開発してる人っているんですよね。
理想論は理解できるけど、どれだけ『体現』してるのかな。
それも個人ではなくプロジェクトとしてね。

ISID内じゃ前からSeasar2不評だよ。

タ　ブ　ー　だ　け　ど　。

>>199
どうでもいいけど、>>175で書いてた、使う前に予測してた弊害って何よ？ｗｗｗ

疎結合否定した時点で、真性かネタの二択だよ俺的には。

今時DIすらわからんJava開発者は、さっさとRubyあたりに移った方が身のためだと思う
多分Rubyもわからなくて廃業するだろうけどな

実際、楽になったといえるような香具師はいないだろうねぇ
Strutsがそうであるように、結局使いこなせなくて大変な思いだけ
が記憶に残ってしまうんだよね
とSpring使ったことないオレがイって見る

だからさっさとスクリプト言語でも何でも、簡単な方にいけばいいのに
DI以前のクソソースしか書けないJava開発者が、現場では一番使えない

ｸﾝｸﾝ
ﾑﾑｯ！！
ｺ・・・ｺﾚﾊ！！！

>>203
とことん楽になったよ。

あとStrutsと比較したらただのアホだから、
人前では決して口にしないように。
DIは(AOPも)パラダイムなんだから。
構造化言語、オブジェクト指向、とかと同列。
進化の方向は「関心ごとを極小にして実装に集中する」で一致してる。

>>203
Javaも使いこなせてないみたいだな

>>204
人の上に立てないやつ

>>199
>ISID内じゃ前からSeasar2不評だよ。
これほんと？(ぁゃιぃ)
不評な理由はなに？

なんかさ、

ジャヴァ・スプリング・フレームワーク と

ネギ・スプリング・フィールド って

なんかにてね？

ネギ・スプリング・フィールドはおまえにそっくりだな

なんか暖冬のせいか、馬鹿がたくさん沸いてでてきてるな

>>206-207
そういう意味で比較したんじゃないからｗ
日本語も読めないようなヤツだと大して使いこなせてもいないんだろう

必死だなｗｗｗ

ネタだと思いたい。

>>212
そりゃ、春のフレームワークだからなｗ。 Spring = 春

バネもってこい！

温泉のフレームワークじゃないの？

スプリングフィールドとかって名前の外人さんいそうじゃねｗｗｗ

DIの考え方は肯定するがDIの存在は否定するよ。

DI使いこなせるやつは密結合でもちゃっちゃと作れる。
DI理解できないやつは密結合の方が早かったりする。

現実問題として多数の人間が後者なんだよ。

この状況でDIコンテナ導入するのは最適かね。

私が言っていた弊害てそういうこと。

ムキになって噛みついてきてる方々は、普段からあまりDIの良さをわかってもらえず、もどかしい思いをしているのかな。

残念ながら多くのプログラマは君達よりずっと馬鹿。

有識者やセンスある人の内輪で盛り上がり、気付いたらJavaの市場規模は縮小してました なんて平気でおきそうで。

『誰にでも』簡単に、より速く これが理想でしょ。

まあ上位開発者がフレームワークでDIを完全に隠蔽できればどーにかなるんらけろ

>>220
作業の分担の仕方を変えれば、あっさりうまくいくよ。

旧来式：
・うまい奴が難しい業務
・下手な奴が簡単な業務

DI導入後：
・うまい奴が全業務のインタフェースを切る
・下手な奴はインタフェースを実装する

>>221
そのうまい奴がいないでDI導入するプロジェクトが存在する訳だが・・・

>>222
それは流石に無謀だろｗ

うまい奴がいないプロジェクトはDI導入しようがしまいがこけるでしょｗ

自分はわかっていると思っているヤツがいるプロジェクトが一番危ういｗ

DIxAOPの宣言的トランザクションや他フレームワークとの連携機能は使いたいが、
DIのメリットが享受できない、理解できない場合は蜜結合すりゃいいんだよ。

220は導入主導したやつにうまい奴だと期待されたんだな。
お前は何も悪くない。そいつの目が節穴だっただけだ。

＞上位開発者がフレームワークでDIを完全に隠蔽できればどーにかなるんらけろ
こんなのは当たり前にやってることなんだよ、普通なら。

>>225
他の奴がわからないと、調べろよとか、
そんな馬鹿な奴らと仕事したくないとか、
俺が５人いたらなとか言う奴がアーキテクチャーを
仕切っていると確かにやばいなｗ
そういう奴は自己中でプロジェクトの成功だとかコストといった観点が抜けてる。

>>222だが、
DI導入を推進してすんごいインターフェースきりまくった奴が逃げ出した
残骸見る限り使い方もわかってない様子。

>>228
＞他の奴がわからないと、調べろよとか、
＞そんな馬鹿な奴らと仕事したくないとか、

むしろDIコンテナは、雑魚に何らの調査力を期待しないで済むように
デザインされていると感じるが。

>>229
何がいいたいかわかんね

DIコンテナといったコンテキストの話じゃない

>>229
それはDIうんぬんの問題というよりも
そいつが技術的に仕切れる奴じゃなかったという話では？

そういう話

よし、今からDIとやらをやるぞ。

ところでJavaもプログラム言語も
ほぼ素人の新人なのだが、
勉強すべき用語をリストアップしてくれ！

>>235

1. 単一責任の原則（SRP：Single Responsibility Principle） クラスを変更する理由は1つ以上存在してはならない
2. オープン・クローズドの原則（OCP：Open-Closed Principle） ソフトウェアの構成要素（クラス、モジュール、関数など）は拡張に対して開いていなければならず（オープン：Open）、修正に対しては閉じていなければならない（クローズド：Closed）
3. リスコフの置換原則（LSP：Liskov Substituion Principle） 派生型はその基本型と置換可能でなければならない
4. 依存関係逆転の原則（DIP：Dependency Inversion Principle） a. 上位のモジュールは下位のモジュールに依存してはならない。どちらのモジュールも「抽象」に依存すべきであるb. 「抽象」は実装の詳細に依存してはならない。実装の詳細が「抽象」に依存すべきである
5. インターフェイス分離の原則（ISP：Interface Segregation Principle） クライアントに、クライアントが利用しないメソッドへの依存を強制してはならない

>>235
仕事ならマジ勘弁してくれ

SRP、OCP、LSP、DIP、ISP だな？

他に知っておく技術は無いか？
俺は素人だからな。当然基礎的なものから全部だ

「人」についての理解が重要です。

>>238
それらを習得する過程で必要なものは全て手に入る。心配するな。

>>240
その必要なものをすべてリストアップしてくれ！

>必要なもの
他の業界への転職

明らかにスレ違いだと分って聞きます。すみません。

Spring Frameworkのような仕組みで、
デスクトップアプリを作ろうと思えば
なにを使えばいいのでしょう？

最近のフレームワークは
WebアプリでHTMLやHTMLっぽいテンプレートを
使ってUIを実装する話しばかりで困ります。

Spring Frameworkのような仕組み とは？

>>243
日本語でおｋ

>>244
えぇ、ですからいわゆるウインドウで作りたいのです。
Windows Formsとか、GTKとかQTとか。

お前はSpringをなんだと思ってるんだ？

もう一度聞く
Spring Frameworkのような仕組み とは？

>>243
電子レンジのような仕組みで、
デスクトップアプリを作ろうと思えば
なにを使えばいいのでしょう？
と質問されたら貴方はどう答えますか？

Springはよく知らないが
SpringでSwingコンポーネントを構成して、部品をFrameにDIさせて実行すればいいんじゃね？
JFrameが部品だらけでごちゃごちゃになるのは
DIコンテナを使えばある程度綺麗にまとめられる気がする
NetBeansやVEが対応できなさそうだが

>>250
NetBeans使った場合コンポーネントのプロパティがDIの定義だと考えるんだ

実際のところインターフェースベースは使い物にならないし複雑にイベントが飛び交うので無理

無理？

>>251
Component自体が継承前提だし、実装に依存した細かなプロパティを外側から変更したいしで
よく考えれば、たしかにインターフェイスベースは無理がありそうだな
DIでの開発に慣れた後にSwingのソースを読むと、ごちゃごちゃしすぎて嫌になるが
あれはRADで開発するものだと割り切るべきか

GUIコンポーネントはプロパティが動的に変わるものだから使えないな
DIってあらかじめ挙動がわかっていて成り立つもの

ただ、GUIコンポーネント単位で使うのではなく、それらを包括した単位で扱うのなら可能
その場合フレーム単位で扱うことになるだろうね

結局はコンポーネントを制御する部分が一番厄介なところなので恩恵はあまりないけど
あとでまるごと作り直したフレームと交換とか出来るようになるのはいいのかもしれない

それでも結局サービスロケータの域からはでないな

おそらくゲームのほうが適用範囲は広いかと

しーましぇん、ちなみに私は>>166です。
ちなみに>>227　私は開発に加担してるけどコーディングも設計もしてないお。

>>221の言うとおりの役割分担になるんだろうね。

ただ、プロジェクトによって(人員の)質のバラつきがあるからねｗ
>>222の言うような状況は発生するんだな。

上位開発者が上手に作れば>>230の言うことおりってのもわかる。
少数の優秀なプログラマと多数の雑魚でチームが構成されても、そこそこイケそう。



>>雑魚に調査力を期待しないで済む
これねえ。　この状態に持っていけるような技術者以外DIに絡むなってことか。
私には扱えないね。
デューダするかな。

>>254
以前作った奴だと getBean 呼びまくりになって
DIでもなんでもなくなっちまったですよ。
そのアプリに適した画面フレームワークを作成した方が
最終的なコストは低く抑えられるし、
変更にもむしろ強いだろうってのがその時得た感触。

画面はやっぱ面倒ですね。
何が面倒って、お客・利用者の目にモロに触れるから
要求の変更速度がやんごとないところ。

256はあくまでも画面(ビュー)の話ね。

つまりある程度以上の複雑さのものまでしか扱えないってこと？

日本語変だなｗ
扱える複雑さに上限があるってこと？

どのような物にも・・・(ry

つーか・・・C#が無料なのに？DI使いたければS2.netとかもあるのに？デスクトップアプリでjava？

LinuxやMacでも動かさないとならないのです

あっそ

リッチクライアントの最先端に興味がある奴は　あぱれっと様のご意見を参考にしろ。
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?mode=viewtopic&topic=9542&forum=12&start=40

>>264
吹いたｗｗｗ

>>256
お偉いさん相手にすると見た目大事なんだよな
帳票も5mこっちにずらせとかすごい多い

WEBアプリだと多少見た目や操作性が貧弱でもいいけど、
リッチなクライアントだとほんと細かい制御をさせられるから無理

JavaSEにJAX-WSとグループレイアウトが標準搭載されたことでたぶんリッチクライアントははやると見てる
鯖もEJB3はDIコンテナになったし、どのDIプロダクトを使おうがDIは必須の知識にはなるだろうね
そしてそのPOJOで作られたEJB3コンポーネントをJAX-WSですぐに公開が可能

1年前のEJB2.1までとは別次元の開発効率になったな

１年前のPOJOでの開発と比べてはどう？

Springは細かい仕様変更要求に弱いってこと？
5mだったらこまかくないか

>>261
クライアントがWindowsだけならC#でもいいかもしれんけど、Javaのクライアントはかなり作りやすいよ
C#はDelphi時代の古いものという感じが強い
当時はBCBともどもお世話になったけど

C#だって無料なのはへぼい開発環境なやつだけなのは問題
クライアントと鯖とで技術者を2つの言語を扱える人を探すより1つの言語を扱える人を探すほうが楽だしな

>>264
一般人には考えもつかないような斬新なシステム・・・

それにしてもリッチクライアントでのJavaクライアントが多いね
1年前というJAX-RPCが使いにくい時代の割には・・・

>5mだったらこまかくないか
ﾜﾛﾀｗ

>それにしてもリッチクライアントでのJavaクライアントが多いね
Javaのフォーラムですからｗｗｗ

>>267
Spring1.2だったかな
それで開発してたけど結局設定ファイルを書くのが面倒だとか
ビジネスロジックに直接絡まないセッターのコードが邪魔とかいろいろいわれて
なかなかDIは認識してもらえなかったよ

柔軟性のあるサービスロケータとしてしか使ってない感じかな

EJB3でテストプロジェクト動かしてるけど、これだとフィールドインジェクションであることやXML必要としないことで
すんなり使ってもらえてる

プライベートな変数にインジェクションしてくれるのはわかりやすくていいね

Spring2は扱ってないのでなんともいえない
フィールドインジェクション使いたかったらSeasar2＋EJB3アノテーションを使って勉強という手もあるね

ほうほう。
俺たちはこれからSpringとEJB3にどう付き合っていけばいいの？
・分散とかSFSBとかを使う必要がある場合はEJB3を使うが、EJB3の機能が特に不要な場合はどちらでもいい？
・EJB3が今後開発の標準になっていく？
・Java Webアプリの大多数はEJB3コンテナを必要としないので、EJB3はあまり普及しない？
・SpringはEJB3とうまく連携していく？
・その他？

識者の方、ご意見よろぴこ

Javaは業界全体で迷走中

HibernateがEJBに逆流したあたりから顕著になってきた

>>254
>DIってあらかじめ挙動がわかっていて成り立つもの
↑これ本当？

ある意味本当でもあるし、ある意味違うとも言える。

>>275
どのようなケースを考えてる？

>>272
Spring Annotationという手は？

>>276
いや具体的にどうって言うわけじゃないんですけどね。
はっきり言い切ってるから気になったんさ。

>>274
HibernateがEntityBeanを乗っ取ったという方が近い

>>279
Hibernate微妙じゃない？
HQL廃止すれば、少しは光さすけど。

スレ違いだ　スマン。

>>269
>C#はDelphi時代の古いものという感じが強い
>それにしてもリッチクライアントでのJavaクライアントが多いね
>C#だって無料なのはへぼい開発環境なやつだけなのは問題
>クライアントと鯖とで技術者を2つの言語を扱える人を探すより1つの言語を扱える人を探すほうが楽だしな
色々とすごいな・・・

EJB3のコア技術の一つJPAはまず普及する技術だろうね
DBマガジンだっけ？アレでちょうど特集やってるね

HibernateはHibernateEMということでJPAの実装のひとつと思うくらいがちょうどいい
実装はどれもオープンソースだし一長一短だと思うがリファレンス実装になってるTopLinkはわりと素直でいい動きしてる
TopLinkは新人に見えるが歴史は長くJavaが登場する前からあるのも面白い
Java版のTopLinkも登場してから8年くらいたってるんだっけ
まぁリファレンス実装というのがどれだけ強みなのかはTomcatを見れば明らか

そして今JavaEEのリファレンスという位置づけでオープンソースなglassfishが稼働中
glassfishはJavaEE鯖の中では軽量なほうで5秒あればノートでも起動するね
Tomcatで面倒なコネクションプールを定義するくらいならglassfishでやったほうが手っ取り早い

EJB3の利点はJavaEEのコアな技術ということでフリーから商用のさまざまな鯖で動かせるというのがいい
JavaEEが注目されはじめたのはその技術そのものよりオープンソースのAP鯖など環境面での影響があると思う

今までサーブレット/JSPしか注目されなかったけど、Tomcatもフリーでテストする環境がすぐに用意できたという理由はあると思う

>>277
コード見たことないのでわからんけど
フィールドインジェクションしてくれるならいいと思う

ただ、Springのプロジェクトって全体的にhibernateにべったりなのがちと気になる
Seasar2もJPA無視なんだっけ？

>>259
上限があるのは複雑さじゃなくて、変化の度合い。
画面アプリは朝令暮改の仕様変更なんてザラ。
サービス仕様決めて・・・とかが水泡に帰す。

この場合、何使って作ってもグダグダになるので
逃走の準備をきちんとしとくのが何よりも大事。

>>266,283
きしだﾀｿ乙

>まぁリファレンス実装というのがどれだけ強みなのかはTomcatを見れば明らか
実例はTomcatだけ？ｗ

JPAがTopLinkよりもHibernateの仕様にかなり近いことを考えると、
Hibernate EMの方が良いのではという考えもあるのでは？ｗ
JPA実装を何するかは様々な観点から検討する必要があり、
プロジェクトによっても採用基準が異なるだろうから
単純に年数だけで決定すると失敗するかも。

>>266は岸田たんというよりもたぶん >>3だろｗｗｗ

>>284
フィールドインジェクションはしてくれなかったと思う。

>ただ、Springのプロジェクトって全体的に
>hibernateにべったりなのがちと気になる
この感覚は俺にはわからない。

>Seasar2もJPA無視なんだっけ？
Seasar2はJPAをサポートしてるよ。
S2Hibernate-JPA, S2TopLink-JPA, Kuina-Dao。
Kuina-Daoは動的な問い合わせを生成したりするのにかな〜り便利。
まだ品質は今一歩かもしれないけどｗ

Session Beanの単体テストって簡単にできるの？
俺、昔のEJBの印象が残っててそこが引っ掛かるんだけど。

>>290
昔のEJBと同程度のユニットテストしかできないと思っていた方がいい。
過剰な期待は禁物。
つまり、ビジネスメソッドの正常系のみ。
トランザクションやセキュリティロールが絡むとダメダメ。

>>288
グループレイアウトやJAX-WSごときでJavaクライアントがはやるなんて
寝言がいえるのはきしだﾀｿしかいない
よって>3もきしだﾀｿ

POJOですからｗｗｗ

＞よって>3もきしだﾀｿ
なら納得ｗｗｗ

>>290
EJBは
Context c = new InitialContext();
(NewInterface) c.lookup("NewInterface");
見たいな感じで取得すればおけ
getBeanとやれることはかわらん

>>291
経験に基づいたコメントサンクス

>過剰な期待は禁物。
そっか。
俺はしばらくは Struts + Spring + JPA/iBATIS でいいやｗ

>>291
具体的にたのむ。

釣れてきましたね〜ｗｗｗ

>>243
あなたはSpring FrameworkがWebアプリ専用だと思ってますね？
他の人が答えたようにSpring Framework上でSwingアプリを作れます。

Javaでスクラッチ開発より楽にデスクトップアプリを作りたいのなら
スタンドアローンアプリでなくEclipseかNetBeansのプラグインを作れば
典型的処理をFrameworkにまかせてアプリ固有処理に専念できます。
「統合開発環境Eclipseプラグイン開発QA」
http://pc10.2ch.net/test/read.cgi/tech/1081517094/

WebアプリでHTMLなどでUIを実装するようにデスクトップのUIを実装したい、
という話だったらSynthをどうぞ。
「進歩したSynth」
http://www-06.ibm.com/jp/developerworks/java/050318/j_j-synth.html

そういえばSpring RCPとかあったな。
ttp://spring-rich-c.sourceforge.net/

swingったってviewが変わっただけだと思うんだが。

Swing Application Frameworkってあったな。内容は知らないけど
あれがSwingのView部分を受け持って、ロジック側をSpringが受け持つようになれば
Struts+Springみたいなイメージで使えるようになるだろうか

上の方でGUIは無理ぽって言ってるひとがいるじゃん。

>>303
そのうちの一人が俺ｗ

>>303-304
Ｖｉｅｗと密結合でつか？ｗ

View内で完結される話で、ロジック以下を密結合させるわけではない。
Viewから上のレイヤはレイヤ内でよろしくやれってことだ。

>Viewから上のレイヤは
サービス層などは上か下かと言えばViewの下のレイヤようなｗ
「Viewから先のレイヤ」の方がまだしっくりくる

っていうか、Ｖｉｅｗ内でよろしくならそのＶｉｅｗがＧＵＩだろうがＣＵＩだろうが
ＪＳＰだろうがなんだっていいんじゃねーの？ｗ

>>305
View部分には使えない。
それ以外に使おうとするとメリットが少ない。というかほとんどない。

>>309
Sptingは、WebアプリのViewを実装する事にしかメリットが得られる使い道が無い
といっている？

>>310
ゴメン、間違えたｗ

だれもViewでSpringを使いたいという話はしていない件

>>310
309ではないが、そんなことは言ってないと思うし、
SpringはWebアプリのViewの実装をサポートするだけではないのは明らか。

>>310だけど、>>309を読み間違えましたｗ
「View部分には・・・」と「それ以外・・・」という言葉のつながりが
よくわからん買った

この流れ見ててわかるだろ。
無理してSpring使うなｗ

>>308
なんだっていいだろ。
何かに限定する話なんぞ誰もしていない。

なんでもいいよ
なんにしても大した発言は無いスレだｗ

>>317
これこれｗ

だが、「こないだ雑誌にのってたのマンマだな」とかよくあるｗ

>>317様
是非仕事に役立つSpringのTipsをご紹介下さい

上の方でもDB MagazineのJPA特集読んで知ったかしてた馬鹿がいたなｗ

あー、Ｗｅｂ層のフレームワークって何がいいのでしょうか？
お馬鹿な私にはStrutsは難しいです・・・

SpringMVC

SpringMVCですか・・・
Strutsとあまりかわらないような・・・
そんなことないですか？

自作が一番わかりやすいよｗ

サンプル見ただけなんですけど、
Clickってわかりやすそうに感じました。
１人プロジェクトならいいんでしょうけどね（苦笑）

Springスレなんであれだけど、
もうちょっとしたらSeasarのTeedaがおもしろいと思うよ。

SpringMVC (ViweはVelocityが良いと思われ。)
Wicket
Teeda

この辺りが有力株か？

簡単なものは SpringMVC+Velocity でやっつけて
ある程度面倒になったら WebService+RichClient で
ってのが最近の俺のパターン。

SpringMVCって戻るボタン、ダブルクリック、マルチウィンドウ対策とかしてくれる？

JBoss Seamがいい。

>>328
WizardFormController使ったアプリで、
マルチウィンドウ試したら思いっきりデータが上書きされたorz

やり方悪い！？

>>328
個人的にはMVCでそんなもんコントロールするなよって思う。
レイヤがそもそも違うじゃねえかと。Viewで勝手にやったらいい。
下位レイヤでサービスしようとするといつか破綻する。

そこまでしてWebアプリにするなってのが本音。

>>329-331
コメントとんくす
やっぱりSpringMVC単体で解決してはくれないのねん。
こういった制御コードはもう書きたくないし、
そうなるとTeeda, Seamを選択したくなっちゃうのよねん。

>>331
気持ちはわからないでもないが、
何の解決策にもならない。

Strutsみたいにトークンの管理をWebフレームワークにさせたいと思うのは自然じゃないか？
が、コードに決まりきったこと書くのはメンドイ。設定ファイルだけでできるとうれしいな。
というかこういうのをAOPで何とかできないのかね？

で、それ以上のこと(ボタンを押せないようにしたいとか)はView(のJavaScript)でやればいいとｵﾓﾀ。

なんか的外れ？

>>334
的外れじゃないと思うよ。
その解決策の１つがJBoss Seamだって話。

>>335
Teedaも忘れないでね　(。-_-。)ポッ

おー、そーりー、そーりー
Teeda最高！
Seasar最高！！！
これでよい？ｗ

>>335
そうなのか。Seamって使ったことないからわからなかった。
ﾄﾝｸｽ。

>>336
ttps://www.seasar.org/issues/browse/TEEDA-44
これ？
でもスレ違いじゃないかぁ？！ｗ

>>338
Seamもスレ違いな件

選択肢提示するだけならまぁいいんじゃねえの？
Springの話をここでしかしないわけでもないんだし。
詳細に立ち入るならスレ違いだが。

>>339
全くすれ違いというわけではないと思うよ。
だって、Seam使う人はSpringを同時に使うことはたいていないわけで、
「じゃあSpringを使って開発していてSeamと同様の機能を
享受するにはどうしたらいいの？」
っていう話に発展してくれること願って投稿したんだけどねｗ
念のため言っておくけど、HibernateとiBatis、StrutsとJSFのように
SpringとSeamは同列のものだとは思ってないよ。

>>341
SeasarのTeedaでは一部Seamを意識しているところがあるよね？
Spring使って開発している場合、
自前で制御コード書いてやってるケースがほとんどじゃない？
Ｗｅｂ特有の問題について全く考慮していない
Ｗｅｂアプリも少なくないと思う。

>SeasarのTeedaでは一部Seamを意識しているところがあるよね？
これは俺も感じたｗ

>Spring使って開発している場合、
>自前で制御コード書いてやってるケースがほとんどじゃない？
Springの責任というわけではないというのはいいよね？ｗ
Struts で開発している人ってSpringを導入しても
たいへんなんじゃないかな？
もう体にしみついちゃって不感症状態なのかもしれないけどｗ

Struts開発で業務に集中したい場合は、Valentine Frameworkがいいかも
http://www.valentineframework.org/

あれ、バレンタインのつづり違う？

SpringMVC自体はあくまでもMVCで
ViewはViewでよろしくやりやがれってスタンスでは？
(Controllerが抽象化されたModelAndViewを返してくるだけ)

>>346
それはそれでいいんだけど、
現実問題としてＷｅｂ固有の問題は解決しないといけないよね？
それはViewで解決する問題っていってる？
その場合のViewって具体的に何？

Spring2.0入門買いました
すごいいいとおもいました

おれもかったよ
著者は印税がっぽがっぽじゃね？

>>330
ﾜﾛﾀｗｗｗ
ｵﾚもそうなったｗｗｗ

>>348-349
俺もかおっかなー・・・・

みんなで買って、はせがわさんをスプリング長者にしてあげよう♪

Spring2.0入門Amazonで買ったけど、
Springわかってない俺にはSprng入門が必要だった orz

そこで Reference Manual ですよ。

ていうかこれ日本語化してるプロジェクトとかある？
周囲に日本語になってないと読まないやつが多数居て泣ける。

>>354
http://andore.com/money/trans/spring_ref_ja.html

>>354
Reference Manual読むのがつらいかたら買ったのに？ｗ

最初はつらかったけど、Spring2.0読んでいくうちにたいぶわかってきた。
なんとかJPAを使ったDao作成までできるようになった。

便利だねコレ

今日はでぶさみいきまつよ
JSUGのみなたまよろしくでつ

コアパッケージ含め、全てのnewをSpring経由にしてみたんだけど・・・
完全にプロジェクト失敗だ。

>>359
明らかにおかしい
間違いなくプロジェクトがこけたのはお前のせい

StringBuffer とか BigDecimal とかも全部ってことか

中庸と言う言葉があってだな

使える奴には良い道具を与えよ。
使えない奴にはｒｙ

>>359のような馬鹿はすっこんでろ！
お前は定型作業やってりゃいいんだよ
回りを不幸にするな

newを全部って、楽しいヤツだな

Stringとかどうやったんだろう。

>>366
String str = "aaa";

"new"って文字列が出てこないからOK！！

とかw

newは世の元凶です

さては、コンストラクタがクラスに内包されるのってオブジェクト指向言語自体の設計ミスなんじゃないのかね。

ネタですたｗ

ネタだと知っていて罵倒してやりました
すげえ気持ちよかったでつｗｗｗ

ストレス解消に貢献でき何よりですｗ

>>369がちょっと興味深いこといったかも。

>>359
お前ごときが興味深いだと？
身の程を知れｗｗｗ
興味深いという奴は何も考えてないといってるのと同じｗｗｗ
ちょー気持ちいいーｗｗｗｗｗｗ

確かに３５９は頭わるそうだな(　´,_ゝ｀)ﾌﾟｯ

>>370
　　　　　　　 　 　 . ｨ
.._ .......､._　　　 _　／:/l!　　またまた、ご冗談を
　:~""''.>ﾞ' "~　,､､''‐'､|　　　　　　　　　_　　　　　　
ﾞ､'､::::::ﾉ:::::::_,.-=.　 _〜:、 　 　 　 　 ／_.}'':,
　``､/:::::::::__....,._ `ﾞ'Y' _.ｪ-､....._　／_ﾞ''iﾞﾉ､ﾉ
　,.--l‐''"~..-_'.x-='"ﾞｰ ､`'-､　,:'　　ﾉﾞﾉﾌﾞ　　　　　
"　　 .!-'",／　 `'-‐'') /＼　`/　てﾞノ-〈
　.-''~　>'ﾞ::　　　 ‐'"ﾞ./　　ヽ.,'　　 ~　／
　　 ／/:::::　　　　 　 ',　 　 /　　　 ,:'

俺、環境構築（総合テスト＆本番）担当なんだけど、
開発からあがってくるXMLのbeanidがすげー適当で一発で動いたためしがないんだけど
なんかうまいことチェックできるような仕掛けとかないですかね？

beanLint

チェックのイミがわからんが、Spring IDEだけではだめなの？

springのxml helloで死にそうです。
seasarを使うべきでしょうか？

……誰も覚えてないコテハン&ちょー遅レスで恐縮だが（笑）

SpringということでなくDIxAOPということでなら、少なくとも今自分が弄ってるEclipse RCPには大いに有用だと思う。
イベントリスナの管理やログ管理オブジェクトの生成の煩雑さには正直ウンザリしてる（苦笑）
（まさに「フレームワーク」として」）アプリケーションの枠組みはEclipse RCP、AOPするための仕組みと割り切ってComposite（SwingだとPanelかな？）の管理にDIxAOPを導入するのはアリだと思う。
……ちなみにPHPもヤる人間なので現在Seasar2で遊んでいるのだが、どーも隔靴掻痒の感が否めん。Springに移行してしまおうかしらん？
一番アテにしていたコンポーネント（Springでは「Bean」かな？の自動登録はEclipse RCPで使えんよーだし。
ただ、それでもS2Daoはスゴいと思う。……ちゃんと動けば（苦笑）
うごかねーだよ、ヒマ見てちょこちょこ動かしてるレベルぢゃ(T_T)

なにいいたいのかいみふ
近視眼的で構成力のないコーダーと推測

たしかに

……バレるもんだな、下地の無さは。２ちゃんでもよく考えて書き込まないとボロが出ますな（苦笑
素直に「プレゼンテーション層が変わるだけでビジネス層やプレゼンテーション層は変わらん」と書いてしまえばよかったかな？

ただ、プレゼンテーション層そのものの作り込みにも、意外とDIxAOPが適用できる部分は多いんぢゃね？　と書きたかったんだけど……まぁいいか、またボロが出る前にやめとこう（苦笑

>>384
キモイ

taglibにインジェクションする仕掛けがSpringに無いのはなんでだろう。

キモイ荒らしが来たと聞いてすっ飛んできますた

キモイ荒らしが来たと聞いてすっ飛んで通り過ぎます

まじきもいな
こんなやつが同じプロジェクトにいなくてよかったよ
まあ、こんなやつがいたら皆で手を組んで出社できなくなるくらい
追い込んじゃうけどねｗｗｗ

>>384
天才。

>>384
あ、typoしてるし（苦笑）
誤：「ビジネス層やプレゼンテーション層は変わらん」
正：「ビジネス層やデータアクセス層は変わらん」
でよろしく。

　　　　　　　　　　 ,. -‐ ''" ￣￣ ｀`丶､
　　　　　　　　　　　i:::::::::::::::::::::::::::::::::::::::::::i　　　　　 |
　　　　　　　　　ｶ　ヽ:::_; ‐--､､ ､---､ ;;_:|　　　　　 |
　　　　　　　　 ﾁ　　 `!;{　　　|ﾄNヽ　 }.:.:.:|　　　　|ヽ'　　要
　　　　　　　　ｶ 　 　　lf　へ、| ､,. へ､ヽ;| 　 　　 | 　　　チ
　　　　　　　 ﾁ　　　 ,.-!. <(')'　　 '(')>　 '=､　　　 |　　　 ェ
　　　　　　　ｶ　　　 .{{〉,|　　'" , ,　`　　 ﾑ }〉 ､ 　 | 　 　 ッ
　　　　　　 ﾁ 　 　／ヾ‐l　　 ,.---､　u i､..ｲ　　｀`'|　　　ク
　　　　　　ｶ ,.ィ_"　　 |`''i、 〈ﾖ￣´,〉　/　/　　 　 |　　　や
　　　　　 ﾁ/,ノr:}　　　ヽ　ヽ `'三'"／　 /　　　　ﾑ　 　　!!
　　　　　 / /,.⊥L_　　　＼l! ` -‐' /　／　　　　　/|
　　　　／ /　 ─‐〈　　　　｀ヽ､一r''" 　 　 　 　　! |／￣ !ヽ
　　r''"　.ノ　'ー─〈 ＿＿　-─‐=ﾆ二二)　　　　l ／　　　|
　 /　　（　 ､　二.ﾌ |-ﾆ￣　-──-　　　|　　　　|　　　　　i

>>389
俺はそんな暇があったらコード書くよ。
まっとうなフレームワーク作って、個人の作業範囲が明確になるようにする。
それでもついて来れないようなら他のプロジェクトに回ってもらう。

>>393
こんなとこ書いてないで手を動かせｗ

>>394
おまえ・・・正論すぎると嫌われるぞｗｗｗ

wwwって書くバカっぽいwww

ビジネスロジックを複数のCommandとして捉え、ChainOfResponsivirityのように次々に呼び出したい。

この設計思想に基づいてSpringを選択するのは正しい？

また、Commandの実行結果によっては次に呼び出すべきCommandが変わる場合もある。
この場合、設定ファイルだけで実現可能？


教えてｴﾛい人

Struts

>397
spring以前の問題
そんなもん自前でやれ

springは疎結合モジュール間の依存を解決させるためのもの

>>397
つ Jakarta Commons Chain

>>399,400

サンクス。
DIで上下レイヤー間の粗結合を受け持たせる…って認識でおk？

>>400の言う通りcommons-chainにするわ。

二人ともありがと

commons-chainのcommandにinjectionするニーズっていうのは結構あると思うんだけど。

5年以上前からこんなしくみつかっとるがな

ビジネスロジックは画面単位、イベント単位どんな風に区切るべき？

イベント単位じゃ
まだ荒い

っていうか１つのビジネスモデル（もしくは更に細かいモデルであったとしても）＝１画面 or １イベントではない

>>403
それって自慢？
俺はその前から使ってるがなｗ

>>407
それって自慢？
俺はその前から使ってるがなｗ

つい画面単位で物を考えてしまうけど、それではうまくいかないかなぁ

画面はビジネスモデルのビューなので

　大きなくくりのビジネスモデル　(1) ← (n) 画面

だけど、イベント単位に考えると、１つのイベントに他のビジネスモデルでも流用可能な
手続きがあったり、そもそも他業務の機能の呼び出しが入ってたりするから、
細かくしておいた方が都合が良いと思うなぁ

業務B画面　　　Action　　　　業務A　　　　　業務B
　│　　　　　　　　　│　　　　　　|　　　　　　　　　|
　├─────→.│　　�@ 　　|　　　　　　　　　|
　│　　　　　　　　　├───→|　　　�A　　　　│
　│　　　　　　　　　├─────────→.│
　│← - - - - - - │　　　　　　|　　　　　　　　 │

�@　業務Aで生成されるデータを取得
�A　�@のデータを使って業務Bの処理を実行

みたいな

>>408
それって自慢？
俺はその前から使ってるがなｗ

Spring Web Flowってめんどくせえな

>>411
それって自慢？
俺はその前から使ってるがなｗ

>>413
それって自慢？
俺はその前から使ってるがなｗ

>>414
それって自慢？
俺はその前から使ってるがなｗ

>>415
それって自慢？
俺はその前から使ってるがなｗ

おもしろいとおもってるのか？これだからプログラマーは。

合コンで女性陣がポカーンとしてる光景が目に浮かぶなｗ

>>41６
それって自慢？
俺はその前から使ってるがなｗ

>>419
それって自慢？
俺はその前から使ってるがなｗ

>>420
それって自慢？
俺はその前から使ってるがなｗ

今度のSpring勉強会で１０分のデモする人ってあっぱれっと殿じゃね？ｗｗｗ
http://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?mode=viewtopic&topic=9542&forum=12&start=40
勉強会出席して拝見させてもらわなきゃｗｗｗ
もちろんデモじゃなくてあっぱれっと殿をねｗｗｗ

Spring勉強会もアッパレット殿とやらも分からん。

だああああああああああああああああああああああああああああああああああああああああああああああああああああああああ！！！！！！！！！！

SpringMVCはこれから流行ると思うかね？

おもわん

思います

思えば

思うとき

思え

思おう

もうWebはいいだろ・・・と思う。

あえてWebで行く時はSpringMVCは悪くない。

>もうWebはいいだろ・・・と思う。
はい！消えた！

つまんねーなー

今日の勉強会レポよろ

つttp://d.hatena.ne.jp/Isoparametric/20070310/1173478497

>>436
レポート乙
２番目のトーカーに対するツッコミがきついようだが、そんなに納得でけへん内容やったん？

http://code.google.com/p/google-guice/

これ軽いね

super-injectionがいい

Springって、netBeansで動くの？
net-sf-springnetbeans-support.nbmをNetBeansにインストールしたけど、この先どうして良いかわからない。
やっぱりエクリプスが良いのかな。

Springが動作するのは、IDE上ではなくてJVM上だ。
「Springって、netBeansで動くの？ 」なんて質問は的はずれもいいところ。

動かないわけないべ。
eclipseつかえるならとりあえずそっちでやっとけ。何ら問題ないだろ

>>442-443
とりあえず、ありがとう。

eclipseはプラグイン探しが大変そうなので、敬遠していたけど、All In One Projectがあるので、そっち試してみます。

>>444
まぁかまわんが、spring使うときにプラグインなんぞ使ったことないぞ
何の貯めにプラグインがいるんだ？

設定ファイル書く時に補完が効けば少し嬉しいんじゃね？くらいだな。

このIDEで動きますかと質問をしている時点でプロジェクトの成功はないだろうなぁと思う

時代はアノテーション

NetBeansって結構ガチガチにライブラリ周りの設定が組み込まれてるから、
標準で入ってないフレームワーク使うとき躊躇するんだよね。
俺もJSFプロジェクト試してみたときに、RIの代わりにMyFaces使う方法がわかんなくて
結局eclipseに逃げたことあるよｗ

組み込みのライブラリ使わなければいいだけじゃないか・・・

>>449みたいな発言を見ると、IDEでしかコーディングできない弊害を感じてしまう・・・

慣れはあるだろうけど>>449見たいなのは特殊だろ

>>452
特殊って？
使いにくいとおもったツールを根性で使うのが普通ですか？

IDEサポートが得られないならIDEとフレームワークを無理矢理組み合わせる必要はない。
サポートの無いフレームワークの扱いやすさ
Eclipse ＞＞＞＞＞＞＞＞＞＞＞ NetBeans

NetBeansはJavaEE標準のアプリをオールインワンで開発できることに重点を置いてる
ように見える。本質的にはフルスペックのJavaEEサーバを使った開発向き
様々なライブラリを組み合わせて使うのには、やはりEclipseが向いてるように思う

ふむふむ

アノテーション全然使わないまま1.6の時代が来てしまった・・

springユーザってたいへんでつねｗｗｗ

は？

↑たいへんなスプリングユーザｗ

よーするにGlassFishだけで動くアプリの開発ならNetBeans、
Springなど非標準のフレームワークを使うならEclipse。
NetBeansでGlassFishなユーザから見るとEclipseでSpringな
ユーザってたいへんでつねwww
ってことか？

case by case

Java以外でも使うからeclipse
JavaだけやってればいいSpringユーザはラクでいいね

springユーザがJavaだけやってればいいケースも少ないだろｗｗｗ

明らかにSpringを分かってない発言が繰り返されてるが
一体どんなものをイメージしてるのか、興味は湧く。

わかってる振りしている発言の開始か？

っていうかSpring以前に、いまだに１.４だぁ──────！！！！
アノテーションてなんだぁ──────！！！！
DIってなんだぁ──────！！！！
俺終わった──────────！！！

EJB3.0の話題はあんまり無いのね。

>>467
1.4でもSpring使えるぞ

>>468
Springのスレだからな

>>469
確かにそうだけど、ム板全体で期待されていないような・・・。

いや・・・
世界的に（ｒｙ

DIコンテナは背後を隠蔽しないけど
EJB3は裏でうねってるものを
アノテーションで見せないようにするのが
なんつーかもう気持ち悪くて話にならん。
interfaceベースの方が分かりやすい。
何をそんなにも隠蔽したがるのか理解できん。

interfaceベースかどうかは関係ないだろ。
EJB3もinterfaceベースで作るのが基本だと思うが。
しかも、EJBコンテナだってDIを管理しているからDIコンテナとも呼べる。
アノテーションでDIの設定をするか、
XML設定ファイルに外出しになっているかの違い程度。

EJB3がまだ流行らないのは、まともな実装のアプリ鯖がまだ少ないからじゃね？
JBoss/WebLogic/WebSphereのJavaEE5完全対応版がリリースされたら、
Hibernate/Spring程度には使われるよ。

springとJSFで開発してみようかな・・・。

まだglassfishしか対応してないからな
今までのEJBとは別物だから普及するだろうね

どういうものかはSeasar2でTigerアノテーションつけたやつで試してみればいい
Springとは違う考え方でどちらかといえばGoogleGuiceが非常に近い

フィールドインジェクションできるってのは強いと思うよ
ロジックと直接かかわらないプロパティアクセスが消せるし
Springはそれを消すために深い継承してるわけだし

EJB3の一部実装として取り出したJPAは普及は確実か

コードに書くのか、外に出てるのかが本質的な違いであって
コードに書いたら、もうDIじゃねーと思うんだけど。
なんであれをDIと呼ぶのか、2年近くたつけどまだ納得できない。

EJB3は流行らないと思うよ。
もう今頃は塗り変わってるはずだったのに、一向にその気配がないし。
JBossだってコアな実装はもう済んでしばらく経つんだから
そんなにいいものだったらボチボチ広まってるはずじゃない？

商用AP鯖がまだ出てないと思うぜ
JavaEE5だけじゃなくJava2SE5というコア技術も変わるからかなり慎重だよ
Sunですらまだだしてないし
そもそもJavaEE5がでてまだちょうど1年しかたってないし

TomcatはJavaEE5の対応が今回は遅いね

あれ、まだそんなだっけ？＞一年
じゃぁもう少し見てみないと分からんのは確かですね。

>>476
インタフェースとかポリモーフィズムって知ってる？
それともアノテーションでDIすると依存関係が密になると思い込んでる？
JBossの実装だってまだRC。業務利用できるレベルの実装が無い現状では
普及してないのも仕方あるまい。

商用鯖リリース待ちだね。

JavaEE5仕様は昨年6月リリースだ。

JBossSeamと比べるとかなり見劣りするんだが。。

つかそもそも高い鯖買って（フリーもあるけど）EJB使うメリットって何ぞ？

>>477
Tomcat担当分はServlet2.5とJSP2.1だから、Tomcat6で既に実装済
EJB3についてはわりかし懐疑的だったけど、NetBeansでGlassFishを動かしてみて
印象が変わった。かなり簡単だし、IDEが標準サポートしてくれるのはやっぱり強みだな

今日はずいぶんお盛んだな。

AOPできるミドルウェア開発者が居たにも関わらず、
ドロドロの密結合しちまった現場事例：　　　　http://pc11.2ch.net/test/read.cgi/prog/1173529414/240

AOPできるミドルウェア開発者が居て、
疎結合をフレームワーク化した事例：　　　　　Seasar

この差は何で発生したのか判るか？

答：前者はたかひろチーム
　　後者はひがチーム

答はアーキテクトの違い

2003年時点で「アーキテクチャーの進化は終わった」とか言い出すような
「見えてない奴」がアーキテクチャ設計に関わった時点で、
そのプロジェクトは終わってるな。

さっさとAOPへのコミットを試みたｃ野氏の方が
よっぽど「見えてる奴」なのが事実。
・・・そこで方法論について権利争い始めちゃうのが
　　ダメっちゃーダメだけど。

>>478のしったかぶりにわろたｗ

そろそろ S2Dao を Spring で実装して
seasarにご引退いただこうぜ

seamはいいな
jsfが好きになった
springがそろそろ引退かもな

やっとSpringをかじり始めた・・・・

ようやっと季節もSpringになってきたというのに．．．

Spring始めるにはいい時期ってことか

バネもってこい

バッファローマン乙

Springの最新のリモートサイトってどこ？

右から２つ目のタブ

しかしGuiceのあの翻訳は何とかならんのか…。powered by Exciteかと。

>>498
自分で訳して公開したら？
言うは易し、行うは・・・ｗｗｗ

Spring終わったなSpring・・・・

>>498
翻訳されてるのか？
JavaDocとGuiceのソースとサンプルソース見ればだいたいおえるっしょ

Googleの翻訳はExciteが神に見えるくらいひどいのどうにかならんのかな

Spring自動登録できねーの？Spring

autowire のことか？

ちゃう

Seasar2みたいなのこと？

どちらかっつとGuice

デフォルト自動登録ってところがGuice
XMLで定義する場合はSpringでも良い

>>507
わかってないね。
Guiceは自動登録ではなく、getInstance()で指定した
クラスまたはキーから@Injectを芋づる式に
解決していくシステム。

@Injectの解決もModuleまたはインターフェースの
アノテーションで指定されているもの。

おまえらが話してる用語がさっぱりわからん。俺プログラマとしてｵﾜﾀ＼(^o^)／

>>507の知ったかに嫉妬

Springはインターフェースを登録できないの?
実装はXML見ればわかるけど、それのアクセサが
どのインターフェースをつかうのかなど継承階層によってはわからないのでは？

Springだお

Springが人気ないのか、>>512の発言が凍らせたのかｗ

guice使えるよguice

>>508
Moduleで指定が無くてもGuiceが自力で解決するんだおー

がおー







……

泣かなかったな、坊主。偉いぞ？

頭のおかしな人発見

ふむ。
Spring-annotationの1.1betaを試してみた。
ちょっと動いた。

これからWebアプリ1個作ってみる予定。
これでXMLから開放されればいいなぁ・・・。

アノテーションでグチャグチャなのも如何なものかと・・・・

規定事項

>>520
XMLでもアノテーションでもグチャグチャにしてくれるﾔｼは
どこにでもいるからね。ｗ

1番使えないのは人間だたりしまふ。
「な、なんじゃこりゃあ〜！」みたいな。

アノテーションとXMLを旨く使い分けられるフレームワークがいいな
どっちかだけってのはキツイな

>>519
ある程度触ったら使用感のレポよろ。

コンポーネント内で完結するならアノテーションも悪くないと思うんだけど
コンポーネント間の関連を記述するには、あまり適さない気がしてならん。
ちょっと触ってみた限りなので、使い方がヘタなのかも知れない。

>524
やってみまふ。
@Injectionとか出来たかなぁ…。

つーかこの時期にｲﾝﾌﾙｴﾝｻﾞはチトつらいっス。

>>524

>.コンポーネント内で完結
こっちはOK。

>コンポーネント間の関連を記述
こっちはNG。

あとXMLとアノテーションを上手に使い分けないと、頭の中でごちゃごちゃになりますな。

アノテーション使う時は、あくまでも簡素に。
TOAnnotationXmlApplicationContext と ClassPathXmlApplicationContext を
使い分ければ幸せになれるかも。なれないかも。

@RequestInterceptor というアノテーションもあるのですが、中身が空っぽなんですよね・・・。

さーて、どうしよう・・・。orz

最近Springを使い始めた者ですがSpringMVCについて質問です。
SimpleFormControllerはただリンクを貼って呼び出すものなのでしょうか？
requestで値を渡してformViewを表示させ、submitで色々処理したいのですが…。

その名のとおりフォームつかうやつだよ

ソースの円コーディングUTF-8ってどーよ

後場食った

>>529
メソッド名や変数名を日本語にしても問題起きないなw

>>531
別にUTF8じゃなくても問題起きないよ
クラス名はファイルシステムに依存するので問題おきやすいが

Javaエバンジェリスト達のコラムサイトでちょうどそんなようなクイズがあったな

サキエルは何番目の使途か？
とか？

お前は何を言っているんだ？

guiceアゲ

guiceアゲ

guiceアゲ

guiceアゲ

guiceアゲ

guiceってSpringと比べて何が良いの？

そうだね。guiceとSpringを比較した場合、次の相違がある。

仮想化とは対象物を不完全ながらもその性質や姿を模倣し現出させることだ。
対して抽象化は、対象物のある特徴的な側面を抽出し概念化することだ。
仮想化で抽象化の技術が使われることはあるだろうが、その逆は考え難い。
コンピュータを使い、扇風機やコタツを抽象化することはできても、仮想化する
ことはできないのだ。少なくとも今の技術では無理だ。コンピュータがその姿形
を変えることはできないのだから。コンピュータが仮想化できるものは、コンピュー
タそのものが直接扱うものだけだ。例えば、仮想メモリ、仮想ネットワーク、仮想
マシン、仮想キーボードといったものだ。

抽象化した結果表現されるものは、設計者が想定した概念やイメージだ。しかし、
実在するものそのものではなく、人が考えたものであるために、このイメージは
非常に脆く、不安定だ。外部からの影響をもろに受け、形を変え易い。個々人が
持つイメージの些細な相違から認識のずれが生じ易い。扇風機の使い方は人に
よって異なることはないが、人がイメージしたものは、その生成から、破棄に至る
まで、非常に不安定な状態になり易い。それを防ぐには、イメージそのものをなる
べく強固なものにし、インターフェースに一貫性と整合性をもたせ、外因による影響
を受けに難くく、壊れ難くするための技術を見につけ、理解を深めておくしかない。

>>542

なるほど〜
どっちもどっちってことね。

さすがにそれはない

ｊuiceアゲ

guiceアゲ

seasarあげ

ソースにコメント入れんやつの作った物なんか使えるかい!

ソースに醤油入れんやつの作った物なんか使えるかい!

RmiServiceExporter を使って特定の RMI サーバを提供しています。
アクセスが集中した際無尽蔵に増やしていくと落ちてしまうので
スレッド数等で制限したいのですが、何かうまい方法は無いでしょうか。

springさげ

Interface21 (Spring) gets 10M VC Funding
ttp://www.infoq.com/news/2007/05/interface21-gets-funding

お前らSpring使ってて困ったり悩んだりした時どうしてる？
英語不自由だから本家のフォーラムに質問は辛いんだよね
日本語で親切に教えてくれる人どっかにいないもんかねー

甘いな

甘いのか…
自力でどうにかする自信ないしSeasarにしようかな

コメントもドキュメントも無いからなー
その分じゃ自分でコードを追っかけるのもあれなんじゃない？

正直自分でコード追っかけるしかないのは無理

じゃあ自分でゴリゴリ作るしかないな

つーか転職した方が（ｒｙ

>>559
履歴書買ってきますた

GJ！！

>>560
安心しろ
この業界、プログラムなんて組めないほうが偉くなれる。
学歴はないとダメだけどな

>>562

>>562
こういう意見をよくみかけるが全く賛同できない
プログラムを書きたくないやつがなぜこの業界にいるのか疑問だからだ
収入もすくないし先行きも不安定なこの業界になぜあえて留まりつづけようとするのか

>>564
賛同？ 現実を見たくないだけだろｗ
プログラミングなんてシステム構築のごく一部に過ぎないんだよ

プログラム書けるより
レビューできるほうがいいかも

>>565
ん？わかりにくかったか？
仕事に喜びがないのに、3K低収入のこの業界に留まり続けるのは何故かと言っている。
>>562が正しいかどうかは、全く関係ない

事業企画やらプロジェクトマネジメントやらができるんなら
ＩＴ業界じゃなくてもいいじゃんってことでしょ。同意。

>>568
そう、それがいいたかった

IT業界で優秀なプロマネでも他の業界じゃ並以下だからとか

>>564
収入が少ないのは下請けの下っ端だからだろ？
もしくは派遣

ヒント： 構造不況

うまく元請け大手SIer(国内メーカー系除く)に潜り込んだら
頭使わなくても高収入なんだから転職する理由はない
拘束時間が長いのは辛いが…

大手SIerって、はじめからPGいないだろ
PGからステップアップっていうルートが無いよ

社会人経験無いんだから知らなくても仕方ないだろ

Spring の話しようぜ

spring-ws がなかなか正式リリースにならんなあ

SpringからS2Daoって使えない？

>>577
n-ichimuraの日記?

昨日からspring使い始めたんだけど、applicationContext.xmlファイルがすごい状態・・・
これって普通？

だいたいそうなる。XML Hell。
分割すればちょっとだけマシになるかも。

>>579
なにをコンポーネントとして登録するかによる。
初心者のうちはなんでもかんでもコンポーネントとして登録してむちゃくちゃになりやすい

>>581
どういうのをコンポーネントとして登録するのがいいのかねえ・・・。

ステートレスなサービスやファサード、DAO
が代表的

サービスってどういう単位？でわければいいの？

ファサードやDAOだったらGuiceでいいや・・・

俺は
1. anonymousで可能なfind系
2. anonymousで可能なadd、update系
3. 認証が必要なfind、add、update系
の3種類を作ることが多い。

?

アホか。基本、全部xmlに入れるべき
DIPはOOの基本原則であって、可能な限り全てのクラスが従うべきもの
って、んなことわかんない奴が使って意味あるのか？

今度２年ぶりにJavaでシステムを構築することになったんですが、
springは使うとして、ViewとController周りとORMあたりの
フレームワークってなにがお勧めかしら。

今でも、Struts、Spring、Hibernateなのかしら？

>>588
くまー

　　　　　　　　　　　　　　　　　　　　　　　　　　 　　　　　　-‐ '´￣￣｀ヽ､
　 ┏┓┏┓　 ┏┓　 ┏┳┳┓　 　 ┏┓　　　　　 ／　／" ｀ヽ ヽ　　＼.　 　 　　　　　 　 ┏┓┏┓
　 ┃┗┛┃┏┛┗━┫┣┻┛┏━┛┗┓　　　//, '/　　　　 ヽﾊ 　､　ヽ 　 　 　 　 　 　 ┃┃┃┃
┏┛　 　 ┗╋┓┏┓┃┃　 　 ┗━┓┏╋━━/. {_{＼　　　 ／ﾘ| ｌ │ i| ━━━━━┓┃┃┃┃
┃┃┃┏┓┃┃┃┃┣╋━━┓　 ┃┃┃　　 ﾚ!小ｌ●　　　 ● 从　|、i|　　　 　 　 　 ┃┃┃┃┃
┃┃┃┃┃┃┃┃┃┃┗━┓┣┓┗┛┗━━ヽ|l⊃　､_,､_,　⊂⊃　|ﾉ│━━━━━┛┗┛┗┛
┃┃　 ┃┃┃┃┃┃┃　 ┏┛┃┗━┓　 /⌒ヽ__|ﾍ　　 ゝ._）　 　j /⌒i !　　　 　 　 　 　┏┓┏┓
┗━━┛┗┛┗┛┗┛　 ┗━┻━━┛ 　 ＼ /::::|　l＞,､ __,　イァ/　 /│　 　　　　　 　 ┗┛┗┛
　　　　　　　　　　　　　 　 　 　 　 　 　 　 　 　 　/:::::/|　|　ヾ:::|三/::{ﾍ､__∧ |
　　　　　　　　　　　　　　　　　　　　　　　　 　 　 ｀ヽ< |　|　　ヾ∨:::/ヾ:::彡'　

>>589
あんまり変わってない感じがする。
Hibernate のかわりに JPA も視野に入ってきたくらいで。

View/Controller については、そもそもなんでブラウザで動かしたいのかって時代では。
ここ1,2年は数年前に作ったWebアプリを
リッチクライアントで作り直す案件が多いように感じる。

Spring2.0入門買って来た。
Spring Web Flowってよさそうなんだけど、使ってる人いる？

つかSeasar使わないおまいら、非国民？

>>594
釣られクマー

>>594
　　　　　　 ,-┐
　,ｨ─､ri´^-─- ､ .┌f^f^f^f^f^f^f^f^f^┐
く　　/ ,　,'　　 ヽ　ヽ|　~ ~ ~ ~ ~ ~ ~ ~ ~│
　`<' / ,'ﾚｲ+tVvヽ!ヽﾄ　知ってるが　　│
　　!/ ,' i |' {］　, [}|ヽﾘ 　名前が　　　　 |
　　`!_{ iﾊﾄ､__iﾌ,ノリ,ｎ 　 気に入らない |
　　 ／/ (^~￣￣∃_ア____n＿＿＿＿＿|
　_r''‐〈　 `´ｱ/ﾄr──!,.--'
<＿>─}､　　`」ﾚ
'ヽ､　　 ,.ﾍｰｧtｲ
　　 Y､.,___/　 |.|
　 　 |　　i `ｰ'i´

Struts+Springについて勉強始めました。いまはSpring入門(2.0でないほう)を読んでいます。
Springそのものはバッチ等のUIが絡まないところで使っていましたが、webアプリで使うのは今回がはじめてです。
(Strutsも単体では経験があります)

>>33-45 を見てみましたが、ActionクラスでビジネスオブジェクトをDIで取得する場合、
getBean()ではなくsetter injection のほうがいいということは、
ActionSupport方式ではなく DelegatingActionProxyがいいということですか？
Spring入門によると、DelegatingActionProxy だと struts-config.xml と action-servlet.xml の
2箇所で定義が必要なので面倒という記述があり、私もそう思っていたので、
>>33-45 の流れのメリットがわかりません。
どなたか教えてください

>>597
とりあえず↓よめば？
http://kakutani.com/trans/fowler/injection.html

メリットはいろいろあるけど、DelegatingActionProxyのほうがテストしやすいよ

>>598
レスどうもありがとうございます。帰りの電車で読んでみます。
たびたび質問で申し訳ありません。2点聞きたいことがあります。

○1.
Struts + Spring を使ってビジネスロジック(ビジネスオブジェクト)を Action に DI したとしても、
ビジネスオブジェクトのメソッドの引数は web 層を引きずってはならないから
public Interface KeiyakuService {
　KeiyakuInfo getKeiyakuInfo(String keiyakuId, String bushoCode, Date nendo);
}
みたいに細かく切り出しますが(ActionFormをそのまま渡すなどしない)、Struts + Spring 連携をしたとしても、
Action の execute() の最初のほうで、ビジネスロジックを呼び出す前に
ActionForm から HTML Form で入力された入力値をせっせと取り出す作業は変わらない、という認識はあってますか？

# Spring とは直接関係ありませんが、ビジネスロジックやユーティリティクラスに
# ActionForm や HttpServlet を引きずりこまないように＆楽するために、
# reflection(BeanUtils)を使って ActionForm からEntityクラスへの変換クラスを
# 自作して使ってますが、もうすこしどうにかならないかなと思う

○2.
DelegatingActionProxy から Action に処理が移っても、Action クラスは Struts を
生で使うときと同じようにスレッドセーフにしておかないといけないと理解してますが、
Actionクラスにビジネスオブジェクトを DI する場合、ビジネスオブジェクトもスレッドセーフに
作っておかないといけないのでしょうか？
・Actionクラスはインスタンスがひとつだけ
→ActionクラスのフィールドにビジネスオブジェクトのインスタンスがDIされるので、
　そのActionに同時アクセスがあった場合、ビジネスオブジェクトの単一のインスタンスが
　すべてのアクセスのスレッドで使いまわされる？

>>599
598氏じゃないが。

Q1 はその認識であってる。詰め替えがアホらしいのは確かだが、
ある程度自動化するフレームワークも出てくるだろうし、あるいは自分で作ってもいい。

Q2 については「ステートレス万歳」の方向が良いかと。
ステートフルなロジックを作成して、スレッドセーフになってるか、その必要があるかに時間費やすよりも、
そのロジックをストートレスに出来ないかを考えた方が、早くて確実で見通しが良い。時が多いと思う。

時は皆に平等です。

>>599
598だが。

>>600さんに同意です。
ビジネスロジックにリッチドメインモデルを使う場合以外は
スレッドセーフを徹底すべきでしょうね

>>599
dozer使っとけよ・・・

Struts + Springなら、AutowiringRequestProcessorもありかと

http://d.hatena.ne.jp/sugapico/00000003/1118125623
上記サイト通りやったのですが、最後のInternalResourceViewResolverの定義がうまく行きません。

どうしてでしょうか？

実際のソースは以下の通りです。
<bean id="exampleController" class="example.ExampleController"/>
<bean id="secondController" class="example.SecondController"/>
<bean id="urlMapping" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
<property name="mappings">
<props>
<prop key="/test.html">exampleController</prop>
<prop key="/test2.html">secondController</prop>
</props>
</property>
</bean>

<!--ViewResolverを使う場合：何故か出来ない-->
<bean id="viewResolver"
class="org.springframework.web.servlet.view.InternalResourceViewResolver">
<property name="viewClass"><value>org.springframework.web.servlet.view.JstlView</value></property>
<property name="prefix"><value>/WEB-INF/jsp/</value></property>
<property name="suffix"><value>.jsp</value></property>
</bean>

public class ExampleController implements Controller {

/**
* @see org.springframework.web.servlet.mvc.Controller#handleRequest(javax.servlet.http.HttpServletRequest,
* javax.servlet.http.HttpServletResponse)
*/
public ModelAndView handleRequest(HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException {


// return new ModelAndView("/WEB-INF/jsp/test.jsp");
// ViewResolver
return new ModelAndView("test");

}

}

エラーは以下のようなものです。
致命的: サーブレット example のServlet.service()が例外を投げました
java.lang.NoClassDefFoundError: javax/servlet/jsp/jstl/fmt/LocalizationContext
at org.springframework.web.servlet.support.JstlUtils.exposeLocalizationContext(JstlUtils.java:83)
at org.springframework.web.servlet.view.JstlView.exposeHelpers(JstlView.java:82)
at org.springframework.web.servlet.view.InternalResourceView.renderMergedOutputModel(InternalResourceView.java:90)
at org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:246)
at org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1000)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:761)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:684)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:394)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:348)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:874)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528)
at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:689)
at java.lang.Thread.run(Unknown Source)

実行時にJSTLの実装ライブラリが無いんじゃないか？
アプリケーションサーバに含まれているか、あるいはアプリケーションの/WEB-INF/libに含まれているか確認。

最近の狛犬もどきのカリスマ

今度はJPA仮想敵で俺達サイコーやってます。
「*2JDBC」のセールストークでマーチン・ファウラーの
「流暢なインターフェイス」引用してますが、JPAの
インターフェイスをパクっている時点で既に論理的に破綻してます。
JPAベースで流暢なインターフェイスを実現するラッパーは作成可能であり、
流暢なインターフェイスを実装していることが「*2JDBC」のセールスポイント
にならないことは明らか。
CoC(規約重視)マンセーで使った偽太陽etcがユーザ層の拡大に失敗している
からCoCやめてみました、それだけ。

特定のDIコンテナに統合されている時点で「*2JDBC」は個人的には利用対象
外、モノは悪くないとは思うが狛犬もどき２に依存する気にはなれない。

"CoCの本質は最低限の規約で最大限の効果を得る"ことにあり、規約でがんじ
がらめにしている時点でCoCを語る資格はない。
偽太陽をみるとわかると思うが「狛犬もどき」はCoCの本質を理解していない。
例えば、偽太陽の属性の扱いまわり、実装で楽をするためにあんな変な規約
を導入しているとしか思えない。
Clickマンセーな人でも偽太陽マンセーな人は少なく、狛犬もどきの信者だけが
偽太陽マンセー。

狛犬もどきの失敗は「狛犬もどき２」の中で閉じた世界を構築していること。
外側からみると、狛犬もどきの信者はハイレベルとは呼べないと感じる。
「"*2JDBC"が流暢なインターフェイスを実装しているから流暢なインターフェイス
でないJPAより優れている」等のセールストークに騙される時点でおわってる。
「狛犬もどき」自体の開発者のうちカリスマ他数名はハイレベル(?)なんだろうが...。
新しいプロダクトをリリースする度に行われる「セールストーク」の質の低さには
ウンザリ。

Seasarの煽りuzeee

ウザイと言うか・・・こんな書き方するってずいぶんとまぁ・・・
池沼にはウンザリ。

狛犬とか太陽とかいうのはうざいが、同意する部分あるな

ASIP乙

内容に自身があるなら隠語や伏字やめれ。読みにくい。
どっかのスレの雰囲気を持ち込まれても困る。

sessionFormをtrueに設定したんですが、このあとどうやってsessionを取得すればいいのでしょうか？
どなたか教えてください。

Scopeのsingletonとglocal sessionの違いを確認できるような
構成ってどんなものがあるでしょうか？違いがわからんです。

前期のシグルイに今期のカイジ、渋い作品は探せばいくらでもあるが単にﾔｼらの趣向に合わんだけだろ
萌えとかいったって細かい趣向の違いがあって妹13人とか30人に囲まれたいﾔｼには今期はもの足りんだろうしな

なんというSpring萌・・・

Spring2.5はすごいな
GuiceやSeasar2の価値をゼロにしたかもしれん

>>619
どのへんが？

>>620
妹13人とか30人に囲まれたいとか

基本的にコアは 1.1.x で完成していて、
1.2.x 以降は設定ファイルの書式が若干良くなったり
かえって悪くなったりしてるだけじゃなかろうか。
(XML 名前空間は使いにくいから失敗だと思う。
機械が読むには悪くないけど、人間が書くには疲れる。)

spring-ws や spring-webflow みたいなサブプロジェクトが
どれだけ完成度高めていくかと、
新たに面白いサブプロジェクト生まれないかなぁって辺りに関心がある。
コアのバージョンはもうどうでも良いって言うか。

Guice や Sesar2 はハナから問題外じゃね？
デファクト取っちまってるプロダクトがどうしたって強いし。
あとは Rails にだまされてる人達が
どれだけ早く DI の妥当さに気がつくかだけでしょ。

膣内射精断面図はまだですか？

>>623
明日の１３時にアルタ前で、直接手渡します。
ロッドジョンソンのTシャツを着て待っていてください。

相も変わらずG'sは狂ってるな。１９人の姉妹だとよ
ttp://gs.dengekinet.com/suteki/

オレの嫁達紹介　全員判別できたら通報する
ちょっと生意気だけどご近所の子のアイたんって子がマジ可愛い。リボンの似合うキュートガールなんだ＾＾
オレの同居人のかなみたんも可愛いすぐるんだ。なんか思考読まれてるんじゃないかってほど、的確に動いてくれて役に立つし＾＾
他の女の子の話してると、彼女のロゼッタたんがディアボロで殴ってくるからそろそろやめとくか＾＾
オレのいとこのあすたんも可愛いんだ。貧乏だから色々支援してあげてる＾＾
ちょっと怖いけどオレにとりついてる幽霊のコゼットたんも好き。今はコップの中に引きこもってでてこないけどさ＾＾
妹のクリスマスたんに女の子の話するとちょっと動揺したように逃げてくんだよね、普段読まないのにこっそりファッションの本とか読んでるの見たときはちょっと萌えた＾＾
近所に住んでる蘭たんはすごいポーカーフェイスでいっつも狐のお面をかぶってるんだけど、オレには優しさと笑顔を見せてくれるんだよね。可愛いすぐるぜ＾＾
幼馴染のテッサてんはクリスマスたんよりおいしい料理を食べさせてあげる！とか毎日いきまいてるけどなんでだろう＾＾
でもドジだからいっつもなにか間違えるんだよなぁ。まぁそこが可愛かったりするけど＾＾
同じ職場のルリたんは皮肉屋でいっつもオレのこと小ばかにしてるけど。本当はオレにぞっこんなのは裏とれてるんだなぁ＾＾
お隣に住んでるアナたんは苗字で呼ぶと怒るんだけど、それがまた可愛くてやめられないんだ＾＾
クリスマスプレゼントでうちにきた電波系の自称オレの妹ちょこたんは本当に純粋無垢で可愛いんだなぁ＾＾
これまた近所の桜田さん家に遊びにくる金糸雀たんも激萌えなんだ。ちょっと頭足りないから、口喧嘩でいじめるのが楽しい＾＾
前ジャングルに行ったとき出あった女の子のマリィっていう子も可愛いんだなぁ。好きな人がいたみたいだけど振り向いてくれないらしく
オレが甘い言葉囁いたらすぐ落ちた。でもずっといるとちょっと疲れる子なんだよね＾＾
以上13人がオレの嫁

age

Spring Dynamic Module が良く理解できないんだけど

Struts2のアクションをダイナミックに変更できたらいいなーと思ってるけど出来そう？

>>560
いまどき履歴書なんて買うなよ。
OpenOfficeで書け。
写真は携帯電話で撮ってOpenOffice Write文書に貼り付けろ。
履歴書は面接先企業にメールで送りつけるのが現在の常識だ。
面接ではノートPCを持ってプレゼンし、自作プログラムを持参し、
自分の能力を強力にアピールろ。

>>571
派遣は下手な零細企業の正社員よりも稼げるのが現実

アピールろ

Spring2.5使っているのですが、
RequestスコープのBean内でServletRequest自身にアクセスするには
どうしたらよいのでしょうか･･･

死ねばいいと思うよ

きがつけばSpringはもう2.5か

2.0 と 2.5 の違いをざっと読んでみたんだが
アノテーションをもっと全面的に押し出しますよって事？
個人的にはイマイチだな。

>>634
中身がごっそりリファクタリングされて爆速化している。

アノテーションは使ってもいいし、使わなくてもいい
ファサードが使いやすくなるので個人的には歓迎

切り分けたい外部インターフェースは明示的にxmlに書けばいいし問題はないね

@Resource、@PostConstruct、@PreDestroy
とかのCommon Annotationsがそのまま使えるのはメチャメチャ便利だからすでに多用しまくり。

Springってバランス取れてるんだよね
標準技術で使えるところは使う、さらに拡張がほしければどうぞとか
Seasar2は自前でなんでもやったるというのが多すぎる希ガス

>>638
Seasarもそれなりに標準サポートしてる。@Resourceなんかも使えるぞ。
S2Xxxで他のフレームワークとの連携もやってるがSpringほど手広くは
できないのが国内限定の辛さだな。

>>634,635
thx.
ここ最近スレが静かで寂しかったけど、ちゃんと人居て安心した。
トランザクションの記述はシンプルになるので
使える場面では積極的に使おうと思う。

>Seasar2は自前でなんでもやったるというのが多すぎる希ガス
何にフォーカスしてるのか一言で言い表せないプロジェクトが多くない気がする。
シンプルで高性能(!=高機能)なツールをどう組み合わせるかが技術者の腕の見せ所なんだけど
組み合わせの自由度が思いのほか少ない。

日本語ドキュメントがあるSeasar2より日本語ドキュメントのないSpringのほうが
扱いが楽ってのもどうもしっくりこないな

>>640
「Next J2EE（笑）」とか「ブルーオーシャン（笑）」とか軸がぶれまくったのが悔やまれるな。

Seasar2ってJavaSE6対応してるの？
Springは2.5で対応したけど

SE6対応は分らんけど、アノテーションの利用に関しては
Spring よりも積極的だったと思う。

でもドキュメント関連は壊滅的。
日本語ドキュメントとか言っても紹介レベルのものだし。
10の事を知りたいのに1しか教えてくれない日本語ドキュメントより
10どころか20や30書いてある英語ドキュメントの方が嬉しい。

Seasar2 の話題は↓で

国産DIコンテナSeasar その12
http://pc11.2ch.net/test/read.cgi/tech/1203122931/

>>645
イラネ

ttp://logch.info/logs/jun.2chan.net/b/src/1204003806653.jpg
妹の惑星を思い出した

spring2 + struts2で開発しようとしてるが、
webapplicationContextへのアクセスで困ってます。

spring2 + struts1では、ActionSupport経由でできるらしいが、
struts2には対応してない。

どーしたら良いの？

2.5 の DL パッケージに入ってる HTML ドキュメントが巨大な 1ファイル HTML なのは何故；？
本家の
http://static.springframework.org/spring/docs/2.5.x/reference/index.html
これみたいな分割 HTML ドキュメントは配布してないの？

>>648
http://struts.apache.org/2.x/docs/spring-plugin.html

>>648 ぐぐれかす

SpringMVCってあんまり使われてないの？
わざわざStrutsと組み合わせるの面倒くさくない？

世間的には Struts がまだまだ強いんだよ・・・

個人的には SpringMVC + Velocity が一番だと思うが。
JSP なんて気持ち悪くて触りたくない。

つまりRailsもカスだと？

VelocityもJSPとかわらんだろ
むしろツールのサポートがあるJSPのほうが楽なことも多い

ttp://cubby.seasar.org/ がSpringで使えるようになったらうれしい。

>>655
SAStrutsの方ならSpringで使えるようになる
ttp://d.hatena.ne.jp/higayasuo/20080401/1207016839
> SAStrutsとS2JDBCもSuper Agile Spring上に移植する予定です。

>>654

POJOのパラメータありメソッドをサクサク呼び出せるのがVelocityの良いところ。
JSPでもFunctionとかあるけど、staticメソッドのみなうえにtdl書くのが死ぬほど面倒くさい・・・
ツールはEclipse+VelocityWebEditでコード補完もバッチリできるよ。

>>653

自分も数年間JSP⇔Velocity両方使って試行錯誤してたけど、
SpringとかDIとの相性がいいからVelocityに落ち着いた。

>>657
velocityだとデザイナとの分離が不可能
分離しないタイプならJSPのほうが融通が利く

テンプレートとしては好きだけどね

>>656
4/1だもんな。
それに、Strutsはいらない。

>DIとの相性がいいから
DI云々よりも目的がハッキリしてるから好き。
どうせテンプレート機能しか使わないんだから
(タグ作り始めるとコードの暗号化を進めるだけ)
そっちに特化してる方が何かとシンプルでやりやすかった。

JSP のコンセプトがどれだけボヤけてたかは
その後に JSTL + EL を取り込んだことで自明でしょ。
最初からそれやっとけよって話。

コンセプトというか、単にASPやPHPの対抗馬として作っただけだしな

>>660

たしかにカスタムタグ自前で作り始めるとわけわかんなくなる…

JSPはスクリプトレットベースだったのを無理やりJSTL+ELを加えて
あげくにスクリプトレットレス推奨になってる時点でスコープやらなにやらグチャグチャになってると思う。

>>658
デザイナとの分離ならむしろ圧倒的にVelocity有利では？？

#foreach や#parse がデフォルトで無限ループができないようになってたり、
デザイナとの分業は余計な問題が起こらないようにいろいろ考えられてるよ。

FreeMarker はどうよ？

View 層に jsp より Velocity というのは自分も同意だが、
SpringMVC は、作らなければならないクラスが多い気がしてあまり好きじゃない。
なんつーか冗長というかめんどくさい。
おれがわかってないだけかもしれないけど。

>>662
デザイナは通常DreamWeaverとかつかうからjspはhtmlと同じように扱えるんだよ
しかもtomcat連携も可能で動的htmlを表示したままcss設定できたりな

>>664

SpringMVCはなんかクラス名がピンとこないのが多い・・・
Model、View、CommandとかMVCでいうと実際にはController部分（？）なのに
紛らわしい感じで混乱する。

SpringMVCはシンプルで薄いラッパだから迷うことはないと思う
2.5とそれ以前とでだいぶ中身は違うと思うけど

>SpringMVC は、作らなければならないクラスが多い気がしてあまり好きじゃない。
ModelAndView と Contoroller 作るだけなんで
これ以上に少なくってことになると
Teeda で Page に全部詰め込むか
Tapestry で PHP 的なプログラミングするしかない。

SpringMVCはどちらかといえばDIベースで作られているのだから
いくらでも好きにいじってください、というものだと思うが

Viewに他のフレームワーク＋Springよりはるかに融通は利くのだが
機能がほしいのならStripseとか普通に使ったほうがいいと思う

Springの他のDIコンテナの追随を許さない圧倒的な利点は
自前でも用意はするし、他のフレームワークの連携も最大限に考慮することだから

>>669
Struts連携もHibernate(JPA)連携もSeasarの方が上。

ラップして存在を隠すことを連携と言うならそうだろうな。

SeasarってJPAとの相性そんなにいいか？
まずトップがJPAを消そうとしてるように見えるんだが

>>672
Kuina＞＞＞＞越えられない壁＞＞＞＞JpaTemplate
簡単な問合せはインターフェース書くだけ
ttp://kuina.seasar.org/ja/user_guide/query.html
複雑ならCriteria
ttp://kuina.seasar.org/apidocs/org/seasar/kuina/dao/criteria/CriteriaOperations.html
SQLサポートも強力
ttp://kuina.seasar.org/ja/user_guide/query.html#SQLによる検索
EntityManager直に使うこともできる。何も隠されてない

どうでもいいけど、Springスレにまで出張するのは頭おかしいとおもうんだ
スレまちがえてないか？

それにSpringだってEJBのように直につかえるよ
そもそも何も考えずつ変えるという意味でJPA使うのならEJB3使うのが一番効率的だと思うけど

もともとJPAはオブジェクトプール用に設計されてるからね

>>674
>672の問いに答えただけだが

> JPA使うのならEJB3使うのが一番効率的だと思うけど
EntityManager使う面倒さは何一つ解消しないしそもそもSFSBが効率的じゃない

何を根拠にSFSBといきなり限定的な話になるのだ

それにステートフルが怖い人ですか
セッションになんでもかんでもぶちこむより活性化、否活性化がちゃんと動くEJBでやったほうがまし
Seasar2ってその辺全部やってくれるの?

>簡単な問合せはインターフェース書くだけ
で、_NOT_IN やろうとして失敗して、
コード見たら失敗するのが当たり前で、
ローカルで修正して JAR 入れ替えたらきちんと動いて、
ああ、やっぱり俺悪くないわ、ろくにテストされてねーじゃんとか思うわけだ。

このレベルの項目すらテストされてないのに
他が題目どおりに動くことなんて微塵も期待できない。
それでも Kuina サイコーだってんなら好きにしてくれ。

>>676
> 何を根拠にSFSBといきなり限定的な話になるのだ
SLSB+JPAはメリットないからSFSB+拡張コンテキスト限定に決まってるだろ常考
それともSLSB+JPAが効率的とか書いたのか？何が効率的なんだ？

> セッションになんでもかんでもぶちこむより
なんでもぶちこんだらSFSBでもだめだろ

> 活性化、否活性化がちゃんと動く
拡張コンテキストがあると非活性化されない

>>677
コミッタに教えてやれよｗ

>>678
拡張コンテキストについて詳しく

>>680
SFSBのライフサイクルに合わせた寿命の長い永続コンテキスト
永続コンテキストはキャッシュみたいなもん

>>680
トランザクション境界ぬけたら非管理下におかれるんじゃないの？

>>681
だった。

>>682
それ通常の永続コンテキスト

KuinaもJPAもEJBもスレ違い

「Java⇔RDBのMapping-Frameworkを語るｽﾚ Vol.4」
ttp://pc11.2ch.net/test/read.cgi/tech/1134701684/

>>684
なら拡張つかうのやめれば？

むしろSFSBはWebに紐付けしないといけないほうが問題。

seamはそのためにあるともいう。

>>686
通常のコンテキスト使うならEJB使うメリットはない
SpringでもSeasarでも同等
>674が言うEJBが効率的てのは何なのかと
スレ違いらしいから続けるならO/Rスレで

>>686の発言はいみふ

>>688
SFSB使ったことないのかい?

Swingクライアント+SFSBならWebと紐付け不要

>>690
揚げ足取りイクナイ

ロジックをステートレスにするのは
フレームワーク側の都合にプログラマが合わしてるだけで
本来の姿じゃないって発言をたまに見かけるが、
ステートフルにするとプログラマの能力を超えてしまう事が多数。

つーか、ステートフルであることがアプリケーションの基本でしょ?
そんな基本ができないやつはいらね

難易度が高いのならともかく、基本がないやつは退場してもらったほうが業界のためにいいよ

>>693
ロッド・ジョンソンに言ってこい

>>693
何が基本なんだかさっぱりわからん
そんなもんケースバイケースに決まってるでしょ

ステートレスだのステートフルだのうるさい奴らはSpringの設定を全部シングルトンにしてそうだ。

ステートレスなロジックオブジェクトとステートフルなエンティティオブジェクトのみで
作られたプログラムなんてオブジェクト指向とは到底呼べない。

>>696
オブジェクト指向と呼べるかどうかには興味はない

>>693
イミフ

>>693
退場してください

オブジェクト指向万歳！！

>>697
オブジェクト指向と呼べるかどうかに興味は無くても
保守性の高い見通しのよいプログラムには興味あるだろう？

ロジックオブジェクトとエンティティオブジェクトを明確に切り分けるのは
そういう観点でも"うまいやり方じゃない"と俺は思うんだが、どうだろう。

>>701
保守性の高い見通しのよいプログラムには興味あるだろう？

ロジックオブジェクトとエンティティオブジェクトを明確に切り分けるのは
そういう観点でも"うまいやり方"と俺は思うんだが、どうだろう。

「保守性の高い見通しのよいプログラム」を定義してくれ
オブジェクト指向(笑)にすると自動的に保守性が高くて見通し良くなるの？

　　　　　 　 　 ,. .‐'テ'ｰ､-. .､
　　　 　 　 ／: : :/ : : : : ヽ : : ＼
　　　　 　 ! : r‐┴‐-､: : : l : : : :l l
　　　　　,.��にﾆﾆﾆﾆlュｭ_l: : : :_l:｣__
　　　／　　　,.ｨ ／"＾l　ﾄ､　￣｀`Tﾆ＞
　　/イ,ｲ / /ｺ/┐　iﾋﾍl'ﾆゝ、 　 |　　　　　言ってみろよ…！
　　　l/ lｲ/l＝=aﾞ　 ,,=a=＝:l r=､ |　　　　　能書きたれてみろ…
. 　 　 　 　 l.`ー_）　　 ー '　|.|ｈ.} |　　　　　聞いてやるよ…
　　　　　　　l　「 ＿＿_ 　 u |Lノ :ﾄ､
　 　 　 　 　 ヽ ‘ｰ─‐’　／ﾞヽ　 |: :「:Tｰ-
　　　　_,,　.-‐'|＼ ￣　／ 　 u ＼| : |:::|: : :
　‐'' ´: : : : : : |::|: l`:イ　　　　　　 l : j|:::|: : :
　: : : : : : : : :.:|::| : i : ヽ　　　　　ノ : ﾉ|:::|: : :
　: : : : : : : : : |::|: : :＼ :`:ｰ-‐ ': : ／: :|:::|: : :

>>702
それもそうだな。保守性の高い見通しのよいプログラムっていうのは
多分に人間の感覚に依存してるものだから一概に言えないけれど、

1.プログラムを変更する際に目を通さなければならないファイルが少ない
2.関連するデータと手順は近いほうがよい(推測できる or 同じ場所にある)

上記二点が備わっていたら保守性が高いと言えるのじゃないだろうか？
で、1.の点に関してはロジックとエンティティが同じの方がいいと思える。1ファイルですむからね。
2.の点に関してはロジックとエンティティを似たような名前にする事でどちらでもある程度解消できる。

ただし、プロジェクトでの名前付けの統一に失敗するとロジックとエンティティを切り分けるやり方は地獄を見る。

オブジェクトの責任の切り分けに失敗して巨大なオブジェクトに多量の処理をさせると俺の主張するやり方のほうが地獄を見る。

だから"メンバーに命名規約を遵守させることが出来る"なら702のやり方でもさほど問題ない。
"メンバーの設計が一定レベルにあることを保障できる"なら俺のやり方の方が冴えてる。

と、思うのだがどうだろう。ちなみに俺はオブジェクト指向についてはそれほどこだわらない。
分かりやすく保守しやすいコードを一番重視する。

　　　　　　､-‐- ､,. z_
　　　＜￣　　　　　　 ゝ
　 ∠´　　　 /Vヽ　　　 ゝ
∠　　 ∧/`'　　ﾑ,　　　　ヽ　　　なんや　おどれと話をしてると
∠/レ'　　　　　　ム　 _,_　 `、
　| 　 ,.−　　　　　 ヾ（へヽ　ヽ　　　わいも落ちるとこまで落ちたって
　|／　／ﾄ､ }　　　　ヽV~) ）　 ヽ　　　　気になるわ…
　＼ ヽ ノ ､ｼ　　,.ｲ　　 ヾ '　 　 }
　,/　　 `｀　ｰ-―- ､　　ヽ.　　　l
　L　r っ　 _. -‐ォ　 ）　　 ）＼　／⌒ヽ
　　　 (二´-‐_'´ノ　　　 ／　 .／　　　　〉、
　　 　 (二´-‐ '　､ ` ／　,／　　 　 　 /　＼
　　　　　 ＼ヽヽ` ／　／/　　　　　　/　　　ヽ
　　　　　　　` ｰ 'ヽ／　/　 　 　 　 , ' 　 　 　 ヽ
　　　　　　　　　　/ヽ. /　　　　　／　　 　 　 　 ヽ

特にwebアプリケーションにおいては、ステートフルなオブジェクトが多いと
スレッドセーフとパフォーマンス面で実装が難しくなって
かえって複雑になるという現状があるからなぁ。

つまり結局「有能な人間を集めればうまくいきます」ってこと？
もはやオブジェクト指向もDIコンテナも関係ないな(爆笑)

どうしてそんな結論に至るのかまったく理解不能。

>>707
現状じゃなくて昔はの間違いでは?
マシンパワーが低いとかの問題で。

スレッドセーフの問題はどちらの場合でもついてくる。

>>664
FreeMarkerってstruts2が中で使ってた

HibernateもFreeMarker中で使ってるんじゃなかったっけ。

VelocityよりFreeMarkerの方が二番煎じな分だけ使いやすい気がする。

微妙にスレチ下げ。

Spring1.3→2.5とジャンプアップを企んでいる者です。
質問なのですが、アノテーションを使ってDIしてる場合、UnitTestってどうやりますか？

1.3の時代はsetterインジェクションをしていたので、
ドライバクラスからテスト対象クラスをnewし、スタブクラスをsetしてやればテストできたのですが、
アノテーションを使うとsetterが無いのでスタブをsetできません。

この場合、UnitTestでもSpringを使う必要があるのでしょうか？

>>713
アノテーション使おうがsetterを使えば同じようにできる
フィールドインジェクションの場合は無理

でも、AOPとかトランザクションとか複雑に絡み合うコンポーネントを考えると
単体テストでもコンテナから呼び出したほうがいいかと

結果、ある程度の結合テストができていると考えていいし


問題が大きいようだったら2.5でもアノテーションつかわなくてもいいんだよ
2.0までのやり方でも問題はない

>>712
FreeMarkerは開発者が人間のクズ。

>>715
どういうこと？

流れぶったぎってすまんが、Spring使ってると
xmlやらインターフェースが増えてうざいし
ほんとに便利なのかコレ

>>717

アノテーションつかえばXML書かなくてもいいよ。
インターフェースも必要なければつかわなくていいよ。

>>717
いつの人ですか？

今は自動で登録できるよ
自動登録するパッケージを指定して
@Componetとかクラスの定義につければよい

Spring（というかDI/AOPコンテナ）使わないと自分でインスタンス管理しなくちゃいけないし
トランザクションも管理しなくちゃいけないし、AOPも使えなくてえらく不便だ。

通常のGUIアプリとかだとDIコンテナが使い物にならなくてワロタ
ならよくある

インスタンス管理はどのフレームワーク使おうが意識をしないってことはないと思うが

意識しないなんて誰か言ったか？

インスタンス管理を意識する・しないじゃなくてインスタンス管理のための仕組みを自分で作るかどうか。
既にそういう機能を持ったフレームワークがあるのな自分で作るのはバカバカしい。
DIコンテナいらねって人はインスタンスを管理するという発想がないのかもね。

つまりwicketはだめでJSFは最高というわけですね

アホか。

JSFって良いか？
もうRESTな作りできるようになったんだっけ？

REST厨ってHTMLのstrict厨と同じ臭いがする

技術が細分化してて向き不向きがはっきりしているってことだよね。

技術というか単なる道具とかテンプレートだよな…

論文がどうだとか言い出すREST厨は嫌いだが
RESTがRIAと相性がいいのは確か

RIAといってもクライアントがさまざまだからなんとも

アプレット/JavaWebStart/.NET関連だとSOAPはやっぱり楽だし（JAX-WS2.1あたりで互換性解決したし）
鯖サイドがJavaでjavascriptだとDWR使ったほうが楽だったり

SOAPは遅すぎてRIA向きじゃない
JavaScriptのライブラリが急速進化し、開発環境が整備されてきた今では
DWRも過去の遺物だろう
Ajax、Flex、Silverlightのどれでも開発出来るように
JAX-RSのような形態を取るのが今後の標準だと思う

RESTみたくゆるい仕様ってツールサポートしにくくね？
ツールのサポートなくても平気のがゆるい仕様なんだろけどさ
JAX-RSのメタ情報って他言語から使えるんか？
SOAPはいらんけどWSDLぽいのは必要じゃねーのか

スレ違い
http://pc11.2ch.net/test/read.cgi/tech/1031149340/

>>732
だからクライアントしだいだろ？
WSDLによるクライアントの開発の容易さは捨てがたいだろう。

それにDWRが過去って。
やっと2.0になってリバースAJAXでかなりよくなったところなのに。

どれでも開発できるようにってのは下手するとこけるからね。
まぁバックエンドのサービスをEJB等できっちりつくっておいて
インターフェースを自由にできるようにしておいたほうがいいと思われ。

好きなものを使えってことで。

俺は WebService(WSDL) が好きなんだが
Microsoft のサポートがプアなのがなあ。

329 名前：デフォルトの名無しさん[sage] 投稿日：2008/05/13(火) 22:04:29
冷ややかな戦争勃発ｗ
ttp://d.hatena.ne.jp/masataka_k/20080513/1210661500#c

342 名前：デフォルトの名無しさん[sage] 投稿日：2008/05/14(水) 02:05:36
はぶ参入で抗争激化！さぁ、盛り上がってまいりました！

343 名前：デフォルトの名無しさん[sage] 投稿日：2008/05/14(水) 02:08:47
とりあえず、保存しといた。
http://s04.megalodon.jp/2008-0514-0207-34/d.hatena.ne.jp/masataka_k/20080513/1210661500

347 名前：デフォルトの名無しさん[sage] 投稿日：2008/05/14(水) 07:16:26
面白くなってきたな。Seasar界隈は人格的にちょっとあれな人が多いのが魅力w

348 名前：デフォルトの名無しさん[sage] 投稿日：2008/05/14(水) 07:40:37
でも、理事のBlogでやることじゃないよこういうことはメールベースでやるべきだと思う
野次馬的には面白いかもしれないけど企業から見たら不安になって採用を躊躇するところが出てきてもおかしくないからね

352 名前：デフォルトの名無しさん[sage] 投稿日：2008/05/14(水) 14:02:42
マーケ的にまずいのでseasar3はとりあえず表に出さないでくださいとかいうのはちょっとやばい

353 名前：デフォルトの名無しさん[sage] 投稿日：2008/05/14(水) 14:04:14
元理事は一旦収束していたのに、なにをしたかったのだろうか。そして日記非公開の理由とは・・・？asipの参戦はありうるのか！？

354 名前：デフォルトの名無しさん[sage] 投稿日：2008/05/14(水) 14:08:14
うわ、ほんとだ 閉鎖した

355 名前：デフォルトの名無しさん[sage] 投稿日：2008/05/14(水) 16:31:01
DB関連とか色々勉強させてもらったけど、このしみったれた感覚が所詮デブオタなんだなと思うわ。

擦れ違いかもしれんが、
Jboss seam使っているやついる？

stateless session bean と 普通のPOJOのビジネスロジックの使い分け方が、
わかんね。

汎用フレームワークの話ならこっちじゃね？
http://pc11.2ch.net/test/read.cgi/tech/1181063688/

セッションビーン使えるならロジックはすべてそっちでいいと思われ。
POJOのほうはView関連に特化させるといい感じかな。

あ、そんなスレあったんだｗ
サンクス。

春よコイ！

>>716
亀レスだが
http://pc11.2ch.net/test/read.cgi/php/1120519290/34

俺ずっと REST は RDBMS の CRUD に対応するもので、
言うなりゃ SQL とかストレージ的な空気をクライアント側から
隠匿するためだけの物に近いと思っているんだが
いっつも SOAP とか RPC とかと同列に語られてるんだよな。

REST で騒いでる奴らって CRUD だけで済むプアーなアプリを作ってるからそういう事言ってるの？
それとも REST 風(つまり、単に定義のゆるいWeb-API)なものと混同してるの？馬鹿なの？

>>743
何を言ってるのかサッパリだわ

>>743
狂っどる

>>743
SOAな連中が語るRESTとROAな連中が語るRESTは別物

>>746
ああ、なるほど。>>743が何言ってるのかわかった。
SOA(笑)方面ではそういう扱い方をするのか。
つーかRESTなんて単なる道具なんだよ。
どういう使い方を語ろうと勝手だろうに。

このレスは権利侵害の申し立てや違法もしくはその疑いにて不可視または削除されました。
削除日時：2010-11-16 07:02:29
https://mimizun.com/delete.html

おまいらSpringと一緒にORマッピングは何つかってんの？
俺はiBatisが分かりやすくて気に入ってる。

>>749
Hibernateかな。
これが一番普及してそうだし。

>>749
Hibernate
マッピングはEclipseに自動生成させて
CriteriaとQueryを中心に使う

>>749
JPAかな
次期HibernateではネイティブでJPA対応するし、各種ツールがそろってるのは大きい

>>749
DBUtils

Hibernateって設定ファイル多くてメンテしにくそうなんだが。
確かによく聞くっちゃ聞くけど。JPAのPJにはまだ当たった事無いです。

>>753
それってJakarta DbUtils？
ORとは違うけど確かに一番便利な気がする。
Springに組み込まれればいいのにな。

>>754
JDBCテンプレートがそんなもんだな

DbUtils は、DI コンテナとか知らないときによく使ってたが、
DbUtils と DI をどうやって組み合わせるの?

サービスオブジェクトに DAO オブジェクトを DI させて、
DAO の実装は Hibernate とか iBatis でなく DbUtils を使う感じ？

>>756
QueryRunnerにコネクションを渡すんだろうけど
それってどうなんだろう・・・　Springが勝手にやってくれるとこを
わざわざ記述しないといけないのかね。

DBUtils の QueryRunner とか *Handler は大抵 JDBCTemplate で代用出来ると思うが。

>>754
HibernateはJPAに対応しているから設定ファイルはpersistence.xml一個だよ
EntityのマッピングはJPAのアノテーションが使えるし、
それはEclipseのWTPなら自動作成できる

DBUtilsはO/Rマッパー使う前は愛用していたけど
今の時代では流石に使う気になれないな

JPAが一番楽だろうね
有名どころのIDEはみんな対応してて設定ファイルはまったくいらないし

Hibernateが一番楽だろうね
voクラスの自動生成とcrudアクセスを多用すればジェネリックスの恩恵にあずかれる
まさに楽チン

ここ半年前までは、
・Hibernate ウンコ!!
・余計なことしすぎ (n+1問題など)　　←使いこなせてない側の問題があるがここでは目をつぶる
・iBatis みたいなの便利!!

というかんじで Hibernate はぼろぼろだったが、JPA の登場により王者復活か?

どれ、おれも本買ってもう一度やってみるか

>>749
ORMは使ってないなあ。
ものすごく薄いDAO層のラッパ作成して
(JdbcTemplate 使うようなやつ)
基本的にSQLそのまま書く。
SQL実行するためのツールがそのまま使えるのが大きい。

でも思ったよりも ORM 使う人多いのね。

>>763
spring使ってるのか？

>>764
JdbcTemplate使ってんなら当然だろ

>>762
JPAの範囲だけ見るとHibernateは確かにあまりよくない
LAZYが何も設定せずにきくのはTopLinkとApache OpenJPA

OpenJPAはManyToOneでもn+1フェッチしないんだよね
joinを積極的に使う戦略のようだ

あとupdateがHibernateが一番頭が悪かった
項目ひとつだけ変更してもすべての項目をアップデートしに行くのはHibernateだけ
ほかの実装は更新された項目だけupdateする

>>766
> ほかの実装は更新された項目だけupdateする

それだとバッチ更新できなくね？

>>766
ManyToOne、OneToOneにはFetchType.LAZY付けるのが基本だと思う
必要なときだけQueryやCriteriaでJOINすればいいんだし

iBatis派少ないな。
まぁ結局そんなの使わずにSQL直書きが後で一番見やすいのは
確定的に明らかだがな。

>>758
無理

>>767
どういうこと？

>>768
もちろんLAZYが一番よい
Joinして持ってきたいときにはそう書けばいいだけだし

Hibernateの問題はLAZYがJPAでまともに実装されていないこと
独自のアノテーションが必要

>>769
iBatis は悪くないんだけど、だったら SQL でいいじゃん
てところに落ち着いてしまうのでは。
とことん抽象化するか、とことん具象で済ますかの二択で。

>>771

んな事ねーんじゃね？

Beanへのマッピングとか便利でしょ、、、てかORマッピングってそこじゃねーの？

JPAもネイティブQueryでnewが使えると最高なんだけどね

>>770
独自アノテーションは微妙だな
せめてpersistence.xmlのpropertyでlazyの挙動を切り替えられるようにして欲しい

>>773
個人的にはnewよりもHibernateのResultTransformerをJPAの仕様に入れて欲しいかな
あれさえあればSQL使うときも戻り値を好きにできるので便利

>>772
Object-Table Mapping ならそうなんだろうけど
いかんせん Relation だから・・・ 重厚長大でどうにも。

ｵﾚ的にはiBatisに重厚長大感はないけどな？？
重厚長大っていったらHibernateじゃないの？

っでｵﾚはiBatis派なんだが

>>776
単に使った事無いだけでしょ。
ORも正しく理解できて無いし、相手するだけスレの無駄。

このスレの人たちは、フレームワークが道具であって目的ではないことを忘れ去ってますね

>>778
道具だからこそこだわるんだろ？
こだわりがいらないのならSeasarつかうさ

>>779
Seasarって、サラダで食べるくらいだなｗ

>>779 どういう事？

Seaserの方が優れているという事だが
デファクトスタンダードという事でおまいらは
Springに固執しているのか？

俺がそうなんだけどよｗ

>>782
>>780

>>782
リファレンスドキュメント読んで、
あるいはソースのコメント読んで
どっちが信頼にたるか考えたらいい。
悩むほど難しい選択ではないはず。

MLのホットデプロイのスレわろたｗｗｗ

>>785
どういうやつ？

iFitって使ってる人居る？

>>769
iBatis はよく使っているよ。
だけど、iBatis ばかりで Hibernate は使いこなせてないので、
くやしいので Hibernate を勉強している。

いろいろ思いはあるのだが、こっちに書くとスレ違いかな(O/Rマッパースレに移るべきかな)

JPAは勉強はあまり必要とはしないと思うけどね

今Hibernateを勉強するなら、一通りJPAを学んだ上で
CriteriaとSQLQuery、一部の独自アノテーションと二次キャッシュを学べばいいと思う
Hibernate独自の設定ファイルはもう使うことは無い

Hibernate 3.2 を使っていたとき(JPA は使っていない)、
Hibernate tools で DB からテーブル情報抜き出して(ant hbm2hbmxml)、
目で確認して、一部手作業で修正、
Spring からは、Spring 入門の8章での使い方をした(HibernateSupport のサブクラス)

n+1 や lazy は、koichik 氏のブログを読み漁って、理論は理解しているつもり。
プロジェクトでは、テストしてパフォーマンスが悪ければ join するようにし、
パフォーマンスが問題にならなければシカトしていた。

>>790
JPA 使うと、テーブルごとの hbm.xml がいらなくなるということ？

去年の Seasar カンファレンスで、「流れるようなインターフェース」で
S2jdbc のやつがあったが、JPA もそんな感じなんだよね。

中村氏の本、Spring でなく Seasar だけど読んでみようかな。

>>791
hbm.xmlもcfg.xmｌも要らない。JPAのpersistence.xmlだけで設定は済む
Springが提供するHibernateやJPAのラップクラスはあまりお勧めしない
SpringはJavaEE5標準方式のJPAのDIに対応しているので、
それを使って直接EntityManagerを使った方が何かと簡単

WEBアプリ最強はSpring + Struts + Hibernate?

最強はフレームワークに振り回されずに本質を見極める人材です

>>791
紺色のＥＪＢ３本が日本語でもっともＪＰＡを詳しく解説してある本かと
EJB3の中の一仕様だからね＞JPA
ただし、JavaSE上で単体でも使えるようにしたと

JPAをもっとも快適に使うためにはJavaEEのほうがいいと思うけど

勉強なんて大げさなものは必要ないよ
NetBeansで自動生成されるコードを見れば大概わかるかと

レスどうもありがとうございます。

>>795
http://www.amazon.co.jp/dp/4797333367
これですね。とりあえず立ち読みしてきます。

>>792
Spring 入門は Spring 1.2 のころだけど、
いまどきの Spring + Hibernate(JPA) の連携の仕方は、
HIbernateDaoSupport ではなく、新しいやり方があるということですね。

>>796
SpringのドキュメントのJPA部分を読めば一通り説明が載ってる
JavaEE5サーバ上で動かす場合は
http://static.springframework.org/spring/docs/2.5.x/reference/orm.html#orm-jpa-setup-jndi
TomcatやJ2EE1.4以下のサーバで動かす場合は
http://static.springframework.org/spring/docs/2.5.x/reference/orm.html#orm-jpa-setup-lcemfb
12.6.2のJpaTemplate、JpaDaoSupportは無視して、12.6.3で@PersistenceContext
を使っている例を参考にするといいと思う

>>796
そうそう
それ読むとDIコンテナもEJB3でいいじゃないかということになるはず

今のプロジェクト、EJB3かspringかどっちでいくかホント迷う

開発環境がNetBeansとか運用環境がGlassfishならばEJB3のほうが楽。

その他ならばどっちでも同じ。

DIコンテナに限った話ではないけど
両方使ってみて、プロジェクトに合う方を選べばいいと思う

メンバの経験が多いほうがいいに決まってるでしょ

>>802
それはメンバにもよる

誰か>>803の解説を頼む

経験が多くても当てにならない・・・ってことかな？
たぶんレス番号のミスかと

メンバは数人で誰もどっちも経験なし。
短納期なんでEODの面と保守時のコードの分かりやすさや、
xmlファイルの少なさからEJBかと思ってるが、あまり普及してないらしいのがマイナス。
後から違う保守要員来たときを考えると流行りのSpringかな？決め手がない

>>804
メンバの技術水準が高ければ、
学習コストよりもプロジェクトに対するFWの相性の方を優先できる
技術水準が低ければ、学習コストを重要視する必要があるので
経験者が多いFWの方が候補になりやすい

>>806
DB層はJPA?

あとInfoQとか見てるとEJB3は最近わりと地味に普及してきている感じかな
Springは古い1.x時代のは多かった

>>808
うん。ORMやりたいんでJPA考えてました。
ちなみにDBのERDは教科書に出てくるくらいのレベルに近く、かなり単純なんで
ちゃんとテーブル設計してマッパーが吐くsqlがインデックススキャンになるようにするのは難しくない、という読み。
EJBといいつつ、分散システムでもなんでもないんだけど、とにかくデリバリを早く、でも保守は用意に、というのが
プロジェクトの主眼です。

短納期で経験のない技術を選ぶってリスキーじゃね？
はまった時にリカバリできるのか？

>810
SpringはともかくEJBってそんなに難しいの？
商用or無償APサーバ＋サーブレット＋JSP＋struts or 自社FW なら経験あるから
何とかなるかと思ってた
自分でも保守やるし、またJDBCゴリゴリのソース相手にするのが嫌なんだ

EJB3ならそんなに難しくは無い
ただしSpringに比べてDI・AOP機能に色々制限があるから
予めプロトでも作って要件を満たせるかどうか確認した方がいいと思う
JPAもCriteriaが標準化されてないという弱点があるから
検索画面で動的にSQL組み立てる処理が多ければ、最初からHibernateなどの
独自Criteria機能を使うことを頭に入れて置いた方がいい

EJB3.1のほんの一部がGlassfishV3で触れるようになったが、かなりよさげだね。

>>811
難しくないよ。
EJB3.0で2本ほど納品済みだけれども、開発効率は非常によかった。
むしろ小規模向きだと思う。
EJB3にしろSpring2.5にしろ、ひとつ覚えておけばその後はどうにでもなる。

>>812
AOPってそんなに使う？
メインはトランザクションなんだろうけど、EJBならばその用途では必要ないしね。
JPAもHibernate依存するのは今はよくないような。
パフォーマンスも問題になるとは思えないしね。

JPQLでDTOを直接生成することも出来るのであんまり困ることはないけど、
パフォーマンスが命でなければEntityからDTO生成するほうがいいかもしれない。

そもそもJPAのプロバイダとしてはHibernateが一番パフォーマンス的にも出来が悪いので注意かな。

EJBの本質は分散処理だと思うが、 >>809 のような分散システムでもなんでもない
web アプリを作る場合、
Tomcat + (Spring +) JPA と、
Glassfish + ejb3 は、パフォーマンスとしてはどちらが速いのだろう?

>>813
AOP は結構使います。ロギングとか。
あとから顧客のうざい要求によって仕様変更があったとき、
既存クラスを変えずに、ログ出力やデータ変換の処理を差し込めるのは
楽だと思う。

>>811だけ読んでも俺ならリスク高いと思うけど。
「JDBCゴリゴリのソース」、「自社FW」
こんなのいつから止まってるのって話だろ。
現状を嫌だと思ってる（問題視してる）のが811のみだったら爆発するぞ。

短納期だし、とりあえずチームの得意な形＋ORマッパでDao層だけ剥がすのが無難だと思うがなぁ・・・

>>811
難しいかどうかじゃなくてさ、時間あるときに触ってもないのに
いきなり実戦投入ってのがありえねーと思ってさ。
そういうやつが痛い目あうとEJB使えねーSpring使えねーって
言い出すからな

Local呼び出しにしろ、web-ejbコンテナ間のオーバヘッドがあるから、
Tomcatが勝つんじゃないの？

sunには賛成できない

TomcatでSpring+JTAって終わってるんじゃないの？
まさかずっとメンテナンスされてないJTOMとかつかっちゃうなんてことは出来ないだろうし

Tomcatも管理するのはたるいよね
GlassfishとかAP鯖だと管理ツールが便利だな
GUIで各種コンポーネントのロギングレベル変えたりとか

Tomcatの範囲だけでもGlassfish使うのお勧め
JTAやデータソース、コネクションプールのチューニングとかそっち方面任せるだけでもかなり楽

2PC使わなけりゃJTAいらん

>>813
AOPはトランザクション用途以外だとログやセキュリティ関連とかで結構使う
SpringはいざとなったらAspectJのフル機能を使えるから、
AOPに関しては何でもアリ状態なのが強み

Web画面は結局は動的Queryによる検索処理が殆どだから
JPAが持ってないCriteria系機能が有るのと無いのとでは生産性が大きく違う
以前JPAのAPIに拘ってCriteriaを採用せず、後で痛い目にあったからよくわかるｗ
Criteriaに関してはHibernateがいちばん機能が充実してるように感じる
TopLinkはCriteria系に関する情報がWeb上にほとんど無いし
OpenJPAはざっと見たところCriteria機能そのものを持ってないっぽい

>>816
結局は、事前にしっかり調査をするかどうかだと思う
開発者に経験がないのなら、事前にアーキテクト的立場の人間が
一通りの機能を確認しておくべき。適当に事前印象だけで決められて
開発フェーズになってからあれも出来ないこれも出来ないと
言い出されるのが一番困る

>>814
GlassfishのWebコンテナはTomcatベースだけどNIO使ったりIO方面でチューニング済み
JBOSSとかもそうだったはず。

>>820
コンテナ管理のトランザクションならJTA使うだろ？

>>820
Connectionからトランザクション管理を独立できることに意味があるので
2PC使うかどうかは関係ないな
JPAもJTAを直接見てるから、JPAと連携させるのなら尚更JTAが望ましい

ロギングだけならどのDIコンテナでもそんなに問題になるとは思えんが
EJB3の場合Interceptorsを必ず付与するようにしておいたほうがいいかもね

>>799は小規模ということであんまり問題にならないと思うけど

とりあえず小規模なうちにDIコンテナとか一通りの勉強しておいたほうがいい
今後JavaEE6やJavaSE7でまた大きく変わるからね

JavaEE5の時代のうちに世の中に追いついておいたほうがそのとき覚えるものが少ないかと

>>822,823
SpringだとJTAなくてもコンテナ(Spring)管理のトランザクション使える
2PCがいらなけりゃJTAはいらん

>>823
> JPAもJTAを直接見てるから、JPAと連携させるのなら尚更JTAが望ましい

EntityTransactionは無視ですかそうですか

>>825
その考えがもう古いんだよ
JPAはJTAを用意できないとRESOURCE_LOCALモードになってしまうし
最近はSpringを介さず直接JTAを見るO/Rマッパーが殆どだぞ

>>827
2PC使わなけりゃローカルモードで十分だろ
何のメリットがある？

>>828
JPAのコンテナモードそのものがJTAモード前提になってる
実装によってはコンテナモードとローカルモードで挙動が変わる
一度JPA仕様をしっかり読むことをお勧めする

>>827を支持しよう
SpringにしろSeasar2にしろJTAとデータソースをJNDIで持ってくるのが正解（EJB3の場合全自動）かと

RESOURCE_LOCALとかスタンドアロンアプリ以外ありえん

>>829
コンテナモードがいらんだろ

id:shinとかid:da-yoshiとかいそうな流れ

このスレ見てると道具の進化に踊らされる猿たちって感じだな

glassfish厨は専スレ立てたらどうかと思うんだ

GlassFishの話だったのか？
APサーバでSpringというパターンが多いからピンとこなかった

>>835
>813,819,822

>>836
ああ悪い、TomcatとAPサーバという話が並行して行われていたのかｗ
TomcatならたしかにJTA使うのが前提にはならないな
個人的にはSpringの仕事はAPサーバばかりなんだが、
やっぱりTomcatで動かしてる現場の方が多いのだろうか？

>>832以降、JTA厨がいなくなった件w

>>838
いやいるけどｗ
自分のやった仕事はほとんどがAPサーバ前提だったから
SpringでもJTAを選ばないという選択肢をしたことは無かった
あまりTomcat案件そのものに当たったこともないんだけど、もしかして自分は少数派なのか？

＞以前JPAのAPIに拘ってCriteriaを採用せず、後で痛い目にあったからよくわかるｗ
なんで調べてから使おうとしないのか理解に苦しむ。

>>839
俺の周囲では少数派だな
OSSのAP鯖つってもJavaEE5なんてつい最近まで選択肢になってないし
J2EE1.4だったらいらん。Spring+Tomcatで十分だったからそのまま
JavaEE6にはちょっと期待してる。Tomcaプロファイルにw

>>841
なるほど、そうなのか
自分の場合、OSSのAP鯖はほとんど無くて、有償のJ2EEサーバが多かった
WebLogicとかWebSphereとか
EJB2なんて勿論使わないから、SpringでDataSourceやJTAを使っていた
JavaEE6のプロファイルって、Tomcat＋Springみたいな形だっけ？
だったら軽くて良さそうだね

>>842
> WebLogicとかWebSphereとか

JTA使いたいからWLS/WASを選んだわけじゃないだろ？
あったから使うってだけで。JMS使ったなら別だが

JMSって普通に使うだろ？

JavaEEプロファイルはもめてるみたい

>>844
大企業のシステムでは普通に使う
中小企業のシステムでは普通は使わない
システム自体の規模(受注額)はあんまり関係ない

プロファイルはJBossがWeb Beansをゴリ押ししてるってどっかで見たな

JBOSS　+　EJB2でDoclet、
パフォーマンスでないのでJDBC直に使いますとか
いう時代に比べれば正直何を選択しても天国だよ

WebBeansはSeamをベースにしてるからそれを
売り込みたいという意味合いが強いと思う

EJB3.1でせっかくwarにはいるようになったのに
JSFのスコープ対応していないというところが
一番の問題だったと思う

EJBはWebだけからアクセスされるものではないから
密接にしたくないというのもあるのかもしれないけどね

WebBeansって未だによく知らないのだけど
Spring Web Flowみたいなもん？

誰かSpringApplicationPlatform落とした？
JPAやJMSをサポートするらしいけどJTAは含まれてる？

JavaEE6 のプロファイルがどうとか、
みんなそういう新しい情報、しかも使い物になるかどうか、ってどこで集めてくるの?

自分はマイコミと atmark-it は読んでいるが、そういうのには出てこないよね。
theserverside.com と infoq は、一時追っかけてたけど脱落したww

海外サイトでも、英語がんばります。

そんなの追いかけても意味ないよ
手段と目的を取り違えたイタイ人になるだけ

>>850
GlassFish厨のことですね。分かります。

JBOSS　+　EJB2でDoclet、
パフォーマンスでないのでJDBC直に使いますとか
いう時代に比べれば正直何を選択しても天国だよ

そんなもんと比較すんな、ぼけ

EJB2の何が悪いの？

>>853
すべて

EJB2の時代まではIDEのサポートとかほとんどなかったのが大きいと思う
そのくせ生成するファイルの膨大さといったら

EJBは金がかかってしかも遅い、ってイメージが定着しちゃったのが失敗だな

EclipseからSpringIDEをインストールしようとしています。

［ヘルプ(H)］→［ソフトウェア更新(S)］→［検索およびインストール(F)］
からインストールしているんだけど、
検索結果ダイアログでフィーチャーを選択してると、なんかフィーチャーが
足りませんみたいなエラーがでてきます。
SpringIDE入れる前にインストールしておかないといけない
ものってありますか？

インストールしたのはこれだけです。
JDK,JRE
Eclipse 3.3
Eclipseの日本語ツール
Tomcatプラグインツール

>>857
EclipseがJava Developersなんじゃない？
WTP・GEFが必要だからJavaEE Developers強く推奨だよ
ttp://springide.org/project/wiki/SpringideInstall

>>858
やさしす

あなたのやさしさが怖かった

StrutsとSpringの連携ってautowiringrequestprocessorを使うのが今風？
分かる人教えて〜

当方女子高生です＞＜；

そんなことしてないでお母さんの手伝いをしなさい

>>858さん
ありがとうございます。

SpringIDEインストールできました。
Springのプロジェクトも作成できました。

ただ、
import org.framework.......
っていう感じに書いてもエラーがでてきます。
コードアシストも反応しないし。。。
他に何か設定ってありますか？

何度もすみません。
Java歴一週間で会社でだれも経験者がいません。
どなたか教えてください。。。

その会社すぐに潰れそうだなｗ

新入社員研修？

>>863
SpringIDEの前にやるべきことが山のようにあるだろ

>>864
まったくだよな

>>863
勉強・調査しましたが無理でした。と報告しなさい

Java出来る人材がいないから潰れるなどということはない

>>863
Springはまずはすてろ
Javaを勉強したほうがいい

環境構築を考えるのならEclipseよりNetBeansのほうがいいかも

>環境構築を考えるのならEclipseよりNetBeansのほうがいいかも
ﾜﾛﾀｗｗｗ

NetBeans厨ってうざいよな
GlassFish厨ってうざいよな

>>870
ほかに環境構築が楽なIDEがあるのなら教えてくれ
昔のJBuilderもかなり楽だったけど、今では面影ゼロだし

ど素人なら、SpringIDEじゃなくて素のEclipseプロジェクトで動かした方がいいかもな
どうせ操作ろくにわからないんだろうし
Eclipseの入門本でも買って、TomcatでWebアプリ動かす練習してみて
それが動かせるようになったらSpringに改めて挑戦してみたらいい

>869の次のセリフ

教科書は「創るJava (改訂第2版)」がいいかも

なんでNetBeans拒否反応凄いの？

まぁ、俺はeclipse3.2を使ってるわけだけどもｗ
3.3の遅さはどうにかならんのかね・・・スピードはNetBeansの勝ちだよ

Eclipse で環境作れないようなら、
NetBeans 使ったところで
たかが知れてる(他の部分でどっちみち躓く)って話だろ。
NetBeans 否定してるわけじゃない。

NetBeansとEclipse両方の経験が豊富な人の冷静な比較が聞きたいですね

>>875
ヒント：
Javaのお勧め入門書スレで創るJavaだけずっと粘着が続いている（比較的最近も急に復活した）
大量に削除でスレ番号が頻繁に移動する

>>875
もしかしてvista使ってない？

>>879
XPだよ
メモリもCPUも開発スペックなんだけどねぇ・・・

自分が言うのもなんだがIDEスレじゃないんでココらへんで・・・

863です。

Tomcatをいれていろいろプログラムを作りました。
組み込みの開発経験は長いので、Javaやサーブレット自体は難なく
簡単なアプリを作れます。

ただ、Springがどうしても入らないんです。

>>881
>Javaやサーブレット自体は難なく簡単なアプリを作れます。
ならSpringIDE使わないでやれば？
今までそういう発現する奴いっぱい見てきたけどホントに出来た奴は０だったな。

SpringIDE入れてもSpringは入らないけどな。
どうしてSpringIDEを入れるとSpringが入ると思い込んでいるのか激しく疑問だ。

SpringIDE無くても問題無いと思うよ
ってかSpringIDE今一なんだよね、
俺は入れても使ってないよ、必要無いから

>>881
他の言語が長いからといって１週間程度のJava暦ですぐにつかえると思い込むのはやばい
表面上だけ理解していると思っておいたほうがいい

>>881
文系出身の今年入社の僕でも出来ましたよ〜
組み込みの経験とか関係ないのでは？

>ただ、Springがどうしても入らないんです。
ちょっとわらってしまいましたｗ

皆さんあんましStrutsとは連携しないのかな？
失礼しましたぁ〜

お兄ちゃんとモンハンしてきまｓ＞＜；

Struts2と連携させて使った、Spring2･5だけど

フレームワーク指定縛りがなければ
SpringMVC + Velocity を試してはどうか

はじめてHibernateを使ってみたんだけどLazyInitializationExceptionが　＞＜
みんなどうやって対応してるの？
画面から直接エンティティを参照しない？

>890

DBから一緒にとってくるように設定しているな。

>>891
ごめん
言ってる意味がわかんないw

>892

Hibernateのドキュメントを読め

>>893
ははは
おこった？ｗ

>DBから一緒にとってくるように設定しているな。
確かに何と何を一緒になのかわからんな
逆じゃねえの？

>逆じゃねえの？

何の逆かわからないよ。

LazyInitializationExceptionが発生するのはトランザクション終了後に
LAZY設定でロードしていないEntityにアクセスしたから
なのでDBから取得する際、HQLのJOIN FETCHなどを使って一緒に取ってくればいい

という意味だと思う

>>897
非常によくわかりました！
そうだよね、一緒にとってくればいいんだよねー

>DBから一緒にとってくるように設定しているな。
だからこれが逆だと思ったんだよねー

クエリではJOIN FETCHって書くけど、この機能そのものはFETCH JOINって言って逆だよね？ｗ

>>892
Java⇔RDBのMapping-Frameworkを語るｽﾚ Vol.4
http://pc11.2ch.net/test/read.cgi/tech/1134701684/

これ入れたら『OIDON』とか使えるようになるんですが
入れたらどんな利点があって汚点があるのか公式の概要見ましたがさっぱりです。

どなたか教えてください。

spring のスパーサンプル本試すのは 1系列で試したほうがいい？
＃独学でひっそりやるんだけど
＃周りで使ってる奴はいねぇ・・・・

今は2.5、1.x台って何時の話だｗ

基本思想には違いないだろ。
EJBみたいに全然別物になっちまうときついが。

EJBの場合別物になっても2.1を理解してた人は3.0へすんなり移行できると思うんだが

EJB3のためにEJB2.1の入門書を読むのはきついって話じゃね？

独学なら、本家のドキュメントを読むのが一番手っ取り早い
英語苦手な俺でも、サンプルが多いので何とか読み進めることができた
日本語のSpring本はどれも情報が古かったり基本的な部分を飛ばしていたりするので
入門者にあまりお勧めできる物が無い

>>906
なるほど、ありがとん　がんばってみるわ
＃あまりいい本なんだよね　確かに・・・・

>>901

1で出来ることはほとんどそのまま2.xで動くから問題ないかと。
2.xで追加された機能は覚えられないけどね。

確かに後方互換はあるけど、記述方法の推奨パターンが全然違うから、
自分は今更1.X系で学ぶのはお勧めしないな
最初から2.X系のスキーマ前提の記述で覚えた方が楽だと思う

>>908,909
ありがとうございます。
JAVAそのものの経験値不足なので、collection あたりを攻めながら
調査します。

java経験ﾅｼでSpringは辞めた方がいい気がするがなぁ・・・

コレクション分からんといい面が使えんしね

DIコンテナ以前の話だな・・・

色々ありがとーーーーー
スキル的には.net版で試せばいいんだろうけど、eclipse3.2.2にupしたら
なぜか、久々にjavaのコード書きたくなってｗ
もう少し(かなりだな)javaの基礎体力をつけてから、試してみますだ

JSUGはひがたんのフレームワークを前面に押し出す愚行はしないようにね。
あくまで一ラッパーフレームワークという位置づけにしておくべき。

つーか、必要なら似たようなモノを自分たちでも作ればいいんじゃね？

SpringSource Application Platformもういじってる人いる？
Tomcatで動くwarはそのまま動くんだっけ？

>>917
それどういうもの？
本家みてもよくわからんかったｗ

DLしようとしたけど個人情報入力を求められたのでやめたｗ

springMVCで日本語が文字化けします・・・。

フィルタつかわないとだめだぞ

springMVCとVelocityの連携について詳しく書いてある書籍ってありますか？　

どうもネット上だと情報が少なくてとっつきにくいです･･･。

>>922
なにげに無理に連携するよりも、VelocityViewServletとかで完全に分離したままでいいような気がする。
で、ViewToolsじゃなくてSpringのBeanをServletContextとかにsetAtributeして使うだけ。
2.5以上ならRequestScopeも使えるし。

連携しなくちゃSpringとVelocity組み合わせる意味ないじゃん？って言われそうだけど
むしろ完全に分離したまま組み合わせるといい感じ。

現時点ではwebのフレームワークはSpringMVCが最強じゃねって気がしてきた
JSF→eclipseでぽとぺた出来ない
struts1系→POJOじゃないしspringよりview層の選択肢が少ない
struts2系→リフレクションしまくりで重い。よくわからん。

springMVCはJSFと違ってアクションベースだから設計方針が枯れてて保守で技術者確保しやすい
(実装上の細かい方言は10年も経つと忘れ去られるんでそこは比較しない)
後発のview技術が出たらそれ入れられる
弱点無しなのに、なんで他のフレームワークのスレだと話題にならんのだろう？

比較対象が勉強不足を物語ってるな

>>925
じゃあ何と比較するの？

ああ、書き方が悪かったなJSFと連携出来るのは知ってるよ
viewにJSF使う気は起きないと言いたかった

>>924
SpringMVCやればわかるけど機能を減らしてより生Servletに近いStrutsだよ
結構使いにくい場面もあるんだ

それなりに扱いやすくなったのはSpring2.5から

ここで wicket や click 厨のおれが登場
wicket や click は、Spring と統合する機能も持っているしね

どれがいいかといわれるとよくわからんが、struts はもういいやって気がする

wicketって確かにhtmlとjavaだけで完結してるかもしれないけど、上手く分業出来るんだろうか？

wicket独自の属性埋め込みがちょっと厄介
プロパティででてこないからね
勝手に消されたりしやすい

うちの会社は SIer なので、デザイナとかいないし、あまり分業することが目的ではない。
開発の初期に、HTML で紙芝居を作るが、それをそのまま使って行きたいのが
理由のひとつかな。

紙芝居の HTML を *.jsp にリネームして、struts のタグに書き換えるのは面倒。

デザイナとの分業というか、凝ったデザインの HTML になる場合は、velocity とかを使ったほうがいいと思う。

velocityもJSPとの違いはないけどね
カスタムタグのほうがまだDreamWeaverで標準対応してる分まし

Strutsのカスタムタグはどのみちお話にならんよ

springMVC厨はいないの？

>wicket や click は、Spring と統合する機能も持っているしね
マジ？
俺が調べたころ(Spring 1.2.8の時代)は
Wicket は面白いけど唯一の難点が Spring との連携に
支障をきたすこととか言われてた気がする。

でもまぁ Struts と SpringMVC の比較であれば
Wicket は毛並みが違うんじゃなかろうか。

>>934
俺は自分で作る時は常に SpringMVC + Velocity だよ。
ModelAndView は XML Schema を記述して JAXB2 で自動生成する。
だけど周囲で Spring 使うのが俺だけだから
デモレベルのものしか作ってない。

おいらもSpringMVC + Velocityなんだけど

>>936
＞ModelAndView は XML Schema を記述して JAXB2 で自動生成する

これの意味がよくわからない…

＞springMVC+Velocityの人
tileはなしですか

>>937
ModelAndView を Java で直接記述せずに、
先に XML Schema で定義しちゃってから
JAXB2 で自動生成・・・同じ文だな。
そんなに説明下手かな、俺。

SpringMVC 使い始めた頃はシコシコ手で書いてたけど、
入れ子を2重にしたり、それを修正したりのサイクルで
結構手戻りを感じてしまって、JAXB2 使うようになった。

spring-ws で XML Schema からのトップダウンアプローチに慣れてたのもある。

>>939
説明云々じゃなくjaxb知らんだけだろ

MVCのアノテーション使ってるひといる？@Controllerとか。
便利？

JAXBなんて標準APIだろ
しかしJAXB2.0での改善点はXMLを使わずにいけるところだが
その逆ということか

スキーマかくのたるいと思うのは俺だけか

>>941
SpringMVC使ってた人ならすんなりいける
アノテーションはむしろ推奨

これからはAJAXのプレッシャー（顧客要望）がだんだん強くなってくるから、
そこら辺がプレゼンテーション系フレームワーク選択のポイントになってくるんじゃねーの

このレスは権利侵害の申し立てや違法もしくはその疑いにて不可視または削除されました。
削除日時：2010-11-16 07:02:29
https://mimizun.com/delete.html

>スキーマかくのたるいと思うのは
初めにJavaありきならトップダウンアプローチが良いし
そうでないならボトムアップの方がスッキリする。俺の場合は。

そこら辺は趣味の領域だから、
自分(達)がやりやすいと思う方を選べばいいんじゃないか。

Javaだからってことはないと思うけどな
XMLだとタイプセーフじゃなくなるってのも大きい

>>947
どのタイプセーフ指してる？ｗ
触った事無いならレスしない方がいいよ？

世の中のXML批判の多数って
XOMすら知らないやつらの声だったりするんだろうか。
鬱になるな。

IDEの補完も効くし、JAXBでいつでもオブジェクトにマッピングできるし
今じゃXMLを無理して避ける理由ってあまり無いからな
Springで定義ファイルが爆発することも無くなったし、便利な時代になったと思う

>>950
なんか矛盾してないか？

>>951
関係ないのが混じってるのは矛盾と言わないんじゃないか？

関係ないのを混ぜてるのは、単に話がそれているだけだよｗ

SpringMVCでVelocity使ってる人に質問
ModelvAndViewに渡したモデルをvmから見れない。nullが返る
toolbox.xmlのkeyとBeanのIDをマッピングをどこかで定義しなきゃいけないと想像していますが、
どこでやるの？

>>954

InternalResourceViewとかと一緒にModelvAndViewに渡したModelなら
vmからそのまま見れるけど（VelocityView系は使ったことないから知らない）、
toolbox.xmlの設定はモデルと関係ないのでは。

普通に見えるが。
どういう風に渡したんだ？

解決した
VelocityToolboxView使ってて、vmの変数、bean定義のid、
toolbox.xmlのkey全部同じ名前にしてたのが原因ぽい
toolbox.xmlから名前消したら見れるようになりました
>>1の本によると渡したidがそのままVelocityコンテキストのkeyにputされるらしく、
マッピングなんてものは意識する必要ないんだね
当たり前だけどViewはVelocityViewでもVelocityToolboxViewでも何でもいけた

Velocity使う理由がないんだよなー
テンプレートとしてなら制御構文のみのJSPでいいし
そっちのほうがツールが対応しているという現実が

補足
toolbox.xmlのオブジェクトには値を定義してなかったんでnullが返ってきた
bean定義とtoolbox.xmlで名前が競合するとtoolbox.xmlのが優先されるようだ

JSPは些細なtypoした時に
大層なエラーが表示されて
それ読んでも原因が書いてない時点で
二度と使う気にならん。

なんであんなに分かりにくいエラー吐くんだろ。

それはJSPではなくコンテナの問題。
使うコンテナや設定によってエラーの内容や詳細度なんていくらでも変わる。

問題の切り分けのセンス無い奴だな。
エラーの意味や意図がわからないだけじゃないの？

最近は、JSPの些細なtypoはIDEのエディターがチェックしてくれるよ
逆にどんなに優れたテンプレートでも、IDEのサポートが無ければtypoのフォローは出来ないからな

切り分けしてるからtypoだと分かって
自分のうっかりさ加減にイライラした。

最近はIDEサポートでサクサク行けるのか。
勉強不足で悪かった。
当時だとVelocityの方がエラーが明快だった。

ところで、DIスレでIDEに依存した解決策示して、なんで満足できるの?

JSPだってエラー箇所実行したらすぐわかるでしょ
カスタムタグによるHTML生成さえしなければ
DreamWeaver等のデザインツールの相性もJSPのほうがいいし

>>960のレベルなのになんで偉そうなの？

「DIスレでIDEに依存した解決策」の意味が不明だが

今やフレームワークもIDEありきの時代。

マジで時代の流れについていけてない奴なんだな。

>>963
別に満足はしてないよｗ
IDE使えばJSPは便利だよと書いただけ
JSPだけではなく、HTML・XMLも、昔に比べたら劇的に書きやすくなった
Spring2のスキーマ使った設定ファイルもIDEのXMLエディタ使えば
楽に書くことが出来るので、Spring使うならIDEは必須だと思っている

VelocityもVelocity Web Editあるよ
気に入らなければJSPエディタ使って書いてもいいし
JSPと違ってプレビューやパレットはないけどこのくらいなら生産性で大きな差が出るほどではない
描画は早いんで縛りがないならVelocityも使ってみては

すれ違いだけど普通JSPってプリコンパイルして使ってるの？
JSPファイル多くてそのままだとアクセス多いサイトだとデプロイした瞬間に複数のJSPコンパイル始まって下手すると落ちる。。。
antでプリコンパイルもできるけどweb.xmlに無理やりマッピング挿入して解決ってどんだけなの。
あとカスタムタグ作るのも面倒くさいし、functionなんかstaticメソッドだけとか。。。
ViewまでJavaのガチガチ感に縛られるのがイヤなので自分もVelocityつこてる。
初心者がSpringと組み合わせるのもtoolbox.xmlの多機能版みたいな感じでわかりやすいと思う。

>>969
デプロイした瞬間にコンパイルするか初回アクセス時にコンパイルするかはサーブレットコンテナ依存かと
Tomcatでもバージョンによって挙動は異なるし手元のアプリケーションサーバーのマニュアル見たら？

どちらにしろおちるということはないはずだが

JSPでカスタムタグ作って・・・というのは間違ってる
JSPでもVelocityと同様のことをやらせればいいだけ

あくまでもカスタムタグは融通を利かせるためのものであって最終手段

Velocityよりfreemarkerの方がいいんじゃね？

>>972
日本での採用案件ってどれぐらいあるんだろ？
大手のSIer主導だとまずないんじゃない？

いい加減、スレタイのFramewo"ｒ"kに、だれか突っ込めよ。

気の触れた方がいらっしゃいます

"ｋ"もだけどな。

>>970
＞デプロイした瞬間にコンパイルするか初回アクセス時にコンパイル

いや、アクセス多いサイトだと両方同じ結果になるってことなんです<(_ _;)>
デプロイした瞬間に全ページアクセスされるので…
JSP50ファイルくらい一気にコンパイル始まるとその間にもリクエスト溜まりまくりで大変なことに…

ちなみにTomcatです<(_ _;)>

それ、パッケージングとデプロイとリリースの手順間違ってないか？
コンパイルしてclassファイルをwarに含めてからデプロイして、
デプロイ完了してからオープンしろよ。

>>977
アクセスが多くても通常ページのアクセスは偏るからまったく同じにはならんだろ

このレスは権利侵害の申し立てや違法もしくはその疑いにて不可視または削除されました。
削除日時：2010-12-18 08:26:03
https://mimizun.com/delete.html

客からspringを使うよう言われたけど
spring以前にFactoryパターンすら分かってない(インターフェースと実装の違いも分かってるのか微妙)
ウチのチームじゃspring無理ぽ。さてどうしたものか。

おまえが教育すればいいだろ

別にspringを使わせる程度ならそれほど教育いらないだろ。
規約を少し作れば済むと思うが

PGが全員はじめてでも設計者がわかってればなんとでもなるが逆だと辛い。

・自動登録を活用して、開発者には設定ファイルを触らせない
・DIコンテナの概念が解るレベルに到達していない場合は
new する代わりにフィールドに@Resourceつける
@Transactionalつけたらcommit rollbackができる
程度の意識で開発してもらう

後は命名規約覚えてもらうくらいで、結構行けると思う