Tomcat10 + log4j2

log4jはlog4j2になって、設定が自動読み込みされるようになった。
Tomcat等Webアプリの場合の設定ファイルの置き場はマニュアルによると、
  1. サーブレットコンテクストに場所が指定されていれば、その場所を探す。
  2. 場所が指定されていなければ、WEB-INFディレクト内のlog4j2で始まるファイル名のファイルを探す。
  3. classpathとか、(Webアプリではない場合と同じ)通常の設定ファイル検索を行う。
となっている。

そこでTomcat10でWEB-INFにlog4j2.xmlを置いたのだが、無視されてしまう。 src直下にlog4j2.xmlを置くと、自動で読み込んでくれた。

なぜ、WEB-INF配下のを読まないのか、log4jのデバッグ出力を有効にしたりして、ソースを追いかけたところ、org.apache.logging.log4j.util.Constantsのコメントにこんな記述を発見。

if we think we are running in a web container, based on the boolean value of system property "log4j2.is.webapp", or (if this system property is not set) whether the javax.servlet.Servlet class is present in the classpath.

Tomcat10ではサーブレットがjavax.servlet.*からjakarta.servlet.*に変わってしまったので、log4j2はWebアプリと判別できなくなってしまったようだ。

コメント

コメントを投稿

このブログの人気の投稿

ORACLEのCHAR型とPostgreSQLのchar型は似て非なるもの

ORACLEでもPostgreSQLでもCHAR型は一言で言うと「長さが固定の文字列」だ。 定義 指定サイズより短い文字列を挿入すると末尾に空白が埋められて、指定されたサイズになる。 なお、ORACLEのCHAR型サイズはバイト数だが、PostgreSQLのCHAR型サイズは文字数なので、PostgreSQLのCHAR型はORACLEのNCHAR型に近い。 データ更新 指定されたサイズより長い文字列を挿入しようとすると、ORACLEはエラーになり、PostgreSQLは指定サイズで切り捨てる。 比較演算 PostgreSQL マニュアルには次のように記載されている。 最後の空白は、重要ではないものとして扱われ、2つのcharacter型の値を比べる際には無視されます。 空白が重要な照合順序では、この挙動は予期しない結果を返す可能性があります。例えば、SELECT 'a '::CHAR(2) collate "C" < E'a\n'::CHAR(2)はCロケールでスペースが改行よりも大きいにも関わらず真を返します。character値を他の文字列型に変換する際は、文字列の終わりの空白は除去されます。 例がちょっとわかりにくいが、 'a'::CHAR(1) = 'a '::CHAR(2) は真と判定されるし、 'a'::varchar = 'a '::CHAR(2) も真と判定される。 ORACLE ORACLEには 空白埋め比較セマンティクス と 非空白埋め比較セマンティクス がある。 CHAR型同士の比較などでは空白埋め比較セマンティクスが使われるが、 比較する片方または両方の値が(N)VARCHAR2データ型の場合、非空白埋め比較セマンティクスが使われる。 非空白埋め比較セマンティクスはマニュアルに次のように記載されている。 2つの値を、最初に異なる文字まで1文字ずつ比較します。最初に異なる文字の位置で、大きい方の文字を持つ値の方が大きいとみなされます。長さが異なる2つの値を短い方の値の最後まで比較して、すべて同じ文字だった場合、長い方の値が大きいとみなされます。同じ長さの2つの値に異...
続きを読む

XBox360コントローラドライバのせいでコア分離セキュリティが有効にできない場合

コア分離を有効化しようとしたらxusb21.sys(XBox360コントローラドライバ)が対応していないので、有効化できなかった。 このコントローラはこのPCでは使ってなかったので、 pnputil -d oem~.inf ※oem~.infはコア分離に失敗したときに表示されていたファイル名。pnputil -eでも調べられる。 で、ドライバストアからxusb21.sysを削除して、コア分離を有効化できた。
続きを読む