Java Spring Frameworkを語るスレ

1 名前：デフォルトの名無しさん mailto:sage [04/02/23 00:51] www.springframework.org/ 乱立するフレームワークと競合するプロトコルの嵐のなかで、 リスクの高い決断を余儀なくされているJavaデベロッパ、プ ロジェクトマネージャに対する福音です。 語るべし。 403 名前：デフォルトの名無しさん mailto:sage [2005/05/17(火) 08:11:38 ] >>402 HttpServletを継承していない普通のクラスが、 /WEB-INF/なんて、HTTP固有のディレクトリ構造に 依存することを良しとする訳ですか。 404 名前：デフォルトの名無しさん mailto:sage [2005/05/17(火) 08:46:55 ] 基本的には普通のクラスはDIコンテナの存在を気にしないようにするね。 405 名前：デフォルトの名無しさん mailto:sage [2005/05/17(火) 08:47:10 ] Servletクラスは絶対パスを取得できるので、そのパスをもらえばいいのでは？ 406 名前：デフォルトの名無しさん mailto:sage [2005/05/17(火) 09:11:58 ] サーブレットからApplicationContext自体をもらえばいいね。 407 名前：デフォルトの名無しさん mailto:sage [2005/05/17(火) 14:22:24 ] FileSystemXmlApplicationContextではだめかいな？ 408 名前：デフォルトの名無しさん mailto:sage [2005/05/17(火) 17:29:46 ] 皆さんどうもありがとうございます。 >>403 /WEB-INF/data にアプリが使うデータファイル置くのは一般的に言って変ですか？ /dataでもいいので普通はそうなら変更を考えます。まだ作法に慣れてないもので勉強します。 >>404 そのクラスは相手がDBじゃなくてファイルなんですがDaoと同じ様な役割をさせたいクラスなんで 他のDaoクラスと同じようにDIコンテナからロードさせてるんですよ。 で、Servletとか関係ない層で動いてるんですが実際のパス取得をどうしようかと悩んでます。 Springのフレームワークからそういうのとれないのかなと考えてましたが、的違いでしたでしょうか？ >>405-407 結局Servletクラスからパスをもらうことにしました。 正直に言ってまだ釈然としないものが残っているんですが、一般的にそうなら慣れるしかないですね 409 名前：デフォルトの名無しさん mailto:sage [2005/05/17(火) 21:41:41 ] いにしえのServlet/JavaBeans流：jarファイル近辺のPropertiesファイルか取得 　　： J2EE流：JNDIからデータの位置を取得 　　　　　 Connectorアーキテクチャでデータを供給 　　： Spring Framework： ？ 410 名前：デフォルトの名無しさん mailto:sage [2005/05/17(火) 22:37:48 ] >>408 ふつうは、普通のクラスはDIコンテナの存在を気にしないでいいようにする 411 名前：デフォルトの名無しさん mailto:sage [2005/05/17(火) 22:39:07 ] >>408 設計が悪いときに無理をしないといけないのは一般的な話だから気にするな。 412 名前：デフォルトの名無しさん mailto:sage [2005/05/17(火) 23:28:33 ] >>409 BeanFactoryから取得 413 名前：デフォルトの名無しさん mailto:sage [2005/05/17(火) 23:41:41 ] BeanFactoryはどこからファイル所在を取得するつもり？ 414 名前：398 mailto:sage [2005/05/17(火) 23:59:50 ] 398です。お忙しいとこ何度もすみません。 >>410 ということは、Spring のアプリケーションコンテキストに依存せず、他の（サーブレットを継承していて サーバ環境にアクセス可能な）クラスからもらってくる方法はまだマシという理解であってますか？ >>411 設計が悪いのなら直したいのです。>>409さんが書いている様に、Springやその他のDIコンテナ （すみませんがJ2EE/EJBは知りません）を使ったときの作法があるのなら、この機会に 身に着けたいと思ってます。普通のクラスが外部リソースにアクセスする一般的な方法を 教えてもらえませんか？ 415 名前：デフォルトの名無しさん mailto:sage [2005/05/18(水) 00:17:47 ] >>413 そりゃサーバサイドだったら、web.xmlじゃないか？ JNDIだってどっかにJNDIのInicialContextFactoryを指定する（プロパティとか）のと同じ事だとおもうけど。 416 名前：デフォルトの名無しさん mailto:sage [2005/05/18(水) 00:44:57 ] つまり、根っこはプロパティ 417 名前：デフォルトの名無しさん mailto:sage [2005/05/18(水) 00:45:37 ] web.xml使うのは、Servlet層だけの簡単アプリ 418 名前：デフォルトの名無しさん mailto:sage [2005/05/19(木) 06:47:36 ] DIしたオブジェクトから先は、いもづる式にDIするようにして、DIコンテナを意識しないとか。 419 名前：デフォルトの名無しさん mailto:sage [2005/05/19(木) 10:10:35 ] >>418 最初は芋づる式って密な感じがして気持ち悪かったけど 実装してみたら楽すぎて止めらんね どういった点でデメリットが出てくるんだろうか 420 名前：デフォルトの名無しさん [2005/06/01(水) 08:56:52 ] JSF+Springで設計してんですけど JSFのバッキングビーンのクラスとビジネスロジックのクラスのそれぞれの役割で バッキングビーン 値のチェック、変換（この辺はバリデータ、コンバータに 任せるべきなんだろう）などのビジネスロジック呼び出す前の処理 あと、ビジネスロジックの結果の後処理 ビジネスロジック 必要なDAOを呼ぶだけ こんな風に考えてます。これだとビジネスロジックのクラスが たいした役割ではないと思うんですけど、DAOのファサード風と考えてよいでしょか JSF+Springのサンプルアプリがみたいどすえ〜 421 名前：デフォルトの名無しさん [2005/06/01(水) 10:05:15 ] >>420 ＞JSF+Springのサンプルアプリがみたいどすえ〜 https://appfuse.dev.java.net/ https://equinox.dev.java.net/ 漏れ自身が勉強中なので情報提供のみで失礼。 422 名前：デフォルトの名無しさん [2005/06/01(水) 10:47:23 ] >>420 ＤＢのモデルを単に画面に表示する・画面に入力した値をＤＢに格納する みたいなシンプルなアプリだとそうなるかもね。 423 名前：デフォルトの名無しさん mailto:sage [2005/06/01(水) 10:50:24 ] sageついでに ＞ビジネスロジック呼び出す前の処理 ＞あと、ビジネスロジックの結果の後処理 どのレベルの処理を言ってるのかわからないけど、 本当にMVCレイヤに置くべき処理なのか再検討してみては？ 424 名前：デフォルトの名無しさん mailto:sage [2005/06/01(水) 11:58:03 ] この本どうよ？書評ｷﾎﾞﾝﾇ 『実践Spring Framework―J2EE開発を変えるDIコンテナのすべて』 www.amazon.co.jp/exec/obidos/ASIN/4822221431 『入門Spring』と『軽快なJava』は読みました。さらに詳しい話を 聞きたい、という目的に使えますかね？ 425 名前：デフォルトの名無しさん mailto:sage [2005/06/02(木) 22:11:28 ] SpringがJSFとXULをイイ感じに仲介するフレームワーク作ってくれたら 一杯おごってやりたい。 426 名前：デフォルトの名無しさん mailto:sage [2005/06/03(金) 12:15:51 ] >>425 Mozilla独自のXULより標準規格のXFormsのほうが良いのでは？ MozillaもOpenOffice.orgもXFormsに対応する上に、 Chibaを使えばXForms未対応のブラウザに対して HTML+JavaScriptに変換してから送信することで 大部分のブラウザに対応できます。 Chiba (サーバーサイドJavaライブラリ) chiba.sourceforge.net/ MozillaとXForms (Mozilla1.8/Firefox1.1で対応予定) www.mozilla-japan.org/projects/xforms/ [XForms 00031] XFormsのためのwiki (村田真氏がMozillaでXForms推進) www2.xml.gr.jp/log.html?MLID=xforms&N=31 427 名前：デフォルトの名無しさん [2005/06/03(金) 12:41:43 ] >>426 XULへの必要性は一般の人にとっては低いとは思うが、 >>425は、ブラウザベースクライアントじゃなくて、リッチクライアントとして XULを使うことを前提に書いてるんじゃなかろうか。 JSF経由でSwingとかFlashをクライアントにするノリで。 428 名前：デフォルトの名無しさん mailto:sage [2005/06/03(金) 12:42:00 ] sage 429 名前：デフォルトの名無しさん mailto:sage [2005/06/22(水) 09:39:06 ] 禿げオヤジは意外とおとなしかったな。 430 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 15:34:01 ] 海外では50％以上のプロジェクトで使われていて ほぼデファクトスタンダードらしいが、なぜこのスレは伸びないの？ 431 名前：デフォルトの名無しさん mailto:sage [2005/06/25(土) 18:21:20 ] まあ、DIスレも伸び悩んでるし、 カテゴリとしてマイナーなんでは。日本では。 432 名前：デフォルトの名無しさん mailto:sage [2005/06/26(日) 08:56:09 ] >>430 DIは、使い始めれば空気みたいなもんで、とくに議論することもなくなるから。 433 名前：デフォルトの名無しさん mailto:sage [2005/06/26(日) 16:54:53 ] つーかSpringがホントに便利なのって純粋なtype2,type3のInjectionその物より、 コンテナが作ったProxyに対するAOPでしょ？ 434 名前：デフォルトの名無しさん mailto:sage [2005/06/26(日) 22:33:01 ] DIってのは、そういうものを便利にするための裏方だからな。 435 名前：デフォルトの名無しさん [2005/06/27(月) 10:43:51 ] このスレ生きてるみたいだから質問させてくれ proxyでAspectをweavingする事の弱点って何だ？ 漏れが把握しているのは 1.自分自身のメソッドを呼び出すとAspectがかからない。 2.visitorみたくthisを渡して処理させるとAspectがかからない。 他に注意点ある？ 436 名前：デフォルトの名無しさん [2005/06/27(月) 11:31:59 ] ものすごくはらへった。 437 名前：デフォルトの名無しさん mailto:sage [2005/06/27(月) 11:41:45 ] 俺もだ。 438 名前：デフォルトの名無しさん mailto:sage [2005/06/27(月) 13:49:43 ] いまさら同意。 439 名前：デフォルトの名無しさん [2005/07/05(火) 11:09:42 ] 1.2.2リリース記念 440 名前：デフォルトの名無しさん [2005/07/05(火) 13:38:30 ] >>439 どこが変わったの？ 441 名前：439 mailto:sage [2005/07/05(火) 15:43:58 ] 詳しく見てない＆試してないけど、注目した一文は； 『added dedicated support for Hibernate Annotation 3.0 beta 2』 442 名前：デフォルトの名無しさん mailto:sage [2005/07/05(火) 17:36:12 ] >>441 でも、前からHibernate Annotations使えてたよ。 443 名前：デフォルトの名無しさん mailto:sage [2005/07/05(火) 22:32:17 ] つうか、Doclet のことを言ってるんじゃあるまいな。 444 名前：デフォルトの名無しさん mailto:sage [2005/07/06(水) 03:19:27 ] アノテーションってそんなにいいもんなんでしょうか。 DIでせっかくコードから煩雑な記述を追い出したのに、 またコード中に埋め込んで、回帰と言うか退化と言うか。 コンパイラに対する指示を埋め込むのは意義が大きいと思うけど。 445 名前：デフォルトの名無しさん mailto:sage [2005/07/07(木) 10:24:52 ] >>443 ここの最後にやりかた書いてあるよ。 ttp://www.fk.urban.ne.jp/home/kishida/kouza/hibernateanno.html 446 名前：デフォルトの名無しさん mailto:sage [2005/07/07(木) 10:25:46 ] >>444 アノテーションは、XMLより記述が楽だし、ソースから得た型の情報を使うことで記述量自体が少なくできてるから、そう煩雑でもない。 クラスに関する情報をソースファイルに一元化できる効果もある。 なによりコンパイラによる静的チェックが効くし、Javaソースエディタでの補完が効く。 447 名前：デフォルトの名無しさん mailto:sage [2005/07/08(金) 22:00:29 ] DIってテストしやすくなる？ 単体まではいいけど、結合で結局アボーンな感じがするのだけど。 まぁつまるところは設計能力か・・・ 448 名前：デフォルトの名無しさん mailto:sage [2005/07/10(日) 00:55:34 ] アボーンって、具体的にはどういう問題がでてくると思う？ 449 名前：デフォルトの名無しさん [2005/07/13(水) 20:03:02 ] TransactionProxyFactoryBeanにtagetってフィールドがあるんですけど、これシングルトンなんです。 マルチスレッドでここに処理が殺到した場合、スレッドセーフにトランザクションさばけるんでしょうか？ 教えてください。 TransactionProxyFactoryBean www.springframework.org/docs/api/org/springframework/transaction/interceptor/TransactionProxyFactoryBean.html 450 名前：デフォルトの名無しさん mailto:sage [2005/07/13(水) 20:42:56 ] >449 そりゃ、targetしだいだろ。targetがスレッドセーフなら、問題ない。 451 名前：名無しさん [2005/07/13(水) 21:00:03 ] 同時に異なるスレッドの異なるtargetがシングルトンのTransactionProxyFactoryBeanにセットされにきたらどうなりますか？ 452 名前：デフォルトの名無しさん mailto:sage [2005/07/13(水) 23:18:19 ] オブジェクトの数とスレッド数は別ものとして考えないと。 ちゃんと考えられてるだろうから、 単一のオブジェクトの同じメソッドを 複数のスレッドが並行して駆け抜けることは全然OKなように つくられてるはず・・・（たぶん） 453 名前：デフォルトの名無しさん mailto:sage [2005/07/14(木) 16:28:52 ] 蒼ざ(ry 454 名前：デフォルトの名無しさん [2005/07/14(木) 19:22:10 ] どうやらtargetもシングルトンじゃないとダメみたいですね。 455 名前：デフォルトの名無しさん [2005/07/16(土) 17:28:30 ] >>462 それはプラットフォームによる。 ・GUIは大抵そう。(OSから飛んでくるイベントの処理は、イベント毎の状態保持が必要。 　　　　　　　　　　　 もっとも、同じ要素に複数イベント飛んできたら、単に順次処理する事が多いんで、 　　　　　　　　　　　 本当のスレッド並列処理はそんなに必要ないと思う。) ・Webアプリ周りも大抵そう。(例の(Statefull)Servletあたりが有名) それ以外の場面で、常にインスタンスとスレッドを別に考えるのは、どーかと思う。 結局インスタンス数を減らしてまでメモリー消費を避けたい特殊な場面(大規模アプリ、組込みアプリ) に固有のやりかただと思う。 456 名前：455 mailto:sage [2005/07/16(土) 17:30:24 ] ああ>>451-452の流れか。>>455は取り消し(ワラ 457 名前：デフォルトの名無しさん mailto:sage [2005/07/19(火) 10:34:04 ] というか誰にレスしてんだ 458 名前：デフォルトの名無しさん [2005/07/24(日) 22:38:13 ] これが最近有名なJSFって奴ね。 Javaは最新の技術追うのが大変（＠＠） 459 名前：デフォルトの名無しさん mailto:sage [2005/07/25(月) 01:15:53 ] ============================== キチガイが狂った独り言を書き込み中 ============================== 460 名前：デフォルトの名無しさん mailto:sage [2005/07/25(月) 07:37:48 ] >>441 applicationContext.xmlの中でHibernate Annotationsの設定がかけるようになるってことみたいだね。 LocalSessionFactoryBeanを使う場合は、hibernate.cfg.xmlを書いておく必要があった。 461 名前：デフォルトの名無しさん mailto:sage [2005/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 mailto:sage [2005/08/08(月) 00:45:20 ] 事故解決しますた。orz 463 名前：デフォルトの名無しさん mailto:sage [2005/08/08(月) 01:32:41 ] いちお、解決方法きぼんぬ 464 名前：デフォルトの名無しさん mailto:sage [2005/08/08(月) 12:18:04 ] 今度は aopallience がねえよって怒られて それを修正したとかそんな流れ？ 465 名前：461 mailto:sage [2005/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 名前：デフォルトの名無しさん mailto:sage [2005/08/08(月) 20:27:13 ] >>464 だいたいあってたね。 467 名前：デフォルトの名無しさん [2005/08/10(水) 12:47:00 ] だいたいってことは、正確にはどーすればよいわけ？ 468 名前：デフォルトの名無しさん mailto:sage [2005/08/10(水) 20:51:17 ] CGLIB とかのライブラリは Spring 付属の jar をぶっこんだ？ まだ 1.1.7 使ってて 1.2 系は試してないけど 付属の jar 入れとけば間違いは少ないと思う。 469 名前：461 mailto:age [2005/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なんで、 ttp://prdownloads.sourceforge.net/cglib/cglib-2.1_2.jar?download ttp://forge.objectweb.org/project/download.php?group_id=23&file_id=3084 のミラーからDLしてください。 …というコトではない？ 470 名前：デフォルトの名無しさん mailto:sage [2005/08/10(水) 21:14:42 ] with-dependency の方のディストリビューション落とせば 添付の jar を必要に応じて加えるだけで 外部のライブラリは不要だったと思うんだけど。。 471 名前：461 mailto:sage [2005/08/10(水) 21:47:00 ] >>470 ｻﾝｸｽ。 >with-dependency こっちじゃなくて、spring-framework-1.2.3.zip落としちゃって…。 ttp://www.techscore.com/tech/Others/Spring/1.html にしっかり書いてありました。orz 472 名前：デフォルトの名無しさん mailto:sage [2005/08/19(金) 12:55:20 ] Spring Beans XML Editor (Spring IDE for Eclipse) ttp://springide.org/project/wiki/BeansXmlEditor Screen Shot 見る感じだと とりあえず欲しい機能は結構揃っているような。 473 名前：デフォルトの名無しさん mailto:sage [2005/08/25(木) 16:33:37 ] www.springframework.org/springide/release-123 474 名前：デフォルトの名無しさん [2005/09/07(水) 09:38:35 ] KingはRodが大嫌いなんだとさw houseofhaug.net/blog/archives/2005/08/12/hibernate-hates-spring/ 475 名前：デフォルトの名無しさん mailto:sage [2005/09/07(水) 09:53:15 ] Hibernate3 でトランザクション周りが結構変わって、 Spring とかなり方向違うなぁと感じたりはする。 Hiernate の Session Factory から getCurrentSession() 呼んだら 思いっきり怒られたりとか。 JTA が必要だったとは知らなかった。 なんかそんなことが続いてる。。 476 名前：デフォルトの名無しさん mailto:sage [2005/09/13(火) 23:10:59 ] Springを勉強してます。 サーブレットにDIしたいクラスのsetter作って 動かしてみたのですが、NullPointerException... サーブレットではsetterインジェクション(?)できないんですか？ ContextからgetBeanすれば普通にとれるんですが。。 477 名前：デフォルトの名無しさん mailto:sage [2005/09/14(水) 00:14:32 ] >>476 普通はBeanにsetter/getter作るでしょ。 むしろ、setter/getter作ると自然にBeanになる。 MVCからやり直s（ry 478 名前：デフォルトの名無しさん mailto:sage [2005/09/14(水) 00:27:50 ] >>476 サーブレットでDIするためにどういう設定したの？ 479 名前：デフォルトの名無しさん mailto:sage [2005/09/14(水) 00:40:33 ] >476 Webコンテナが管理しているサーブレットインスタンスを そのサーブレットが呼ばれる前に，アプリ側から取得する方法があるとでも？ 480 名前：デフォルトの名無しさん mailto:sage [2005/09/14(水) 01:39:52 ] しかし、いろんなこと考える奴がいるもんだな・・・ある意味感心したw 481 名前：デフォルトの名無しさん mailto:sage [2005/09/14(水) 02:41:41 ] >>479 web.xmlにはプロキシサーブレットを登録して、そのときパラメータで実際のサーブレットクラスを指定するような実装にすればできんでもない。 482 名前：476 mailto:sage [2005/09/15(木) 01:29:23 ] >>477-481 勉強不足でごめんなさい。 サーブレットからビジネスロジックを呼び出すのに 自分でビジネスロジックのインスタンスを作らずに、 setterを作って、ビジネスロジックをDIしようとしたのですが。。。 やっぱり無理なんですかね？ 483 名前：デフォルトの名無しさん mailto:sage [2005/09/15(木) 02:32:53 ] >>482 便乗してTapestryの宣伝でもしてみるか。 Tapestry-4.0だと、それに相当する事が出来るようになってる。 Tapestry-4.0自体はDIコンテナにHiveMind使ってるけど、 HiveMindとSpringを連携させる方法もあるので、 Springで管理してるオブジェクトをTapestryのページや コンポーネントにDIすることできて便利。 484 名前：デフォルトの名無しさん mailto:sage [2005/09/15(木) 03:15:06 ] >>483 日本語のドキュメントはどこにありますか？ 485 名前：デフォルトの名無しさん mailto:sage [2005/09/15(木) 16:21:13 ] あなたはいぢわるな人だ 486 名前：デフォルトの名無しさん [2005/09/19(月) 09:44:33 ] で、実際に開発で使ってる実績ってあるの？ Spring。 487 名前：デフォルトの名無しさん mailto:sage [2005/09/19(月) 09:47:35 ] 何をもって実績と呼ぶかを定義しないと そりゃどっかで使ってるさ。で終わってしまう。 488 名前：デフォルトの名無しさん [2005/09/19(月) 19:12:43 ] どっかって・・・。 どこでも使ってないんじゃないの、と思ってるんだが。 489 名前：デフォルトの名無しさん mailto:sage [2005/09/19(月) 20:59:49 ] おれんとこの現場は使ってる 490 名前：デフォルトの名無しさん mailto:sage [2005/09/19(月) 21:06:20 ] >>488 そうかもね。 というか、DI自体にメリットというか魅力を感じない。 いや、考え方とかそういったのは素晴らしいと思うよ。 だけど、実際には客先にコストダウンとかのメリットがある訳じゃないし、 実行速度が上がるわけじゃない。 まぁ、テストを簡単に行えて品質は上がるのかもしれない。 だけど、問題は、DI使ったからといって、修正とかが楽になるかと言えば、答えはNO。 大抵の修正はメソッドの呼び出しとか、そういったものまで結構変更になる。 なのに、下手にDI使ってインターフェースとか定義してたら、 結局インターフェースもクラスも関連するもの全部修正しないといけない。 つまり、殆どの場合、DI使うことにより、修正の手間は倍以上になる。 作る時に、無駄ともいえるものを作るんだから、下手したら4倍近い手間。 世間がこれからどうなるか知らないが、すくなくても俺の会社では DIは明示的には使わないという方向で決まった。 （ライブラリの内部とかで使われてるとかは知ったこっちゃ無い） 491 名前：デフォルトの名無しさん mailto:sage [2005/09/19(月) 22:21:44 ] インターフェイスをきるときには、システム将来計画等から予想して、 ある程度変更になりそうな部分を見極めとかないと意味は無い DIか否かより、結局は設計の問題になると思うけど 492 名前：デフォルトの名無しさん mailto:sage [2005/09/19(月) 23:06:57 ] >>490 君の言ってることはDIとは直接関係ないかなぁ。 単にインターフェースへのプログラミングってやつの是非を語っているだけではないのか？ まぁ、それも確かに賛否両論よく議論されているネタだけどね DI使うと部品作って組み立てるプロセスが面白くて、楽しく開発は出来るんだけど、 アホには使いこなせないからあまりポピュラーにはならないかもしれない 493 名前：デフォルトの名無しさん [2005/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 名前：デフォルトの名無しさん [2005/09/20(火) 00:11:05 ] あーーすみません エラーメッセージがまちがっていました。。 javax.servlet.ServletException: Neither Errors instance nor plain target object for bean name 'user' available as request attribute 495 名前：デフォルトの名無しさん mailto:sage [2005/09/20(火) 01:41:00 ] まだ490みたいなこと言う人居たのか。すげえな。世の中って。 496 名前：デフォルトの名無しさん mailto:sage [2005/09/20(火) 02:29:53 ] MVC フレームワーク使ったことないんで (Viewは絶対にVelocityが良い派。 コントローラはStrutsがベタ打ちっぽくて好き派。) 大きく外してるかも知れませんが ttp://64.233.179.104/search?q=cache:LDvUSmAKRi8J:xlegend.dip.jp/~hamasyou/archives/Engineer-Soul/springframeworkneooiaieaadiiocmvcweb.php+spring.bind+ServletException+Neither+instance&hl=ja ＞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 名前：デフォルトの名無しさん mailto:sage [2005/09/20(火) 20:30:51 ] >>495 そうでもないんじゃない？ 実際、ある程度予測できる範囲やちょっとした修正なら、DIだろうが何だろうが修正は簡単。 だけど、大抵の場合って、そもそもの仕様から引っくり返されるんだよね。 『ごめん。やっぱりこの機能も追加して』って一言で。 そうなると、確かに>>490の言うような状態に陥る。 498 名前：デフォルトの名無しさん mailto:sage [2005/09/21(水) 01:34:49 ] インターフェース直して、テストコード直して、実装直す。 簡単ジャマイカ 499 名前：デフォルトの名無しさん mailto:sage [2005/09/21(水) 01:44:41 ] >>497 顧客の「やっぱり」が予想できる場合と出来ない場合で違うと思う 予想できない場合は、たとえどんな作り方をしてても無駄なわけだし 500 名前：デフォルトの名無しさん mailto:sage [2005/09/21(水) 03:19:34 ] DIの肝って、「実装を交換できる」ってこと。 あとは想像力さえあれば、大抵の状況は、インターフェイスの修正無しになんとかできるはずだが。 まぁ、インターフェイスの設計がへぼいとどうにもならない場合があるけど。 501 名前：デフォルトの名無しさん mailto:sage [2005/09/21(水) 05:36:55 ] べつに、実装交換しなくても便利なんだけど。 実際のアプリケーションでDIでつなげたクラス同士を切り替えることなんてほとんどない。 それでも、つなげることをやってもらえるだけで便利。 502 名前：デフォルトの名無しさん mailto:sage [2005/09/21(水) 23:44:25 ] >>501 コードでつなげる処理を書くよりも便利なの？ やっぱり自分で試して体感してみるしかないかな。 503 名前：デフォルトの名無しさん mailto:sage [2005/09/22(木) 06:51:23 ] 自分でさわらずに批判してもしかたないよ。

---

---

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

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