Câu hỏi Nên các dự án mới sử dụng logback thay vì log4j? [đã đóng]


Nên các dự án mới sử dụng logback thay vì log4j như một khung khai thác gỗ?

Hoặc với các từ khác: 'Có logback tốt hơn log4j (để lại SLF4J-'feature' của logback bên cạnh)? '


76
2017-10-07 14:55


gốc


Bạn có thể mở rộng về lý do tại sao câu hỏi này đã bị đóng? - James McMahon
Câu hỏi này hữu ích cho tôi, bỏ phiếu để mở lại. - Eric Wilson
Làm thế nào trên trái đất này là "quá địa hoá?" Một số lượng lớn các dự án java sử dụng log4j. Câu hỏi liệu nó có nên được coi là "không được chấp nhận" có lợi cho việc đăng nhập mới hơn (mà tác giả dường như xem xét rằng nó không dùng log4j) có liên quan đến nhiều người và sẽ tiếp tục trong một thời gian không. - EricS
Đã bỏ phiếu để mở lại, nhưng dường như chỉ có một phiếu bầu của tôi. - skiphoppy
Bình chọn để mở lại là tốt; Tôi cho rằng nó được bản địa hóa thành "java" và điều đó đủ tốt: / - Paul Gregoire


Các câu trả lời:


Bạn nên sử dụng SLF4J + Logback để ghi nhật ký.

Nó cung cấp các tính năng gọn gàng như các thông điệp được tham số và (trái ngược với việc ghi nhật ký commons) một Ngữ cảnh Chẩn đoán được Ánh xạ (MDC, javadoc, tài liệu).

Sử dụng SLF4J làm cho phụ trợ ghi nhật ký có thể trao đổi một cách khá thanh lịch.

Ngoài ra, SLF4J hỗ trợ bắc cầu các khung công tác ghi nhật ký khác cho việc triển khai SLF4J thực tế bạn sẽ sử dụng để ghi lại các sự kiện từ phần mềm của bên thứ ba sẽ hiển thị trong nhật ký hợp nhất của bạn - ngoại trừ java.util.logging không thể được bắc cầu giống như cách ghi nhật ký khác khung là.

Bridging jul được giải thích trong javadocs của SLF4JBridgeHandler.

Tôi đã có một kinh nghiệm rất tốt bằng cách sử dụng kết hợp SLF4J + Logback trong một số dự án và phát triển LOG4J đã khá nhiều bị đình trệ.

SLF4J có các nhược điểm còn lại sau đây:

  • Nó không hỗ trợ các varargs để tương thích với Java <1.5
  • Nó không hỗ trợ sử dụng cả hai thông điệp parametrized và một ngoại lệ cùng một lúc.
  • Nó không chứa hỗ trợ cho một bối cảnh chẩn đoán lồng nhau (NDC, javadoc) mà LOG4J có.

81
2018-05-31 22:10



LOL, tôi vừa nhận được huy hiệu Necromancer cho câu trả lời này! Cảm ơn tất cả các cử tri;) Tôi chưa bao giờ mong đợi nhận được một ... - Huxi
Ngữ cảnh chẩn đoán được ánh xạ là lựa chọn thay thế mạnh mẽ hơn cho bối cảnh chẩn đoán lồng nhau - Gaël Marziou
Điều đó không hoàn toàn đúng. Họ thực sự là khái niệm trực giao. MDC là một Map trong khi NDC là một Stack. Hãy xem sourceforge.net/apps/trac/lilith/wiki/NestedDiagnosticContext cho một số ví dụ sử dụng. - Huxi
Tôi không bao giờ tìm ra lý do tại sao MDC và NDC được gọi là những gì chúng được gọi thay vì một cái gì đó dễ dàng hơn để ghi nhớ. Thở dài. - Thorbjørn Ravn Andersen
@Huxi, "Bản đồ" và "Stack" có lẽ? - Thorbjørn Ravn Andersen


Tác giả (của cả Logback và Log4j) có một danh sách các lý do để thay đổi tại http://logback.qos.ch/reasonsToSwitch.html.

