Java Spring Frameworkを語るスレ

Java Spring Framewor ..

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を取り出すには、こうする見たいなのってあるの？

340:デフォルトの名無しさん
05/04/11 16:10:43
>>339
俺はこうしてるよ。
ApplicationContext ctx = WebApplicationContextUtils.getWebApplicationContext(servletContext);

341:デフォルトの名無しさん
05/04/11 16:33:05
>>340
素早い回答サンクス！！！
やっぱり、ユーティリティはあったのね。

342:デフォルトの名無しさん
05/04/11 22:03:14
アプリケーションを起動したまま、コンポーネントを入れ替える方法ってありますか？

343:デフォルトの名無しさん
05/04/11 22:42:10
こういうやり方で取り出すのはOKなのかな？
これならServletContext無くても取れるんだけども。

package util;

public final class BeanFactoryHolder implements BeanFactoryAware {

　　private static final BeanFactoryHolder HOLDER = new BeanFactoryHolder();

　　public static BeanFactoryHolder getHolderInstance() { return HOLDER; }
　　public static BeanFactory getBeanFactory() { return HOLDER.beanFactory; }

　　private BeanFactory beanFactory;

　　private BeanFactoryHolder() { }

　　public void setBeanFactory(BeanFactory bf) {
　　　　if (beanFactory != null) {
　　　　　　throw new IllegalStateException("beanFactory already exists");
　　　　}
　　　　beanFactory = bf;
　　}
}

<bean id="beanFactoryHolder" class="util.BeanFactoryHolder" factory-method="getHolderInstance"/>

344:デフォルトの名無しさん
05/04/12 01:37:15
1個のVMに1個のWebアプリケーションのみ配備する、という限定ならいいだろうね。
裏を返せば不適当ということ。

util.BeanFactoryHolderクラスは、
Servletコンテナに100個のWebアプリがディプロイされていても、
そのうちの1個でしか使えない。
もしくは、100個のWebアプリ間で1個のBeanFactoryを共有する。

345:303
05/04/13 01:02:58
ご意見色々ありがとー。勉強になりました。
上に出てきた本も読んでみます。

現状の漏れの考えは、
１．ビジネスロジックに再利用性は殆ど感じない（あるとしたら
ライブラリとかユーティリティ系）。
２．業務要件として拡張性が求められている箇所は、自分で
ファクトリを作らないでDIコンテナを利用するのは良いかも。
３．本読んだらかわるかも。

おまけ
EJBで作られたビジネスロジックのコンポーネントは殆ど見たことない
んだけど、それってEJBがめんどいからでは無くってやっぱり
ビジネスロジックに再利用性が無いからじゃないかなって、
思いまふ（UI系は除いて）。
beaが頑張ってる気もするけど、beaでこの程度かと。。。

346:デフォルトの名無しさん
05/04/13 01:46:12
ビジネスロジックをインターフェース経由で使うのは再利用のためじゃなくて、
業務上の変更に耐えられるようにするためだよ。

EJBはほっといてもインターフェース中心になるんだけど、一つのオブジェクトに
対して４つのインターフェースが必要だったりして馬鹿くさいので誰もやらんのだ
と思うけど。

おれもトランザクション・スクリプトというか、関数プログラミング的に作っても
追いつくときは、極端にstaticメソッドだけでビジネスロジックを組んだこともある。

でもドメインモデルみたいに、各ビジネスロジック・オブジェクトが他のオブジェクト
と結びつき合ってる場合だと、業務の変更に対応する場合に、クラス構成を変えた
ほうが早いという場合もあるよ。
「請求書サービス」を「請求書サービス」と「売掛統計サービス」と「台帳サービス」
の三つに分解して、請求サービスのデータ登録メソッドを呼び出したら統計と
台帳も更新するように変えたって、請求書サービスのインターフェースがかわら
なければコントローラに影響を与えない。

逆に、オブジェクトが互いに依存し合ったドメインモデルのようなものを作らない
なら、別段困らないようにも思う。

347:デフォルトの名無しさん
05/04/18 21:27:23
Spring入門が発売されましたなぁ

348:デフォルトの名無しさん
05/04/18 23:07:17
今読んでます

349:デフォルトの名無しさん
05/04/18 23:27:43
どんな感じ？

350:デフォルトの名無しさん
05/04/19 09:09:14
俺は確保はしたがまだきちんと読んでない。
iBATIS との連携について書いてあったのがわりと新鮮だった感じ。
(もちろん Hibernate との連携も抑えてあった。)

Spring in Action の方が読み応えありそうなので
そっちを最初に片付けようと思ってる。

