Java Spring Frameworkを語るスレ
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん
NGNG乱立するフレームワークと競合するプロトコルの嵐のなかで、
リスクの高い決断を余儀なくされているJavaデベロッパ、プ
ロジェクトマネージャに対する福音です。
語るべし。
0188デフォルトの名無しさん
NGNGあとで渡せばいいじゃん。
0189デフォルトの名無しさん
NGNGStrutsTestCaseは使えないし。
0190189
NGNGJNDIデータソースが使えないのが困るだけだ。
0191デフォルトの名無しさん
NGNG共通プロパティを持つ基底ビーンを指定できたら便利だな。
0192デフォルトの名無しさん
NGNGシングルトンになっちゃうんですが
回避策はありますか？
0193デフォルトの名無しさん
NGNGどっちかでsingleton=trueのままなんじゃないの？
0194デフォルトの名無しさん
NGNG0195デフォルトの名無しさん
NGNGメジャー
関わる人が多い
ドキュメントが揃っている
たぶんメインストリームになる
Seasar
日本ローカル
そこらへんで開発してる
構成ファイルがシンプル高機能
たぶんマイナーなまま
0196デフォルトの名無しさん
NGNG0197デフォルトの名無しさん
NGNGSeasarスレに本人降臨
http://pc5.2ch.net/test/read.cgi/tech/1092044210/
0198デフォルトの名無しさん
NGNG1つめのxmlファイルで、あるbeanのpropertyにlistをセットして、
2つめのxmlファイルから、その1つめで定義したbeanを呼び出して、
更にlistに要素を追加することって可能でしょうか？
このビーンはシングルトンです。
0199デフォルトの名無しさん
NGNGxmlファイルはどうとでも分割できるから、一つの定義でかけるならできるんじゃないの？
0200デフォルトの名無しさん
NGNGそれが少々複雑なケースで、最初の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ファイルが
ないよみたいなエラーが出るんですけど、やっぱこれって普通に無理なんですかね？
0201デフォルトの名無しさん
NGNG普通に無理というか、普通にDIを誤解しているだけだと思われ。
Bean定義の継承ができるかどうか、という話だな。
欲しい機能だけど、できるかどうかは知らない。
いまリファレンス読んでる最中だから。
0202デフォルトの名無しさん
NGNGparent属性は型が違ってもいいので便利。
複数のparentを持つにはどうすればいいのかは不明。
0203デフォルトの名無しさん
NGNGのSpring Framework Mail Extension使ったことある人いる？
Velocityを使ったVelocityMailMessageだけオリジナルを元にコピーする
コンストラクタがついてなくて困ってるんだけど。
Springでこれのインスタンス生成してビジネスロジッククラスにセット。
そのままVelocityJavaMailSenderに渡したら
マルチスレッドでごっちゃになってまう。
Singleton=falseにすればいいんだろうけど
その場合ビジネスロジック内にApplicationContextからの取得ロジックを書くことになって
ビジネスロジックがSpringに依存してしまう。
スキルありそうな人だからこれでも普通に使えると思うんだけどどうやればうまく使えるかな？
0204デフォルトの名無しさん
NGNGサービスクラスとして
FooService implements IFoo
を定義して、
テスト用のサービスクラスとして
FooTestService implements IFoo
のようなものを定義することになると思いますが、
テストごとにテスト用のサービスクラスを変えることって
簡単にできますか？
Cactusと組み合わせた場合とかにデプロイごとに設定ファイル
変えるようなことになってしまわないですか？
0205デフォルトの名無しさん
NGNGできる。
テストケースによって読み込むconfigファイルを変えるだけ。
0207デフォルトの名無しさん
NGNGhttp://www.amazon.co.jp/exec/obidos/ASIN/1932394354
ってたけーよ！
0208デフォルトの名無しさん
NGNGまあ、元がイングランドで発売（ポンド->円換算)だからね。。
Professional Java Development with the Spring Framework
の方は、まあ買える値段なんだけど、、、
0209デフォルトの名無しさん
NGNGttp://blog.ozacc.com/archives/000862.html
本家のAbstractDependencyInjectionSpringContextTestsより使いやすそう。
（っていうかこのクラスCVSからとってこないと動かないし・・・・）
0210デフォルトの名無しさん
NGNGめっちゃ亀レスだけど、
amazon.co.jpはポンドとドルのときがあって、
ポンド換算のときはなぜか高い。
ドルになったときに購入するのがおすすめ。
0211デフォルトの名無しさん
NGNG0212デフォルトの名無しさん
NGNG0213デフォルトの名無しさん
NGNGttp://d.hatena.ne.jp/koichik/20040408#1081424192
この例で言うところの one や two って
もともとのクラス実装(study.Foo)に
ComparableIntroductionInterceptor の実装が足されたものと理解してるんですけど
実際 study.Foo の機能使うときってどうすりゃいいんでしょうか。
one, two に対して単純にキャストするだけでは例外出ちゃうし。
0214デフォルトの名無しさん
NGNGPicoConatiner 1.1出ました。
http://www.picocontainer.org/Download
0215デフォルトの名無しさん
NGNGDependncy Injectionを語るスレ
http://pc5.2ch.net/test/read.cgi/tech/1099827125/
0216デフォルトの名無しさん
NGNGDI 廚 = マップ廚
分かるか？実行時解決ﾏﾝｾｰ！？
どっかでソースコード自動生成はもはや時代遅れで実行時バイトコード
生成ﾏﾝｾｰとかいう香具師もいたな。何が犠牲になってるかも分からずに
実行時なんたらって言いたいだけちゃうんかと。
なんなら俺が DI + II（Implementation Injection）コンテナでも作ろうか。
コードはもはやインタフェースのみで意識するのは界面仕様のみ。
実装コードは不要。依存性と実装はおまいらの大好きな XML に。
実装の取り替えはもちろん、いつでも修正可能だ。理想的だろ？
0217デフォルトの名無しさん
NGNG必死ですね。だんだんかわいそうになってきた。
何が犠牲になってるの？
マップ厨のときはORM無条件に不要といってたから厨だったんだけど、java.util.Mapでマッピングすること自体は、特に問題ないと思われる。
というか、無条件にDIダメといってる文脈がマップ厨の人と同一人物くさい。
> なんなら俺が DI + II（Implementation Injection）コンテナでも作ろうか。
別に、DIのしくみだけで十分同じことが実装可能なので必要ないけど、面白そうだから、作ってくれ。
0218デフォルトの名無しさん
NGNG0219217
NGNG0220デフォルトの名無しさん
NGNG思い起こせば、Javaを覚えたてのころは継承を乱用し、
GoF本を読めば(作ってるシステムにとって)意味のないクラスを量産し、
作ってる本人はご満悦ですが、保守する人とかどうしてるんだろう、
と思う今日このごろなコードもかつては作ってしまった気もします。
ハシカやオタフクカゼの困ったところは、「一度かかっておかない」と抗体ができないところ。
新しい設計技法、言語、ツールを知ると使いたくなるというのは
技術者の真っ当な感情だと思いますが、下手に使うとまわりが被害をこうむりますかも。
あと、伝染性がある上に発病期間までに時間があったりすることも。
ちゃんとテストして(使ってみて)、これは行けると踏んでから、
まずはリスクの少ない部分から適用していきましょうと(予防接種)。
生産性と品質に対して何の寄与もしないどころか、
足を引っ張るだけのフレームワークにハメられた僕は
別な何かが見える様になったと思います。
0221デフォルトの名無しさん
NGNG新しい技術に拒絶感を持つのはなにみたいなもんだろうか
0222デフォルトの名無しさん
NGNGここはネタスレのウォッチスレではないはずだ。
0223デフォルトの名無しさん
NGNG0224デフォルトの名無しさん
NGNG585 名前：デフォルトの名無しさん 本日のレス 投稿日：04/11/24 13:04:21
燃料投下。
ttp://d.hatena.ne.jp/higayasuo/20041124#1101254759
0225デフォルトの名無しさん
NGNGま、そんなもんじゃない？
定義ファイルの分割がよくわからんけど。
要するに、Springじゃひがさんのやりたいことはできない、という程度かと。
0226デフォルトの名無しさん
NGNG0227デフォルトの名無しさん
NGNG0228デフォルトの名無しさん
NGNG0229デフォルトの名無しさん
NGNG出てた。
約20ページの特集で、Spring+Hibernate、Spring+Strutsについての解説。
割りと初歩的な部分だけど、丁寧に解説されている印象。
0230デフォルトの名無しさん
NGNGたしかにオートバインディングは、名前でのオートバインディングしか使えないね。型によるのは怖い。
定義ファイルの分割については非常に疑問だね。インクルードができない、ということかな。名前空間のこと？
定義ファイルの肥大化に関しては、大規模プロジェクトで大規模に現れるような、シングルトンなクラスばっかりだと、XDoclet使えばいいということにもなるので、実質問題にはならないかと。
ただ、そんときは定義の継承を上手に使う必要があると思う。
逆にいえば、定義の継承ができないSeasar2では、XDocletを使ってクラスにBean定義を埋め込むのと面倒なことが起こるかも。
0231デフォルトの名無しさん
NGNG"import" element for XML bean definitions
ってのがあるんだけど、これがインクルード機能じゃないのかな。詳細をみても
よく分からんかったのだけど。
両方ともまだ使ってなくて、Seasar2は日本語資料が多いし、Springはデファクトになりそうな勢いが
あるということで、最近ずっと資料をよんで検討してました。まだ使ってない人間の感覚からすると、
Springのほうが面倒っぽいですね。直感的でないというか。
なんか微妙に変な感じがするなーと思ってたら、この日記を読んでなるほどと思った。
ttp://d.hatena.ne.jp/koichik/20040330#1080650506
ここに書いているとおり、Springの資料を読んでるとなんでもかんでもBeanなんだな、
と感じる。Spring的純粋主義なんでしょうか。一方Seasar2は「作ってるクラス定義自体には
Seasar2フレームワークへの依存関係を絶対もたせない」という方向での純粋主義みたいな
ところがありますね。後者の方が好みかなあ。
0232デフォルトの名無しさん
NGNG結局フレームワークに依存するんだから、どこにその依存が現れるかは、どうでもいいと思う。
信じる道を行けばいいだけ。
ポリシーが一定してないのは困るけど、両者ともそういうことはないし。
0233デフォルトの名無しさん
NGNGクラスがフレームワーク依存しなければ、
「再利用しやすいかも」って思うんだよね。
実際に使い込んだわけじゃないから、あくまで幻想だけど。
0234デフォルトの名無しさん
NGNG0235デフォルトの名無しさん
NGNGそして11/16に1.3予定になった形跡がある。
まだまだ先の話か。
0236デフォルトの名無しさん
NGNG本当に使いやすいのかなあ？
0237デフォルトの名無しさん
NGNGビーン定義ファイルは型による事前検証が可能だしね。
0238デフォルトの名無しさん
NGNG0239デフォルトの名無しさん
NGNG> コンパイル時に検証できないうえにファクトリでダウンキャストしないといけないのに？
周辺ライブラリを使えばダウンキャストは不要。
例えばStrutsのActionに最初から依存Serviceへの
参照がセットされてるとか。
というかむしろダウンキャストしない使い方が標準。
0240デフォルトの名無しさん
NGNGJavaソースを検証するコンパイル時に、Bean定義を検証する必然性はあるの？
別でいいじゃん。
0241デフォルトの名無しさん
NGNG0242デフォルトの名無しさん
NGNG今知りたい。
コンパイル時に検証したい理由。
たとえばantで別の検証タスクを作ってもいいし、簡易なら、単にビーン定義を読み込むだけの検証用プログラムを作ればいいと思うんだが。
0243デフォルトの名無しさん
NGNGなるほど、やっぱダウンキャストは勝手にやってくれって感じだよな
>>242
Javaしか知らん奴には弱い型付けとか言ってもわからんのだろう
藻前は却下
0244デフォルトの名無しさん
NGNG弱い型付けってなんですか？
0245デフォルトの名無しさん
NGNGhttp://www.google.com/webhp?hl=ja
ほれ
0246デフォルトの名無しさん
NGNG「弱い型付け」で検索したら、Server Errorでますた(T-T)
0247デフォルトの名無しさん
NGNG釣りはいいからさっさと調べろボケ
0248デフォルトの名無しさん
NGNG0249デフォルトの名無しさん
NGNGほんとに出たんだって。
GoogleのServer Error
0250デフォルトの名無しさん
NGNG0251デフォルトの名無しさん
NGNGで、自分はこんな感じでAntを使用してチェックしてるんだが、どうよ？
1.spring-beans.dtdを利用して、DTDレベルの妥当性のチェックをする。
2./beans/bean/@classの値がクラス名として正しいのか検証する。
1.はAntのXMLValidateタスクを使用。
2.はXPath + java.net.URLClassLoaderを使用しAnt拡張タスクを自作して使用。
まぁ、DTDレベルの妥当性チェック + クラス名チェックなんで完全とまではいかないが、
実行時前にチェック出来るんで、だいぶ楽になった気がするな。
0252デフォルトの名無しさん
NGNGだから、とりあえず設定ファイル読み込むだけのプログラム作って、それでエラー検出してもらうんじゃだめなの？と。
なんならそれをAntのタスクにしてもいいし。
0253デフォルトの名無しさん
NGNG0254デフォルトの名無しさん
NGNG0255デフォルトの名無しさん
NGNG毎回すべてをテストすることは難しいし。
0256デフォルトの名無しさん
NGNGANTやMavenでプロジェクトに組み込んでしまえば
自動でやってくれるじゃん。
0257デフォルトの名無しさん
NGNGテストを自分で作らないかぎりは、自動でテストしてくれない。
0258デフォルトの名無しさん
NGNG0259デフォルトの名無しさん
NGNGSpringIDEが、それぐらい、やってくれるんじゃないの。
0260デフォルトの名無しさん
NGNGというかやらない馬鹿もいるわけで。でも馬鹿でもコンパイルだけはする。
0261デフォルトの名無しさん
NGNGつまらんテスト仕様書を書く（しかもExcelで！）
よりテストコードを書くほうが楽しいと思わないか？
細かい修正のリリースの度に
テスト仕様書に則ってテストするのは
本来ならあたりまえの作業のはずなんだが
殆ど真面目に実行されていない。
テスト仕様書なんか納品前にでっち上げられる始末。
（銀行の勘定系とかはちゃんとやるけど）
それがmake（の相当品）に組み込まれているなら
便利だと思わないか？
0262デフォルトの名無しさん
NGNG> 細かい修正のリリースの度に
> テスト仕様書に則ってテストするのは
> 本来ならあたりまえの作業のはずなんだが
> 殆ど真面目に実行されていない。
細かいメソッド作成の度に
テストファーストに則ってテストを作成するのは
本来ならあたりまえの作業のはずなんだが
殆ど真面目に実行されていない。
というのと違いはあるのかな？
0263デフォルトの名無しさん
NGNG目視テストでは修正リリース時に毎回再実施のコストがかかる。
「真面目に実行」されていないのはリソース不足が理由。
自動テストでは上記の再実施のコストは激減する。
「真面目に実行」されないケースは開発者のスキル不足と
腐敗アーキテクチャが理由。
以上。
0264デフォルトの名無しさん
NGNG> 自動テストでは上記の再実施のコストは激減する。
再実施のコストが激減しても、テスト初回のコストは激増するわけだろ。
> 「真面目に実行」されないケースは開発者のスキル不足と
> 腐敗アーキテクチャが理由。
これが通常のテストに当てはまらない理由と
> 目視テストでは修正リリース時に毎回再実施のコストがかかる。
> 「真面目に実行」されていないのはリソース不足が理由。
これがテストファーストに当てはまらない理由を教えてもらいたい。
0265デフォルトの名無しさん
NGNG俺もそう思わんでも無いけど、そう思うのは自分の技能不足だということに気づいた今日この頃
0266デフォルトの名無しさん
NGNG0267デフォルトの名無しさん
NGNGチーム全員、すべてのプロジェクトで徹底するのが難しいんだよ。
0268デフォルトの名無しさん
NGNGつまり、ユニットテストというのは、個人の能力に依存することになるんだよね。
で、ユニットテストに依存するということは、チームの個々人の能力に依存することになる。
安定して開発するための一般的な手法としては、テストファーストはお勧めできない。
0269デフォルトの名無しさん
NGNG0270デフォルトの名無しさん
NGNG典型的な請負DQNシステムの場合、そういう余剰な工数ってどこから
捻出できるの？
0271デフォルトの名無しさん
NGNG確かにのびるが、２倍の200%ではなくて、115%くらいになるそうだ。でその15%分、
品質が15%あがるらしい。どうやって計ったのかは知らない。
0272デフォルトの名無しさん
NGNG0273デフォルトの名無しさん
NGNG二人いるなら二人分の金がかかる（奴隷でない限り）。
で二人で一緒に仕事すると、一人で別々にやる場合と比べて生産性が半分になりそうな
ので、費用も倍になりそうだという話じゃないか？
実際には別々にやった時と同じくらいの生産性を（つまり二人で二人分）を出す（らしい）と
いうことなんだが。
まあほんとかどうかは知らない。
0274デフォルトの名無しさん
NGNGデータベースからとってきた値をJSPに流し込むのって、ただの作業だし。
0275デフォルトの名無しさん
NGNG> で二人で一緒に仕事すると、一人で別々にやる場合と比べて生産性が半分になりそうな
> ので、費用も倍になりそうだという話じゃないか？
そうそう、そういいたかったんだ。ありがとう。
0276デフォルトの名無しさん
NGNGそれはユニットテストだのＴＤＤだの以前に、
きちんとバグのないソフト作るとか、きちんとテストできるとか、きちんとデバッグできるだとか、
ある程度個人の能力に依存するのは当然だと思うぞ。
１００人の人間がいて、１００人とも皆が同じ答えを出すっていうのは人間じゃないぞ。
0277デフォルトの名無しさん
NGNGコンパイラでチェックできるのなら、100人の人間がいて、コンパイルに通っていれば、100人とも皆が書いたコードがチェックに通っている。
0278デフォルトの名無しさん
NGNGコンパイラで型チェックさせるなんて意味あんのか、別の方法でチェックしても
いいじゃん、という話だったんじゃないか？
おれは>>260と同じ理由で価値があると思ってるけど。
0279デフォルトの名無しさん
NGNGコア部分はDIコンテナなんだね。MBeanで定義した各サービスをDIコンテナを使って依存性注入したり
独自のサービスをMBean化して公開出来るようになるらしい
記事には書いてなかったけど、そのDIコンテナってSpringを使ってるそうだし
今後は、APサーバーがDIコンテナを核として構築されるのが主流になっていくのだろうか
0280デフォルトの名無しさん
NGNGGBeanという形でFactoryを隠すことで、コンポーネントの利用者はサービスのみを享受できる。
サービスを提供したいのに、サービスを利用する準備から伝えないといけないのは、提供側も利用側もめんどくさい。
DIコンテナがあれば、提供者が好き勝手にFactoryを準備できる。
来年からやるプロジェクトではぜったいDIコンテナ使う。
S2よりはSpringだな。
0281デフォルトの名無しさん
NGNG内部がSpringって、あのAOPが自分のインスタンスメソッド呼び出しには適用されない問題は
大丈夫なのかな。（クラスＡのset.*にaspectを適用したら、最初に呼び出したsetHogeには
Aspectが適用されるけど、setHogeからthis.setHageを呼んだらAspectが適用されない問題）
実装の仕方みて「あーなるほどこりゃ自分で自分のメソッド呼んだら適用されないなー」と
思いはしたが、AOP的には困ったもんなのでまじなんとかしてほしい。
0282デフォルトの名無しさん
NGNGするかな？
0283デフォルトの名無しさん
NGNG動かない（ことがある）ってことわかってるか？
0284デフォルトの名無しさん
NGNGGeronimoはAOPは標準では提供しないらしいよ。コアに持っているのはあくまでDIコンテナで
AOPについては既存のものがGBean対応してくれるのを期待してるらしいね
AOPをコアに置いているJBossとは考え方が違うのかな？
0285デフォルトの名無しさん
NGNGでも、ログが重要なのって、オブジェクトの入り口のメソッドだから、急いで対応するほど問題になってないんじゃない？
0286デフォルトの名無しさん
NGNG0287デフォルトの名無しさん
05/02/15 01:33:40そんなさ、余計にバグ増やしてるようなもんじゃん。
補完も出来ないし面倒なだけだ。
■ このスレッドは過去ログ倉庫に格納されています