- 1 名前：デフォルトの名無しさん mailto:sage [04/02/23 00:51]
- www.springframework.org/
乱立するフレームワークと競合するプロトコルの嵐のなかで、
リスクの高い決断を余儀なくされているJavaデベロッパ、プ
ロジェクトマネージャに対する福音です。
語るべし。
- 313 名前：デフォルトの名無しさん mailto:sage [2005/04/09(土) 13:39:51 ]
- そうだな、インターフェースを使ったプログラミングをしようとすると、
ファクトリをつくらなくちゃいけなくなるだろ。だって、newでインスタンス
を作っちゃうと、newしている部分は具象クラスに依存してしまうから。
なんで、ファクトリ用クラスをつくって、ファクトリ経由でオブジェクト生成する。
とここまでは誰でも実装すると思うんだよ。
で、ここでファクトリを書く方法を考えてみようや。クラスごとにファクトリを
別に書くなんて馬鹿げてる。じゃあ、インスタンス生成メソッドの引数でクラス・オブジェクト
かクラス名を引数で取ることにしよう。
じゃあ生成メソッド内で、渡されたClassに対してgetInstanceすることにしようか？
これはできない。渡されるClassは、インターフェースだろうから。
じゃあif文で、渡されたClassなりClass名なりで分岐して、具体的な生成クラスを
特定しようか。これも馬鹿げてる。クラスを追加するたびにファクトリにif文を追加
して、コンパイルし直すのか？ 分かりやすい記述法で外部ファイルに記述したい
ところだ。
そういや、具象クラスを生成するときのコンストラクタに引き渡す引数はどうしよう
か。ファクトリの生成メソッドにObject[]として引き渡してもらおうか？ 生成後に
setXXXX()で全部セットしてもらおうか。どっちにしても、具象クラスのコンストラクタ
なりプロパティに依存してしまうよねえ。
さあ、どう実装しようか。外部ファイルで具象オブジェクトを特定して、具象オブジェクト
生成時に内部状態の初期設定も行うファクトリだ。
そんな話を説明しているのがロッド・ジョンソンの本「J2EEシステムデザイン」。いろんな
アイデアを具体例を使って披露していく。このアイデアを実装して公開したのが
Spring Frameworkだよ。
- 314 名前：デフォルトの名無しさん mailto:sage [2005/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 名前：デフォルトの名無しさん mailto:sage [2005/04/09(土) 16:24:18 ]
- インターフェイスを使う利点が少ない状況ってのはやっぱりある罠。
上にも少し出てたけどプロジェクトメンバーの技量があまりに低い場合には
プログラム中で全てif文で分岐した方が効率がいい場合もあるかもしれない。
インターフェイスの使い方をよくわかってない人はまだ意外といる。（職場によるだろうけど）
「外部ファイルで具象ファイルを指定することにより具象ファイルを変更することが可能」というのも
それによる恩恵を受けられる環境と受けられない環境があるんじゃないだろうか。
自社システムやそれに近いぐらいに自分のところで管理しているシステムで
かつ頻繁な拡張や似たようなもの作る機会が多いなら強力だと思うけど
作って納品して終わりとか拡張がまるでなかったりしたら自分たちにとっての利点はあまりないかも。
>>311が理想だと思うけど状況次第では>>312の言うこともわかる。
俺はSpring好きだしどんどん使っていきたいと思ってるけど使ってもおいしくない状況ってのはやっぱりあるんジャマイカ。
ところでSpring in Action邦訳☆⌒ 凵＼(＼･∀･) まだぁ?
- 316 名前：デフォルトの名無しさん mailto:sage [2005/04/09(土) 17:02:49 ]
- そう、だから、インターフェースを使う必要がないならファクトリも必要ないんで、
DIパターンの利点がほぼなくなる。
あとは、コンテナが提供するAOP機能が使いたいかどうかだけだろう。
でもインターフェースを使ったことによる利点が出てくるのって、実は開発の
後の方（変更が入った時）なんで、最初のうちに「この開発ではインターフェース
使うほどじゃないだろ」とか判断してしまうと、後半で泣きを見ることもあるから、
先行投資としてインターフェース中心でいくんじゃないかね。
- 317 名前：デフォルトの名無しさん mailto:sage [2005/04/09(土) 17:11:58 ]
- インターフェイス主体でプログラム作るときの面倒さが減ることがDIのメリットなら、DI自体にはメリットはないみたいになるな。
- 318 名前：デフォルトの名無しさん mailto:sage [2005/04/09(土) 17:45:35 ]
- >>317
詳しく
- 319 名前：デフォルトの名無しさん mailto:sage [2005/04/09(土) 18:03:51 ]
- いや、DI「コンテナ」の、インターフェース生成時の実装隠蔽ファクトリとしての利点はなくな
るだろうけど、インスタンス生成時に依存性を注入して、すべてのプロパティが構成済みの
オブジェクトを作成するというDIパターン自体のメリットは残るだろう。
インターフェース主体でないからって、DIパターンなしだったら、
インスタンス生成→他の依存インスタンス生成（このインスタンスにも依存インスタンスがある）
→インスタンスのプロパティに依存インスタンスをセット
ってのを自前でやらないといけない。newして、関連オブジェクトをnewしまくって、関連
オブジェクトの全プロパティをセットして、で、最初にnewしたオブジェクトに関連オブジェクトを
セットしないといけない。
そんなめんどくさいこと、ファクトリでやってよ、と思わないか？
- 320 名前：デフォルトの名無しさん mailto:sage [2005/04/09(土) 18:28:24 ]
- ファクトリでやるのはめんどくさいから、それぞれのオブジェクトでやってよ、と思ってはだめですか？
- 321 名前：デフォルトの名無しさん mailto:sage [2005/04/09(土) 19:33:43 ]
- >>319
先日迷ったあげくSpring無しで書いたんだけどいちいちnewしてセットは確かに面倒だった。
これを面倒だと思うのはある程度Springに慣れてるからだと思うけど
それ以上に苦痛だったのは後で変更が発生したときの修正が面倒そうだと思いながら書いてたからだな。
でも>>319の一番のメリットは
具象クラスが変わることで具象クラスが必要とするオブジェクトが変わってもファクトリを修正せずに対応できること
（つまりは具象クラスの差し替えのしやすさ）
じゃないのかな。
それも具象クラス差し替え時に生きてくるメリットな気がする。
俺はSpringやDIコンテナ、もちろんインターフェース多用するのも否定するつもりはないんだけど
仕事場の環境次第ではSpringわからない人もまだ多いし
>>318の言うような先行投資の効果が目に見えて出ない時も多々ある。
それを考えると設定ファイル書いたり周知したりで面倒さが前面に出てくる人がいるのもわかるな、と。
後々俺が作った物を他の人が管理することになった時にその人はSpringを知っていてくれるだろうか、
俺がこれまでにしたつもりの先行投資は最終的にプラスになるのだろうか、
とちょっと悩んで書いたのが>>315なんだ。
チラシの裏って書いた方が良かったかもな。すまん（´・ω・｀）
- 322 名前：303 mailto:sage [2005/04/09(土) 20:29:45 ]
- >>314
>ロジック層のオブジェクト生成はどうするわけ？ newしてるってこと？
うん、newしてる。
>>315
そうだね、頻繁な拡張とかはないです。
>>316
>でもインターフェースを使ったことによる利点が出てくるのって、実は開発の
>後の方（変更が入った時）
うーん、開発後方でImplクラスを丸ごと挿げ替えるほどの変更は
ないなー。Implクラスの実装を修正するだけじゃすまないって事デツか？
あー、>>319 見て分かった。ビジネスロジック層の作り方がそもそも違うんだ。
漏れは、依存オブジェクトをプロパティ経由でセットしないデツ。なので、
ビジネスロジック層のオブジェクトの殆どが状態を持たないです。
ただね、このOOPらしくない所が良いのか悪いのかは漏れも迷ってる。
- 323 名前：デフォルトの名無しさん [2005/04/09(土) 21:16:39 ]
- ＯＯに反するコード＝劣悪なコード
- 324 名前：デフォルトの名無しさん mailto:sage [2005/04/09(土) 21:37:54 ]
- ステキなOOの概念がこの2年で大きく変わっている現実
- 325 名前：デフォルトの名無しさん mailto:sage [2005/04/09(土) 22:15:37 ]
- > うーん、開発後方でImplクラスを丸ごと挿げ替えるほどの変更は
>ないなー。Implクラスの実装を修正するだけじゃすまないって事デツか？
ただのロジック変更ならソースの修正で済むけど、対象によってロジック分岐とかだと
if instanceof else if〜 で分岐するのは全くエレガントじゃないから
Strategyパターンにしたほうが後々いいでしょ、って事だな。
拡張性とか関係ない部分ならいいかもしんないけど。
- 326 名前：デフォルトの名無しさん mailto:sage [2005/04/10(日) 00:22:16 ]
- うーん、最近の流れは勉強になるなぁ。
いつまでも独学は不安なので、自分の独学部分が正しいか
検証することも踏まえて、なんか本を買おうと思うのですが、
・これは読め
・これは糞だから読んじゃだめ
などありましたら、ご紹介いただけますか?
- 327 名前：デフォルトの名無しさん mailto:sage [2005/04/10(日) 00:27:43 ]
- >>322
＞ないなー。Implクラスの実装を修正するだけじゃすまないって事デツか？
機能追加の場合には新しい機能向けのクラス作って
条件によってどちらを使うか切り替えればわかりやすいと思う。
また、別のユーザー向けに似たようなシステム作る時には
クラスごと差し替えることができればとても楽。
＞漏れは、依存オブジェクトをプロパティ経由でセットしないデツ
引数で渡してるの？
インターフェース使わないならそれでも困らないと思うけど
インターフェースで実装の切り替えをするような場合には引
数がビジネスロジッククラスの実装に依存すると困るのよ。
ある実装ではこのオブジェクト使うけどこの実装では使わないとなると引数が統一できないから。
その点>>319のように依存オブジェクトを初期化時に設定ファイルで指定して
プロパティやコンストラクタでセットするようにすれば
呼び出し側からは実装の違いを全く意識する必要がないことになる。
- 328 名前：デフォルトの名無しさん mailto:sage [2005/04/10(日) 01:11:57 ]
- Springを使って3ヶ月程度のプロジェクトをやってみた。
俺はPMの立場で実装はやらないが、コードレビューする程度。
結論は、SpringにするかはともかくIoCコンテナなしの開発は、もう考えられない。
最初にかならず行っていた低レイヤー部分のフレームワーク作りをしなくて済むのだから。
いつもなら、実装がぶれるのが嫌で、最初のうちに低レイヤーのフレームワークを作ってから
プログラマに渡していた。
最初にこう書くべきだというサンプルを見せてやれば、
newbieでもそこそこのものを書き上げてくれる。
Springのソースを読んでて、interfaceは多重継承できることを初めて知った。
Javaには自信を持ってたのに、自分に少しがっかりした。
- 329 名前：デフォルトの名無しさん mailto:sage [2005/04/10(日) 02:32:31 ]
- >>326
>>313にも出てるけど、ロッド・ジョンソンの「J2EEシステムデザイン」はお勧めできる。
ttp://www.amazon.co.jp/exec/obidos/ASIN/4797322888/250-2144330-3153039
DI(あるいはIoC)コンテナ登場前夜に、EJBの問題点を詳細に書き表して、なおかつ
解決するための方法論を具体的なコードを交えて説明した名作だ。この本で紹介された
アイデアがそのまんまSpring Frameworkの基礎になってる事は有名。AOPの実現方法ま
でおんなじだし、Springの解説書か？と思えるほど。
まあロッド・ジョンソンがSpringの開発者なわけであたりまえなんだろうけど。
一方読む必要がないのは、「Java ブループリント」だな。人生を無駄遣いする事になる。
- 330 名前：デフォルトの名無しさん mailto:sage [2005/04/10(日) 02:53:18 ]
- >>328
そう、それだ。
エンタープライズ向け開発だと、いろんな技術レベルの人間があつまるから、かならず
基礎アーキテクチャを技術レベルが高い人間で実装するよな。
つまり技術レベルの低い人でも、決められた実装方法に従って普通のJavaプログラムと
して作れば、あとは基礎アーキテクチャが何とかするよ、という状態を作るわけだ。
そういうものの大部分って、ロジック層のシングルトン・オブジェクトをどうやって生成するか
とか、初期化を間違わないにはどうしたらいいかとか、EJBを取得するのにJNDI参照したり
RemoteExceptionを処理し忘れたりしないようにするにはどうしたらいいか、とか、
めんどくさいことばっかりなんだよな。
Springはそういうものの大部分を吸収してくれるし、EJBの利点の一つ、宣言的トランザクション
もサポートしてる。
正直、リモート呼び出しの必要性が無ければEJBを使う意味を見いだせない。
- 331 名前：デフォルトの名無しさん mailto:sage [2005/04/10(日) 03:25:34 ]
- 思うに、Spring自体が、EJBのめんどくさいところを解消する過程で産みだされたところを
ふまえとかないと、なんで「Spring楽だー」という輩がいるのか理解できなくて、>>307のような
感想になっても仕方がないと思う。
>>307
>その代わりにXMLファイルがごちゃごちゃして手に負えなくなる。
EJBのディプロイメント・ディスクリプタというXMLファイルは、SpringのXML定義の１０倍は
ごちゃごちゃしてて手に負えないんですよ。Springの構成ファイルは分かりやすいよ。
しかも構成ファイル一つでリモート呼び出しを除くEJBの機能を実現できるんだったら、
EJBに苦しめられた輩が採用しない理由はないよ。
- 332 名前：デフォルトの名無しさん [2005/04/10(日) 03:39:21 ]
- ふむ、ageとこう。
- 333 名前：デフォルトの名無しさん mailto:sage [2005/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 名前：デフォルトの名無しさん mailto:sage [2005/04/10(日) 08:58:20 ]
- >>328
Webじゃない普通のアプリについてはどう思ってるか教えて欲しい
- 335 名前：328 mailto:sage [2005/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 mailto:sage [2005/04/10(日) 13:11:02 ]
- >>335
さんきゅ
- 337 名前：デフォルトの名無しさん mailto:sage [2005/04/11(月) 02:58:25 ]
- Spring In Actionよりも、ロッド・ジョンソンの「Expert One-on-One J2EE Development without EJB」
を邦訳してほしいな。「J2EEシステムデザイン」の続編みたいな本だ。
- 338 名前：デフォルトの名無しさん mailto:sage [2005/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 名前：デフォルトの名無しさん mailto:sage [2005/04/11(月) 15:24:27 ]
- ああ、途中で送信してもうた。
>>335の
> BeanFactoryのアトリビュートへの設定と取り出しを管理するクラス自体は、Spring組み込みで提供されてる。
> しかしServletContextを使える場所でしかBeanFactoryを取得できないという制約が生まれる。
は、ApplicationContextを指していると思うんですけど、ApplicationContextの取り出しは、
>>338に書いたように、ServletContextから、↓の名前のクラスで埋められている、オブジェクトを取り出すんでOK？
「org.springframework.web.struts.ContextLoaderPlugIn.CONTEXT.」
それとも、ApplicationContextを取り出すには、こうする見たいなのってあるの？
- 340 名前：デフォルトの名無しさん mailto:sage [2005/04/11(月) 16:10:43 ]
- >>339
俺はこうしてるよ。
ApplicationContext ctx = WebApplicationContextUtils.getWebApplicationContext(servletContext);
- 341 名前：デフォルトの名無しさん mailto:sage [2005/04/11(月) 16:33:05 ]
- >>340
素早い回答サンクス！！！
やっぱり、ユーティリティはあったのね。
- 342 名前：デフォルトの名無しさん mailto:sage [2005/04/11(月) 22:03:14 ]
- アプリケーションを起動したまま、コンポーネントを入れ替える方法ってありますか？
- 343 名前：デフォルトの名無しさん mailto:sage [2005/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 名前：デフォルトの名無しさん mailto:sage [2005/04/12(火) 01:37:15 ]
- 1個のVMに1個のWebアプリケーションのみ配備する、という限定ならいいだろうね。
裏を返せば不適当ということ。
util.BeanFactoryHolderクラスは、
Servletコンテナに100個のWebアプリがディプロイされていても、
そのうちの1個でしか使えない。
もしくは、100個のWebアプリ間で1個のBeanFactoryを共有する。
- 345 名前：303 mailto:sage [2005/04/13(水) 01:02:58 ]
- ご意見色々ありがとー。勉強になりました。
上に出てきた本も読んでみます。
現状の漏れの考えは、
１．ビジネスロジックに再利用性は殆ど感じない（あるとしたら
ライブラリとかユーティリティ系）。
２．業務要件として拡張性が求められている箇所は、自分で
ファクトリを作らないでDIコンテナを利用するのは良いかも。
３．本読んだらかわるかも。
おまけ
EJBで作られたビジネスロジックのコンポーネントは殆ど見たことない
んだけど、それってEJBがめんどいからでは無くってやっぱり
ビジネスロジックに再利用性が無いからじゃないかなって、
思いまふ（UI系は除いて）。
beaが頑張ってる気もするけど、beaでこの程度かと。。。
- 346 名前：デフォルトの名無しさん mailto:sage [2005/04/13(水) 01:46:12 ]
- ビジネスロジックをインターフェース経由で使うのは再利用のためじゃなくて、
業務上の変更に耐えられるようにするためだよ。
EJBはほっといてもインターフェース中心になるんだけど、一つのオブジェクトに
対して４つのインターフェースが必要だったりして馬鹿くさいので誰もやらんのだ
と思うけど。
おれもトランザクション・スクリプトというか、関数プログラミング的に作っても
追いつくときは、極端にstaticメソッドだけでビジネスロジックを組んだこともある。
でもドメインモデルみたいに、各ビジネスロジック・オブジェクトが他のオブジェクト
と結びつき合ってる場合だと、業務の変更に対応する場合に、クラス構成を変えた
ほうが早いという場合もあるよ。
「請求書サービス」を「請求書サービス」と「売掛統計サービス」と「台帳サービス」
の三つに分解して、請求サービスのデータ登録メソッドを呼び出したら統計と
台帳も更新するように変えたって、請求書サービスのインターフェースがかわら
なければコントローラに影響を与えない。
逆に、オブジェクトが互いに依存し合ったドメインモデルのようなものを作らない
なら、別段困らないようにも思う。
- 347 名前：デフォルトの名無しさん mailto:sage [2005/04/18(月) 21:27:23 ]
- Spring入門が発売されましたなぁ
- 348 名前：デフォルトの名無しさん [2005/04/18(月) 23:07:17 ]
- 今読んでます
- 349 名前：デフォルトの名無しさん [2005/04/18(月) 23:27:43 ]
- どんな感じ？
- 350 名前：デフォルトの名無しさん mailto:sage [2005/04/19(火) 09:09:14 ]
- 俺は確保はしたがまだきちんと読んでない。
iBATIS との連携について書いてあったのがわりと新鮮だった感じ。
(もちろん Hibernate との連携も抑えてあった。)
Spring in Action の方が読み応えありそうなので
そっちを最初に片付けようと思ってる。
- 351 名前：デフォルトの名無しさん mailto:sage [2005/04/19(火) 22:02:23 ]
- >>349
入門書という位置づけのようだが、定義ファイルに関する説明が
一覧表ですまされていたりするので、本当に初めての人がこの本で
Springを使えるようになるのかはちょっと疑問。
ApplicationContextのメッセージソースやイベントの説明はあるのに
FactoryBeanの説明がないっていうのは妥当な判断だろうか？
AOPも定義ファイルに書く使い方の前にProxyFactoryを直接使った例で
説明する意味はあるのだろうか？
DIとAOPという一番ベーシックな部分の説明が弱いのが入門書としては
難点だと思う。といって応用的な話があるわけでもなく…
- 352 名前：デフォルトの名無しさん mailto:sage [2005/04/19(火) 22:48:59 ]
- >>350-351
サンキュ
Seasar2をちょっと触ってみたぐらいの俺だけど、Spring in Actionを買ってみます
- 353 名前：デフォルトの名無しさん mailto:sage [2005/04/19(火) 22:54:31 ]
- Spring入門、俺も読み始めました。
内容はおいといて、文章は少しウザイ。
- 354 名前：デフォルトの名無しさん mailto:sage [2005/04/20(水) 17:55:55 ]
- JDBCコネクションをプーリングしたいんですが、どんな方法があるのでしょうか？
- 355 名前：デフォルトの名無しさん mailto:sage [2005/04/20(水) 20:01:54 ]
- Webならサーブレットコンテナまかせ。
- 356 名前：デフォルトの名無しさん mailto:sage [2005/04/21(木) 00:52:01 ]
- >>354
Springで使うのなら、Apache Commons DBCPが一番お手軽かな
ttp://jakarta.apache.org/commons/dbcp/
- 357 名前：デフォルトの名無しさん mailto:sage [2005/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 名前：デフォルトの名無しさん mailto:sage [2005/04/21(木) 10:06:14 ]
- >>355,356
まずはDBCPから始めてみます。
- 359 名前：デフォルトの名無しさん mailto:sage [2005/04/21(木) 11:51:42 ]
- >>357
本屋に逝って JavaPress Vol.41 を嫁
- 360 名前：デフォルトの名無しさん mailto:sage [2005/04/21(木) 12:27:25 ]
- >>359
持ってるけど大したこと書いてない
spring.jar他をクラスパスに通せと必要に応じてsrcやdoc以下を参照しろってだけ
spring.jarくらいならともかく，その他のlibにあるJARを手間かけずにまとめて
クラスパスに設定したいなんて誰も考えないってこと？
- 361 名前：デフォルトの名無しさん [2005/04/21(木) 20:41:26 ]
- JSFやSeasarの陰に隠れてもはや風前の灯火…。
- 362 名前：デフォルトの名無しさん mailto:sage [2005/04/21(木) 22:00:16 ]
- >360
spring 使うことで増える lib は
spring.jar と aopalliance.jar
(AOP する人は cglib もか)程度なんで、
別に特別たくさん増やすとかいうわけでもないので
そんなに問題になると思わないんですが。
Spring のソース見る分にはlib/以下のjar
にclasspath通しまくる必要なんてないし。
- 363 名前：デフォルトの名無しさん mailto:sage [2005/04/21(木) 22:09:55 ]
- >>361
JSFの影にかくれるとか言ってる時点で、Springがなんなのかわかってないだけということをさらしてるわけですね。
- 364 名前：デフォルトの名無しさん mailto:sage [2005/04/21(木) 22:13:01 ]
- >>361
で、どれが良いのか言ってみそ
- 365 名前：デフォルトの名無しさん mailto:sage [2005/04/21(木) 22:58:54 ]
- >>364
EJB3.0
- 366 名前：デフォルトの名無しさん mailto:sage [2005/04/22(金) 13:58:47 ]
- ふぅ〜、アフォ発見。たまに湧いて出るこういうボケも、一種の清涼剤か。
- 367 名前：デフォルトの名無しさん mailto:sage [2005/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 名前：デフォルトの名無しさん mailto:sage [2005/04/23(土) 00:29:07 ]
- こんなこと書くと荒れるかもしれないが
SpringとSeasarって国内の業務ではどっちが多く使われてるのかな？
- 369 名前：デフォルトの名無しさん mailto:sage [2005/04/23(土) 02:19:57 ]
- 現実的にはSpringかと。
ただ、オープンソースのプロダクトの利用数を数えるのは難しい上、両方そこまで大々的には使われてないから実数はよくわからない罠。
- 370 名前：デフォルトの名無しさん [2005/04/23(土) 22:42:23 ]
- 1.2のRC2が出てるが、
なんか役に立ちそうな機能追加された？
- 371 名前：デフォルトの名無しさん mailto:sage [2005/04/24(日) 01:21:41 ]
- Hibernate3対応かな？
- 372 名前：368 mailto:sage [2005/04/24(日) 19:14:40 ]
- >>369
thx!
- 373 名前：デフォルトの名無しさん mailto:sage [2005/04/24(日) 19:30:21 ]
- >>372
ただ、Spring使ってる人のまわりではSpringばっかりだし、Seasar2使ってる人のまわりではSeasar2ばっかりだから、人の意見はあまりあてにならんけどね。
- 374 名前：デフォルトの名無しさん mailto:sage [2005/05/06(金) 13:30:15 ]
- すまん、DIはよく知らんのだが、よくEJBは××だからDIまんせー的な
発言見るんだけど、そもそもDIってリモートコールできんの？
- 375 名前：デフォルトの名無しさん mailto:sage [2005/05/06(金) 13:58:11 ]
- DIパターンとリモートコールは全然関係ない領域の話だとおもうがね。
- 376 名前：デフォルトの名無しさん mailto:sage [2005/05/06(金) 14:30:44 ]
- 一つ聞きたいんですが
ttp://wiki.bmedianode.com/Spring/?%BC%D9%B0%AD%A4%CASingleton
↑のページを参考に beanRefContext.xml を書いたのですが
Spring が DEBUG メッセージを吐くのでちと気持ち悪いです。
ログは汚れるものの、期待通りの動作はしています。
型の合うコンストラクタが見つからないとか、そんな感じのメッセージなのですが
確かに ClassPathXmlApplicationContext のコンストラクタに
java.util.ArrayList を持つものはない模様で
この辺りは「一通りコンストラクタ調べたけどないっぽいから
String[] だと思って処理しよう」とかそんな流れでしょうか？
この辺り、ログを汚さないでスマートに指定する方法を教えていただけないでしょうか？
- 377 名前：デフォルトの名無しさん mailto:sage [2005/05/06(金) 18:37:22 ]
- Springをちょっとずつ勉強しててＤＩのあたりまでわかったところなんですが、
AOP周りにも触ってみようと思ってます。
で、AOPって、具体的にはどんなことに使えるのかサッパリわかりません。
ログとる例ばっかりで、他に出来ることはないのか？って感じなんですが、
何に使うんですか？AOP
コンテナ側では使ってるのは理解できるんですが。
具体的な用途や、参考になるページがあったら
すみませんが教えてもらえないでしょうか。
- 378 名前：デフォルトの名無しさん mailto:sage [2005/05/07(土) 03:33:48 ]
- AOPの二大用途といえば、
- ロギング
- トランザクション
だわな
- 379 名前：デフォルトの名無しさん mailto:sage [2005/05/07(土) 05:15:36 ]
- Webの場合はそのくらいだな。
- 380 名前：デフォルトの名無しさん mailto:sage [2005/05/07(土) 06:30:47 ]
- GUIのプログラムの場合、データ変更の画面への通知もAOPがいい。
- 381 名前：デフォルトの名無しさん mailto:sage [2005/05/07(土) 06:33:45 ]
- イベントリスナーとかの代わりにって事？
- 382 名前：デフォルトの名無しさん mailto:sage [2005/05/07(土) 06:58:12 ]
- GUIモノだと、だいたいセッターの後でnotifyみたいなの呼び出す必要があって、かなりめんどい。
それがAOPで楽できる。
- 383 名前：デフォルトの名無しさん mailto:sage [2005/05/07(土) 08:04:05 ]
- 効率を無視していいなら良いんじゃないの
- 384 名前：デフォルトの名無しさん mailto:sage [2005/05/07(土) 08:38:48 ]
- 無視していいわけないけど、影響が少なければ問題ない。
- 385 名前：377 mailto:sage [2005/05/07(土) 12:01:00 ]
- どうもありがとうございます。Web系なんですが、ログもトランザクションも
Springだとそのための手段が用意されてるのでなかなか使い道が難しいですね。
昔ＧＵＩも作ったことあったのですが、その例もなるほどなって思いました。
面倒ですものね。「横断的関心」ってやつがちょっとイメージできた気がします。
探してたら、こんなページも見つけました。難しいので理解できてませんが
ttp://www.oucc.org/~tail/aspectj/index.php?%A5%A2%A5%B9%A5%DA%A5%AF%A5%C8%A4%CE%CD%F8%CD%D1%CA%FD%CB%A1
- 386 名前：デフォルトの名無しさん mailto:sage [2005/05/07(土) 12:03:14 ]
- あ、すいません。ログはないですね。
- 387 名前：デフォルトの名無しさん mailto:sage [2005/05/08(日) 13:35:51 ]
- >>386
org.springframework.aop.interceptor.TraceInterceptor
org.springframework.aop.interceptor.DebugInterceptor
- 388 名前：デフォルトの名無しさん mailto:sage [2005/05/08(日) 18:55:53 ]
- >>375
質問した者だが
いやそうじゃなくて、じゃあそもそもEJBと比較して意味あんのかって意味。
分散オブジェクト技術とそうでない技術なら話してる土台が違うわけで
DI>>EJBとかわけわかんないんだけど。
- 389 名前：デフォルトの名無しさん mailto:sage [2005/05/08(日) 19:18:26 ]
- >>388
EJBは分散が必要ない人にも分散を前提としためんどうな手続きを強要してた。
ほとんどの人に分散は必要なかった。
ほとんどの人にDI+ORM > EJB。
- 390 名前：デフォルトの名無しさん mailto:sage [2005/05/08(日) 19:21:41 ]
- >>389
てか分散使わないのにEJB使ってる時点でどうかと・・。
まぁ後者のORMとかはわからなくもないが、EJBは
どっちかっつーと、というかどう考えても分散オブジェクトなわけで。
- 391 名前：デフォルトの名無しさん mailto:sage [2005/05/08(日) 19:35:40 ]
- で、だからEJB使わずDI+ORMでいいじゃんとなったんでしょ。
- 392 名前：デフォルトの名無しさん mailto:sage [2005/05/08(日) 21:33:10 ]
- >>391があたりまえだがいいことをいった。
- 393 名前：デフォルトの名無しさん mailto:sage [2005/05/08(日) 22:17:34 ]
- >>390
まあ、EJBには分散以外にもいい点があるわけで。
宣言的なトランザクションとか、SQLを直接書かないDBMSアクセスとか。
そういEJBのよい機能は使いたいけど、
EJBは動かすの面倒、重い、コンテナに依存してテストしづらい
ってのがあって、その打開策としてSpringをはじめとして色々な
ソフトが出てきているわけだよな。
- 394 名前：デフォルトの名無しさん mailto:sage [2005/05/08(日) 23:26:16 ]
- EJBってのはむしろCORBAの世界で
生きるはずなのだが。
- 395 名前：デフォルトの名無しさん mailto:sage [2005/05/08(日) 23:38:34 ]
- それはない。
- 396 名前：デフォルトの名無しさん [2005/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 名前：デフォルトの名無しさん mailto:sage [2005/05/12(木) 19:55:24 ]
- そりゃeCacheのjarを用意していないからでは
- 398 名前：デフォルトの名無しさん mailto:sage [2005/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 名前：デフォルトの名無しさん mailto:sage [2005/05/15(日) 22:24:06 ]
- >>398
私も同じ現象起きてます。
"/WEB-INF/lib/applicationContext.xml"という指定をすると
WEB-INFが見当たらないというエラーが返ってきます
なんでかしらんけど、パッケージの中しかパスが認識されないんです
だから
"/jp/co/sample/applicationContext.xml"
みたいにすると読み込めるんですよ。
でもソースのパッケージの中に設定入れとくのはちょっと気持ち悪いな、といった感じです
私はEclipseでTomcatプラグイン使用してますけど
Web.xmlの設定とかが必要なのかなー
- 400 名前：399 mailto:sage [2005/05/15(日) 22:30:21 ]
- レスした後に気づいたけど
>で、コンテキストは取得できましたが、パスを取り出す方法はないでしょうか？
>（もちろんコンテキストからでなくても構わないです。）
これどいう言う意味ですかね？
絶対パスで指定しなければルート（WEB-INFなのか？）から
フォルダをなめていってくれてapplicationContextを探すってことですかね。
不勉強ですいませんorz
- 401 名前：デフォルトの名無しさん mailto:sage [2005/05/16(月) 05:36:09 ]
- つか、Webアプリだったらweb.xmlに設定書いた設定使うようにすりゃいいじゃん。
- 402 名前：398 mailto:sage [2005/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 名前：デフォルトの名無しさん mailto:sage [2005/05/17(火) 08:11:38 ]
- >>402
HttpServletを継承していない普通のクラスが、
/WEB-INF/なんて、HTTP固有のディレクトリ構造に
依存することを良しとする訳ですか。
- 404 名前：デフォルトの名無しさん mailto:sage [2005/05/17(火) 08:46:55 ]
- 基本的には普通のクラスはDIコンテナの存在を気にしないようにするね。
- 405 名前：デフォルトの名無しさん mailto:sage [2005/05/17(火) 08:47:10 ]
- Servletクラスは絶対パスを取得できるので、そのパスをもらえばいいのでは？
- 406 名前：デフォルトの名無しさん mailto:sage [2005/05/17(火) 09:11:58 ]
- サーブレットからApplicationContext自体をもらえばいいね。
- 407 名前：デフォルトの名無しさん mailto:sage [2005/05/17(火) 14:22:24 ]
- FileSystemXmlApplicationContextではだめかいな？
- 408 名前：デフォルトの名無しさん mailto:sage [2005/05/17(火) 17:29:46 ]
- 皆さんどうもありがとうございます。
>>403
/WEB-INF/data にアプリが使うデータファイル置くのは一般的に言って変ですか？
/dataでもいいので普通はそうなら変更を考えます。まだ作法に慣れてないもので勉強します。
>>404
そのクラスは相手がDBじゃなくてファイルなんですがDaoと同じ様な役割をさせたいクラスなんで
他のDaoクラスと同じようにDIコンテナからロードさせてるんですよ。
で、Servletとか関係ない層で動いてるんですが実際のパス取得をどうしようかと悩んでます。
Springのフレームワークからそういうのとれないのかなと考えてましたが、的違いでしたでしょうか？
>>405-407
結局Servletクラスからパスをもらうことにしました。
正直に言ってまだ釈然としないものが残っているんですが、一般的にそうなら慣れるしかないですね
- 409 名前：デフォルトの名無しさん mailto:sage [2005/05/17(火) 21:41:41 ]
- いにしえのServlet/JavaBeans流：jarファイル近辺のPropertiesファイルか取得
：
J2EE流：JNDIからデータの位置を取得
Connectorアーキテクチャでデータを供給
：
Spring Framework： ？
- 410 名前：デフォルトの名無しさん mailto:sage [2005/05/17(火) 22:37:48 ]
- >>408
ふつうは、普通のクラスはDIコンテナの存在を気にしないでいいようにする
- 411 名前：デフォルトの名無しさん mailto:sage [2005/05/17(火) 22:39:07 ]
- >>408
設計が悪いときに無理をしないといけないのは一般的な話だから気にするな。
- 412 名前：デフォルトの名無しさん mailto:sage [2005/05/17(火) 23:28:33 ]
- >>409
BeanFactoryから取得
- 413 名前：デフォルトの名無しさん mailto:sage [2005/05/17(火) 23:41:41 ]
- BeanFactoryはどこからファイル所在を取得するつもり？
|
 |