Dưới đây là một số ít bị mắc kẹt với tôi;

  • Triển khai nhanh hơn

    Dựa trên công việc trước đây của chúng tôi về log4j, logback internals đã được viết lại để thực hiện khoảng mười lần nhanh hơn trên thực thi quan trọng nhất định đường dẫn. Không chỉ là logback các thành phần nhanh hơn, chúng có bộ nhớ nhỏ hơn là tốt.

  • Tự động tải lại cấu hình các tập tin

    Logback-classic có thể tự động tải lại tệp cấu hình của nó khi sửa đổi. Quá trình quét là cả nhanh và an toàn vì nó không liên quan đến việc tạo ra một thread để quét. Kỹ thuật này tinh tế đảm bảo rằng lượt phát lại cũng trong các máy chủ ứng dụng và tổng quát hơn trong JEE môi trường.

  • Stack dấu vết với dữ liệu đóng gói

    Khi logback in một ngoại lệ, stack trace sẽ bao gồm bao bì dữ liệu. Đây là dấu vết ngăn mẫu được tạo bởi bản trình diễn logback ứng dụng web.

    14: 28: 48,835 [btpool0-7] THÔNG TIN c.q.l.demo.prime.PrimeAction - 99 là không phải là giá trị hợp lệ java.lang.Exception: 99 không hợp lệ
    tại ch.qos.logback.demo.prime.PrimeAction.execute (PrimeAction.java:28) [lớp /: na] lúc org.apache.struts.action.RequestProcessor.processActionPerform (RequestProcessor.java:431) [struts-1.2.9.jar: 1.2.9] tại org.apache.struts.action.RequestProcessor.process (RequestProcessor.java:236) [struts-1.2.9.jar: 1.2.9] tại org.apache.struts.action.ActionServlet.doPost (ActionServlet.java:432) [struts-1.2.9.jar: 1.2.9] tại javax.servlet.http.HttpServlet.service (HttpServlet.java:820) [servlet-api-2.5-6.1.12.jar: 6.1.12]
    tại org.mortbay.jetty.servlet.ServletHolder.handle (ServletHolder.java:502) [jetty-6.1.12.jar: 6.1.12] tại ch.qos.logback.demo.UserServletFilter.doFilter (UserServletFilter.java:44) [lớp /: na] lúc org.mortbay.jetty.servlet.ServletHandler $ CachedChain.doFilter (ServletHandler.java:1115) [jetty-6.1.12.jar: 6.1.12] tại org.mortbay.jetty.servlet.ServletHandler.handle (ServletHandler.java:361) [jetty-6.1.12.jar: 6.1.12] tại org.mortbay.jetty.webapp.WebAppContext.handle (WebAppContext.java:417) [jetty-6.1.12.jar: 6.1.12] tại org.mortbay.jetty.handler.ContextHandlerCollection.handle (ContextHandlerCollection.java:230) [jetty-6.1.12.jar: 6.1.12]

    Từ trên, bạn có thể nhận ra ứng dụng đang sử dụng Struts phiên bản 1.2.9 và được triển khai trong cầu cảng phiên bản 6.1.12. Như vậy, ngăn xếp dấu vết sẽ nhanh chóng thông báo cho người đọc về các lớp học được điều chỉnh trong ngoại lệ nhưng cũng là gói và các phiên bản gói mà chúng thuộc về. Khi nào khách hàng gửi cho bạn một chồng theo dõi, với tư cách là nhà phát triển, bạn sẽ không còn cần phải yêu cầu họ gửi cho bạn thông tin về các phiên bản của các gói mà họ đang sử dụng. Các thông tin sẽ là một phần của ngăn xếp dấu vết. Xem chuyển đổi "% xThrowable" từ để biết chi tiết.

    Tính năng này có thể khá hữu ích đối với điểm mà một số người dùng nhầm lẫn xem xét nó một tính năng của IDE của họ.

  • Tự động xóa lưu trữ nhật ký cũ

    Bằng cách đặt thuộc tính maxHistory của TimeBasedRollingPolicy hoặc SizeAndTimeBasedFNATP, bạn có thể kiểm soát số lượng tối đa các tệp đã lưu trữ. Nếu bạn lăn các cuộc gọi chính sách cho rollover hàng tháng và bạn muốn giữ giá trị một năm nhật ký, chỉ cần đặt maxHistory tài sản đến 12. Tệp nhật ký đã lưu trữ hơn 12 tháng sẽ tự động bị xóa.

Có thể có một thiên vị ở đó, nhưng cùng một anh chàng đã viết cả hai khuôn khổ và nếu anh ta đang nói sử dụng Logback trên Log4j anh ta có thể đáng nghe.


20
2018-05-18 12:27



Lưu ý rằng tác giả có lý do cá nhân để muốn mọi người chuyển đổi, vì vậy danh sách không hoàn toàn không thiên vị. - Thorbjørn Ravn Andersen
@ ThorbjørnRavnAndersen Lý do cá nhân là gì? Nó là một dự án nguồn mở. - Kshitiz Sharma
Đó là một câu chuyện dài. Tôi đề nghị bạn mở một câu hỏi mới nếu bạn thực sự muốn biết. - Thorbjørn Ravn Andersen


