[Seasar-user:2122] Re: injectDependencyについて

[Masataka Kurihara]

栗原です。

> それはちょっと今更な感じ．S2.1 を出す前のタイミングだったら
> ともかく，現時点で考える意義があるとは思えません．

  既存ユーザーに迷惑かからないように、しかし、一度でも前に
出てきたこともある考えを温めなおして整理しなおすのに意義も
クソもないと思うけどね。

> おそらく S2 の利用者のほとんどが Web アプリケーションを
> 開発していることも考えると，ここで Servlet API を抽象化するような
> 方向は不必要な抽象化ではないでしょうか？

  それは、そういう考えもありますね。ただ、違う考えもある。
この件、議論するのがめんどくさいようなら止めますけど。。。

> 非 Web アプリケーションを開発している人にとっては servlet-api.jar が
> 不要になると精神衛生上好ましいかもしれませんが，それ以上のメリットが
> あるとは思えません．

  私はもっと過激に、サーブレットAPIだけじゃなく、OGNLも
Javassistも抜いても動くようにしたほうがいいと思ってるん
ですが。。。Log4Jもなんとか抜けませんかね。で、これも
仕様変更でなく、内部実装の話です。できないものかな？と。
場合によっては、内部のDeployerやAssemblerのうち、不要
なものは抜けるというのもすばらしいです。

> ちなみに S2JMS の受信系 (つまり非 Web アプリ) では，JMS メッセージに
> HttpServletRequest の皮を被せることを考えています．
> それによって，JMS メッセージのプロパティに設定されたオブジェクトを
> instance="request" で扱えるようにしようという魂胆です．

  instance="JMS"でいいじゃないですか。Deployerを作って、
DTDの件どうするか考えるほうが、近道だと思いますよ。

> ここでのポイントは，例えば Map のような汎用インタフェースの下に
> HttpServletRequest や javax.jms.Message を使った実装を配置するという
> ありきたりな考え方に囚われるのではなく，HttpServletRequest を
> 共通のインタフェースとして利用すると考えることでしょう．
> 非 Web アプリケーションで request スコープを使いたければ，
> HttpServletRequest を implements した固有の実装クラスを
> 提供すればいいのです．S2JMS がそうしようと考えているように．

  私も、前にMailをHttpServletRequestに変換して取り扱う
商用のフレームワークを作ったけど、そのときはすばらしい
アイディアだと思いましたが、結果、どうかなあと。Struts
でMailをHTTPに変えて受けて、レスポンスはStrutsはHTTPで
行ってると思ってるけどSMTPでというものです。私の実装が
へぼかっただけなのかもしれませんけどね。昔のことですし。