logback brzmi bardzo podobnie do logowania się w jakarta commons - jakie są główne różnice?
mat b
12
SLF4J (czyli fasada) brzmi podobnie do commons.logging. Główną różnicą jest to, że SLF4J używa statycznego wiązania, podczas gdy commons.logging używa jakiejś strategii rozwiązywania. Logback („natywna” (tj. Nie ma dodatkowej warstwy wrapper) implementacja fasady) jest porównywalna z LOG4J, ale ma bogatsze API.
Huxi
Odpowiedzi:
190
Logback natywnie implementuje SLF4J API. Oznacza to, że jeśli korzystasz z logowania zwrotnego, w rzeczywistości używasz SLF4J API. Teoretycznie można by bezpośrednio użyć wewnętrznego interfejsu API logowania do logowania, ale jest to wysoce odradzane. Cała dokumentacja logbacka i przykłady dotyczące rejestratorów są napisane pod kątem API SLF4J.
Więc używając logback, faktycznie używałbyś SLF4J i jeśli z jakiegoś powodu chciałbyś przełączyć się z powrotem na log4j, możesz to zrobić w ciągu kilku minut, po prostu upuszczając slf4j-log4j12.jar na ścieżkę klasy.
Podczas migracji z logback do log4j, wylogowuj określone części, szczególnie te zawarte w logback pliku konfiguracyjnym logback.xml , nadal musiałyby zostać przeniesione do jego odpowiednika log4j, tj . Log4j.properties . Podczas migracji w innym kierunku konfiguracja log4j, tj. Log4j.properties , musiałaby zostać przekonwertowana na jej odpowiednik logback. Jest do tego narzędzie online . Nakład pracy związany z migracją plików konfiguracyjnych jest znacznie mniejszy niż praca wymagana do migracji wywołań programu rejestrującego rozpowszechnionych w całym kodzie źródłowym oprogramowania i jego zależnościach.
To świetna okazja do rozmowy z twórcą tak popularnego oprogramowania. Dzięki Ceki za log4j.
Srujan Kumar Gulla
7
Zastrzeżenie: ten facet jest oryginalnym twórcą wszystkich Log4j, SLF4J i Logback. Ale nie pracuj już dla Log4j.
Victor Stafusa
56
Powinieneś? Tak .
Czemu? Log4J został zasadniczo wycofany przez Logback .
Czy to jest pilne? Może nie.
Czy to jest bezbolesne? Prawdopodobnie, ale może to zależeć od instrukcji logowania.
Zwróć uwagę, że jeśli naprawdę chcesz w pełni wykorzystać LogBack (lub SLF4J), to naprawdę musisz napisać odpowiednie instrukcje logowania . Zapewni to korzyści, takie jak szybszy kod z powodu leniwej oceny i mniej wierszy kodu, ponieważ można uniknąć strażników.
Na koniec bardzo polecam SLF4J. (Po co odtwarzać koło z własną fasadą?)
Uwaga: projekt log4j nie uznaje log4j za przestarzały.
Thorbjørn Ravn Andersen
17
Terminologia powinna zostać wyjaśniona; jednoznacznie autor projektu log4j uważa logback za następcę log4j. To ten sam autor obu projektów, więc jego opinia powinna mieć znaczenie; sam "projekt log4j" tak naprawdę niczego nie "bierze pod uwagę". Obecna grupa osób związanych z log4j ma rozbieżne opinie (niektórzy faktycznie się zgadzają, inni nie są zaskoczeni). Mając trochę więcej historii za nami (3 lata po oryginalnym komentarzu), SLF4J + Logback nadal zyskuje na popularności w stosunku do Log4j.
michael
@michael_n Zauważ, że Log4j 1 NIE został napisany przez jedną osobę. Błędem jest powiedzenie „tego samego autora”. Ceki jest bez wątpienia ważnym autorem, ale nie jedynym. W rzeczywistości wiele osób pomogło stworzyć Log4j 1 takim, jakim jest.
Christian,
@Christian "NIE zostało napisane ...", oczywiście, powinno to być zasugerowane dla każdego dojrzałego projektu Apache (i mojej kwalifikacji, "obecna grupa ludzi związana z log4j"); niemniej jednak, gdybym mógł edytować komentarz, powiedziałbym, że „ autorstwo oryginalnie ”, jak stwierdza również artykuł na Wikipedii. Odp .: „W rzeczywistości wiele osób pomogło uczynić Log4j 1 tym, czym jest” , to jest absolutnie, dwuznacznie prawdziwe (tj. Na dobre lub na złe); a także w pewnym stopniu przyczyniły się do powstania slf4j + logback :-)
michael
3
Więc co z tego, że wszyscy walczysz o tę lub inną bibliotekę rejestrowania? Dlaczego próbujemy zabijać / promować biblioteki? Przynajmniej podaj jakieś racjonalne uzasadnienie, DLACZEGO jeden jest lepszy od drugiego. Boże, przepełnienie stosu to bałagan.
Użytkownik
48
W świecie rejestrowania są fasady (takie jak Apache Commons Logging, slf4j lub nawet Log4j 2.0 API) i implementacje (Log4j 1 + 2, java.util.logging, TinyLog, Logback).
Zasadniczo powinieneś wymienić swój własny wrapper na slf4j IF i tylko wtedy, gdy nie jesteś z niego zadowolony z jakiegoś powodu. Podczas gdy Apache Commons Logging tak naprawdę nie zapewnia nowoczesnego API, zapewnia to slf4j i nowa fasada Log4j 2. Biorąc pod uwagę, że wiele aplikacji używa slf4j jako opakowania, może to mieć sens.
slf4j daje wiele fajnych cukierków API, jak ten przykład z dokumentów slf4j:
logger.debug("Temperature set to {}. Old temperature was {}.", t, oldT);
To podstawianie zmiennych. Jest to również obsługiwane przez Log4j 2.
Musisz jednak mieć świadomość, że slf4j został opracowany przez QOS, który również utrzymuje logback. Log4j 2.0 jest wypalany w Apache Software Foundation. W ciągu ostatnich trzech lat ponownie wyrosła tam tętniąca życiem i aktywna społeczność. Jeśli cenisz Open Source, tak jak robi to Apache Software Foundation ze wszystkimi jego gwarancjami, możesz ponownie rozważyć użycie slf4j na korzyść bezpośredniego użycia Log4j 2.
Proszę zanotować:
W przeszłości log4j 1 nie był aktywnie obsługiwany, podczas gdy Logback był. Ale dzisiaj jest inaczej. Log4j 2 jest aktywnie rozwijany i wydaje się prawie regularnie. Zawiera również wiele nowoczesnych funkcji, a -imho- czyni kilka rzeczy lepszymi niż Logback. Czasami jest to tylko kwestia gustu i powinieneś wyciągnąć własne wnioski.
Podczas czytania zobaczysz, że Log4j 2 został zainspirowany Logbackiem, ale także innymi platformami rejestrowania. Ale podstawa kodu jest inna; prawie nic nie dzieli z Log4j 1 i zero z Logback. Doprowadziło to do pewnych ulepszeń, takich jak w przykładzie Log4j 2 działa ze strumieniami bajtowymi zamiast Strings pod maską. Nie traci też zdarzeń podczas rekonfiguracji.
Wszystko wskazuje na to, że najlepszym pomysłem jest wybranie struktur rejestrowania, które najlepiej pasują do tego, co chcesz osiągnąć. Nie przełączałbym pełnego frameworka, gdybym wyłączył logowanie w środowisku produkcyjnym i po prostu wykonał podstawowe logowanie w mojej aplikacji. Jeśli jednak robisz trochę więcej z logowaniem, po prostu spójrz na funkcje, które są dostarczane przez frameworki i ich twórców. Chociaż otrzymujesz komercyjne wsparcie dla Logback przez QOS (słyszałem), obecnie nie ma komercyjnego wsparcia dla Log4j 2. Z drugiej strony, jeśli potrzebujesz przeprowadzić rejestrację audytu i potrzebujesz wysokiej wydajności zapewnianej przez asynchroniczne programy dołączające, bardzo sensowne jest sprawdź log4j 2.
Należy pamiętać, pomimo całego komfortu, jaki zapewniają, fasady zawsze pochłaniają trochę wydajności. Być może nie ma to na ciebie żadnego wpływu, ale jeśli masz mało zasobów, być może będziesz musiał zapisać wszystko, co możesz mieć.
Bez lepszego poznania wymagań jest prawie niemożliwe udzielenie rekomendacji. Po prostu: nie zmieniaj tylko dlatego, że wiele osób się zmienia. Przełącz się tylko dlatego, że widzisz jego wartość. Argument, że log4j jest martwy, już się nie liczy. Żyje i jest gorąco.
ZRZECZENIE SIĘ: Obecnie jestem wiceprezesem Apache Logging Services i zajmuję się również log4j.
Nie do końca odpowiadając na twoje pytanie, ale gdybyś mógł odejść od własnej roboty wrappera, to istnieje Simple Logging Facade for Java (SLF4J), na który Hibernate się teraz przełączył (zamiast zwykłego logowania).
SLF4J nie cierpi z powodu żadnego z problemów z ładowaniem klas ani wycieków pamięci obserwowanych w Jakarta Commons Logging (JCL).
SLF4J obsługuje logowanie JDK, log4j i logback. Zatem przejście z log4j do logback powinno być dość łatwe w odpowiednim momencie.
Edycja: Aplogies, których nie wyraziłem jasno. Sugerowałem użycie SLF4J, aby odizolować się od konieczności dokonywania trudnego wyboru między log4j lub logback.
Znam SLF4J. Ale poprosiłem o ramy do drewna, a nie o elewację!
4
Przeprosiny. Sugerowałem, że gdybyś używał SLF4J zamiast własnej niestandardowej fasady, to przejście z log4j na logback byłoby mniej bolesne?
zestaw narzędzi,
Jakie jest źródło tego cytatu? Rejestrowanie plików Commons to wypróbowany i przetestowany składnik. Nigdy nie miałem z tym wycieku pamięci.
Kshitiz Sharma
1
@KshitizSharma - z linku do dokumentacji SLF4J, który dostarczyłem: slf4j.org/manual.html
zestaw narzędzi
13
Twoja decyzja powinna być oparta na
twoje rzeczywiste zapotrzebowanie na te „więcej funkcji”; i
Twój oczekiwany koszt wprowadzenia zmiany.
Powinieneś oprzeć się pokusie zmiany interfejsów API tylko dlatego, że jest „nowszy, lśniący, lepszy”. Przestrzegam zasady „jeśli coś nie jest zepsute, nie kopaj”.
Jeśli Twoja aplikacja wymaga bardzo wyrafinowanej struktury rejestrowania, warto zastanowić się, dlaczego.
Dojrzały projekt lub nawet projekt znajdujący się głęboko w fazie rozwoju prawdopodobnie straciłby więcej niż zysk z takiej aktualizacji, IMHO. Logback jest z pewnością znacznie bardziej zaawansowany w szeregu punktów, ale nie w stopniu umożliwiającym całkowitą wymianę w działającym systemie. Z pewnością rozważałbym logowanie do nowego programu, ale istniejący log4j jest wystarczająco dobry i dojrzały dla wszystkiego, co już zostało wydane i spotkało użytkownika końcowego. To bardzo subiektywne, powinieneś sam zobaczyć koszty.
Odpowiedzi:
Logback natywnie implementuje SLF4J API. Oznacza to, że jeśli korzystasz z logowania zwrotnego, w rzeczywistości używasz SLF4J API. Teoretycznie można by bezpośrednio użyć wewnętrznego interfejsu API logowania do logowania, ale jest to wysoce odradzane. Cała dokumentacja logbacka i przykłady dotyczące rejestratorów są napisane pod kątem API SLF4J.
Więc używając logback, faktycznie używałbyś SLF4J i jeśli z jakiegoś powodu chciałbyś przełączyć się z powrotem na log4j, możesz to zrobić w ciągu kilku minut, po prostu upuszczając slf4j-log4j12.jar na ścieżkę klasy.
Podczas migracji z logback do log4j, wylogowuj określone części, szczególnie te zawarte w logback pliku konfiguracyjnym logback.xml , nadal musiałyby zostać przeniesione do jego odpowiednika log4j, tj . Log4j.properties . Podczas migracji w innym kierunku konfiguracja log4j, tj. Log4j.properties , musiałaby zostać przekonwertowana na jej odpowiednik logback. Jest do tego narzędzie online . Nakład pracy związany z migracją plików konfiguracyjnych jest znacznie mniejszy niż praca wymagana do migracji wywołań programu rejestrującego rozpowszechnionych w całym kodzie źródłowym oprogramowania i jego zależnościach.
źródło
Powinieneś? Tak .
Czemu? Log4J został zasadniczo wycofany przez Logback .
Czy to jest pilne? Może nie.
Czy to jest bezbolesne? Prawdopodobnie, ale może to zależeć od instrukcji logowania.
Zwróć uwagę, że jeśli naprawdę chcesz w pełni wykorzystać LogBack (lub SLF4J), to naprawdę musisz napisać odpowiednie instrukcje logowania . Zapewni to korzyści, takie jak szybszy kod z powodu leniwej oceny i mniej wierszy kodu, ponieważ można uniknąć strażników.
Na koniec bardzo polecam SLF4J. (Po co odtwarzać koło z własną fasadą?)
źródło
W świecie rejestrowania są fasady (takie jak Apache Commons Logging, slf4j lub nawet Log4j 2.0 API) i implementacje (Log4j 1 + 2, java.util.logging, TinyLog, Logback).
Zasadniczo powinieneś wymienić swój własny wrapper na slf4j IF i tylko wtedy, gdy nie jesteś z niego zadowolony z jakiegoś powodu. Podczas gdy Apache Commons Logging tak naprawdę nie zapewnia nowoczesnego API, zapewnia to slf4j i nowa fasada Log4j 2. Biorąc pod uwagę, że wiele aplikacji używa slf4j jako opakowania, może to mieć sens.
slf4j daje wiele fajnych cukierków API, jak ten przykład z dokumentów slf4j:
logger.debug("Temperature set to {}. Old temperature was {}.", t, oldT);To podstawianie zmiennych. Jest to również obsługiwane przez Log4j 2.
Musisz jednak mieć świadomość, że slf4j został opracowany przez QOS, który również utrzymuje logback. Log4j 2.0 jest wypalany w Apache Software Foundation. W ciągu ostatnich trzech lat ponownie wyrosła tam tętniąca życiem i aktywna społeczność. Jeśli cenisz Open Source, tak jak robi to Apache Software Foundation ze wszystkimi jego gwarancjami, możesz ponownie rozważyć użycie slf4j na korzyść bezpośredniego użycia Log4j 2.
Proszę zanotować:
W przeszłości log4j 1 nie był aktywnie obsługiwany, podczas gdy Logback był. Ale dzisiaj jest inaczej. Log4j 2 jest aktywnie rozwijany i wydaje się prawie regularnie. Zawiera również wiele nowoczesnych funkcji, a -imho- czyni kilka rzeczy lepszymi niż Logback. Czasami jest to tylko kwestia gustu i powinieneś wyciągnąć własne wnioski.
Napisałem krótkie omówienie nowych funkcji Log4j 2.0: http://www.grobmeier.de/the-new-log4j-2-0-05122012.html
Podczas czytania zobaczysz, że Log4j 2 został zainspirowany Logbackiem, ale także innymi platformami rejestrowania. Ale podstawa kodu jest inna; prawie nic nie dzieli z Log4j 1 i zero z Logback. Doprowadziło to do pewnych ulepszeń, takich jak w przykładzie Log4j 2 działa ze strumieniami bajtowymi zamiast Strings pod maską. Nie traci też zdarzeń podczas rekonfiguracji.
Log4j 2 może logować się szybciej niż inne znane mi frameworki: http://www.grobmeier.de/log4j-2-performance-close-to-insane-20072013.html
Mimo to społeczność użytkowników wydaje się być znacznie większa niż Logbacki: http://www.grobmeier.de/apache-log4j-is-the-leading-logging-framework-06082013.html
Wszystko wskazuje na to, że najlepszym pomysłem jest wybranie struktur rejestrowania, które najlepiej pasują do tego, co chcesz osiągnąć. Nie przełączałbym pełnego frameworka, gdybym wyłączył logowanie w środowisku produkcyjnym i po prostu wykonał podstawowe logowanie w mojej aplikacji. Jeśli jednak robisz trochę więcej z logowaniem, po prostu spójrz na funkcje, które są dostarczane przez frameworki i ich twórców. Chociaż otrzymujesz komercyjne wsparcie dla Logback przez QOS (słyszałem), obecnie nie ma komercyjnego wsparcia dla Log4j 2. Z drugiej strony, jeśli potrzebujesz przeprowadzić rejestrację audytu i potrzebujesz wysokiej wydajności zapewnianej przez asynchroniczne programy dołączające, bardzo sensowne jest sprawdź log4j 2.
Należy pamiętać, pomimo całego komfortu, jaki zapewniają, fasady zawsze pochłaniają trochę wydajności. Być może nie ma to na ciebie żadnego wpływu, ale jeśli masz mało zasobów, być może będziesz musiał zapisać wszystko, co możesz mieć.
Bez lepszego poznania wymagań jest prawie niemożliwe udzielenie rekomendacji. Po prostu: nie zmieniaj tylko dlatego, że wiele osób się zmienia. Przełącz się tylko dlatego, że widzisz jego wartość. Argument, że log4j jest martwy, już się nie liczy. Żyje i jest gorąco.
ZRZECZENIE SIĘ: Obecnie jestem wiceprezesem Apache Logging Services i zajmuję się również log4j.
źródło
Nie do końca odpowiadając na twoje pytanie, ale gdybyś mógł odejść od własnej roboty wrappera, to istnieje Simple Logging Facade for Java (SLF4J), na który Hibernate się teraz przełączył (zamiast zwykłego logowania).
SLF4J obsługuje logowanie JDK, log4j i logback. Zatem przejście z log4j do logback powinno być dość łatwe w odpowiednim momencie.
Edycja: Aplogies, których nie wyraziłem jasno. Sugerowałem użycie SLF4J, aby odizolować się od konieczności dokonywania trudnego wyboru między log4j lub logback.
źródło
Twoja decyzja powinna być oparta na
Powinieneś oprzeć się pokusie zmiany interfejsów API tylko dlatego, że jest „nowszy, lśniący, lepszy”. Przestrzegam zasady „jeśli coś nie jest zepsute, nie kopaj”.
Jeśli Twoja aplikacja wymaga bardzo wyrafinowanej struktury rejestrowania, warto zastanowić się, dlaczego.
źródło
Dojrzały projekt lub nawet projekt znajdujący się głęboko w fazie rozwoju prawdopodobnie straciłby więcej niż zysk z takiej aktualizacji, IMHO. Logback jest z pewnością znacznie bardziej zaawansowany w szeregu punktów, ale nie w stopniu umożliwiającym całkowitą wymianę w działającym systemie. Z pewnością rozważałbym logowanie do nowego programu, ale istniejący log4j jest wystarczająco dobry i dojrzały dla wszystkiego, co już zostało wydane i spotkało użytkownika końcowego. To bardzo subiektywne, powinieneś sam zobaczyć koszty.
źródło