Aktualizacja bibliotek log4j 1.2 - 2.17.2 oraz konfiguracji

Autor
Damian
Terlecki
4 minuty
Java

Niedawne luki bezpieczeństwa w bibliotece log4j2 wywołały spore zamieszanie w świecie Javy. Z pewnością wielu twórców zaczęło bardziej interesować się tym, jakie zależności wykorzystują w swoich produktach. Obecnie możemy cieszyć się dwiema bezpiecznymi wersjami log4j, mianowicie 2.17.1 i 2.17.2. Niektóre starsze produkty nadal jednak używają wersji 1.2 log4j, która osiągnęła koniec cyklu życia w 2015 roku. Co więcej, wiele z nich często nie wykorzystuje też żadnej fasady typu slf4j, bezpośrednio odwołując się do interfejsu log4j.

W procesie aktualizacji możesz wybrać zastąpienie wersji 1.2 biblioteką reload4j zawierającą te same klasy, połatane pod względem krytycznych luk. Najbardziej szanowanym podejściem jest jednak pełna migracja do log4j2. Trzecią opcją jest spotkanie się w połowie drogi i użycie mostu log4j-1.2-api, który łączy stare API z rdzeniem wersji 2.

Using log4j 2 via the log4j 1.x API
Źródło: https://logging.apache.org/log4j/2.x/manual/migration.html na licencji Apache 2.0

Oprócz samego API, log4j2 wprowadził wsparcie obsługi starej konfiguracji już w wersji 2.13.3. Nie każdy element konfiguracji był jednak w pełni obsługiwany. Szczególnie problematyczne okazały się dodatki z biblioteki, apache-log4j-extras (która, nawiasem mówiąc, zawiera pewien podzbiór klas z 1.2, co sprawia, że korzystanie z niej jest nieco wątpliwe).

Uwaga: Kilka obiecujących ulepszeń, zaplanowanych na wersję 2.18, ma pozwolić na obsłużenie dodatkowych elementów konfiguracyjnych znanych z apache-extra, takich jak np. org.apache.log4j.rolling.RollingFileAppender.

Możemy więc zaktualizować konfigurację do nowego formatu lub pozostawić ją w starej wersji o ile nie wybiega ona poza standardowe wsparcie. Warto jeszcze zwrócić uwagę na ulepszenia zaimplementowane w wersji 2.17.2 w porównaniu do 2.17.1. Wcześniej ładowanie konfiguracji przez most za pomocą kodu było zaimplementowane jako brak operacji. Wersja 2.17.2, poza licznymi poprawkami, zmienia również to zachowanie.

Jeśli masz pozostałości kodu, który ładuje konfigurację za pomocą interfejsu API 1.2, na przykład tak:

DOMConfigurator.configure(filename);
DOMConfigurator.configureAndWatch(configFilename, delay);

Możesz spodziewać się różnego zachowania. Jak wspomniano w dokumentacji dotyczących migracji, nie jest to dozwolone, ale do wersji 2.17.1 włącznie, nie miało to żadnych negatywnych skutków. W wersji 2.17.2 biblioteka spróbuje załadować konfigurację 1.x, co będzie miało wpływ na Twoje podeście do aktualizacji, jeśli używasz tego interfejsu:

public class DOMConfigurator {
    //2.17.1:
    public static void configureAndWatch(final String configFilename, final long delay) {
    }

    //2.17.2:
    public static void configureAndWatch(final String fileName, final long delay) {
        XMLWatchdog xdog = new XMLWatchdog(fileName);
        xdog.setDelay(delay);
        xdog.start();
    }
    //...
}

Jeśli chodzi o właściwości systemu, preferowanym źródłem konfiguracji podczas korzystania z mostu jest parametr log4j.configurationFile znany z log4j2. Jednocześnie możesz użyć starszego parametru systemowego log4j.configuration z wersji 1.x, który ułatwia płynne przejście do nowego formatu.