トップページ⇒tech
1001コメント358KB

Java Spring Frameworkを語るスレ

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさんNGNG
http://www.springframework.org/

乱立するフレームワークと競合するプロトコルの嵐のなかで、
リスクの高い決断を余儀なくされているJavaデベロッパ、プ
ロジェクトマネージャに対する福音です。

語るべし。
0682デフォルトの名無しさん2006/02/02(木) 01:36:23
お勧めとかではなく、beanとかlogicを使うべきではない、という感じだな。
06836592006/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を始めて勉強してた頃はｵﾌﾞｼﾞｪｸﾄ指向に感動し、新技術ﾏﾝｾｰだったのに。
他に居ないのかな、こんな方。




0684デフォルトの名無しさん2006/02/02(木) 11:17:28
>682
beanを使うべきじゃないとは言っても、
messageはなかなか避けられないような。
06856692006/02/02(木) 11:31:58
おいおい、そんな後ろ向きになるなよ。

新技術に対する感動を忘れたらオレらの仕事はつまらなく
なるばかりだぜ。つーか、今でもspring・iBATIS・hibernateって
やってるんだろーが。何でviewだけそんなに野望を失うのさ？

struts-taglibは、数年後には非推奨API（あるいはそれに準じた
無体な扱いを受ける立場）になるんだぜ？　君は後進に
非推奨APIのメンテをさせる気かい？

JSF怖くないってｗ　つーかあれ便利だぞ。少なくてもstrutsに
比べりゃね。なんつったて同じ作者の二番煎じなんだから。
JSF自体がDI持ってるからSpringとの組み合わせもし易いしね。
練れてなくて意味無い所で苦労を強いられるのは認めるけど。

な〜んて書きながら、オレ自身もJSFマンセーには
なりきれないのだけどね。初期の頃に宣伝されたリッチ
クライアント対応とか全然進んでねぇし。（JDNCは実質
ポシャったみたいね）　早いとこJSPの呪縛から抜け出して
欲しいと思っているのに、なんか全然別の方向に逝こうと
しているみたいだし。。。

愚痴ｽﾏｿ
0686デフォルトの名無しさん2006/02/02(木) 11:44:00
JSFも悪くないと思うけどね、まだ出来たてのせいか
ちょっとこなれてない感じ。 EL式とかアレだし。
sunのより高機能なんでmyfaces使っても、バグが結構あって
DataTableとか微妙な挙動をする場合がある。

1.2待ちかな
0687デフォルトの名無しさん2006/02/02(木) 13:02:24
>>684
messageは使うね。

>>686
2年もたってるのに、出来立てはないとおもう
06886592006/02/03(金) 12:37:57
>>669
Viewも野望だけはあるんですけどね。
ただWebだと、JSFにしても色々あり過ぎて、決め手に欠けます。
それにお偉方の説得材料が足りません。
もう暫くおとなしく待って、淘汰されてから選んで良いかな。

Viewはお偉方にも分かってしまうんで、ここ以外は、好き勝手やれるんだけどねぇ。

0689デフォルトの名無しさん2006/02/03(金) 13:49:52
正直jsp2.0で十分な気が
0690デフォルトの名無しさん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閉じて分離ｵﾌﾞｼﾞｪｸﾄになってんだから、良いじゃん、
と思うんだけど、教えて下され。
0691デフォルトの名無しさん2006/02/15(水) 15:11:12
>>690
スレ違い
http://pc8.2ch.net/test/read.cgi/tech/1134701684/
06926902006/02/15(水) 15:56:38
>691
ｽﾏｿ
0693デフォルトの名無しさん2006/03/07(火) 11:35:44
保守、というか1.2.7記念。
0694デフォルトの名無しさん2006/03/07(火) 12:03:36
EJB3.0 のどこが DI なのかと思い始める今日この頃。
0695デフォルトの名無しさん2006/03/07(火) 12:49:55
つまり、勉強不足？
0696デフォルトの名無しさん2006/03/07(火) 23:10:38
@EJBアノテーションによるフィールドインジェクションだが？
0697デフォルトの名無しさん2006/03/07(火) 23:40:25
まぁ勉強不足なのは確かだが。

