2011-03-14 9 views
0

サーブレットコンテキストはアプリケーションごと(または.WARごと)です。 EAR内のサーバー上のすべてのアプリケーションで利用できるように、属性を格納できるものはありますか?サーブレットコンテキストよりも上位に何かがありますか

+0

明確にする:より高いレベルの抽象化とは対照的に、より広い範囲(つまり、より大きな可視性)について話しているのでしょうか? –

+0

はい、そうです。 –

答えて

1

通常、EAR/WARはスコープされていますが、いくつかのコンテナには「共有ライブラリ」という概念があり、必要なものを提供する可能性があります。一部のコンテナはフラットなクラスローダーを使用しています。つまり、WAR Aの静的フィールドがWAR Bに表示されます。オールインワン全部私は、プロパティがあまり静的でない限り、ほとんどのサーバーワイド属性に対してお勧めします(system properties)。

さらに動的なデータについては、必要な値を持つJARを作成し、それをサーバーのクラスパスに追加することをお勧めします。他の問題との間でスレッドの安全性を確保するためには十分な注意が必要です。

+0

しかし、実行時に変更できる実際のPOJOはどうでしょうか? –

+0

私の答えは、サーバーレベルのジャーを含めるように更新されました。これは悪い習慣の端にありますが、それは機能しますが、解決するよりも頭痛を引き起こす可能性があります。 –

+0

はかなりハックのように聞こえる。 -Cmon sun/oracle、 "serverContext"がいいでしょう。 –

3

AFAIK、いいえ、それはサーブレットの仕様になります。もちろん、JNDI(複数のWebアプリケーション間で接続を検索するために通常使用される)やHazelcastなどの分散データ構造プロバイダのようなソリューションを調べることができます。

関連する問題