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

Java Spring Frameworkを語るスレ

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

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

語るべし。
0329デフォルトの名無しさん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 ブループリント」だな。人生を無駄遣いする事になる。
0330デフォルトの名無しさん2005/04/10(日) 02:53:18
>>328
そう、それだ。
エンタープライズ向け開発だと、いろんな技術レベルの人間があつまるから、かならず
基礎アーキテクチャを技術レベルが高い人間で実装するよな。

つまり技術レベルの低い人でも、決められた実装方法に従って普通のJavaプログラムと
して作れば、あとは基礎アーキテクチャが何とかするよ、という状態を作るわけだ。

そういうものの大部分って、ロジック層のシングルトン・オブジェクトをどうやって生成するか
とか、初期化を間違わないにはどうしたらいいかとか、EJBを取得するのにJNDI参照したり
RemoteExceptionを処理し忘れたりしないようにするにはどうしたらいいか、とか、
めんどくさいことばっかりなんだよな。

Springはそういうものの大部分を吸収してくれるし、EJBの利点の一つ、宣言的トランザクション
もサポートしてる。

正直、リモート呼び出しの必要性が無ければEJBを使う意味を見いだせない。
0331デフォルトの名無しさん2005/04/10(日) 03:25:34
思うに、Spring自体が、EJBのめんどくさいところを解消する過程で産みだされたところを
ふまえとかないと、なんで「Spring楽だー」という輩がいるのか理解できなくて、>>307のような
感想になっても仕方がないと思う。

>>307
>その代わりにXMLファイルがごちゃごちゃして手に負えなくなる。

EJBのディプロイメント・ディスクリプタというXMLファイルは、SpringのXML定義の10倍は
ごちゃごちゃしてて手に負えないんですよ。Springの構成ファイルは分かりやすいよ。
しかも構成ファイル一つでリモート呼び出しを除くEJBの機能を実現できるんだったら、
EJBに苦しめられた輩が採用しない理由はないよ。
0332デフォルトの名無しさん2005/04/10(日) 03:39:21
ふむ、ageとこう。
0333デフォルトの名無しさん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ンヽ/ムノじ

0334デフォルトの名無しさん2005/04/10(日) 08:58:20
>>328
Webじゃない普通のアプリについてはどう思ってるか教えて欲しい
03353282005/04/10(日) 10:12:52
>>334
今回は、通常のアプリとWebアプリとどちらでもSpringを使った。
Webアプリのほうが制約があり、通常のアプリのほうがより自由というのが回答。

Springの構成は、まず通常のJavaアプリで使えるコアがある。
optionalな形でSpring WebなどのWebアプリ用サポートがある。

Springは、BeanFactoryという汎用のファクトリに識別子を渡して生成してもらうのだが、
このファクトリのインスタンスをどこかに保存しておく必要がある。
保存しない場合は、ファクトリのインスタンスを毎回newする必要が出てくる。
これは毎回設定を解釈するというコストをかけることとイコールだ。

で、通常のアプリならメインクラスのメンバにでも入れておけばよい。
これがWebアプリだと、applicationスコープのアトリビュートに放り込むことになる。

BeanFactoryのアトリビュートへの設定と取り出しを管理するクラス自体は、Spring組み込みで提供されてる。
しかしServletContextを使える場所でしかBeanFactoryを取得できないという制約が生まれる。

ちゃんとクラス設計していれば問題は生じないけど、
ちょっと工夫してあげなきゃならない場面もでてくる。

まああれだ。たぶん大丈夫だよ。
心配なら一度ファクトリ部分のソースを追って、中身を確認したらどうだろう。
変な制約はないし、シンプルで、不安は生まれないと思う。
03363342005/04/10(日) 13:11:02
>>335
さんきゅ
0337デフォルトの名無しさん2005/04/11(月) 02:58:25
Spring In Actionよりも、ロッド・ジョンソンの「Expert One-on-One J2EE Development without EJB」
を邦訳してほしいな。「J2EEシステムデザイン」の続編みたいな本だ。
0338デフォルトの名無しさん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.");
0339デフォルトの名無しさん2005/04/11(月) 15:24:27
ああ、途中で送信してもうた。

>>335
> BeanFactoryのアトリビュートへの設定と取り出しを管理するクラス自体は、Spring組み込みで提供されてる。
> しかしServletContextを使える場所でしかBeanFactoryを取得できないという制約が生まれる。

は、ApplicationContextを指していると思うんですけど、ApplicationContextの取り出しは、
>>338に書いたように、ServletContextから、↓の名前のクラスで埋められている、オブジェクトを取り出すんでOK?
「org.springframework.web.struts.ContextLoaderPlugIn.CONTEXT.」

