Pertanyaan Haruskah proyek baru menggunakan logback, bukan log4j? [Tutup]


Haruskah proyek baru menggunakan logback, bukan log4j sebagai kerangka kerja pencatatan?

Atau dengan kata lain: 'Apakah logback lebih baik daripada log4j (meninggalkan SLF4J-'fitur' dari logback di samping)? '


76
2017-10-07 14:55


asal


Jawaban:


Anda harus menggunakan SLF4J + Logback untuk masuk.

Ini menyediakan fitur yang rapi seperti pesan parametrized dan (berbeda dengan commons-logging) Konteks Diagnostik yang Dipetakan (MDC, javadoc, dokumentasi).

Menggunakan SLF4J membuat logging backend dapat ditukarkan dengan cara yang cukup elegan.

Selain itu, SLF4J mendukung bridging kerangka kerja penebangan lain ke implementasi SLF4J yang sebenarnya akan Anda gunakan sehingga aktivitas pencatatan dari perangkat lunak pihak ketiga akan muncul dalam log terpadu Anda - dengan pengecualian java.util.logging yang tidak dapat dijembatani dengan cara yang sama dengan pencatatan lain kerangka kerja adalah.

Menjembatani jul dijelaskan dalam javadocs dari SLF4JBridgeHandler.

Saya telah memiliki pengalaman yang sangat baik menggunakan kombinasi SLF4J + Logback di beberapa proyek dan pengembangan LOG4J telah cukup banyak terhenti.

SLF4J memiliki kelebihan yang tersisa berikut ini:

  • Itu tidak mendukung varargs untuk tetap kompatibel dengan Java <1.5
  • Itu tidak mendukung menggunakan pesan parametrized dan pengecualian pada saat yang sama.
  • Ini tidak berisi dukungan untuk Konteks Diagnostik Bersarang (NDC, javadoc) yang dimiliki LOG4J.

81
2018-05-31 22:10



Penulis (Logback dan Log4j) memiliki daftar alasan untuk berubah http://logback.qos.ch/reasonsToSwitch.html.

Inilah beberapa yang mencuat ke arah saya;

  • Implementasi lebih cepat

    Berdasarkan pekerjaan kami sebelumnya di log4j, logback internal telah ditulis ulang untuk tampil sekitar sepuluh kali lebih cepat pada eksekusi kritis tertentu jalur. Tidak hanya logback komponen lebih cepat, mereka memiliki jejak memori yang lebih kecil juga.

  • Reload konfigurasi otomatis file

    Logback-klasik dapat secara otomatis memuat kembali file konfigurasinya modifikasi. Proses pemindaian adalah cepat dan aman karena tidak melibatkan penciptaan yang terpisah utas pemindaian. Ini teknis kehalusan memastikan bahwa logback memainkan baik dalam server aplikasi dan lebih umum dalam JEE lingkungan Hidup.

  • Jejak stack dengan data pengemasan

    Ketika logback mencetak pengecualian, jejak stack akan mencakup kemasan data. Berikut ini contoh jejak tumpukan dihasilkan oleh logback-demo aplikasi web.

    14: 28: 48.835 [btpool0-7] INFO c.q.l.demo.prime.PrimeAction - 99 adalah bukan nilai yang valid java.lang.Exception: 99 tidak valid
    di ch.qos.logback.demo.prime.PrimeAction.execute (PrimeAction.java:28) [kelas /: na] di org.apache.struts.action.RequestProcessor.processActionPerform (RequestProcessor.java:431) [struts-1.2.9.jar: 1.2.9] di org.apache.struts.action.RequestProcessor.process (RequestProcessor.java:236) [struts-1.2.9.jar: 1.2.9] di org.apache.struts.action.ActionServlet.doPost (ActionServlet.java:432) [struts-1.2.9.jar: 1.2.9] di javax.servlet.http.HttpServlet.service (HttpServlet.java:820) [servlet-api-2.5-6.1.12.jar: 6.1.12]
    di org.mortbay.jetty.servlet.ServletHolder.handle (ServletHolder.java.502) [jetty-6.1.12.jar: 6.1.12] di ch.qos.logback.demo.UserServletFilter.doFilter (UserServletFilter.java:44) [kelas /: na] di org.mortbay.jetty.servlet.ServletHandler $ CachedChain.doFilter (ServletHandler.java:1115) [jetty-6.1.12.jar: 6.1.12] di org.mortbay.jetty.servlet.ServletHandler.handle (ServletHandler.java:361) [jetty-6.1.12.jar: 6.1.12] di org.mortbay.jetty.webapp.WebAppContext.handle (WebAppContext.java:417) [jetty-6.1.12.jar: 6.1.12] di org.mortbay.jetty.handler.ContextHandlerCollection.handle (ContextHandlerCollection.java:230) [jetty-6.1.12.jar: 6.1.12]

    Dari penjelasan di atas, Anda dapat mengenali bahwa aplikasi menggunakan Struts versi 1.2.9 dan ditempatkan di bawah versi jetty 6.1.12. Jadi, tumpuk jejak akan cepat menginformasikan pembaca tentang kelas yang menyimpang di kecuali tetapi juga paket dan versi paket yang mereka miliki. Kapan pelanggan Anda mengirimi Anda setumpuk jejak, sebagai pengembang Anda tidak akan perlu lagi meminta mereka untuk mengirim Anda informasi tentang versi paket yang mereka gunakan. Itu informasi akan menjadi bagian dari tumpukan jejak. Lihat konversi "% xThrowable" kata untuk detail.

    Fitur ini bisa sangat membantu titik yang beberapa pengguna salah menganggapnya sebagai fitur IDE mereka.

  • Penghapusan otomatis arsip log lama

    Dengan menetapkan properti maxHistory TimeBasedRollingPolicy atau UkuranAndTimeBasedFNATP, Anda bisa mengontrol jumlah maksimum file yang diarsipkan. Jika Anda berguling panggilan kebijakan untuk rollover bulanan dan Anda ingin mempertahankan nilai satu tahun log, cukup mengatur maxHistory properti ke 12. file log yang diarsipkan lebih tua dari 12 bulan akan dihapus secara otomatis.

