2

私はロギングの改善に取り組んでおり、そのような問題に直面しました。私たちのプロジェクトには、共通の構成とライブラリを持つ共通のプロジェクトを使用してビルドする多くのスタンドアロンがあります。ロギングには log4j 1.2.15 を使用し、すべてのスタンドアロンで使用される log4j init Bean では、環境名に基づいて環境固有の構成ベースをロードします。

<bean id="log4jConfigurer-bean" class="org.springframework.beans.factory.config.MethodInvokingFactoryBean">
    <property name="targetClass" value="org.springframework.util.Log4jConfigurer"/>
    <property name="targetMethod" value="initLogging"/>
    <property name="arguments">
        <list>
            <value>classpath:config/env/log4j-${env.name}.xml</value>
        </list>
    </property>
</bean>

(ディレクトリ内の log4j.{env.name}.xml から構成のファイル名を作成するだけです)。

場合によっては、環境がどのように呼び出されるのか本当にわからない、他のプロジェクトで使用される共通ライブラリ (および他のプロジェクトで使用できると思われます) があります。この場合、var ${env.name} が不明な名前である場合、もちろん、構成ディレクトリにログインするための構成ファイルはありません。

ファイル config/env/log4j-${env.name}.xml が見つからなかった場合、デフォルトの設定ファイルを読み込むにはどうすればよいですか? 環境固有の構成を実装するこの方法 (Spring Bean レベルを使用) についてのみ話しているわけではありませんが、その構成が環境固有の負荷を実装できる場合に備えて、log4j をバージョン 2 にアップグレードするか、同様の機能を持つ他のロガーに切り替えることも可能です。構成レベル (ある種の構成継承である可能性があります)?

log4j構成のすべての力を使用していないだけで、環境変数に接続されたロジックを使用して、1つの構成ファイルで環境固有のアペンダーを作成できますか? バリエーションやアイデアはありますか？

4

1 に答える 1

1

「すぐに使える」ソリューションはありません。

を使用する代わりにMethodInvokingFactoryBean、パラメーターを検証してから を呼び出す独自の Bean を作成しますLog4jConfigurer.initLogging()。

または、この新しい Bean に構成のリストを渡し、それぞれを順番に試行させます。

于 2013-09-24T11:21:29.180 に答える