それとも、ApplicationContextを取り出すには、こうする見たいなのってあるの?
0340デフォルトの名無しさん2005/04/11(月) 16:10:43
>>339
俺はこうしてるよ。
ApplicationContext ctx = WebApplicationContextUtils.getWebApplicationContext(servletContext);
0341デフォルトの名無しさん2005/04/11(月) 16:33:05
>>340
素早い回答サンクス!!!
やっぱり、ユーティリティはあったのね。
0342デフォルトの名無しさん2005/04/11(月) 22:03:14
アプリケーションを起動したまま、コンポーネントを入れ替える方法ってありますか?
0343デフォルトの名無しさん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"/>
0344デフォルトの名無しさん2005/04/12(火) 01:37:15
1個のVMに1個のWebアプリケーションのみ配備する、という限定ならいいだろうね。
裏を返せば不適当ということ。

util.BeanFactoryHolderクラスは、
Servletコンテナに100個のWebアプリがディプロイされていても、
そのうちの1個でしか使えない。
もしくは、100個のWebアプリ間で1個のBeanFactoryを共有する。
03453032005/04/13(水) 01:02:58
ご意見色々ありがとー。勉強になりました。
上に出てきた本も読んでみます。

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

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

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

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

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

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

逆に、オブジェクトが互いに依存し合ったドメインモデルのようなものを作らない
なら、別段困らないようにも思う。
0347デフォルトの名無しさん2005/04/18(月) 21:27:23
Spring入門が発売されましたなぁ
0348デフォルトの名無しさん2005/04/18(月) 23:07:17
今読んでます
0349デフォルトの名無しさん2005/04/18(月) 23:27:43
どんな感じ?
0350デフォルトの名無しさん2005/04/19(火) 09:09:14
俺は確保はしたがまだきちんと読んでない。
iBATIS との連携について書いてあったのがわりと新鮮だった感じ。
(もちろん Hibernate との連携も抑えてあった。)

Spring in Action の方が読み応えありそうなので
そっちを最初に片付けようと思ってる。
0351デフォルトの名無しさん2005/04/19(火) 22:02:23
>>349
入門書という位置づけのようだが、定義ファイルに関する説明が
一覧表ですまされていたりするので、本当に初めての人がこの本で
Springを使えるようになるのかはちょっと疑問。
ApplicationContextのメッセージソースやイベントの説明はあるのに
FactoryBeanの説明がないっていうのは妥当な判断だろうか?
AOPも定義ファイルに書く使い方の前にProxyFactoryを直接使った例で
説明する意味はあるのだろうか?
DIとAOPという一番ベーシックな部分の説明が弱いのが入門書としては
難点だと思う。といって応用的な話があるわけでもなく…
0352デフォルトの名無しさん2005/04/19(火) 22:48:59
>>350-351
サンキュ
Seasar2をちょっと触ってみたぐらいの俺だけど、Spring in Actionを買ってみます
0353デフォルトの名無しさん2005/04/19(火) 22:54:31
Spring入門、俺も読み始めました。
内容はおいといて、文章は少しウザイ。
0354デフォルトの名無しさん2005/04/20(水) 17:55:55
JDBCコネクションをプーリングしたいんですが、どんな方法があるのでしょうか?
0355デフォルトの名無しさん2005/04/20(水) 20:01:54
Webならサーブレットコンテナまかせ。
0356デフォルトの名無しさん2005/04/21(木) 00:52:01
>>354
Springで使うのなら、Apache Commons DBCPが一番お手軽かな
ttp://jakarta.apache.org/commons/dbcp/
0357デフォルトの名無しさん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してからインポート?
みんなどうしてる?
0358デフォルトの名無しさん2005/04/21(木) 10:06:14
>>355,356
まずはDBCPから始めてみます。
0359デフォルトの名無しさん2005/04/21(木) 11:51:42
>>357
本屋に逝って JavaPress Vol.41 を嫁
0360デフォルトの名無しさん2005/04/21(木) 12:27:25
>>359
持ってるけど大したこと書いてない
spring.jar他をクラスパスに通せと必要に応じてsrcやdoc以下を参照しろってだけ
spring.jarくらいならともかく,その他のlibにあるJARを手間かけずにまとめて
クラスパスに設定したいなんて誰も考えないってこと?
0361デフォルトの名無しさん2005/04/21(木) 20:41:26
JSFやSeasarの陰に隠れてもはや風前の灯火…。
0362デフォルトの名無しさん2005/04/21(木) 22:00:16
>360
spring 使うことで増える lib は
spring.jar と aopalliance.jar
(AOP する人は cglib もか)程度なんで、
別に特別たくさん増やすとかいうわけでもないので
そんなに問題になると思わないんですが。