Mungkin ada bias di sana, tetapi orang yang sama itu menulis kedua kerangka dan jika dia mengatakan menggunakan Logback melalui Log4j, dia mungkin patut didengarkan.


20
2018-05-18 12:27



Saya akan menggunakan slf4j untuk login dalam semua kasus. Ini memungkinkan Anda untuk memilih backend pencatatan log aktual yang ingin Anda gunakan, pada waktu penggunaan, bukan waktu kode.

Ini terbukti sangat berharga bagi saya. Ini memungkinkan saya untuk menggunakan log4j di JVM lama, dan logback dalam 1.5+ JVM, dan juga java.util.logging jika diperlukan.


10
2018-01-20 12:47



Mundur lebih banyak Java EE aware:
secara umum (dari kode ke dokumentasi) ini mengingat kontainer - bagaimana beberapa aplikasi hidup berdampingan, bagaimana loader kelas diterapkan, dll. Konteks untuk penebang, JNDI, konfigurasi JMX termasuk dll.

dari pengembang yang prospektif hampir sama, Logback menambahkan Pencatatan parameter (tidak perlu digunakan jika (logger.isDebugEnabled ()) untuk menghindari deretan konklusi string

Log4j - hanya plus besar adalah dukungan JVM lama, kecil (IMO) NDC (Logback only MDC), beberapa ekstensi. Sebagai contoh saya menulis ekstensi untuk configureAndWatch untuk Log4j, tidak ada hal seperti itu untuk Logback


2
2018-04-22 17:02



log4j dan logback asli dirancang dan diimplementasikan oleh orang yang sama.

beberapa alat sumber terbuka telah menggunakan SLF4J. Saya tidak melihat ada kekurangan yang signifikan dalam alat ini. Jadi, kecuali Anda memiliki banyak ekstensi untuk log4j di basis kode Anda, saya akan melanjutkan dengan logback.


1
2017-10-07 15:08



Saya akan berpikir bahwa keputusan Anda harus turun ke keputusan yang sama jika Anda memutuskan antara menggunakan log4j atau Jakarta Commons Logging - apakah Anda mengembangkan perpustakaan yang akan dimasukkan dalam aplikasi lain? Jika demikian, maka tampaknya tidak adil untuk memaksa pengguna perpustakaan Anda untuk juga menggunakan perpustakaan pilihan penebangan Anda.

Jika jawabannya tidak, saya akan pergi dengan apa yang lebih mudah untuk ditambahkan dan apa yang lebih nyaman bagi Anda. Kedengarannya seperti logback hanya sebagai extensible dan dapat diandalkan sebagai log4j, jadi jika Anda nyaman menggunakannya, lanjutkan.


1
2017-10-07 15:50



Saya tidak akrab dengan SLF4J, dan saya hanya melihat sekilas tentang logback, tetapi ada dua hal yang terlintas dalam pikiran saya.

Pertama, mengapa Anda mengecualikan alat dari pemeriksaan? Saya pikir penting untuk tetap berpikiran terbuka dan memeriksa semua kemungkinan untuk memilih yang terbaik.

Kedua, saya pikir dalam beberapa proyek satu alat lebih baik daripada alat lain, dan sebaliknya mungkin benar dalam proyek yang berbeda. Saya tidak berpikir bahwa satu alat selalu lebih baik daripada alat lain. Bagaimanapun juga, ada tidak ada peluru perak.

Untuk menjawab pertanyaan Anda - Ya dan tidak. Itu tergantung pada proyek, dan seberapa akrabnya tim dengan satu alat. Saya tidak akan mengatakan "jangan gunakan log4j" jika seluruh tim sangat nyaman dengannya, ini memenuhi semua kebutuhan, dan logback tidak menawarkan apa pun yang kita perlukan untuk menyelesaikan tugas.


-3
2017-10-07 14:58