04/10/06 05:40:36
>>199
それが少々複雑なケースで、最初の1.xmlでhibernateで使用する
hbm.xmlをリストでもつLocalSessionFactoryBeanを定義して、
次に読まれる2.xmlで、更に他のhbm.xmlを追加したいような感じです。
で、更に2.xmlでリストに追加したいhbm.xmlの設定は1.xmlで指定した
hbm.xmlのpojoをmany-to-oneで参照しているんですよね・・・
それで2.xmlを読み込む際に1.xmlで追加していたはずのhbm.xmlファイルが
ないよみたいなエラーが出るんですけど、やっぱこれって普通に無理なんですかね？
201:デフォルトの名無しさん
04/10/06 09:15:05
>>200
普通に無理というか、普通にDIを誤解しているだけだと思われ。
Bean定義の継承ができるかどうか、という話だな。
欲しい機能だけど、できるかどうかは知らない。
いまリファレンス読んでる最中だから。
202:デフォルトの名無しさん
04/10/06 12:28:34
parent属性使えばBean定義の継承はできるようだけど、listに追加というのは難しそうだな。
parent属性は型が違ってもいいので便利。
複数のparentを持つにはどうすればいいのかは不明。
203:デフォルトの名無しさん
04/10/13 22:32:02
URLﾘﾝｸ(www.ozacc.com)
のSpring Framework Mail Extension使ったことある人いる？
Velocityを使ったVelocityMailMessageだけオリジナルを元にコピーする
コンストラクタがついてなくて困ってるんだけど。
Springでこれのインスタンス生成してビジネスロジッククラスにセット。
そのままVelocityJavaMailSenderに渡したら
マルチスレッドでごっちゃになってまう。
Singleton=falseにすればいいんだろうけど
その場合ビジネスロジック内にApplicationContextからの取得ロジックを書くことになって
ビジネスロジックがSpringに依存してしまう。
スキルありそうな人だからこれでも普通に使えると思うんだけどどうやればうまく使えるかな？
204:デフォルトの名無しさん
04/10/14 21:57:30
Spring＋Strutsを使うと想定した場合に
サービスクラスとして
FooService implements IFoo
を定義して、
テスト用のサービスクラスとして
FooTestService implements IFoo
のようなものを定義することになると思いますが、
テストごとにテスト用のサービスクラスを変えることって
簡単にできますか？
Cactusと組み合わせた場合とかにデプロイごとに設定ファイル
変えるようなことになってしまわないですか？
205:デフォルトの名無しさん
04/10/15 19:49:37
>>204
できる。
テストケースによって読み込むconfigファイルを変えるだけ。
206:デフォルトの名無しさん
04/10/15 21:41:40
URLﾘﾝｸ(www.amazon.co.jp)
207:デフォルトの名無しさん
04/10/16 11:48:47
じゃ漏れも貼っとくか
URLﾘﾝｸ(www.amazon.co.jp)
ってたけーよ！
208:デフォルトの名無しさん
04/10/17 02:24:42
> 207
まあ、元がイングランドで発売（ポンド->円換算)だからね。。
Professional Java Development with the Spring Framework
の方は、まあ買える値段なんだけど、、、
209:デフォルトの名無しさん
04/10/18 01:25:24
SpringTestCase
URLﾘﾝｸ(blog.ozacc.com)
本家のAbstractDependencyInjectionSpringContextTestsより使いやすそう。
（っていうかこのクラスCVSからとってこないと動かないし・・・・）
210:デフォルトの名無しさん
04/10/27 20:24:42
>>208
めっちゃ亀レスだけど、
amazon.co.jpはポンドとドルのときがあって、
ポンド換算のときはなぜか高い。
ドルになったときに購入するのがおすすめ。
211:デフォルトの名無しさん
04/10/30 00:15:25
日本語版☆⌒ 凵＼(＼･∀･) まだぁ?
212:デフォルトの名無しさん
04/11/01 12:58:29
英語版でいいから欲しいなぁ。。
213:デフォルトの名無しさん
04/11/08 14:43:34
Introduction Advice でわけわかめな状態に。
URLﾘﾝｸ(d.hatena.ne.jp)
この例で言うところの one や two って
もともとのクラス実装(study.Foo)に
ComparableIntroductionInterceptor の実装が足されたものと理解してるんですけど
実際 study.Foo の機能使うときってどうすりゃいいんでしょうか。
one, two に対して単純にキャストするだけでは例外出ちゃうし。
214:デフォルトの名無しさん
04/11/09 02:05:52
(スレ違いだと思うけど、他に書くとこないんで)
PicoConatiner 1.1出ました。
URLﾘﾝｸ(www.picocontainer.org)
215:デフォルトの名無しさん
04/11/09 09:52:08
>>214
Dependncy Injectionを語るスレ
ｽﾚﾘﾝｸ(tech板)
216:デフォルトの名無しさん
04/11/17 00:06:40
XML がソースそのものだと言ったが、もうひとつ。
DI 廚 = マップ廚
分かるか？実行時解決ﾏﾝｾｰ！？
どっかでソースコード自動生成はもはや時代遅れで実行時バイトコード
生成ﾏﾝｾｰとかいう香具師もいたな。何が犠牲になってるかも分からずに
実行時なんたらって言いたいだけちゃうんかと。
なんなら俺が DI + II（Implementation Injection）コンテナでも作ろうか。
コードはもはやインタフェースのみで意識するのは界面仕様のみ。
実装コードは不要。依存性と実装はおまいらの大好きな XML に。
実装の取り替えはもちろん、いつでも修正可能だ。理想的だろ？
217:デフォルトの名無しさん
04/11/17 01:29:51
>>216
必死ですね。だんだんかわいそうになってきた。
何が犠牲になってるの？
マップ厨のときはORM無条件に不要といってたから厨だったんだけど、java.util.Mapでマッピングすること自体は、特に問題ないと思われる。
というか、無条件にDIダメといってる文脈がマップ厨の人と同一人物くさい。
> なんなら俺が DI + II（Implementation Injection）コンテナでも作ろうか。
別に、DIのしくみだけで十分同じことが実装可能なので必要ないけど、面白そうだから、作ってくれ。
218:デフォルトの名無しさん
04/11/17 01:33:02
DIスレでやれ。
219:217
04/11/17 01:37:04
気づかなかったんだよorz
220:デフォルトの名無しさん
04/11/19 09:07:42
ＤＩはある意味ではハシカみたいなもんじゃないかと思います。
思い起こせば、Javaを覚えたてのころは継承を乱用し、
GoF本を読めば(作ってるシステムにとって)意味のないクラスを量産し、
作ってる本人はご満悦ですが、保守する人とかどうしてるんだろう、
と思う今日このごろなコードもかつては作ってしまった気もします。
ハシカやオタフクカゼの困ったところは、「一度かかっておかない」と抗体ができないところ。
新しい設計技法、言語、ツールを知ると使いたくなるというのは
技術者の真っ当な感情だと思いますが、下手に使うとまわりが被害をこうむりますかも。
あと、伝染性がある上に発病期間までに時間があったりすることも。
ちゃんとテストして(使ってみて)、これは行けると踏んでから、
まずはリスクの少ない部分から適用していきましょうと(予防接種)。
生産性と品質に対して何の寄与もしないどころか、
足を引っ張るだけのフレームワークにハメられた僕は
別な何かが見える様になったと思います。
221:デフォルトの名無しさん
04/11/19 09:25:06
ま、コピペもある意味ではハシカみたいなもんじゃないかと思うわけだな。
新しい技術に拒絶感を持つのはなにみたいなもんだろうか
222:デフォルトの名無しさん
04/11/19 10:16:40
待て待て。
ここはネタスレのウォッチスレではないはずだ。
223:デフォルトの名無しさん
04/11/19 13:49:20
ひっそりとヲチするのもいいかもね。
224:デフォルトの名無しさん
04/11/24 13:35:30
DIスレからコピペ。
585 名前：デフォルトの名無しさん 本日のレス 投稿日：04/11/24 13:04:21
燃料投下。
URLﾘﾝｸ(d.hatena.ne.jp)
225:デフォルトの名無しさん
04/11/24 19:19:32
>>224
ま、そんなもんじゃない？
定義ファイルの分割がよくわからんけど。
要するに、Springじゃひがさんのやりたいことはできない、という程度かと。
226:デフォルトの名無しさん
04/11/24 23:45:25
斜に構えるSpring Frameworkユーザーであった。
227:デフォルトの名無しさん
04/11/24 23:50:23
ネタスレに巻き込まれたくないからな。
228:デフォルトの名無しさん
04/11/25 01:06:39
Java World 1月号に特集出てるね。
229:デフォルトの名無しさん
04/11/25 03:43:35
>> 228
出てた。
約20ページの特集で、Spring+Hibernate、Spring+Strutsについての解説。
割りと初歩的な部分だけど、丁寧に解説されている印象。
230:デフォルトの名無しさん
04/11/25 07:18:10
OGNLは諸刃の剣ということにしておこう。負け惜しみ的に。
たしかにオートバインディングは、名前でのオートバインディングしか使えないね。型によるのは怖い。
定義ファイルの分割については非常に疑問だね。インクルードができない、ということかな。名前空間のこと？
定義ファイルの肥大化に関しては、大規模プロジェクトで大規模に現れるような、シングルトンなクラスばっかりだと、XDoclet使えばいいということにもなるので、実質問題にはならないかと。
ただ、そんときは定義の継承を上手に使う必要があると思う。
逆にいえば、定義の継承ができないSeasar2では、XDocletを使ってクラスにBean定義を埋め込むのと面倒なことが起こるかも。
231:デフォルトの名無しさん
04/11/25 08:47:40
Springｎ 1.1.1のリリースノートに
"import" element for XML bean definitions
ってのがあるんだけど、これがインクルード機能じゃないのかな。詳細をみても
よく分からんかったのだけど。
両方ともまだ使ってなくて、Seasar2は日本語資料が多いし、Springはデファクトになりそうな勢いが
あるということで、最近ずっと資料をよんで検討してました。まだ使ってない人間の感覚からすると、
Springのほうが面倒っぽいですね。直感的でないというか。
なんか微妙に変な感じがするなーと思ってたら、この日記を読んでなるほどと思った。
URLﾘﾝｸ(d.hatena.ne.jp)
ここに書いているとおり、Springの資料を読んでるとなんでもかんでもBeanなんだな、
と感じる。Spring的純粋主義なんでしょうか。一方Seasar2は「作ってるクラス定義自体には
Seasar2フレームワークへの依存関係を絶対もたせない」という方向での純粋主義みたいな
ところがありますね。後者の方が好みかなあ。
232:デフォルトの名無しさん
04/11/25 09:05:32
クラスにはフレームワーク依存のメンバは現れないんだけど、最終的なアプリケーションとしてフレームワークに依存するから、好みの問題なんだよね。
結局フレームワークに依存するんだから、どこにその依存が現れるかは、どうでもいいと思う。
信じる道を行けばいいだけ。
ポリシーが一定してないのは困るけど、両者ともそういうことはないし。
233:デフォルトの名無しさん
04/11/25 23:32:01
漏れも231的な感覚なんだけど、
クラスがフレームワーク依存しなければ、
「再利用しやすいかも」って思うんだよね。
実際に使い込んだわけじゃないから、あくまで幻想だけど。
234:デフォルトの名無しさん
04/11/27 04:00:46
検索するとSpring1.1からOGNL対応っていうのをみかけるんだけど、結局どうなったんだろう？
235:デフォルトの名無しさん
04/11/27 04:28:58
２月ごろ優先度がminorからmajorにあがって、4月ごろ1.1の予定になってたのが、5月にminorにおちつつ1.2予定になって
そして11/16に1.3予定になった形跡がある。
まだまだ先の話か。
236:デフォルトの名無しさん
04/12/06 00:38:33
SpringにしてもSeaser2にしてもJava自体が強い型付け言語なのにも関わらずリフレクションを多様するDIContainerってどおなのよ？
本当に使いやすいのかなあ？
237:デフォルトの名無しさん
04/12/06 00:44:57
強い型付けだからこそ、DIコンテナが生きるんだよ。
ビーン定義ファイルは型による事前検証が可能だしね。
238:デフォルトの名無しさん
04/12/06 00:59:40
コンパイル時に検証できないうえにファクトリでダウンキャストしないといけないのに？
239:デフォルトの名無しさん
04/12/06 03:47:22
>>238
> コンパイル時に検証できないうえにファクトリでダウンキャストしないといけないのに？
周辺ライブラリを使えばダウンキャストは不要。
例えばStrutsのActionに最初から依存Serviceへの
参照がセットされてるとか。
というかむしろダウンキャストしない使い方が標準。
240:デフォルトの名無しさん
04/12/06 11:23:48
>>238
Javaソースを検証するコンパイル時に、Bean定義を検証する必然性はあるの？
別でいいじゃん。
241:デフォルトの名無しさん
04/12/07 00:01:00
ま、大きくなったらわかるさ。
242:デフォルトの名無しさん
04/12/07 01:01:32
>>241
今知りたい。
コンパイル時に検証したい理由。
たとえばantで別の検証タスクを作ってもいいし、簡易なら、単にビーン定義を読み込むだけの検証用プログラムを作ればいいと思うんだが。
243:デフォルトの名無しさん
04/12/09 00:31:01
>>239
なるほど、やっぱダウンキャストは勝手にやってくれって感じだよな
>>242
Javaしか知らん奴には弱い型付けとか言ってもわからんのだろう
藻前は却下
244:デフォルトの名無しさん
04/12/09 01:12:30
>>243
弱い型付けってなんですか？
245:デフォルトの名無しさん
04/12/09 01:38:48
>>244
URLﾘﾝｸ(www.google.com)
ほれ
246:デフォルトの名無しさん
04/12/09 01:47:22
>>245
「弱い型付け」で検索したら、Server Errorでますた(T-T)
247:デフォルトの名無しさん
04/12/09 01:53:30
>>246
釣りはいいからさっさと調べろボケ
248:デフォルトの名無しさん
04/12/09 01:53:33
型の指定が「無い」ことを「弱い型付け」と呼んでいいんですか？
249:デフォルトの名無しさん
04/12/09 01:54:12
>>247
ほんとに出たんだって。
GoogleのServer Error
250:デフォルトの名無しさん
04/12/09 01:58:01
ところで、Bean定義がコンパイル時に型解決できないのを、コンパイルとは別にBean定義の検証してもいいんじゃないの？っていう疑問は解決できませんでしたよ。
251:デフォルトの名無しさん
04/12/09 23:51:24
設定ファイルの不備が実行時でないと検出できないってのは効率が悪すぎる。
で、自分はこんな感じでAntを使用してチェックしてるんだが、どうよ？
1.spring-beans.dtdを利用して、DTDレベルの妥当性のチェックをする。
2./beans/bean/@classの値がクラス名として正しいのか検証する。
1.はAntのXMLValidateタスクを使用。
2.はXPath + java.net.URLClassLoaderを使用しAnt拡張タスクを自作して使用。
まぁ、DTDレベルの妥当性チェック + クラス名チェックなんで完全とまではいかないが、
実行時前にチェック出来るんで、だいぶ楽になった気がするな。
252:デフォルトの名無しさん
04/12/10 00:53:16
>>251
だから、とりあえず設定ファイル読み込むだけのプログラム作って、それでエラー検出してもらうんじゃだめなの？と。
なんならそれをAntのタスクにしてもいいし。
253:デフォルトの名無しさん
04/12/10 01:18:09
java房は世の中javaしかないと表ますね
254:デフォルトの名無しさん
04/12/10 02:31:46
別に普通にJUnitでテストしたらいいじゃん。
255:デフォルトの名無しさん
04/12/10 02:44:05
テスト至上主義は現実を考えるとどうかと思うよ。
毎回すべてをテストすることは難しいし。
256:デフォルトの名無しさん
04/12/10 23:44:01
>>255
ANTやMavenでプロジェクトに組み込んでしまえば
自動でやってくれるじゃん。
257:デフォルトの名無しさん
04/12/11 03:45:44
>>256
テストを自分で作らないかぎりは、自動でテストしてくれない。
258:デフォルトの名無しさん
04/12/11 10:02:07
そこでJTestですよ。
259:デフォルトの名無しさん
04/12/11 11:05:36
>>251
SpringIDEが、それぐらい、やってくれるんじゃないの。
260:デフォルトの名無しさん
04/12/11 11:39:36
コンパイラは誰でも必ず起動するってことだろ。テストはやらない人もいる。
というかやらない馬鹿もいるわけで。でも馬鹿でもコンパイルだけはする。
261:デフォルトの名無しさん
04/12/11 12:48:25
>>257
つまらんテスト仕様書を書く（しかもExcelで！）
よりテストコードを書くほうが楽しいと思わないか？
細かい修正のリリースの度に
テスト仕様書に則ってテストするのは
本来ならあたりまえの作業のはずなんだが
殆ど真面目に実行されていない。
テスト仕様書なんか納品前にでっち上げられる始末。
（銀行の勘定系とかはちゃんとやるけど）
それがmake（の相当品）に組み込まれているなら
便利だと思わないか？
262:デフォルトの名無しさん
04/12/11 14:05:56
>>261
> 細かい修正のリリースの度に
> テスト仕様書に則ってテストするのは
> 本来ならあたりまえの作業のはずなんだが
> 殆ど真面目に実行されていない。
細かいメソッド作成の度に
テストファーストに則ってテストを作成するのは
本来ならあたりまえの作業のはずなんだが
殆ど真面目に実行されていない。
というのと違いはあるのかな？
263:デフォルトの名無しさん
04/12/12 00:32:30
>>262
目視テストでは修正リリース時に毎回再実施のコストがかかる。
「真面目に実行」されていないのはリソース不足が理由。
自動テストでは上記の再実施のコストは激減する。
「真面目に実行」されないケースは開発者のスキル不足と
腐敗アーキテクチャが理由。
以上。
264:デフォルトの名無しさん
04/12/12 02:57:00
>>263
> 自動テストでは上記の再実施のコストは激減する。
再実施のコストが激減しても、テスト初回のコストは激増するわけだろ。
> 「真面目に実行」されないケースは開発者のスキル不足と
> 腐敗アーキテクチャが理由。
これが通常のテストに当てはまらない理由と
> 目視テストでは修正リリース時に毎回再実施のコストがかかる。
> 「真面目に実行」されていないのはリソース不足が理由。
これがテストファーストに当てはまらない理由を教えてもらいたい。
265:デフォルトの名無しさん
04/12/12 17:58:07
>>255
俺もそう思わんでも無いけど、そう思うのは自分の技能不足だということに気づいた今日この頃
266:デフォルトの名無しさん
04/12/12 17:59:42
JUnit in Action 嫁。
267:デフォルトの名無しさん
04/12/12 19:12:50
>>265
チーム全員、すべてのプロジェクトで徹底するのが難しいんだよ。
268:デフォルトの名無しさん
04/12/12 21:09:02
>>265
つまり、ユニットテストというのは、個人の能力に依存することになるんだよね。
で、ユニットテストに依存するということは、チームの個々人の能力に依存することになる。
安定して開発するための一般的な手法としては、テストファーストはお勧めできない。
269:デフォルトの名無しさん
04/12/13 00:10:47
そういうことを想定してたからこそ、ペアプロって発想が出てきたんだと予想してみる。
270:デフォルトの名無しさん
04/12/13 01:28:06
ペアプロって人月が倍になるように見えるんだけど間違ってる？
典型的な請負DQNシステムの場合、そういう余剰な工数ってどこから
捻出できるの？
271:デフォルトの名無しさん
04/12/13 01:49:37
XPの本で読んだだけだけど、研究によると、ペアプロをするとコーディング時間は
確かにのびるが、２倍の200%ではなくて、115%くらいになるそうだ。でその15%分、
品質が15%あがるらしい。どうやって計ったのかは知らない。
272:デフォルトの名無しさん
04/12/13 11:56:23
そうじゃなくて2人分の金が必要って話になるんじゃないかってことだろ。人月だから。
273:デフォルトの名無しさん
04/12/13 13:03:39
二人分の金が必要なのは当たり前だ。二人いるならね。どんな手法だろうが
二人いるなら二人分の金がかかる（奴隷でない限り）。
で二人で一緒に仕事すると、一人で別々にやる場合と比べて生産性が半分になりそうな
ので、費用も倍になりそうだという話じゃないか？
実際には別々にやった時と同じくらいの生産性を（つまり二人で二人分）を出す（らしい）と
いうことなんだが。
まあほんとかどうかは知らない。
274:デフォルトの名無しさん
04/12/13 13:20:16
問題は、プログラムには単純作業的なものが多くて、ペアプログラミングの効率のよさが得られるところが少ないってことじゃないのかな？
データベースからとってきた値をJSPに流し込むのって、ただの作業だし。
275:デフォルトの名無しさん
04/12/13 20:04:55
>>273
> で二人で一緒に仕事すると、一人で別々にやる場合と比べて生産性が半分になりそうな
> ので、費用も倍になりそうだという話じゃないか？
そうそう、そういいたかったんだ。ありがとう。
276:デフォルトの名無しさん
04/12/13 21:49:00
>>268
それはユニットテストだのＴＤＤだの以前に、
きちんとバグのないソフト作るとか、きちんとテストできるとか、きちんとデバッグできるだとか、
ある程度個人の能力に依存するのは当然だと思うぞ。
１００人の人間がいて、１００人とも皆が同じ答えを出すっていうのは人間じゃないぞ。
277:デフォルトの名無しさん
04/12/13 22:11:52
>>276
コンパイラでチェックできるのなら、100人の人間がいて、コンパイルに通っていれば、100人とも皆が書いたコードがチェックに通っている。
278:デフォルトの名無しさん
04/12/13 23:48:13
なんだかいつの間にかテストの有効性の話になってるが、もともとは、
コンパイラで型チェックさせるなんて意味あんのか、別の方法でチェックしても
いいじゃん、という話だったんじゃないか？
おれは>>260と同じ理由で価値があると思ってるけど。
279:デフォルトの名無しさん
04/12/25 14:58:37
今月のJavaWorldの記事でGeronimoの記事を読んでたんだけど
コア部分はDIコンテナなんだね。MBeanで定義した各サービスをDIコンテナを使って依存性注入したり
独自のサービスをMBean化して公開出来るようになるらしい
記事には書いてなかったけど、そのDIコンテナってSpringを使ってるそうだし
今後は、APサーバーがDIコンテナを核として構築されるのが主流になっていくのだろうか
280:デフォルトの名無しさん
04/12/26 00:04:13
俺様フレームワークを作るときにいつも困ってるのが「Factoryの提供の仕方」だったからな。
GBeanという形でFactoryを隠すことで、コンポーネントの利用者はサービスのみを享受できる。
サービスを提供したいのに、サービスを利用する準備から伝えないといけないのは、提供側も利用側もめんどくさい。
DIコンテナがあれば、提供者が好き勝手にFactoryを準備できる。
来年からやるプロジェクトではぜったいDIコンテナ使う。
S2よりはSpringだな。
281:デフォルトの名無しさん
04/12/26 00:18:57
>>279
内部がSpringって、あのAOPが自分のインスタンスメソッド呼び出しには適用されない問題は
大丈夫なのかな。（クラスＡのset.*にaspectを適用したら、最初に呼び出したsetHogeには
Aspectが適用されるけど、setHogeからthis.setHageを呼んだらAspectが適用されない問題）
実装の仕方みて「あーなるほどこりゃ自分で自分のメソッド呼んだら適用されないなー」と
思いはしたが、AOP的には困ったもんなのでまじなんとかしてほしい。
282:デフォルトの名無しさん
04/12/26 00:32:48
一番使われるトランザクションとかログてきには、あまり困らないのでなんとかしないんじゃない？
するかな？
283:デフォルトの名無しさん
04/12/26 00:40:09
おい、「setなんたらというのが呼ばれたら全部ログ吐け」ってのが、ちゃんと
動かない（ことがある）ってことわかってるか？
284:デフォルトの名無しさん
04/12/26 00:44:11
>>281
GeronimoはAOPは標準では提供しないらしいよ。コアに持っているのはあくまでDIコンテナで
AOPについては既存のものがGBean対応してくれるのを期待してるらしいね
AOPをコアに置いているJBossとは考え方が違うのかな？
285:デフォルトの名無しさん
04/12/26 01:32:44
>>283
でも、ログが重要なのって、オブジェクトの入り口のメソッドだから、急いで対応するほど問題になってないんじゃない？
286:デフォルトの名無しさん
05/01/06 01:32:25
proxyタイプのAOPじゃそれが限界だろ。いやならAspectJだ
287:デフォルトの名無しさん
05/02/15 01:33:40
Springしかり、最近のORMしかり、マッピングファイルうざい。
そんなさ、余計にバグ増やしてるようなもんじゃん。
補完も出来ないし面倒なだけだ。
288:デフォルトの名無しさん
05/02/15 01:57:26
まあマッピングファイルがうざいということには賛成だな。
DI Containerは便利だし使ってるけど、たしかにマッピングファイルを書くのがかなりうざい。
ある程度自動化できるとは言ってもなあ。
289:デフォルトの名無しさん
05/02/15 02:17:31
今のところだいたいXDocletで書いたもので用が足るから、あまり困ってない。
Strutsタグ+α程度で。
290:デフォルトの名無しさん
05/02/15 02:38:31
そもそも、何でもマッピングファイルにすれば保守性、拡張性に
優れるって発想は誰からのものなんだ？
増えすぎると逆効果だぞ・・・
ＪＡＶＡの世界って品質よりも名前だよな。著名な製作者が
提唱すると、何でもスタンダードになっちゃう。
291:MARU-CHAN
05/02/15 08:12:56
ところでSpringとEclipseを使った場合ってMVCはEclipse方式でEJB（セッション管理など）の部分をSpringでやるっていうイメージなのでしょうか？
292:MARU-CHAN
05/02/15 08:14:04
ごめんなさい、２９１はEclipseじゃなくてStrutsの間違い。
293:MARU-CHAN
05/02/15 08:25:38
２９１は間違いダラケでした・・・書き直すと
ところでSpringとStrutsを使った場合ってMVCはStruts方式でEJB（トランザクション管理など）の部分をSpringでやるっていうイメージなのでしょうか？
です。すんません。
294:デフォルトの名無しさん
05/02/15 12:12:02
>>293
MVCというのがどういうことか正確にわからんが、StrutsのActionとActionFormはそのまま使って、ActionServletをSpringに置き換えることになる。
HTMLフォーム→JavaオブジェクトまではStrutsに任せて、あとはSpringでって感じだな。
295:デフォルトの名無しさん
05/02/28 10:26:54
アマゾヌで Spring In Action 発注したが 3/11 配送予定。
予約じゃなかったから仕方ないところか。
>293
Struts はコントロールとビューだけに専念して
ロジックを POJO で記述して Spring に管理させる感じかと。
Spring 独自の MVC フレームワークもあるらしいけど
そっちってどんな感じなんですかね？
Struts の servlet API べったりな感じが
どーも Spring の POJO マンセー思想に合わない気がする。。
296:デフォルトの名無しさん
05/03/06 14:23:38
POJOなんて、スローガンに過ぎなかった、と。
297:デフォルトの名無しさん
05/03/10 12:25:54
Spring in Action がまだ届かない
298:デフォルトの名無しさん
05/03/10 21:07:16
SpringってWebじゃない普通のアプリケーションでも使えるの？
299:デフォルトの名無しさん
05/03/10 23:29:18
使おうと思えばつかえるけど、そういうのにはPicoContainerのほうが向いていると思われ。
私はPicoContainerの、何にでも使えるところが気に入ってます。
300:デフォルトの名無しさん
05/03/16 19:21:26
Seaser>>>>>>>>>>>>>>>>>>>>>Spring
301:デフォルトの名無しさん
05/03/17 10:43:16
Seaserなんて存在しないから、ということがいいたいのか。
302:デフォルトの名無しさん
05/04/08 15:20:13
6月にやるJavaWorldのイベントにロッド・ジョンソンが来るみたい。
URLﾘﾝｸ(www.javaworld.jp)
生ロッド見に行こうかな。
303:デフォルトの名無しさん
05/04/09 00:26:06
DIのよさが分からん。。。
インスタンスを設定ファイルで与えられるって事がそんなにいいの？
アンチDIというより「DIってすげんだぜー」って言えるように
実は洗脳して欲しかったりする。
DIが出てきてどんな所が楽チンになったのよ？
304:デフォルトの名無しさん
05/04/09 01:12:55
コンポーネント指向が強制される所？
インターフェイス経由で操作するのは、前から言われてることだし。
305:デフォルトの名無しさん
05/04/09 01:20:32
>>303
EJBを使ってみれば、以下にSpringが楽で、「ああ俺だったらEJBのこのめんどくせえ
ところ、こうするのに！」というところを見事に解決していることがわかるよ。
306:デフォルトの名無しさん
05/04/09 01:28:17
以下＝如何
307:デフォルトの名無しさん
05/04/09 09:16:59
303じゃないけど俺も同じような感じ。
EJBを使わない俺にはメリットのない話ですか？
クラスどうしの依存性が減り、シンプルになり、
ユニットテストがやりやすくなるという利点は分かるのですけど、
その代わりにXMLファイルがごちゃごちゃして手に負えなくなる。
勘違いしてる？
308:303
05/04/09 09:21:03
>コンポーネント指向が強制される所？
あるレベル以上のメンバーと組むことが出来る漏れとしては、
そんなもんｲﾗﾈ？
>インターフェイス経由で操作するのは、前から言われてることだし。
インターフェースは好きじゃないっス。デバッグやりにくいっス。
（あくまでDIのためにインターフェース作るのはね。プラグイン開発
とか機能要件として必要な場合はもちろん使う）
>EJBを使ってみれば、以下にSpringが楽で、「ああ俺だったらEJBのこのめんどくせえ
>ところ、こうするのに！」というところを見事に解決していることがわかるよ。
漏れもEJBはめんどくさいって思ってる。なのでHibernateつかってる。
AOPでトランザクションはいい感じだけど、DIのよさはまだわからっス。
309:デフォルトの名無しさん
05/04/09 09:23:51
>>307
ハゲドウ!!
310:303
05/04/09 09:25:00
309は漏れです。。。
311:デフォルトの名無しさん
05/04/09 10:29:11
>>308
インタフェース経由で作らないと、使い回しがしにくいだろ？
Spring以前の問題。
あるレベル以上のメンバーの中で、308のレベルだけ低いのか、
あるレベルというのが低いのか。
312:303
05/04/09 11:07:08
うぬー。使い回ししやすい、しにくいはインターフェースに
かかわらずクラス設計しだいじゃないの？
上にも書いたけどインターフェース自体を否定してるわけじゃないよ。
インターフェースとImplクラスが1つずつしか作らない場合
は面倒だなーって思います。
313:デフォルトの名無しさん
05/04/09 13:39:51
そうだな、インターフェースを使ったプログラミングをしようとすると、
ファクトリをつくらなくちゃいけなくなるだろ。だって、newでインスタンス
を作っちゃうと、newしている部分は具象クラスに依存してしまうから。
なんで、ファクトリ用クラスをつくって、ファクトリ経由でオブジェクト生成する。
とここまでは誰でも実装すると思うんだよ。
で、ここでファクトリを書く方法を考えてみようや。クラスごとにファクトリを
別に書くなんて馬鹿げてる。じゃあ、インスタンス生成メソッドの引数でクラス・オブジェクト
かクラス名を引数で取ることにしよう。
じゃあ生成メソッド内で、渡されたClassに対してgetInstanceすることにしようか？
これはできない。渡されるClassは、インターフェースだろうから。
じゃあif文で、渡されたClassなりClass名なりで分岐して、具体的な生成クラスを
特定しようか。これも馬鹿げてる。クラスを追加するたびにファクトリにif文を追加
して、コンパイルし直すのか？ 分かりやすい記述法で外部ファイルに記述したい
ところだ。
そういや、具象クラスを生成するときのコンストラクタに引き渡す引数はどうしよう
か。ファクトリの生成メソッドにObject[]として引き渡してもらおうか？ 生成後に
setXXXX()で全部セットしてもらおうか。どっちにしても、具象クラスのコンストラクタ
なりプロパティに依存してしまうよねえ。
さあ、どう実装しようか。外部ファイルで具象オブジェクトを特定して、具象オブジェクト
生成時に内部状態の初期設定も行うファクトリだ。
そんな話を説明しているのがロッド・ジョンソンの本「J2EEシステムデザイン」。いろんな
アイデアを具体例を使って披露していく。このアイデアを実装して公開したのが
Spring Frameworkだよ。
314:デフォルトの名無しさん
05/04/09 15:18:41
>>308
> 漏れもEJBはめんどくさいって思ってる。なのでHibernateつかってる。
> AOPでトランザクションはいい感じだけど、DIのよさはまだわからっス。
EJBめんどくさい→Hibernateつかってる
となるということは、「EJB = EntityBeanのみ」ってことなのか？
DI Containerが作られた契機となった問題点って、Stateless Session Beanを
つかったビジネスロジック層の作り方があまりにもめんどくさい、ってところだっ
たと思うんで、ロジック層をDIパターン以外の方法で効率よく解決できるんなら、
「DIいらね」ってことに出来ると思うけど、Hibernateではそこは解決できんよね。
Hibernateで永続化層はクリアしたとして、ロジック層のオブジェクト生成は
どうするわけ？ newしてるってこと？ EJBは論外として。
315:デフォルトの名無しさん
05/04/09 16:24:18
インターフェイスを使う利点が少ない状況ってのはやっぱりある罠。
上にも少し出てたけどプロジェクトメンバーの技量があまりに低い場合には
プログラム中で全てif文で分岐した方が効率がいい場合もあるかもしれない。
インターフェイスの使い方をよくわかってない人はまだ意外といる。（職場によるだろうけど）
「外部ファイルで具象ファイルを指定することにより具象ファイルを変更することが可能」というのも
それによる恩恵を受けられる環境と受けられない環境があるんじゃないだろうか。
自社システムやそれに近いぐらいに自分のところで管理しているシステムで
かつ頻繁な拡張や似たようなもの作る機会が多いなら強力だと思うけど
作って納品して終わりとか拡張がまるでなかったりしたら自分たちにとっての利点はあまりないかも。
>>311が理想だと思うけど状況次第では>>312の言うこともわかる。
俺はSpring好きだしどんどん使っていきたいと思ってるけど使ってもおいしくない状況ってのはやっぱりあるんジャマイカ。
ところでSpring in Action邦訳☆⌒ 凵＼(＼･∀･) まだぁ?
316:デフォルトの名無しさん
05/04/09 17:02:49
そう、だから、インターフェースを使う必要がないならファクトリも必要ないんで、
DIパターンの利点がほぼなくなる。
あとは、コンテナが提供するAOP機能が使いたいかどうかだけだろう。
でもインターフェースを使ったことによる利点が出てくるのって、実は開発の
後の方（変更が入った時）なんで、最初のうちに「この開発ではインターフェース
使うほどじゃないだろ」とか判断してしまうと、後半で泣きを見ることもあるから、
先行投資としてインターフェース中心でいくんじゃないかね。
317:デフォルトの名無しさん
05/04/09 17:11:58
インターフェイス主体でプログラム作るときの面倒さが減ることがDIのメリットなら、DI自体にはメリットはないみたいになるな。
318:デフォルトの名無しさん
05/04/09 17:45:35
>>317
詳しく
319:デフォルトの名無しさん
05/04/09 18:03:51
いや、DI「コンテナ」の、インターフェース生成時の実装隠蔽ファクトリとしての利点はなくな
るだろうけど、インスタンス生成時に依存性を注入して、すべてのプロパティが構成済みの
オブジェクトを作成するというDIパターン自体のメリットは残るだろう。
インターフェース主体でないからって、DIパターンなしだったら、
インスタンス生成→他の依存インスタンス生成（このインスタンスにも依存インスタンスがある）
→インスタンスのプロパティに依存インスタンスをセット
ってのを自前でやらないといけない。newして、関連オブジェクトをnewしまくって、関連
オブジェクトの全プロパティをセットして、で、最初にnewしたオブジェクトに関連オブジェクトを
セットしないといけない。
そんなめんどくさいこと、ファクトリでやってよ、と思わないか？
320:デフォルトの名無しさん
05/04/09 18:28:24
ファクトリでやるのはめんどくさいから、それぞれのオブジェクトでやってよ、と思ってはだめですか？
321:デフォルトの名無しさん
05/04/09 19:33:43
>>319
先日迷ったあげくSpring無しで書いたんだけどいちいちnewしてセットは確かに面倒だった。
これを面倒だと思うのはある程度Springに慣れてるからだと思うけど
それ以上に苦痛だったのは後で変更が発生したときの修正が面倒そうだと思いながら書いてたからだな。
でも>>319の一番のメリットは
具象クラスが変わることで具象クラスが必要とするオブジェクトが変わってもファクトリを修正せずに対応できること
（つまりは具象クラスの差し替えのしやすさ）
じゃないのかな。
それも具象クラス差し替え時に生きてくるメリットな気がする。
俺はSpringやDIコンテナ、もちろんインターフェース多用するのも否定するつもりはないんだけど
仕事場の環境次第ではSpringわからない人もまだ多いし
>>318の言うような先行投資の効果が目に見えて出ない時も多々ある。
それを考えると設定ファイル書いたり周知したりで面倒さが前面に出てくる人がいるのもわかるな、と。
後々俺が作った物を他の人が管理することになった時にその人はSpringを知っていてくれるだろうか、
俺がこれまでにしたつもりの先行投資は最終的にプラスになるのだろうか、
とちょっと悩んで書いたのが>>315なんだ。
チラシの裏って書いた方が良かったかもな。すまん（´・ω・｀）
322:303
05/04/09 20:29:45
>>314
>ロジック層のオブジェクト生成はどうするわけ？ newしてるってこと？
うん、newしてる。
>>315
そうだね、頻繁な拡張とかはないです。
>>316
>でもインターフェースを使ったことによる利点が出てくるのって、実は開発の
>後の方（変更が入った時）
うーん、開発後方でImplクラスを丸ごと挿げ替えるほどの変更は
ないなー。Implクラスの実装を修正するだけじゃすまないって事デツか？
あー、>>319 見て分かった。ビジネスロジック層の作り方がそもそも違うんだ。
漏れは、依存オブジェクトをプロパティ経由でセットしないデツ。なので、
ビジネスロジック層のオブジェクトの殆どが状態を持たないです。
ただね、このOOPらしくない所が良いのか悪いのかは漏れも迷ってる。
323:デフォルトの名無しさん
05/04/09 21:16:39
ＯＯに反するコード＝劣悪なコード
324:デフォルトの名無しさん
05/04/09 21:37:54
ステキなOOの概念がこの2年で大きく変わっている現実
325:デフォルトの名無しさん
05/04/09 22:15:37
> うーん、開発後方でImplクラスを丸ごと挿げ替えるほどの変更は
>ないなー。Implクラスの実装を修正するだけじゃすまないって事デツか？
ただのロジック変更ならソースの修正で済むけど、対象によってロジック分岐とかだと
if instanceof else if～ で分岐するのは全くエレガントじゃないから
Strategyパターンにしたほうが後々いいでしょ、って事だな。
拡張性とか関係ない部分ならいいかもしんないけど。
326:デフォルトの名無しさん
05/04/10 00:22:16
うーん、最近の流れは勉強になるなぁ。
いつまでも独学は不安なので、自分の独学部分が正しいか
検証することも踏まえて、なんか本を買おうと思うのですが、
・これは読め
・これは糞だから読んじゃだめ
などありましたら、ご紹介いただけますか?
327:デフォルトの名無しさん
05/04/10 00:27:43
>>322
＞ないなー。Implクラスの実装を修正するだけじゃすまないって事デツか？
機能追加の場合には新しい機能向けのクラス作って
条件によってどちらを使うか切り替えればわかりやすいと思う。
また、別のユーザー向けに似たようなシステム作る時には
クラスごと差し替えることができればとても楽。
＞漏れは、依存オブジェクトをプロパティ経由でセットしないデツ
引数で渡してるの？
インターフェース使わないならそれでも困らないと思うけど
インターフェースで実装の切り替えをするような場合には引
数がビジネスロジッククラスの実装に依存すると困るのよ。
ある実装ではこのオブジェクト使うけどこの実装では使わないとなると引数が統一できないから。
その点>>319のように依存オブジェクトを初期化時に設定ファイルで指定して
プロパティやコンストラクタでセットするようにすれば
呼び出し側からは実装の違いを全く意識する必要がないことになる。
328:デフォルトの名無しさん
05/04/10 01:11:57
Springを使って3ヶ月程度のプロジェクトをやってみた。
俺はPMの立場で実装はやらないが、コードレビューする程度。
結論は、SpringにするかはともかくIoCコンテナなしの開発は、もう考えられない。
最初にかならず行っていた低レイヤー部分のフレームワーク作りをしなくて済むのだから。
いつもなら、実装がぶれるのが嫌で、最初のうちに低レイヤーのフレームワークを作ってから
プログラマに渡していた。
最初にこう書くべきだというサンプルを見せてやれば、
newbieでもそこそこのものを書き上げてくれる。
Springのソースを読んでて、interfaceは多重継承できることを初めて知った。
Javaには自信を持ってたのに、自分に少しがっかりした。
329:デフォルトの名無しさん
05/04/10 02:32:31
>>326
>>313にも出てるけど、ロッド・ジョンソンの「J2EEシステムデザイン」はお勧めできる。
URLﾘﾝｸ(www.amazon.co.jp)
DI(あるいはIoC)コンテナ登場前夜に、EJBの問題点を詳細に書き表して、なおかつ
解決するための方法論を具体的なコードを交えて説明した名作だ。この本で紹介された
アイデアがそのまんまSpring Frameworkの基礎になってる事は有名。AOPの実現方法ま
でおんなじだし、Springの解説書か？と思えるほど。
まあロッド・ジョンソンがSpringの開発者なわけであたりまえなんだろうけど。
一方読む必要がないのは、「Java ブループリント」だな。人生を無駄遣いする事になる。
330:デフォルトの名無しさん
05/04/10 02:53:18
>>328
そう、それだ。
エンタープライズ向け開発だと、いろんな技術レベルの人間があつまるから、かならず
基礎アーキテクチャを技術レベルが高い人間で実装するよな。
つまり技術レベルの低い人でも、決められた実装方法に従って普通のJavaプログラムと
して作れば、あとは基礎アーキテクチャが何とかするよ、という状態を作るわけだ。
そういうものの大部分って、ロジック層のシングルトン・オブジェクトをどうやって生成するか
とか、初期化を間違わないにはどうしたらいいかとか、EJBを取得するのにJNDI参照したり
RemoteExceptionを処理し忘れたりしないようにするにはどうしたらいいか、とか、
めんどくさいことばっかりなんだよな。
Springはそういうものの大部分を吸収してくれるし、EJBの利点の一つ、宣言的トランザクション
もサポートしてる。
正直、リモート呼び出しの必要性が無ければEJBを使う意味を見いだせない。
331:デフォルトの名無しさん
05/04/10 03:25:34
思うに、Spring自体が、EJBのめんどくさいところを解消する過程で産みだされたところを
ふまえとかないと、なんで「Spring楽だー」という輩がいるのか理解できなくて、>>307のような
感想になっても仕方がないと思う。
>>307
>その代わりにXMLファイルがごちゃごちゃして手に負えなくなる。
EJBのディプロイメント・ディスクリプタというXMLファイルは、SpringのXML定義の１０倍は
ごちゃごちゃしてて手に負えないんですよ。Springの構成ファイルは分かりやすいよ。
しかも構成ファイル一つでリモート呼び出しを除くEJBの機能を実現できるんだったら、
EJBに苦しめられた輩が採用しない理由はないよ。
332:デフォルトの名無しさん
05/04/10 03:39:21
ふむ、ageとこう。
333:デフォルトの名無しさん
05/04/10 03:46:18
＿
r-､' ´ ｀ヽr-､
ｨ7 /l: ハヽﾊ ﾄヾ 駄スレを保守することは、この俺が許さん！
'|l |'´_` ´_ ｀| || 信念に基づいて行動する。
| |´ﾋ} ﾋ}｀! l| それを人は正義と言う。
__ノﾞ). 从 l, _'_. |从 今俺が行ってることは、荒らしではない。
,_'（＿ ﾉ_ヽ ヾl.＞ - ,イ;ﾘ 正義という名の粛清だぁ！
{ f:ﾃ} {'f:ﾃ}',／＼ヽ--/／ヽ
ヽ,r─‐ ､ｨ .､､ i l＞Y＜! i '､ バーニング！
/ iゝ＿ﾉ iヽ /l |l l ',
lﾝヽ/ムノじ
334:デフォルトの名無しさん
05/04/10 08:58:20
>>328
Webじゃない普通のアプリについてはどう思ってるか教えて欲しい
335:328
05/04/10 10:12:52
>>334
今回は、通常のアプリとWebアプリとどちらでもSpringを使った。
Webアプリのほうが制約があり、通常のアプリのほうがより自由というのが回答。
Springの構成は、まず通常のJavaアプリで使えるコアがある。
optionalな形でSpring WebなどのWebアプリ用サポートがある。
Springは、BeanFactoryという汎用のファクトリに識別子を渡して生成してもらうのだが、
このファクトリのインスタンスをどこかに保存しておく必要がある。
保存しない場合は、ファクトリのインスタンスを毎回newする必要が出てくる。
これは毎回設定を解釈するというコストをかけることとイコールだ。
で、通常のアプリならメインクラスのメンバにでも入れておけばよい。
これがWebアプリだと、applicationスコープのアトリビュートに放り込むことになる。
BeanFactoryのアトリビュートへの設定と取り出しを管理するクラス自体は、Spring組み込みで提供されてる。
しかしServletContextを使える場所でしかBeanFactoryを取得できないという制約が生まれる。
ちゃんとクラス設計していれば問題は生じないけど、
ちょっと工夫してあげなきゃならない場面もでてくる。
まああれだ。たぶん大丈夫だよ。
心配なら一度ファクトリ部分のソースを追って、中身を確認したらどうだろう。
変な制約はないし、シンプルで、不安は生まれないと思う。
336:334
05/04/10 13:11:02
>>335
さんきゅ
337:デフォルトの名無しさん
05/04/11 02:58:25
Spring In Actionよりも、ロッド・ジョンソンの「Expert One-on-One J2EE Development without EJB」
を邦訳してほしいな。「J2EEシステムデザイン」の続編みたいな本だ。
338:デフォルトの名無しさん
05/04/11 15:20:29
便乗質問なんですが、
>>335の
> BeanFactoryのアトリビュートへの設定と取り出しを管理するクラス自体は、Spring組み込みで提供されてる。
> しかしServletContextを使える場所でしかBeanFactoryを取得できないという制約が生まれる。
ServletContext sContext = getServlet().getServletContext();
ApplicationContext aContext =
(ApplicationContext)sContext.getAttribute("org.springframework.web.struts.ContextLoaderPlugIn.CONTEXT.");
339:デフォルトの名無しさん
05/04/11 15:24:27
ああ、途中で送信してもうた。
>>335の
> BeanFactoryのアトリビュートへの設定と取り出しを管理するクラス自体は、Spring組み込みで提供されてる。
> しかしServletContextを使える場所でしかBeanFactoryを取得できないという制約が生まれる。
は、ApplicationContextを指していると思うんですけど、ApplicationContextの取り出しは、
>>338に書いたように、ServletContextから、↓の名前のクラスで埋められている、オブジェクトを取り出すんでOK？
「org.springframework.web.struts.ContextLoaderPlugIn.CONTEXT.」
それとも、ApplicationContextを取り出すには、こうする見たいなのってあるの？
340:デフォルトの名無しさん
05/04/11 16:10:43
>>339
俺はこうしてるよ。
ApplicationContext ctx = WebApplicationContextUtils.getWebApplicationContext(servletContext);
341:デフォルトの名無しさん
05/04/11 16:33:05
>>340
素早い回答サンクス！！！
やっぱり、ユーティリティはあったのね。
342:デフォルトの名無しさん
05/04/11 22:03:14
アプリケーションを起動したまま、コンポーネントを入れ替える方法ってありますか？
343:デフォルトの名無しさん
05/04/11 22:42:10
こういうやり方で取り出すのはOKなのかな？
これならServletContext無くても取れるんだけども。
package util;
public final class BeanFactoryHolder implements BeanFactoryAware {
private static final BeanFactoryHolder HOLDER = new BeanFactoryHolder();
public static BeanFactoryHolder getHolderInstance() { return HOLDER; }
public static BeanFactory getBeanFactory() { return HOLDER.beanFactory; }
private BeanFactory beanFactory;
private BeanFactoryHolder() { }
public void setBeanFactory(BeanFactory bf) {
if (beanFactory != null) {
throw new IllegalStateException("beanFactory already exists");
}
beanFactory = bf;
}
}
<bean id="beanFactoryHolder" class="util.BeanFactoryHolder" factory-method="getHolderInstance"/>
344:デフォルトの名無しさん
05/04/12 01:37:15
1個のVMに1個のWebアプリケーションのみ配備する、という限定ならいいだろうね。
裏を返せば不適当ということ。
util.BeanFactoryHolderクラスは、
Servletコンテナに100個のWebアプリがディプロイされていても、
そのうちの1個でしか使えない。
もしくは、100個のWebアプリ間で1個のBeanFactoryを共有する。
345:303
05/04/13 01:02:58
ご意見色々ありがとー。勉強になりました。
上に出てきた本も読んでみます。
現状の漏れの考えは、
１．ビジネスロジックに再利用性は殆ど感じない（あるとしたら
ライブラリとかユーティリティ系）。
２．業務要件として拡張性が求められている箇所は、自分で
ファクトリを作らないでDIコンテナを利用するのは良いかも。
３．本読んだらかわるかも。
おまけ
EJBで作られたビジネスロジックのコンポーネントは殆ど見たことない
んだけど、それってEJBがめんどいからでは無くってやっぱり
ビジネスロジックに再利用性が無いからじゃないかなって、
思いまふ（UI系は除いて）。
beaが頑張ってる気もするけど、beaでこの程度かと。。。
346:デフォルトの名無しさん
05/04/13 01:46:12
ビジネスロジックをインターフェース経由で使うのは再利用のためじゃなくて、
業務上の変更に耐えられるようにするためだよ。
EJBはほっといてもインターフェース中心になるんだけど、一つのオブジェクトに
対して４つのインターフェースが必要だったりして馬鹿くさいので誰もやらんのだ
と思うけど。
おれもトランザクション・スクリプトというか、関数プログラミング的に作っても
追いつくときは、極端にstaticメソッドだけでビジネスロジックを組んだこともある。
でもドメインモデルみたいに、各ビジネスロジック・オブジェクトが他のオブジェクト
と結びつき合ってる場合だと、業務の変更に対応する場合に、クラス構成を変えた
ほうが早いという場合もあるよ。
「請求書サービス」を「請求書サービス」と「売掛統計サービス」と「台帳サービス」
の三つに分解して、請求サービスのデータ登録メソッドを呼び出したら統計と
台帳も更新するように変えたって、請求書サービスのインターフェースがかわら
なければコントローラに影響を与えない。
逆に、オブジェクトが互いに依存し合ったドメインモデルのようなものを作らない
なら、別段困らないようにも思う。
347:デフォルトの名無しさん
05/04/18 21:27:23
Spring入門が発売されましたなぁ
348:デフォルトの名無しさん
05/04/18 23:07:17
今読んでます
349:デフォルトの名無しさん
05/04/18 23:27:43
どんな感じ？
350:デフォルトの名無しさん
05/04/19 09:09:14
俺は確保はしたがまだきちんと読んでない。
iBATIS との連携について書いてあったのがわりと新鮮だった感じ。
(もちろん Hibernate との連携も抑えてあった。)
Spring in Action の方が読み応えありそうなので
そっちを最初に片付けようと思ってる。
351:デフォルトの名無しさん
05/04/19 22:02:23
>>349
入門書という位置づけのようだが、定義ファイルに関する説明が
一覧表ですまされていたりするので、本当に初めての人がこの本で
Springを使えるようになるのかはちょっと疑問。
ApplicationContextのメッセージソースやイベントの説明はあるのに
FactoryBeanの説明がないっていうのは妥当な判断だろうか？
AOPも定義ファイルに書く使い方の前にProxyFactoryを直接使った例で
説明する意味はあるのだろうか？
DIとAOPという一番ベーシックな部分の説明が弱いのが入門書としては
難点だと思う。といって応用的な話があるわけでもなく…
352:デフォルトの名無しさん
05/04/19 22:48:59
>>350-351
サンキュ
Seasar2をちょっと触ってみたぐらいの俺だけど、Spring in Actionを買ってみます
353:デフォルトの名無しさん
05/04/19 22:54:31
Spring入門、俺も読み始めました。
内容はおいといて、文章は少しウザイ。
354:デフォルトの名無しさん
05/04/20 17:55:55
JDBCコネクションをプーリングしたいんですが、どんな方法があるのでしょうか？
355:デフォルトの名無しさん
05/04/20 20:01:54
Webならサーブレットコンテナまかせ。
356:デフォルトの名無しさん
05/04/21 00:52:01
>>354
Springで使うのなら、Apache Commons DBCPが一番お手軽かな
URLﾘﾝｸ(jakarta.apache.org)
357:デフォルトの名無しさん
05/04/21 00:55:53
「Spring入門」の2章でSpringをEclipseで使えるようにする説明があるんだけど、
「まずはSpringを以下のサイトからダウンロードし、適当なディレクトリに
解凍してほしい。
(URLとファイル名)
図2.19はダウンロードしたSpringをインポートしたJavaプロジェクト(以降は
Springプロジェクト)である。」
ってだけなんだよね。普通はこの説明で十分なのかな？
この後インポートした中にあるJARを別プロジェクトのlibにコピーしたりして
インポートする意味なしじゃね？ って感じなんだよね。ソースパスの話ないし。
手間かけずにクラスパス通してSpringのソース見れるようにしたいんだけど
どうするのがいいのかな？
CVSから.projectと.classpath取ってくる？ maven eclipseしてからインポート？
みんなどうしてる？
358:デフォルトの名無しさん
05/04/21 10:06:14
>>355,356
まずはDBCPから始めてみます。
359:デフォルトの名無しさん
05/04/21 11:51:42
>>357
本屋に逝って JavaPress Vol.41 を嫁
360:デフォルトの名無しさん
05/04/21 12:27:25
>>359
持ってるけど大したこと書いてない
spring.jar他をクラスパスに通せと必要に応じてsrcやdoc以下を参照しろってだけ
spring.jarくらいならともかく，その他のlibにあるJARを手間かけずにまとめて
クラスパスに設定したいなんて誰も考えないってこと？
361:デフォルトの名無しさん
05/04/21 20:41:26
JSFやSeasarの陰に隠れてもはや風前の灯火…。
362:デフォルトの名無しさん
05/04/21 22:00:16
>360
spring 使うことで増える lib は
spring.jar と aopalliance.jar
(AOP する人は cglib もか)程度なんで、
別に特別たくさん増やすとかいうわけでもないので
そんなに問題になると思わないんですが。
Spring のソース見る分にはlib/以下のjar
にclasspath通しまくる必要なんてないし。
363:デフォルトの名無しさん
05/04/21 22:09:55
>>361
JSFの影にかくれるとか言ってる時点で、Springがなんなのかわかってないだけということをさらしてるわけですね。
364:デフォルトの名無しさん
05/04/21 22:13:01
>>361
で、どれが良いのか言ってみそ
365:デフォルトの名無しさん
05/04/21 22:58:54
>>364
EJB3.0
366:デフォルトの名無しさん
05/04/22 13:58:47
ふぅ～、アフォ発見。たまに湧いて出るこういうボケも、一種の清涼剤か。
367:デフォルトの名無しさん
05/04/22 15:32:50
なんか Perl の話をしているところへ
ナメック語やRupyの陰に隠れて云々
とかって言われた気分。
そんなことより Spring で Color を Set する時に(コンストラクタベース)
いろいろ警告が出るようになってしまいました。
<bean id="bgColor" class="java.awt.Color" singleton="true">
<constructor-arg index="0">
<value>16711374</value>
</constructor-arg>
</bean>
Color(int rgb) を呼び出してるつもりなんですが
Ignoring constructor [public java.awt.Color(int,int,int,int)] of bean 'bgColor': could not satisfy dependencies
(以下stack trace)
Ignoring constructor [public java.awt.Color(float,float,float)] of...(同様にstack trace)
と延々とログられた挙句、最後に
Bean 'bgColor' instantiated via constructor [public java.awt.Color(int)]
と表示されて、無事インスタンスが作成されます。
一応、インスタンス作成されて実用上は問題ないといえなくもないですが
ログが太って困るのでどうにかしたいんですが
誰か正しい設定方法をご存知の方、ご教授ください。
1.1.2 で動かすと問題ないのですが、1.1.6 に上げたら出るようになりました。
(Spring のログレベルは DEBUG ですが、これはしばらくこのままで行きたいです。)
368:デフォルトの名無しさん
05/04/23 00:29:07
こんなこと書くと荒れるかもしれないが
SpringとSeasarって国内の業務ではどっちが多く使われてるのかな？
369:デフォルトの名無しさん
05/04/23 02:19:57
現実的にはSpringかと。
ただ、オープンソースのプロダクトの利用数を数えるのは難しい上、両方そこまで大々的には使われてないから実数はよくわからない罠。
370:デフォルトの名無しさん
05/04/23 22:42:23
1.2のRC2が出てるが、
なんか役に立ちそうな機能追加された？
371:デフォルトの名無しさん
05/04/24 01:21:41
Hibernate3対応かな？
372:368
05/04/24 19:14:40
>>369
thx!
373:デフォルトの名無しさん
05/04/24 19:30:21
>>372
ただ、Spring使ってる人のまわりではSpringばっかりだし、Seasar2使ってる人のまわりではSeasar2ばっかりだから、人の意見はあまりあてにならんけどね。
374:デフォルトの名無しさん
05/05/06 13:30:15
すまん、DIはよく知らんのだが、よくEJBは××だからDIまんせー的な
発言見るんだけど、そもそもDIってリモートコールできんの？
375:デフォルトの名無しさん
05/05/06 13:58:11
DIパターンとリモートコールは全然関係ない領域の話だとおもうがね。
376:デフォルトの名無しさん
05/05/06 14:30:44
一つ聞きたいんですが
URLﾘﾝｸ(wiki.bmedianode.com)
↑のページを参考に beanRefContext.xml を書いたのですが
Spring が DEBUG メッセージを吐くのでちと気持ち悪いです。
ログは汚れるものの、期待通りの動作はしています。
型の合うコンストラクタが見つからないとか、そんな感じのメッセージなのですが
確かに ClassPathXmlApplicationContext のコンストラクタに
java.util.ArrayList を持つものはない模様で
この辺りは「一通りコンストラクタ調べたけどないっぽいから
String[] だと思って処理しよう」とかそんな流れでしょうか？
この辺り、ログを汚さないでスマートに指定する方法を教えていただけないでしょうか？
377:デフォルトの名無しさん
05/05/06 18:37:22
Springをちょっとずつ勉強しててＤＩのあたりまでわかったところなんですが、
AOP周りにも触ってみようと思ってます。
で、AOPって、具体的にはどんなことに使えるのかサッパリわかりません。
ログとる例ばっかりで、他に出来ることはないのか？って感じなんですが、
何に使うんですか？AOP
コンテナ側では使ってるのは理解できるんですが。
具体的な用途や、参考になるページがあったら
すみませんが教えてもらえないでしょうか。
378:デフォルトの名無しさん
05/05/07 03:33:48
AOPの二大用途といえば、
- ロギング
- トランザクション
だわな
379:デフォルトの名無しさん
05/05/07 05:15:36
Webの場合はそのくらいだな。
380:デフォルトの名無しさん
05/05/07 06:30:47
GUIのプログラムの場合、データ変更の画面への通知もAOPがいい。
381:デフォルトの名無しさん
05/05/07 06:33:45
イベントリスナーとかの代わりにって事？
382:デフォルトの名無しさん
05/05/07 06:58:12
GUIモノだと、だいたいセッターの後でnotifyみたいなの呼び出す必要があって、かなりめんどい。
それがAOPで楽できる。
383:デフォルトの名無しさん
05/05/07 08:04:05
効率を無視していいなら良いんじゃないの
384:デフォルトの名無しさん
05/05/07 08:38:48
無視していいわけないけど、影響が少なければ問題ない。
385:377
05/05/07 12:01:00
どうもありがとうございます。Web系なんですが、ログもトランザクションも
Springだとそのための手段が用意されてるのでなかなか使い道が難しいですね。
昔ＧＵＩも作ったことあったのですが、その例もなるほどなって思いました。
面倒ですものね。「横断的関心」ってやつがちょっとイメージできた気がします。
探してたら、こんなページも見つけました。難しいので理解できてませんが
URLﾘﾝｸ(www.oucc.org)
386:デフォルトの名無しさん
05/05/07 12:03:14
あ、すいません。ログはないですね。
387:デフォルトの名無しさん
05/05/08 13:35:51
>>386
org.springframework.aop.interceptor.TraceInterceptor
org.springframework.aop.interceptor.DebugInterceptor
388:デフォルトの名無しさん
05/05/08 18:55:53
>>375
質問した者だが
いやそうじゃなくて、じゃあそもそもEJBと比較して意味あんのかって意味。
分散オブジェクト技術とそうでない技術なら話してる土台が違うわけで
DI>>EJBとかわけわかんないんだけど。
389:デフォルトの名無しさん
05/05/08 19:18:26
>>388
EJBは分散が必要ない人にも分散を前提としためんどうな手続きを強要してた。
ほとんどの人に分散は必要なかった。
ほとんどの人にDI+ORM > EJB。
390:デフォルトの名無しさん
05/05/08 19:21:41
>>389
てか分散使わないのにEJB使ってる時点でどうかと・・。
まぁ後者のORMとかはわからなくもないが、EJBは
どっちかっつーと、というかどう考えても分散オブジェクトなわけで。
391:デフォルトの名無しさん
05/05/08 19:35:40
で、だからEJB使わずDI+ORMでいいじゃんとなったんでしょ。
392:デフォルトの名無しさん
05/05/08 21:33:10
>>391があたりまえだがいいことをいった。
393:デフォルトの名無しさん
05/05/08 22:17:34
>>390
まあ、EJBには分散以外にもいい点があるわけで。
宣言的なトランザクションとか、SQLを直接書かないDBMSアクセスとか。
そういEJBのよい機能は使いたいけど、
EJBは動かすの面倒、重い、コンテナに依存してテストしづらい
ってのがあって、その打開策としてSpringをはじめとして色々な
ソフトが出てきているわけだよな。
394:デフォルトの名無しさん
05/05/08 23:26:16
EJBってのはむしろCORBAの世界で
生きるはずなのだが。
395:デフォルトの名無しさん
05/05/08 23:38:34
それはない。
396:デフォルトの名無しさん
05/05/12 14:50:52
Spring＋HibernateでWebアプリ開発しようとしているんですが
applicationcontext.xmlのsessionFactoryのところで
java.lang.NoClassDefFoundError: net/sf/ehcache/CacheException
となってしまいます
でも、Hibernateのソースを見ても
net.sf.ehcache.CacheExceptionというクラスは存在してないみたいなんですが
どういうことなんでしょうか？
Hibernateはspring-framework-1.1.5の中に入っていたものを使用しています
397:デフォルトの名無しさん
05/05/12 19:55:24
そりゃeCacheのjarを用意していないからでは
398:デフォルトの名無しさん
05/05/14 18:48:46
質問があります。どうしてもわからないので教えてください。
applicationContext.xml に登録したオブジェクト(bean)の中の処理でファイルを読もうとしています。
このクラスは HttpServlet を継承していません。（特にクライアントからの要求を受け付けるわけではないので
そうしていました）したがって、web.xml には mapping していません。
この状態で、(webapps/project)/WEB-INF/data/ といったディレクトリからファイルを読み出したいので、
絶対パスを取得しようとしていますが、わかりません。
ApplicationContext appCtx = new ClassPathXmlApplicationContext("applicationContext.xml");
で、コンテキストは取得できましたが、パスを取り出す方法はないでしょうか？
（もちろんコンテキストからでなくても構わないです。）
Spring 使ってる上でクラスの作り方が間違っているとか、もっと普通の方法があるようでしたら
ご指摘ください。よろしくお願い致します。
399:デフォルトの名無しさん
05/05/15 22:24:06
>>398
私も同じ現象起きてます。
"/WEB-INF/lib/applicationContext.xml"という指定をすると
WEB-INFが見当たらないというエラーが返ってきます
なんでかしらんけど、パッケージの中しかパスが認識されないんです
だから
"/jp/co/sample/applicationContext.xml"
みたいにすると読み込めるんですよ。
でもソースのパッケージの中に設定入れとくのはちょっと気持ち悪いな、といった感じです
私はEclipseでTomcatプラグイン使用してますけど
Web.xmlの設定とかが必要なのかなー
400:399
05/05/15 22:30:21
レスした後に気づいたけど
>で、コンテキストは取得できましたが、パスを取り出す方法はないでしょうか？
>（もちろんコンテキストからでなくても構わないです。）
これどいう言う意味ですかね？
絶対パスで指定しなければルート（WEB-INFなのか？）から
フォルダをなめていってくれてapplicationContextを探すってことですかね。
不勉強ですいませんorz
401:デフォルトの名無しさん
05/05/16 05:36:09
つか、Webアプリだったらweb.xmlに設定書いた設定使うようにすりゃいいじゃん。
402:398
05/05/17 05:44:34
>>399
/web.xml
/WEB-INF/config/ (クラスパスが通っている)
/WEB-INF/config/applicationContext.xml
/WEB-INF/data/ （クラスパスが通っていない）
/WEB-INF/data/data.xml
結局知りたいのは、HttpServlet を継承していないクラスから、
上の /WEB-INF/data/data.xml を読む方法なんですが、わからない・・・
>>401
web.xml に登録していなくて、httpServlet を継承していないクラスから
web.xml に記載した初期化パラメータ読むにはどうすればいいんですか？
マジで調べてもわからなかったので、すいませんが教えてください。
403:デフォルトの名無しさん
05/05/17 08:11:38
>>402
HttpServletを継承していない普通のクラスが、
/WEB-INF/なんて、HTTP固有のディレクトリ構造に
依存することを良しとする訳ですか。
404:デフォルトの名無しさん
05/05/17 08:46:55
基本的には普通のクラスはDIコンテナの存在を気にしないようにするね。
405:デフォルトの名無しさん
05/05/17 08:47:10
Servletクラスは絶対パスを取得できるので、そのパスをもらえばいいのでは？
406:デフォルトの名無しさん
05/05/17 09:11:58
サーブレットからApplicationContext自体をもらえばいいね。
407:デフォルトの名無しさん
05/05/17 14:22:24
FileSystemXmlApplicationContextではだめかいな？
408:デフォルトの名無しさん
05/05/17 17:29:46
皆さんどうもありがとうございます。
>>403
/WEB-INF/data にアプリが使うデータファイル置くのは一般的に言って変ですか？
/dataでもいいので普通はそうなら変更を考えます。まだ作法に慣れてないもので勉強します。
>>404
そのクラスは相手がDBじゃなくてファイルなんですがDaoと同じ様な役割をさせたいクラスなんで
他のDaoクラスと同じようにDIコンテナからロードさせてるんですよ。
で、Servletとか関係ない層で動いてるんですが実際のパス取得をどうしようかと悩んでます。
Springのフレームワークからそういうのとれないのかなと考えてましたが、的違いでしたでしょうか？
>>405-407
結局Servletクラスからパスをもらうことにしました。
正直に言ってまだ釈然としないものが残っているんですが、一般的にそうなら慣れるしかないですね
409:デフォルトの名無しさん
05/05/17 21:41:41
いにしえのServlet/JavaBeans流：jarファイル近辺のPropertiesファイルか取得
：
J2EE流：JNDIからデータの位置を取得
Connectorアーキテクチャでデータを供給
：
Spring Framework： ？
410:デフォルトの名無しさん
05/05/17 22:37:48
>>408
ふつうは、普通のクラスはDIコンテナの存在を気にしないでいいようにする
411:デフォルトの名無しさん
05/05/17 22:39:07
>>408
設計が悪いときに無理をしないといけないのは一般的な話だから気にするな。
412:デフォルトの名無しさん
05/05/17 23:28:33
>>409
BeanFactoryから取得
413:デフォルトの名無しさん
05/05/17 23:41:41
BeanFactoryはどこからファイル所在を取得するつもり？
414:398
05/05/17 23:59:50
398です。お忙しいとこ何度もすみません。
>>410
ということは、Spring のアプリケーションコンテキストに依存せず、他の（サーブレットを継承していて
サーバ環境にアクセス可能な）クラスからもらってくる方法はまだマシという理解であってますか？
>>411
設計が悪いのなら直したいのです。>>409さんが書いている様に、Springやその他のDIコンテナ
（すみませんがJ2EE/EJBは知りません）を使ったときの作法があるのなら、この機会に
身に着けたいと思ってます。普通のクラスが外部リソースにアクセスする一般的な方法を
教えてもらえませんか？
415:デフォルトの名無しさん
05/05/18 00:17:47
>>413
そりゃサーバサイドだったら、web.xmlじゃないか？
JNDIだってどっかにJNDIのInicialContextFactoryを指定する（プロパティとか）のと同じ事だとおもうけど。
416:デフォルトの名無しさん
05/05/18 00:44:57
つまり、根っこはプロパティ
417:デフォルトの名無しさん
05/05/18 00:45:37
web.xml使うのは、Servlet層だけの簡単アプリ
418:デフォルトの名無しさん
05/05/19 06:47:36
DIしたオブジェクトから先は、いもづる式にDIするようにして、DIコンテナを意識しないとか。
419:デフォルトの名無しさん
05/05/19 10:10:35
>>418
最初は芋づる式って密な感じがして気持ち悪かったけど
実装してみたら楽すぎて止めらんね
どういった点でデメリットが出てくるんだろうか
420:デフォルトの名無しさん
05/06/01 08:56:52
JSF+Springで設計してんですけど
JSFのバッキングビーンのクラスとビジネスロジックのクラスのそれぞれの役割で
バッキングビーン
値のチェック、変換（この辺はバリデータ、コンバータに
任せるべきなんだろう）などのビジネスロジック呼び出す前の処理
あと、ビジネスロジックの結果の後処理
ビジネスロジック
必要なDAOを呼ぶだけ
こんな風に考えてます。これだとビジネスロジックのクラスが
たいした役割ではないと思うんですけど、DAOのファサード風と考えてよいでしょか
JSF+Springのサンプルアプリがみたいどすえ～
421:デフォルトの名無しさん
05/06/01 10:05:15
>>420
＞JSF+Springのサンプルアプリがみたいどすえ～
URLﾘﾝｸ(appfuse.dev.java.net)
URLﾘﾝｸ(equinox.dev.java.net)
漏れ自身が勉強中なので情報提供のみで失礼。
422:デフォルトの名無しさん
05/06/01 10:47:23
>>420
ＤＢのモデルを単に画面に表示する・画面に入力した値をＤＢに格納する
みたいなシンプルなアプリだとそうなるかもね。
423:デフォルトの名無しさん
05/06/01 10:50:24
sageついでに
＞ビジネスロジック呼び出す前の処理
＞あと、ビジネスロジックの結果の後処理
どのレベルの処理を言ってるのかわからないけど、
本当にMVCレイヤに置くべき処理なのか再検討してみては？
424:デフォルトの名無しさん
05/06/01 11:58:03
この本どうよ？書評ｷﾎﾞﾝﾇ
『実践Spring Framework―J2EE開発を変えるDIコンテナのすべて』
URLﾘﾝｸ(www.amazon.co.jp)
『入門Spring』と『軽快なJava』は読みました。さらに詳しい話を
聞きたい、という目的に使えますかね？
425:デフォルトの名無しさん
05/06/02 22:11:28
SpringがJSFとXULをイイ感じに仲介するフレームワーク作ってくれたら
一杯おごってやりたい。
426:デフォルトの名無しさん
05/06/03 12:15:51
>>425
Mozilla独自のXULより標準規格のXFormsのほうが良いのでは？
MozillaもOpenOffice.orgもXFormsに対応する上に、
Chibaを使えばXForms未対応のブラウザに対して
HTML+JavaScriptに変換してから送信することで
大部分のブラウザに対応できます。
Chiba (サーバーサイドJavaライブラリ)
URLﾘﾝｸ(chiba.sourceforge.net)
MozillaとXForms (Mozilla1.8/Firefox1.1で対応予定)
URLﾘﾝｸ(www.mozilla-japan.org)
[XForms 00031] XFormsのためのwiki (村田真氏がMozillaでXForms推進)
URLﾘﾝｸ(www2.xml.gr.jp)
427:デフォルトの名無しさん
05/06/03 12:41:43
>>426
XULへの必要性は一般の人にとっては低いとは思うが、
>>425は、ブラウザベースクライアントじゃなくて、リッチクライアントとして
XULを使うことを前提に書いてるんじゃなかろうか。
JSF経由でSwingとかFlashをクライアントにするノリで。
428:デフォルトの名無しさん
05/06/03 12:42:00
sage
429:デフォルトの名無しさん
05/06/22 09:39:06
禿げオヤジは意外とおとなしかったな。
430:デフォルトの名無しさん
05/06/25 15:34:01
海外では50％以上のプロジェクトで使われていて
ほぼデファクトスタンダードらしいが、なぜこのスレは伸びないの？
431:デフォルトの名無しさん
05/06/25 18:21:20
まあ、DIスレも伸び悩んでるし、
カテゴリとしてマイナーなんでは。日本では。
432:デフォルトの名無しさん
05/06/26 08:56:09
>>430
DIは、使い始めれば空気みたいなもんで、とくに議論することもなくなるから。
433:デフォルトの名無しさん
05/06/26 16:54:53
つーかSpringがホントに便利なのって純粋なtype2,type3のInjectionその物より、
コンテナが作ったProxyに対するAOPでしょ？
434:デフォルトの名無しさん
05/06/26 22:33:01
DIってのは、そういうものを便利にするための裏方だからな。
435:デフォルトの名無しさん
05/06/27 10:43:51
このスレ生きてるみたいだから質問させてくれ
proxyでAspectをweavingする事の弱点って何だ？
漏れが把握しているのは
1.自分自身のメソッドを呼び出すとAspectがかからない。
2.visitorみたくthisを渡して処理させるとAspectがかからない。
他に注意点ある？
436:デフォルトの名無しさん
05/06/27 11:31:59
ものすごくはらへった。
437:デフォルトの名無しさん
05/06/27 11:41:45
俺もだ。
438:デフォルトの名無しさん
05/06/27 13:49:43
いまさら同意。
439:デフォルトの名無しさん
05/07/05 11:09:42
1.2.2リリース記念
440:デフォルトの名無しさん
05/07/05 13:38:30
>>439
どこが変わったの？
441:439
05/07/05 15:43:58
詳しく見てない＆試してないけど、注目した一文は；
『added dedicated support for Hibernate Annotation 3.0 beta 2』
442:デフォルトの名無しさん
05/07/05 17:36:12
>>441
でも、前からHibernate Annotations使えてたよ。
443:デフォルトの名無しさん
05/07/05 22:32:17
つうか、Doclet のことを言ってるんじゃあるまいな。
444:デフォルトの名無しさん
05/07/06 03:19:27
アノテーションってそんなにいいもんなんでしょうか。
DIでせっかくコードから煩雑な記述を追い出したのに、
またコード中に埋め込んで、回帰と言うか退化と言うか。
コンパイラに対する指示を埋め込むのは意義が大きいと思うけど。
445:デフォルトの名無しさん
05/07/07 10:24:52
>>443
ここの最後にやりかた書いてあるよ。
URLﾘﾝｸ(www.fk.urban.ne.jp)
446:デフォルトの名無しさん
05/07/07 10:25:46
>>444
アノテーションは、XMLより記述が楽だし、ソースから得た型の情報を使うことで記述量自体が少なくできてるから、そう煩雑でもない。
クラスに関する情報をソースファイルに一元化できる効果もある。
なによりコンパイラによる静的チェックが効くし、Javaソースエディタでの補完が効く。
447:デフォルトの名無しさん
05/07/08 22:00:29
DIってテストしやすくなる？
単体まではいいけど、結合で結局アボーンな感じがするのだけど。
まぁつまるところは設計能力か・・・
448:デフォルトの名無しさん
05/07/10 00:55:34
アボーンって、具体的にはどういう問題がでてくると思う？
449:デフォルトの名無しさん
05/07/13 20:03:02
TransactionProxyFactoryBeanにtagetってフィールドがあるんですけど、これシングルトンなんです。
マルチスレッドでここに処理が殺到した場合、スレッドセーフにトランザクションさばけるんでしょうか？
教えてください。
TransactionProxyFactoryBean
URLﾘﾝｸ(www.springframework.org)
450:デフォルトの名無しさん
05/07/13 20:42:56
>449
そりゃ、targetしだいだろ。targetがスレッドセーフなら、問題ない。
451:名無しさん
05/07/13 21:00:03
同時に異なるスレッドの異なるtargetがシングルトンのTransactionProxyFactoryBeanにセットされにきたらどうなりますか？
452:デフォルトの名無しさん
05/07/13 23:18:19
オブジェクトの数とスレッド数は別ものとして考えないと。
ちゃんと考えられてるだろうから、
単一のオブジェクトの同じメソッドを
複数のスレッドが並行して駆け抜けることは全然OKなように
つくられてるはず・・・（たぶん）
453:デフォルトの名無しさん
05/07/14 16:28:52
蒼ざ(ry
454:デフォルトの名無しさん
05/07/14 19:22:10
どうやらtargetもシングルトンじゃないとダメみたいですね。
455:デフォルトの名無しさん
05/07/16 17:28:30
>>462
それはプラットフォームによる。
・GUIは大抵そう。(OSから飛んでくるイベントの処理は、イベント毎の状態保持が必要。
もっとも、同じ要素に複数イベント飛んできたら、単に順次処理する事が多いんで、
本当のスレッド並列処理はそんなに必要ないと思う。)
・Webアプリ周りも大抵そう。(例の(Statefull)Servletあたりが有名)
それ以外の場面で、常にインスタンスとスレッドを別に考えるのは、どーかと思う。
結局インスタンス数を減らしてまでメモリー消費を避けたい特殊な場面(大規模アプリ、組込みアプリ)
に固有のやりかただと思う。
456:455
05/07/16 17:30:24
ああ>>451-452の流れか。>>455は取り消し(ワラ
457:デフォルトの名無しさん
05/07/19 10:34:04
というか誰にレスしてんだ
458:デフォルトの名無しさん
05/07/24 22:38:13
これが最近有名なJSFって奴ね。
Javaは最新の技術追うのが大変（＠＠）
459:デフォルトの名無しさん
05/07/25 01:15:53
==============================
キチガイが狂った独り言を書き込み中
==============================
460:デフォルトの名無しさん
05/07/25 07:37:48
>>441
applicationContext.xmlの中でHibernate Annotationsの設定がかけるようになるってことみたいだね。
LocalSessionFactoryBeanを使う場合は、hibernate.cfg.xmlを書いておく必要があった。
461:デフォルトの名無しさん
05/08/06 22:29:31
Spring1.2.3でProxyFactoryBean使おうと思って
[ sample.xml ]
<beans>
<bean id="test" class="org.springframework.aop.framework.ProxyFactoryBean">
<property name="proxyTargetClass"><value>true</value></property>
<property name="target"><ref local="person"/></property>
<property name="interceptorNames"><value>advisor</value></property>
</bean>
…略…
</beans>
[ sample.java ]
BeanFactory factory = new ClassPathXmlApplicationContext("/com/mamezou/aop/proxydi/sample.xml");
Person person = (Person) factory.getBean("test");
person.setName("Hoge");
ってやるとCGLIBがねぇよってエラーになって、
CGLIB2.1のjarクラスパスに突っ込んでやるとエラーになるんだけど…。
対処方法ってなんかある？
462:461
05/08/08 00:45:20
事故解決しますた。orz
463:デフォルトの名無しさん
05/08/08 01:32:41
いちお、解決方法きぼんぬ
464:デフォルトの名無しさん
05/08/08 12:18:04
今度は aopallience がねえよって怒られて
それを修正したとかそんな流れ？
465:461
05/08/08 20:07:27
遅レス、スマソ。
CGLIB2.1入れても
java.lang.NoClassDefFoundError: org/objectweb/asm/Type
って出たので、ASM入れただけです。
＿｜￣｜○|||
ASMは1.5.3入れました。2.0だと
java.lang.NoClassDefFoundError: org/objectweb/asm/CodeVisitor
が出ます故。これで動いたは動いたケド、正しいかどうかは…。
466:デフォルトの名無しさん
05/08/08 20:27:13
>>464
だいたいあってたね。
467:デフォルトの名無しさん
05/08/10 12:47:00
だいたいってことは、正確にはどーすればよいわけ？
468:デフォルトの名無しさん
05/08/10 20:51:17
CGLIB とかのライブラリは
Spring 付属の jar をぶっこんだ？
まだ 1.1.7 使ってて 1.2 系は試してないけど
付属の jar 入れとけば間違いは少ないと思う。
469:461
05/08/10 20:53:28
ageます。ｽﾏｿ。
>>467
asm-1.5.3.jar
cglib-2.1_2.jar
をWEB-INF/lib/に放り込んでクラスパス通すだけでつ。
「ProxyFactoryBean使うときはCGLIB入れろ」
ってドキュメントに書いてあったのですが、
CGLIB使うときはASM入れないないとNGなんで、
URLﾘﾝｸ(prdownloads.sourceforge.net)
URLﾘﾝｸ(forge.objectweb.org)
のミラーからDLしてください。
…というコトではない？
470:デフォルトの名無しさん
05/08/10 21:14:42
with-dependency の方のディストリビューション落とせば
添付の jar を必要に応じて加えるだけで
外部のライブラリは不要だったと思うんだけど。。
471:461
05/08/10 21:47:00
>>470
ｻﾝｸｽ。
>with-dependency
こっちじゃなくて、spring-framework-1.2.3.zip落としちゃって…。
URLﾘﾝｸ(www.techscore.com)
にしっかり書いてありました。orz
472:デフォルトの名無しさん
05/08/19 12:55:20
Spring Beans XML Editor (Spring IDE for Eclipse)
URLﾘﾝｸ(springide.org)
Screen Shot 見る感じだと
とりあえず欲しい機能は結構揃っているような。
473:デフォルトの名無しさん
05/08/25 16:33:37
URLﾘﾝｸ(www.springframework.org)
474:デフォルトの名無しさん
05/09/07 09:38:35
KingはRodが大嫌いなんだとさw
URLﾘﾝｸ(houseofhaug.net)
475:デフォルトの名無しさん
05/09/07 09:53:15
Hibernate3 でトランザクション周りが結構変わって、
Spring とかなり方向違うなぁと感じたりはする。
Hiernate の Session Factory から getCurrentSession() 呼んだら
思いっきり怒られたりとか。
JTA が必要だったとは知らなかった。
なんかそんなことが続いてる。。
476:デフォルトの名無しさん
05/09/13 23:10:59
Springを勉強してます。
サーブレットにDIしたいクラスのsetter作って
動かしてみたのですが、NullPointerException...
サーブレットではsetterインジェクション(?)できないんですか？
ContextからgetBeanすれば普通にとれるんですが。。
477:デフォルトの名無しさん
05/09/14 00:14:32
>>476
普通はBeanにsetter/getter作るでしょ。
むしろ、setter/getter作ると自然にBeanになる。
MVCからやり直s（ry
478:デフォルトの名無しさん
05/09/14 00:27:50
>>476
サーブレットでDIするためにどういう設定したの？
479:デフォルトの名無しさん
05/09/14 00:40:33
>476
Webコンテナが管理しているサーブレットインスタンスを
そのサーブレットが呼ばれる前に，アプリ側から取得する方法があるとでも？
480:デフォルトの名無しさん
05/09/14 01:39:52
しかし、いろんなこと考える奴がいるもんだな・・・ある意味感心したw
481:デフォルトの名無しさん
05/09/14 02:41:41
>>479
web.xmlにはプロキシサーブレットを登録して、そのときパラメータで実際のサーブレットクラスを指定するような実装にすればできんでもない。
482:476
05/09/15 01:29:23
>>477-481
勉強不足でごめんなさい。
サーブレットからビジネスロジックを呼び出すのに
自分でビジネスロジックのインスタンスを作らずに、
setterを作って、ビジネスロジックをDIしようとしたのですが。。。
やっぱり無理なんですかね？
483:デフォルトの名無しさん
05/09/15 02:32:53
>>482
便乗してTapestryの宣伝でもしてみるか。
Tapestry-4.0だと、それに相当する事が出来るようになってる。
Tapestry-4.0自体はDIコンテナにHiveMind使ってるけど、
HiveMindとSpringを連携させる方法もあるので、
Springで管理してるオブジェクトをTapestryのページや
コンポーネントにDIすることできて便利。
484:デフォルトの名無しさん
05/09/15 03:15:06
>>483
日本語のドキュメントはどこにありますか？
485:デフォルトの名無しさん
05/09/15 16:21:13
あなたはいぢわるな人だ
486:デフォルトの名無しさん
05/09/19 09:44:33
で、実際に開発で使ってる実績ってあるの？
Spring。
487:デフォルトの名無しさん
05/09/19 09:47:35
何をもって実績と呼ぶかを定義しないと
そりゃどっかで使ってるさ。で終わってしまう。
488:デフォルトの名無しさん
05/09/19 19:12:43
どっかって・・・。
どこでも使ってないんじゃないの、と思ってるんだが。
489:デフォルトの名無しさん
05/09/19 20:59:49
おれんとこの現場は使ってる
490:デフォルトの名無しさん
05/09/19 21:06:20
>>488
そうかもね。
というか、DI自体にメリットというか魅力を感じない。
いや、考え方とかそういったのは素晴らしいと思うよ。
だけど、実際には客先にコストダウンとかのメリットがある訳じゃないし、
実行速度が上がるわけじゃない。
まぁ、テストを簡単に行えて品質は上がるのかもしれない。
だけど、問題は、DI使ったからといって、修正とかが楽になるかと言えば、答えはNO。
大抵の修正はメソッドの呼び出しとか、そういったものまで結構変更になる。
なのに、下手にDI使ってインターフェースとか定義してたら、
結局インターフェースもクラスも関連するもの全部修正しないといけない。
つまり、殆どの場合、DI使うことにより、修正の手間は倍以上になる。
作る時に、無駄ともいえるものを作るんだから、下手したら4倍近い手間。
世間がこれからどうなるか知らないが、すくなくても俺の会社では
DIは明示的には使わないという方向で決まった。
（ライブラリの内部とかで使われてるとかは知ったこっちゃ無い）
491:デフォルトの名無しさん
05/09/19 22:21:44
インターフェイスをきるときには、システム将来計画等から予想して、
ある程度変更になりそうな部分を見極めとかないと意味は無い
DIか否かより、結局は設計の問題になると思うけど
492:デフォルトの名無しさん
05/09/19 23:06:57
>>490
君の言ってることはDIとは直接関係ないかなぁ。
単にインターフェースへのプログラミングってやつの是非を語っているだけではないのか？
まぁ、それも確かに賛否両論よく議論されているネタだけどね
DI使うと部品作って組み立てるプロセスが面白くて、楽しく開発は出来るんだけど、
アホには使いこなせないからあまりポピュラーにはならないかもしれない
493:デフォルトの名無しさん
05/09/20 00:09:30
SimpleFormControllerでvalidatorを行おうとしています。
<bean id="confirmEntryController" class="controller.ConfirmEntryController">
<property name="commandClass"><value>model_entity.User</value></property>
<property name="commandName"><value>user</value></property>
<property name="validator"><ref local="userValidator"/></property>
<property name="formView"><value>userEntryView</value></property>
<property name="successView"><value>confirmView</value></property>
</bean>
エラーを表示するのに、spring:bindを利用しているのですが、
-------------entry.jsp-----------------------------------------
<spring:bind path="user.name">
<FONT color="#FF0000"><c:out value="${status.errorMessage}"/></FONT>
</spring:bind>
entry.jspを表示するときに、次のようなエラーになってしまいます。
javax.servlet.ServletException: Neither Errors instance nor plain target object for bean name 'command' available as request attribute
なにか見落としがあるのでしょうか？
あうあぅ締め切りがあさってです。助けてください・・・
494:デフォルトの名無しさん
05/09/20 00:11:05
あーーすみません
エラーメッセージがまちがっていました。。
javax.servlet.ServletException: Neither Errors instance nor plain target object for bean name 'user' available as request attribute
495:デフォルトの名無しさん
05/09/20 01:41:00
まだ490みたいなこと言う人居たのか。すげえな。世の中って。
496:デフォルトの名無しさん
05/09/20 02:29:53
MVC フレームワーク使ったことないんで
(Viewは絶対にVelocityが良い派。
コントローラはStrutsがベタ打ちっぽくて好き派。)
大きく外してるかも知れませんが
URLﾘﾝｸ(64.233.179.104)
＞Bind 時に
＞javax.servlet.ServletException: Neither Errors instance nor plain target object for bean name 《コマンド名》 available as request attribute
＞という例外が発生する事があります。 これは、Bind するコマンドオブジェクトがリクエストに保存されていないのが原因です。
＞コントローラに SimpleFormController を使っている場合、processFormSubmission() メソッドで、
＞super.onSumit(request, response, command, errors) を呼び出すと、例外は発生しなくなりました。参考までに。
ConfirmEntryController でそれに類する処理が必要かどうか、存在するのかの確認と、
デバッガで動かしてリクエストの中身を覗いてみてはどうでしょうか？
497:デフォルトの名無しさん
05/09/20 20:30:51
>>495
そうでもないんじゃない？
実際、ある程度予測できる範囲やちょっとした修正なら、DIだろうが何だろうが修正は簡単。
だけど、大抵の場合って、そもそもの仕様から引っくり返されるんだよね。
『ごめん。やっぱりこの機能も追加して』って一言で。
そうなると、確かに>>490の言うような状態に陥る。
498:デフォルトの名無しさん
05/09/21 01:34:49
インターフェース直して、テストコード直して、実装直す。
簡単ジャマイカ
499:デフォルトの名無しさん
05/09/21 01:44:41
>>497
顧客の「やっぱり」が予想できる場合と出来ない場合で違うと思う
予想できない場合は、たとえどんな作り方をしてても無駄なわけだし
500:デフォルトの名無しさん
05/09/21 03:19:34
DIの肝って、「実装を交換できる」ってこと。
あとは想像力さえあれば、大抵の状況は、インターフェイスの修正無しになんとかできるはずだが。
まぁ、インターフェイスの設計がへぼいとどうにもならない場合があるけど。
501:デフォルトの名無しさん
05/09/21 05:36:55
べつに、実装交換しなくても便利なんだけど。
実際のアプリケーションでDIでつなげたクラス同士を切り替えることなんてほとんどない。
それでも、つなげることをやってもらえるだけで便利。
502:デフォルトの名無しさん
05/09/21 23:44:25
>>501
コードでつなげる処理を書くよりも便利なの？
やっぱり自分で試して体感してみるしかないかな。
503:デフォルトの名無しさん
05/09/22 06:51:23
自分でさわらずに批判してもしかたないよ。
504:デフォルトの名無しさん
05/09/22 09:06:33
DI に関する話をココでやって
Springの話をDIスレでやると言う
ねじれ現象が起きてるのは何故ですか？
505:デフォルトの名無しさん
05/09/22 11:53:07
ながいものはねじれるというのが物理法則の基本だから。
506:デフォルトの名無しさん
05/09/23 09:54:47
そもそもDIスレなんてのかあったのかって話。
507:デフォルトの名無しさん
05/09/23 17:54:03
>>506
Dependncy Injectionを語るスレ
ｽﾚﾘﾝｸ(tech板)
508:デフォルトの名無しさん
05/09/23 23:10:30
多少綴りが間違ってるのと、DI という略語を併記しなかった失策っぽい。
509:デフォルトの名無しさん
05/09/24 03:31:24
>>507
一月半もレスないのか。
S2スレはFAQの件で盛り上がっているというのに……。
510:デフォルトの名無しさん
05/09/24 03:33:09
本題ではあまりもりあがらない件
511:デフォルトの名無しさん
05/10/05 11:18:48
>>449の件って、>>454が正解なんですか？
だれか解説お願いします。
512:デフォルトの名無しさん
05/10/19 09:37:25
こんな記事があったんですが、Springが主流になりますかね？
URLﾘﾝｸ(www-128.ibm.com)
513:デフォルトの名無しさん
05/10/19 10:43:13
>>512
読めん！
514:512じゃないけど
05/10/19 16:48:17
>>513
これなら読めるか？
URLﾘﾝｸ(www-06.ibm.com)
515:デフォルトの名無しさん
05/10/19 17:50:56
>>514
読める！
516:デフォルトの名無しさん
05/10/23 21:45:48
おまいら、SpringのTransaction管理って使ってますか？
517:デフォルトの名無しさん
05/10/23 22:15:15
使ってない。
むしろ自分でトランザクションコード書いた方が安心する。
別に大した労力じゃないし。
分散トランザクションやろうとしたら別だけど。
518:デフォルトの名無しさん
05/10/23 22:20:08
そしてデッドロック
519:デフォルトの名無しさん
05/10/23 22:26:25
デッドロックに対して気をつけなきゃいけないことは、トランザクション管理も
ハードコーディングも一緒なり
520:デフォルトの名無しさん
05/10/24 00:00:28
>>517
try/finally/try/catchをいちいち書くの面倒じゃない？
521:デフォルトの名無しさん
05/10/24 00:22:16
>>520
書くと安心するｗ
いたるところで書くわけでもないし苦痛でもない。
522:デフォルトの名無しさん
05/10/24 14:16:34
ひとりとかふたりで開発するならそれでもいいんだけどねぇ。
人数多くなってわけわかんないコーダーが含まれるようになると、それじゃ怖い。
523:デフォルトの名無しさん
05/10/24 15:15:19
投げて上で処理するとか。
一箇所で処理できる仕組みであれば何でもいいけどな漏れは。
524:デフォルトの名無しさん
05/10/24 17:24:13
投げて上で処理ってどういうこと？
上でconnection.rollback();
を実装するという意味だよな？
525:デフォルトの名無しさん
05/10/24 21:00:01
>>523
その為にAspectとか有るんじゃないか？
526:デフォルトの名無しさん
05/10/24 21:21:21
そこでEntity Beanですよ。
527:デフォルトの名無しさん
05/10/24 23:28:43
コミット、ロールバックもろもろ書いてあるメイン処理テンプレートソース
用意してコレ使えという。
528:デフォルトの名無しさん
05/10/24 23:32:53
要するにAOPは使いたくないってこと？
529:デフォルトの名無しさん
05/10/25 00:27:49
トランザクションだけはコードで書きたい。
530:デフォルトの名無しさん
05/10/25 09:47:45
テンプレートを使うやり方ってtransactionScriptみたいなヤツ？
あれって複数Daoに更新命令メッセージ渡したい時にうまくasid守れるのだっけ？
ドアホな質問だったらｽﾏｿ
>>529
自作インタセプタでAOPするのも嫌なの？
531:デフォルトの名無しさん
05/10/25 10:35:43
ACID
532:530
05/10/25 11:30:31
し、しまった、ゴメン恥sage
533:デフォルトの名無しさん
05/10/25 21:41:41
Seasarを選ばなかったおまいらは非国民
534:デフォルトの名無しさん
05/10/25 21:55:08
日本で作ったところくらいしか、とりたてて特徴がないからなぁ。
逆にSeasar選ぶのは国粋主義だとは言える。
535:デフォルトの名無しさん
05/10/25 23:30:51
>>530
>>インタセプタ
それならいいかも。コードかけるから。
536:デフォルトの名無しさん
05/10/26 01:28:04
>>534
国粋主義が悪いかのように匂わす藻舞は共産主義者
537:デフォルトの名無しさん
05/10/26 01:34:42
>>536
ウヨ厨発見。
「国粋主義」ってそもそも悪口だし。悪いに決まってる。
538:デフォルトの名無しさん
05/10/26 10:14:29
Javaが日本発な言語でない以上、
Seasar2もSpringもその意味では五十歩百歩だろ。
使いやすい方使えばいいのよ。
539:デフォルトの名無しさん
05/10/26 13:35:27
>>534
どっちがいいのかは個人の判断だと思うけど､
かなり違うよSpringとSeasarは。
特徴がないと思っているのは単なる勉強不足。
540:デフォルトの名無しさん
05/10/26 16:42:29
>539
で、両者の顕著な違いってどの辺り？
軽量DIコンテナ+AOPサポートって言う
コアな考え方が同一な以上、
枝葉は多少異なるだろうけど、
幹の部分は大差なく感じるんですが。
それぞれのサブプロジェクト(MVCフレームワークとか)は
モデルが大きく異なるだろうけど、限りなく枝葉な問題だし(私には)。
そこの違いがでかいんだよと言われると、大変困るが。