04/02/23 01:14
ばっかじゃねーの。まとめて一つのスレでやれ。あほ。
フレームワーク、ライブラリなんてJavaより多い言語はいくつもあるっつーの。
あほ。
3:デフォルトの名無しさん
04/02/23 07:02
Java Summer Framework
4:デフォルトの名無しさん
04/02/26 13:11
うほっ！！！いいスレッド。。
5:デフォルトの名無しさん
04/02/26 22:58
本家
URLﾘﾝｸ(www.springframework.org)
Rod Johnson著「実践J2EE システムデザイン」
URLﾘﾝｸ(www.amazon.co.jp)
TheServerSide.com - Introducing the Spring Framework
URLﾘﾝｸ(www.theserverside.com)
Rod Johnson著「J2EE Development without EJB, Expert One-on-One」2004年5月発刊予定
URLﾘﾝｸ(www.amazon.co.jp)
SourceBeatの電子出版書籍「Spring Live」
URLﾘﾝｸ(www.sourcebeat.com)
「Spring Live」サポート用Blog
URLﾘﾝｸ(www.sourcebeat.com)
Struts + Hibernate + Spring Framework のWebアプリ 作者は「Spring Live」の著者
URLﾘﾝｸ(raibledesigns.com)
Spring Frameworkを使用したJDBCプログラミングチュートリアル(作成途中)
URLﾘﾝｸ(www.buggybean.org)
6:デフォルトの名無しさん
04/02/26 22:59
eclipseプラグイン「Spring UI for Eclipse」
URLﾘﾝｸ(springui.sourceforge.net)
Spring FrameworkのWiki「Spring Pad」
URLﾘﾝｸ(wiki.bmedianode.com)
Spring Frameworkを利用した蔵書検索アプリケーション
URLﾘﾝｸ(www.commentout.com)
PicoContainerのプレゼンテーション資料日本語版(IoCの説明がわかりやすい)
URLﾘﾝｸ(cvs.picocontainer.codehaus.org)
7:デフォルトの名無しさん
04/02/26 23:14
利点：
Spring Frameworkを使うことによって、複数のコンポーネント間の依存性が下がる。
よって、Unitテストがし易くなったり、コンポーネントの自由な結合・組み合わせが可能となる。
XMLファイルを設定ファイルにしてBeanを生成することから、一見CommonsのDigesterやBeantilsと
同じじゃないか、と思ってしまうが、そうではなくUIからDBアクセスまで全てのレイヤをサポートし
レイヤ・ライブラリ間のシームレスな連携が実現できるところが最大の特徴。
欠点：
Bean定義をXMLに書かないといけない為すぐにXMLが肥大化してしまい、Strutsのstruts-config.xmlと
同じような悩みを抱えてしまう恐れがある。
8:5=6=7
04/02/26 23:18
自分が振れるネタはとりあえずこんなもんかな。
>>1さん
スレ立ておめ
9:デフォルトの名無しさん
04/02/27 07:59
Picoとの比較もありだよね。 >>1さん
Springのほうが高機能なのに、Picoのほうが
もてはやされている気がするのはなぜだろう。
漏れの気のせいかも知れんが。
SpringでPicoをつかうってのもあったような。
ソースを忘れてしまったが。
10:デフォルトの名無しさん
04/02/27 10:19
Type2,Type3もまいらどっち派?
11:デフォルトの名無しさん
04/02/27 10:21
>>9
> SpringでPicoをつかうってのもあったような。
SpringじゃなくてHibernateだった。
12:5=6=7=8改め春一番
04/02/27 12:58
>>9さん
自分なりの意見を。
Pico ContainerはType2, Type3両方をサポートしている。SpringはType3のみ。
よって使い勝手としてはPico Containerに軍配が上がる。
でもそれはIoCフレームワークとしてみた観点のみ。
Springはそれ以外にJDBC(O/Rマッピング)、メール、Webプレゼンテーション、AOP
と様々なレイヤをサポートしている為、1つのアプリケーションに一貫性を持たせるには
やはりSpringがいい選択だと思う。(個人的にはWeb周りはまだまだという感じだが。)
ネタ振りとしてリンクもはっとこう。
IoCとは何か、DAOパターンへの適用、PicoContainerとSpringの比較
URLﾘﾝｸ(today.java.net)
HiveMindとSpringの比較
URLﾘﾝｸ(javatapestry.blogspot.com)
>>10さん
Type3かな。Type2のコンストラクタベースは深く突っ込んで使うには少々使いづらい。
XMLの肥大化問題はもっとこの辺が流行ってくれば、ツールが対応してくれるでしょ、と楽観。
13:春一番
04/02/27 12:59
>>11
HibernateでPico??
Spring + Hibernateであれば幾つかリソースがあるね。
Hibernate - Data Access with the Spring Framework
URLﾘﾝｸ(hibernate.bluemars.net)
Spring AOP with Hibernate
URLﾘﾝｸ(www.springframework.org)
14:デフォルトの名無しさん
04/02/27 13:26
>>12
Type2とType3が逆じゃない？
Type2がSetterベースで、Type3がコンストラクタベースだよね。
それから、Spring Framework 1.0 M3以降はType2に加えてType3 IoCも
サポートされています。Type2(Setterベース)の場合、
<bean id="userManager" class="net.2ch.dao.UserManager">
<property name="dataSource"><ref bean="myDataSource"/></property>
</bean>
と書いていたものがType3(コンストラクタベース)では、
<bean id="userManager" class="net.2ch.dao.UserManager">
<constructor-arg><ref bean="myDataSource"/></constructor-arg>
</bean>
のようになる。
この場合、UserManagerインターフェースのコンストラクタのシグネチャは
public UserManager(DataSource dataSource);
という感じで。
15:春一番
04/02/27 14:18
>>14
＿|￣|○
16:デフォルトの名無しさん
04/03/01 22:53
ちょっとこっちに参戦してください。
ｽﾚﾘﾝｸ(tech板:542-543番)
17:デフォルトの名無しさん
04/03/02 09:20
>>16
参戦してきますた。
それにしても、AOPすれも多すぎだし、
各スレの依存関係が強いね。
18:デフォルトの名無しさん
04/03/02 22:46
つかrc2リリースくらい書こうよ
19:デフォルトの名無しさん
04/03/02 23:43
RCになってから、いろいろ変えんなよ。
20:デフォルトの名無しさん
04/03/03 13:07
>>19
リリース後はAPI変えないみたいなこといってたから
かけこみで変更しとけってのががおおかったんじゃないの？
21:デフォルトの名無しさん
04/03/03 18:48
web.xmlにapplicationContext.xmlを定義する方法で、Webアプリで使ってるんだけど
稼動中にapplicationContext.xmlを編集した後、内部でrefresh()を呼び出しても
全然内容が更新されない。
何でか分かる人いる？(てか、そもそもrefresh()がそういう用途にあるのかも分からん)
22:デフォルトの名無しさん
04/03/09 00:38
保守
23:デフォルトの名無しさん
04/03/09 08:30
>>21
そのrefresh()ってどのクラスにあるの?
m4では見つからなかったけど。
rc2落としてみるか。
24:デフォルトの名無しさん
04/03/09 13:38
>>23
AbstractApplicationContext っす
25:デフォルトの名無しさん
04/03/10 08:04
>>24
コードを見る限りは、refreshBeanFactoryで、
更新されそうだけど。
デバッガで追うしかない?
26:1さん
04/03/10 22:03
正直レスついて嬉しい。ﾜｰｲ
27:デフォルトの名無しさん
04/03/12 10:20
なんかねたなーい?
そういえば、Spring MVCってどうよ。
WebWorkのほうがいいって香具師もいるが。
Spring単独の話題より、比較の方が特徴が分かって面白い。
28:デフォルトの名無しさん
04/03/12 11:23
>>27
SpringのMVCはフレキシブルすぎて「MVC初心者」には使いこなせない感じ。
FormやValidatorやらも一通り揃ってて機能的には申し分ないんだけど、
多人数のプロジェクトで使おうとするとSpringのMVCをベースにもう一段
自分用MVCフレームワークを作るような構造にしないと、StrutsのActionで
ヒーヒー言ってるような人たちにはつらいと思う。
29:デフォルトの名無しさん
04/03/18 12:49
IoCはもう古い！これからはDependency Injectionだ！
「Inversion of Controlコンテナと Dependency Injectionパターン」
URLﾘﾝｸ(www.kakutani.com)
・・・ごめんなさい。名前変えただけです。
30:デフォルトの名無しさん
04/03/18 19:28
>>29
正確にいうと、type 2とtype 3がdependency injectionね。
31:デフォルトの名無しさん
04/03/18 23:12
JBossAOP って IoC コンテナですか？
ってか IoC と AOP ってどんな関係？ 全然違うもの？
32:デフォルトの名無しさん
04/03/20 01:16
全然違うモノ、
IoCはパターンのひとつ、AOPはある考え方と実践のための技術。
IoCもAOPに使えるかもしらんが、とにかく別物。具ぐれ。
33:デフォルトの名無しさん
04/03/21 13:38
あいまいな質問で申し訳ないが、SpringとWebWork2、どっち選んだらいいと思う？
比較資料希望。
34:デフォルトの名無しさん
04/03/21 19:33
>>33
比較大将間違ってないか、それ？
35:デフォルトの名無しさん
04/03/21 20:55
SpringとWebWork2の比較してるのは知らないな。
サンプルソースでもみて決定するのはいかが？
Spring
URLﾘﾝｸ(www.springframework.org)
WebWork2はWEB+DBPressで特集されてたのでそちらを参照。
だけどSpringのWEBアプリ用クラス使うより、StrutsやWebWork2と組み合わせるほうが一般的みたいよ。
36:デフォルトの名無しさん
04/03/22 10:36
Spring、Pico、Hivemind、XWork、S2 を比較した場合どんな感じですか？
Spring は元祖、
Pico はお手軽、
Hivemind は Tapestry ｻｸｰｼｬ作、
XWork は Webwork2 の一部、
S2 は日本人作
だと思うんすけど、これはここがｲｲ！とかあったりしますか？
やっぱ Spring がいいんかな。S2 は JTA とかついてきますが他のにも
ついてきたりしますか。
37:デフォルトの名無しさん
04/03/22 14:43
>>36
自前コンポーネントの管理が中心ならPicoが手軽でよい。
HibernateやJTAやVelocityまで巻き込んで管理したいならSpringが便利でよい。
自前コンポーネントの管理が中心で、かつMVCフレームワークが決まってなければ
WebWork2/XWorkというのも良い。
日本語ドキュメントが皆無でもよければHiveMindでよい。
即、実運用に入るというのでなければS2も期待大。
という感じだ。
38:デフォルトの名無しさん
04/03/22 15:19
>>37
Spring が実用向きってことですね。ところで
Spring は S2 みたいに JTA を使うための JTM 付いてますか？
URLﾘﾝｸ(homepage3.nifty.com)
別に JTM サポートする AP サーバか JDBC ドライバが必要ですか？
ってか自分で調べれないくらい英語弱いので S2 待ったほうがいいのか・・・
39:デフォルトの名無しさん
04/03/22 22:09
>>38
APサーバもしくは、JTAをサポートするTransactionManagerと
ConnectionPoolが必要。
40:デフォルトの名無しさん
04/03/22 22:38
>>39
ありがﾄﾝ！ JTM が無い Tomcat なので少し先の S2 で検討します。
Tomcat + Tyrex or JOTM + DBCP + Spring とかは連携があっしには
難しそうなので置いときます。
41:デフォルトの名無しさん
04/03/23 10:35
>>40
レポート期待してる。
42:デフォルトの名無しさん
04/03/29 13:27
Jakarta Projectスレは盛り上がらないときもあれば盛り上がるときもある。
Eclipseスレも最近のところほとんどレスが減った。
それでも週に一回くらいのレスはつく。
ということで無理して立てたスレに文句を言う必要も無い。
このスレはTepestryスレやJakarta スレ並みに
盛り上がると思われたが盛り上がらなかった。それだけのことだ。
しかしおれはこのSpring frameworkというものをはじめて知った。
ちょっくら拝見してみるか。
43:デフォルトの名無しさん
04/03/29 13:28
Spring Framework もそうだが、PicoContainerもXWorkも
J2EE専用じゃないぞ。どっちかっていうと逆だ。
Swingアプリケーションにだって、アプレットにだって適用可能だ。
58 名前：デフォルトの名無しさん 投稿日：04/03/25 22:55
乱立してるから避けられてるんでしょ。
標準化されたら変わるのでは。
59 名前：デフォルトの名無しさん 投稿日：04/03/25 23:35
だれか、JCPにIoC Container Service APIの策定を提案してみたら？
60 名前：デフォルトの名無しさん 投稿日：04/03/25 23:36
IoCコンテナの考え方って、Javaに限った話じゃないよねえ？
CやC++でも同じものがあっても便利なんでわ。
61 名前：デフォルトの名無しさん 投稿日：04/03/25 23:58
>>57
URLﾘﾝｸ(wiki.bmedianode.com)
にさ、
> Spring Framework（単にSpringと呼ばれることもあります）は、Rod Johnson氏の
> 著書Expert One-on-One J2EE Design and Development（邦訳は実践J2EE シス
> テムデザイン）の中で紹介されたコードをベースにしたJ2EEアプリケーションフレー
> ムワークです。
って書いてあるからJ2EE用だと思っていた。へぇー。
解説を読む限りはＥＪＢへの依存度を減らしやすくなるという
ことからJ2EEなどの敷居を下げるってイメージが見える。
44:デフォルトの名無しさん
04/03/29 13:43
54 名前：デフォルトの名無しさん 投稿日：04/03/25 22:38
>>2
Java以外のフレームワークやライブラリは有名じゃないとか有償で高価でだれもてをつけられないとか
なんらかの理由があるのかもしれんよ。
55 名前：デフォルトの名無しさん 投稿日：04/03/25 22:40
よく見たらJ2EE用フレームワークか。
そりゃそうだ。敷居が高すぎてなかなか盛り上がらないんだよJ2EE/EJB関連スレは。
JBossスレもなかなか盛り上がらない。
J2EEは見たからに難しいから。
2chねらでJ2EEを極めた香具師ってそうそういないと思われ、なんだな。
56 名前：デフォルトの名無しさん 投稿日：04/03/25 22:45
J2EEが敷居が高いつか泡沫案件には洋ナシってのはわかるが、
このSpring Frameworkは、J2EEを簡単に
使えるようにしてくれるもんじゃないのか？
Mission Statement
We believe that:
・J2EE should be easier to use
We aim that:
・Spring should be a pleasure to use
とあるし。よく知らんけど興味だけはあり。ageてみる。
45:デフォルトの名無しさん
04/03/29 13:49
>>61
IoCコンテナの主な役割は、Abstract Factoryの外部化、とでもいえばわかりやすい
のかな？J2EEのBusiness Delegateなんかの生成を行わせることが多いみたい、という
ことでJ2EE用と宣伝されるみたいだけどさ。
レイヤー間の依存関係を減らしたいと思う境界全てで有効な仕組みデス。
JDBCやJNDI、JAXPのAPIが、実装から切り離されて隠蔽されているのは多分知ってい
ると思うけど、同じようなことがしたい場所全てで、こういう仕組みを使うと簡単に
実現できるわけさ。
63 名前：1の人 投稿日：04/03/26 01:17
タイトルを"IoCコンテナを語るスレ"にでもしとけば、変なアンチが寄って来ないですんだかな。
ｺﾞﾒﾝﾅｻｲ。
64 名前：デフォルトの名無しさん 投稿日：04/03/26 01:24
そうだね。次スレはそういうスレタイで。
65 名前：デフォルトの名無しさん 投稿日：04/03/26 03:05
IoCってのは汎用AbstractFactoryってことでええの？
Products（Abstract/Concrete）は自分たちで作って登録して、
使う側はConcreteProductには触れないですむと。
なんか名前があってない気がするな。
漠然とCallBackみたいなもんかと思ってたよ。
46:デフォルトの名無しさん
04/03/29 13:52
>>65
名前はそのうち、DI(Dependency Injection) Containerになる余寒。
Factory + DependencyInjection (+ AOP)だね。
具象クラス同士がお互いに依存しないようにできるから
テストがしやすくなり、メンテナンス性もあがる。
でもSpringって巨大だね。
Hibernateとのインテグレーション機能以外を
使ってる香具師いる?
67 名前：デフォルトの名無しさん 投稿日：04/03/26 14:08
>>62
Abstractory Factoryって
部品追加するとすべての実装工場にまで部品を追加しないと
いけないので良い印象がない。
47:デフォルトの名無しさん
04/03/29 13:54
このスレ復旧完了。
スレ違いなネタ(Javaスレ大杉とか)はカットしますた。
48:デフォルトの名無しさん
04/03/30 08:58
>>47
乙
49:デフォルトの名無しさん
04/04/09 15:22
SEASARとどっちがいいんですか？
それとも競合するものではないのですか？
50:デフォルトの名無しさん
04/04/10 00:08
>>49
んなもん、世界中にユーザのいるSpringにきまっとろーが。
51:デフォルトの名無しさん
04/04/11 12:55
Seasarでいいよもう。
Springいんない。
52:デフォルトの名無しさん
04/04/12 12:24
Seasarの開発者が
＞AOPをS2独自ではなく、URLﾘﾝｸ(aopalliance.sourceforge.net)に
＞準拠させようと思います。これで、S2のインターセプタ(Advice)が
＞Springでも使えるようになります。
って書いてるね。
AOPアライアンスなんてのがあるんだったら競合するわけじゃない気がしてきたんだが
まあWebSphereとWebLogicが競合なんだからSpringとSeasarもその意味では競合か。
53:デフォルトの名無しさん
04/04/13 06:48
>>52
どうみても、かぶってる(競合している)フレームワークどうしだと思うが。
54:49
04/04/14 11:14
日本ではSeasarということでFAですか？
55:デフォルトの名無しさん
04/04/14 19:44
Seasarにいっぴょう
56:デフォルトの名無しさん
04/04/15 23:17
そんなにSeasarっていいのか。
Spring + Hibernate みたいなことが簡単にできる？
ちょっと調べてみないといけないなぁ。
57:デフォルトの名無しさん
04/04/16 00:27
>>56
S2Hibernateってのがあるみたいだね。
58:デフォルトの名無しさん
04/04/16 01:44
>56
透過的トランザクションは対応してる。
S2Hibernateのソース読むとわかるけど、S2Hibernate自体はあんまりたいしたことはして
なくてSessionとSessionFactoryへのBridgeをしてるだけ。
Springみたいなサポートクラスはないのは少し残念。
両方使ってみたけどもORMとの組み合わとからいろいろとSpringの方が便利だな。
プレゼンテーションとかの連携もこれからみたいだし。
他のフレームワークとの連携度でみるとSpringが一歩抜け出してると思われ。
Spring>Pico>Seasar
という感じだけど、どう？
ただ、Seasarは敷居が低いんで、IoCはこれから始めるっていう人にはかなりいいと思う。
59:デフォルトの名無しさん
04/04/16 06:58
>>58
Springみたいなサポートクラスって何?
HibernateTemplateのことなら、SeasarはSessionを
オープン・クローズする必要がないし、
HibernateExceptionもラップしてくれるから
おなじようなもんだと思うけど。
60:デフォルトの名無しさん
04/04/16 10:14
このスレはSeasar2にIOCされますた。
61:デフォルトの名無しさん
04/04/19 23:40
国際オリンピック委員会
62:デフォルトの名無しさん
04/04/21 21:46
Tapestryは3.0 Finalが出ても、ドキュメント類が貧弱。
ってことは、その弟分のIoC、HiveMindも、期待できないのかもな。
63:デフォルトの名無しさん
04/04/22 08:15
S2のPlugin開発がはじまったみたい。
URLﾘﾝｸ(www.mobster.jp)
64:デフォルトの名無しさん
04/04/26 10:11
>>62
作者謹製のTapestry in Actionを買え！っつーことなんでしょうね。
（そういうビジネスモデル？）
すぐにHiveMind in Actionも出る事でしょう。
65:デフォルトの名無しさん
04/04/29 15:22
>>64
完成して（枯れて）ないのに Tapestry in Action なんぞ買えん。
実際に普及するんだったらブラッシュアップされて細部が変更され
Tapestry in Action の内容は過去のものに。
Tapestry は作者のオナニー。
66:デフォルトの名無しさん
04/05/11 22:30
なんかEJB3.0の動向やら、Web上の毎評判聞くだけだと
もの凄い有用かつ将来性のあるフレームワーク(&Iocコンテナ?)っぽいけど
スレが伸びないのは何故？やっぱどっか問題があるのか？
はたまた先進過ぎて使ってるヤシがいないのか...
67:デフォルトの名無しさん
04/05/11 22:32
と言う事で揚げてみる
68:デフォルトの名無しさん
04/05/12 07:34
>>66
日本で本気で使っている人をあまり聞いたことがないね。
JavaWorldで特集されるらしいから、また変わるかも。
69:デフォルトの名無しさん
04/05/12 07:51
>>68
PicoもSpringもバリバリ普通につかってるよ？
使ってないのってあなたのまわりだけじゃないの？
70:デフォルトの名無しさん
04/05/12 09:42
>>69
こんなもの使ってるのってあなたのまわりだけじゃないの？
71:デフォルトの名無しさん
04/05/12 23:11
picoは知らんがSpringはなかなか良いぞ。 フレームワークとの関係を薄く出来るから
他のヤツとも組み合わせやすいし、ダメな部分だけ除外しやすい。
Tapestoryは公式ドキュメントすら殆ど無くて、3.0にもなってまだプレビューリリースみたいな
感じだから、まだ変わっていきそうな予感。 あんまりスマートじゃない部分も多いし。
72:デフォルトの名無しさん
04/05/14 12:18
>>66
EJB=敷居が高い、という印象を拭いきれないから
73:デフォルトの名無しさん
04/05/14 12:32
みんなJBossにしか興味がないから
74:デフォルトの名無しさん
04/05/25 22:03
おいお前らJava Worldで特集組まれてますよ
でも結局EJB3.0+Struts+JBossAOPらへんに呑まれそうな予感
75:デフォルトの名無しさん
04/05/26 01:29
JBoss厨がいるな。JBossAOPが呑むなんてこたないだろう。
76:74
04/05/27 21:48
>>75
激しく例えが悪かったが
JBossAOP「らへん」ね
別にAspectJでもいいんだけど。と言うかそっちの方が適切ね
要はSpringって全部入り(+他と連携)目指してるみたいだけど
だったら各層専門のフレームワークを寄せ集めた方がいいんでないの？
と素人目に思った訳だがどうだろう？
教えてSpringマスター!!
77:デフォルトの名無しさん
04/05/28 13:01
>>76
各層専門のフレームワークを寄せ集めて集中管理するのがSpringですよ。
78:デフォルトの名無しさん
04/05/30 23:50
>>77
なるほど、そう考えると便利な気がしてきました
「フレームワークのためのフレームワーク」的発想（であってる?)ですかね
79:デフォルトの名無しさん
04/06/08 03:30
PicoContainer 1.0 final age
80:デフォルトの名無しさん
04/06/08 20:52
pico tte nadesuka?
doko de jouhou nyushu dekirunodesuka?
81:デフォルトの名無しさん
04/06/08 22:57
すみません、どなたかＷＥＢＷＯＲＫと
ＳＵＮ ＡＰＰ ＳＥＲＶＥＲ ８
上手に合わせて使う方法御存じないでしょうか。
当方ＥＪＢ（ＣＭＰ）とＷＥＢＷＯＲＫを利用して、
プログラミングしたいのですが。
ＡＮＴの使い方覚えるよりも、ＡＰＰ ＳＥＲＶＥＲ
付属のＤＥＰＬＯＹＴＯＯＬを使いたいのです。
御存じの方がいらっしゃいましたら、どうぞよろしく
お願いします。
82:デフォルトの名無しさん
04/06/08 23:17
ﾏﾙﾁ
83:デフォルトの名無しさん
04/06/08 23:44
DeployToolなんて、EARだのWARだのをデプロイするだけじゃないのけ。
EARやWARを作成できれば、Antでビルドしようが他を使おうがどうでも
いいんでないの。Ant以外でビルドをする仕組みを今から作るなんて、
ﾋﾏﾀﾞﾅｵｲ、とおもうが。
84:デフォルトの名無しさん
04/06/27 09:02
strutsとの連携ってどういうこと？
Actionクラスを普通にstrutsで定義して、
その中でbeanＦａｃｔｏｒｙからDAO取得とか？
85:デフォルトの名無しさん
04/07/04 02:16
>>84
普通はActionからService呼び出して、その中でDAO使う。
当然、ServiceとDAOはSpringのContextから取得。
要は今までEJBを用いていた所をSpringで差し替えるだけ。
さらに、AOPを用いて各層の間に共通処理を差し込めば尚良し。
全然盛り上がってないのね…日本だとS2推しなの？
86:デフォルトの名無しさん
04/07/06 10:40
漏れはS2推しだなー
87:デフォルトの名無しさん
04/07/07 00:33
SpringやS2などのDIコンテナって局所的に盛り上がってるみたいだけど、メインストリームになるかねぇ？
POJOをプラモのごとく自由に組み合わせてシステム構築って魅力的ではあるけど、コンテナ独自機能も結構多いし。
コンテナ乱立で総崩れの可能性が高いような気がする。
88:デフォルトの名無しさん
04/07/07 07:24
>>87
コンテナ独自のインターフェースが規定されているのはSpring。
S2はそんなことないよ。
89:デフォルトの名無しさん
04/07/07 13:27
S2は取り巻きの盛りあがり方に引いちゃうな。
90:デフォルトの名無しさん
04/07/07 13:54
Springはロッドジョンソンの表紙に引いちゃうな
91:デフォルトの名無しさん
04/07/07 14:09
>>89-90
ちゃんとものを見ような
92:デフォルトの名無しさん
04/07/07 23:15
>>89-91
なずななのはななもないのばな
93:デフォルトの名無しさん
04/07/09 22:47
日本人ならSEASAR使えよ。
94:デフォルトの名無しさん
04/07/10 10:17
日経に比嘉氏の記事が出てたな
95:デフォルトの名無しさん
04/07/10 10:21
Spring使えネ、っていってたな。
96:名無しさん＠そうだ選挙に行こう
04/07/11 18:16
正直S2はひが氏以外に大した人材がいない（いても強くコミットしてない）
から先は無いと思う。
それに、Spring作ってる方は「Seaserには負けねー」とは言わないだろうな。
器が違うというか、「オープン」のスタンスが違うと言うか…。
97:名無しさん＠そうだ選挙に行こう
04/07/11 20:14
で、>>96から見てSpringはどうなのさ
98:デフォルトの名無しさん
04/07/11 23:42
IoCコンテナ作ってりゃ大なり小なりSpringは意識するんじゃないのかな
それは仕方ないことだし別に悪いことじゃないと思うけどね
JBossだって他のJ2EEサーバには負けねーってノリだけど器が小さいとは思わない
似たようなもんだろ
99:デフォルトの名無しさん
04/07/11 23:52
>>98
JBossは、自作自演してたりするけどな。
100:デフォルトの名無しさん
04/07/12 12:10
100get
101:デフォルトの名無しさん
04/07/16 21:02
>正直S2はひが氏以外に大した人材がいない（いても強くコミットしてない）
>から先は無いと思う。
最近開発を(一部)分担したらしいが、それがうまくいくかどうか。
失敗すればHORBの二の舞か。
102:デフォルトの名無しさん
04/07/16 21:08
HORBってあったねぇ。
あれの失敗の原因って何だろ。
・開発者１人に依存しすぎ、開発者発病であぼーん
・そもそも分散オブジェクトに需要がなかった
103:デフォルトの名無しさん
04/07/16 23:57
OMG様のCORBAとSUN本家のRMIの2強がいちゃあ、
黄色い猿が作ったモンが広がる余地はないだろ。
104:デフォルトの名無しさん
04/07/17 00:03
>>102
標準性が必要な分散オブジェクト技術としては、弱すぎた。
105:103
04/07/17 00:05
あぁ、それと、当時はまだgoogleもなく、常時接続も極めて少なく、インターネット上の情報が少なかった
今みたいなインターネットありきじゃなく、雑誌の情報が主で、プロモーションができてなかったんじゃないかと。
今であれば、それなりに使えたかも。
とりあえず情報少なすぎた。
106:デフォルトの名無しさん
04/07/17 00:54
HORBってclassファイルのバイトコードエンジニアリングでスタブを生成してなかったっけ。
今はそこらじゅうのAOP対応コンテナでやってるけど、当時としては画期的だったような。
107:デフォルトの名無しさん
04/07/17 01:16
>>101
優しいなもまいは。そうやって使いもしないプロダクトにまで気を使ってやるもまいの優しさが報われるのを祈っているぞ
108:デフォルトの名無しさん
04/07/17 07:34
>>107
どうも。
とりあえず生暖かく見守ります。
109:デフォルトの名無しさん
04/07/20 10:13
Springで質問です。
JDBCTemplate.query(String,RowCallbackHandler)というメソッドで
RowCallbackHandlerインターフェースの実装を渡すと、
ResultSetの件数分だけRowCallbackHandlerのprocessRow(ResultSet)が
呼ばれるんですが、これってデータがものすごい数あった場合、
ものすごい回数呼ばれるじゃないですか。
それって性能的にどうなんでしょうか。一回のprocessRowの中でwhileループ
まわしてすべて終わらしてしまうのはよくないですか?
110:デフォルトの名無しさん
04/07/20 11:35
>>109
URLﾘﾝｸ(d.hatena.ne.jp)
↑よみましょう
111:デフォルトの名無しさん
04/07/21 22:38
Seasarのサイトを見てみた。
「易しさと優しさ」がテーマだと書いてあった。
ダウンロードページを見てみた。
頭のいい人が考える「易しさと優しさ」っていうのは、所詮あんなもんなんだ、と思った。
112:デフォルトの名無しさん
04/07/21 22:50
選択肢が多いことは即ちわかりにくい、という大原則をわかってないらしい。
何ダウンロードすればいいのか、わからない。
あぁ、わかりやすさはテーマではないのか。
わかってる人に易しく優しければいいんだな。
113:デフォルトの名無しさん
04/07/21 23:18
彡ミミミミ彡彡
巛巛巛巛彡彡 ＜ こいつマジでアホやな
i ＿＿＿＿＿＿＿＿＿＿＿＿
⌒ ⌒ | | ＿＿＿＿＿＿＿＿＿＿＿
-･=- , (-･=- | |
⌒ ) ･ ･)( ^ヽ | |
┏━┓ | | |112 名前：デフォルトの名無しさん
┃ヽ三ﾉ ┃ |. | | 選択肢が多いことは即ちわかりにくい
. ┗━┛ ﾉ | | ,ｨー-ーｭｧ
｀- ､ ＿ー-ーｲ/. | | ／ '｀'｀'｀ヽ
｀ ￣ l l ￣ ｀ヽ､. |／ ｨソ
ヽ ヽ >ヽ ／ ,ノ＿＿＿＿＿＿＿＿
＼ ＼ ／ ノ＼／ヽ､＿ ,,,ｨ'"＿＿＿＿＿＿＿＿＿
ﾝ ＼ ｀´ ／ ﾝ /ﾆﾕﾆﾕﾆﾕﾆﾕﾆﾕﾆﾕﾆﾕﾆﾕ
＼ ／ ／ /ｴｴｴｴｴｴｴｴI ﾛｴｴｴｴｴｴ
114:デフォルトの名無しさん
04/07/22 00:44
>>112
その辺は多分どっちもどっち。
Springのようにすべてが取り込まれる方が良い人も
いるでしょうし、S2のようにコア以外は使う人に意志に任せる
というのもありだと思う。
個人的には必要なのは自分で選べた方が良いけどね。
115:デフォルトの名無しさん
04/07/22 04:29
>>114
無用に古いバージョンがある。
116:デフォルトの名無しさん
04/07/22 04:30
っていうか、本体が一番下にあるのが・・・。
117:デフォルトの名無しさん
04/07/22 19:51
せめてS2本体は別ページに置くか、トップページで最新版へのリンクを明示しておくか。
私的にはMaven使ってビルドするサンプルプロジェクトあれば十分だと思うけど。
（サンプル落としてビルドしたら依存関係を持つプロダクトを全部落としてくるようにする）
118:デフォルトの名無しさん
04/07/22 20:43
トップページではDIコンテナとかAOPがなんのことかわからないとSeasarがなんなのかわからんしね。
119:デフォルトの名無しさん
04/07/22 20:51
頭のいい人が「やさしい」といっても、ふつうの人は理解するのは大変。
そういうことでしょ。
120:デフォルトの名無しさん
04/07/22 21:07
>>119
「わからない」ということがどういうことかわかってないと、「わかりやすい」は難しい。
あの人たちの周りには、「わからない人」というのはいないし、寄ってこないだろうからね。
っていうか、「日本語で書いてある」「ドキュメントがたくさんある」「設定ファイルが単純」ということをもって「易しい」とか「優しい」っていってるだけだね。
「やさしさ」を重要視してるというのなら、「やさしさ」のためにどういう活動や管理をしているか、聞きたいもんだ。
GUIもないのに、「直感的」とか。
MSの、なんも考えずに使える環境とか見てると、やっぱすごく「優しさ」「易しさ」「わかりやすさ」考えられてると思う。
121:デフォルトの名無しさん
04/07/22 22:55
なあ、Javaってまだフレームワーク競争してんの？
122:デフォルトの名無しさん
04/07/23 01:29
>>120
具体的にS2の何がわかりづらいの？
123:デフォルトの名無しさん
04/07/23 01:40
>>81
Apache Mavenならdeployが驚くほど簡単にできるぞ。
まあやってみい？
124:デフォルトの名無しさん
04/07/23 01:45
>>120
GUIのどこが直感的なの？
コマンド探そうとしてアイコンみてもただの絵にしか見えなくて(以下略)
125:デフォルトの名無しさん
04/07/23 01:55
またコマンドライン対GUIネタかよ
とりあえず>>120はvs.netでも使ってろってこった
126:デフォルトの名無しさん
04/07/23 02:21
Maven + Eclipse + MevenideがあればVSﾄﾞﾄﾈﾄなんていらない。
127:デフォルトの名無しさん
04/07/23 02:39
そもそもJavaにGUIを期待してる時点で(ry
128:デフォルトの名無しさん
04/07/23 03:18
Eclipseは例外。
それどころかこれからはすべてが例外になる。
Swingも著しく早くなってきた。
そしてJavaWebStartの本格普及。
Appletに取って代わる技術だ。
そしてJSFによるリッチクライアントだ。
そしてJiniテクノロジーの普及。
129:デフォルトの名無しさん
04/07/23 03:47
Jiniかよ！
130:デフォルトの名無しさん
04/07/23 04:24
＞MSの、なんも考えずに使える環境
そのせいでクソシステムが乱造されてるわけだが
131:デフォルトの名無しさん
04/07/23 05:57
>>120
その単純な設定ファイルを見て、実際にどう処理されるか、わからないと使えない。
こういう場合は、こう使え！という実例があればいいけど、当面期待できそうにない。
DIコンテナとかAOPを力説されても、ひいちゃうな。
132:デフォルトの名無しさん
04/07/23 06:40
>>130
それはクソシステムの乱造とは関係ありません。
133:デフォルトの名無しさん
04/07/23 08:27
AOPとかDIコンテナとかの便利さは使い方はすでにわかってる人に対して、こんな簡単に使えますよ、っていってるんだよね。
断っとくけど、Seasarはいいものだとは思う。わかってれば簡単だし。
周辺技術との連携も充実してきてるから、わかってれば使い易いし。
134:デフォルトの名無しさん
04/07/23 15:11
>>131
＞DIコンテナとかAOPを力説されても、ひいちゃうな。
DIやAOPがSpringの売りですが何か？
135:デフォルトの名無しさん
04/07/23 15:20
Springの方は、「優しさを重視」とかインチキくさいこといいながらトップページに概要も書いてない、ということがないからおけ。
136:デフォルトの名無しさん
04/07/23 15:37
Springでいいじゃん。
137:デフォルトの名無しさん
04/07/23 16:00
>>132
だったら.netでちゃんとしたシステム作ってればいいだろ
何も考えずに使えるから何も考えずに行き当たりばったりに作る馬鹿が増えたんだよ
MSマンセーならJava使わなくていいじゃん
138:デフォルトの名無しさん
04/07/23 16:26
>>137
なにかにマンセーになるのは必須なのですか？
.netも、Javaとは別の性格でいいところはいいし、ちゃんとすればちゃんとしたものができるし、Javaでもちゃんとしなければクソシステムができる。
たとえMSマンセーであってもJavaがいいときにJava使うことはいいことだ。
139:デフォルトの名無しさん
04/07/23 16:31
で結局SpringはどうなんだYO
140:デフォルトの名無しさん
04/07/23 16:48
SpringのスレでMSを引き合いに出すのもどうかとおもうがな
141:デフォルトの名無しさん
04/07/23 16:52
統合開発環境として、MSのものはとっても優れてるから。
SpringなりSeasarなりも、いろんな技術を統合するためのフレームワークを目指してそうな気配だから、MSの開発環境並に統合された環境を用意してくれれば幸せ。
142:デフォルトの名無しさん
04/07/23 18:09
その辺はEclipseと比較すべきだろう
プラグインの取り組みはされているようだけど
そもそもEclipseがVS.netのように敷居が低いとは思えんしなあ
143:デフォルトの名無しさん
04/07/23 21:21
SEASERみたいなマイナーなやつに粘着するやつウザイ
もっとSpringの情報が欲しい。実際に仕事で使ってるやつとかの書き込みキボンヌ
144:デフォルトの名無しさん
04/07/23 21:42
Springも充分マイナーだと思う・・・
145:デフォルトの名無しさん
04/07/23 23:28
Springがマイナーとはいわないだろう
J2EEに与えたインパクトは大きいよ
146:デフォルトの名無しさん
04/07/24 10:44
>>142
そこでNetBeansですよ。
NetBeans4.0次第だけどな。
147:デフォルトの名無しさん
04/07/24 23:08
コンテナとIDEのはなしをまぜこぜにしてもなあ
148:デフォルトの名無しさん
04/07/25 00:14
>>145
各種O/R Mappingフレームワークに多大な影響を与えたと思われるWebObjectsは未だマイナーだと思われ。
って言うと信者が湧いてきそうだな。
149:デフォルトの名無しさん
04/07/25 00:16
その代わりTapestryとCayenneが注目されてるからいいんじゃない＞WO
150:デフォルトの名無しさん
04/07/25 00:48
>>148
作ったところが作ったところだから。
どんなに広まっても、マイナーということになる運命。
151:デフォルトの名無しさん
04/07/26 10:05
>>141
> 統合開発環境として、MSのものはとっても優れてるから。
M$のVS.NETなんてEmacs + GNU makeと比べたら大したことねえよ。
最近ではEclipseのプラグイン拡張が凄いことになっている。
しかもApache Antと併用できる上に、Apache Mavenという強力なプロジェクト管理ツールが登場した。
こいつもEclipseで使える。
しかもサーバ関係はＭ＄は弱い。Javaのほうが強しだな。
WebServicesで.NETはJavaに敗れたわけだし。
152:デフォルトの名無しさん
04/07/26 15:38
Eclipseのプラグイン拡張は、結局それぞれのプラグインをちゃんと把握してないといけないので、MSの統合環境みたいに、なにも考えなくてもいろんな技術が統合されたものができるというわけにはいかない。
Emacs + makeの場合、ほんとにそれぞれの項目を理解していないと使えない。
それぞれの項目同士の連携は、自分で考える必要がある。
それぞれの部品単位ではMS以外の環境が優れているかもしれないけど、「統合」という点ではMSの環境が優れている。
EclipseもEmacsも、たくさんの機能がひとつの環境から使える、という程度でしかない。
153:デフォルトの名無しさん
04/07/26 18:17
>>152
> Eclipseのプラグイン拡張は、結局それぞれのプラグインをちゃんと把握してないといけないので、MSの統合環境みたいに、なにも考えなくてもいろんな技術が統合されたものができるというわけにはいかない。
アホか。VS.NETにもプラグイン拡張があるぞ。
Eclipseのプラグインの把握はたいしたことがないぞ。
ちゃんとドキュメントは揃っているんだし。説明書をよめばだいたいわかる、どころか読まなくてもすぐに使えるんだし。
開発経験の無いド素人じゃあるまいし、エンジニアがそんなことも把握できないでどうするんだか。
> それぞれの部品単位ではMS以外の環境が優れているかもしれないけど、「統合」という点ではMSの環境が優れている。
> EclipseもEmacsも、たくさんの機能がひとつの環境から使える、という程度でしかない。
どこをどう統合したんだか。
VS.NETは2004になってからやっとリファクタリングなどのような
Eclipseに追いついた機能を手に入れたんだし。
154:デフォルトの名無しさん
04/07/26 18:24
>>153
WebサービスしらなくてもWebサービスつくれちゃうとか。
データベースのテーブルデータを取ってくるのをWebサービスにしてVBに貼り付けとか、簡単にできた気がする。
StrutsものにしてもHibernaterものにしても、それぞれが何かをちゃんと把握してないと使えない気がする。
Eclipseではなくて、Javaの問題なんだけど、そういったそれぞれのコンポーネントが縦割りで独立していて、連携をとるのに知識が求められる。
MSの技術は、それぞれは大したことないんだけど、それぞれを意識せずに連携できる。
それを解消しようとするものとして、Springがあるんだろうけど。
155:デフォルトの名無しさん
04/07/26 19:11
>>154
> WebサービスしらなくてもWebサービスつくれちゃうとか。
それもどうかと思うが
> それを解消しようとするものとして、Springがあるんだろうけど。
それも違うような気がするが
156:デフォルトの名無しさん
04/07/26 19:43
>>155
そう？
StrutsやらHibernateやらのアーキテクチャの違いを、IoCを介することで一貫性を保ちやすくする、という目的もあると思うんだけど。
157:デフォルトの名無しさん
04/07/26 21:04
上手く説明できないが違和感を感じる＞IoCを介してアーキテクチャの一貫性を保つ
158:デフォルトの名無しさん
04/07/26 21:28
>>157
違和感を感じる にも違和感を覚える。
159:デフォルトの名無しさん
04/07/26 21:53
このスレで一番参考になったレスかもしれない
160:デフォルトの名無しさん
04/07/26 22:26
>>157
SpringではSpringDAOとかSpringORMとかSpringMVCとかで
SeasarではS2DAOとかS2HibernateとかS2Strutsとかで
なんか、統一的な利用方法を提供しようとしてると思う。
基本的にJavaWorld2004/7の受け売り。
161:デフォルトの名無しさん
04/07/30 00:34
>>160
>SpringではSpringDAOとかSpringORMとかSpringMVCとかで
>SeasarではS2DAOとかS2HibernateとかS2Strutsとかで
これではアーキテクチャは統一されていないよね？
単一のフレームワークにて、ORMやJDBCフレームワークが利用できるのも統一的な利用方法とは
言えないのでは？
プレゼンテーション-ビジネス-パーシステンス層、全てにおいてIoCをベースとしたフレームワークを
利用できる為、アプリケーションにおけるアーキテクチャの統一性がはかれる。
またIoCを介することで、アプリケーションが個別のフレームワーク(Struts,Hibernate・・・)を意識しなくて
よいアーキテクチャを設計しやすくなると漏れは思っているがどうよ？
162:デフォルトの名無しさん
04/08/10 02:34
S2ネタはこっちでどうぞ
国産オープンソースDIコンテナSeasar V2(S2)
ｽﾚﾘﾝｸ(tech板)
163:デフォルトの名無しさん
04/09/08 22:38
1.1もでたことだし
164:デフォルトの名無しさん
04/09/11 17:16:39
ところで、SpringStrutsを使うとき、struts-configやapplicationContextをXDocletでは管理できんですか？
165:デフォルトの名無しさん
04/09/12 10:31:07
未だになんでSpringがいいのか全然分からないんだけど。
あんな別途にXML書いてアホかと思う。利点が見えない。
誰かSpringの利点が書いてあるリソース教えてください。
それか語ってください。
166:デフォルトの名無しさん
04/09/12 11:45:37
利点が見えないのはアホかと思うが、XML書いてアホかと思うのは同意しまくり。
SpringStrutsなんか使った日には、XDocletも使えず、struts-configとapplicationContextを書き換える必要がある。
かなり間違えやすそう。
テストが楽になるとはいうが、XML定義が正しいことのテストはどうするのさ？
利点はここでも見てろ。
URLﾘﾝｸ(wiki.bmedianode.com)
ようするに一極集中ってイイね、という話だ。
167:デフォルトの名無しさん
04/09/12 13:29:56
DIはEoDではない、と思われ。
168:デフォルトの名無しさん
04/09/12 21:17:16
>>165
Spring + Struts + Hibernateのコード書いてみたが、コード自体は非常にすっきりした。
いかにオブジェクトの生成・保持・伝達にコードが必要だったかわかる。
だから、逆に、Struts+HibernateでDI使わないとすると、あんないろんな場所でオブジェクトの生成取得コード書いて、必死に受け渡しして慎重に保持するのを見るとアホかと思う。
ということが言えるかもしれない。
169:デフォルトの名無しさん
04/09/13 00:52:43
そもそもWebインターフェースで複雑な業務を扱うのはいかがなかものか、と。
170:デフォルトの名無しさん
04/09/13 01:11:52
>>169
一般向けだと、現状Webインターフェイス以外の選択肢はないと思うが。
171:デフォルトの名無しさん
04/09/13 20:53:56
この本、
今現在webl○gicとN○Lの訳わかんねーﾌﾚｰﾑﾜｰｸ使ってﾑｶつきながら巨大webｱﾌﾟﾘ作ってるおれは
素直に感動した。
【軽快なJava】
URLﾘﾝｸ(www.esbooks.co.jp)
172:デフォルトの名無しさん
04/09/13 21:05:10
web10gicの変数名クラス名がやたら癇に障る
173:デフォルトの名無しさん
04/09/13 23:02:12
>>171
おれもその本買ってきた。J2EEはプログラマーの臨界点を超えて
複雑すぎるんじゃないかと思ってたのをそのまんま明快に書いてて
楽しい。
174:デフォルトの名無しさん
04/09/14 01:30:09
しかし、翻訳者がきらい。
へんな「翻訳者注」ない？
175:デフォルトの名無しさん
04/09/14 01:33:10
>>174
うむ、翻訳者がいけてないのは事実。こんなとこに訳注はいらんわい、
てなところにまで訳注があって、しかも日本語が意味不明。
最初、翻訳文なんで原文が意味不明なのかと思ったら、「訳者注」とか
書いてあるんでびっくりした。
176:デフォルトの名無しさん
04/09/14 01:49:20
えー、そうなの？
177:デフォルトの名無しさん
04/09/15 11:50:42
岩谷か。。。orz
178:デフォルトの名無しさん
04/09/15 19:32:38
>>171
よさげな本じゃな。
翻訳者には期待できないことを覚悟したうえで
買って読んでみるか
179:デフォルトの名無しさん
04/09/15 23:13:13
おれ岩谷の名前を意識したことなくて、今回あまりの訳注の多さに
びっくりしたんだが、ぐぐってみるとすごいのな。いやびっくり。
180:デフォルトの名無しさん
04/09/16 10:34:40
軽快なJava読んだよ。
でも、はっきりいって Spring Frameworkスレの住人にとって、
今更技術的に役に立つことはないかも。
EJBっていけてないじゃんと思ってるけど、それを口に出すと
「お前がデキないだけ」
「お前のやってる案件が小規模なだけ」
と煽られてストレス溜まってるﾔｼが、自分の考えを再確認するには
いいかもしれない…
181:デフォルトの名無しさん
04/09/16 20:14:22
こんな感じのリストを、プロパティじゃなくbeanとして定義することってできますか？
<list>
<bean class="org.apache.struts.util.LabelValueBean">
<constructor-arg index="0"><value>いらない</value></constructor-arg>
<constructor-arg index="1"><value>0</value></constructor-arg>
</bean>
</list>
182:デフォルトの名無しさん
04/09/16 20:47:32
>>180
>軽快なJava読んだよ。
SF小説ですか？
183:デフォルトの名無しさん
04/09/16 22:01:02
話題についていってない人はっけーん。
っつうか、10レス上くらい読めばいいのに。
184:デフォルトの名無しさん
04/09/17 07:17:23
ぼけたつもりなんだろ>>182は
いじめてやるなよ
185:デフォルトの名無しさん
04/09/17 12:48:59
定義ファイルだけど、同じクラスの定義を何個も書くの面倒。
値だけ異なる複数のBeanを定義する方法ってあるの？
例えば、商品クラスのインスタンスを４つ作るみたいな。
186:デフォルトの名無しさん
04/09/17 13:48:25
>>185
コピペ
187:デフォルトの名無しさん
04/09/18 10:10:57
Springからファクトリでクラスをロードするとき、
プログラムからコンストラクタに引数ってわたせない？
HttpRequestわたしたいんですが
188:デフォルトの名無しさん
04/09/19 03:21:59
>>187
あとで渡せばいいじゃん。
189:デフォルトの名無しさん
04/09/24 04:57:45
Spring + StrutsのActionをテストするにはどうするのがいいんだろう？
StrutsTestCaseは使えないし。
190:189
04/09/24 07:06:07
ごめん、StrutsTestCaseで問題なかった。
JNDIデータソースが使えないのが困るだけだ。
191:デフォルトの名無しさん
04/09/24 22:54:26
>>185
共通プロパティを持つ基底ビーンを指定できたら便利だな。
192:デフォルトの名無しさん
04/09/28 20:16:34
ProxyFactoryBeanを通すと生成されるオブジェクトが全部
シングルトンになっちゃうんですが
回避策はありますか？
193:デフォルトの名無しさん
04/09/29 03:59:07
確認してないが、そんなことはないと思うが。
どっちかでsingleton=trueのままなんじゃないの？
194:デフォルトの名無しさん
04/10/04 11:38:15
SeasarとSpringの違いってナニ？
195:デフォルトの名無しさん
04/10/04 11:44:33
Spring
メジャー
関わる人が多い
ドキュメントが揃っている
たぶんメインストリームになる
Seasar
日本ローカル
そこらへんで開発してる
構成ファイルがシンプル高機能
たぶんマイナーなまま
196:デフォルトの名無しさん
04/10/04 13:46:46
S2OpenAMFは使いたいと思ってるんだが
197:デフォルトの名無しさん
04/10/05 02:40:53
Seasar関係者が、自身の日記上でちゃんねらーに宣戦布告。
Seasarスレに本人降臨
ｽﾚﾘﾝｸ(tech板)
198:デフォルトの名無しさん
04/10/05 19:41:09
2つのappcalitionContext.xmlを読み込んでいるんですけど、
1つめのxmlファイルで、あるbeanのpropertyにlistをセットして、
2つめのxmlファイルから、その1つめで定義したbeanを呼び出して、
更にlistに要素を追加することって可能でしょうか？
このビーンはシングルトンです。
199:デフォルトの名無しさん
04/10/05 20:16:52
>>198
xmlファイルはどうとでも分割できるから、一つの定義でかけるならできるんじゃないの？
200:デフォルトの名無しさん
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を取り出すには、こうする見たいなのってあるの？