問題タブ [spring-profiles]

プロパティに基づいてフィールドを自動配線する必要がありspring.profiles.activeます。サービスはプロファイルに基づいてのみ作成されますが、サービスは他のクラスで自動配線されるため、@Profile アノテーションを使用できません。

プロファイルに基づいてフィールドを自動配線する方法はありますか?

これまでのところ、Spring Boot Maven プロジェクト (pom を除く) の xml ファイルの開発を回避することができました。それらはすべてコンパイル時に生成されます。ここで指定されているように、実行コマンド内でプロファイルを定義することでこの方法を維持したいと考えていました。 .

@ ComponentScanメイン クラスを使用してコンポーネントのスキャンを有効にし、DAO を @ Repositoryとしてタグ付けするだけで、UserDAOmySQLImpl クラス (UserDAO を継承) を自動配線することに成功しました。

次に、Live で db8 実装を使用する場合に備えて、2 つ目の DAO を追加することを楽しみにしています。どの UserDAO 実装を使用する必要があるかをアプリケーションが判断する必要があります。プロフィールが答えのようでした。

いくつか読んだ後、ほとんどの場合、これらのプロファイルとコンポーネントを管理するために、ある種の構成クラスと外部 xml を追加する必要があるように見えましたが、これは面倒なようで、不要であることを願っています。

私は2つの実装で次のようにタグ付けしました:

-

そして、ここで指定されているように、Maven の目標を介してアクティブなプロファイルを設定します。これは、開発スクリプトとライブ ビルド スクリプトのそれぞれの目標内でアクティブなプロファイルを指定できるように、これが適切でクリーンなソリューションになることを願っています。

私の現在のテストの目標は次のとおりです。

ただし、ビルド時に、両方の Bean が取得されているというエラーが表示されます。

質問

• Maven ゴールに設定されたプロファイルは、@Profile タグを使用するときにチェックされるプロファイルですか?

• プロファイルが適切に設定されていない場合、どちらの実装も選択されるべきではないのに、Spring が両方の実装を選択するのはなぜですか?

• 私が探しているものを達成するためのきれいな方法に関する提案はありますか?

ボーナス

これを複製するのに苦労していますが、使用するプロファイルを決定するために環境ファイルが存在するかどうかを簡単に確認するのは簡単なので、アプリ内でプロファイルを設定したいと思います ( Spring Profiles Examplesにあります)。

私が取り組んでいるアプリケーションの異常なメインクラスに、いじるのをためらっています。

どんな助けでも大歓迎です。

乾杯、スコット。

war特定のプロファイル用にパッケージ化したいと考えています。これは可能ですか？ファイルをパッケージ化するように適切pom.xmlに構成されてwarおり、アプリをパッケージ化しています

しかし、このコマンドで Spring プロファイルを提供する方法がわかりません。

ありがとう、助けていただければ幸いです。

私が取り組んでいるアプリケーションには、XML ベースの Spring 構成 (フレームワーク バージョン: 4.1.7.RELEASE) があります。

プロファイルが指定されている場合、特定の Bean をインスタンス化する必要があるため、次を my に追加しましたweb.xml。

spring.profile選択された Maven プロファイルに基づいて、Maven pom.xml で設定されたプロパティです。

maven-war選択した Maven プロファイルに基づいてプレースホルダーが適切な値に置き換えられるため、プラグインでフィルタリングを有効にしました。これは期待どおりに機能します。したがって、Maven が関与する部分はクリアされ、正常に動作します。

ただし、Environment インスタンスを挿入しようとすると、アクティブなプロファイル リストが空になります。

のservletConfigInitParamsプロパティ ソースのリストに が表示されますがEnvironment、 myinit-paramは単に無視されているようです。

2 つの Maven プロファイルで実際のシステム プロパティを提供し、それらのセットで実行することで、Spring プロファイルを設定することができましたが、これは運用環境で実行可能なソリューションではなく、コマンド ラインから提供することもできません。

誰が私が間違っているのか教えてもらえますか?

私は春のプロファイルを使用して、さまざまな Bean のセットを管理しています。アクティブなプロファイルは、プログラムでオーバーライドするように設定されています

と使用

アクティブなプロファイルのソースは、環境固有のファイルです。したがって、環境ファイルのプロファイルが (Bean XML で) 使用可能なプロファイルと異なる可能性が非常に高く、これは避けたいと考えています。この目的で使用できる「getAvailableProfiles」のようなアクセサーが ConfigurableApplicationContext に表示されません。アクティブなプロファイル値が設定される前に実際に利用可能かどうかを検証することは可能ですか?

サンプル XML の例

この場合、利用可能なプロファイルの私の定義は「ProfileA」、「ProfileB」です。この場合、「ProfileC」をアクティブなプロファイルに設定したくありません。

config.xml ファイルで true に設定されたignoreUnresolvablePlaceHoldersを無視する Spring Boot アプリケーションに問題があります。

これらのオプションを明示的に設定しています。

Junit では問題なく動作しますが、アプリを Spring Boot として実行すると、Caused by: java.lang.IllegalArgumentException: Could not resolve placeholder on startup がスローされます。

次のように Spring プロファイルを追加すると、すべてが失敗し始めました。

どんな助けでも大歓迎です...

別のプロジェクトを使用する Spring プロジェクトがあります。各プロジェクトには、プロファイルごとapplicationContext.xmlに およびを使用して Java コードから初期化する独自のスプリング プロファイルがあります。*.propertiesからプロファイルを挿入しますargs[]。問題は、2 番目のプロジェクトが 2 番目のプロジェクトから env のデフォルト構成を使用することです。2 番目のプロジェクトに applicationContext.xml env を注入できません。Springargs[]プロファイルがどのように機能するかを説明する記事を探してみました。

1. デフォルトが設定されていない場合にプロファイルを表示する階層はありますapplicationContext.xmlか?
2. システム変数は構成よりも強力applicationContext.xmlですか?
3. 私の課題に対する最善の解決策は何だと思いますか?

その件に関する記事や例さえあれば大歓迎です!! 前もって感謝します。

私は Spring 初心者で、Spring の簡単な「プロファイル」処理の利点を活用しようとしています。私はすでにこのチュートリアルに取り組んでいました: https://spring.io/blog/2011/02/14/spring-3-1-m1-introducing-profileで、その概念を簡単な例に適用したいと思います。と の 2 つのプロファイルがdevありprodます。@Configuration設定されたプロファイルに応じて、異なる Bean をインスタンス化できる (共通のインターフェイスをそれぞれ実装する) 各プロファイルのクラスを想像します。

現在使用しているクラスは次のようになります。

StatusController.java

EnvironmentAwareBean.java

EnvironmentAwareBean.java

EnvironmentAwareBean.java

DevConfig.java

ProdConfig.java

この例を実行すると、起動時に次の例外がスローされます (SPRING_PROFILES_DEFAULTが に設定されdevます)。

(...) UnsatisfiedDependencyException: (...) ネストされた例外は org.springframework.beans.factory.NoUniqueBeanDefinitionException: タイプ [EnvironmentAwareBean] の適格な Bean が定義されていません: 単一の一致する Bean が予想されますが、見つかりました 3: prodBean、devBean、getDevBean

私のアプローチは推奨される構成からかけ離れていますか? 私の意見では、すべての Bean ごとに注釈を付けて、後で新しいクラスが追加されたときにいくつかのバリアントを忘れる可能性があるのではなく、それぞれConfigurationに注釈を付ける方が理にかなっています。@Profile