トップページ⇒tech
1001コメント358KB

Java Spring Frameworkを語るスレ

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさんNGNG
http://www.springframework.org/

乱立するフレームワークと競合するプロトコルの嵐のなかで、
リスクの高い決断を余儀なくされているJavaデベロッパ、プ
ロジェクトマネージャに対する福音です。

語るべし。
0783デフォルトの名無しさん2006/05/21(日) 07:33:25
>>782
ここで解説されているみたいなことをやるべし
http://www-128.ibm.com/developerworks/edu/j-dw-java-springswing-i.html
07847822006/05/22(月) 00:01:56
>>783
自分でインスタンスを生成する必要がある場合の話です。

07857692006/05/22(月) 15:49:50
getBeanを利用する主な場面とは。。。
たとえば親子関係をなすドメイン（請求書と請求明細）などは
ロジック上で画面の内容をドメインに変換する必要があるのですが
明細クラスのような１クラスで複数インスタンス必要になる場合は
betBeanで必要数分インスタンスを生成する必要がある。
みたいな場面です。
0786デフォルトの名無しさん2006/05/22(月) 16:54:00
>>785
内部でインスタンスを生成する必要があるロジックの場合は、
そのインスタンスを生成するFactoryクラスをインジェクトする
ってのをよくやる。
0787デフォルトの名無しさん2006/05/23(火) 22:20:49
てかドメインモデルとはめちゃ相性悪い。
アナパタ時代の設計にDI使おうとすると死ねる
0788デフォルトの名無しさん2006/05/24(水) 11:41:00
よくわからんが、
higaﾀｿが提唱しているシンドメインモデルならドメインロジックだけDIにして、ドメインモデル(データ)
だけ通常の手段(new)で生成すればよいのでは？
ttp://d.hatena.ne.jp/higayasuo/searchdiary?of=5&word=%2a%5bgoya%5d
0789デフォルトの名無しさん2006/05/24(水) 13:07:20
▽どっちが速いSeasar2 VS Spring
http://cm.thinkit.co.jp/?4_23934_12965_1
0790デフォルトの名無しさん2006/05/24(水) 14:00:57
>>788
オレもそうしてる。ドメインのPOJOは自分でnewする方がOOしてる気分になるね。
DIに生成させるのはServiceLayer〜DataStoreLayerのドメイン『操作』クラス達だぬ。

>>789
ｷｬﾊｷｬﾊ。なんかヒガﾀｿ最近人格が変わった？ JavaOneでイジメでもくらったのかな。

PowerdBySpringのフレームワークがこんなにポコポコ誕生している現状を見れば、
1.2.xとスピード競争やった所で焼け石に水ﾀﾞﾇ。
AspectJが推奨スタイルになる2.0のこと知らぬ訳ではないだろうにね。

別にRodファンではないけどさ。
0791デフォルトの名無しさん2006/05/24(水) 15:39:44
785が考えるケースで getBean() することはない。
データは普通に new したらいい。
なんで getBean() しようとしたのか教えてくれ。
メリットが何一つ思い浮かばない。
07927882006/05/24(水) 17:02:50
>データは普通に new したらいい。
激しく同意。

ビジネスロジック周りでDIしたいと思うなら、
ドメインビジネスとしてクラスを切り分ければいいのでは？と思った次第。
07937692006/05/24(水) 22:06:40
>シンドメインモデル

>ドメインビジネスとしてクラスを切り分ければ。。。

ということは、私の思うトランザクションスクリプト + DAOという
組み合わせがDIでは有効という考えと同意と考えられます。
そちらのほうが合っているという結論ですよね。結局は。
DIを利用する上では状態をもつドメインはミスマッチであるということですね。
07947692006/05/24(水) 22:24:03
>なんで getBean() しようとしたのか教えてくれ。
>メリットが何一つ思い浮かばない。

785であげた例も悪かったですが。。。
1.getBeanするドメインが他のドメインを持っている。
オブジェクトグラフの一気取りが可能（Factory作ればすむという話もあるが）
2.やはりInterfaceを実装する実クラスをコードに書かなくてよい
この２つはかなりのメリットです。