351:デフォルトの名無しさん
05/04/19 22:02:23
>>349
入門書という位置づけのようだが、定義ファイルに関する説明が
一覧表ですまされていたりするので、本当に初めての人がこの本で
Springを使えるようになるのかはちょっと疑問。
ApplicationContextのメッセージソースやイベントの説明はあるのに
FactoryBeanの説明がないっていうのは妥当な判断だろうか？
AOPも定義ファイルに書く使い方の前にProxyFactoryを直接使った例で
説明する意味はあるのだろうか？
DIとAOPという一番ベーシックな部分の説明が弱いのが入門書としては
難点だと思う。といって応用的な話があるわけでもなく…

352:デフォルトの名無しさん
05/04/19 22:48:59
>>350-351
サンキュ
Seasar2をちょっと触ってみたぐらいの俺だけど、Spring in Actionを買ってみます

353:デフォルトの名無しさん
05/04/19 22:54:31
Spring入門、俺も読み始めました。
内容はおいといて、文章は少しウザイ。

354:デフォルトの名無しさん
05/04/20 17:55:55
JDBCコネクションをプーリングしたいんですが、どんな方法があるのでしょうか？

355:デフォルトの名無しさん
05/04/20 20:01:54
Webならサーブレットコンテナまかせ。

356:デフォルトの名無しさん
05/04/21 00:52:01
>>354
Springで使うのなら、Apache Commons DBCPが一番お手軽かな
URLﾘﾝｸ(jakarta.apache.org)

357:デフォルトの名無しさん
05/04/21 00:55:53
「Spring入門」の2章でSpringをEclipseで使えるようにする説明があるんだけど、
「まずはSpringを以下のサイトからダウンロードし、適当なディレクトリに
解凍してほしい。
(URLとファイル名)
図2.19はダウンロードしたSpringをインポートしたJavaプロジェクト(以降は
Springプロジェクト)である。」
ってだけなんだよね。普通はこの説明で十分なのかな？
この後インポートした中にあるJARを別プロジェクトのlibにコピーしたりして
インポートする意味なしじゃね？って感じなんだよね。ソースパスの話ないし。
手間かけずにクラスパス通してSpringのソース見れるようにしたいんだけど
どうするのがいいのかな？
CVSから.projectと.classpath取ってくる？ maven eclipseしてからインポート？
みんなどうしてる？

358:デフォルトの名無しさん
05/04/21 10:06:14
>>355,356
まずはDBCPから始めてみます。

359:デフォルトの名無しさん
05/04/21 11:51:42
>>357
本屋に逝って JavaPress Vol.41 を嫁

360:デフォルトの名無しさん
05/04/21 12:27:25
>>359
持ってるけど大したこと書いてない
spring.jar他をクラスパスに通せと必要に応じてsrcやdoc以下を参照しろってだけ
spring.jarくらいならともかく，その他のlibにあるJARを手間かけずにまとめて
クラスパスに設定したいなんて誰も考えないってこと？

361:デフォルトの名無しさん
05/04/21 20:41:26
JSFやSeasarの陰に隠れてもはや風前の灯火…。

362:デフォルトの名無しさん
05/04/21 22:00:16
>360
spring 使うことで増える lib は
spring.jar と aopalliance.jar
(AOP する人は cglib もか)程度なんで、
別に特別たくさん増やすとかいうわけでもないので
そんなに問題になると思わないんですが。

Spring のソース見る分にはlib/以下のjar
にclasspath通しまくる必要なんてないし。

363:デフォルトの名無しさん
05/04/21 22:09:55
>>361
JSFの影にかくれるとか言ってる時点で、Springがなんなのかわかってないだけということをさらしてるわけですね。

364:デフォルトの名無しさん
05/04/21 22:13:01
>>361
で、どれが良いのか言ってみそ

365:デフォルトの名無しさん
05/04/21 22:58:54
>>364
EJB3.0

366:デフォルトの名無しさん
05/04/22 13:58:47
ふぅ～、アフォ発見。たまに湧いて出るこういうボケも、一種の清涼剤か。

367:デフォルトの名無しさん
05/04/22 15:32:50
なんか Perl の話をしているところへ
ナメック語やRupyの陰に隠れて云々

とかって言われた気分。

そんなことより Spring で Color を Set する時に(コンストラクタベース)
いろいろ警告が出るようになってしまいました。

<bean id="bgColor" class="java.awt.Color" singleton="true">
<constructor-arg index="0">
<value>16711374</value>
</constructor-arg>
</bean>

Color(int rgb) を呼び出してるつもりなんですが
Ignoring constructor [public java.awt.Color(int,int,int,int)] of bean 'bgColor': could not satisfy dependencies
(以下stack trace)
Ignoring constructor [public java.awt.Color(float,float,float)] of...(同様にstack trace)
と延々とログられた挙句、最後に
Bean 'bgColor' instantiated via constructor [public java.awt.Color(int)]
と表示されて、無事インスタンスが作成されます。