結局クライアントコードに依存性を書いてる辺りが、
確かに従来のJavaの文法じゃないけど
アノテーションと言う名前のただの lookup じゃん、とか。

(DIとは関係ないが)@Statefulも
アノテーションと言う名前の implicit な interface になっただけで
同じことをするのに書法のバリエーションが増えただけで
Perl のガラクタ折衷主義を思い出したり。
0698デフォルトの名無しさん2006/03/08(水) 22:01:48
"アノテーション使ってるからDIじゃない"っていいたいの？

interfaceがメソッドに付けれますか、と。
"ただのlookup"ではないしな。
結局アノテーションどうこうとゴネてるやつって、変化を受け入れれないだけなんだよな。
0699デフォルトの名無しさん2006/03/09(木) 01:38:51
クライアント側でリソース名を明示的に書いているから
DIとはいいがたいと思ってます。

＞"ただのlookup"ではないしな。
どんな嬉しさがあるか、教えていただけないでしょうか。
煩雑な記述が減る程度しか思いつきません。

＞interfaceがメソッドに付けれますか、と。
@Stateful はメソッドに付かないと思うけど。
0700デフォルトの名無しさん2006/03/09(木) 03:37:13
>>699
> クライアント側でリソース名を明示的に書いているからDIとはいいがたいと思ってます。

つまり、DIをわかってないと。
0701デフォルトの名無しさん2006/03/09(木) 13:01:15
そっか。DIの定義が変わったのか。
0702デフォルトの名無しさん2006/03/09(木) 22:20:05
>>701
変ってないだろ。
君が勘違いしてるだけ。
0703デフォルトの名無しさん2006/03/11(土) 15:16:19
2.0になってどう？
近い将来でseasar使うか2.0使うか迷ってるんだが、
Spring側の利点が見つからない・・・

両方つかってみたけど、seasarだとXMLをかなり省けるから
楽なんだが・・・

誰か意見ください。
0704デフォルトの名無しさん2006/03/13(月) 13:14:45
>702
DIって、クライアント側で明示的にリソース指定した部分が
コンテナが注入するようになって素敵だよって流れだと思ってたんですが。
で、勘違いのない本当の定義とは？

>703
利点が見つからないならSeaser2使えば良いかと。
とりあえずXMLが省けることは多分大した利点にならんよ。
0705デフォルトの名無しさん2006/03/13(月) 21:56:40
横槍ｽﾏｿ

>>704
そもそもEJB3のDIは「明示的にリソース指定」はしないぞ

＞とりあえずXMLが省けることは多分大した利点にならんよ。
その根拠は？
書かなくて済むのであれば書かないに越したことは無いし
XMLのメンテナンスだって馬鹿にならない
0706デフォルトの名無しさん2006/03/13(月) 23:15:36
>>704
DIの最低限の定義は、自分でインスタンスをとって来ないで、よそから注入してもらうこと。

@EJBアノテーションつけたとしても、それなりのコンテナ使わない限りなにも影響はない。
そのままSpringやSeasar使えばそれなりに注入される。
0707デフォルトの名無しさん2006/03/14(火) 10:32:53
DIに関して705氏と706氏の意見で納得。
確かに自分でインスタンスとってきてるわけではないね。
俺はとってくる情報が書かれてることそのものが嫌いなんですが
これはDIとは関係ないってことですね。

>その根拠は？
autowire 使えばそれなりに記述量は減るけれども
曖昧さが増えてかえって混乱を招くだけだった、との経験から。
Seasar2だと違うのかも知れない。
適当なこと言ってごめんなさい。