もちろん前提がドメインロジックとデータの分離であれば、データに対して
getBeanするメリットが何もないというのは理解できますが。

DIを利用する上では状態をもつドメインはミスマッチである
けれども
上記の理由があるためドメインモデルでもDIを採用しました。
けれども
getBeanする部分をもっといいやり方はないですかねーという質問でした。
0795デフォルトの名無しさん2006/05/25(木) 01:09:09
Hibernate等のORマッパでドメインモデルを取得すれば、
one-to-manyなんかの関係は勝手に構築してくれる。
1の芋づる式にとりたいというだけでgetBeanするのはDIの役割とは違う希ガス。
（もしかして、DAOが生成するデータが≠ドメインモデルな設計？）

>2.やはりInterfaceを実装する実クラスをコードに書かなくてよい
はちょっと意味が理解できん。ｽﾏｿ。解説ｷﾎﾞﾝ。

>DIを利用する上では状態をもつドメインはミスマッチである
と
>上記の理由があるためドメインモデルでもDIを採用しました。
は納得できないなぁ。
そう考えた理由は？

あと、ビジネスロジックを切り出しただけでトランザクションスクリプトって呼ぶの？
SQLで記述するのか、呼び出し側の言語で記述するのか、が
ドメインモデルとトランザクションスクリプトの最大の相違だと思ってた。
ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?DomainLogicAndSQL
0796デフォルトの名無しさん2006/05/25(木) 01:14:00
うーん、ドメインモデルとかDIとかいろいろいじった結果一時DIに傾倒したが....

結局ところ、ドメインモデルのサポートとしてDIを使うくらいにしておきたいと
思った。
もしどうしてもどっちかを取らなくちゃいけなくなったら、サービス層を内製しても
ステートフルなドメインモデルを選択したい。Hibernateとか使うと、リッチなJava
オブジェクトをそのままＤＢにマッピングできたりするし。

それに、そっちのほうがオブジェクト指向っぽい感じがするから。
0797デフォルトの名無しさん2006/05/25(木) 15:57:44
精読したが
＞ 上記の理由があるためドメインモデルでもDIを採用しました。
の結論に至った理由が理解できなかった。

実際何を getBean() したのかが分からない。
getBean(リテラル文字) まくりな状況より
new した方が可読性高いし変なキャストもせずに済む。
設定ファイルで singleton="false" を書き忘れる心配もない。
どうしても生成部分を隠したいなら、
簡単な Factory を作って、そいつを DI でセットしたらいい。
0798デフォルトの名無しさん2006/06/29(木) 07:36:24
RC2あげ
0799デフォルトの名無しさん2006/07/04(火) 09:35:38
過疎スレ保全

つか、2.0期待sage
0800デフォルトの名無しさん2006/07/04(火) 20:58:53
時給１０００円でＪａｖａ教えてくださるかたを募集します
場所　所沢（池袋・高田馬場から直通）
よろしくおねがいします
ｉ−ｗａｎｔ−ｔｏ−ｓｔｕｄｙ−ｊａｖａ＠ｈｏｔｍａｉｌ．ｃｏ．ｊｐ
（アドレスは全角で書いてあるので半角に直してください）
0801デフォルトの名無しさん2006/07/05(水) 03:49:26
コンビニのバイトより安いですが、よろしくお願いします。
0802デフォルトの名無しさん2006/07/05(水) 16:53:11
おひおひ、1,000\/h っていくら何でも安すぎだよ。
それじゃ労働しようとする意欲湧かねぇな。

君が♀なら別。
0803デフォルトの名無しさん2006/07/05(水) 17:12:10
javaを教えると一言に言っても色々あるしな
0804デフォルトの名無しさん2006/07/05(水) 19:13:48
Springと関係ないな
0805デフォルトの名無しさん2006/07/05(水) 19:33:12
>>804
つーかスレタイにJavaが含まれているスレに無差別絨毯爆撃しているだけだから無視するのがよろしいかと
0806デフォルトの名無しさん2006/07/05(水) 22:35:28
しかし以外にたくさんあるんだな。
>つーかスレタイにJavaが含まれているスレ
ブックマークしていながら、今回のマルチが出るまで気づかなかった。
0807デフォルトの名無しさん2006/07/07(金) 15:39:40
Spring WS のドキュメントが結構揃ってきたすね。
前は XML-Object Mapping の章しかなかったのに。
そろそろまじめに調べ始めるかな。
08088002006/07/17(月) 21:33:22
教える対象は超初心者です。

