Deprecate usage of TCCL in `Loader/LoaderUtil`

オープン
#2,850 コメント 2 件 リアクション 1 件 担当者 0 名 GitHub で見る

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

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

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
リファクタリング
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
java
領域
backend

調査の方向性

まず issue #1977 と、2.x コードベースでの Loader および LoaderUtil の使用箇所を読みます。loadClass(String) と類似のエントリポイントを追跡し、ここで説明されている LoggerContext の classloader の選択も確認します。TCCL に依存する使用が削除または非推奨化され、それぞれのケースに対して明示的な classloader パスが確立されれば完了です。

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

説明

As a complement to #1977, we should probably remove the usage of the thread context classloader from Loader and LoaderUtil in 2.x

The usage of Loader.loadClass(String) and LoaderUtil.loadClass(String) and similar methods is extremely prone to memory leaks, since the result of such a call is often assigned to a static field.

The thread context classloader is often the classloader of a web application that can be stopped and restarted at will. Any object that we obtain from it must be kept in a weak reference.

IMHO, we should always provide an explicit classloader to load a class by name and we can only choose between:

  • the classloader that loaded log4j-core or log4j-api,
  • the classloader associated with the current LoggerContext.
主要言語
Java
スター
3.6k
フォーク
1.8k
平均マージ
5日 6時間
マージ済み PR(30日)
24

環境構築

  • Dockerfile・Docker Compose ファイルなし
  • プルリクエストのテンプレートあり
  • コントリビューションガイドなし

はじめの一歩

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

apache/logging-log4j2 のほかの issue

apache/logging-log4j2 の issue をすべて見る

似ている issue

Java の issue をもっと見る

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

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