- 1 名前:デフォルトの名無しさん mailto:sage [04/02/23 00:51]
- www.springframework.org/
乱立するフレームワークと競合するプロトコルの嵐のなかで、 リスクの高い決断を余儀なくされているJavaデベロッパ、プ ロジェクトマネージャに対する福音です。 語るべし。
- 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 ]
- ご意見色々ありがとー。勉強になりました。
上に出てきた本も読んでみます。 現状の漏れの考えは、 1.ビジネスロジックに再利用性は殆ど感じない(あるとしたら ライブラリとかユーティリティ系)。 2.業務要件として拡張性が求められている箇所は、自分で ファクトリを作らないでDIコンテナを利用するのは良いかも。 3.本読んだらかわるかも。 おまけ EJBで作られたビジネスロジックのコンポーネントは殆ど見たことない んだけど、それってEJBがめんどいからでは無くってやっぱり ビジネスロジックに再利用性が無いからじゃないかなって、 思いまふ(UI系は除いて)。 beaが頑張ってる気もするけど、beaでこの程度かと。。。
- 346 名前:デフォルトの名無しさん mailto:sage [2005/04/13(水) 01:46:12 ]
- ビジネスロジックをインターフェース経由で使うのは再利用のためじゃなくて、
業務上の変更に耐えられるようにするためだよ。 EJBはほっといてもインターフェース中心になるんだけど、一つのオブジェクトに 対して4つのインターフェースが必要だったりして馬鹿くさいので誰もやらんのだ と思うけど。 おれもトランザクション・スクリプトというか、関数プログラミング的に作っても 追いつくときは、極端に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をちょっとずつ勉強しててDIのあたりまでわかったところなんですが、
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だとそのための手段が用意されてるのでなかなか使い道が難しいですね。 昔GUIも作ったことあったのですが、その例もなるほどなって思いました。 面倒ですものね。「横断的関心」ってやつがちょっとイメージできた気がします。 探してたら、こんなページも見つけました。難しいので理解できてませんが 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はどこからファイル所在を取得するつもり?
- 414 名前:398 mailto:sage [2005/05/17(火) 23:59:50 ]
- 398です。お忙しいとこ何度もすみません。
>>410 ということは、Spring のアプリケーションコンテキストに依存せず、他の(サーブレットを継承していて サーバ環境にアクセス可能な)クラスからもらってくる方法はまだマシという理解であってますか? >>411 設計が悪いのなら直したいのです。>>409さんが書いている様に、Springやその他のDIコンテナ (すみませんがJ2EE/EJBは知りません)を使ったときの作法があるのなら、この機会に 身に着けたいと思ってます。普通のクラスが外部リソースにアクセスする一般的な方法を 教えてもらえませんか?
- 415 名前:デフォルトの名無しさん mailto:sage [2005/05/18(水) 00:17:47 ]
- >>413
そりゃサーバサイドだったら、web.xmlじゃないか? JNDIだってどっかにJNDIのInicialContextFactoryを指定する(プロパティとか)のと同じ事だとおもうけど。
- 416 名前:デフォルトの名無しさん mailto:sage [2005/05/18(水) 00:44:57 ]
- つまり、根っこはプロパティ
- 417 名前:デフォルトの名無しさん mailto:sage [2005/05/18(水) 00:45:37 ]
- web.xml使うのは、Servlet層だけの簡単アプリ
- 418 名前:デフォルトの名無しさん mailto:sage [2005/05/19(木) 06:47:36 ]
- DIしたオブジェクトから先は、いもづる式にDIするようにして、DIコンテナを意識しないとか。
- 419 名前:デフォルトの名無しさん mailto:sage [2005/05/19(木) 10:10:35 ]
- >>418
最初は芋づる式って密な感じがして気持ち悪かったけど 実装してみたら楽すぎて止めらんね どういった点でデメリットが出てくるんだろうか
- 420 名前:デフォルトの名無しさん [2005/06/01(水) 08:56:52 ]
- JSF+Springで設計してんですけど
JSFのバッキングビーンのクラスとビジネスロジックのクラスのそれぞれの役割で バッキングビーン 値のチェック、変換(この辺はバリデータ、コンバータに 任せるべきなんだろう)などのビジネスロジック呼び出す前の処理 あと、ビジネスロジックの結果の後処理 ビジネスロジック 必要なDAOを呼ぶだけ こんな風に考えてます。これだとビジネスロジックのクラスが たいした役割ではないと思うんですけど、DAOのファサード風と考えてよいでしょか JSF+Springのサンプルアプリがみたいどすえ〜
- 421 名前:デフォルトの名無しさん [2005/06/01(水) 10:05:15 ]
- >>420
>JSF+Springのサンプルアプリがみたいどすえ〜 https://appfuse.dev.java.net/ https://equinox.dev.java.net/ 漏れ自身が勉強中なので情報提供のみで失礼。
- 422 名前:デフォルトの名無しさん [2005/06/01(水) 10:47:23 ]
- >>420
DBのモデルを単に画面に表示する・画面に入力した値をDBに格納する みたいなシンプルなアプリだとそうなるかもね。
- 423 名前:デフォルトの名無しさん mailto:sage [2005/06/01(水) 10:50:24 ]
- sageついでに
>ビジネスロジック呼び出す前の処理 >あと、ビジネスロジックの結果の後処理 どのレベルの処理を言ってるのかわからないけど、 本当にMVCレイヤに置くべき処理なのか再検討してみては?
- 424 名前:デフォルトの名無しさん mailto:sage [2005/06/01(水) 11:58:03 ]
-
この本どうよ?書評キボンヌ 『実践Spring Framework―J2EE開発を変えるDIコンテナのすべて』 www.amazon.co.jp/exec/obidos/ASIN/4822221431 『入門Spring』と『軽快なJava』は読みました。さらに詳しい話を 聞きたい、という目的に使えますかね?
- 425 名前:デフォルトの名無しさん mailto:sage [2005/06/02(木) 22:11:28 ]
- SpringがJSFとXULをイイ感じに仲介するフレームワーク作ってくれたら
一杯おごってやりたい。
- 426 名前:デフォルトの名無しさん mailto:sage [2005/06/03(金) 12:15:51 ]
- >>425
Mozilla独自のXULより標準規格のXFormsのほうが良いのでは? MozillaもOpenOffice.orgもXFormsに対応する上に、 Chibaを使えばXForms未対応のブラウザに対して HTML+JavaScriptに変換してから送信することで 大部分のブラウザに対応できます。 Chiba (サーバーサイドJavaライブラリ) chiba.sourceforge.net/ MozillaとXForms (Mozilla1.8/Firefox1.1で対応予定) www.mozilla-japan.org/projects/xforms/ [XForms 00031] XFormsのためのwiki (村田真氏がMozillaでXForms推進) www2.xml.gr.jp/log.html?MLID=xforms&N=31
- 427 名前:デフォルトの名無しさん [2005/06/03(金) 12:41:43 ]
- >>426
XULへの必要性は一般の人にとっては低いとは思うが、 >>425は、ブラウザベースクライアントじゃなくて、リッチクライアントとして XULを使うことを前提に書いてるんじゃなかろうか。 JSF経由でSwingとかFlashをクライアントにするノリで。
- 428 名前:デフォルトの名無しさん mailto:sage [2005/06/03(金) 12:42:00 ]
- sage
- 429 名前:デフォルトの名無しさん mailto:sage [2005/06/22(水) 09:39:06 ]
- 禿げオヤジは意外とおとなしかったな。
- 430 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 15:34:01 ]
- 海外では50%以上のプロジェクトで使われていて
ほぼデファクトスタンダードらしいが、なぜこのスレは伸びないの?
- 431 名前:デフォルトの名無しさん mailto:sage [2005/06/25(土) 18:21:20 ]
- まあ、DIスレも伸び悩んでるし、
カテゴリとしてマイナーなんでは。日本では。
- 432 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 08:56:09 ]
- >>430
DIは、使い始めれば空気みたいなもんで、とくに議論することもなくなるから。
- 433 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 16:54:53 ]
- つーかSpringがホントに便利なのって純粋なtype2,type3のInjectionその物より、
コンテナが作ったProxyに対するAOPでしょ?
- 434 名前:デフォルトの名無しさん mailto:sage [2005/06/26(日) 22:33:01 ]
- DIってのは、そういうものを便利にするための裏方だからな。
- 435 名前:デフォルトの名無しさん [2005/06/27(月) 10:43:51 ]
- このスレ生きてるみたいだから質問させてくれ
proxyでAspectをweavingする事の弱点って何だ? 漏れが把握しているのは 1.自分自身のメソッドを呼び出すとAspectがかからない。 2.visitorみたくthisを渡して処理させるとAspectがかからない。 他に注意点ある?
|

|