開発者マシンで使用される一連のプロパティがある場合があります。これは開発者ごとに異なり、別のセットはステージング環境用で、さらに別のセットは運用環境用です。
Spring アプリケーションでは、実稼働環境ではなくローカル環境にロードしたい Bean がある場合や、その逆の場合もあります。
これをどのように処理しますか？別のファイル、ant/maven リソース フィルタリング、またはその他のアプローチを使用していますか?
5692 次
13 に答える
8
JNDIにさまざまなプロパティを配置しました。このようにして、各サーバーを構成し、1つのwarファイルを作成できます。プロパティのリストが大きい場合は、プロパティ（またはXML）ファイルを別のサーバーでホストします。JNDIを使用して、使用するファイルのURLを指定します。
環境ごとに異なるアプリファイル（war / ear）を作成している場合は、テストしているのと同じwar/earをデプロイしていません。
私のアプリの1つでは、いくつかのRESTサービスを使用しています。ルートURLをJNDIに入れるだけです。次に、各環境で、その環境に適したRESTサービスと通信するようにサーバーを構成できます。
于 2008-09-18T16:22:10.847 に答える
2
環境に固有のプロパティファイルを使用し、jar/warsをビルドするときにantビルドに正しいセットを選択させます。
アプリサーバーによっては、環境固有のものをディレクトリサービス（JNDI）を介して処理することもできます。tomcatを使用し、データソースはTomcatの読み取り専用JNDI実装で定義されています。Springを使用すると、検索が非常に簡単になります。
また、同じソースプロジェクトからさまざまなサイト（異なるコンテンツ、セキュリティロールなど）を構築するためのant戦略も使用します。
このビルド戦略で少し問題が発生する原因が1つあります。それは、ビルドが実行されるまでファイルとディレクトリが存在しないことが多いため、（同じスプリングセットを使用して）真の統合テストを作成するのが困難になる可能性があることです。 IDE内から実行可能な）。また、ファイルの存在などをチェックするIDEの機能の一部を見逃しています。
于 2008-09-18T16:18:19.340 に答える
2
Maven を使用して、プロジェクトの src/main/resources の下にあるリソースを除外します。これをプロパティ ファイルと組み合わせて使用し、Spring ベースのプロジェクトでカスタマイズされた属性を取り込みます。
デフォルト ビルドの場合、ホーム ディレクトリにプロパティ ファイルがあり、Maven はそれをオーバーライドとして使用します (ローカルの Tomcat インストールなどは正しく検出されます)。テスト サーバーと運用サーバーは、私の他のプロファイルです。-Pproduction実稼働サーバー用のアプリケーションを構築するために必要なのは、単純なことだけです。
于 2008-09-18T17:22:12.620 に答える
2
マシンごとに異なる Spring XML 構成ファイルを使用し、マシン間で異なるすべての構成データが、それらの Spring 構成ファイルからロードされる Bean によって参照されるようにします。
たとえば、別のアプリの Java RMI インターフェイスに接続する webapp があります。私のアプリは、Spring XML 構成ファイルで構成された Bean を介して、この他のアプリの RMI インターフェースのアドレスを取得します。私のアプリと他のアプリの両方に開発インスタンス、テスト インスタンス、および運用インスタンスがあるため、アプリ用に 3 つの構成ファイルがあります。実例。
あとは、どの構成ファイルがどのマシンに展開されるかだけを明確にしておく必要があります。これまでのところ、WAR ファイルを生成する前に正しい構成ファイルを所定の場所にコピーする Ant タスクを作成する戦略に問題はありませんでした。したがって、上記の例では、プロダクション WAR を生成する 1 つ、開発 WAR を生成する 1 つ、およびテスト WAR を生成する 1 つの 3 つの Ant タスクがあります。3 つのタスクはすべて、適切な構成ファイルの適切な場所へのコピーを処理し、同じ次のステップ (アプリのコンパイルと WAR の作成) を呼び出します。
これが意味をなすことを願っています...
于 2008-09-18T16:10:29.780 に答える
2
異なるプロパティ ファイルを使用し、ビルドが行われた環境に基づいて置換を行う ant 置換フィルターを使用します。http://www.devrecipes.com/2009/08/14/environment-specific-configuration-for-Java-applications/を参照してください。
于 2009-09-08T03:55:18.173 に答える
1
ソース管理リポジトリに保存され、手動で更新された個別の構成ファイル。通常、構成はあるバージョンと次のバージョンの間で根本的に変更されることはないため、同期 (手動であっても) は実際には大きな問題ではありません。
本番環境の非常にスケーラブルなシステムの場合、構成ファイルをテンプレートに保持し、ビルド スクリプトの一部としてこれらのテンプレートを使用して「最終的な」構成ファイルをレンダリングするスキームを真剣にお勧めします (すべての環境で同じプロセスを使用する必要があります)。
于 2008-09-18T16:15:34.620 に答える
1
私は最近、ライブ環境またはステージング環境の代替構成に Maven も使用しました。Maven Profiles を使用した本番構成。それが役に立てば幸い。
于 2008-12-04T22:05:23.153 に答える
0
We use different ant targets for different environments. The way we do it may be a bit inelegant but it works. We will just tell certain ant targets to filter out different resource files (which is how you could exclude certain beans from being loaded), load different database properties, and load different seed data into the database. We don't really have an ant 'expert' running around but we're able to run our builds with different configurations from a single command.
于 2008-09-18T16:24:33.587 に答える
0
Caleb P と JeeBee がおそらく最速の解決策を持っています。さらに、さまざまなサービスをセットアップしたり、さまざまなマシン上のファイルを指定したりする必要はありません。${user.name} 変数を使用するか、Ant または Maven の -D 引数でプロファイルを指定することにより、環境を指定できます。
さらに、このセットアップでは、一般的なプロパティ ファイルと、特定の環境用のオーバーライド プロパティ ファイルを使用できます。Ant と Maven の両方がこれらの機能をサポートしています。
于 2008-09-18T16:40:27.277 に答える
0
私が見た解決策の 1 つは、本番環境と同じになるようにステージング環境を構成することです。これは、各環境に同じ IP 範囲の VLAN があり、マシンの役割が同じ IP アドレスにあることを意味します (たとえば、各環境の db クラスター IP は常に 192.168.1.101 です)。ファイアウォールは、外部向けのアドレスを Web サーバーにマッピングしたため、PC 上のホスト ファイルを交換することで、同じ URL を使用でき ます。スワップインしたホストファイル。
これが理想的な解決策であるかどうかはわかりません。維持するのは非常に面倒ですが、興味深い点です。
于 2008-09-18T16:34:07.027 に答える
0
ターゲット展開の構成を保持するさまざまな構成フォルダーがあり、ANT を使用して、ファイル コピー段階で使用するフォルダーを選択します。
于 2008-09-18T16:16:51.153 に答える
0
Ant のコピーをフィルター ファイルと共に使用します。変数を含む構成ファイルを含むディレクトリには、各環境のファイルを含むディレクトリがあります。ビルド スクリプトは環境を認識し、正しい変数ファイルを使用します。
于 2008-09-18T16:08:52.030 に答える
0
PropertyPlaceholderConfigurer を調査することを忘れないでください。これは、JNDI が利用できない環境で特に役立ちます。
于 2008-09-27T08:35:39.123 に答える