Spring のソース見る分にはlib/以下のjar
にclasspath通しまくる必要なんてないし。
0363デフォルトの名無しさん2005/04/21(木) 22:09:55
>>361
JSFの影にかくれるとか言ってる時点で、Springがなんなのかわかってないだけということをさらしてるわけですね。
0364デフォルトの名無しさん2005/04/21(木) 22:13:01
>>361
で、どれが良いのか言ってみそ
0365デフォルトの名無しさん2005/04/21(木) 22:58:54
>>364
EJB3.0
0366デフォルトの名無しさん2005/04/22(金) 13:58:47
ふぅ〜、アフォ発見。たまに湧いて出るこういうボケも、一種の清涼剤か。
0367デフォルトの名無しさん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 ですが、これはしばらくこのままで行きたいです。)
0368デフォルトの名無しさん2005/04/23(土) 00:29:07
こんなこと書くと荒れるかもしれないが
SpringとSeasarって国内の業務ではどっちが多く使われてるのかな?
0369デフォルトの名無しさん2005/04/23(土) 02:19:57
現実的にはSpringかと。
ただ、オープンソースのプロダクトの利用数を数えるのは難しい上、両方そこまで大々的には使われてないから実数はよくわからない罠。
0370デフォルトの名無しさん2005/04/23(土) 22:42:23
1.2のRC2が出てるが、
なんか役に立ちそうな機能追加された?
0371デフォルトの名無しさん2005/04/24(日) 01:21:41
Hibernate3対応かな?
03723682005/04/24(日) 19:14:40
>>369
thx!
0373デフォルトの名無しさん2005/04/24(日) 19:30:21
>>372
ただ、Spring使ってる人のまわりではSpringばっかりだし、Seasar2使ってる人のまわりではSeasar2ばっかりだから、人の意見はあまりあてにならんけどね。
0374デフォルトの名無しさん2005/05/06(金) 13:30:15
すまん、DIはよく知らんのだが、よくEJBは××だからDIまんせー的な
発言見るんだけど、そもそもDIってリモートコールできんの?
0375デフォルトの名無しさん2005/05/06(金) 13:58:11
DIパターンとリモートコールは全然関係ない領域の話だとおもうがね。
0376デフォルトの名無しさん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[] だと思って処理しよう」とかそんな流れでしょうか?
この辺り、ログを汚さないでスマートに指定する方法を教えていただけないでしょうか?
0377デフォルトの名無しさん2005/05/06(金) 18:37:22
Springをちょっとずつ勉強しててDIのあたりまでわかったところなんですが、
AOP周りにも触ってみようと思ってます。

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

コンテナ側では使ってるのは理解できるんですが。
具体的な用途や、参考になるページがあったら
すみませんが教えてもらえないでしょうか。
0378デフォルトの名無しさん2005/05/07(土) 03:33:48
AOPの二大用途といえば、

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

だわな
0379デフォルトの名無しさん2005/05/07(土) 05:15:36
Webの場合はそのくらいだな。
0380デフォルトの名無しさん2005/05/07(土) 06:30:47
GUIのプログラムの場合、データ変更の画面への通知もAOPがいい。
0381デフォルトの名無しさん2005/05/07(土) 06:33:45
イベントリスナーとかの代わりにって事?
0382デフォルトの名無しさん2005/05/07(土) 06:58:12
GUIモノだと、だいたいセッターの後でnotifyみたいなの呼び出す必要があって、かなりめんどい。
それがAOPで楽できる。
0383デフォルトの名無しさん2005/05/07(土) 08:04:05
効率を無視していいなら良いんじゃないの
0384デフォルトの名無しさん2005/05/07(土) 08:38:48
無視していいわけないけど、影響が少なければ問題ない。
03853772005/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
0386デフォルトの名無しさん2005/05/07(土) 12:03:14
あ、すいません。ログはないですね。
0387デフォルトの名無しさん2005/05/08(日) 13:35:51
>>386
org.springframework.aop.interceptor.TraceInterceptor
org.springframework.aop.interceptor.DebugInterceptor
0388デフォルトの名無しさん2005/05/08(日) 18:55:53
>>375
質問した者だが

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

