【概要】
※ここで言うクラスは基本的に「Page」クラスのことである。

＜現状＞
スーパークラスのSetterに@RequestParameterが付いていて、
サブクラスでそのSetterをオーバーライドして@RequestParameterを付けない場合、
スーパークラスの@RequestParameterは無効になる。

＜改善＞
スーパークラスのSetterに@RequestParameterが付いていて、
サブクラスでそのSetterをオーバーライドして@RequestParameterを付けない場合、
スーパークラスの@RequestParameterの効果が引き継がれる。

【詳細】
「現状」の一番の問題としては、Setterオーバーライドした場合の付け忘れである。
開発者は、最初の知らない時点では必ずやってしまうだろうし、
知ってからもつい忘れてしまうことがかなり予想される。
その場合の発生する現象が「値が入ってこない」ということのため、
原因の特定に時間がかかってしまう可能性がある。

アノテーションは、スーパークラスに付けても再自動生成時に上書きされない
仕様があり、開発者はスーパークラスにアノテーションを付ければ、
サブクラスでSetterをオーバーライドする必要はあまりないが、
アプリで独自に付けた処理(アノテーション)が、スーパークラスの
他の大量のSetterとかGetter定義に埋もれて可読性がわるくなるため、
実業務での利用は、あまり考えにくい。
（サブクラスでオーバーライドして「アプリで独自に付けた処理(アノテーション)」
　が一望できるような形で実装する方が好ましい）
また、サブクラスでSetterにフィルタ処理や別途処理を入れるために
オーバーライドした場合、スーパークラスのアノテーションが継承されないのは
あまり効率的でないという別の問題もある。

「改善」の課題としては、サブクラスでスーパークラスのアノテーション指定を
無効化する方法を提供する必要があることである。案として、
サブクラスのSetterに別途「アノテーション無効化用アノテーション」を付与する方法がある。
例えば以下のような感じ： ※名前は仮

@Ignore(@RequestParameter.class)
public void setFooName() {
    ...
}

この方法は、「現状」におけるサブクラスによるアノテーション無効化よりも
明示的でわかりやすい分、良い方法である。

但し、この無効化は「業務的な重要度は低い」と思われるため、
「改善」実現後にすぐにある必要はないと思われる。
少なくとも画面固有のスーパークラスのアノテーションを無効化する必要性は
ほとんどないかと思われる。あるのは、画面間で共通のPageBaseのような
スーパークラスであらかじめ用意したアノテーション付きメソッドを
とある画面だけで無効化したい、というような場合である。

【補足】
これは@RequestParameterだけでなく、他のアノテーションでも同様の話である。
一番、重要度が高いのが「@RequestParameter」という話である。