下面以实际项目中日志为例，从简单到复杂，讲解log4j2日志框架配置文件的使用。
2.1 简单版日志配置，输出控制台
配置文件如下：
2.2 简单版日志配置，控制台、文件双输出
配置文件如下
2.3 日志的级别“透传”——additivity属性
注意一个问题：对比配置文件修改前后的控制台的输出可以看到，配置修改前控制台的输出日志级别为error，意味着只有erro级别以上的日志才会打印，事实也确实是如此，如配置：
有了logger之后，日志级别是由logger的级别控制？
如上，发现一个问题：日志文件中这个时候确实打印的是warn以上级别的日志，控制台也确实是info级别以上的日志，但是，日志文件只打印与业务相关的日志，控制台这个时候打印的是与业务无关的系统和数据库操作日志，这是为什么？
Logger的appender根据参数additivity决定是否要叠加root的appender，logger的级别是其自身定义的级别，和root的级别没什么关系。判断一个类的日志输出情况，首先找到这个类所在的logger（没有特别定义则默认为root），然后根据以上规则判断出这个logger的appender和level。然后既可以知道这个类的哪些日志会被输出到哪些地方了。注意：任何一个类只会和一个logger对应，要么是定义的logger，要么是root，判断的关键在于找到这个logger，然后判断这个logger的appender和level。 因此对于上述现象的解释是：业务相关的类都在包com.onlyisssilence.muya下，它们的日志输出到了文件中，而数据库以及其他的框架类日志使用的是默认的logger——root，而root的appender为控制台，所以均会打印到控制台上。
2.4 Logger配置中root和logger的区别
logger存在父子级别的概念，其中root是根级别的，当待打印的文件没有设置任何所属的logger时，会默认使用root级别的，如上例中的sql的日志、系统日志(它们均没有设置其logger)，对于这种层级的包中的类，如果重复设置了其logger那么以离该文件最近的节点设置的logger为主。
2.5 Log4j2中特殊appender之JAP
项目中有的时候需要存储一些操作日志，比如用户登录登出，查询信息，删除信息等，这些操作对于前端可能就是一个接口的调用，对于后端而言就是controller层中的一个方法的调用，这种业务场景的需求可以考虑使用log4j2+切面技术的相结合来实现，总的思路是，每个接口添加日志操作的自定义注解；注解的处理类中调用log4j2的日志工具打印日志；打印的日志使用JAP这种属性的appender，这种appender再通过定义日志操作类实现自动的入库。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容，请联系我们，一经查实，本站将立刻删除。
如需转载请保留出处：https://51itzy.com/kjqy/188291.html