分散オブジェクト技術とそうでない技術なら話してる土台が違うわけで
DI>>EJBとかわけわかんないんだけど。
0389デフォルトの名無しさん2005/05/08(日) 19:18:26
>>388
EJBは分散が必要ない人にも分散を前提としためんどうな手続きを強要してた。
ほとんどの人に分散は必要なかった。
ほとんどの人にDI+ORM > EJB。
0390デフォルトの名無しさん2005/05/08(日) 19:21:41
>>389

てか分散使わないのにEJB使ってる時点でどうかと・・。
まぁ後者のORMとかはわからなくもないが、EJBは
どっちかっつーと、というかどう考えても分散オブジェクトなわけで。
0391デフォルトの名無しさん2005/05/08(日) 19:35:40
で、だからEJB使わずDI+ORMでいいじゃんとなったんでしょ。
0392デフォルトの名無しさん2005/05/08(日) 21:33:10
>>391があたりまえだがいいことをいった。
0393デフォルトの名無しさん2005/05/08(日) 22:17:34
>>390
まあ、EJBには分散以外にもいい点があるわけで。
宣言的なトランザクションとか、SQLを直接書かないDBMSアクセスとか。

そういEJBのよい機能は使いたいけど、
EJBは動かすの面倒、重い、コンテナに依存してテストしづらい
ってのがあって、その打開策としてSpringをはじめとして色々な
ソフトが出てきているわけだよな。
0394デフォルトの名無しさん2005/05/08(日) 23:26:16
EJBってのはむしろCORBAの世界で
生きるはずなのだが。
0395デフォルトの名無しさん2005/05/08(日) 23:38:34
それはない。
0396デフォルトの名無しさん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の中に入っていたものを使用しています

0397デフォルトの名無しさん2005/05/12(木) 19:55:24
そりゃeCacheのjarを用意していないからでは
0398デフォルトの名無しさん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 使ってる上でクラスの作り方が間違っているとか、もっと普通の方法があるようでしたら
ご指摘ください。よろしくお願い致します。
0399デフォルトの名無しさん2005/05/15(日) 22:24:06
>>398
私も同じ現象起きてます。
"/WEB-INF/lib/applicationContext.xml"という指定をすると
WEB-INFが見当たらないというエラーが返ってきます
なんでかしらんけど、パッケージの中しかパスが認識されないんです
だから
"/jp/co/sample/applicationContext.xml"
みたいにすると読み込めるんですよ。
でもソースのパッケージの中に設定入れとくのはちょっと気持ち悪いな、といった感じです
私はEclipseでTomcatプラグイン使用してますけど
Web.xmlの設定とかが必要なのかなー
04003992005/05/15(日) 22:30:21
レスした後に気づいたけど

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

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

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

不勉強ですいませんorz
0401デフォルトの名無しさん2005/05/16(月) 05:36:09
つか、Webアプリだったらweb.xmlに設定書いた設定使うようにすりゃいいじゃん。
04023982005/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 に記載した初期化パラメータ読むにはどうすればいいんですか?
マジで調べてもわからなかったので、すいませんが教えてください。
0403デフォルトの名無しさん2005/05/17(火) 08:11:38
>>402
HttpServletを継承していない普通のクラスが、
/WEB-INF/なんて、HTTP固有のディレクトリ構造に
依存することを良しとする訳ですか。
0404デフォルトの名無しさん2005/05/17(火) 08:46:55
基本的には普通のクラスはDIコンテナの存在を気にしないようにするね。
0405デフォルトの名無しさん2005/05/17(火) 08:47:10
Servletクラスは絶対パスを取得できるので、そのパスをもらえばいいのでは?
0406デフォルトの名無しさん2005/05/17(火) 09:11:58
サーブレットからApplicationContext自体をもらえばいいね。
0407デフォルトの名無しさん2005/05/17(火) 14:22:24
FileSystemXmlApplicationContextではだめかいな?
0408デフォルトの名無しさん2005/05/17(火) 17:29:46
皆さんどうもありがとうございます。

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

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

>>405-407
結局Servletクラスからパスをもらうことにしました。
正直に言ってまだ釈然としないものが残っているんですが、一般的にそうなら慣れるしかないですね
0409デフォルトの名無しさん2005/05/17(火) 21:41:41
いにしえのServlet/JavaBeans流:jarファイル近辺のPropertiesファイルか取得
  :
J2EE流:JNDIからデータの位置を取得
      Connectorアーキテクチャでデータを供給
  :