それにしても盛り上がらないスレですね。なんでだろ。
0708デフォルトの名無しさん2006/03/14(火) 18:46:23
一部雑誌や新しいもの好きが飛びついてるだけで
現場ではほとんど使われてないから。
0709デフォルトの名無しさん2006/03/14(火) 19:36:29
はい、飛びつきました
0710デフォルトの名無しさん2006/03/14(火) 22:14:33
うちでは全部SpringかSeasar使ってるが、世間ではそうなのか？
トランザクションに関してはとても楽だが
0711デフォルトの名無しさん2006/03/15(水) 17:34:47
>>707
いったん使い出せば、通常の範囲では質問もなにもないし、特に話題がないからかもね。
0712デフォルトの名無しさん2006/03/15(水) 17:52:50
ｲｲﾅｰ
うちで使ってるｽｹﾞｰ高いアプリケーションサーバーは
jspしか使えない
0713デフォルトの名無しさん2006/03/15(水) 21:47:24
そりゃないんじゃね〜の？
0714デフォルトの名無しさん2006/03/15(水) 22:14:35
>>712
BroadVision One-To-One
以前はC++しか使えなかった。マジで。
0715デフォルトの名無しさん2006/03/15(水) 22:14:55
713宛てだった
0716デフォルトの名無しさん2006/03/15(水) 22:30:54
「Portal,Commerceの価格は1CPUで810万円からとなっております。」
ΣΣ（ﾟдﾟlll）
0717デフォルトの名無しさん2006/03/16(木) 00:03:31
そういやあ、WebObjectsも昔は７５０万とかしたよなあ。。。。
0718デフォルトの名無しさん2006/03/16(木) 00:05:24
製品カタログ見ても何をするものなのかが分からん。
0719デフォルトの名無しさん2006/03/16(木) 02:13:23
JSPしか動かないTomcatみたいなの
ショボいDBのラッパーとかユーザー管理とかビジネスルールのライブラリとかがいっぱい付いてる
あと やたら高い
0720デフォルトの名無しさん2006/03/16(木) 03:57:55
うちの会社で出してるゴミコンポーネントも945万円するお。
1年で1個売れれば万々歳だって。
0721デフォルトの名無しさん2006/03/17(金) 16:09:08
そりゃむしろ、945万もするから売れるんだろう。
金を出す人間は、無料でしっかりしたモノを嫌がって
バカ高くてヘボいモノを好む傾向にあるから。

で、現場は地獄を見る、と。
0722デフォルトの名無しさん2006/03/17(金) 17:20:41
無料だとちょっと問題が出るとすぐ捨てるけど、
金かけてると捨てるわけにはいかないからなあ
0723http://www.vector.co.jp/soft/win95/util/se072729.html2006/03/18(土) 20:26:19
TextSS　のWindowsXP(Professional)64bit化おながいします

もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？
0724デフォルトの名無しさん2006/03/25(土) 12:11:47
なあ、参照しかしないクエリーでもトランザクション切ってる
なんて事ないよな？
サービスのインスタンス化時にトランザクション切るのをデフォルト
にしてるのを見たことあるぞ。。。
同時アクセス数増えたとき、大変な事になるのがわからんのじゃろうか。
0725デフォルトの名無しさん2006/03/27(月) 10:58:31
AOPでトランザクション管理するなら、
READだけの処理では普通は開かんようにするはず。
0726デフォルトの名無しさん2006/03/27(月) 14:11:08
>AOPでトランザクション管理するなら
してなかったりして
0727デフォルトの名無しさん2006/03/27(月) 16:22:43
貼っとく

【BEA】Using the Java Persistence API with Spring 2.0
http://dev2dev.bea.com/pub/a/2006/03/jpa-spring-medrec.html
0728デフォルトの名無しさん2006/03/27(月) 19:02:56
>>724
どうして大変な事になるの？
0729デフォルトの名無しさん2006/03/28(火) 09:58:12
複数のテーブルを参照してひとつのデータを作るような場合は、
読み込みでもトランザクションきらないとまずいんじゃないの？
0730デフォルトの名無しさん2006/03/28(火) 10:11:35
>>729
> 複数のテーブルを参照してひとつのデータを作るような場合は、
JOINではなくて、複数のSELECT発行って事？
0731デフォルトの名無しさん2006/03/28(火) 11:05:09
>>730
ISOLATION_LEVELのデフォルトって普通はREAD_COMMITTEDじゃないの？
複数のSELECTまで考えるとISOLATION_LEVELをREPEATABLE_READに変更しないと駄目じゃない？
0732デフォルトの名無しさん2006/03/28(火) 11:33:17
>>731
InnoDBのデフォルトはREPEATABLE_READみたいだなあ
07337302006/03/28(火) 11:45:37
>>731
>>732
DBベンダによってデフォルトが異なる。んで、大抵はREPEATABLE_READ(らしい)。

