Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Logger.debug(Class, Supplier) logs under java.lang.Class instead of the given class

オープン 初心者向け
  • 何か問題がありますか？
#38,211 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
78/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
java
領域
backend

調査の方向性

Logger.javaから始めます。issueによると、infoとwarnにはすでに対応するクラス用オーバーロードがあります。次にLoggerTestを調べます。現在テストされているのはインスタンスベースの呼び出しだけです。DEBUGが有効な場合と無効な場合の、クラスベースのsupplier呼び出しをテストに追加し、throwableを渡す形式も含めます。完了条件は、指定されたクラスロガーを使用し、throwableを保持し、DEBUGが無効なときにsupplierの評価を省略することです。

索引モデルが issue の本文から書いたものです。

説明

OKR : Customer Support Team : Falcon Type : Defect
Problem Statement

com.dotmarketing.util.Logger has no debug(Class, Supplier<String>) overload. A call written in the usual static style:

Logger.debug(MyService.class, () -> "message");

compiles against debug(Object ob, Supplier<String> message) instead, because a Class is also an Object. That method resolves the logger with ob.getClass(), and for a Class argument that returns java.lang.Class. The message is therefore checked against, and written to, the java.lang.Class logger rather than MyService's logger.

Impact:

  • Enabling DEBUG for the owning class (log4j config, PUT /api/v1/logger, or System → Logs) has no effect on these messages. They stay silent.
  • They only appear if java.lang.Class is set to DEBUG, and then show up under the name lang.Class, which makes them hard to attribute.
  • The same applies to debug(Object, Throwable, Supplier) when called with a Class.

info and warn are not affected: they already have (Class, Supplier) overloads (Logger.java lines 70 and 423). Only debug is missing them.

Scope on main: 107 calls of the form Logger.debug(X.class, () -> ...) plus 4 of the form Logger.debug(X.class, e, () -> ...), across 49 files under dotCMS/src/main/java.

The existing LoggerTest only calls Logger.debug(this, ...) with an instance, which works, so the class-based form is untested.

Steps to Reproduce

Runtime (example: AuthCredentialPushPublishUtil, which logs a DEBUG message when a push-publish auth key does not match the one configured for the sending server)

  1. Run a receiver instance with USE_JWT_TOKEN_IN_PUSH_PUBLISH=false.
  2. In Publishing Environments, register a server to receive from: address = the IP the receiver sees for your requests, Auth Key = correct-key. (The receiver log line Authentication Token is invalid for ip: X shows that IP.)
  3. Set the class's logger to DEBUG: 
    curl -u [email protected]:admin -X PUT http://localhost:8080/api/v1/logger \
  -H "Content-Type: application/json" \
  -d '{"name":"com.dotcms.publisher.pusher.AuthCredentialPushPublishUtil","level":"DEBUG"}'
  4. Send a push-publish request with a non-matching key: 
    curl -X POST http://localhost:8080/api/bundlePublisher/publish \
  -H "Authorization: Bearer wrong-key" \
  -H "Content-Type: application/octet-stream" --data-binary "not-a-bundle"
  5. Actual: HTTP 401, and no Push publish key does not match the one set for endpoint: <name> line in the log.
  6. Set java.lang.Class to DEBUG instead and repeat step 4: 
    curl -u [email protected]:admin -X PUT http://localhost:8080/api/v1/logger \
  -H "Content-Type: application/json" \
  -d '{"name":"java.lang.Class","level":"DEBUG"}'
    Actual: the line now appears, attributed to the wrong logger: 
    DEBUG lang.Class - Push publish key does not match the one set for endpoint: <name>

The same happens for any of the 111 call sites, e.g. com.dotcms.analytics.attributes.CustomAttributeAPIImpl.

Unit test (fails today)

@Test
public void debug_supplier_with_class_uses_that_class_logger() {
    final String loggerName = LoggerTest.class.getName();
    try {
        Logger.setLevel(loggerName, "DEBUG");
        final AtomicBoolean evaluated = new AtomicBoolean(false);
        Logger.debug(LoggerTest.class, () -> {
            evaluated.set(true);
            return "should be built";
        });
        assertTrue(evaluated.get()); // fails: the java.lang.Class logger is checked instead
    } finally {
        Logger.setLevel(loggerName, "INFO");
    }
}

Expected: the message is checked against and logged under the class that was passed in.

Acceptance Criteria
  • Logger.debug(X.class, supplier) checks DEBUG on, and logs under, X's logger.
  • Logger.debug(X.class, throwable, supplier) does the same and keeps the throwable.
  • The supplier is still not evaluated when DEBUG is disabled for X (no eager message building).
  • Logger.debug(this, supplier) with an instance behaves as today.
  • Existing call sites need no change; the fix is new overloads in Logger.
  • LoggerTest covers the class-based forms, enabled and disabled, and fails without the fix.
dotCMS Version

Latest from main (reproduced on 26.10.21-01).

Severity

Medium - Some functionality impacted

Links

NA

主要言語
Java
スター
972
フォーク
489
平均マージ
2日 15時間
マージ済み PR（30日）
206

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

dotCMS/core のほかの issue

dotCMS/core の issue をすべて見る

似ている issue

Java の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。