Java Spring Frameworkを語るスレ

1 名前：デフォルトの名無しさん mailto:sage [04/02/23 00:51] www.springframework.org/ 乱立するフレームワークと競合するプロトコルの嵐のなかで、 リスクの高い決断を余儀なくされているJavaデベロッパ、プ ロジェクトマネージャに対する福音です。 語るべし。 654 名前：デフォルトの名無しさん mailto:sage [2006/01/11(水) 11:24:00 ] >>653 HibernateCallback 655 名前：653 mailto:sage [2006/01/11(水) 22:34:55 ] >>654 return getHibernateTemplate().execute(new HibernateCallback() { public Object doInHibernate(Session session) { // クエリ投げて結果を返す } } って感じですね。マニュアルにも載ってました。ポイントありがとう。 656 名前：デフォルトの名無しさん mailto:sage [2006/01/21(土) 20:54:23 ] ttp://pcweb.mycom.co.jp/news/2006/01/20/346.html > Drools 2.5 BETA 2において提供されている拡張モジュールはdrools-decisiontables、 > drools-dotnet、drools-examples、drools-groovy、drools-ide、drools-io、drools-java、 > drools-jsr94、drools-python、drools-smf、drools-smftest、drools-spring、 > drools-spring-examples、drools-spring-jdk5。ベースとなる藻ジュースはdrools-base、 > drools-core、drools-core-3.0。 Springにも対応しているらしいルールエンジンだが、なんだかベースが不味そうだ。 657 名前：デフォルトの名無しさん mailto:sage [2006/01/21(土) 21:14:58 ] >>656 「藻ジュース」(・∀・)ｲｲ 658 名前：デフォルトの名無しさん mailto:sage [2006/01/22(日) 10:27:33 ] いや飲みたくはない…… 659 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 21:26:19 ] 今、新しいｱﾌﾟﾘ作るんで、まあ流行のSpringと扱い慣れているStrutsでと思っています。 まずはｱｰｷﾃｸﾁｬを決めるために、いろいろサンプルを作ってみてるんですが、質問です。 Struts&Springの連携で、代表的なのは 　1) ActionSupport 　2) DelegatingActionProxy 　3) DelegatingRequestProcessor の3つだと思うのですが、2) or 3) で決めかねています。 1)はせっかくなんでつまらないのでﾎﾞﾂ。 残るはDelegatingActionProxyとDelegatingRequestProcessorですが、 機能的にどちらが良いのか分かりません。 どちらかと言えばActionを継承させてBaseActionを使っていたことが多いのですが、 RequestProcessorの方が上位ですよね。 アプリケーションは到って小規模なんでどちらでも同じだと思いもするのですが、 考慮すべき点や拡張性の点等、ご助言･苦言を頂けないでしょうか。 非常に基本的な質問で恐縮ですが、 660 名前：デフォルトの名無しさん mailto:sage [2006/01/23(月) 23:34:09 ] たいくつでつまらない技術が一番強い。 661 名前：659 mailto:sage [2006/01/24(火) 11:18:42 ] >>660 確かに、ごもっともだと思います。 実はこれまでの開発ではSpringを使う機会もあったのですが、 見易さ、改修性の高さ、開発規模から ServiceはInterfaceを使わずに実装しました。 (さすがにDAOはiBatis使って分けましたが) それに比べ、今回は10年前にCで作った参照のみのアプリの更新で 時間的な余裕もあるので遊びたいと思ってます。 APIも読んでみたのですが、XDOCLETを使うか、また宣言で問題があったら、 といった使い分けの程度しか理解できませんでした。 みなさん、どのような使い方されているのでしょうか、教えて頂けるとありがたいっす。 662 名前：デフォルトの名無しさん mailto:sage [2006/01/24(火) 13:57:58 ] >659 (1) と (3) は Struts に変更があったら、思い切り引きずられそう。 TilesRequestProcessor が出ようが新規に Action が発明されようが 涼しい顔して DelegatingActionProxy でラップするのみの (2) が好きですね。 (ていうか (2) しか使ったことないですけど。) その分設定ファイルは煩雑になるわけですが。 自分の分かりやすいと思える方法でやるのが一番かと。 小規模でそれほど寿命も長くないのであれば、(1) も手っ取り早くていいと思いますよ。 XDOCLET は思ったほど便利じゃないと言うか、 開発の間に試行錯誤してると、結局手で書いたほうが速かったでした。 ↑これは設計がまずかっただけかも知れません。 663 名前：デフォルトの名無しさん mailto:sage [2006/01/24(火) 23:17:11 ] >>662 Actionベースはやはり分かり易いですよね。 人数が多いそれなりの規模なら、間違いなくActionProxyでいくと思います。 いくつかサンプル作ってみたのですが、3種類の感想は ActionSupport -確かに楽だけど、Springの楽しさは十分に味わえない気が。 　でも実装はまんまActionなんで、いたって簡単。 　しかもプログラマの質がそれなりなら、自分入れて3人位いれば 　中規模まで行ける気がする。 ActionProxy -実質これがStruts&Springの標準でしょう。 　至って堅牢なシステムが訳分からん害虫と一緒でもテストファーストで 　スムーズに作れそう。 　しかもこれまでのStrutsの資産も十分に生かせるんじゃないでしょうか。 RequestProcessor -Controler以前の処理をガチガチにやるのであれば、やはりRequestProcessorだと 　思います。 　が、幾分硬すぎる気が。大人数のRUPには向いているかな。 自分ごときが作るシステムはそれほどクリティカルじゃないし、ユルイと思うのですが、 まあ当たり前、と言った感想でしょうか。 今回はActionProxyからやってみようと思います。 時間もある分、新しい人も多いんで。 また進展したら報告します。　いらんか。 664 名前：デフォルトの名無しさん mailto:sage [2006/01/25(水) 12:22:51 ] ＞また進展したら報告します。　いらんか。 最近スレが過疎ってるからチラシの裏でも問題ないかと。 ＞訳分からん害虫 でかいところが素敵なフレームワーク作ってるかと言うと そんな仕事にありつけたことが一度もないのは運が悪いんだろうか。 665 名前：659 mailto:sage [2006/01/25(水) 22:18:20 ] >>664 なかなか難しく厳しい問題です、拡張性･メンテナンス性を含めた機能美で言えば。 確かに誰がやったん?ってひどいのもありますが、現状では仕方ないかとも思っています。 1つはレガシーのためです。 やはり遺物であっても今から見ればあほあほなRDB設計であっても どうしても引きずらないではいられません。 例えばホストシステムの特定部分をWebに置き換える際、レガシーのデータやインターフェースは その他のホストのためにつないでやらないといけません。 おかげでせっかくのDAOも、結局は???になってしまいがちです。 これまで私も挑んだのですが砕け散りました。 もう一つは、企業にとってみればシステムが構築されれば後は減価償却の対象でしかありません。 本来3ヶ月かけて作るべきものであっても即興で1.5ヶ月でつくれば評価されてしまいます、 掛けたくないのは人件費な訳ですから。 もちろんこんなシステムの維持のコストは高いです。が、トップの方々には見えてきません。 ユーザーからの機能追加要望があった、といえば、それなりのコストであれば通ってしまいます。 海外拠点との情報連携なんてつけてやれば大喜びです。 (フェーズ毎に見積もりきちんととって開発も難しいのが現状ですから・・・) と、過疎板でうだつのあがらん社内SEが独り言ってみました。 666 名前：デフォルトの名無しさん mailto:sage [2006/01/25(水) 22:53:35 ] 664ですがマ板向きな話題になりそうなのでこの件はクローズ。 脱線させてごめんなさい。 667 名前：デフォルトの名無しさん mailto:sage [2006/01/29(日) 00:03:48 ] すいません、Spring.NETの話題もここで良かったりします？ 668 名前：デフォルトの名無しさん mailto:sage [2006/01/29(日) 09:45:51 ] わかんない。 けど、とりあえず書いてみれ 669 名前：デフォルトの名無しさん mailto:sage [2006/01/31(火) 10:23:30 ] >>659 ＞うだつのあがらん社内SE お前様はオレですかｗ 疑問に思ったことを二つ。 ＞見易さ、改修性の高さ、開発規模から ＞ServiceはInterfaceを使わずに実装しました。 何故だよ？　facadeした方がP層から見たときに理解しやすいし、 実装ロジックを意識しないで済むと思うのだけど。あと例えば 君がAPI定義して、君の手下が実装する、なんて作業も スムースになると思うのだけど。 あと、その場所にSpringのTransaction制御は適用してるの？ それとも君達でゴリゴリ書いているの？ そこがSpringの一番美味しい所だと思うのだが。 670 名前：デフォルトの名無しさん mailto:sage [2006/01/31(火) 10:24:23 ] ＜連投＞ ＞流行のSpringと扱い慣れているStrutsでと思っています。 扱い慣れているとはいえ、何故に死滅が確定している 現verのStruts？　同じ社内SEの立場として言うが、 それって将来に禍根を残すんじゃないの？ 特に、struts-taglibを使うのは忌むべきことじゃないのか？ 高度にクリティカルじゃなくてもいいなら、素直にJSFを 採用すりゃいいじゃん。もし、strutsじゃなきゃ人材を 確保できねぇと言うなら、せめて org.springframework.ui.velocityパッケージの研究を してから決定した方がいいんじゃないの？ 671 名前：デフォルトの名無しさん mailto:sage [2006/01/31(火) 12:13:28 ] 死滅とかはNG Wordに入れてる人も居るから避けたほうが吉。 JSF はもう少し枯れてからの方が良くない？ 今のところ、Velocity でやっちゃうのが一番直感的に思う。 672 名前：デフォルトの名無しさん mailto:sage [2006/01/31(火) 12:24:21 ] うちで使ってるアプリケーションサーバーはJSPしか動かねぇ Servletすら使えない 673 名前：デフォルトの名無しさん mailto:sage [2006/01/31(火) 15:42:57 ] 釣りには屈しない 674 名前：デフォルトの名無しさん mailto:sage [2006/02/01(水) 09:47:13 ] おぉ、まだ居る方が。 >>669 ServiceのInterfaceについては、いかに害虫がｵﾌﾞｼﾞｪｸﾄ指向を知らなくても ｵﾌﾞｼﾞｪｸﾄ指向らしいJavaになるか考えてこうなりました。 まずあの方達はｸﾗｽを上手く切り出せないんです、最初は。 で、下手にInterfaceやって使いまわしなんて考えると開発中の手入れが 恐ろしいことになり、ある意味好き勝手にやってもらいました。 で、DAOについてはﾒｿｯﾄﾞが明確なんでInterface切ってやってもらってます。 iBatisを使ってるんですが、こいつだとDAOの中のみでTransaction制御できるんで 助かります。 これだと統合ﾃｽﾄ中にこっちでｸﾘﾃｨｶﾙな部分がすぐいぢれるんで楽なんですよ。 675 名前：659 mailto:sage [2006/02/01(水) 10:14:07 ] 書き忘れですが、674 = 659です。 Strutsについては、JSFでの置換えも検討しましたが、 今回、自分以外はJavaでWebやるの初めてなんですよね。 やはりﾌﾞﾗｳｻﾞからRequestをServletで受けて、というのを実感 し易いのはStrutsかなぁ、と思います。 JSF、VBちっくにﾄﾞﾗｯｸﾞ＆ﾄﾞﾛｯﾌﾟでできてしまうんで、最初からこれだと 裏の理解が薄く後々に生きない気がします。 それと社内SE的にはもう少し枯れてからで良いかなと、正直思います。 Taglibについては、個人的にこれ以上覚えられるかー、ということで beanとlogicにのみ制限しています。 まあ多少beanを拡張はしていますが。。。 個人的には、Struts → JSFで行きたいなと、Viewについては。 676 名前：669 mailto:sage [2006/02/01(水) 10:53:44 ] >>659 ＞DAOの中のみでTransaction制御 これって複雑なことをやろうとすると破綻しないかい？ 複数のテーブルを更新するのもDaoのメソッド単位になる、 従って肥大したDaoImplを書かざるを得なくなる、という原因で。 オレのやり方だとこんな感じだ。 <ServiceLayer> public void deposit(Account account, Money increasedMoney){ 　　accountDao.update(account); 　　revenueDetailDao.insert(account, increasedMoney); } で、トランザクションはあくまでserviceLayerに置く。つまり上の depositメソッドに対してPROPAGATION_REQUIREDを設定する。 オレはさらに、dao層、上の例ではaccountDao.updateと revenueDetailDao.insertに対しては PROPAGATION_MANDATORYをかけている。 これによりserviceLayerを通さずにDaoに触ったら即座にアポーン。 君の「DAOの中のみでTransaction制御」だと、上の二つの メソッドを一つにまとめないと原始性を維持できないのでは？ 勘違いだったらｽﾏｿ。 677 名前：659 mailto:sage [2006/02/01(水) 12:13:46 ] >>669 DAO単位で考えれば原始性を維持できない可能性は仰る通り存在します。 でも、実際の使用で考えれば、多少複雑なﾃﾞｰﾀはﾕｰｻﾞに紐付いているわけで、 2重ログインを防げば、問題無しという訳です。 美しくないことは、確かですが。 Springでのﾄﾗﾝｻﾞｸｼｮﾝ管理は、まだ読んだだけですけど、実装も含めｽﾏｰﾄですね。 ﾄﾗﾝｻﾞｸｼｮﾝ属性なんか、いかにも楽できそうで。 DAOは何を使われてるんですか? 今回はHibernateが親和性も高く、情報も多いんで使おうかと思ってます。 678 名前：669 mailto:sage [2006/02/01(水) 13:12:05 ] う〜ん、オレにはそれはチョト怖く感じる。 更新が途中で落ちる可能性なんてゴロゴロしてるワケだし。。。 （オレには納得いかんが）落ちる可能性を完全無視するとしても、 その場合は最低でもペシミスティックロックで組まんとイカンと 思うのだけど。。。 頼む、トランザクション管理層をserviceLayerに持ち上げとくれ。 Spring使えばチョチョイのチョイだ。 iBATISは好きだぉ。 679 名前：デフォルトの名無しさん mailto:sage [2006/02/01(水) 16:24:19 ] >>669 仰ってることが分かってきました。 自分が話しをごっちゃにした予感です、害虫さんと自分の立場を。 害虫さんのﾄﾗﾝｻﾞｸｼｮﾝ管理は、はっきり言って、信用してません。 で、問題があった際にDAOとServiceを引っ張って考えるのはしんどいんで DAOについてはiBatisのAutoCommitにして、自分はServiceに集中できるように している、という話です。 読み返してみると、確かに訳分からん話してますね、自分。 そういえば、SpringとベストマッチなDAOって何でしょ? iBatisもいけるようだとﾈｯﾄに載ってた気がしますが、やはりHibernateですかね? 他に面白いのないでしょうか。 680 名前：デフォルトの名無しさん mailto:sage [2006/02/01(水) 20:56:14 ] HibernateはDBを一から設計するっていうならおすすめ 既存のDBがからむならiBatisの方が無難だとおもう 害虫さんがいてiBatis学習コストが気になるっていうなら Spring JDBCでもいいんじゃない？ 681 名前：デフォルトの名無しさん mailto:sage [2006/02/02(木) 01:17:25 ] >>675 ＞Taglibについては、個人的にこれ以上覚えられるかー、ということで ＞beanとlogicにのみ制限しています。 Strutsでやるんなら最低限必要なStrutsタグはhtmlタグのみで、後はJSTLで置き換えるのがお勧め JSTLはJava EE5に含まれることが決定しているし、JSFも1.2からはJSTLと連携出来るようになる 682 名前：デフォルトの名無しさん mailto:sage [2006/02/02(木) 01:36:23 ] お勧めとかではなく、beanとかlogicを使うべきではない、という感じだな。 683 名前：659 mailto:sage [2006/02/02(木) 10:15:36 ] >>680 既存DB、IMSもRDBもわんさかあるんで、これまではiBatisだったんですよね。 ｵﾌﾞｼﾞｪｸﾄﾍﾞｰｽでのDB考えるなら、Hibernateというｲﾒｰｼﾞは確かに強いですよね。 そんな幸せな開発はやったことありませんが。 >>681、682 z/OS中心の製造業社内SE的には、Webのプレゼンテーション層については過渡期に 感じるので、枯れ果てた技術で十分かなと思います。 新しい技術を入れても今後ﾒﾝﾃする人が大変なだけですよ、うちのような環境では。 JDKにしても既存のものは1.4.Xが限度で、5にすることなんてありえません。 ぶっちゃけ、手間の割にﾒﾘｯﾄがあんまり考えられません。 それよりも新しいWASには5を導入する方向で考えると思います。 個人的にはJSFの熟成を期待しつつ、ちょっと複雑になりそうだったらﾘｯﾁで、 と行ければ良いなぁ。 ・・・今はこんなこと考えている自分が、ちょっと嫌。 Javaを始めて勉強してた頃はｵﾌﾞｼﾞｪｸﾄ指向に感動し、新技術ﾏﾝｾｰだったのに。 他に居ないのかな、こんな方。 684 名前：デフォルトの名無しさん mailto:sage [2006/02/02(木) 11:17:28 ] >682 beanを使うべきじゃないとは言っても、 messageはなかなか避けられないような。 685 名前：669 mailto:sage [2006/02/02(木) 11:31:58 ] おいおい、そんな後ろ向きになるなよ。 新技術に対する感動を忘れたらオレらの仕事はつまらなく なるばかりだぜ。つーか、今でもspring・iBATIS・hibernateって やってるんだろーが。何でviewだけそんなに野望を失うのさ？ struts-taglibは、数年後には非推奨API（あるいはそれに準じた 無体な扱いを受ける立場）になるんだぜ？　君は後進に 非推奨APIのメンテをさせる気かい？ JSF怖くないってｗ　つーかあれ便利だぞ。少なくてもstrutsに 比べりゃね。なんつったて同じ作者の二番煎じなんだから。 JSF自体がDI持ってるからSpringとの組み合わせもし易いしね。 練れてなくて意味無い所で苦労を強いられるのは認めるけど。 な〜んて書きながら、オレ自身もJSFマンセーには なりきれないのだけどね。初期の頃に宣伝されたリッチ クライアント対応とか全然進んでねぇし。（JDNCは実質 ポシャったみたいね）　早いとこJSPの呪縛から抜け出して 欲しいと思っているのに、なんか全然別の方向に逝こうと しているみたいだし。。。 愚痴ｽﾏｿ 686 名前：デフォルトの名無しさん mailto:sage [2006/02/02(木) 11:44:00 ] JSFも悪くないと思うけどね、まだ出来たてのせいか ちょっとこなれてない感じ。 EL式とかアレだし。 sunのより高機能なんでmyfaces使っても、バグが結構あって DataTableとか微妙な挙動をする場合がある。 1.2待ちかな 687 名前：デフォルトの名無しさん mailto:sage [2006/02/02(木) 13:02:24 ] >>684 messageは使うね。 >>686 2年もたってるのに、出来立てはないとおもう 688 名前：659 mailto:sage [2006/02/03(金) 12:37:57 ] >>669 Viewも野望だけはあるんですけどね。 ただWebだと、JSFにしても色々あり過ぎて、決め手に欠けます。 それにお偉方の説得材料が足りません。 もう暫くおとなしく待って、淘汰されてから選んで良いかな。 Viewはお偉方にも分かってしまうんで、ここ以外は、好き勝手やれるんだけどねぇ。 689 名前：デフォルトの名無しさん mailto:sage [2006/02/03(金) 13:49:52 ] 正直jsp2.0で十分な気が 690 名前：デフォルトの名無しさん mailto:sage [2006/02/15(水) 15:03:14 ] Hibernate3初心者ですが、ちょっと教えて下さい。 many-to-one のﾏｯﾌﾟで、もし該当ﾃﾞｰﾀが存在しなくても怒られない方法、 知りませんか? 例えば <class name="item"> <id name="id"/> <many-to-one name="bid"/> </class> <class name="bid"> <id name="id"/> <pro name="amount"/> </class> これで from Item item left join fetch item.bid　をやって、 取得したリストを表示させると、bidを取得できなかったitemの item.bid.amountをgetすると、 LazyInitializ E org.hibernate.LazyInitializationException TRAS0014I: 次の例外がログに記録されました。 org.hibernate.LazyInitializationException: could not initialize proxy - the owning Session was closed と、ｱﾎﾞﾝです。 session閉じて分離ｵﾌﾞｼﾞｪｸﾄになってんだから、良いじゃん、 と思うんだけど、教えて下され。 691 名前：デフォルトの名無しさん mailto:sage [2006/02/15(水) 15:11:12 ] >>690 スレ違い pc8.2ch.net/test/read.cgi/tech/1134701684/ 692 名前：690 mailto:sage [2006/02/15(水) 15:56:38 ] >691 ｽﾏｿ 693 名前：デフォルトの名無しさん mailto:sage [2006/03/07(火) 11:35:44 ] 保守、というか1.2.7記念。 694 名前：デフォルトの名無しさん mailto:sage [2006/03/07(火) 12:03:36 ] EJB3.0 のどこが DI なのかと思い始める今日この頃。 695 名前：デフォルトの名無しさん mailto:sage [2006/03/07(火) 12:49:55 ] つまり、勉強不足？ 696 名前：デフォルトの名無しさん mailto:sage [2006/03/07(火) 23:10:38 ] @EJBアノテーションによるフィールドインジェクションだが？ 697 名前：デフォルトの名無しさん mailto:sage [2006/03/07(火) 23:40:25 ] まぁ勉強不足なのは確かだが。 結局クライアントコードに依存性を書いてる辺りが、 確かに従来のJavaの文法じゃないけど アノテーションと言う名前のただの lookup じゃん、とか。 (DIとは関係ないが)@Statefulも アノテーションと言う名前の implicit な interface になっただけで 同じことをするのに書法のバリエーションが増えただけで Perl のガラクタ折衷主義を思い出したり。 698 名前：デフォルトの名無しさん mailto:sage [2006/03/08(水) 22:01:48 ] "アノテーション使ってるからDIじゃない"っていいたいの？ interfaceがメソッドに付けれますか、と。 "ただのlookup"ではないしな。 結局アノテーションどうこうとゴネてるやつって、変化を受け入れれないだけなんだよな。 699 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 01:38:51 ] クライアント側でリソース名を明示的に書いているから DIとはいいがたいと思ってます。 ＞"ただのlookup"ではないしな。 どんな嬉しさがあるか、教えていただけないでしょうか。 煩雑な記述が減る程度しか思いつきません。 ＞interfaceがメソッドに付けれますか、と。 @Stateful はメソッドに付かないと思うけど。 700 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 03:37:13 ] >>699 > クライアント側でリソース名を明示的に書いているからDIとはいいがたいと思ってます。 つまり、DIをわかってないと。 701 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 13:01:15 ] そっか。DIの定義が変わったのか。 702 名前：デフォルトの名無しさん mailto:sage [2006/03/09(木) 22:20:05 ] >>701 変ってないだろ。 君が勘違いしてるだけ。 703 名前：デフォルトの名無しさん [2006/03/11(土) 15:16:19 ] 2.0になってどう？ 近い将来でseasar使うか2.0使うか迷ってるんだが、 Spring側の利点が見つからない・・・ 両方つかってみたけど、seasarだとXMLをかなり省けるから 楽なんだが・・・ 誰か意見ください。 704 名前：デフォルトの名無しさん mailto:sage [2006/03/13(月) 13:14:45 ] >702 DIって、クライアント側で明示的にリソース指定した部分が コンテナが注入するようになって素敵だよって流れだと思ってたんですが。 で、勘違いのない本当の定義とは？ >703 利点が見つからないならSeaser2使えば良いかと。 とりあえずXMLが省けることは多分大した利点にならんよ。 705 名前：デフォルトの名無しさん mailto:sage [2006/03/13(月) 21:56:40 ] 横槍ｽﾏｿ >>704 そもそもEJB3のDIは「明示的にリソース指定」はしないぞ ＞とりあえずXMLが省けることは多分大した利点にならんよ。 その根拠は？ 書かなくて済むのであれば書かないに越したことは無いし XMLのメンテナンスだって馬鹿にならない 706 名前：デフォルトの名無しさん mailto:sage [2006/03/13(月) 23:15:36 ] >>704 DIの最低限の定義は、自分でインスタンスをとって来ないで、よそから注入してもらうこと。 @EJBアノテーションつけたとしても、それなりのコンテナ使わない限りなにも影響はない。 そのままSpringやSeasar使えばそれなりに注入される。 707 名前：デフォルトの名無しさん mailto:sage [2006/03/14(火) 10:32:53 ] DIに関して705氏と706氏の意見で納得。 確かに自分でインスタンスとってきてるわけではないね。 俺はとってくる情報が書かれてることそのものが嫌いなんですが これはDIとは関係ないってことですね。 >その根拠は？ autowire 使えばそれなりに記述量は減るけれども 曖昧さが増えてかえって混乱を招くだけだった、との経験から。 Seasar2だと違うのかも知れない。 適当なこと言ってごめんなさい。 それにしても盛り上がらないスレですね。なんでだろ。 708 名前：デフォルトの名無しさん mailto:sage [2006/03/14(火) 18:46:23 ] 一部雑誌や新しいもの好きが飛びついてるだけで 現場ではほとんど使われてないから。 709 名前：デフォルトの名無しさん mailto:sage [2006/03/14(火) 19:36:29 ] はい、飛びつきました 710 名前：デフォルトの名無しさん [2006/03/14(火) 22:14:33 ] うちでは全部SpringかSeasar使ってるが、世間ではそうなのか？ トランザクションに関してはとても楽だが 711 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 17:34:47 ] >>707 いったん使い出せば、通常の範囲では質問もなにもないし、特に話題がないからかもね。 712 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 17:52:50 ] ｲｲﾅｰ うちで使ってるｽｹﾞｰ高いアプリケーションサーバーは jspしか使えない 713 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 21:47:24 ] そりゃないんじゃね〜の？ 714 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 22:14:35 ] >>712 BroadVision One-To-One 以前はC++しか使えなかった。マジで。 715 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 22:14:55 ] 713宛てだった 716 名前：デフォルトの名無しさん mailto:sage [2006/03/15(水) 22:30:54 ] 「Portal,Commerceの価格は1CPUで810万円からとなっております。」 ΣΣ（ﾟдﾟlll） 717 名前：デフォルトの名無しさん mailto:sage [2006/03/16(木) 00:03:31 ] そういやあ、WebObjectsも昔は７５０万とかしたよなあ。。。。 718 名前：デフォルトの名無しさん mailto:sage [2006/03/16(木) 00:05:24 ] 製品カタログ見ても何をするものなのかが分からん。 719 名前：デフォルトの名無しさん mailto:sage [2006/03/16(木) 02:13:23 ] JSPしか動かないTomcatみたいなの ショボいDBのラッパーとかユーザー管理とかビジネスルールのライブラリとかがいっぱい付いてる あと やたら高い 720 名前：デフォルトの名無しさん mailto:sage [2006/03/16(木) 03:57:55 ] うちの会社で出してるゴミコンポーネントも945万円するお。 1年で1個売れれば万々歳だって。 721 名前：デフォルトの名無しさん mailto:sage [2006/03/17(金) 16:09:08 ] そりゃむしろ、945万もするから売れるんだろう。 金を出す人間は、無料でしっかりしたモノを嫌がって バカ高くてヘボいモノを好む傾向にあるから。 で、現場は地獄を見る、と。 722 名前：デフォルトの名無しさん mailto:sage [2006/03/17(金) 17:20:41 ] 無料だとちょっと問題が出るとすぐ捨てるけど、 金かけてると捨てるわけにはいかないからなあ 723 名前：http://www.vector.co.jp/soft/win95/util/se072729.html mailto:http://msdn2.microsoft.com/ja-jp/library/h2k70f3s.aspx [2006/03/18(土) 20:26:19 ] TextSS　のWindowsXP(Professional)64bit化おながいします もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？ 724 名前：デフォルトの名無しさん mailto:sage [2006/03/25(土) 12:11:47 ] なあ、参照しかしないクエリーでもトランザクション切ってる なんて事ないよな？ サービスのインスタンス化時にトランザクション切るのをデフォルト にしてるのを見たことあるぞ。。。 同時アクセス数増えたとき、大変な事になるのがわからんのじゃろうか。 725 名前：デフォルトの名無しさん [2006/03/27(月) 10:58:31 ] AOPでトランザクション管理するなら、 READだけの処理では普通は開かんようにするはず。 726 名前：デフォルトの名無しさん mailto:sage [2006/03/27(月) 14:11:08 ] >AOPでトランザクション管理するなら してなかったりして 727 名前：デフォルトの名無しさん mailto:sage [2006/03/27(月) 16:22:43 ] 貼っとく 【BEA】Using the Java Persistence API with Spring 2.0 dev2dev.bea.com/pub/a/2006/03/jpa-spring-medrec.html 728 名前：デフォルトの名無しさん mailto:sage [2006/03/27(月) 19:02:56 ] >>724 どうして大変な事になるの？ 729 名前：デフォルトの名無しさん mailto:sage [2006/03/28(火) 09:58:12 ] 複数のテーブルを参照してひとつのデータを作るような場合は、 読み込みでもトランザクションきらないとまずいんじゃないの？ 730 名前：デフォルトの名無しさん mailto:sage [2006/03/28(火) 10:11:35 ] >>729 > 複数のテーブルを参照してひとつのデータを作るような場合は、 JOINではなくて、複数のSELECT発行って事？ 731 名前：デフォルトの名無しさん mailto:sage [2006/03/28(火) 11:05:09 ] >>730 ISOLATION_LEVELのデフォルトって普通はREAD_COMMITTEDじゃないの？ 複数のSELECTまで考えるとISOLATION_LEVELをREPEATABLE_READに変更しないと駄目じゃない？ 732 名前：デフォルトの名無しさん [2006/03/28(火) 11:33:17 ] >>731 InnoDBのデフォルトはREPEATABLE_READみたいだなあ 733 名前：730 mailto:sage [2006/03/28(火) 11:45:37 ] >>731 >>732 DBベンダによってデフォルトが異なる。んで、大抵はREPEATABLE_READ(らしい)。 結論としては、複数のSELECTを発行するサービスのメソッドは トランザクション制御しなきゃならんって事か。 734 名前：731 mailto:sage [2006/03/28(火) 11:59:04 ] >>732 Oracleのデフォルトは文レベルの読み取り一貫性(READ_COMMITTED)だったような... >>733 >結論としては、複数のSELECTを発行するサービスのメソッドは >トランザクション制御しなきゃならんって事か。 加えて以下の様に明示的にISOLATIONレベルを指定しないといけないのかな？ <property name="transactionAttributes"> <props> <prop key="get*">PROPAGATION_REQUIRED, ISOLATION_REPEATABLE_READ, readOnly</prop> </props> </property> 735 名前：733(=730) mailto:sage [2006/03/28(火) 12:24:32 ] >>734 いささか古いが、 www.tomlauren.com/weblog/archives/000019.html によると、OracleのデフォルトはREAD_COMMITTEDみたいだ。 でも、REPEATABLE_READがNotSupportって事になると、 SERIALIZABLEしかないな。 最新の公式資料キボン。 736 名前：731 mailto:sage [2006/03/28(火) 14:16:43 ] >>735 Oracleで以下の操作をやると conn.setTransactionIsolation(Connection.TRANSACTION_REPEATABLE_READ); java.sql.SQLException: READ_COMMITTEDおよびSERIALIZABLEのみが有効なトランザクション・レベルです。 ... ってエラーが出るよ。 Oracleだと更新処理を伴うトランザクションでトランザクションレベルの読み取り一貫性を 保証したいのであればSERIALIZABLEを指定するしかないのでは？ ※更新処理を伴わないのであればreadOnlyだけで大丈夫みたい でも実際にSERIALIZABLEがどうしても必要になる局面があんまり無いような気も... で、元の話は >>724 > なあ、参照しかしないクエリーでもトランザクション切ってる > なんて事ないよな？ ってことだけどこれって 読み取り一貫性を保証しなくて良い参照のみのトランザクションでAOPで管理せず、AutoCommitも無効にしている場合、 明示的にトランザクションを開始する必要があるのか？ という意味なのかな？ 737 名前：デフォルトの名無しさん mailto:sage [2006/03/28(火) 16:19:46 ] Strutsを使った場合の、AOPによる宣言的トランザクション管理について意見を聞かせてください。 (前提) ・サービスクラスの各メソッドはAOPによって宣言的トランザクション管理されている。 (処理) ・リクエスト->更新Action->表示Action->JSPとディスパッチする。 ・更新Actionと表示ActionはサービスクラスのupdateHoge()やfindHoge()を呼び出す。 これだと、1回のリクエスト中に2つのActionが2回ビジネスロジックを実行するから、 トランザクションも2回発生してしまいますよね？(1操作=2トランザクション) 何となく腑に落ちませんが、これが当たり前なんでしょうか？ それとも、Facadeサービスから更新も検索もまとめて呼ぶべきでしょうか？ 更新と検索の引数リストが全く異なる場合はFacadeしたくないんですが… 738 名前：デフォルトの名無しさん mailto:sage [2006/03/28(火) 20:03:23 ] 好きにしろとしか…… 個人的には、更新作業の頻度次第で決める 739 名前：デフォルトの名無しさん [2006/03/29(水) 11:26:28 ] 本家よりコピペ Spring 2.0 Release Party in Stuttgart (organized by JUGS) Submitted by Juergen Hoeller on Fri, 2006-02-24 18:31. Event Start: 2006-03-30 14:00 End: 2006-03-30 23:00 Timezone: -14400 いよいよ2.0が間もなく到来だぬ。 ところで2.0の目玉って何なのさ？（恥） 740 名前：デフォルトの名無しさん mailto:sage [2006/03/29(水) 16:35:27 ] >>738 んじゃ、Action2つにする。 とりあえず、HibernateでOpenSessionInViewしておけばAction2つでも 1トランザクションになるよね？ 741 名前：デフォルトの名無しさん mailto:sage [2006/03/31(金) 23:11:17 ] >>740 トランザクションとHibernateのセッションの区別はついてますか？ 742 名前：デフォルトの名無しさん mailto:sage [2006/03/32(土) 00:26:43 ] これ、掻い摘んでいうと何？ 743 名前：デフォルトの名無しさん mailto:sage [2006/03/32(土) 01:38:39 ] 軽量コンテナ 744 名前：デフォルトの名無しさん mailto:sage [2006/03/32(土) 05:59:35 ] >>742 「Java2EEなんかクソくらえ」 745 名前：デフォルトの名無しさん [2006/03/32(土) 06:03:37 ] 今日は32日だ。うそをついていい日ではない。 746 名前：デフォルトの名無しさん mailto:sage [2006/03/32(土) 10:39:20 ] www.2ch.net/ ＊エイプリルフール中止のお知らせ＊ 本年度、ITバブル崩壊の余波、またライブドア事件の混迷、楽天ゴールデンイーグルスぶっちぎり最下位など、 悪条件の重なりによる株価低迷が２ちゃんねる運営費にも多大なる影響を与え、 火の車である今の財務状況を鑑みるに、エイプリルフールの全面中止もやむなしという判断にあいなりました。 ご期待されていた皆様には大変申し訳ありませんが、どうぞよろしくご理解いただければ幸いです。 また、妄言民族と呼ばれ、近隣アジア諸国に多大なる苦痛を与えている日本国民としてこれを良い機会と考え、 例えエイプリルフールだとしても嘘を無くし、世界平和に貢献できる公明正大な言論の場を標榜すべく襟を正しつつ、 ２ちゃんねるはエイプリルフールの根絶に今後とも邁進していく所存でございます。 747 名前：724 mailto:sage [2006/04/02(日) 12:30:05 ] >読み取り一貫性を保証しなくて良い参照のみのトランザクションでAOPで管理せず、 >AutoCommitも無効にしている場合、明示的にトランザクションを開始する必要があるのか？ そうじゃ。RDBにもよるが、読み取り一貫性を実現するために、大体がテンポラリ領域に データをコピーしている（OracleとSQL Serverは少なくともそう）。 この事から、一覧など頻繁に閲覧されてデータ量が多い場合、直ぐエラーになっちまう。 （同時アクセスが多いと、Tempがクリアされる前に次が来ちゃうからじゃ） このエラーを受けてDB屋にTemp領域増やせっていうのはナンセンス。 もちろん、ビジネスロジック上大きなTempが必要な場合もあるからそれは、 ちゃんと見積もりをDB屋に伝えればいい。大きくするのに否定的な訳じゃなく PGの手抜きに対して文句を言ってるんじゃ。 また、上記の事だけじゃないが、上記だけからでも結構コスト（負荷） が掛かることは言うまでもないよな。 748 名前：デフォルトの名無しさん mailto:sage [2006/04/02(日) 13:10:03 ] >>747 > そうじゃ。RDBにもよるが、読み取り一貫性を実現するために、大体がテンポラリ領域に > データをコピーしている（OracleとSQL Serverは少なくともそう）。 オラクルは違うだろ。 データがコピーされるのは読み取り時じゃなくて更新時。 コピー先はテンポラリじゃなくてUNDO表領域。 > この事から、一覧など頻繁に閲覧されてデータ量が多い場合、直ぐエラーになっちまう。 頻繁に閲覧されてもそれだけじゃエラーにならない。 頻繁に更新されている時にのんびり読んでるとORA-01555 本当に理解して書いてるか？ 749 名前：デフォルトの名無しさん mailto:sage [2006/04/02(日) 15:04:58 ] > > この事から、一覧など頻繁に閲覧されてデータ量が多い場合、直ぐエラーになっちまう。 > > 頻繁に閲覧されてもそれだけじゃエラーにならない。 > 頻繁に更新されている時にのんびり読んでるとORA-01555 > 本当に理解して書いてるか？ 激しく同意。 付け加えるなら、Oracleではトランザクションの有無にかかわらず 文レベルの一貫性は常に保証しようとするから、 > 頻繁に更新されている時にのんびり読んでるとORA-01555 という状況はトランザクションの有無にかかわらず起こりうる。 だから、>747の主張は少なくともOracleには当てはまらない。 750 名前：740 mailto:sage [2006/04/02(日) 18:58:45 ] >>741 スマソ＆サンクス 考えてみれば、サービス層でAOPトランザクション管理していると、 複数Actionが複数サービス呼び出す時点で複数トランザクションになる… んでOpenSesseionInViewしてもHibernateのSessionが1つに保たれるだけですな。 結論すると、2Actionだと2トランザクションでいくしかないのか。 751 名前：731 mailto:sage [2006/04/03(月) 14:34:04 ] あんまりSpringと関係が無くなって来たような気が... >>747 >>748 >>749 読み取り一貫性に関しての詳細は置いておいて元の話だとOracleでは 以下になるんじゃないかな？ 必要な読み取り一貫性が文をまたがるのであれば読み取り専用の トランザクションを明示的に開始する必要がある。 必要な読み取り一貫性が文レベルでよいのであれば明示的にトランザクションを 開始しなくても良い(コネクションを生成した際のトランザクションがずっと使われている) 但し、更新処理の前にはCommitを発行して明示的にトランザクションを開始する必要がある どちらにしてもOracleで更新やロックを伴わないトランザクションでCommitを行っても 無視される(v$sesstatのuser_commitは増えない)のでパフォーマンスには大した影響を与えない 結局のところ空コミット(参照のみトランザクションでのコミット)のコストの話なのかな？ 752 名前：740 mailto:sage [2006/04/07(金) 20:14:03 ] 今さらだが、ようやくStruts+Spring+Hibernate (DelegatingActionProxy、 StandardXAPoolDataSource、 JOTM、 OpenSessionInViewFilter、 JtaTransactionManager) のアプリが作れたよ… さて、次はSeasarも試してみるか… 753 名前：デフォルトの名無しさん [2006/04/07(金) 23:51:41 ] Hibernateって使える？ 754 名前：デフォルトの名無しさん mailto:sage [2006/04/08(土) 06:37:50 ] Java標準になったくらい使える。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef