Apakah layak menggunakan slf4j dengan log4j2

114

Saya tidak dapat memutuskan apakah akan menggunakan slf4j atau tidak dengan log4j2. Berdasarkan posting online, sepertinya itu tidak akan memiliki kinerja apa pun tetapi apakah itu benar-benar diperlukan.

Juga poin-poin ini mendukung log4j2:

SLF4J memaksa aplikasi Anda untuk mencatat String. API Log4j 2 mendukung pencatatan CharSequence apa pun jika Anda ingin membuat log teks, tetapi juga mendukung pencatatan Objek apa adanya.
Log4j 2 API menawarkan dukungan untuk mencatat objek Pesan, ekspresi lambda Java 8, dan logging bebas sampah (ini menghindari pembuatan larik vararg dan menghindari pembuatan Strings saat membuat log objek CharSequence).

— Andy897
sumber

Mungkin. Bagaimana jika server aplikasi saya menyertakan slf4jdan logback (atau log4jv1)? Haruskah saya kemudian dipaksa untuk menginstal pencatat ketiga untuk menggunakan aplikasi Anda? Atau mungkin keamanan perusahaan memutuskan Anda hanya boleh menggunakan java.util.loggingdalam produksi, lalu bagaimana?

— Elliott Frisch

Terima kasih telah menulis. Namun, jika setiap orang menggunakan lebar log4j org, argumen di atas tidak akan berlaku.

— Andy897

Menggunakan SLF4J berarti mengganti implementasi sangat mudah jika kebijakan perusahaan berubah, misalnya ketika perusahaan Anda diakuisisi dan kebijakan baru dipaksakan pada Anda. Menggunakan SLF4J sekarang, saat Anda menulis kode, tidak akan memakan waktu lebih lama daripada menggunakan Log4j secara langsung. Mengganti panggilan langsung Log4j nanti akan memakan banyak waktu. SLF4J adalah investasi / asuransi gratis untuk masa depan. Apakah itu lebih penting daripada fitur API Log4j 2? Hanya Anda (atau kebijakan perusahaan) yang dapat memutuskan itu.

— Andreas

Apakah ada cara untuk menggunakan slf4j dengan log4j2 jika Anda mau? Halaman ini menunjukkan penggunaan dengan log4j - versi 1.2 - yang sudah habis masa pakainya), tetapi tidak ada opsi untuk log4j2. Jika ada cara, mengapa slf4j tidak menyebutkannya?

— J Woodchuck

162

Lanjutkan: program ke API log4j2, bukan slf4j

Aman: Log4j2 API menawarkan jaminan yang sama persis dengan slf4j - dan banyak lagi.

Sekarang Log4j2 itu sendiri dipisahkan menjadi API dan modul implementasi, tidak ada lagi nilai dalam menggunakan SLF4J.

Ya, merupakan praktik teknik yang baik untuk tetap membuka opsi Anda. Anda mungkin ingin mengubah ke implementasi logging lain nanti.

Selama 10 tahun terakhir ini, membangun fleksibilitas seperti itu dalam aplikasi Anda berarti menggunakan API pembungkus seperti SLF4J. Fleksibilitas ini tidak datang secara gratis: kelemahan dari pendekatan ini adalah aplikasi Anda tidak dapat menggunakan kumpulan fitur yang lebih kaya dari perpustakaan logging yang mendasarinya.

Log4j2 menawarkan solusi yang tidak mengharuskan aplikasi Anda dibatasi pada penyebut umum terendah.

Katup pelepasan: log4j-to-slf4j

Log4j2 menyertakan log4j-to-slf4jmodul jembatan. Aplikasi apa pun yang dikodekan dengan Log4j2 API dapat memilih untuk mengalihkan implementasi pencadangan ke implementasi yang sesuai dengan slf4j kapan saja.

Seperti yang disebutkan dalam pertanyaan, menggunakan API Log4j2 secara langsung menawarkan lebih banyak fungsionalitas dan memiliki beberapa keuntungan non-fungsional dibandingkan menggunakan API pembungkus seperti slf4j:

API Pesan
Lambdas untuk lazy logging
Catat Objek apa pun, bukan hanya String
Bebas Sampah: hindari membuat vararg atau membuat String jika memungkinkan
CloseableThreadContext secara otomatis menghapus item dari MDC setelah Anda selesai menggunakannya

(Lihat 10 fitur API Log4j2 tidak tersedia di SLF4J untuk lebih jelasnya.)

Aplikasi dapat dengan aman menggunakan fitur-fitur kaya Log4j2 API ini tanpa terkunci pada implementasi inti Log4j2 asli.

SLF4J masih merupakan katup pengaman Anda, itu tidak berarti aplikasi Anda harus mengkodekan API SLF4J lagi.

Pengungkapan: Saya berkontribusi ke Log4j2.

Pembaruan: Tampaknya ada beberapa kebingungan bahwa pemrograman ke API Log4j2 entah bagaimana memperkenalkan "fasad untuk fasad". Tidak ada perbedaan dalam hal ini antara API Log4j2 dan SLF4J.

Kedua API tersebut memerlukan 2 dependensi saat menggunakan implementasi native, dan 4 dependensi untuk implementasi non-native. SLF4J dan Log4j2 API identik dalam hal ini. Sebagai contoh:

Dependensi yang diperlukan serupa untuk SLF4J dan Log4j 2 API

— Remko Popma
sumber

Saya mengerti. Biarkan saya menyusun ulang pertanyaan saya. Apakah ada implementasi independen dari API log4j2 selain log4j2?

— Ceki

API dan impl Log4j2 tidak "digabungkan erat". Semua implementasi SLF4J ini semuanya tersedia: Aplikasi yang dikodekan dengan API Log4j2 dapat memilih log4j-to-slf4jdependensi alih-alih log4j-coredan memilih salah satu implementasi SLF4J yang Anda sebutkan ini. Jumlah implementasi asli API Log4j2 tidak relevan.

— Remko Popma

Masalahnya adalah Anda sering memiliki ketergantungan pada pustaka yang menggunakan slf4j sendiri, jadi lebih mudah untuk tetap menggunakannya.

— Davio

jadi, saya harus menggunakan antarmuka untuk antarmuka untuk implementasi? Ya, tidak, terima kasih ... Slf4j mengalahkan log4j dengan menyediakan antarmuka yang baik untuk implementasi untuk logging ... log4j2 seharusnya hanya mengimplementasikan slf4j api - jika ada fitur yang hilang, kontribusikan kembali, jika slf4j tidak mau mengambil yang baru fitur, maka MUNGKIN ada kasus untuk antarmuka api log4j2 ....

— RockMeetHardplace

@RemkoPopma - Anda masih menganjurkan agar tidak menggunakan antarmuka log4j. Ya, saya mengerti - Saya bisa merangkai antarmuka log4j2 -> antarmuka slf4j -> implementasi apa pun, tetapi saya lebih suka tidak mengabstraksi abstraksi - terima kasih tetapi tidak, terima kasih.

— RockMeetHardplace