一応、インスタンス作成されて実用上は問題ないといえなくもないですが
ログが太って困るのでどうにかしたいんですが
誰か正しい設定方法をご存知の方、ご教授ください。
1.1.2 で動かすと問題ないのですが、1.1.6 に上げたら出るようになりました。
(Spring のログレベルは DEBUG ですが、これはしばらくこのままで行きたいです。)

368:デフォルトの名無しさん
05/04/23 00:29:07
こんなこと書くと荒れるかもしれないが
SpringとSeasarって国内の業務ではどっちが多く使われてるのかな？

369:デフォルトの名無しさん
05/04/23 02:19:57
現実的にはSpringかと。
ただ、オープンソースのプロダクトの利用数を数えるのは難しい上、両方そこまで大々的には使われてないから実数はよくわからない罠。

370:デフォルトの名無しさん
05/04/23 22:42:23
1.2のRC2が出てるが、
なんか役に立ちそうな機能追加された？

371:デフォルトの名無しさん
05/04/24 01:21:41
Hibernate3対応かな？

372:368
05/04/24 19:14:40
>>369
thx!

373:デフォルトの名無しさん
05/04/24 19:30:21
>>372
ただ、Spring使ってる人のまわりではSpringばっかりだし、Seasar2使ってる人のまわりではSeasar2ばっかりだから、人の意見はあまりあてにならんけどね。

374:デフォルトの名無しさん
05/05/06 13:30:15
すまん、DIはよく知らんのだが、よくEJBは××だからDIまんせー的な
発言見るんだけど、そもそもDIってリモートコールできんの？

375:デフォルトの名無しさん
05/05/06 13:58:11
DIパターンとリモートコールは全然関係ない領域の話だとおもうがね。

376:デフォルトの名無しさん
05/05/06 14:30:44
一つ聞きたいんですが
URLﾘﾝｸ(wiki.bmedianode.com)
↑のページを参考に beanRefContext.xml を書いたのですが
Spring が DEBUG メッセージを吐くのでちと気持ち悪いです。
ログは汚れるものの、期待通りの動作はしています。

型の合うコンストラクタが見つからないとか、そんな感じのメッセージなのですが
確かに ClassPathXmlApplicationContext のコンストラクタに
java.util.ArrayList を持つものはない模様で
この辺りは「一通りコンストラクタ調べたけどないっぽいから
String[] だと思って処理しよう」とかそんな流れでしょうか？
この辺り、ログを汚さないでスマートに指定する方法を教えていただけないでしょうか？

377:デフォルトの名無しさん
05/05/06 18:37:22
Springをちょっとずつ勉強しててＤＩのあたりまでわかったところなんですが、
AOP周りにも触ってみようと思ってます。

で、AOPって、具体的にはどんなことに使えるのかサッパリわかりません。
ログとる例ばっかりで、他に出来ることはないのか？って感じなんですが、
何に使うんですか？AOP

コンテナ側では使ってるのは理解できるんですが。
具体的な用途や、参考になるページがあったら
すみませんが教えてもらえないでしょうか。

378:デフォルトの名無しさん
05/05/07 03:33:48
AOPの二大用途といえば、

- ロギング
- トランザクション

だわな

379:デフォルトの名無しさん
05/05/07 05:15:36
Webの場合はそのくらいだな。

380:デフォルトの名無しさん
05/05/07 06:30:47
GUIのプログラムの場合、データ変更の画面への通知もAOPがいい。

381:デフォルトの名無しさん
05/05/07 06:33:45
イベントリスナーとかの代わりにって事？

382:デフォルトの名無しさん
05/05/07 06:58:12
GUIモノだと、だいたいセッターの後でnotifyみたいなの呼び出す必要があって、かなりめんどい。
それがAOPで楽できる。

383:デフォルトの名無しさん
05/05/07 08:04:05
効率を無視していいなら良いんじゃないの

384:デフォルトの名無しさん
05/05/07 08:38:48
無視していいわけないけど、影響が少なければ問題ない。

385:377
05/05/07 12:01:00
どうもありがとうございます。Web系なんですが、ログもトランザクションも
Springだとそのための手段が用意されてるのでなかなか使い道が難しいですね。

昔ＧＵＩも作ったことあったのですが、その例もなるほどなって思いました。
面倒ですものね。「横断的関心」ってやつがちょっとイメージできた気がします。

探してたら、こんなページも見つけました。難しいので理解できてませんが
URLﾘﾝｸ(www.oucc.org)

386:デフォルトの名無しさん
05/05/07 12:03:14
あ、すいません。ログはないですね。

387:デフォルトの名無しさん
05/05/08 13:35:51
>>386
org.springframework.aop.interceptor.TraceInterceptor
org.springframework.aop.interceptor.DebugInterceptor

388:デフォルトの名無しさん
05/05/08 18:55:53
>>375
質問した者だが

