We use ivy to manage a multi project java application, and recently this error started showing up when we do builds. What's causing this?
This was fixed by adding the following line to the end of the dependencies section in ivy.xml:
<dependencies>
<exclude module="log4j-over-slf4j" />
</dependencies>
Why was it an issue?
Looks like the log4j bridge for sjf4j has an incomplete implementation
This url explains it in more detail.
It looks like the log4j bridge does not implement the full interface for log4j . If you are still using direct log4j calls, you will need both the slf4j bridge jar and the log4j jar
In your case it looks like you excluded the bridge jar, so all slf4j calls go directly to log4j instead of the bridge.
If your code invokes log4j through the xml file , this will work. However if your code programatically invokes log4j initialization this bridge is not going to work
I know this is a very old question but I wanted to share what worked out fine for me. If you have different artifacts of slf4j-log4j* for two projects that are interdependent on each other, for example spring data jpa and spring MVC, this happens. Keep it consistent or even better have a parent pom. In my case I had slf4j-log4j12 on my spring data jpa project and slf4j-log4j13 on my spring MVC one.
Comment this dependency from the pom.xml
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j13</artifactId>
<version>
</dependency>
And add (or keep) the following one:
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.12</version>
</dependency>
Wherever you see a compile time error regarding Log4j, add the following import:
import org.apache.log4j.Logger;
Related
Is there OWSAP ESAPI logging supported in logback for spring boot application? I did a lot of research but could not find much on this. I found out that org.owasp.esapi now supports this after this PR . But this means that I will have to do away with logback. Is there a way that I can implement OWSAP ESAPI logging using logback? We are using slf4j logger that logback provides.
I looked at logback's maven page and there has not been any major release since 2017. So I am guessing that logback does not supports OWSAP ESAPI logging. Please correct me if I am wrong. If that is the case are there any alternatives I can use?
Also according to this spring-boot does not support slf4j 1.8 and above.If that is the case are there any alternatives I can use?
I found out that org.owasp.esap actually delegates the actual logging to our existing infrastructure. So all I had to do is add the correct package and it automatically takes care of the logging via whatever config I have in logback.
Add the esapi dependency to pom.xml
<dependency>
<groupId>org.owasp.esapi</groupId>
<artifactId>esapi</artifactId>
<version>2.2.0.0</version>
</dependency>
Add the ESAPI.properties file to src/main/resources/. This file contains the config properties for the ESAPI logger. Since I was using Slf4j looger, I set ESAPI.Logger=org.owasp.esapi.logging.slf4j.Slf4JLogFactory in the file.
Now we can use the ESAPI logger for logging which internally will use the Slf4j logger. As the function definition of the ESAPI logger has an extra argument I had to update all the logger functions accordingly.
For me, the solution was:
Add the next code to my pom.xml
<dependency>
<groupId>org.owasp.esapi</groupId>
<artifactId>esapi</artifactId>
<version>2.2.0.0</version>
</dependency>
Add ESAPI.properties and validation.properties files to src/main/resources/, I took them from this post, of Vaquar Khan answer.
Update the property ESAPI.Logger in the file ESAPI.properties with this code of AshwinSreekumar:
ESAPI.Logger=org.owasp.esapi.logging.slf4j.Slf4JLogFactory
I hope it will help you, because in my case, I had to do some extra steps to make it work.
I am using commons-logging which should bridge to Log4J2 in an OSGi environment and so have added the dependencies, export-package and import-package in the pom.xml as below but the logger does not get set to Log4J2 logger. No errors are shown but when debugged I found it being set to JDK14Logger.
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
<version>2.8.2</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.8.2</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-jcl</artifactId>
<version>2.8.2</version>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>2.8.2</version>
</dependency>
<Export-Package>
org.apache.logging.log4j.*,
org.apache.commons.logging.*
</Export-Package>
<Import-Package>
!org.apache.logging.log4j.*,
!org.apache.commons.logging.*,
*;resolution:=optional
</Import-Package>
[UPDATE]
From the log4j user mailing list I could figure out that due to the non-modular nature of ServiceLoader. I checked out a few usages of ServiceLoader in the OSGi environment to find implementations of interfaces but still couldn't get how this could be gotten to work.
I tried it using pax logging as well but the result is the same except for that the logger is now being set to JclLogger
As Christian said in the other answer, the best fit for logging in OSGI is the pax-logging bundle.
The Pax-logging is built over SLF4J and can be deployed with different possible implementations:
pax-logging-log4j2 (Log4J2)
pax-logging-logback (Logback)
Before we also used pax-logging-service which was using Log4J version 1 but it is not more recommended as the two other implementations works well.
I personally not tested Logback implementation in OSGI, but Log4j2 is working (with some limitations).
One of the good things with this solution is that you must not import any logging implementation on your bundles, the only things have to you do is:
declare slf4j-api as provided dependency (maven scope)
declare eventually the slf4j-simple as test scope in your maven
You don't need to tweak any of the maven-bundle-plugin options regarding logging of any of your bundles.
Here are the step how to do it in ServiceMix version 7.0.1; this release uses originally the pax-logging-services but the next step shows what need to be changed.
By installing the bundles in the startup.properties (immediately after boot time) you ensure that all libs are loaded in the beginning.
These two replace the older version of pax-logging-api and pax-logging-service replaced by pax-logging-log4j2:
mvn\:org.ops4j.pax.logging/pax-logging-api/1.11.13 = 8
mvn\:org.ops4j.pax.logging/pax-logging-log4j2/1.11.13 = 8
then in the file: org.ops4j.pax.logging.cfg you mentions just the line:
org.ops4j.pax.logging.log4j2.config.file=${karaf.etc}/log4j2.xml
and add your log4j2.xml file in the ${karaf.etc} folder (installation of servicemix/etc).
You have to copy the libs in the ${karaf.home}/system folder.
This is if you just need a standard log file.
Now come the limitations: if you need to generate your log as json document, I was only able to use the deprecated JSONLayout in the log4j2.xml.
For setting up JSONLayout you can follow my other answer.
In short:
Add the three Jackson dependencies in startup.properties:
mvn\:com.fasterxml.jackson.core/jackson-annotations/2.12.4 = 6
mvn\:com.fasterxml.jackson.core/jackson-core/2.12.4 = 6
mvn\:com.fasterxml.jackson.core/jackson-databind/2.12.4 = 6
and also the pax-logging-log4j2-extra (if you're using log4j2 implementation):
mvn\:org.ops4j.pax.logging/pax-logging-log4j2-extra/1.11.13 = 6
On my version I had to add the three following lines in overrides.properties:
mvn:com.fasterxml.jackson.core/jackson-core/2.12.4;range="[2,3)"
mvn:com.fasterxml.jackson.core/jackson-databind/2.12.4;range="[2,3)"
mvn:com.fasterxml.jackson.core/jackson-annotations/2.12.4;range="[2,3)"
I created a simple docker-compose with a servicemix 7.0.1 on github with the two ways of creating json logs (the new JsonTemplateLayout not working at the moment).
If the above is in your user bundle then this is not correct.
In your user bundle you should simply use the commons logging API and not change the settings of the maven bundle plugin.
It will then create Import-Package statements for the commons logging API but not for log4j which is what you want.
You then should install a suitable logging framework at runtime. I know that pax-logging can handle commons logging in a OSGi compatible way. Maybe plain log4j2 also works but I am not sure.
Please help,
For the past couple of days I have been trying to get Logback 1.1.3 to work with my Bukkit plugin. For reference my pom.xml includes these lines:
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-core</artifactId>
<version>1.1.3</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.1.3</version>
</dependency>
And the following jars are listed under "Maven Dependencies":
logback-core-1.1.3.jar
logback-classic-1.1.3,jar
slf4j-api-1.7.7.jar (which appeared out of nowhere)
The stacktrace that the server console produces can be found here (line 29 of MoneyDrops.java is:
private static final Logger LOGGER = LoggerFactory.getLogger("MoneyDropsLogger");).
I have also searched through stackoverflow but all the answers suggest that I need to provide an implementation that use the SLF4J api (such as log4j), however, it is to my understanding that logback natively implements the api and that I do not need another jar file.
Any help would be greatly appreciated.
There's a dependency in the pom of logback-classic to slf4j which Maven will resolve. That's the reason of the "appeared out of nowhere".
If I read the documentation of JavaPluginLoader it says:
Represents a Java plugin loader, allowing plugins in the form of .jar
I'm not at all familiar with this library but I would interpret it as "This plugin will only load the specified jar" which would be the MoneyDrops jar.
Line 127 at https://github.com/Bukkit/Bukkit/blob/master/src/main/java/org/bukkit/plugin/java/JavaPluginLoader.java actually provides the bukkit classloader and a file as the classpath. I presume the file will be your jar.
So in order to make this work you'd need to somehow make your dependencies available to the classloader of bukkit. Maybe the minecraft server?
Another option is to unpack all the dependencies. The jars are compressed files anyway and repack them with your code. This way you can provide a single jar to the pluginloader. There's a maven plugin doing this for you but I forgot the name.
Thank you all for your help! I have concluded that I do not actually need logging in my plugin anyway (it is not that heavy) and have opted to remove it completely and rely on the Bukkit logger instead. Again, thank you all for your help.
After using Eclipse EE and Eclipse Axis2 Code Generator plugin, I got a two
operation generated java files with the same error:
Cannot instantiate the type ADBDataSource ConcatRequest.java
Cannot instantiate the type ADBDataSource ConcatResponse.java
Here is the problem:
org.apache.axiom.om.OMDataSource dataSource = new
org.apache.axis2.databinding.ADBDataSource(this,MY_QNAME);
This code appears in both ConcatRequest.java and ConcatResponse.java and
causes the error. I see that ADBDataSource is abstract and cannot be instantiated.
I'm totally new to Axis and I don't know how to solve this problem. Please help.
I had this problem due to a version mismatch of axis2-adb. Safest way to deal with this problem is to have a look at the lib folder of the eclipse plugin (eclipse/(dropins|plugins)/ ... .jar). Then look for the versions of the dependecies and include them (the ones you actually need) in your build path.
i faced the same issue while generating JAVA Stubs from WSDL. Following are the steps I used to solve the issues :
Follow the below link to generate Stubs : https://support.pcmiler.com/en/support/solutions/articles/19000053078-java-client-axis2-code-generator-for-eclipse.
Now there is a small tweak to this link. After doing point no 10 & 11 as mentioned in the above link , only use axis2-1.7.9 to generate your stubs and when they are generated used the jars mentioned in the \axis2-1.7.9\lib in your build path.
Hope this solves your issue.
Old topic, but I was working on a legacy project with several subprojects.
In one of those subprojects, I came across this same message.
It also was a version problem (Maven dependencies...).
Ctrl-Click (in Eclipse/IntelliJ) on "ADBDataSource". Which version is it? For me it was 1.5.6, but in my pom.xml there was only
<dependency>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2</artifactId>
<version>1.7.4</version>
</dependency>
However, this subproject had a dependency on another subproject which WAS using 1.5.6 (I found it by searching in the whole project for "1.5.6" using the Notepad++ "Search / Find in Files" menu option).
Then in the dependency to that other project, I excluded 1.5.6 :
<dependency>
<groupId>com.group.id</groupId>
<artifactId>anotherproject</artifactId>
<version>version</version>
<exclusions>
<exclusion>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2</artifactId>
</exclusion>
</exclusions>
</dependency>
After adding the exclusion, the project did use the 1.7.4 version.
I am getting this exception while trying to call SOAP webservice using axis. basically I have written a axis client.
org.apache.commons.discovery.DiscoveryException: Class org.apache.commons.logging.impl.SLF4JLogFactory does not implement org.apache.commons.logging.LogFactory.
When I remove the all the common-logging jars, I would able to remove these errors but these jars are coming from other apis, i dont have control on them.
Is there any way to overcome this problem?
There is a pretty detailed explanation of what the issue may be and ways to debug it in the commons logging documentation. Your particular issue may be,
There is also another more unusual way in which this cast can fail:
even when the binary is compatible, the implementation class loaded at
runtime may be linked to a different instance of the LogFactory class.
For more information, see the tech guide.
None of this solutions worked for me. I figure out my solution in SLF4J documentation
http://slf4j.org/faq.html#excludingJCL
alternative 2) provided scope Commons-logging can be rather simply and
conveniently excluded as a dependency by declaring it in the provided
scope within the pom.xml file of your project. The actual
commons-logging classes would be provided by jcl-over-slf4j. This
translates into the following pom file snippet:
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.1.1</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>1.7.21</version>
</dependency>
The first dependency declaration essentially states that
commons-logging will be "somehow" provided by your environment. The
second declaration includes jcl-over-slf4j into your project. As
jcl-over-slf4j is a perfect binary-compatible replacement for
commons-logging, the first assertion becomes true. Unfortunately,
while declaring commons-logging in the provided scope gets the job
done, your IDE, e.g. Eclipse, will still place commons-logging.jar on
your project's class path as seen by your IDE. You would need to make
sure that jcl-over-slf4j.jar is visible before commons-logging.jar by
your IDE.
SLF4J documentation gives more alternatives, this worked for me.
The Link to the above mentioned Documentation to section "Fixes" suggests to include
-Dorg.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.LogFactoryImpl
in your setup.
For some people it might be easier to include this code instead:
static
{
System.setProperty(LogFactory.FACTORY_PROPERTY, LogFactory.FACTORY_DEFAULT);
}
Replace jcl-over-slf4j jar with commons-logging jar
Probably its too late :-) but for me following worked. I am using spring boot and added it as first line in the main methods. More explanation as suggested above is here.
System.setProperty("org.apache.commons.logging.LogFactory", "org.apache.commons.logging.impl.LogFactoryImpl");