[cubby-dev:103] Re: POJOAction 対応の話題

BABA,Yasuyuki [E-MAIL ADDRESS DELETED]
2009年 6月 28日 (日) 02:35:36 JST 

馬場です。

そういえば、applicationContext.xml の component-scan で include-filter
を指定してますけど、XxxAction とか XxxService とかに @Component をつけ
て、component-scan はもうひとつ上のパッケージを指定するのはどうでしょうか？

↓今はこうなっているところを
<context:component-scan
	base-package="org.seasar.cubby.spring_examples.action">
	<context:include-filter type="assignable"
		expression="org.seasar.cubby.action.Action" />
	<context:include-filter type="annotation"
		expression="org.seasar.cubby.action.ActionClass" />
</context:component-scan>

↓こんなふうに
<context:component-scan
	base-package="org.seasar.cubby.spring_examples" />

アプリを作る場合は後者のほうを使うかと思ったんですが、どうでしょう？


Takashi SOMEDA さんは書きました:
> 染田です。
> 
>> 鈴木さん、
> 
> お疲れ様ですー、ありがとうございます。
> 
> 一点だけ変更してコミットさせてもらいました。
> ケースとしてはあまり無いと思ってはいるのですが、
> SpringContainerProvider/SpringConverterProvider などでも
> やっているように、引き渡されてくるコンテナが親を持つケースに
> 備えて、BeanFactoryUtils を使うようにしました。他は特にいじってませんです。
> 
> --- こんな感じ ----
> 
> Index: src/main/java/org/seasar/cubby/plugins/spring/spi/SpringPathResolverProvider.java
> ===================================================================
> --- src/main/java/org/seasar/cubby/plugins/spring/spi/SpringPathResolverProvider.java	(revision
> 1808)
> +++ src/main/java/org/seasar/cubby/plugins/spring/spi/SpringPathResolverProvider.java	(working
> copy)
> @@ -19,6 +19,7 @@
>  import org.seasar.cubby.spi.PathResolverProvider;
>  import org.seasar.cubby.util.ActionUtils;
>  import org.springframework.beans.BeansException;
> +import org.springframework.beans.factory.BeanFactoryUtils;
>  import org.springframework.beans.factory.annotation.Autowired;
>  import org.springframework.context.ApplicationContext;
>  import org.springframework.context.ApplicationContextAware;
> @@ -54,8 +55,9 @@
>  			return;
>  		}
> 
> -		for (final String beanDefinitionName : applicationContext
> -				.getBeanDefinitionNames()) {
> +		final String[] names = BeanFactoryUtils
> +				.beanNamesIncludingAncestors(applicationContext);
> +		for (final String beanDefinitionName : names) {
>  			final Class<?> type = applicationContext
>  					.getType(beanDefinitionName);
>  			if (ActionUtils.isActionClass(type)) {
> 
> -----
> 
> 2009/6/26 [E-MAIL ADDRESS DELETED] <[E-MAIL ADDRESS DELETED]>:
>> 馬場さん、染田さん
>>
>> 鈴木です。
>>
>>>> ReaderEventListener でなくても、SpringPathResolverProvider#initialize で
>>>> Action のサブクラスを検索するかわりに全部スキャンしてチェックしてもよく
>>>> ない？
>> 全スキャンするやり方でうまく行きました！
>> ありがとうございました（＾＾
>>
>> spring-examples の方は IndexAction だけ @ActionClass を使うように変更し
>> ました。（@ActionClass を使うものと Action を extends するもの両方あった
>> ほうが良いと思ったので）
>>
>> Takashi SOMEDA さんは書きました:
>>> 染田です。
>>>
>>> 結論からいうと、馬場さん案に賛成でございます。
>>> お騒がせしてすみません。
>>>
>>> というのもですね、、、
>>>
>>> よく考えたら、ReaderEventListener を implements した
>>> SpringPathResolverProvider のやりかたうまくいきませんね。。。
>>>
>>> 1) XmlBeanDefinitionReader に SpringPathResolverProvider をセット
>>> 2) XmlBeanDefinitionReader を利用して applicationContext を初期化
>>> 3) applicationContext から SpringPathResolverProvider を初期化
>>>
>>> となり、矛盾しちゃう。。。
>>> ということで、ReaderEventListener の話は
>>> 忘れてください。。。ごめんなさい。。
>>>
>>>> ReaderEventListener でなくても、SpringPathResolverProvider#initialize で
>>>> Action のサブクラスを検索するかわりに全部スキャンしてチェックしてもよく
>>>> ない？
>>> 賛成なのですが、思ってたことをコメントしときますー。
>>>
>>> 結構コンポーネント数多くなったら全スキャン大変なのかなー、
>>> と思ったり、というのが気にはなっていたのです。
>>> # 仮に ReaderEventListener でも一緒なのですが、チェックする数は一緒でも
>>> # 多少は処理タイミングが分散されるかなぁ、と。
>>>
>>> とはいえ、初期化一度だけの話ですし、構造的に初期化時の
>>> 全スキャンより良い手がそもそもないような気がしてきました。
>>>
>>> かたやまさんが、前書いていた、BeanPostProcessor みたいな雰囲気で、
>>> コンポーネント登録時に何か前後処理実行されるような仕組みが他に
>>> あればいいんですけど、どうもなさそうですしねぇ。ふむぅ。
>>> # Bean の初期化時とかだと、PathResolver 的には遅すぎるので。。。
>>>
>>> http://static.springframework.org/spring/docs/2.5.x/reference/beans.html#beans-factory-extension-bpp
>>> http://d.hatena.ne.jp/c9katayama/20080530/1212130016
>>>
>>> ではではー。
>>>
>>> 2009/6/25 BABA,Yasuyuki <[E-MAIL ADDRESS DELETED]>:
>>>> 馬場です。
>>>>
>>>> ReaderEventListener でなくても、SpringPathResolverProvider#initialize で
>>>> Action のサブクラスを検索するかわりに全部スキャンしてチェックしてもよく
>>>> ない？
>>>>
>>>> ↓こんな感じ
>>>> for (final String beanDefinitionName :
>>>>        applicationContext.getBeanDefinitionNames()) {
>>>>        final Class<?> type =
>>>>                applicationContext.getType(beanDefinitionName);
>>>>        if (ActionUtils.isActionClass(type)) {
>>>>                pathResolver.add(type);
>>>>        }
>>>> }
>>>>
>>>>
>>>> [E-MAIL ADDRESS DELETED] さんは書きました:
>>>>> 馬場さん、染田さん
>>>>>
>>>>> 鈴木です。
>>>>>
>>>>> フォローありがとうございます！
>>>>>
>>>>> ＞染田さん
>>>>>> で、調べてみた所を共有してみます。
>>>>> 詳しく調べていただいてありがとうございます。
>>>>> まずは ReaderEventListener でやってみます（＾＾；
>>>>>
>>>>>> どうも、ApplicationContext から、アノテーション付きの
>>>>>> クラスを引っこ抜くのはそれなりに大変そうに見えますね。
>>>>> request などの Web アプリケーション用のスコープが指定されていると上手く
>>>>> 取れませんでした。
>>>>>
>>>>> 以下、僕の調べた内容（というより詰まった内容）です。
>>>>>
>>>>> ====
>>>>>
>>>>> 原因をつかめていないのでざっくりになりますが、
>>>>>
>>>>> ・JUnit でテストを行うと「java.lang.IllegalStateException: No Scope
>>>>> registered for scope 'request' ...」という例外が発生
>>>>> => WebApplicationContext ためのようで、自分で request などのスコープを登
>>>>> 録する必要がありそう
>>>>>
>>>>> ・（JUnit ではなく）普通に動かしたときは
>>>>> 「java.lang.IllegalStateException: No thread-bound request found ...」と
>>>>> いう例外が発生
>>>>> => 初期化順序の問題？？
>>>>>
>>>>> ====
>>>>>
>>>>> Takashi SOMEDA さんは書きました:
>>>>>> 染田です。
>>>>>>
>>>>>>> 鈴木さん、
>>>>>> 的外れ or 既に調査済みだったらスミマセン。
>>>>>> どうも、ApplicationContext から、アノテーション付きの
>>>>>> クラスを引っこ抜くのはそれなりに大変そうに見えますね。
>>>>>>
>>>>>> で、調べてみた所を共有してみます。
>>>>>>
>>>>>> -----
>>>>>> XmlBeanDefinitionReader に、ReaderEventListener を impl したクラスを
>>>>>> 設定すると、コンポーネント登録時に、componentRegistered を呼んでくれる。
>>>>>> => SpringPathResolverProvider をこの実装クラスにし、コンポーネント登録時に
>>>>>>      PathResolver に add するような感じでいける？
>>>>>> # ちなみに、ComponentScanBeanDefinitionParser から引っ掛けて行きました。
>>>>>>
>>>>>> XmlBeanDefinitionReader の初期化は、web の場合 ContextLoader で行われます。
>>>>>> ちなみに、このクラスをサブクラス化して、ContextLoader で指定する方法はあります。
>>>>>> # 詳細は ContextLoader の javadoc で。。。
>>>>>>
>>>>>>
>>>>>> 正直、Listener を使ってコンポーネント登録時に PathResolverProvider の処理を呼び出すと、
>>>>>> PathResolverProvider 自体の初期化のタイミングと (多分) ずれるので、イマイチかなー、
>>>>>> と思ったりもしています。
>>>>>>
>>>>>> ただ、コンテナの登録時のフックに仕掛けられるので、component-scan じゃない
>>>>>> 方法で登録された場合でも、対応出来るメリットもあるかとは思います。
>>>>>> -----
>>>>>>
>>>>>> と今日の所はここまで調べてみました。
>>>>>> また、何かわかれば適宜共有しましょー。
>>>>>>
>>>>>> 2009/6/23 Takashi SOMEDA <[E-MAIL ADDRESS DELETED]>:
>>>>>>>> 困ったことになってるとこがあれば言ってください。
>>>>>>>> なんかわかるかもしれないので。
>>>>>>> ですねー。
>>>>>>> 何かあればシェアしましょうー。
>>>>>>>
>>>>>>> 2009/6/23 BABA,Yasuyuki <[E-MAIL ADDRESS DELETED]>:
>>>>>>>> はーい。
>>>>>>>> 困ったことになってるとこがあれば言ってください。
>>>>>>>> なんかわかるかもしれないので。
>>>>>>>>
>>>>>>>> suzuki kei さんは書きました:
>>>>>>>>> 鈴木です。
>>>>>>>>>
>>>>>>>>>>> ひとまず、適当なアノテーションがついたクラスで、
>>>>>>>>>>> Spring に登録されているものを取得する処理の組み込みを
>>>>>>>>>>> お願いしても良いでしょうか？
>>>>>>>>>> 了解しました。今週末にでも見ておきますー。
>>>>>>>>> すんなりできると思ったのですが、ちょっとてこずってます。
>>>>>>>>> 週末に〜、と言っていたのですがすみません。（＾＾；
>>>>>>>>>
>>>>>>>>> とりあえず現状報告です。
>>>>>>>>>
>>>>>>>>> 2009/06/18 6:20 [E-MAIL ADDRESS DELETED] <[E-MAIL ADDRESS DELETED]>:
>>>>>>>>>> 鈴木です。
>>>>>>>>>>
>>>>>>>>>> Seasar Conference に参加された方、おつかれさまでした。
>>>>>>>>>>
>>>>>>>>>> ＞染田さん
>>>>>>>>>>>> 鈴木さん、
>>>>>>>>>>> ひとまず、適当なアノテーションがついたクラスで、
>>>>>>>>>>> Spring に登録されているものを取得する処理の組み込みを
>>>>>>>>>>> お願いしても良いでしょうか？
>>>>>>>>>> 了解しました。今週末にでも見ておきますー。
>>>>>>>>>>
>>>>>>>>>> Takashi SOMEDA さんは書きました:
>>>>>>>>>>> 染田です。
>>>>>>>>>>>
>>>>>>>>>>> Seasar Conference お疲れ様でしたー。
>>>>>>>>>>>
>>>>>>>>>>>> 馬場さん、
>>>>>>>>>>> ありがとうございました m(_ _)m
>>>>>>>>>>> しゃべりすぎてすみません。
>>>>>>>>>>>
>>>>>>>>>>>> T2 チームの皆様、
>>>>>>>>>>> よねさんの俳句お借りしました。m(_ _)m
>>>>>>>>>>> あと、画像もいくつかおかり (拝借 ?!) しました。m(_ _)m
>>>>>>>>>>> ありがとうございました。勝手にかりてしまいごめんなさい。
>>>>>>>>>>>
>>>>>>>>>>> ...
>>>>>>>>>>>
>>>>>>>>>>> で、表題の POJOAction の件ですが、馬場さんとは口頭で
>>>>>>>>>>> アノテーションをクラスにつけて判別しようかという事になりました。
>>>>>>>>>>>
>>>>>>>>>>>> 馬場さん、
>>>>>>>>>>> あれから考えてみたものの、通常補完は使うし、若干長くても
>>>>>>>>>>> 構わないので、
>>>>>>>>>>>
>>>>>>>>>>>   @Actionable
>>>>>>>>>>>   @ActionClass
>>>>>>>>>>>   @ActionObject
>>>>>>>>>>>   @PlainAction
>>>>>>>>>>>
>>>>>>>>>>> とかになるのかなぁ、、、と思ってました。
>>>>>>>>>>> 「Action」 って単語を外すと、なんとなく直感的では
>>>>>>>>>>> なくなるような気がして。。。
>>>>>>>>>>> 二単語になると負けたような気がするのですが。。。
>>>>>>>>>>>
>>>>>>>>>>>> 鈴木さん、
>>>>>>>>>>> ひとまず、適当なアノテーションがついたクラスで、
>>>>>>>>>>> Spring に登録されているものを取得する処理の組み込みを
>>>>>>>>>>> お願いしても良いでしょうか？
>>>>>>>>>>>
>>>>>>>>>>> 対象は SpringPathResolverProvider で pathResolver に
>>>>>>>>>>> class に add している部分でございます。
>>>>>>>>>>> また何か疑問あったら聞いてくださいまし。
>>>>>>>>>>>
>>>>>>>>>>> 以上です。
>>>>>>>>> _______________________________________________
>>>>>>>>> cubby-dev mailing list
>>>>>>>>> [E-MAIL ADDRESS DELETED]
>>>>>>>>> https://ml.seasar.org/mailman/listinfo/cubby-dev
>>>>>>>> --
>>>>>>>> BABA,Yasuyuki
>>>>>>>> [E-MAIL ADDRESS DELETED]
>>>>>>>> _______________________________________________
>>>>>>>> cubby-dev mailing list
>>>>>>>> [E-MAIL ADDRESS DELETED]
>>>>>>>> https://ml.seasar.org/mailman/listinfo/cubby-dev
>>>>>>>>
>>>>>>> --
>>>>>>> ======================================
>>>>>>> 株式会社チョイスタジオ
>>>>>>> 取締役 CTO 染田貴志
>>>>>>> mail: [E-MAIL ADDRESS DELETED]
>>>>>>> www: http://www.choistudio.jp/
>>>>>>>
>>>>>>> 〒606-8225
>>>>>>> 京都市左京区田中門前町46 京美華ビル3F
>>>>>>> TEL: 075-724-4400
>>>>>>> ======================================
>>>>>>>
>>>>> _______________________________________________
>>>>> cubby-dev mailing list
>>>>> [E-MAIL ADDRESS DELETED]
>>>>> https://ml.seasar.org/mailman/listinfo/cubby-dev
>>>> --
>>>> BABA,Yasuyuki
>>>> [E-MAIL ADDRESS DELETED]
>>>> _______________________________________________
>>>> cubby-dev mailing list
>>>> [E-MAIL ADDRESS DELETED]
>>>> https://ml.seasar.org/mailman/listinfo/cubby-dev
>>>>
>>>
>>>
>> _______________________________________________
>> cubby-dev mailing list
>> [E-MAIL ADDRESS DELETED]
>> https://ml.seasar.org/mailman/listinfo/cubby-dev
>>
> 
> 
> 


-- 
BABA,Yasuyuki
[E-MAIL ADDRESS DELETED]

cubby-dev メーリングリストの案内