Java Spring Framewor ..
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フレームワークとか)は
モデルが大きく異なるだろうけど、限りなく枝葉な問題だし(私には)。
そこの違いがでかいんだよと言われると、大変困るが。
541:デフォルトの名無しさん
05/10/26 16:59:35
ロジックとかDAOを呼び出すだけで使ってる分にはあまり差を感じないけどな。
542:デフォルトの名無しさん
05/10/26 17:18:39
>>540
DIだとあまり変わらないかもね。
ただ、Seasarの新しいバージョンだと､DIが結構変わったみたい。
XMLはほとんど書かないらしい。
AOPは結構違う。
JavaWorldに出てたけど､同じAOP AllianceのAPIにもとづいているとは
思えないくらいに設定の仕方が違う。
543:デフォルトの名無しさん
05/10/26 20:24:41
設定方法なんか、どうだってなるわけだが。
544:デフォルトの名無しさん
05/10/27 00:49:30
DIやAOPよりも、自前でJTA実装用意してるかどうかが大きい気がする
Tomcatやローカルアプリに対して、安定したJTA環境＋AOPによる宣言トランザクションを提供出来るというのが
自分から見たS２の売りかな？
Springも外部のJTA実装を用意すれば一緒なんだけど、出来ればSpring内で実装まで用意して欲しい
545:デフォルトの名無しさん
05/10/27 09:37:46
ん〜、煽りじゃなくて教えて欲しいのだが、自前JTAってそんなにいいの？
どうせAP鯖上で動くならそのAP鯖のJTA使えばいいと思う。
つっか、AP鯖のJTA使うと、提供されている管理画面を
使えちゃったりして便利なんだよね。使用状況とか一目瞭然だし。
546:デフォルトの名無しさん
05/10/27 11:05:18
>>545
> どうせAP鯖上で動くならそのAP鯖のJTA使えばいいと思う。
AP鯖ならそれ使えばよろし。
「Tomcatやローカルアプリ」の場合の話。
547:デフォルトの名無しさん
05/10/27 11:50:06
JOTMとか?
というか部品を用意してあるかどうかなんて些細な差と言うか、
そもそも比較項目にすらならん気がする。
224 にも張られた内容見るといろいろ差があるなとは思う。
結局AOPに対するアプローチが一番の違いか？
Spring はどこまでも POJO マンセーな感じ。
良い意味でも悪い意味でも。
548:デフォルトの名無しさん
05/10/27 12:38:18
>>547
JTA実装するかしないかの差は、両者のトランザクション管理に対する考えの違いでもある。
JTAを標準としてJDBCトランザクションを排除していこうとしてるのがS2
JDBCもJTAも、DIコンテナがラップして利用者に統一的に使って貰おうとしてるのがSpring
549:デフォルトの名無しさん
05/10/27 12:39:51
>>547
POJOマンセーはSeasarのほう。
Springには、何かしたかったら､こういうインターフェースを実装しろ
というのがいろいろあるけど、Seasarはそういうのがほとんど無い。
550:デフォルトの名無しさん
05/10/28 01:25:53
jsfを使うんだけどspringはどの段階で作り始めればいいんですか？
ある程度jspとかbeanとか決まってから？
551:デフォルトの名無しさん
05/10/28 09:21:16
>>550
君の脳内が整理されたら。
552:デフォルトの名無しさん
05/10/28 10:56:12
Spring 自体は作らんだろ。作らんよね？
Spring 自体は作りませんね。
553:デフォルトの名無しさん
05/10/28 14:25:10
そんなレスはいらんねん
554:デフォルトの名無しさん
05/10/28 18:52:00
なんかすごいヤシが来たな、ﾜｸﾜｸ
555:デフォルトの名無しさん
05/10/30 17:47:22
(・∀・)ﾊｲｰｷｮ
556:デフォルトの名無しさん
05/10/30 21:02:51
>>555
気が早いよ。ヽ(`Д´)ﾉ
もう少しまってろ。
557:デフォルトの名無しさん
05/10/31 01:27:45
保全
558:デフォルトの名無しさん
05/10/31 14:31:11
ところで、Springを使ってサービスを２つ起動しているけど
片方のサービスを止めたり、動かしたりする場合のサンプリングが解らず・・・・
筆不精で表現が不十分ならすまん・・・。
559:デフォルトの名無しさん
05/10/31 14:49:38
>>558
サービスとSpringは直接関係ないだろ。
560:デフォルトの名無しさん
05/10/31 14:50:21
つうか、サンプリングって新しいな、おい。
561:デフォルトの名無しさん
05/11/01 13:36:58
統計やってるんだろう
562:デフォルトの名無しさん
05/11/01 14:30:30
springとhibernateを使ってるのですが、以下のようなコードでDBからデータを取得した時に
ログ情報はどうやって出すのでしょうか？
出したい情報としては、どのテーブルに、どんな条件で取得or更新処理等を行っているかです。
SQLの場合は、SQLそのものをログに出せば良かったのですが、spring+hibernateになった場合
SQLの時と同等の内容をログに出力する方法が分からなくなってしまいました…。
Hoge hoge = (Hoge)getHibernateTemplate().get(Hoge.class, primaryKey);
このgetの中でやっている事をログに出したいです。
563:デフォルトの名無しさん
05/11/01 19:08:20
Hibernate の設定でログにSQLを吐くってのがあったはず。
564:デフォルトの名無しさん
05/11/02 00:43:48
springの設定でhibernatePropertiesに
<prop key="hibernate.show_sql">true</prop>
を設定
565:デフォルトの名無しさん
05/11/02 10:31:05
>>563,564
ありがとうございます！
おかげさまで、SQLは出力されるようになったのですが、
出力されるSQLのWHERE句の条件部分が、実際の値に置換する前の「？」に
なってしまいます….
この「？」の部分が実際の値に置換された状態のSQLを出力する事は出来ないのでしょうか？
566:デフォルトの名無しさん
05/11/05 20:04:59
さっぱり関係ないんだけど、PreparedStatementに値が入れられた後のSQLを
吐き出させられないかと思うことはよくあるな。
567:デフォルトの名無しさん
05/11/05 20:42:17
DB側でログだすしかないね。
JDBC4でやってくれないのかなぁ
568:デフォルトの名無しさん
05/11/06 00:19:10
そもそもJDBC内で完全なSQL生成してるわけじゃないから無理だよな。
そんなことしてたらPrepareStatement意味ない。。
569:デフォルトの名無しさん
05/11/06 01:52:33
なんかのクラスのログレベルを下げれば、
どんなパラメータを入れたか確認できるけど一応。
どのクラスかは会社に居ないので確認できましぇん
570:デフォルトの名無しさん
05/11/06 15:24:20
Spring + Hibernate3 でテストしてた時は
パラメータも表示されてたと記憶してるが。
571:デフォルトの名無しさん
05/11/07 09:55:19
ドライバにトレースオプションとか無いの?
572:デフォルトの名無しさん
05/11/08 01:15:17
>>566
p6spyってのを使えばできるらしいよ。
573:sage
05/11/13 01:07:52
SpringWebMVC使ってるんだけど、
フォーム上の二つの入力フィールドの値を、
コマンドオブジェクトの一つのプロパティにBindすることってできないんだろうか？
574:デフォルトの名無しさん
05/11/13 01:12:45
JavaScriptFrameworkかとおもた
575:デフォルトの名無しさん
05/11/13 13:14:15
よし、今からSpringを勉強するよ。
指示をくれ
とりあえずダウンロードしてくるわ
576:デフォルトの名無しさん
05/11/13 13:35:02
spring-framework-1.2.5-with-dependencies.zipをダウンロードして
Eclipseに展開
その間に
URLﾘﾝｸ(www.atmarkit.co.jp)
これを読んでる
577:デフォルトの名無しさん
05/11/13 13:39:20
なにこれ？
あほですか？
ただ、指定のクラスを生成して、ついでにプロパティも入れるというだけ？
くだらん。
ただのFactoryじゃん。
messageを生成時に注入してHello World!かよ。
おめでてーな。
まあ、記事が馬鹿だということを予想して付属のSampleためしてくるよ。
578:デフォルトの名無しさん
05/11/13 13:43:19
>> Spring Frameworkで理解するDI（1）
(2)は、まだー？
579:デフォルトの名無しさん
05/11/13 13:53:10
>>578
もちろん1,2,3を読んでの感想ね。
いま、ExampleのCountryを読んでるんだけど、
いきなりソースを読んでも意味わからんわ。
それぞれのクラスが他に依存しないってことは
Utilを読むみたいに、いきなり読めるってことかと思ってしまった。
今から/samples/countries/*.txtを読んでデプロイして実行してみる。
580:デフォルトの名無しさん
05/11/13 14:08:34
日本用のpropertiesがないからぬるぽい。
適当になぶる
581:デフォルトの名無しさん
05/11/13 14:59:14
解説しよう
なぶる ＝ 触る
582:デフォルトの名無しさん
05/11/13 16:09:48
解説ありがとう
今から外出しないといけなくなった
とりあえずどんな実装をしていくかという
癖みたいなものはわかった。
出たついでに本屋にでも寄って理論を立ち読みしてくるわ
583:デフォルトの名無しさん
05/11/13 18:13:33
ぬるぽ
584:デフォルトの名無しさん
05/11/13 22:40:28
帰ってきたよ
理論読んでくるの忘れたから、検索するわ
あとで
585:デフォルトの名無しさん
05/11/17 20:48:05
1.2.6記念
586:デフォルトの名無しさん
05/11/28 11:55:56
閑古鳥だな
587:デフォルトの名無しさん
05/11/28 12:00:14
DIは結局流行り物だってこった。
DIスレもSeasarスレも活気ないしな。
588:デフォルトの名無しさん
05/11/28 12:06:55
需要は大いにあるけど、
言語レベルでの制約によるメリットが一部損なうことや、
リファクタリングがかなりし難くなるところがやはり気に食わないな。
589:デフォルトの名無しさん
05/11/28 12:33:48
DIコンテナがなくても
SetterInjectionとFactoryでいいけどさ。
AOPと親和力が高いのが魅力的だよね。
抜け出せない。
遅いのに。
590:デフォルトの名無しさん
05/11/28 13:15:50
つか、もうEJB3でおけ
591:デフォルトの名無しさん
05/11/28 13:18:05
でも「EJB？ﾊｧ？これからはSpringだろ」
てのを受けて試しにSpring触って第一印象が>>577ってパターンが結構多い気がするな。
592:デフォルトの名無しさん
05/11/28 20:17:43
フロントしか弄ってない俺には、Strutsの焼き直し。
593:デフォルトの名無しさん
05/11/28 21:17:10
今って分散環境だとビジネスロジックには
何が一番使われてんの？
594:デフォルトの名無しさん
05/11/28 21:21:10
あ、これじゃいみわかんねえや
モデルだった
595:デフォルトの名無しさん
05/11/28 22:32:06
>>592
Strutsとは全くかぶってないので、StrutsをどうやきなおしてもSpringにならない・・・
596:デフォルトの名無しさん
05/11/28 22:33:25
>>595
フロントコントローラ、まんまStrutsなんだが。
597:デフォルトの名無しさん
05/11/29 00:09:53
これってどこがいいの？
XMLからクラスが生成できるだけ？
598:デフォルトの名無しさん
05/11/29 00:22:41
>>595
次の次ぐらいのStrutsはWebWorkになるそうだぞ。
599:デフォルトの名無しさん
05/11/29 00:25:00
ん？IDEと統合するのを目標に作られたJSFがあるからそれはないべ？
600:デフォルトの名無しさん
05/11/29 00:34:16
>>599
ほれ。
URLﾘﾝｸ(www.mail-archive.com)
601:デフォルトの名無しさん
05/11/29 00:37:30
もうひとつ。
URLﾘﾝｸ(blogs.opensymphony.com)
スレ違い。失礼。
602:デフォルトの名無しさん
05/11/29 00:42:46
>>600-601
えーーーー。
なんかすっげー違和感・・・。
603:デフォルトの名無しさん
05/11/29 12:19:40
>リファクタリングがかなりし難くなる
なるか？
設定ファイル書き直しの手間が云々って意味？
604:デフォルトの名無しさん
05/12/01 20:40:22
SpringFrameworkのDefaultIntroductionAdvisorと
DelegatingIntroductionInterceptor の使い方がやっと分かった。
AOPヽ(´ー｀)ノﾏﾝｾｰ
605:デフォルトの名無しさん
05/12/06 10:25:25
使う場所を見つけるまでがAOPです
606:デフォルトの名無しさん
05/12/08 08:03:22
AOPとDIと、どっちが偉いの？
607:デフォルトの名無しさん
05/12/08 08:41:40
別々の話だから、比べてもしかたない。
608:デフォルトの名無しさん
05/12/08 09:35:46
どっちも偉くはないですが
609:デフォルトの名無しさん
05/12/10 23:50:35
URLﾘﾝｸ(muimi.com)
SpringのHello Worldでどのサイトをみても
これ以上のことがどこも書いていないのですが
どういった点が優れているのでしょうか？
いまいちこのフレームワークが他よりも優れいているというメリットが見えないのですが
また具体的に何が得意とかあるのでしょうか？
610:デフォルトの名無しさん
05/12/11 01:16:39
他ってなんのことを言ってるの？
611:デフォルトの名無しさん
05/12/11 15:13:00
みなさん実際に実務だとどんなところにSpring使ってます？
全面的に使ってたりする？
612:デフォルトの名無しさん
05/12/11 15:47:19
Springは使うなら全面的だろ。
613:デフォルトの名無しさん
05/12/11 15:49:33
>>612
大根としてつかうだけならどこか１部だけでもOKでは。
614:デフォルトの名無しさん
05/12/11 16:10:46
>>613
たとえばStruts使う場合だと、すべてのActionをSpringに委譲するし。
615:デフォルトの名無しさん
05/12/11 16:14:12
>>614
具象オブジェクトの生成部分を切り出す単位って、そこしかないわけか
オイ？ﾓｯﾄどこにでもあるでしょうがよ。
616:デフォルトの名無しさん
05/12/11 16:20:57
？？？
617:伝説新人タクシ
05/12/11 16:23:20
>>609
疎結合であるとかそれによって単体テストがしやすいとかいうこと？
618:デフォルトの名無しさん
05/12/11 17:11:40
Springわかんなかったんなら、EJB3を待ってたほうがいいかもね。
619:デフォルトの名無しさん
05/12/11 17:54:34
予習でやるならともかく、今の流れだと、これから本格的にSpring使うってのはなしなきがするな。
だから、逆に絶対やっといても損はない気がするけどさ。
620:デフォルトの名無しさん
05/12/12 10:29:59
そんな難しいものじゃないし、画期的な機能に満ち溢れているわけでもないよ。
ただ単に便利なツールでいいのだと思うけど。
便利なBeanFactory、それで充分だよ。
おまけで付いてくる付属品はけっこういいよ。
AOPもそうだし、ORMやらmailやらが楽チンに扱えるのも嬉しい。
S2でもSpringでもどっちでもいいけど、これがない世界には戻りたくないね。
EJB3があれば不要という話もあるね、GabinKingが主張しているように。
でもSpringを通してEJB3を使った方がより簡単、そういう機能が出てくるって予想してる。
621:デフォルトの名無しさん
05/12/12 10:36:16
というか、普通のTomcatで動かせて面倒なパッケージング不要なEJB3、みたいな感じになると思う。
622:デフォルトの名無しさん
05/12/12 10:36:44
追伸：煽るワケじゃないが、Springごときを理解できない方が
EJB3を使いこなせるとは思えない。Annotationの裏で
起こっている出来事を多少は理解している必要はある、って
認識の元の考えだけど。
623:デフォルトの名無しさん
05/12/12 10:58:46
Springってかなり裏方的な働きだから、単体ではよさがわかりにくいんだと思う。
EJB3でも、単にORマッピングだという認識で、なんだか裏側で勝手に結びつけてくれるという感じになるんじゃないかな。
624:デフォルトの名無しさん
05/12/12 16:27:03
EJB3 って来ると思う？
Java ソースにアノテーション埋め込むのと
設定ファイルに外出しされてるのと
どっちが疎結合か考えたら
EJB3 は退化してるとしか思えない。
625:デフォルトの名無しさん
05/12/12 18:56:40
アノテーションで疎結合じゃないという話は、すでに時代遅れだし、EJB3が来ないと思うなら、別の部分で批判しないといけない。
626:デフォルトの名無しさん
05/12/12 19:05:38
簡単に理由をいえば
「疎結合のためにアノテーションを排除して、なんの意味がある？」
627:デフォルトの名無しさん
05/12/12 20:42:36
ﾌﾟｹﾞﾗ
おまいらどうせ来年にはAnnotationに文句垂れてると思うよ、飽きっぽいから。
628:デフォルトの名無しさん
05/12/12 21:45:25
>>627
いや、それはそれで良いんじゃねぇの？
不満がなければ技術革新なんてねぇさ。
629:デフォルトの名無しさん
05/12/12 21:58:43
Annotationの仕様には不満があるけど、Annotation自体はとても気に入ってるよ。
630:デフォルトの名無しさん
05/12/12 22:25:06
Springで簡単なWebアプリを作るサンプルがあるサイトしらない？
WebApplicationContextを使って云々みたいな。。。
631:デフォルトの名無しさん
05/12/12 22:28:53
Struts使った方が楽だからねぇ・・・
632:デフォルトの名無しさん
05/12/12 22:53:59
AnnotationとEnumの組み合わせが好きだな
XDocletとは違って定数を指定できるし、引数の型チェックも出来る
633:デフォルトの名無しさん
05/12/13 02:02:54
StrutsよりもJSFをもう少し簡単にした物を使いたい
634:デフォルトの名無しさん
05/12/13 09:39:22
>>630
ほらよ
URLﾘﾝｸ(www-06.ibm.com)
URLﾘﾝｸ(www5f.biglobe.ne.jp)
URLﾘﾝｸ(appfuse.dev.java.net)
URLﾘﾝｸ(equinox.dev.java.net)
勧められるのは、ビジネスロジックレイヤ内にサービスレイヤを
作ってるヤツ。（Facadeかけてるやつ）
とりあえずIBMのヤツを熟読しろ。
635:教えてください
05/12/13 21:35:54
左クリックを使用できないようにjavaScriptを組んだつもりでしたが、機能しません。
どこが間違ってるのかご指南ください。
問題のＨＰ URLﾘﾝｸ(urei.ojaru.jp)
フレームを使用してますが
Ｉｍａｇｅｓ→***のリンク→左使用不可ページ となってます。
*** のページ 左使用不可ページ直リン防止script
左使用不可ページ 左使用不可script
このようにしたのですが･･･････ﾏｲﾘﾏｼﾀ
もうどうしていいのか分りません
636:デフォルトの名無しさん
05/12/13 22:01:21
>>635 はスレ(板？)違いの上に、マルチ
637:デフォルトの名無しさん
05/12/14 10:05:47
板違いというより、基地外
638:デフォルトの名無しさん
05/12/16 02:08:32
Spring.NETの方はどうですか？
同じ？
639:デフォルトの名無しさん
05/12/16 13:48:47
>>638
Spring.NETは基本的なDI・AOPの機能は既に実装済み。
DB、トランザクション、WEB等の機能はまだ開発中みたいだな。
だけど、正直.NETでDIは使う気にならないな。
640:デフォルトの名無しさん
05/12/17 13:07:47
>>639
何故？
641:デフォルトの名無しさん
05/12/24 12:10:09
ActionSupportを使ってStrutsとSpring連携させてるんだけど
このクラスのテストケースをstrutstestcaseを使って書こうとした時に
Actionから呼び出すBeanを変えてテストケース書きたい場合
Bean定義のXMLを変えるしか方法がない？
テストケース側からビジネスロジックの注入を書けると楽なんだけど、、、
642:デフォルトの名無しさん
05/12/25 01:54:24
自分で注入しちゃったら？
643:デフォルトの名無しさん
05/12/26 01:34:51
Struts + Sringでエ○画像掲示板つくってみました。
Spring入れたほうが動作は安定して早くなりました。
644:デフォルトの名無しさん
05/12/26 11:56:02
>>642
その方法がわからないんだよう
ポインタなぞあったら教えてぎぶみー
645:デフォルトの名無しさん
05/12/28 07:47:52
Spring2.0って機能面ではどう変わったんですか？
646:デフォルトの名無しさん
05/12/28 07:55:33
>>644
セッターインジェクションの場合
setXxx(value);
フィールドインジェクションの場合
xxx = value;
で注入できますｗ
647:デフォルトの名無しさん
05/12/28 14:12:36
>>645
設定ファイルがXML Schemaベースになってる。
648:デフォルトの名無しさん
05/12/29 12:31:25
Important new features include:
* Simplified, extensible XML configuration
* Powerful new Spring AOP features and AspectJ 5 integration
* Asynchronous JMS facilities enabling message-driven POJOs
* Spring Portlet MVC, a MVC framework for JSR-168 Portlets
* ... and much, much more
これって設定ファイルが結構変わるのかな？
個人的には三番目がようやくと言った感じ。
JmsTemplate はいろいろ思うように行かなくて
(非同期受信なし、リソースを開放するタイミングが制御できないなど)
結局新たに作成したものを使った。
JndiTemplate があればどうにかなった。
649:デフォルトの名無しさん
06/01/08 02:38:17
フレームワークの議論ばかりしていて実際にハイレベルな
パフォーマンス＆拡張性が要求される現場では役に立たない
方々乙かれさまです。
650:デフォルトの名無しさん
06/01/08 03:19:20
どこでも役に立たない>>649よりはマシだけどな。
651:デフォルトの名無しさん
06/01/08 03:40:27
>>635>>637>>649
652:デフォルトの名無しさん
06/01/10 15:18:00
普通なら釣りなんだろうが現場見てると
本気でそう考えてるｵｻｰﾝがたくさん居て死にそうになる。
さすがに起動時だけは遅いが、一度起動してしまえば
速度が気になったことはないな。
拡張性については具体的な例を挙げて欲しいな。
どういう要求が出た時にどういう対応をしたのかを。
653:デフォルトの名無しさん
06/01/11 03:07:47
HibernateDaoSupportを使う場合にQuery#setFirstResults(int)やsetMaxResults(int)を
使うにはどうすればいいかご存じの方はいませんか?
getHibernateTemplate().find* ではQueryオブジェクトを渡せないし。。。
getSession()して自分で処理するしかないかな。
Spring 1.2.6 です。
654:デフォルトの名無しさん
06/01/11 11:24:00
>>653
HibernateCallback
655:653
06/01/11 22:34:55
>>654
return getHibernateTemplate().execute(new HibernateCallback() {
public Object doInHibernate(Session session) {
// クエリ投げて結果を返す
}
}
って感じですね。マニュアルにも載ってました。ポイントありがとう。
656:デフォルトの名無しさん
06/01/21 20:54:23
URLﾘﾝｸ(pcweb.mycom.co.jp)
> 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:デフォルトの名無しさん
06/01/21 21:14:58
>>656
「藻ジュース」(・∀・)ｲｲ
658:デフォルトの名無しさん
06/01/22 10:27:33
いや飲みたくはない……
659:デフォルトの名無しさん
06/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:デフォルトの名無しさん
06/01/23 23:34:09
たいくつでつまらない技術が一番強い。
661:659
06/01/24 11:18:42
>>660
確かに、ごもっともだと思います。
実はこれまでの開発ではSpringを使う機会もあったのですが、
見易さ、改修性の高さ、開発規模から
ServiceはInterfaceを使わずに実装しました。
(さすがにDAOはiBatis使って分けましたが)
それに比べ、今回は10年前にCで作った参照のみのアプリの更新で
時間的な余裕もあるので遊びたいと思ってます。
APIも読んでみたのですが、XDOCLETを使うか、また宣言で問題があったら、
といった使い分けの程度しか理解できませんでした。
みなさん、どのような使い方されているのでしょうか、教えて頂けるとありがたいっす。
662:デフォルトの名無しさん
06/01/24 13:57:58
>659
(1) と (3) は Struts に変更があったら、思い切り引きずられそう。
TilesRequestProcessor が出ようが新規に Action が発明されようが
涼しい顔して DelegatingActionProxy でラップするのみの (2) が好きですね。
(ていうか (2) しか使ったことないですけど。)
その分設定ファイルは煩雑になるわけですが。
自分の分かりやすいと思える方法でやるのが一番かと。
小規模でそれほど寿命も長くないのであれば、(1) も手っ取り早くていいと思いますよ。
XDOCLET は思ったほど便利じゃないと言うか、
開発の間に試行錯誤してると、結局手で書いたほうが速かったでした。
↑これは設計がまずかっただけかも知れません。
663:デフォルトの名無しさん
06/01/24 23:17:11
>>662
Actionベースはやはり分かり易いですよね。
人数が多いそれなりの規模なら、間違いなくActionProxyでいくと思います。
いくつかサンプル作ってみたのですが、3種類の感想は
ActionSupport
-確かに楽だけど、Springの楽しさは十分に味わえない気が。
でも実装はまんまActionなんで、いたって簡単。
しかもプログラマの質がそれなりなら、自分入れて3人位いれば
中規模まで行ける気がする。
ActionProxy
-実質これがStruts&Springの標準でしょう。
至って堅牢なシステムが訳分からん害虫と一緒でもテストファーストで
スムーズに作れそう。
しかもこれまでのStrutsの資産も十分に生かせるんじゃないでしょうか。
RequestProcessor
-Controler以前の処理をガチガチにやるのであれば、やはりRequestProcessorだと
思います。
が、幾分硬すぎる気が。大人数のRUPには向いているかな。
自分ごときが作るシステムはそれほどクリティカルじゃないし、ユルイと思うのですが、
まあ当たり前、と言った感想でしょうか。
今回はActionProxyからやってみようと思います。
時間もある分、新しい人も多いんで。
また進展したら報告します。 いらんか。
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
4912日前に更新/243 KB
担当:undef