Spring Framework: ?
0410デフォルトの名無しさん2005/05/17(火) 22:37:48
>>408
ふつうは、普通のクラスはDIコンテナの存在を気にしないでいいようにする
0411デフォルトの名無しさん2005/05/17(火) 22:39:07
>>408
設計が悪いときに無理をしないといけないのは一般的な話だから気にするな。
0412デフォルトの名無しさん2005/05/17(火) 23:28:33
>>409
BeanFactoryから取得
0413デフォルトの名無しさん2005/05/17(火) 23:41:41
BeanFactoryはどこからファイル所在を取得するつもり?
04143982005/05/17(火) 23:59:50
398です。お忙しいとこ何度もすみません。

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

>>411
設計が悪いのなら直したいのです。>>409さんが書いている様に、Springやその他のDIコンテナ
(すみませんがJ2EE/EJBは知りません)を使ったときの作法があるのなら、この機会に
身に着けたいと思ってます。普通のクラスが外部リソースにアクセスする一般的な方法を
教えてもらえませんか?
0415デフォルトの名無しさん2005/05/18(水) 00:17:47
>>413
そりゃサーバサイドだったら、web.xmlじゃないか?

JNDIだってどっかにJNDIのInicialContextFactoryを指定する(プロパティとか)のと同じ事だとおもうけど。
0416デフォルトの名無しさん2005/05/18(水) 00:44:57
つまり、根っこはプロパティ
0417デフォルトの名無しさん2005/05/18(水) 00:45:37
web.xml使うのは、Servlet層だけの簡単アプリ
0418デフォルトの名無しさん2005/05/19(木) 06:47:36
DIしたオブジェクトから先は、いもづる式にDIするようにして、DIコンテナを意識しないとか。
0419デフォルトの名無しさん2005/05/19(木) 10:10:35
>>418
最初は芋づる式って密な感じがして気持ち悪かったけど
実装してみたら楽すぎて止めらんね
どういった点でデメリットが出てくるんだろうか
0420デフォルトの名無しさん2005/06/01(水) 08:56:52
JSF+Springで設計してんですけど
JSFのバッキングビーンのクラスとビジネスロジックのクラスのそれぞれの役割で

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

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

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

JSF+Springのサンプルアプリがみたいどすえ〜
0421デフォルトの名無しさん2005/06/01(水) 10:05:15
>>420

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

https://appfuse.dev.java.net/
https://equinox.dev.java.net/

漏れ自身が勉強中なので情報提供のみで失礼。
0422デフォルトの名無しさん2005/06/01(水) 10:47:23
>>420
DBのモデルを単に画面に表示する・画面に入力した値をDBに格納する
みたいなシンプルなアプリだとそうなるかもね。
0423デフォルトの名無しさん2005/06/01(水) 10:50:24
sageついでに

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

どのレベルの処理を言ってるのかわからないけど、
本当にMVCレイヤに置くべき処理なのか再検討してみては?
0424デフォルトの名無しさん2005/06/01(水) 11:58:03

この本どうよ?書評キボンヌ
『実践Spring Framework―J2EE開発を変えるDIコンテナのすべて』
http://www.amazon.co.jp/exec/obidos/ASIN/4822221431

『入門Spring』と『軽快なJava』は読みました。さらに詳しい話を
聞きたい、という目的に使えますかね?
0425デフォルトの名無しさん2005/06/02(木) 22:11:28
SpringがJSFとXULをイイ感じに仲介するフレームワーク作ってくれたら
一杯おごってやりたい。
0426デフォルトの名無しさん2005/06/03(金) 12:15:51
>>425
Mozilla独自のXULより標準規格のXFormsのほうが良いのでは?
MozillaもOpenOffice.orgもXFormsに対応する上に、
Chibaを使えばXForms未対応のブラウザに対して
HTML+JavaScriptに変換してから送信することで
大部分のブラウザに対応できます。

Chiba (サーバーサイドJavaライブラリ)
http://chiba.sourceforge.net/
MozillaとXForms (Mozilla1.8/Firefox1.1で対応予定)
http://www.mozilla-japan.org/projects/xforms/
[XForms 00031] XFormsのためのwiki (村田真氏がMozillaでXForms推進)
http://www2.xml.gr.jp/log.html?MLID=xforms&N=31
0427デフォルトの名無しさん2005/06/03(金) 12:41:43
>>426
XULへの必要性は一般の人にとっては低いとは思うが、
>>425は、ブラウザベースクライアントじゃなくて、リッチクライアントとして
XULを使うことを前提に書いてるんじゃなかろうか。
JSF経由でSwingとかFlashをクライアントにするノリで。
0428デフォルトの名無しさん2005/06/03(金) 12:42:00
sage
■ このスレッドは過去ログ倉庫に格納されています