問題タブ [component-scan]

別のプロジェクトから偽のクライアントを自動配線するのに問題があります。偽のクライアントの実装が生成および注入されていないようです。

これは私が得ているエラーです。

偽のクライアントは非常に単純です。簡潔にするためにインポートを削除しました。

コンポーネントスキャンをプロジェクトに追加して、アプリケーションとそのコントローラーを含め、他のプロジェクトに偽のクライアントを含めました。

簡潔にするためにほとんどのインポートが削除された残りのコントローラー。

さまざまなプロジェクトやさまざまなパッケージで偽のクライアント インターフェイスを定義しようとしましたが、アプリケーションと同じパッケージに配置した場合にのみ成功しました。これは、スキャンにパッケージを含めているにもかかわらず、コンポーネント スキャンの問題であると思われます。再利用可能な「コントラクト」を定義し、それを使用するアプリケーションで偽のクライアントを定義する代わりに、各プロジェクトに一意のパッケージ構造を持たせるために、偽のクライアントインターフェイスを共有プロジェクトに保持したいと思います。

ありがとう、ウェス。

Spring コンテキストの定義に問題があります。この問題を抱えている他の人を見ると、通常は間違ったスキーマ宣言を使用していることが原因でしたが、私の問題には当てはまらないと思います。

ここにxmlがあります

私はSpring-4.1.6を使用しています

SpringBoot main/Application.java クラスがあります

およびテスト用の同様のもの

メイン コードは正しく実行されます。テスト コードは NoUniqueBeanDefinitionException をスローし、不要な MySqlRepository コンポーネントを適切に除外していないように見えます。

一般的な Bean を含む抽象 Spring 構成クラスがあります。

一般的な Bean の詳細は、そのサブクラスによって設定されます。

...と...

私のテストは のみを使用する必要がありTestConfig、 について知る必要はありませんRealConfig(ただし、 内の他のコンポーネントにアクセスする必要がありますrealPackage)。始まります：

上記のコードでは、これは期待どおりに機能し、"test"仕様を使用しています。しかし、 内のパッケージの順序を逆にすると、@ComponentScan代わり"real"に詳細が使用されます。これは私を困惑させています-これでTestConfigオーバーライドされたメソッドを呼び出す必要があることを指定していますか? Spring がこれを行う理由と、それをどのように解決できるかについて、だれかアドバイスしてもらえますか?

Spring Boot が一部のクラスを自動構成するのを防ぐのに苦労しています (この例では: SolrAutoConfiguration)。説明するために、大幅に縮小した例をセットアップしました。

https://github.com/timtebeek/componentscan-exclusions

実際には、20 以上の内部@SpringBootApplicationプロジェクトがあり、それぞれが独自の依存関係をまとめています。(理想的ではありません/私の考えではありませんが、今から離れるのは難しいです。)

この問題は、複数のサブプロジェクトが Solr 5.2.1 を使用しているために発生しますが、Spring Boot は 4.x としか互換性がありません。@SpringBootApplication最終的なアプリケーション (例では module-b) では、すべてのモジュールですべてのクラスをインポートしたいのですがSolrAutoConfiguration、実行はできません。

特定の除外なしで@SpringBootApplication取得された のインスタンスは引き続き をロードするため、これは失敗します。@ComponentScanSolrAutoConfiguration

複数のクラスを組み合わせるときに、自動構成クラスを適切に除外するにはどうすればよい@SpringBootApplicationですか?

私はすでにexcludeFilters最終版@SpringBootApplicationで作業しようとしましたが、まだ解決には至っていません。

hibernate を spring と統合しようとしていますが、それが可能かどうかを知りたくて、@Autowired と @Componentscan を使用して BasicDataSource クラスを注入できますか?

読みました：

複数のコンポーネント スキャン

Spring MVC の ApplicationContext と WebApplicationContext の違いは何ですか?

<context:component-scan /> がディスパッチャ コンテキストではなくアプリケーション コンテキストにある場合、@RequestMapping アノテーションが機能しない(これについては後で詳しく説明します)

他にもいくつかありますが、これらのどれも質問に答えていません:

Spring MVC アプリケーションの ROOT コンテキストに存在する場合、スコープが<context:component-scan.../>制限されるのはなぜですか?

