37

Web プロジェクトの構成を Web プロジェクト (ear/war ファイル) の外部に保存したいと考えています。アプリケーションは、実行中のコンテナー (WebSphere/JBoss など) を認識できません。

これを処理する最善の方法は何ですか?

JNDI はクリーンな方法ですか? JNDI で問題を解決できる場合、どのように構成すればよいですか? (カスタムオブジェクト?)

私の場合、SOAP/WS エンドポイントには単純な Key=>Value ペア (文字列、文字列) しかありません。

4

5 に答える 5

27

WAR ファイル外のプロパティ ファイルの読み取りについては、この質問を参照してください。

JNDI からの変数値の読み取りについては、この質問を参照してください。これが最善の解決策だと思います。次のコードで String 変数を読み取ることができます。

Context initialContext = new InitialContext();
String myvar = (String) initialContext.lookup("java:comp/env/myvar");

上記のコードは、すべてのコンテナーで機能します。Tomcat では、conf/server.xml で次のように宣言します。

<GlobalNamingResources ...>
  <Environment name="myvar" value="..."
         type="java.lang.String" override="false"/>
</GlobalNamingResources>

上記により、グローバル リソースが作成されます。アプリケーションのコンテキストでリソースを定義することもできます。ほとんどのコンテナでは、JNDI リソースは MBeans 管理コンソールから利用できます。それらのいくつかは、それらを編集するためのグラフィカル インターフェイスを提供します。変更が行われた場合、せいぜいアプリケーションの再起動が必要です。

JNDI リソースがどのように定義および編集されるかは、コンテナー固有です。適切な設定を適用するのは、構成者/管理者の仕事です。

JNDI が提供する利点は次のとおりです。

  • WAR/EAR ファイル内のパラメーターのデフォルト値を定義できます。
  • パラメータはコンテナで簡単に設定できます。
  • パラメータの値を変更するときにコンテナを再起動する必要はありません。
于 2009-06-10T22:21:47.600 に答える
11

さまざまな開発者向けに Web アプリをデプロイするとき、および Amazon の EC2 で同様の構成要件がありました。構成をバイナリ コードから分離するにはどうすればよいでしょうか? 私の経験では、JNDI は複雑すぎて、使用するコンテナによって大きく異なります。また、手作業で編集する XML は構文エラーの影響を非常に受けやすいため、このアイデアは破棄されました。いくつかのルールに基づいた設計でこれを解決しました。

1) 単純な name=value エントリのみを使用する必要があります

2) パラメータを 1 つだけ変更するだけで、新しい構成をロードできるようにする必要があります。

3) WAR バイナリは、再パッケージ化せずに再構成可能である必要があります。

4) 機密パラメータ (パスワード) はバイナリにパッケージ化されません

すべての構成に .properties ファイルを使用System.getProperty("domain");し、適切なプロパティ ファイルをロードするために使用することで、要件を満たすことができました。ただし、システム プロパティはファイル URL を指していません。代わりに、使用する構成を指定するために「ドメイン」と呼ばれる概念を作成しました。構成の場所は常に次のとおり
$HOME/appName/config/$DOMAIN.propertiesです。

したがって、独自の構成を使用してアプリを実行する場合は、ドメインを自分の名前に設定してアプリを
-Ddomain=jason
起動します。起動時にアプリがファイルをロードします。
/home/jason/appName/config/jason.properties
これにより、開発者は構成を共有できるため、アプリの同じ状態を再現できます。再コンパイルや再パッケージを行わずにテストと展開を行うことができます。次に、ドメイン値を使用して、バンドルされた WAR の外部の標準の場所から .properties をロードします。

次のような運用構成を使用して、ワークステーションで運用環境を完全に再作成でき
-Ddomain=ec2 ます。
/home/jason/appName/config/ec2.properties

この設定により、各環境で異なる構成を使用して、正確に 1 つのコンパイル済みバイナリ セットで開発/QA/リリース サイクルを実行できます。バイナリにパスワードなどをバンドルするリスクはなく、人々は構成を共有して、私たちが見ている問題を再現できます。

于 2009-06-18T17:38:53.967 に答える
10

環境変数を使用して、構成が含まれている URL (おそらく file:// URL) を指します。これはセットアップが非常に簡単で、JNDI インフラストラクチャを必要としません。

ここにいくつかのサンプルコードがあります（メモリから入力されました - 私はこれをコンパイル/テストしていません）：

public void loadConfiguration() {
   String configUrlStr = System.getenv("CONFIG_URL"); // You'd want to use a more
                                                      // Specific variable name.
   if(configUrlStr == null || configUrlStr.equals("") {
       // You would probably want better exception handling, too.
       throw new RuntimeException("CONFIG_URL is not set in the environment."); 
   }


   try {
       URI uri = new URI(configUrlStr);
       File configFile = new File(uri);
       if(!configFile.exists()) {
          throw new RuntimeException("CONFIG_URL points to non-existant file");
       }
       if(!configFile.canRead()) {
          throw new RuntimeException("CONFIG_URL points to a file that cannot be read.");
       }
       this.readConfiguration(configFile);
   } catch (URISyntaxException e) {
       throw new RuntimeException("Malformed URL/URI in CONFIG_URL");
   }



}
于 2009-06-08T17:24:34.410 に答える
9

クラスパス上にある通常のJavaプロパティファイルを保存して、プロパティをロードするだけですか？

それは簡単でかなり単純です..私が何かを逃していない限り

于 2009-06-12T22:36:09.490 に答える
4

私のお気に入りの場所は次のとおりです。環境変数とプロパティファイル（上記のJaredとkgiannakakisによって提案されたように）。

環境プロパティを格納するデータベーステーブル

ただし、もう1つの簡単な解決策は、データベーステーブルに環境プロパティを格納することです。

アプリケーションがデータベースを使用する場合

  • これは比較的簡単にセットアップできます
  • 値を制御/変更するための本当に簡単な方法を提供します
  • DBスクリプトの一部にすることで、プロセスにうまく統合できます。
于 2009-06-10T23:28:12.007 に答える