Java Spring Frameworkを語るスレ

Java Spring Framewor ..

2:デフォルトの名無しさん
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わたしたいんですが

次ページ