在使用Java编程的过程中,我们常常会遇到各种各样的错误和异常。其中一个常见的问题是在依赖库中出现了相互冲突的情况,比如在使用日志框架时可能会出现java.lang.IllegalStateException: Detected both log4j-over-slf4j.jar AND bound slf4j-log4j12.jar on the class path的异常。这个异常是由于在项目的依赖中同时存在了log4j-over-slf4j.jar和slf4j-log4j12.jar这两个不兼容的库引起的。
假设,在 JavaMavenService2 模块中,log4j 的版本是 1.2.7,在 JavaMavenService1 模块中,它虽然继承于 JavaMavenService2 模块,但是它排除了在 JavaMavenService2 模块中继承 1.2.7 的版本,自己引入了 1.2.9 的 log4j 版本。
上面的这些问题,基本都是由于多套日志框架共存或配置错误导致的。那么为什么会出现共存或者冲突呢? 一般是以下几种原因:
上篇文章 记一次log4j不打印日志的踩坑记 介绍了遇到的log4j踩坑经历和解决方法,这篇文章我们重点来学习和了解下有关Java中日志组件的内容,在这之前,其实在我的头脑里,并没有形成系统的日志框架知识,原因其实是一直没有重视过这块,之前都是各种拷贝改改能跑就行,并不理解相关的架构和原理,这次趁着这个机会正好来系统了解一下,除了要系统的理解日志框架大多数知识外,我们还要学习一个非常关键的知识,就是关于Java默认的类加载器加载jar包的顺序问题,不夸张的说,只有理解了这个,才能搞明白jar冲突问题发生的本质。
你是否遇到过配置了日志,但打印不出来的情况?你是否遇到过配置了 logback,启动时却提示 log4j 错误的情况?像下面这样:
我就想验证一下上手难度到底有多低,于是我翻了很多文章,都是大同小异,说出漏洞了,很牛逼,赶紧修吧,晚了就玩完啦。然后配上一个唤起了计算器的截图,就结束了,也没有人告诉我到底怎么玩啊。
2021 年 12 月 9 日,该项目被曝存在 严重安全漏洞 ,攻击者只需要向目标机传入一段特殊代码,就能触发漏洞,自由地在远程执行任意代码来控制目标机器!
引入第三方库'org.raml:raml-parser:0.8.12',导致slf4j依赖冲突。
前几天一个跑有java应用的生产集群(200多台物理机)升级了一个版本,重启后发现约有50台机器日志不能正常输出,但其程序却能正常的运行,在生产环境中,日志是非常重要的一个监控手段,如果没有日志输出,无疑是非常危险的。
参考: https://docs.gradle.org/current/userguide/userguide_single.html#sec:listing_dependencies
implementation 'org.apache.logging.log4j:log4j:2.17.2' 上面是简写法,完整版写法如下: implementation group: 'org.apache.logging.log4j', name: 'log4j', version: '2.17.2'
问题描述 Missing artifact com.sun.jdmk:jmxtools:jar:1.2.1 Missing artifact com.sun.jmx:jmxri:jar:1.2.1 报错原因 项目引入依赖包含的log4j依赖和jms.jar、jmxtools.jar包冲突 解决办法 手动引入log4j依赖,并排除jms.jar和jmxtools.jar包 log4j log4j 1.2.17
引入org.apache.activemq:activemq-all依赖与org.slf4j:log4j-over-slf4j导致运行时冲突产生“Detected both log4j-over-slf4j.jar AND slf4j-log4j12.jar on the class path, preempting StackOverflow”异常,这是由于org.apache.activemq引入的slf4j-log4j12.jar与pom文件中的 log4j-over-slf4j.jar循环调用导致的异常,从名字上可以看出slf4j-log4j12是将slf4j的日志桥接到log4j12上, log4j-over-slf4j则是将log4j的日志桥接到slf4j上,因而产生了循环调用。
今早,DD注意到JetBrains在官方博客发文宣布要将log4j从IntelliJ平台移除了,该变化将在2022.1版本发布。
解决jar包冲突的简单办法– 在使用log4j.properties时,pom中导入的一些jar会产生log4j类的冲突报错,以下是一个简单的pom配置:
如果对于commons-loging、log4j、slf4j、LogBack等都已经非常清楚了,可以忽略本文。几次解决日志冲突问题时对这几个概念的简单总结,希望对这块基础没有理解透的同学能有所帮助,当然如果对这块有更深刻理解的同学,也贡献出自己的知识和见解。
Log4j漏洞是很严重的问题。这个零日漏洞影响Log4j库,让攻击者可以在依赖Log4j写入日志消息的系统上执行任意代码。
三歪最近每天都很忙,一直在整合系统,期间遇到了不少奇奇怪怪的问题。今天想分享一个Bug,如果后面你遇到了希望你能想起这篇文章。
在Log4j中java的日志级别具有5种正常级别,优先级从低到高主要为:DEBUG、INFO、WARN、ERROR、FATAL。还有两个可用的特别的日志记录级别,ALL,最低的日志级别,用于打开所有的日志记录,OFF:最高的日志级别,用户关闭所有的日志记录。Log4j建议只使用四个级别,优先级从高到低分别是 ERROR、WARN、INFO、DEBUG。 通过定义日志的级别,可以控制到应用程序中相应级别的日志信息的开关。比如定义了INFO级别,则应用程序中所有DEBUG级别的日志信息将不被打印出来,也是说大于等于设置的日志级别的日志才输出
Caused by: java.lang.IllegalArgumentException: LoggerFactory is not a Logback LoggerContext but Logback is on the classpath. Either remove Logback or the competing implementation (class org.apache.logging.slf4j.Log4jLoggerFactory loaded from file:/C:/Users/yhu/.m2/repository/org/apache/logging/log4j/log4j-slf4j-impl/2.8.2/log4j-slf4j-impl-2.8.2.jar). If you are using WebLogic you will need to add 'org.slf4j' to prefer-application-packages in WEB-INF/weblogic.xml: org.apache.logging.slf4j.Log4jLoggerFactory
如果你使用的是 Log4j 1.x、Logback 或者其他日志框架,这次就可以幸免于难。
之前都是使用SparkStreaming开发,最近打算学习一下Flink,就从官网下载了Flink 1.11,打算搞一个客户端,将程序提交在yarn上。因为Flink从1.7之后就不再提供Hadoop的依赖,所以很多依赖就要自己下载,于是各种ClassNotFoundException,其中以log*.class为首的格外猖狂,可能是因为flink和Hadoop的日志实现有点区别,就一直哐哐哐报错,slf4j、log4j、logback各种jar包十几个,百度好久也没搞清各个jar有什么区别,用在何处,就打算自己总结一下。
公司用的springboot,随着项目的不断庞大,经常会出现一些稀奇古怪的问题,其实多半是配置文件有问题,但是没有错误提示信息,就很是难受,无从下手,如果这篇文章有帮助到你的话,希望留下个足迹或者点个赞再走嘛,以下列举一些自己遇到的常见的问题处理办法:
SparkStreaming用久了,打算学习一下Flink,就从官网下载了Flink 1.11,打算搞一个客户端,将程序提交在yarn上。因为Flink从1.7之后就不再提供Hadoop的依赖,所以很多依赖就要自己下载,于是各种ClassNotFoundException,其中以log*.class为首的格外猖狂,可能是因为flink和Hadoop的日志实现有点区别,就一直哐哐哐报错,slf4j、log4j、logback各种jar包十几个,百度好久也没搞清各个jar有什么区别,用在何处,就打算自己总结一下。
本文的目的是搞清楚Java中各种日志Log之间是怎么的关系,如何作用、依赖,好让我们平时在工作中如果遇到“日志打不出”或者“日志jar包冲突”等之类的问题知道该如何入手解决,以及在各种场景下如何调整项目中的各个框架的日志输出,使得输出统一。
2021年11月24日,阿里云安全团队向Apache官方报告了Apache Log4j2远程代码执行漏洞。
那么多组件对MQ、Redis、鉴权等的封装着,每个组件都需要打印日志,组件日志与业务日志混合在一起,干扰业务排查问题。组件日志主要是为了排查问题,组件打印的日志也没有必要被收集到SLS、ELK上等。
日志是我们工作中经常提及的内容,但是我们很少关心他的实现原理,基本的都是直接使用别人配置好的东西,那么这么多的日志框架,他是如何做到日志的统一打印呢,spring是如何实现的,springboot是如何实现,又有哪些日志框架呢,具体是如何实现以及选择的呢
今天把项目的log4j的依赖改成了log4j2的依赖后,发现使用Maven打包时报错如下:
在一家IT企业中,项目经理虎大力(龙套) 正在指挥 程序员鹿小明(精英龙套)开发一个大型的增删改查项目。为了开发这个项目。项目组仅有的程序员鹿小明每天工作996
使用java开发项目时,log日志一般都是应用程序必不可少的一部分,大部分情况下我们的log文件都是普通的文本信息,通过level来标记不同级别的日志。 日志的目的,主要还是为了出现问题时有追踪的途径,方便从里面查出原因,在数据量小的时候通过linux上的各种shell命令如awk,grep就能快速查询或者做一些简单的统计,当数据量的时候,而且程序本身还是分布式的时候,这种方式就有点费劲。比如你有10台机器,你需要登录每台查询,是非常繁琐的,而且数据量大的时候linux命令可能效率非常低。所以这个时候我们就
Logback 算是JAVA 里一个老牌的日志框架,从06年开始第一个版本,迭代至今也十几年了。不过logback最近一个稳定版本还停留在 2017 年,好几年都没有更新;logback的兄弟 slf4j 最近一个稳定版也是2017年,有点凉凉的意思。
据媒体报道,近期工信部网络安全管理局通报称,阿里云计算有限公司(以下称:阿里云)在 11 月 24 日发现了 Log4j2 安全漏洞隐患后率先向 Apache 基金会披露了该漏洞,未及时向中国工信部通报相关信息,未有效支撑工信部开展网络安全威胁和漏洞管理。经研究,工信部网络安全管理局决定暂停阿里云作为上述合作单位 6 个月。暂停期满后,根据阿里云整改情况,研究恢复其上述合作单位。
版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
由于MyBatis-Plus是在MyBatis的基础上只做增强不做改变,因此其与Spring的整合非常简单。只需把MyBatis的依赖换成MyBatis的依赖,再把sqlSessionFactory换成MyBatis-Plus的即可。下面让我们在Spring中快速集成Mybatis-Plus的具体操作:
Apache Log4j 是一款开源的 Java 日志框架,被广泛地应用在中间件、开发框架与 Web 应用中,用来记录日志信息。
现在的公司由于绝大部分项目都采用分布式架构,很早就采用ELK了,只不过最近因为额外的工作需要,仔细的研究了分布式系统中,怎么样的日志规范和架构才是合理和能够有效提高问题排查效率的。
win10安装Hadoop3.0.0:https://blog.csdn.net/qq262593421/article/details/105927625
在进行 Java 开发时,通常我们会选择 Slf4j 作为日志门面,但日志实现却不尽相同。如果系统运行中同时存在多个日志实现,就会出现类似下图的 Warning。
由于新发现的 DoS(拒绝服务)攻击导致 StackOverflowError 终止进程,log4j 版本 2.17.0 刚刚发布。
近期一个 Apache Log4j 远程代码执行漏洞细节被公开,攻击者利用漏洞可以远程执行代码。经过分析,该组件存在Java JNDI注入漏洞,当程序将用户输入的数据进行日志,即可触发此漏洞,成功利用此漏洞可以在目标服务器上执行任意代码。
在实际的业务场景中,我们经常会遇到如下异常提示:“Process finished with exit code x “。通常表现为:创建好的 Spring Boot 微服务项目,启动时无异常,却立马自动退出,无论基于何种方式启动均无效且控制台无任何有效信息。此类异常的处理往往较为繁琐,尤其是在无任何 Log 、无明显关键字输出的场景下,尤为让人摸不着头脑。
2021年12月10日凌晨前,网上曝出了 log4j 的核弹级漏洞,这种漏洞超级高危,操作简单,利用方便,适用范围广,可以直接任意代码执行,接管你的服务器。
随后就是RPC架构,之前的垂直应用架构其实可以说是在一个进程内的通讯,而RPC就是一种进步,RPC是进程之间的通讯,远程过程调用就是这么来的。
领取专属 10元无门槛券
手把手带您无忧上云