いやそうじゃなくて、じゃあそもそもEJBと比較して意味あんのかって意味。

分散オブジェクト技術とそうでない技術なら話してる土台が違うわけで
DI>>EJBとかわけわかんないんだけど。

389:デフォルトの名無しさん
05/05/08 19:18:26
>>388
EJBは分散が必要ない人にも分散を前提としためんどうな手続きを強要してた。
ほとんどの人に分散は必要なかった。
ほとんどの人にDI+ORM > EJB。

390:デフォルトの名無しさん
05/05/08 19:21:41
>>389

てか分散使わないのにEJB使ってる時点でどうかと・・。
まぁ後者のORMとかはわからなくもないが、EJBは
どっちかっつーと、というかどう考えても分散オブジェクトなわけで。

391:デフォルトの名無しさん
05/05/08 19:35:40
で、だからEJB使わずDI+ORMでいいじゃんとなったんでしょ。

392:デフォルトの名無しさん
05/05/08 21:33:10
>>391があたりまえだがいいことをいった。

393:デフォルトの名無しさん
05/05/08 22:17:34
>>390
まあ、EJBには分散以外にもいい点があるわけで。
宣言的なトランザクションとか、SQLを直接書かないDBMSアクセスとか。

そういEJBのよい機能は使いたいけど、
EJBは動かすの面倒、重い、コンテナに依存してテストしづらい
ってのがあって、その打開策としてSpringをはじめとして色々な
ソフトが出てきているわけだよな。

394:デフォルトの名無しさん
05/05/08 23:26:16
EJBってのはむしろCORBAの世界で
生きるはずなのだが。

395:デフォルトの名無しさん
05/05/08 23:38:34
それはない。

396:デフォルトの名無しさん
05/05/12 14:50:52
Spring＋HibernateでWebアプリ開発しようとしているんですが
applicationcontext.xmlのsessionFactoryのところで

java.lang.NoClassDefFoundError: net/sf/ehcache/CacheException
となってしまいます
でも、Hibernateのソースを見ても
net.sf.ehcache.CacheExceptionというクラスは存在してないみたいなんですが
どういうことなんでしょうか？

Hibernateはspring-framework-1.1.5の中に入っていたものを使用しています

397:デフォルトの名無しさん
05/05/12 19:55:24
そりゃeCacheのjarを用意していないからでは

398:デフォルトの名無しさん
05/05/14 18:48:46
質問があります。どうしてもわからないので教えてください。

applicationContext.xml に登録したオブジェクト(bean)の中の処理でファイルを読もうとしています。
このクラスは HttpServlet を継承していません。（特にクライアントからの要求を受け付けるわけではないので
そうしていました）したがって、web.xml には mapping していません。

この状態で、(webapps/project)/WEB-INF/data/ といったディレクトリからファイルを読み出したいので、
絶対パスを取得しようとしていますが、わかりません。

ApplicationContext appCtx = new ClassPathXmlApplicationContext("applicationContext.xml");

で、コンテキストは取得できましたが、パスを取り出す方法はないでしょうか？
（もちろんコンテキストからでなくても構わないです。）

Spring 使ってる上でクラスの作り方が間違っているとか、もっと普通の方法があるようでしたら
ご指摘ください。よろしくお願い致します。

399:デフォルトの名無しさん
05/05/15 22:24:06
>>398
私も同じ現象起きてます。
"/WEB-INF/lib/applicationContext.xml"という指定をすると
WEB-INFが見当たらないというエラーが返ってきます
なんでかしらんけど、パッケージの中しかパスが認識されないんです
だから
"/jp/co/sample/applicationContext.xml"
みたいにすると読み込めるんですよ。
でもソースのパッケージの中に設定入れとくのはちょっと気持ち悪いな、といった感じです
私はEclipseでTomcatプラグイン使用してますけど
Web.xmlの設定とかが必要なのかなー

400:399
05/05/15 22:30:21
レスした後に気づいたけど

>で、コンテキストは取得できましたが、パスを取り出す方法はないでしょうか？
>（もちろんコンテキストからでなくても構わないです。）

これどいう言う意味ですかね？

絶対パスで指定しなければルート（WEB-INFなのか？）から
フォルダをなめていってくれてapplicationContextを探すってことですかね。

不勉強ですいませんorz

401:デフォルトの名無しさん
05/05/16 05:36:09
つか、Webアプリだったらweb.xmlに設定書いた設定使うようにすりゃいいじゃん。

402:398
05/05/17 05:44:34
>>399

/web.xml
/WEB-INF/config/ (クラスパスが通っている)
/WEB-INF/config/applicationContext.xml
/WEB-INF/data/　　（クラスパスが通っていない）
/WEB-INF/data/data.xml

結局知りたいのは、HttpServlet を継承していないクラスから、
上の /WEB-INF/data/data.xml を読む方法なんですが、わからない・・・