結論としては、複数のSELECTを発行するサービスのメソッドは
トランザクション制御しなきゃならんって事か。
07347312006/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>
0735733(=730)2006/03/28(火) 12:24:32
>>734
いささか古いが、
http://www.tomlauren.com/weblog/archives/000019.html
によると、OracleのデフォルトはREAD_COMMITTEDみたいだ。
でも、REPEATABLE_READがNotSupportって事になると、
SERIALIZABLEしかないな。

最新の公式資料キボン。
07367312006/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も無効にしている場合、
明示的にトランザクションを開始する必要があるのか？

という意味なのかな？
0737デフォルトの名無しさん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したくないんですが…
0738デフォルトの名無しさん2006/03/28(火) 20:03:23
好きにしろとしか……
個人的には、更新作業の頻度次第で決める
0739デフォルトの名無しさん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の目玉って何なのさ？（恥）
0740デフォルトの名無しさん2006/03/29(水) 16:35:27
>>738
んじゃ、Action2つにする。

とりあえず、HibernateでOpenSessionInViewしておけばAction2つでも
1トランザクションになるよね？
0741デフォルトの名無しさん2006/03/31(金) 23:11:17
>>740
トランザクションとHibernateのセッションの区別はついてますか？
0742デフォルトの名無しさん2006/03/32(土) 00:26:43
これ、掻い摘んでいうと何？
0743デフォルトの名無しさん2006/03/32(土) 01:38:39
軽量コンテナ
0744デフォルトの名無しさん2006/03/32(土) 05:59:35
>>742
「Java2EEなんかクソくらえ」
0745デフォルトの名無しさん2006/03/32(土) 06:03:37
今日は32日だ。うそをついていい日ではない。
0746デフォルトの名無しさん2006/03/32(土) 10:39:20
http://www.2ch.net/
＊エイプリルフール中止のお知らせ＊
本年度、ITバブル崩壊の余波、またライブドア事件の混迷、楽天ゴールデンイーグルスぶっちぎり最下位など、
悪条件の重なりによる株価低迷が２ちゃんねる運営費にも多大なる影響を与え、
火の車である今の財務状況を鑑みるに、エイプリルフールの全面中止もやむなしという判断にあいなりました。
ご期待されていた皆様には大変申し訳ありませんが、どうぞよろしくご理解いただければ幸いです。
また、妄言民族と呼ばれ、近隣アジア諸国に多大なる苦痛を与えている日本国民としてこれを良い機会と考え、
例えエイプリルフールだとしても嘘を無くし、世界平和に貢献できる公明正大な言論の場を標榜すべく襟を正しつつ、
２ちゃんねるはエイプリルフールの根絶に今後とも邁進していく所存でございます。
07477242006/04/02(日) 12:30:05
>読み取り一貫性を保証しなくて良い参照のみのトランザクションでAOPで管理せず、
>AutoCommitも無効にしている場合、明示的にトランザクションを開始する必要があるのか？
そうじゃ。RDBにもよるが、読み取り一貫性を実現するために、大体がテンポラリ領域に
データをコピーしている（OracleとSQL Serverは少なくともそう）。
この事から、一覧など頻繁に閲覧されてデータ量が多い場合、直ぐエラーになっちまう。
（同時アクセスが多いと、Tempがクリアされる前に次が来ちゃうからじゃ）
このエラーを受けてDB屋にTemp領域増やせっていうのはナンセンス。
もちろん、ビジネスロジック上大きなTempが必要な場合もあるからそれは、
ちゃんと見積もりをDB屋に伝えればいい。大きくするのに否定的な訳じゃなく
PGの手抜きに対して文句を言ってるんじゃ。

また、上記の事だけじゃないが、上記だけからでも結構コスト（負荷）
が掛かることは言うまでもないよな。
0748デフォルトの名無しさん2006/04/02(日) 13:10:03
>>747
> そうじゃ。RDBにもよるが、読み取り一貫性を実現するために、大体がテンポラリ領域に
> データをコピーしている（OracleとSQL Serverは少なくともそう）。