私の理解では、指定されたパッケージ内のすべてのクラスのスキャンが発生し、ステレオタイプ化された Bean@Componentまたはそのサブステレオタイプ ( @Repository、@Serviceおよび@Controller) のいずれかがインスタンス化されます。

与えられた:

applicationContext.xml (ルート コンテキスト)

main-servlet.xml (サーブレット コンテキスト)

com/myproject/web/MainController.java

Spring のドキュメントには、ルート コンテキストでインスタンス化されたすべての Bean が共有され、個々のサーブレット アプリケーション コンテキストで使用できると記載されています。したがって、<context:...>ルート コンテキストでの 2 つの宣言により、サーブレット コンテキストで表示される Bean が生成されます。しかし、そうではないようです。サーブレットのコンテキストで<context:component-scan.../>両方を繰り返す必要があります。<context:property-placeholder.../>

<context:component-scan.../>サーブレット コンテキストでを省略すると、

@Controllerが解決されなかったことを示します。

処理されていないプロパティ参照を使用<context:property-placeholder.../>した注釈の結果を省略すると、私の場合、いくつかの壊れたリンクが発生します。@Value

これらの<context:.../>ディレクティブは両方とも Bean のインスタンス化につながるため、ドキュメントとは正反対に、Bean が子コンテキストで表示されない理由について混乱しています。また、component-scanステートメントが 2 つあると、コントローラー Bean が 2 回インスタンス化されることはありませんか?

<context:component-scan /> がディスパッチャ コンテキストではなくアプリケーション コンテキストにある場合、@RequestMapping アノテーションが機能しないことに関しては<mvc:annotation-driven />、アプリ コンテキストにあり、ここでの回答では 2 つのcomponent-scanステートメントが必要な理由が説明されていません。

「魔法」がどのように機能するかを完全に理解し、何かを微調整したときにどのように動作するかを予測できない限り、「魔法」を使用するのは本当に不快です。したがって、「両方の場所に追加して先に進む」という「解決策」は受け入れられません。

新しい Spring Boot Web アプリケーションを作成したいと考えています。

私の構造は次のようになります。

私は2つの方法で行くことができます：

1. MyApplication にアノテーションを付け@SpringBootApplicationて、コントローラー、JPA リポジトリーなどを見つけられるようにします。
2. などを一緒に使用して@EnableWebMvc、さまざまなコンポーネント タイプの基本パッケージを明示的に指定します。@EnableJpaRepostories@ComponentScan(basePackages=...)

私は喜んで最初のアプローチを採用しますが、Spring が特定のパッケージではなくすべてをスキャンするため、(アプリのコードベースが大幅に拡大した場合) アプリケーションの起動に時間がかかるという懸念があります。ただし、少なくとも 1 回はこれらのファイルをすべて読み取って、Bean を見つける必要があります。

質問は次のとおりです。

Spring (Boot) は、Bean のすべてのサブパッケージを 1 回だけスキャンするほどスマートですか?それとも、デフォルト構成のままにしておくとオーバーヘッドが追加されますか?

拡張時のgetServletConfigClasses()vs の違いは何ですか。今朝から多くの情報源を読んでいますが、違いについてはまだ明確に理解していません:getRootConfigClasses()AbstractAnnotationConfigDispatcherServletInitializer

次の 2 つの構成をご覧ください。

1)。

はConServlet.class、

2)。

WebConfig.classが参照している

ビューの初期化など、 ConServletとWebConfigの両方が (多かれ少なかれ) 同じことを行っていることがわかります。

しかし、なぜ ：

• ConServletが返されますgetRootConfigClasses()
• WebConfigが返される間getServletConfigClasses()

ドキュメントを読みました

getRootConfigClasses()とgetServletConfigClasses( )の両方 が

提供される @Configuration および/または @Component クラスを指定します.. (それらの違い)

• のルート アプリケーション コンテキストgetRootConfigClasses()
• のディスパッチャ サーブレット アプリケーション コンテキスト getServletConfigClasses()

しかし、なぜConServletとWebConfig が同じこと (ビューの初期化など) を行っているのでしょうか。簡単な用語/例で実際にルートコンテキストとディスパッチャーサーブレット（私はこれを知っています）とは何ですか

ありがとうございました！