Co słychać w logowaniu w Javie? [Zamknięte]

Dlaczego jeden z poniższych pakietów miałby używać zamiast drugiego?

• Rejestrowanie Java
• Commons Logging
• Log4j
• SLF4j
• Logback

W porządku chronologicznym wyglądu api (o ile wiem):

• Log4j, ponieważ prawie wszyscy go używają (z mojego doświadczenia)
• Commons Logging, ponieważ używają go projekty open source (dzięki czemu mogą integrować się z dowolną strukturą rejestrowania używaną w zintegrowanym rozwiązaniu); szczególnie ważne, jeśli jesteś API / Framework / OSS i polegasz na innych pakietach, które używają Commons Logging.
• Commons Logging, ponieważ nie chcesz "blokować" określonego frameworku rejestrowania (więc zamiast tego ograniczasz się do tego, co daje ci Commons Logging) - nie sądzę, aby rozsądne było decydowanie o tym punkcie jako przyczynie.
• Rejestrowanie Java, ponieważ nie chcesz dodawać dodatkowego pliku jar.
• SLF4j, ponieważ jest nowszy niż Commons Logging i zapewnia sparametryzowane rejestrowanie:

logger.debug("The entry is {}.", entry);
//which expands effectively to
if (logger.isDebugEnabled()){
    // Note that it's actually *more* efficient than this - see Huxi's comment below...
    logger.debug("The entry is " + entry + "."); 
}

• Logback, ponieważ jest nowszy niż log4j i ponownie obsługuje sparametryzowane rejestrowanie, ponieważ bezpośrednio implementuje SLF4j
• SLF4j / Logback, ponieważ został napisany przez tego samego gościa, który zrobił log4j, więc ulepszył go (według Kena G - dzięki. Wydaje się, że pasuje do ich wcześniejszych postów )
• SLF4j, ponieważ publikują również adapter log4j, więc nie musisz "wyłączać" log4j w starszym kodzie - wystarczy, że log4j.properties używa SLF4j i jego konfiguracji

Uważam, że logowanie w Javie jest mylące, niespójne, słabo udokumentowane i szczególnie przypadkowe. Co więcej, istnieje ogromne podobieństwo między tymi strukturami rejestrowania, co powoduje powielanie pracy i niejasności co do środowiska logowania, w którym się aktualnie znajdujesz. W szczególności, jeśli pracujesz w poważnym stosie aplikacji internetowych Java, często jesteś w wielokrotnośćśrodowiska logowania w jednym czasie; (np. hibernacja może używać log4j i tomcat java.util.logging). Apache commons ma na celu łączenie różnych platform logowania, ale tak naprawdę tylko zwiększa złożoność. Jeśli nie wiesz tego z wyprzedzeniem, jest to całkowicie oszałamiające. Dlaczego moje komunikaty dziennika nie są drukowane na konsoli itp.? Och, ponieważ patrzę na logi Tomcata, a nie log4j. Dodając kolejną warstwę złożoności, serwer aplikacji może mieć globalne konfiguracje rejestrowania, które mogą nie rozpoznawać lokalnych konfiguracji dla określonej aplikacji internetowej. Wreszcie, wszystkie te ramy rejestrowania są ZBYT SKOMPLIKOWANE. Logowanie w Javie było chaotycznym bałaganem, przez co deweloperzy tacy jak ja byli sfrustrowani i zdezorientowani.

Wczesne wersje Java nie miały wbudowanej struktury rejestrowania, co prowadziło do tego scenariusza.

Jest jeden ważny punkt, o którym wcześniej nie wspomniano:

SLF4J (i zarówno Logback, jak i LOG4J jako zaplecze logowania) obsługują tak zwany Mapped Diagnostic Context (MDC, patrz javadoc i dokumentacja ).

Jest to zasadniczo mapa <String, String> lokalna dla wątku, której można użyć do dodania dodatkowych informacji kontekstowych do zdarzenia rejestrowania. Aktualny stan MDC jest dołączony do każdego wydarzenia.

Może to być niezwykle przydatne, jeśli umieścisz w nim takie rzeczy, jak nazwa użytkownika i adres URL żądania (w przypadku aplikacji internetowej). Można to zrobić na przykład automatycznie za pomocą filtra.

Zobacz także odpowiedzi na pytanie Jakie są sprawdzone metody rejestrowania błędów? , szczególnie:

• Istnieją pewne potencjalne problemy z ładowaniem klas z Commons Logging.

• Log4J i SLF4J zostały opracowane przez tę samą osobę, ucząc się na podstawie problemów znalezionych w praktyce z Log4J.

W projekcie naszej firmy używamy LOG4j i jest on bardzo łatwy w użyciu, jak pokazał Stephen na swoim przykładzie. Napisaliśmy również własne klasy wzorców dla LOG4j, dzięki czemu możesz tworzyć własne schematy plików wyjściowych. Możesz opisać, jak powinien wyglądać Twój plik dziennika. Możliwe jest rozszerzenie oryginalnych klas log4j.

Wszystkie właściwości LOG4j można zmienić w pliku log4j.properties, dzięki czemu można używać różnych plików dla różnych projektów.

Rejestrowanie w Javie nie jest moją ulubioną, ale może to być spowodowane tym, że używam log4j od samego początku.

Commons Logging przegląd daje powód jego istnienia: Rejestrowanie kodu z biblioteki, gdy nie masz kontroli nad spodem ramy rejestrowania. Bardzo ważne dla różnych projektów Apache, które będą połączone z zewnętrznymi aplikacjami. Być może nie jest to tak ważne dla wewnętrznych projektów IT, w których masz pełną kontrolę.

To powiedziawszy, piszę do Commons Logging, podobnie jak wielu innych programistów, których znam. Powodem jest zminimalizowanie bagażu mentalnego: możesz zmieniać projekty lub prace i nie musisz uczyć się nowych ram (pod warunkiem, że nowa praca / projekt również korzysta z CL i / lub możesz przekonać ich do przejścia do niego).

Istnieje również pewna wartość w tworzeniu własnych opakowań wokół używanego frameworka. Jak opisano tutaj , lubię używać obiektu LogWrapper, aby zapewnić niestandardowe ciągi znaków (ważne) i zminimalizować wizualny bałagan w instrukcjach logowania (mniej ważne).

Generalnie używałbym Log4J.

Użyłbym rejestrowania Java, gdybym nie miał nic przeciwko zależności od Java 1.4, ale nadal preferowałbym Log4J.

Użyłbym Commons Logging, gdybym ulepszał coś, co już go używało.

Sugerowałbym stworzenie cienkiej fasady rejestrowania, która może zapisywać w dowolnej platformie rejestrowania, w którym to momencie wybór silnika wspierającego staje się kwestią sporną.