Tôi sẽ sử dụng slf4j để đăng nhập vào tất cả các trường hợp. Điều này cho phép bạn chọn phụ trợ ghi nhật ký thực tế nào bạn muốn sử dụng, vào thời gian triển khai thay vì thời gian mã.

Điều này đã được chứng minh là rất có giá trị đối với tôi. Nó cho phép tôi sử dụng log4j trong JVM cũ, và logback trong 1,5+ JVM, và cũng java.util.logging nếu cần thiết.


10
2018-01-20 12:47





Ghi lại nhiều nhận biết về Java EE hơn:
nói chung (từ mã đến tài liệu hướng dẫn) nó lưu ý các vùng chứa - cách nhiều ứng dụng cùng tồn tại, cách trình nạp lớp được triển khai vv Các ngữ cảnh cho trình ghi nhật ký, JNDI, cấu hình JMX bao gồm v.v.

từ nhà phát triển tiềm năng gần như giống nhau, Logback thêm Ghi nhật ký tham số (không cần sử dụng nếu (logger.isDebugEnabled ()) để tránh chi phí nối chuỗi)

Log4j - chỉ có cộng thêm khổng lồ là hỗ trợ JVM cũ, nhỏ (IMO) NDC (chỉ logback MDC), một số phần mở rộng. Ví dụ tôi đã viết phần mở rộng cho configureAndWatch cho Log4j, không có điều gì cho Logback


2
2018-04-22 17:02





log4j ban đầu và logback được thiết kế và thực hiện bởi cùng một người.

một số công cụ nguồn mở đã sử dụng SLF4J. Tôi không thấy bất kỳ sự thiếu sót đáng kể nào trong công cụ này. Vì vậy, trừ khi bạn có rất nhiều phần mở rộng để log4j trong codebase của bạn, tôi sẽ đi trước với logback.


1
2017-10-07 15:08





Tôi nghĩ rằng quyết định của bạn nên đi xuống cùng một quyết định nếu bạn quyết định sử dụng log4j hoặc Jakarta Commons Logging - bạn có đang phát triển một thư viện sẽ được đưa vào các ứng dụng khác không? Nếu vậy, sau đó nó không có vẻ công bằng để buộc người dùng thư viện của bạn cũng sử dụng thư viện đăng nhập của bạn lựa chọn.

Nếu câu trả lời là không, tôi sẽ chỉ đi với những gì là đơn giản để thêm và những gì bạn cảm thấy thoải mái hơn. Âm thanh như logback chỉ là có thể mở rộng và đáng tin cậy như log4j, vì vậy nếu bạn cảm thấy thoải mái khi sử dụng nó, hãy tiếp tục.


1
2017-10-07 15:50



Nếu bạn đang phát triển một thư viện, hãy sử dụng slf4j, vì nó có thể sử dụng bất kỳ phần phụ trợ nào mà không có nhược điểm của việc ghi nhật ký. Nếu bạn đang viết một ứng dụng sử dụng slf4j để bạn có thể sử dụng logback. - David Roussel


Tôi không quen thuộc với SLF4J, và tôi đã chỉ xem xét một chút về logback, nhưng có hai điều cần lưu ý.

Trước tiên, tại sao bạn không bao gồm một công cụ từ kiểm tra? Tôi nghĩ rằng điều quan trọng là phải giữ một tâm trí cởi mở và kiểm tra tất cả các khả năng để lựa chọn tốt nhất.

Thứ hai, tôi nghĩ rằng trong một số dự án, một công cụ tốt hơn một công cụ khác, và điều ngược lại có thể đúng trong một dự án khác. Tôi không nghĩ rằng một công cụ luôn tốt hơn một công cụ khác. Có, sau khi tất cả, không có viên đạn bạc.

Để trả lời câu hỏi của bạn - Có và không. Nó phụ thuộc vào dự án, và làm thế nào quen thuộc đội là với một công cụ. Tôi sẽ không nói "không sử dụng log4j" nếu toàn bộ nhóm rất thoải mái với nó, nó đáp ứng mọi nhu cầu, và logback không cung cấp bất cứ thứ gì mà chúng ta cần để hoàn thành nhiệm vụ.


-3
2017-10-07 14:58



SLF4J là một mặt tiền mà logback sử dụng. Tôi không để lại gì bên cạnh. Đó là 'tính năng'.
Ah. Cảm ơn bạn đã làm rõ, nhưng các điểm chính của câu trả lời của tôi vẫn áp dụng. - Thomas Owens
Wow! Nói về mơ hồ ... thay thế log4j và logback trong câu trả lời này cho bất kỳ hai thư viện, ngôn ngữ, IDE, vv và xem kết quả! ngạc nhiên! : D - Pablo Fernandez