>>401
web.xml に登録していなくて、httpServlet を継承していないクラスから
web.xml に記載した初期化パラメータ読むにはどうすればいいんですか？
マジで調べてもわからなかったので、すいませんが教えてください。

403:デフォルトの名無しさん
05/05/17 08:11:38
>>402
HttpServletを継承していない普通のクラスが、
/WEB-INF/なんて、HTTP固有のディレクトリ構造に
依存することを良しとする訳ですか。

404:デフォルトの名無しさん
05/05/17 08:46:55
基本的には普通のクラスはDIコンテナの存在を気にしないようにするね。

405:デフォルトの名無しさん
05/05/17 08:47:10
Servletクラスは絶対パスを取得できるので、そのパスをもらえばいいのでは？

406:デフォルトの名無しさん
05/05/17 09:11:58
サーブレットからApplicationContext自体をもらえばいいね。

407:デフォルトの名無しさん
05/05/17 14:22:24
FileSystemXmlApplicationContextではだめかいな？

408:デフォルトの名無しさん
05/05/17 17:29:46
皆さんどうもありがとうございます。

>>403
/WEB-INF/data にアプリが使うデータファイル置くのは一般的に言って変ですか？
/dataでもいいので普通はそうなら変更を考えます。まだ作法に慣れてないもので勉強します。

>>404
そのクラスは相手がDBじゃなくてファイルなんですがDaoと同じ様な役割をさせたいクラスなんで
他のDaoクラスと同じようにDIコンテナからロードさせてるんですよ。
で、Servletとか関係ない層で動いてるんですが実際のパス取得をどうしようかと悩んでます。
Springのフレームワークからそういうのとれないのかなと考えてましたが、的違いでしたでしょうか？

>>405-407
結局Servletクラスからパスをもらうことにしました。
正直に言ってまだ釈然としないものが残っているんですが、一般的にそうなら慣れるしかないですね

409:デフォルトの名無しさん
05/05/17 21:41:41
いにしえのServlet/JavaBeans流：jarファイル近辺のPropertiesファイルか取得
　　：
J2EE流：JNDIからデータの位置を取得
　　　　　 Connectorアーキテクチャでデータを供給
　　：
Spring Framework：？

410:デフォルトの名無しさん
05/05/17 22:37:48
>>408
ふつうは、普通のクラスはDIコンテナの存在を気にしないでいいようにする

411:デフォルトの名無しさん
05/05/17 22:39:07
>>408
設計が悪いときに無理をしないといけないのは一般的な話だから気にするな。

412:デフォルトの名無しさん
05/05/17 23:28:33
>>409
BeanFactoryから取得

413:デフォルトの名無しさん
05/05/17 23:41:41
BeanFactoryはどこからファイル所在を取得するつもり？

414:398
05/05/17 23:59:50
398です。お忙しいとこ何度もすみません。

>>410
ということは、Spring のアプリケーションコンテキストに依存せず、他の（サーブレットを継承していて
サーバ環境にアクセス可能な）クラスからもらってくる方法はまだマシという理解であってますか？

>>411
設計が悪いのなら直したいのです。>>409さんが書いている様に、Springやその他のDIコンテナ
（すみませんがJ2EE/EJBは知りません）を使ったときの作法があるのなら、この機会に
身に着けたいと思ってます。普通のクラスが外部リソースにアクセスする一般的な方法を
教えてもらえませんか？

415:デフォルトの名無しさん
05/05/18 00:17:47
>>413
そりゃサーバサイドだったら、web.xmlじゃないか？

JNDIだってどっかにJNDIのInicialContextFactoryを指定する（プロパティとか）のと同じ事だとおもうけど。

416:デフォルトの名無しさん
05/05/18 00:44:57
つまり、根っこはプロパティ

417:デフォルトの名無しさん
05/05/18 00:45:37
web.xml使うのは、Servlet層だけの簡単アプリ

418:デフォルトの名無しさん
05/05/19 06:47:36
DIしたオブジェクトから先は、いもづる式にDIするようにして、DIコンテナを意識しないとか。

419:デフォルトの名無しさん
05/05/19 10:10:35
>>418
最初は芋づる式って密な感じがして気持ち悪かったけど
実装してみたら楽すぎて止めらんね
どういった点でデメリットが出てくるんだろうか

420:デフォルトの名無しさん
05/06/01 08:56:52
JSF+Springで設計してんですけど
JSFのバッキングビーンのクラスとビジネスロジックのクラスのそれぞれの役割で

バッキングビーン
値のチェック、変換（この辺はバリデータ、コンバータに
任せるべきなんだろう）などのビジネスロジック呼び出す前の処理
あと、ビジネスロジックの結果の後処理

ビジネスロジック
必要なDAOを呼ぶだけ

