問題タブ [spring-config]

この問題は Spring-Data リリース 2 で発生しました。最新バージョン 1.13.9 (およびそれ以前) では問題なく動作します。

コントローラーコード:

Spring-Data 2 スタイルでも同じ:

構成：

また、Java 構成と XML 構成を使用して、Spring Boot を使用しない単純な Spring アプリケーションを試しました。結果は同じです：

Spring-Data のバージョンを 1.X に変更すると、オブジェクトの並べ替えに対して正しい JSON 応答が得られます。

すべてを試したようですが、変更ログで並べ替えの変更に関する通知は見つかりませんでした。Spring JIRA ではそのような問題は見つかりませんでした。

問題は、次のような並べ替えで spring-data 2.X libs JSON を取得する方法です。

それ以外の：

以下に示すように、クラスを拡張するときに定義されるジェネリック型を持つ Bean の作成を処理する基本構成クラスを提供したいと考えています。@Beanただし、メソッドを呼び出すことはありません。

これは風変わりなユースケースであるため、理解するにはある程度の忍耐が必要であり、風変わりなソリューションが必要になる場合があります。

コンテキスト

@Beanではなくメソッドによって作成された、コンテキストに存在する特定の Bean インスタンスに対して自動アクションを実行する、Spring で使用するライブラリを作成しています@ComponentScan。可能であれば、Bean はタイプではなく、他の手段、できればファクトリ メソッドの注釈によって区別できる必要があります。

これが理想的なケースです。たとえば、Bean を生成する方法が 2 つあるとします。

ここで、2 番目の Bean は、それを作成したメソッドの注釈のために特別です。@Specialしかし、それを区別できるようにするメカニズムはオプションです。

では、どうにかして特別な豆だけを手に入れたい。

警告

すべての Bean が同じインターフェースを実装する場合、タイプごとに注入できることは承知しています。ただし、これは可能な限り透過的に機能する必要があり、既存のアプリへの変更は可能な限り少なくする必要があります。

潜在的なアプローチ

私が念頭に置いている2つの広範なアプローチを次に示します。

1) Bean を登録するプロセスにジャックし、Bean インスタンスをある種のコンテナーに透過的にラップします (この部分は実行可能であると確信しています)。例えば

次に、 type のすべての Bean をすべて注入しますWrapper。ここでの問題は明らかに重複です...代わりに、インターフェイスを実装するプロキシインスタンスをオンザフライで生成できるWrapperので、同時に元のBeanとラッパーとして機能できます。私はエキゾチックなソリューションでも大丈夫だと言いましたよね？

2) Spring はすでに Bean候補を実際の登録済み Bean と区別しています (たとえば@ComponentScan、パッケージ、注釈などで候補をフィルタリングできます)。このプロセスに参加して、後でそれらの Bean インスタンスを区別できるようにするいくつかの有用なメタデータ (ファクトリ メソッドなど) をまだ含んでいる候補記述子を取得したいと考えています。