DispatchしたときのGroovyCategorySupportの振る舞い
GroovyのスクリプトでServletCategoryを利用して、RequestDispatcherを利用するとrequestとかのsetでこける。
具体的には
１，スクリプトAでrequestのsetを実行しスクリプトBへDispatchする。
２，スクリプトBでrequestのsetを実行する。
そうするとGroovyRuntimeExceptionでAmbiguous method overloading for methodと怒られてしまうのだが、これはおかしいよなー
場所的にはMetaClassImplクラスのchooseMostSpecificParamsにおいてmatchesが1ないしは0以外の時に発生する。つまり簡単に言えば、ServletCategoryで追加しているsetメソッドが重複しているよーって言っているのである。
Groovyのソースコードを追っていると、GroovyCategorySupportにおいてCategoryのキャッシュを保持するためにThreadLocalを利用しているが、ここが超臭う。
private static ThreadLocal local = new ThreadLocal() {
protected Object initialValue() {
List stack = new ArrayList();
stack.add(Collections.EMPTY_MAP);
return stack;
}
};
RequestDispatcherを利用しない場合は問題ないのになー。
↑これはTomcatがThreadの使い回しの際にinitialValueで初期化しているからと思われ・・・
オリジナルのGroovletでも同じ現象が発生してる・・・・・orz
そんなに影響はないけどCategory使えないのは利便性の観点から痛いなー
具体的には
１，スクリプトAでrequestのsetを実行しスクリプトBへDispatchする。
２，スクリプトBでrequestのsetを実行する。
そうするとGroovyRuntimeExceptionでAmbiguous method overloading for methodと怒られてしまうのだが、これはおかしいよなー
場所的にはMetaClassImplクラスのchooseMostSpecificParamsにおいてmatchesが1ないしは0以外の時に発生する。つまり簡単に言えば、ServletCategoryで追加しているsetメソッドが重複しているよーって言っているのである。
Groovyのソースコードを追っていると、GroovyCategorySupportにおいてCategoryのキャッシュを保持するためにThreadLocalを利用しているが、ここが超臭う。
private static ThreadLocal local = new ThreadLocal() {
protected Object initialValue() {
List stack = new ArrayList();
stack.add(Collections.EMPTY_MAP);
return stack;
}
};
RequestDispatcherを利用しない場合は問題ないのになー。
↑これはTomcatがThreadの使い回しの際にinitialValueで初期化しているからと思われ・・・
オリジナルのGroovletでも同じ現象が発生してる・・・・・orz
そんなに影響はないけどCategory使えないのは利便性の観点から痛いなー