オラクルは違うだろ。
データがコピーされるのは読み取り時じゃなくて更新時。
コピー先はテンポラリじゃなくてUNDO表領域。

> この事から、一覧など頻繁に閲覧されてデータ量が多い場合、直ぐエラーになっちまう。

頻繁に閲覧されてもそれだけじゃエラーにならない。
頻繁に更新されている時にのんびり読んでるとORA-01555
本当に理解して書いてるか？
0749デフォルトの名無しさん2006/04/02(日) 15:04:58
> > この事から、一覧など頻繁に閲覧されてデータ量が多い場合、直ぐエラーになっちまう。
>
> 頻繁に閲覧されてもそれだけじゃエラーにならない。
> 頻繁に更新されている時にのんびり読んでるとORA-01555
> 本当に理解して書いてるか？

激しく同意。
付け加えるなら、Oracleではトランザクションの有無にかかわらず
文レベルの一貫性は常に保証しようとするから、
> 頻繁に更新されている時にのんびり読んでるとORA-01555
という状況はトランザクションの有無にかかわらず起こりうる。

だから、>747の主張は少なくともOracleには当てはまらない。
07507402006/04/02(日) 18:58:45
>>741
スマソ＆サンクス
考えてみれば、サービス層でAOPトランザクション管理していると、
複数Actionが複数サービス呼び出す時点で複数トランザクションになる…
んでOpenSesseionInViewしてもHibernateのSessionが1つに保たれるだけですな。

結論すると、2Actionだと2トランザクションでいくしかないのか。
07517312006/04/03(月) 14:34:04
あんまりSpringと関係が無くなって来たような気が...

>>747
>>748
>>749
読み取り一貫性に関しての詳細は置いておいて元の話だとOracleでは
以下になるんじゃないかな？

必要な読み取り一貫性が文をまたがるのであれば読み取り専用の
トランザクションを明示的に開始する必要がある。

必要な読み取り一貫性が文レベルでよいのであれば明示的にトランザクションを
開始しなくても良い(コネクションを生成した際のトランザクションがずっと使われている)
但し、更新処理の前にはCommitを発行して明示的にトランザクションを開始する必要がある

どちらにしてもOracleで更新やロックを伴わないトランザクションでCommitを行っても
無視される(v$sesstatのuser_commitは増えない)のでパフォーマンスには大した影響を与えない

結局のところ空コミット(参照のみトランザクションでのコミット)のコストの話なのかな？
07527402006/04/07(金) 20:14:03
今さらだが、ようやくStruts+Spring+Hibernate
(DelegatingActionProxy、
StandardXAPoolDataSource、
JOTM、
OpenSessionInViewFilter、
JtaTransactionManager)
のアプリが作れたよ…

さて、次はSeasarも試してみるか…
0753デフォルトの名無しさん2006/04/07(金) 23:51:41
Hibernateって使える？
0754デフォルトの名無しさん2006/04/08(土) 06:37:50
Java標準になったくらい使える。
0755デフォルトの名無しさん2006/04/08(土) 13:40:24
DB設計がしっかりしているならHibernate
DB設計が腐っているならiBATIS
どっちも便利であるのは間違いない。
適材適所で。
0756デフォルトの名無しさん2006/04/27(木) 06:56:47
spring 使いたい。しかしEJBコンテナを捨てるには問題が。
リモート呼び出しやORM（hibernateで）は置き換えることが
できたけど、EJBのMessage Driven Beanを代替するものが
見つからない。MDB便利すぎる。
0757デフォルトの名無しさん2006/04/28(金) 01:17:20
Struts+Springで
SpringのViewクラスを使用したい場合は
どうすれば良い？
0758デフォルトの名無しさん2006/04/28(金) 21:03:44
それってStruts使う意味あんの?
0759デフォルトの名無しさん2006/04/29(土) 20:34:44
>>757
既存システムとしてStrutsの部品があって
ExcelとかPDFを出力したいので
SpringのViewを使用する
0760デフォルトの名無しさん2006/04/29(土) 20:36:33
つ POI
0761デフォルトの名無しさん2006/05/08(月) 16:21:07
Struts(SpringのStrutsインテグレーション機能)とSpringMVCって同時に動作できないの？
web.xmlとXXX-servlet.xmlを調整すれば、実現できそうだけど？
0762デフォルトの名無しさん2006/05/09(火) 09:52:00
1.2.8記念

