マキノ式ブログ

きっとGroovy本家の人やコアな人は既に把握していて既出かもしれないのだが・・・・

ある程度原因が判明、状況から判断すると、結局スクリプト実行時にダイナミックにCategoryサポートを付加する際に、クラスの型ごとに行なっており、なおかつ実行時MetaClassImplにて関連するMetaMethodをすべて取得しているという動作に由来するようだ。

なぜこのような現象が発生するかというと、結局Servletコンテナの実装のため、もしくはGroovyの実装のためとしか言いようがない。

現象に照らし合わせて、状況を整理してみる。
１，スクリプトAでrequestのsetを実行しスクリプトBへDispatchする。
２，スクリプトBでrequestのsetを実行する。
そうするとGroovyRuntimeExceptionでAmbiguous method overloading for methodと例外が発生。

この時、最初のスクリプトAでバインドされたrequestはorg.apache.catalina.connector.RequestFacadeのインスタンスであり、GroovyCategorySupportのThreadLocalのstackにもRequestFacadeクラスのClassインスタンスをkeyとしてsetのCategoryMethodがキャッシュされる。
（詳しく言えばRequestFacadeがcategorizedClassとされ、さらにCategoryMethodにてHttpServletReqeustを対象としてキャッシュされる。）

ところが、スクリプトBでバインドされたrequestはコンテナによりDispatchされたrequestなのでorg.apache.catalina.core.ApplicationHttpRequest（HttpServletRequestWrapperのサブクラス）となっている。
そのためstackには新たにApplicationHttpRequestをkeyとしてsetのCategoryMethodがキャッシュされる。
（同じくApplicationHttpRequestがcategorizedClassとされ、さらにCategoryMethodにてHttpServletReqeustを対象としてキャッシュされる。）

このためスクリプトBの実行時にはCategoryメソッドの検索で、見事に2つのsetメソッドが存在することになり、結果的にAmbiguous method overloading for methodとなるらしい。

ということで、結局Servlet関連のrequest,session,contextに関連するCategoryサポートは利用できる局面と利用できない局面が混在することになるので、紛らわしいから利用しない方向で実装することに決定。
まあsetAttributeを書くのがそれほど苦痛とも思われないので、問題ないかと・・・

参考：
GroovyCategorySupportのコードを追ってみた。
裏マキノ式:GroovyCategorySupportの分析