専門学校などでJavaを勉強されていて夏休みだけ教えたいという方も歓迎です
0809デフォルトの名無しさん2006/07/18(火) 12:06:26
javaの前に常識って物を勉強したほうが良いと思います^^;
08108002006/07/18(火) 12:49:11
常識も教えていただければと思います。
0811デフォルトの名無しさん2006/07/18(火) 14:19:48
ここで聞いても学べません
0812デフォルトの名無しさん2006/07/20(木) 22:25:56
もはや完全にSeasarに押されてるな。
0813デフォルトの名無しさん2006/07/21(金) 00:57:25
>>812
獄長乙
0814デフォルトの名無しさん2006/07/21(金) 23:57:04
WebMVCのSimpleFormControllerで、
フォームのパラメータ名とCommandのフィールド名を
任意にマッピング（バインド）する方法がわからない…
0815デフォルトの名無しさん2006/07/24(月) 17:54:58
spring:bind使ってないの？
0816デフォルトの名無しさん2006/07/26(水) 12:31:58
Java World 2006/09 特集

2.0 とか関係なしに
・EJB3.0 に懐疑的
・ORM は最終的に JDBC に回帰する
な姿勢が良かった。

あと Acegi の記事が後で役に立ちそう。
0817デフォルトの名無しさん2006/08/01(火) 13:18:00
漏れJavaWorld斜め読みした所。詳しくはこれから読む。

豆蔵が書いたのねコレ。漏れは以前、長谷川ダンナの話を
聞いたことがあるのだが、

「Hibernateは確かに優れたプロダクトだが万能じゃない。
　陥りやすい穴もあるから慎重に検討してから導入した方がいい。」

って言ってた。禿同だったんだけどね。今回の記事もその思想が
根底に流れているみたいだね。

JPAマンセーな流れの中でこういう視点は貴重だと思う。
0818デフォルトの名無しさん2006/08/09(水) 01:22:18
Servlet依存のコード(JSFバッキングBeanも含む)とサービスメソッド
のデータ受け渡しってPOJOでもDTO使った方がいいのかな？
直にビジネスオブジェクト受け取った方がコーディングが楽なんだが・・・
0819デフォルトの名無しさん2006/08/10(木) 09:35:55
>>818

http://www.atmarkit.co.jp/fjava/kaisetsu/j2eewatch02/j2eewatch02.html
から抜粋

このように、POJOをそのままEntity Beanとして扱うことができれば、従来のEJB開発で
Web層とのデータ交換に利用されてきたDTO（Data Transfer Object）パターンはもはや
不要となる（実のところ、J2EEパターンの多くはEJBの使いにくさを緩和するために
生み出されたアンチパターンであるという見方もある）。
0820デフォルトの名無しさん2006/08/15(火) 22:23:19
うーん、結局、「Web層」って、BCE でいうと、どこになるんだろか。
「Web層」がBだけの役割であれば、M に B を依存させないために、
DTO(のようなもの)は必要のような気がする。

表示で使うPOJOを直接永続化するということは、
逆に永続化の都合に（N:N関係は扱えないとか）、
表示部のロジックが依存してしまう、ということになるんじゃないの？
0821デフォルトの名無しさん2006/08/16(水) 10:13:12
この本の書評たのむ。

http://www.amazon.co.jp/gp/product/4797334223/

特にオレが知りたいのは、

・2.0を紹介してるか。

・JPAを使ったWebApp例で、マンセー記事ばかりではなく
　注意点やアンチパターン的な解説もしているのか。

・SpringWebServiceの解説あるのか。

