I'm using neo4j-jdbc in an application and get a lot of "Starting the Apache HTTP client" messages during connections.
For logging I'm using logback, slf4j and the bridges like jul-to-slf4j, jcl-over-slf4j and log4j-over-slf4j.
My configuration file is in the classpath and called logback.xml. If I set the root log level to "OFF" its working for every message beside the apache messages.
How can I turn off the "Starting the Apache HTTP client" output?
I tried using log4j which also did'nt work for that message.
Setting the specific package of the httpclient (wire, org.apache, org.restlet, etc.) also didn't work.
The output is generated via a getLogger call from org.restlet.ext.httpclient, so no direct System.out.println statement or something like that.
Any thoughts on that?
Edit: These are the relevant dependencies of the pom file:
[..]
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.5</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.0.12</version>
</dependency>
<dependency>
<groupId>org.neo4j</groupId>
<artifactId>neo4j-jdbc</artifactId>
<version>2.0.2</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>log4j-over-slf4j</artifactId>
<version>1.7.7</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jul-to-slf4j</artifactId>
<version>1.7.7</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>1.7.7</version>
</dependency>
[..]
As Stefan Armbruster and Michael Hunger mentioned in the comments it is fixed in the master branch.
I couldn't figure out exactly why the messages are send to the console, since it looks like a proper jcl logger is used, anyway the messages are gone in the 2.1.5-SNAPSHOT version.
Related
I'm trying to use elasticsearch with websphere 8.5 I added some dependencies of logs like
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.24</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>log4j-over-slf4j</artifactId>
<version>1.6.1</version>
<type>jar</type>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-core</artifactId>
<version>0.9.28</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>0.9.28</version>
</dependency>
and when I start my server I get this error
[05/01/18 16:38:41:894 WET] 0000005c ecs W com.ibm.ws.ecs.internal.scan.context.impl.ScannerContextImpl scanJAR unable to open input stream for resource META-INF/versions/9/org/apache/logging/log4j/util/StackLocator.class in archive WEB-INF/lib/log4j-api-2.9.1.jar
java.lang.IllegalArgumentException
thanks for helping
You should be able to exclude the log4 jars from WebSphere annotation processing using the instructions at this IBM KnowledgeCenter topic.
Modify the server property Ignore-Scanning-Archives in order to ignore the scanJar for this library.
There are 2 different ways for do that:
Modify the server directly:
Add the jar in the file {WAS}/properties/amm.filter.properties
Ignore-Scanning-Archives = log4j-api-2.9.1.jar
Using Manifest file:
Is practically the same, add the property Ignore-Scanning-Archives inside your Manifest in the EAR file.
If the project is a Maven project add new xml tag in the maven-ear-plugin
<plugin>
<artifactId>maven-ear-plugin</artifactId>
...
<manifestEntries>
<Ignore-Scanning-Archives>log4j-api-2.9.1.jar</Ignore-Scanning-Archives>
My logging dependencies currently look like this:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-bom</artifactId>
<version>2.9.1</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependencies>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-api</artifactId>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.25</version>
</dependency>
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-slf4j-impl</artifactId>
</dependency>
I noticed that commons-logging.jar is still in my classpath, for some reason. Should I exclude that or doesn't that cause any issues?
I didn't notice any problems so far, but I'm still wondering if that jar would still cause problems somehow.
There are dependencies that use commons-logging. If it's not present, you'll get NoClassDefFoundErrors when they attempt to log. If there were a possibility to have those not even try to use the dependency, it wouldn't be a problem. However that's not very likely.
However, if they use commons-logging but you're using SLF4J, then there's a problem. They're logging in the wrong place (from your point of view). This is where logging bridges come to work. They implement the public API of different logging frameworks, but redirect the logging to what you're using.
For SLF4J there are several bridges (both ways), so instead of bringing in commons-logging, you bring in jcl-over-slf4j. Libraries will think they're using commons-logging, when they're actually using SLF4J (which then uses an actual logging implementation like Logback).
Easy, huh? ;)
Yes, exclude the commons-logging dependency and add the log4j-jcl bridge instead:
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-jcl</artifactId>
</dependency>
SLF4J API is also redundant because it is already a transitive dependency of the log4j-slf4j-impl binding.
I have unit tests in Java, and I want to add some information on the test to the log.
I want to do it with Maven - mvn clean install –Pstaging, and also in Jenkins
I tried to do it with Logger:
private static final Logger LOG = LoggerFactory.getLogger(S2STest.class); and then
LOG.info("message")
and Added it to the pom.xml
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.6</version>
<scope>provided</scope>
</dependency>
However, I didn't see any information when I run the test.
How I can add information to the test in Maven and Jenkins?
Jenkins doesn't include an SLF4J implementation by default. You can see that in their pom:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>${slf4jVersion}</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-nop</artifactId>
<version>${slf4jVersion}</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-jdk14</artifactId>
<version>${slf4jVersion}</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>${slf4jVersion}</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>log4j-over-slf4j</artifactId>
<version>${slf4jVersion}</version>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.1.3</version>
</dependency>
So, what you need to do is include your own SLF4J implementation in your own pom, such as Log4J or Logback, OR configure it to use the slf4j-jdk14 implementation by using Logger.addHandler. In the first two cases, you will also have to configure that framework's appropriate configuration files as well.
Once you have turned on whichever of these logging frameworks you've decided, you will be able to use that configuration to generate a target for the logging information, and you will have the file. However, getting into the details of exactly how to do that is too broad of a question for Stack Overflow; I recommend picking one and reading their tutorials.
I am not a big fan of web services, but sometimes you have to conform with a client interface. I have successfully generated code from the the provided WSDLs, but when I try and run the application which actually uses the generated classes, I get the following:
java.lang.ClassNotFoundException: org.apache.axis2.transport.local.LocalTransportSender
I am keeping the generated code in a separate project and have the following dependencies in my pom:
<dependencies>
<dependency>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-adb</artifactId>
<version>1.6.1</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-kernel</artifactId>
<version>1.6.1</version>
<scope>compile</scope>
</dependency>
</dependencies>
As stated, the jar gets generated without any issues, but when it is includes in the application that makes use of it, I get the said exception.
Any ideas?
Adding below dependency would probably should solve this problem.
<dependency>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-transport-local</artifactId>
<version>1.6.2</version>
</dependency>
Use next dependencies , and you should not have any problem
For api axis 2
axis2-adb
For runtime
axis2-transport-local
Laxis2-transport-http
I am using slf4j 1.6.2 api jar (tried using 1.6.1 as well) - logback version is 0.9.29 (core & classic). I am using jdk1.6 on ubuntu. The exception I received is copied below.
Exception in thread "main" java.lang.NoSuchMethodError: org.slf4j.helpers.MessageFormatter.arrayFormat(Ljava/lang/String;[Ljava/lang/Object;)Lorg/slf4j/helpers/FormattingTuple;
at ch.qos.logback.classic.spi.LoggingEvent.<init>(LoggingEvent.java:112)
at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:471)
at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:427)
at ch.qos.logback.classic.Logger.info(Logger.java:631)
I am also getting a message complaining about slf4j binding mismatch.
"SLF4J: The requested version 1.6 by your slf4j binding is not compatible with [1.5.5, 1.5.6, 1.5.7, 1.5.8, 1.5.9, 1.5.10, 1.5.11]"
It very much looks like the version of slf4j-api.jar being loaded by the JVM has version 1.5.x. You surely have slf4j-api-1.5.x.jar on your class path (in addition to slf4j-api-1.6.2.jar). Check your class path.
Adding the following dependencies might help :
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.7</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jul-to-slf4j</artifactId>
<version>1.7.7</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>1.7.7</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>log4j-over-slf4j</artifactId>
<version>1.7.7</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-jdk14</artifactId>
<version>1.7.7</version>
</dependency>
slf4j-api version does not match that of the binding:
An SLF4J binding designates an artifact such as slf4j-jdk14.jar or slf4j-log4j12.jar used to bind slf4j to an underlying logging framework, say, java.util.logging and respectively log4j.
Mixing different versions of slf4j-api.jar and SLF4J binding can cause problems. For example, if you are using slf4j-api-1.7.2.jar, then you should also use slf4j-simple-1.7.2.jar, using slf4j-simple-1.5.5.jar will not work.
NOTE From the client's perspective all versions of slf4j-api are compatible. Client code compiled with slf4j-api-N.jar will run perfectly fine with slf4j-api-M.jar for any N and M. You only need to ensure that the version of your binding matches that of the slf4j-api.jar. You do not have to worry about the version of slf4j-api.jar used by a given dependency in your project. You can always use any version of slf4j-api.jar, and as long as the version of slf4j-api.jar and its binding match, you should be fine.
At initialization time, if SLF4J suspects that there may be a api vs. binding version mismatch problem, it will emit a warning about the suspected mismatch.
Got from http://www.slf4j.org, I hope it can help.
Also, you must have a many slf4j-api jars of versions mentioned in the []. Try keeping a single version of slf4j-api and the corresponding compatible slf4j-log4j jars in the classpath.
Mixing different versions of slf4j jars will always be troublesome
The NoSuchMethodError is due to the discovery of Methods-with-the-same-name more than once, probably coming from the different versions of the same jars
We have to align the versions of slf4j-api and the corresponding binding, in my case I was using slf4j-log4j12, acording with the documentation of SLF4J:
http://www.slf4j.org/codes.html#version_mismatch
I replace the versions of both libraries included as transitive dependencies, putting in my pom this:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.1</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.7.1</version>
</dependency>
I hope this help to somebody.
Kind regards,
Jaider
I had the exact same error message. I solved it by excluding the dependency org.apache.directory.server:apacheds-all. Somehow that jar overrides org.slf4j.spi.LocationAwareLogger
This may be more "me too", but I'll try to outline a more complete solution. I mix a lot of software from diverse sources together in my product. I encountered this problem first with NiFi JARs, then more recently with Cassandra JARs all over again. I had already insisted in pom.xml that I have the same version of slf4j everywhere:
<slf4j.version>[1.7.25]</slf4j.version>
...
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>${slf4j.version}</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-simple</artifactId>
<version>${slf4j.version}</version>
</dependency>
... (all the slf4j JARs I needed)
Then, I told Maven I wanted Cassandra without whatever it was bringing in for slf4j:
<dependency>
<groupId>org.apache.cassandra</groupId>
<artifactId>cassandra-all</artifactId>
<version>${cassandra.version}</version>
<exclusions>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
</exclusion>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-simple</artifactId>
</exclusion>
</dependency>
However, like you, I was getting complaints from
Exception in thread "main" java.lang.NoSuchMethodError: org.slf4j.helpers.MessageFormatter.arrayFormat(Ljava/lang/String;[Ljava/lang/Object;)Lorg/slf4j/helpers/FormattingTuple;
at ch.qos.logback.classic.spi.LoggingEvent.<init>(LoggingEvent.java:112)
From mvn dependency:tree, I found out that I was getting logback 1.1.3 which wasn't matching what Cassandra was apparently using (0.9-something like you). So, I excluded getting logback too by adding these exclusions to slf4j ones already there:
<dependency>
<groupId>org.apache.cassandra</groupId>
<artifactId>cassandra-all</artifactId>
<version>${cassandra.version}</version>
<exclusions>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
</exclusion>
<exclusion>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-simple</artifactId>
</exclusion>
<exclusion>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-core</artifactId>
</exclusion>
<exclusion>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
</exclusion>
</dependency>
...whereupon, the problem I had and you are reporting here, went away. I hope this helps someone.
Download from Below link
https://jar-download.com/artifacts/ch.qos.logback/logback-classic/1.1.3/source-code
all three jars are compatible with each other