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");
Related
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.
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;
I'm new to threading in java and now read the "java concurrency in practice". As you possibly understand I'm trying to do any examples but can't. when I'm trying to use #Immutable annotation IDE(Idea) underlines it red.
What is the possible reason of this?
The reason is that you do not have the correct jar in your classpath.
The maven artifact for this jar is:
<dependency>
<groupId>net.jcip</groupId>
<artifactId>jcip-annotations</artifactId>
<version>1.0</version>
<dependency>
If you do not have this jar in your classpath, you don't have the annotation.
Note however that this is superseded by JSR 305. There is also a Maven artifact for an implementation of that JSR:
<dependency>
<groupId>com.google.code.findbugs</groupId>
<artifactId>jsr305</artifactId>
<version>2.0.1</version>
</dependency>
(side note: excellent choice of a read! This is one must-have book for all Java devs out there)
Download the jar file providing the jcip annotations and add it to the module dependencies.
As far as working with that book's examples, so all those annotations, like #ThreadSafe, #Immutable/#Threadsafe, they all are just symbolic (though fge above is correct, you can use those jars as well, but from learning perspective, just ignore them)
So, simply ignore them. Anywhere, if you see #Immutable, it simply means that code written is IMMUTABLE, by the virtue of code implementation.
You don't need any jar at all. Just remove those annotations from your examples :)
I am trying to use the annotations of findbugs 1.3.2.
I used the edu.umd.cs.findbugs.annotations.NonNull annotation in a simple test,
and it works fine.
However, now I have a large project, composed of sub-modules, using maven,
and I get the following compilation error by just importing that annotation in some java file:
com.sun.tools.javac.code.Symbol$CompletionFailure: class file for javax.annotation.meta.When not found
what can be the problem?
i tried adding the findbugs dependency in all sub-modules.
maybe it is a conflict with jsr305? I see that one of our dependencies uses jsr305 1.3.9.
In my experience, this error always occurs when you use #NonNull and jsr305.jar is not on the classpath. In order to use the findbugs annotations, you must add both annotations.jar and jsr305.jar to the classpath.
Some annotations (I am thinking of #SuppressWarnings) can be used without jsr305.jar, but #NonNull requires it for sure.
(You mentioned jsr305.jar in your question, but you didn't say explicitly that you've checked. Also, people are going to land here when searching for the error message, and they will need to add jsr305.jar.) Only one version of jsr305.jar should be on the classpath.
You can also use this dependency
<dependency>
<groupId>com.google.code.findbugs</groupId>
<artifactId>annotations</artifactId>
<version>3.0.1</version>
</dependency>