こんな風に考えてます。これだとビジネスロジックのクラスが
たいした役割ではないと思うんですけど、DAOのファサード風と考えてよいでしょか

JSF+Springのサンプルアプリがみたいどすえ～

421:デフォルトの名無しさん
05/06/01 10:05:15
>>420

＞JSF+Springのサンプルアプリがみたいどすえ～

URLﾘﾝｸ(appfuse.dev.java.net)
URLﾘﾝｸ(equinox.dev.java.net)

漏れ自身が勉強中なので情報提供のみで失礼。

422:デフォルトの名無しさん
05/06/01 10:47:23
>>420
ＤＢのモデルを単に画面に表示する・画面に入力した値をＤＢに格納する
みたいなシンプルなアプリだとそうなるかもね。

423:デフォルトの名無しさん
05/06/01 10:50:24
sageついでに

＞ビジネスロジック呼び出す前の処理
＞あと、ビジネスロジックの結果の後処理

どのレベルの処理を言ってるのかわからないけど、
本当にMVCレイヤに置くべき処理なのか再検討してみては？

424:デフォルトの名無しさん
05/06/01 11:58:03

この本どうよ？書評ｷﾎﾞﾝﾇ
『実践Spring Framework―J2EE開発を変えるDIコンテナのすべて』
URLﾘﾝｸ(www.amazon.co.jp)

『入門Spring』と『軽快なJava』は読みました。さらに詳しい話を
聞きたい、という目的に使えますかね？

425:デフォルトの名無しさん
05/06/02 22:11:28
SpringがJSFとXULをイイ感じに仲介するフレームワーク作ってくれたら
一杯おごってやりたい。

426:デフォルトの名無しさん
05/06/03 12:15:51
>>425
Mozilla独自のXULより標準規格のXFormsのほうが良いのでは？
MozillaもOpenOffice.orgもXFormsに対応する上に、
Chibaを使えばXForms未対応のブラウザに対して
HTML+JavaScriptに変換してから送信することで
大部分のブラウザに対応できます。

Chiba (サーバーサイドJavaライブラリ)
URLﾘﾝｸ(chiba.sourceforge.net)
MozillaとXForms (Mozilla1.8/Firefox1.1で対応予定)
URLﾘﾝｸ(www.mozilla-japan.org)
[XForms 00031] XFormsのためのwiki (村田真氏がMozillaでXForms推進)
URLﾘﾝｸ(www2.xml.gr.jp)

427:デフォルトの名無しさん
05/06/03 12:41:43
>>426
XULへの必要性は一般の人にとっては低いとは思うが、
>>425は、ブラウザベースクライアントじゃなくて、リッチクライアントとして
XULを使うことを前提に書いてるんじゃなかろうか。
JSF経由でSwingとかFlashをクライアントにするノリで。

428:デフォルトの名無しさん
05/06/03 12:42:00
sage

429:デフォルトの名無しさん
05/06/22 09:39:06
禿げオヤジは意外とおとなしかったな。

430:デフォルトの名無しさん
05/06/25 15:34:01
海外では50％以上のプロジェクトで使われていて
ほぼデファクトスタンダードらしいが、なぜこのスレは伸びないの？

431:デフォルトの名無しさん
05/06/25 18:21:20
まあ、DIスレも伸び悩んでるし、
カテゴリとしてマイナーなんでは。日本では。

432:デフォルトの名無しさん
05/06/26 08:56:09
>>430
DIは、使い始めれば空気みたいなもんで、とくに議論することもなくなるから。

433:デフォルトの名無しさん
05/06/26 16:54:53
つーかSpringがホントに便利なのって純粋なtype2,type3のInjectionその物より、
コンテナが作ったProxyに対するAOPでしょ？

434:デフォルトの名無しさん
05/06/26 22:33:01
DIってのは、そういうものを便利にするための裏方だからな。

435:デフォルトの名無しさん
05/06/27 10:43:51
このスレ生きてるみたいだから質問させてくれ

proxyでAspectをweavingする事の弱点って何だ？
漏れが把握しているのは

1.自分自身のメソッドを呼び出すとAspectがかからない。
2.visitorみたくthisを渡して処理させるとAspectがかからない。

他に注意点ある？

436:デフォルトの名無しさん
05/06/27 11:31:59
ものすごくはらへった。

437:デフォルトの名無しさん
05/06/27 11:41:45
俺もだ。

438:デフォルトの名無しさん
05/06/27 13:49:43
いまさら同意。

439:デフォルトの名無しさん
05/07/05 11:09:42
1.2.2リリース記念

440:デフォルトの名無しさん
05/07/05 13:38:30
>>439
どこが変わったの？

441:439
05/07/05 15:43:58
詳しく見てない＆試してないけど、注目した一文は；

『added dedicated support for Hibernate Annotation 3.0 beta 2』