って何なのこれ？
0763デフォルトの名無しさん2006/05/10(水) 18:31:22
1.2.8 についてか、Spring についてか。＞何なの
0764デフォルトの名無しさん2006/05/11(木) 00:10:50
クラス属性に対応するbean定義の<property name>の値って、何でもいいんだな。
setterの名前さえ整合性が取れていれば。
0765デフォルトの名無しさん2006/05/19(金) 09:53:31
貼っとく

Rodが語った2.0@JavaOne

https://www28.cplan.com/cb_export/PS_TS-3744_277744_124-1_FIN_v2.pdf

user:contentbuilder
pass:doc789
0766デフォルトの名無しさん2006/05/19(金) 14:31:03
>765
thx.

Message-Driven POJO なんて構想もあったのか。初めて知った。

Extensible XML Confinguration は
俺様設定が乱立しそうでちと怖いな。
0767デフォルトの名無しさん2006/05/19(金) 14:32:45
>>761
そりゃできるだろ。
0768デフォルトの名無しさん2006/05/19(金) 16:50:26
では757は解決だな
0769デフォルトの名無しさん2006/05/20(土) 00:21:20
ソースコード上でAppicationContextを利用してBeanを取得するしかない
場合、どうしてます？
いい方法を考えているうちにgetBean("BeanId")のコードがいっぱいできた
まんまプロジェクト終盤にきてしまった。。。
0770デフォルトの名無しさん2006/05/20(土) 00:56:56
そんなに気にしなくていいと思うけど、
getBeanId()のメソッドを用意して静的にアクセスできるようにはしてる。
0771デフォルトの名無しさん2006/05/20(土) 00:59:34
もちろんID取得もSpringで管理するんだよな?
0772デフォルトの名無しさん2006/05/20(土) 01:01:22
そもそも、自分でgetBeanしなくていいように作ります。
StrutsならDelegatingActionProxy使えばいいし
TapestryもSpringと連携させてコンポーネントにInjectしてもらえるし。
0773デフォルトの名無しさん2006/05/20(土) 06:12:45
それができない場合はルックアップするしかない。
どこからでもルックアップできてしまうので収集がつかなくなるおそれはあるけど、
>>770 のように bean の種類ごとにルックアップするメソッドを用意しておけば
いく分見通しもよくなると思われ。
0774デフォルトの名無しさん2006/05/20(土) 08:56:55
それただのサービスロケータになってる
別にいいけど
0775デフォルトの名無しさん2006/05/20(土) 12:58:25
サービスロケータだと何がダメなの?
0776デフォルトの名無しさん2006/05/20(土) 13:05:37
DI自体がサービスロケータ
0777デフォルトの名無しさん2006/05/20(土) 15:56:24
>>775
サービスロケータに依存してしまうからですよ。
0778デフォルトの名無しさん2006/05/20(土) 15:59:55
ただ、サービスロケータはコンパイルエラーでミスを検地できるので
単純にどっちが上とかはいえない

ってDIってネーミングつけた人いってなかったっけ？
07797752006/05/20(土) 16:13:32
>>777
なるほどー。ありがとうございます。
となるとそれくらいの依存は気にならないなー。
元レスは注入できない場合の話だし
07807692006/05/20(土) 16:55:15
かといって他の解決方法もないのですよね。たぶん。
ドメインモデルとは相性が悪いのでしょうか。やはり。
いまさら設計をトランザクションスクリプトにできないし。。。
まっ宣言的トランザクションだけでもかなり有効であることには
変わりないわけだし。
0781デフォルトの名無しさん2006/05/20(土) 22:52:38
＞ソースコード上でAppicationContextを利用してBeanを取得するしかない
場合

ってどういう場合なんだろう？
素朴な疑問。
■ このスレッドは過去ログ倉庫に格納されています