Specifically, I use spring only for configuring my project through ApplicationContext. In my spring xml I load some bean properties through PropertyPlaceholderConfigurer. Whenever in the dependencies I swap commons-logging-x.x with jcl-slf4j.jar the loading of the context fails with ClassNotFoundExceptions on the placeholder substitutions. Example:
In my spring.xml there is:
<bean id="testbean" class="${testbean.implementingClass}"/>
where testbean.implementingClass is defined in spring.properties:
testbean.implementingClass=my.implementation.TestClass
If I run the project using commons-logging jar all works perfectly. If I change it to jcl-slf4j then I get ClassNotFoundException that the class [${testbean.implementingClass}] was not found, i.e. it does not do the placeholder substituion. Has anyone observed this?
EDIT: My problem doesnt have to do with the jars because:
From http://www.slf4j.org/legacy.html :
Our JCL over SLF4J implementation will allow you to migrate to SLF4J gradually, especially if some of the libraries your software depends on continue to use JCL for the foreseeable future. You can immediately enjoy the benefits of SLF4J's reliability and preserve backward compatibility at the same time. Just replace commons-logging.jar with jcl-over-slf4j.jar. Subsequently, the selection of the underlying logging framework will be done by SLF4J instead of JCL but without the class loader headaches plaguing JCL. The underlying logging framework can be any of the frameworks supported by SLF4J. Often times, replacing commons-logging.jar with jcl-over-slf4j.jar will immediately and permanently solve class loader issues related to commons logging.
When you use jcl-slf4j, you have to make sure you have excluded all commons-logging dependencies from your project. Make sure there is no commons-logging jar anywhere in the classpath.
Related
I'm trying to upgrade the logback-classic library from version 1.2.3 to 1.2.8. The patch notes say that all DB related code has been removed, so the main DBAppender class no longer exists in the new version https://logback.qos.ch/news.html. Has anyone found some kind of upgrade guide or know of a workaround solution?
Please see https://logback.qos.ch/news.html.
2022-04-20, Release of logback.db version 1.2.11.1
As of logback version 1.2.8 DBAppender no longer ships with logback.
However, DBAppender for logback-classic is available under the
following Maven coordinates:
ch.qos.logback.db:logback-classic-db:1.2.11.1
and for logback-access under
ch.qos.logback.db:logback-access-db:1.2.11.1
Both of these artifacts require
ch.qos.logback.db:logback-core-db:1.2.11.1 which will be pulled in
automatically by Maven's transitivity rules.
I was wondering the same thing after upgrading spring to the 2.6.3 which pulls in logback version 1.2.8+ through spring-boot-starter-logging dependency.
According to logback's site: https://logback.qos.ch/news.html in version 1.2.8: "2) we have removed all database (JDBC) related code in the project with no replacement."
My logback xml configuration file has a custom DB Appender in it and the application failed to build with the following error:
Could not create an Appender of type [ch.qos.logback.classic.db.DBAppender]. ch.qos.logback.core.util.DynamicClassLoadingException: Failed to instantiate type ch.qos.logback.classic.db.DBAppender
After doing some research, I found a ticket in the logback backlog with a request to document how to proceed. https://jira.qos.ch/browse/LOGBACK-1609
Apparently the DB appender was removed due to a vulnerability.
According to the developer: "The source code is still there. Until this issue is resolved, you can fetch the code from tag 1.2.8 and rebuild. The DBAppender issue is a bit more complex than what people think. As you can imagine, we have a lot on my plate these days but we'll get to it eventually."
So it sounds like the code was removed while they work on a fix and support will be added back eventually. I wouldn't count on a quick fix though.
As a workaround I have pinned the logback version in my projects gradle file so that I can use the latest version of spring along with the latest version of logback that still supports the DB appender class.
Here is the syntax I used:
ext['logback.version'] = '1.2.7'
After the log4j zero-day vulnerability, we started to look if there are any more artifacts that are using either slf4J or lower versions of log4j.
Checking the mvn dependency tree we have figured that spring-security-saml2-core is using slf4j, and we tried to exclude that from the artifact. However, we are receiving the below runtime exception :
-java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
at org.opensaml.DefaultBootstrap.getLogger(DefaultBootstrap.java:246)
at org.opensaml.DefaultBootstrap.initializeXMLSecurity(DefaultBootstrap.java:189)
at
If you are referring to the CVE-2021-44228 vulnerability (aka. Log4Shell) then Slf4J is not the vulnerable library so you don't have to exclude it. Only Log4j-core is affected by this particular vulnerability for versions between 2 until before 2.15.0
See https://nvd.nist.gov/vuln/detail/CVE-2021-44228
There are other known vulnerabilities at the moment (and many that are still probably waiting to be discovered), as #eray-tufay points out. The example he gives is https://cve.report/CVE-2021-4104:
Note this issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default
So, to be protected against current and future vulnerabilities:
include in your build pipeline an automatic check against new vulnerabilities, like https://owasp.org/www-project-dependency-check/
constantly upgrade your dependendencies to use the latest versions
I needed EasyStream available at sourceforge site and added the dependency in my application. My SLF4J-API used to work just fine but now it has a disagreement. The way am using code snippet is :
private final Map<?, ?> parentContext;
MDC.setContextMap(parentContext);
For some reason i am getting a compile time error now with the message :
The method setContextMap(Map<String,String>) in the type MDC is not applicable for the argument Map<Capture#5of-?,Capture#6of-?>
kindly suggest how i can get ride of this error.
My guess is that EasyStream depends on a different version of SLF4J than the one you're using. Having more than one of the same version of a dependency on one's classpath leads to all sorts of weird issues. Depending on what dependency management system you're using, you probably need to tell it to exclude the child slf4j-api dependency or perhaps override it. For example, in Maven, I'd use the <dependencyManagement> system to force all dependencies to use the same version of slf4j-api. Perhaps if you edit your question with more details about the dependency management system you're using you can get a more specific answer, and details on how to check and prevent such problems in the future.
Can anyone tell me the difference between slf4j-log4j and log4j-over-slf4j? Which is more standard to use in a Java web application? I currently have both on the classpath and that is causing a runtime exception as the web server is trying to prevent a StackOverFlowException from happening.
Exception:
java.lang.IllegalStateException:
Detected both log4j-over-slf4j.jar AND slf4j-log4j12.jar on the class path
slf4j-log4j is using log4j as an implementation of slf4j.
log4j-over-slf4j causes calls to the log4j API to be 'routed' to slf4j.
You cannot use both of these JAR's at the same time.
Both are valid libraries to use and are equally 'standard', it depends on the project.
In general, if your project is using log4j already and you don't have the ability to update all of your log4j Loggers to slf4j Loggers; log4j-over-slf4j is a quick fix to be able to start using slf4j immediately.
However, if your project is new or does not have an existing logging mechanism and you choose to use slf4j, slf4j-log4j would be the way to go as it is just specifying slf4j should be bound to log4j.
That being said, I agree with c12's comment. Stop using log4j and instead use slf4j and logback.
in my project , org.slf4j.impl.Log4jLoggerFactory is in
activemq-all-5.7.0.jar
not in slf4j-log4j12.jar
the exception message mislead me
I'm being driven out of my mind by the following exception:
java.lang.IllegalArgumentException:
com.sun.xml.messaging.saaj.soap.LocalStrings != com.sun.xml.internal.messaging.saaj.soap.LocalStrings
at java.util.logging.Logger.getLogger(Logger.java:357)
at com.sun.xml.internal.messaging.saaj.soap.SAAJMetaFactoryImpl.<clinit>(SAAJMetaFactoryImpl.java:41)
It's occurring when I try to deploy a WAB (web application OSGi bundle) to Glassfish (3.1.1).
I'm trying to use an up-to-date version of SAAJ (com.sun.xml.messaging.saaj...) rather than the old JDK one (which is the com.sun.xml.internal.saaj... one), by putting the string com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl in the file META-INF/services/javax.xml.soap.MessageFactory.
It appears there is some logging going on before the OSGi classloading kicks in, and therefore the 'wrong' ResourceBundle is being returned during initialization of the static log field of com.sun.xml.messaging.saaj.soap.MessageFactoryImpl (SAAJ's implementation of javax.xml.soap.MessageFactory).
Anyone seen this / any workarounds on offer?
Never got to the bottom of this, but manifest voodoo eventually made it go away (with all of the javax.xml.ws / javax.ws.rs packages in Import-Package rather than on the bundle classpath WEB-INF/lib).
It was also possible to work around it by using
-Djavax.xml.soap.MessageFactory=com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl
on Glassfish startup, though obviously this forces that implementation on all users of MessageFactory.
See: JDK-6741342 : Logger.getLogger() throws java.lang.IllegalArgumentException on saaj classes.
Instead, it's related to the introduction of saaj into JDK 6.....and the workaround involved re-ordering jars.