442:デフォルトの名無しさん
05/07/05 17:36:12
>>441
でも、前からHibernate Annotations使えてたよ。

443:デフォルトの名無しさん
05/07/05 22:32:17
つうか、Doclet のことを言ってるんじゃあるまいな。

444:デフォルトの名無しさん
05/07/06 03:19:27
アノテーションってそんなにいいもんなんでしょうか。
DIでせっかくコードから煩雑な記述を追い出したのに、
またコード中に埋め込んで、回帰と言うか退化と言うか。

コンパイラに対する指示を埋め込むのは意義が大きいと思うけど。

445:デフォルトの名無しさん
05/07/07 10:24:52
>>443
ここの最後にやりかた書いてあるよ。
URLﾘﾝｸ(www.fk.urban.ne.jp)

446:デフォルトの名無しさん
05/07/07 10:25:46
>>444
アノテーションは、XMLより記述が楽だし、ソースから得た型の情報を使うことで記述量自体が少なくできてるから、そう煩雑でもない。
クラスに関する情報をソースファイルに一元化できる効果もある。
なによりコンパイラによる静的チェックが効くし、Javaソースエディタでの補完が効く。

447:デフォルトの名無しさん
05/07/08 22:00:29
DIってテストしやすくなる？
単体まではいいけど、結合で結局アボーンな感じがするのだけど。

まぁつまるところは設計能力か・・・

448:デフォルトの名無しさん
05/07/10 00:55:34
アボーンって、具体的にはどういう問題がでてくると思う？

449:デフォルトの名無しさん
05/07/13 20:03:02
TransactionProxyFactoryBeanにtagetってフィールドがあるんですけど、これシングルトンなんです。
マルチスレッドでここに処理が殺到した場合、スレッドセーフにトランザクションさばけるんでしょうか？
教えてください。

TransactionProxyFactoryBean
URLﾘﾝｸ(www.springframework.org)

450:デフォルトの名無しさん
05/07/13 20:42:56
>449

そりゃ、targetしだいだろ。targetがスレッドセーフなら、問題ない。

451:名無しさん
05/07/13 21:00:03
同時に異なるスレッドの異なるtargetがシングルトンのTransactionProxyFactoryBeanにセットされにきたらどうなりますか？

452:デフォルトの名無しさん
05/07/13 23:18:19
オブジェクトの数とスレッド数は別ものとして考えないと。

ちゃんと考えられてるだろうから、
単一のオブジェクトの同じメソッドを
複数のスレッドが並行して駆け抜けることは全然OKなように
つくられてるはず・・・（たぶん）