・SpringRichClientとかAcegi(SpringSecurity）の解説あるのか。

でも、読んだ印象でも何でもいいから知りたい。
0822デフォルトの名無しさん2006/08/17(木) 11:01:55
>820
> 表示で使うPOJOを直接永続化するということは、
> 逆に永続化の都合に（N:N関係は扱えないとか）、
> 表示部のロジックが依存してしまう、ということになるんじゃないの？
シンプルなアプリなら問題ないと思うんだが。
ただ、発想としては「永続化するPOJOを直接表示する」が正しいかと。

どうしても気になるなら、
サービス層で永続化用DTOからプレゼン用DTOへ変換してやれば良いと思う。(higaﾀｿのシンドメインモデルってやつね)
問題は、プレゼン用DTO・変換ロジックを実装するコストに対して価値があるかどうか。では？
08238222006/08/17(木) 17:21:40
間違い。
×　シンドメインモデルってやつね
○　Dxoってやつね

あと
ttp://capsctrl.que.jp/kdmsnr/wiki/bliki/?LocalDTO
0824デフォルトの名無しさん2006/08/22(火) 09:50:14
貼っとく

【IBM】Introduction to Spring 2 and JPA
https://www6.software.ibm.com/developerworks/education/j-spring2/
0825デフォルトの名無しさん2006/08/25(金) 23:20:47
tp://www.sssg.org/jp-springframework/?FAQ
Seasarの連中もキモイけどこれもイタイ。
0826デフォルトの名無しさん2006/08/25(金) 23:23:36
>>824
ログインパスワード教えて
0827デフォルトの名無しさん2006/08/26(土) 09:06:37
>>825
ゆるされるはんいじゃない？
0828デフォルトの名無しさん2006/08/26(土) 10:29:20
回答がおもろい。
0829デフォルトの名無しさん2006/08/26(土) 23:38:21
仲間由紀恵でなく蛯原友里にすべき
0830デフォルトの名無しさん2006/08/27(日) 23:31:05
>>829
仲間由紀恵は沖縄出身
08318242006/08/28(月) 09:30:04
>>826

ごめんごめん、先に米IBMの会員登録してくれ。
無料＆誰でもOKね。

https://www.ibm.com/account/profile/us?page=reg
0832デフォルトの名無しさん2006/08/28(月) 12:16:59
抜粋くらいないとわざわざ会員登録してまで見ようとは思わない。
0833デフォルトの名無しさん2006/08/28(月) 12:43:34
ここでそんな文句言われても…
08348242006/08/28(月) 18:21:41
序文

Java server applications need not be difficult and tedious to create.
Now in its second generation, the lightweight Spring framework adds a large suite of features
that make it simple for even new server application developers to use.
One key enhancement is Spring 2's integration with the Java Persistence API (JPA),
a cornerstone of the Enterprise JavaBeans (EJB) 3.0 specification. In this tutorial,
learn how to create server applications from scratch using the Spring 2 framework.
08358242006/08/28(月) 18:26:13
その次

Before you start

For almost a decade, the "proper" way to build a robust and
maintainable server-side Java application has been the exclusive domain
of the Java 2 Enterprise Edition (J2EE) platform.

J2EE applications are built using Enterprise JavaBeans (EJB) technology
and run on servers that facilitate deployment and provide rich container services
(such as the management of database connections and pooling).

These servers also add value by providing deploy-time declarative control of
important features such as security and transactions. Although versatile,
the J2EE development process involves many tedious and repetitive tasks
and the creation and maintenance of large numbers of source code files.

Many lightweight Java frameworks claim to simplify server application development,
but none matches the Spring framework in maturity and popularity (see Resources).
Now in version 2, Spring was designed from day one to simplify the server application
building process.

0836デフォルトの名無しさん2006/08/28(月) 18:26:48
その次

Instead of approaching development from an all-in-one container perspective,
Spring aims to provide just enough support for an application's requirements
without the burden of a full-fledged container environment. Spring eliminates code bloat:
you can code and test business objects completely outside of any container,
letting your business-object code remain simple, testable, maintainable, and reusable.

With the arrival of Java EE 5 and EJB 3.0, the J2EE community is poised to meet
the Spring developer community. EJB 3.0 supports the notion of lightweight POJOs
(Plain Old Java Objects) as EJB components and introduces the Java Persistence API (JPA),
a persistence mechanism that can run externally to the container.

This persistence mechanism automates the movement of information between business objects
and external relational databases.

Version 2 of the Spring framework has continued its evolution and also leverages JPA
as a persistence mechanism.

In this tutorial, you will work with Spring 2 and JPA persistence.
You'll create a server application using the Spring 2 framework, complete with access
to a DB2 Express-C database. The Eclipse IDE facilitates the development of the Java application
and enhances your exploration of the Spring 2 framework.

これ以上は面倒見ない。
0837デフォルトの名無しさん2006/08/29(火) 10:38:46
いつの間にやら　SpringLDAP っちゅーSubProjectができてるね。

これってAcegiと被ってないんだろうか・・・？
どうやって棲み分けしようとしているのか、理解している人いたら教えて。
0838デフォルトの名無しさん2006/08/29(火) 17:36:04
acegi とはレイヤーが違う。
LDAP ってセキュリティとはあまり関係ないのでは。
一種のDBを操作するプロトコル(書きより読みに重点)
程度のもんだと思う。
0839デフォルトの名無しさん2006/08/30(水) 08:04:35
>>821
Acegi使ったサンプルは載ってた。
0840デフォルトの名無しさん2006/08/31(木) 10:13:57
Eclipse RCPとSpringによる実用的なシッククライアントの構築
ttp://codezine.jp/a/article.aspx?aid=528
0841デフォルトの名無しさん2006/08/31(木) 11:59:47
>>799
> 過疎スレ保全
> つか、2.0期待sage


Web2.0に期待揚げ
0842デフォルトの名無しさん2006/08/31(木) 15:09:25
マーケティング用語なんてどうでもいい
0843デフォルトの名無しさん2006/08/31(木) 15:12:01
「Web2.0」を使いたがるのは40代以上
0844デフォルトの名無しさん2006/08/31(木) 17:58:42

>>838

説明thx、acegi に AuthXxxLdapImpl みたいなのがあるので
混乱していたのですが、確かに違うレイヤの話ですね。

（基本的に「業務アプリ屋」なもので、LDAPの本質とか
頭脳から抜け落ちていました）

>>839

情報ｱﾘｶﾞﾄ、今度その辺を試そうと思っているので購入
してみることにします。

>>840

お、これイイ。今度の仕事、このパターンになりそうなんです。
（EclipseRCPじゃなくてSwingになりそうだけど）
丁度都合よく記事が出てラッキー!!
0845デフォルトの名無しさん2006/09/06(水) 23:21:30
>>844
Swingを選ぶあたり、保守性を考慮してあっていいね
SE5.0から速度が向上してるよ
0846デフォルトの名無しさん2006/09/07(木) 01:34:24
データベースのフロントエンドで、Eclipse RCP使ってもメリットないし。
0847デフォルトの名無しさん2006/09/07(木) 15:27:08
ここでCGLIB聞いちゃいますが、

最も単純な、あるクラスの全メソッド呼び出しをインターセプトする場合、
Enhancer使って、MethodInterceptorをCallbackさせます。
この時CGLIBは一体どうやって実現してるか分かる方いますか？
CGLIBは、対象のクラスは弄らず、サブクラス化してるらしいが、
そのサブクラスにはどういう仕掛けをしてメソッドインターセプトする
でしょうか。

0848デフォルトの名無しさん2006/09/10(日) 21:58:06
http://www.google.co.jp/search?q=%E5%A5%B3%E9%99%B0%E3%83%9D%E3%82%A4%E3%83%B3%E3%83%88
0849デフォルトの名無しさん2006/09/11(月) 01:01:18
OpenSessionInViewInterceptorを定義して、それをSpringMVCで使うときは
bean定義でSimpleUrlHandlerMappingのinterceptorsにていぎするのまではいいのですが。
トランザクションのコミットとロールバック条件などはどのように設定するものなんでしょうか。
0850デフォルトの名無しさん2006/09/12(火) 01:32:58
Seasar2使え
0851デフォルトの名無しさん2006/09/20(水) 09:59:17
>>849
ぐぐれ
0852デフォルトの名無しさん2006/09/29(金) 00:22:03
カウントダウンｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!!!

ってEclipseのパクリかよｗ
0853デフォルトの名無しさん2006/09/29(金) 21:48:32
この道はいつか来た道
0854デフォルトの名無しさん2006/09/29(金) 22:11:27
ああ そうだよ
0855デフォルトの名無しさん2006/09/30(土) 21:57:09
その下の The Spring Rich Client Project ってのも木になる。
0856デフォルトの名無しさん2006/10/02(月) 18:46:19
質問です。

以下の場合、スレッドセーフになりますか？？

・SpringとStrutsの連携で「DelegatingActionProxy」を使用
・Service層のオブジェクトをSetterインジェクションしてインスタンス変数に保持
　※Service層のオブジェクトはスレッドセーフを意識していない


StrutsはスレッドセーフにするにはActionでインスタンス変数を使用しないとなると
↑の場合、スレッドセーフにならないような気がします。


もし、スレッドセーフにならないとして、synchronizedする以外でいい方法が
あれば教えてください。

やっぱ、ActionSupport使うしかないんですかね？？
0857デフォルトの名無しさん2006/10/02(月) 20:18:36
＞スレッドセーフになりますか？
ここで言う setter injection てのは
定義ファイルに書いといてコンテナにDIしてもらう事？

Action も Service も singleton="false" にすれば
スレッドセーフを考えなくてもOK。(コストは最悪。)

＞ActionSupport使うしかないんですかね？
ActionSupport も Action に違いないので
インスタンス変数持たせたら大変。

インスタンス変数を ThreadLoacal で保持させる方法も考えられるけど、
サーブレットコンテナが Action のインスタンスを使い回したりするから、
execute 抜ける前に、確実に変数クリアする等の注意が必要。

結局、いろいろやるより、Service 層をスレッドセーフにした方が楽。
0858デフォルトの名無しさん2006/10/03(火) 10:02:49
>>857
コンテナに DI してもらうという意味です。
言葉足らずでした．．．

確かに ActionSupport も Action を extends してるから
DelegatingActionProxy だろうが一緒ですね

Service 層をスレッドセーフな構造になるように考えてみます。
0859デフォルトの名無しさん2006/10/04(水) 00:10:57
Spring 2.0 リリース記念age
0860デフォルトの名無しさん2006/10/05(木) 09:43:31
豆の人たちあたりが早く解説記事書いてくれんかな。




読んでたら宜しく＞豆
0861デフォルトの名無しさん2006/10/27(金) 01:13:54
Spring-Annotation v1.0 ｷﾀ━━━━(ﾟ∀ﾟ)━━━━!!

やってみたー。動かなかったー。


orz
0862デフォルトの名無しさん2006/10/31(火) 20:38:16
↓の記事だけどさ、動かなかったんだよね。
ttp://journal.mycom.co.jp/articles/2006/10/26/annotation/

そんでさ、インスタンスをサ、createBeanで作ってやったワケよ。
とりあえずサ、動くこと確認してから記事にしろと言いたいわけ。
ソースまで追っかけさせんナ。ヽ(`Д´)ﾉｳﾜｧﾝ

TOAnnotationXmlApplicationContext ctx =
　　　new TOAnnotationXmlApplicationContext("classpath*:applicationContext.xml");

ConfigurableListableBeanFactory factory = ctx.getBeanFactory();

//createBeanの第2引数の0とか１とか2とかね、第3引数のtrue, falseとかね。ﾍ(ﾟ∀ﾟﾍ)ｱﾋｬ
TargetBean bean = (TargetBean)factory.createBean(TargetBean.class, 1, true);
bean.xxx();

プログラムは漏れの本業じゃないのに…。
烏賊にも動きました的な記事は要らんよ。検証してから書けや！

spring-annotation 試したヤシ、居る？
0863デフォルトの名無しさん2006/11/01(水) 10:38:09
試すならライターの記事よりもリファレンス見たり
テストケース触った方が良いかも知れんですよ。

annotation なんて無視するのが一番だと個人的には感じる。
0864デフォルトの名無しさん2006/11/01(水) 12:20:21
間違ってるのに記事を起こすのはどうかと思うのです。

しかもSpring-annotation同梱のサンプル・ソースも同じコードだし、ドキュメントないし。

結局ソース追っかけてくしかないね。

0865デフォルトの名無しさん2006/11/01(水) 12:36:59
Springにアノテーション使うと、エラく簡単になるよ。
0866デフォルトの名無しさん2006/11/02(木) 01:59:49
>>865
どのへんが？
0867デフォルトの名無しさん2006/11/02(木) 11:11:00
>>865
アノテーションでInjectionとか出来るなら使えるけど、そうじゃなきゃ意味ないぽ。
0868デフォルトの名無しさん2006/11/02(木) 11:21:38
アノテーションでDIならEJB3でおｋ
0869デフォルトの名無しさん2006/11/02(木) 22:28:27
>>862
普通に動いたけど。
それだとアノテーション書いてる意味なくね？
0870デフォルトの名無しさん2006/11/02(木) 22:34:44
>>866 >>867
アノテーションの定義のやりかたによってはXML不要になる。
オレオレアノテーションの定義もそれほど難しくないし。
0871デフォルトの名無しさん2006/11/02(木) 23:17:18
>>862
あと、createBeanの第2引数はファクトリの定数でいいかと。
0872デフォルトの名無しさん2006/11/03(金) 00:02:37
>>869
え゛？

new TOAnnotationXmlApplicationContext("classpath*:applicationContext.xml").getBean("bean");
だと、
NoSuchBeanDefinitionExceptionが返ってきて"No bean named 'bean' is defined"って言われる。

factory.createBean(); で動きました？

>ファクトリの定数
ソース見たら、BY_NAMEは１だって書いてあったので。
ConfigurableListableBeanFactory.AUTOWIRE_BY_NAME
でいいわけですね。
0873デフォルトの名無しさん2006/11/07(火) 14:49:21
spring hibernate strutsでアプリを組んでorg.hibernate.StaleObjectStateExceptionを発生したときのハンドリングって、global-exceptionで行うのが正しいのだろうか・・？
0874デフォルトの名無しさん2006/11/25(土) 18:53:10
んでこのフレームワーク結構導入実績でてきた？
MSの.netもおんなじようなSpring出しているけど
最近なんかMSさん追随してません。
0875デフォルトの名無しさん2006/11/25(土) 19:55:24
.Netな世界ではみんなCOM+サービスに満足してるんじゃね？
0876デフォルトの名無しさん2006/11/26(日) 02:57:30
.NET版SpringのSpring.NETって導入されてるんだろうか
0877デフォルトの名無しさん2006/11/26(日) 18:43:09
Spring Web Flowってどうなの？
ドキュメンツ読んでもいまいちよくわからんし、管理するxmlが増えそうだし。
0878デフォルトの名無しさん2006/12/03(日) 19:40:12
>>876
Spring.NET 1.0.2ならC/SのWindowsFormsな案件で使ってる。
SpringにはFormとDataAccessを管理させてる。
あと、AOPでDataAccessモジュールのSQLクエリキャッシュとトランザクション制御をやってる。
0879デフォルトの名無しさん2006/12/06(水) 16:53:07
なんで2chではspringとSeasarとでスレの勢いがぜんぜん違うの？
仕事(主に顧客の業務イントラ)でDIコンテナ使うとき、springを使うときのほうが圧倒的なのだが。
seasarを使っているというのをほとんど聞いたことがない。

ソフトウェアとしてどちらが優れているということについては
ここでは置いときますが、個人的にはSeasarには興味があるけど、
もっとspringのスレも盛り上がっていいと思うのだが・・・
0880デフォルトの名無しさん2006/12/06(水) 16:58:10
国産だし、どうしても目がいっちまう。

実際問題、Springで十分実用に耐えるんだけどな。
日本以外も含めれば、実績も多いみたいだし。
08818792006/12/06(水) 17:04:00
>>880
2ヶ月前アメリカに行ってとあるカンファレンスに出席してきたけど、
やはりみんなspring使ってた。
SSH(Struts, Spring, Hibernate)を肌で感じた。

>国産だし、どうしても目がいっちまう。

おれの周りだけかもしれないけど、
みんなspringという名前は知っているけど、Seasarという名前は
知らない人が多い。
0882デフォルトの名無しさん2006/12/06(水) 17:44:11
>>879
教祖ネタというか、燃料が供給されるかの違いだと思うけど。
■ このスレッドは過去ログ倉庫に格納されています