Log4j单体封装器的好处?[英] Benefits of Log4j singleton wrapper?

本文是小编为大家收集整理的关于Log4j单体封装器的好处?的处理/解决方法,可以参考本文帮助大家快速定位并解决问题,中文翻译不准确的可切换到English标签页查看源文。

问题描述

我最近继承了一些Java代码,需要将其集成到我正在从事的项目中.我的项目是处理和转换XML消息的服务代理.查看新代码时,我发现了以下记录类:

import org.apache.log4j.BasicConfigurator;
import org.apache.log4j.Level;
import org.apache.log4j.Logger;

public class MyLogger {

    private static MyLogger instance = null;
    protected final static Logger log = Logger.getLogger(MyLogger.class);

    private MyLogger() {
        super();
    }

    public static MyLogger getInstance(){
        if(instance  == null){
            instance  = new MyLogger();
            BasicConfigurator.configure();
            log.setLevel(Level.ALL);
        }
        return instance;
    }

    public void info(String myclass, String msg) {
        log.info("[" + myclass + "] " + msg);

    }

    public void error(String myclass, String msg, Exception ce) {               
        log.error("[" + myclass + "] " + msg, ce);      
    }

    public void warning(String myclass, String msg) {
        log.warn("[" + myclass + "] " + msg);
    }    
}

此类基本上将log4j与(另一个)singleton包装.我需要集成的所有登录时间都像这样:

public class MyClass {
   private final static MyLogger log = MyLogger.getInstance();
   private final static String myclass= MyClass.class.getName();

   ...

   log.info(myclass, "Information message...");   
}

我认为使用额外的类进行伐木没有任何明显的好处,因此我正在考虑重构此代码以删除mylogger类并以以下方式登录:

import org.apache.log4j.Logger;

public class MyClass {
   private static Logger log = Logger.getLogger(MyClass.class);

   ...

   log.info("Information Message...");     
}

这将使日志记录机制在整个项目中保持一致.在这样做之前,我想知道将log4j与我可能缺少的单身班包装有任何好处.谢谢!

编辑:感谢大家的有用答案 - 我从每个人那里获取了几个新见解.接受内森·休斯(Nathan Hughes)的回答是指出失去的功能,使班级完好无损 - 我一直以为独自离开辛格尔顿的最大缺点只是代码膨胀.我会垃圾班.

推荐答案

摆脱它.使用这种怪异意味着将使用相同的记录器(mylogger)和方法列出所有记录的记录(这就是为什么对方法的参数包括被记录的事物类别的原因).这意味着您不仅必须在每个记录器调用中添加任何类,方法和行号信息,而且不能像使用典型的log4j方法一样对不同软件包的日志级别进行任何过滤,并将其用作记录器的典型log4j方法.

这东西是一块垃圾,没有它,您会更好.

其他推荐答案

我唯一能看到的好处是,可以轻松地将Log4J实现与另一个记录实现交换,或者让日志记录进行更自定义的事情,例如log到您自己的数据库之一.

也就是说,我仍然会重构直接使用log4j的代码.或者,就我而言,更有可能使用 slf4j .

其他推荐答案

您的继承代码所做的一件事是使事物变得非线程安全.由于getInstance()中没有锁定,您可能会分发多个实例并打破代码的单例.

您还失去了每个类设置日志记录级别的能力,具体取决于您的工作.

本文地址:https://www.itbaoku.cn/post/1574985.html

问题描述

I have recently inherited some Java code and need to integrate it into a project that I am working on. My project is a service agent that processes and transforms XML messages. While looking through the new code, I discovered the following logging class:

import org.apache.log4j.BasicConfigurator;
import org.apache.log4j.Level;
import org.apache.log4j.Logger;

public class MyLogger {

    private static MyLogger instance = null;
    protected final static Logger log = Logger.getLogger(MyLogger.class);

    private MyLogger() {
        super();
    }

    public static MyLogger getInstance(){
        if(instance  == null){
            instance  = new MyLogger();
            BasicConfigurator.configure();
            log.setLevel(Level.ALL);
        }
        return instance;
    }

    public void info(String myclass, String msg) {
        log.info("[" + myclass + "] " + msg);

    }

    public void error(String myclass, String msg, Exception ce) {               
        log.error("[" + myclass + "] " + msg, ce);      
    }

    public void warning(String myclass, String msg) {
        log.warn("[" + myclass + "] " + msg);
    }    
}

This class basically wraps log4j with (another) singleton. All of the logging in the classes that I need to integrate look something like this:

public class MyClass {
   private final static MyLogger log = MyLogger.getInstance();
   private final static String myclass= MyClass.class.getName();

   ...

   log.info(myclass, "Information message...");   
}

I do not see any obvious benefit to using an extra class for logging, thus I am considering refactoring this code to remove the MyLogger class and log in the following fashion:

import org.apache.log4j.Logger;

public class MyClass {
   private static Logger log = Logger.getLogger(MyClass.class);

   ...

   log.info("Information Message...");     
}

This would make the logging mechanism consistent across the project. Before I do this, I would like to know if there are any benefits to wrapping Log4j with a singleton class that I may be missing. Thanks!

EDIT: Thanks everyone for the helpful answers - I pickup up several new insights from each. Accepted Nathan Hughes' answer for pointing out lost functionality by leaving the class intact - I had been assuming that the biggest downside to leaving the singleton alone was simply code bloat. I will trash the class.

推荐答案

Get rid of it. Using this monstrosity means all logging that goes through it will be listed with the same logger (MyLogger) and method (which is why the arguments to its methods include the class of the thing being logged). That means not only do you have to add any class, method, and line number information to each logger call, but you can't do any filtering on log levels for different packages the way you could using the typical log4j approach with classes as loggers.

This thing is a piece of junk and you are better off without it.

其他推荐答案

The only benefit that I could see is that it would be easy to swap out the log4j implementation with another logging implementation, or get the logging to do something much more customised such as log to one of your own databases.

That said, I would still refactor the code to use log4j directly. Or, more likely in my case, to use SLF4J.

其他推荐答案

One thing your inherited code does that log4j does is make thing non-thread safe. Since there is no locking in getInstance() you can potentially hand out more than one instance and break the singleton intentions of the code.

You also lose the ability to set logging levels for each class depending on what you are doing.