453:デフォルトの名無しさん
05/07/14 16:28:52
蒼ざ(ry

454:デフォルトの名無しさん
05/07/14 19:22:10
どうやらtargetもシングルトンじゃないとダメみたいですね。

455:デフォルトの名無しさん
05/07/16 17:28:30
>>462
それはプラットフォームによる。
・GUIは大抵そう。(OSから飛んでくるイベントの処理は、イベント毎の状態保持が必要。
　　　　　　　　　　　もっとも、同じ要素に複数イベント飛んできたら、単に順次処理する事が多いんで、
　　　　　　　　　　　本当のスレッド並列処理はそんなに必要ないと思う。)
・Webアプリ周りも大抵そう。(例の(Statefull)Servletあたりが有名)
それ以外の場面で、常にインスタンスとスレッドを別に考えるのは、どーかと思う。
結局インスタンス数を減らしてまでメモリー消費を避けたい特殊な場面(大規模アプリ、組込みアプリ)
に固有のやりかただと思う。

456:455
05/07/16 17:30:24
ああ>>451-452の流れか。>>455は取り消し(ワラ

457:デフォルトの名無しさん
05/07/19 10:34:04
というか誰にレスしてんだ

458:デフォルトの名無しさん
05/07/24 22:38:13
これが最近有名なJSFって奴ね。
Javaは最新の技術追うのが大変（＠＠）

459:デフォルトの名無しさん
05/07/25 01:15:53
==============================
キチガイが狂った独り言を書き込み中
==============================

460:デフォルトの名無しさん
05/07/25 07:37:48
>>441
applicationContext.xmlの中でHibernate Annotationsの設定がかけるようになるってことみたいだね。
LocalSessionFactoryBeanを使う場合は、hibernate.cfg.xmlを書いておく必要があった。

461:デフォルトの名無しさん
05/08/06 22:29:31
Spring1.2.3でProxyFactoryBean使おうと思って

[ sample.xml ]
<beans>
<bean id="test" class="org.springframework.aop.framework.ProxyFactoryBean">
<property name="proxyTargetClass"><value>true</value></property>
<property name="target"><ref local="person"/></property>
<property name="interceptorNames"><value>advisor</value></property>
</bean>
…略…
</beans>

[ sample.java ]
BeanFactory factory = new ClassPathXmlApplicationContext("/com/mamezou/aop/proxydi/sample.xml");
Person person = (Person) factory.getBean("test");
person.setName("Hoge");

ってやるとCGLIBがねぇよってエラーになって、
CGLIB2.1のjarクラスパスに突っ込んでやるとエラーになるんだけど…。

対処方法ってなんかある？

462:461
05/08/08 00:45:20
事故解決しますた。orz

463:デフォルトの名無しさん
05/08/08 01:32:41
いちお、解決方法きぼんぬ

464:デフォルトの名無しさん
05/08/08 12:18:04
今度は aopallience がねえよって怒られて
それを修正したとかそんな流れ？

465:461
05/08/08 20:07:27
遅レス、スマソ。

CGLIB2.1入れても
java.lang.NoClassDefFoundError: org/objectweb/asm/Type
って出たので、ASM入れただけです。

＿｜￣｜○|||

ASMは1.5.3入れました。2.0だと
java.lang.NoClassDefFoundError: org/objectweb/asm/CodeVisitor
が出ます故。これで動いたは動いたケド、正しいかどうかは…。

466:デフォルトの名無しさん
05/08/08 20:27:13
>>464
だいたいあってたね。

467:デフォルトの名無しさん
05/08/10 12:47:00
だいたいってことは、正確にはどーすればよいわけ？

468:デフォルトの名無しさん
05/08/10 20:51:17
CGLIB とかのライブラリは
Spring 付属の jar をぶっこんだ？
まだ 1.1.7 使ってて 1.2 系は試してないけど
付属の jar 入れとけば間違いは少ないと思う。

469:461
05/08/10 20:53:28
ageます。ｽﾏｿ。

>>467
asm-1.5.3.jar
cglib-2.1_2.jar
をWEB-INF/lib/に放り込んでクラスパス通すだけでつ。
「ProxyFactoryBean使うときはCGLIB入れろ」
ってドキュメントに書いてあったのですが、
CGLIB使うときはASM入れないないとNGなんで、
URLﾘﾝｸ(prdownloads.sourceforge.net)
URLﾘﾝｸ(forge.objectweb.org)
のミラーからDLしてください。

…というコトではない？

470:デフォルトの名無しさん
05/08/10 21:14:42
with-dependency の方のディストリビューション落とせば
添付の jar を必要に応じて加えるだけで
外部のライブラリは不要だったと思うんだけど。。

471:461
05/08/10 21:47:00
>>470
ｻﾝｸｽ。

>with-dependency
こっちじゃなくて、spring-framework-1.2.3.zip落としちゃって…。

URLﾘﾝｸ(www.techscore.com)
にしっかり書いてありました。orz

472:デフォルトの名無しさん
05/08/19 12:55:20
Spring Beans XML Editor (Spring IDE for Eclipse)
URLﾘﾝｸ(springide.org)
Screen Shot 見る感じだと
とりあえず欲しい機能は結構揃っているような。

473:デフォルトの名無しさん
05/08/25 16:33:37
URLﾘﾝｸ(www.springframework.org)

474:デフォルトの名無しさん
05/09/07 09:38:35
KingはRodが大嫌いなんだとさw

URLﾘﾝｸ(houseofhaug.net)

475:デフォルトの名無しさん
05/09/07 09:53:15
Hibernate3 でトランザクション周りが結構変わって、
Spring とかなり方向違うなぁと感じたりはする。

Hiernate の Session Factory から getCurrentSession() 呼んだら
思いっきり怒られたりとか。
JTA が必要だったとは知らなかった。

なんかそんなことが続いてる。。

476:デフォルトの名無しさん
05/09/13 23:10:59
Springを勉強してます。
サーブレットにDIしたいクラスのsetter作って
動かしてみたのですが、NullPointerException...
サーブレットではsetterインジェクション(?)できないんですか？
ContextからgetBeanすれば普通にとれるんですが。。

477:デフォルトの名無しさん
05/09/14 00:14:32
>>476

普通はBeanにsetter/getter作るでしょ。
むしろ、setter/getter作ると自然にBeanになる。
MVCからやり直s（ry

478:デフォルトの名無しさん
05/09/14 00:27:50
>>476
サーブレットでDIするためにどういう設定したの？

479:デフォルトの名無しさん
05/09/14 00:40:33
>476
Webコンテナが管理しているサーブレットインスタンスを
そのサーブレットが呼ばれる前に，アプリ側から取得する方法があるとでも？

480:デフォルトの名無しさん
05/09/14 01:39:52
しかし、いろんなこと考える奴がいるもんだな・・・ある意味感心したw

481:デフォルトの名無しさん
05/09/14 02:41:41
>>479
web.xmlにはプロキシサーブレットを登録して、そのときパラメータで実際のサーブレットクラスを指定するような実装にすればできんでもない。

次ページ