After upgrading gwt from version 2.1.1 to 2.8.0, I got the error message
2017-04-20 12:59:19.551:WARN:oejuc.AbstractLifeCycle:main: FAILED c.g.g.d.s.j.WebAppContextWithReload#341fbaf1{/,file:/C:/Users/xxx/.IntelliJIdea2017.1/system/gwt/xxx.97baa614/xxx.fdf824a8/run/www/,STARTING}{C:\Users\xxx\.IntelliJIdea2017.1\system\gwt\xxx.97baa614\xx.fdf824a8\run\www}: java.util.ServiceConfigurationError: org.apache.juli.logging.Log: Provider org.eclipse.jetty.apache.jsp.JuliLog not a subtype
java.util.ServiceConfigurationError: org.apache.juli.logging.Log: Provider org.eclipse.jetty.apache.jsp.JuliLog not a subtype
I found some other posts with similar messages, like this or this, but the situation seems to be different:
I do not use Maven or Ant, just pure IntelliJ, I have no reference to any Tomcat library, and I am not aware of any JSP in our application.
I found through debugging that first the class loader com.google.gwt.dev.shell.jetty.Jettylauncher$WebAppContextWithReload$WebAppClassLoaderExtension loads class org.eclipse.jetty.apache.jsp.JuliLog including interface org.apache.juli.logging.Log.
Then, later interface org.apache.juli.logging.Log is loaded by sun.misc.Launcher$AppClassLoader triggered indirectly by
org.eclipse.jetty.webapp.WebAppContext.startContext()
which calls method initialize of an
org.eclipse.jetty.jsp.JettyJspServlet
instance.
I have no idea why a JspServlet needs to be initialized at all, as no JSPs are used in the application, as far as I see, just a few Servlets. And it seems all the classes involved in this conflict are contained in the single jar gwt-dev.jar, so I see no possibility to influence any class loading behavior via class path settings.
Any idea how I could resolve this?
I also got this error upgrading from gwt from version 2.4 to 2.8.2.
Jake W's answer helped me.
To solve this, I ran a maven dependency tree on my project to figure out what was referencing jetty's apache-jsp.
To run the dependency tree, in Eclipse I created a new run configuration -> maven build -> with the goals "dependency:tree -Doutput=/dependency/file.txt". Once it's run, the console output will show where it saves the output. It should be the same location that you referenced with the -Doutput option.
Look for something like this in the output file:
- org.eclipse.jetty:apache-jsp:jar:9.2.14.v20151106:compile
And then look up in the tree to see where it's being pulled in from. In my case it came from this:
+- com.google.gwt:gwt-dev:jar:2.8.2:compile
+- net.sourceforge.htmlunit:htmlunit:jar:2.19:compile
\- org.eclipse.jetty:apache-jsp:jar:9.2.14.v20151106:compile
Once you know where it's coming from, (assuming you're using maven) you can add an exclusion in your pom.xml file for it:
</dependencies>
<dependency>
<groupId>com.google.gwt</groupId>
<artifactId>gwt-dev</artifactId>
<version>${gwt.version}</version>
<exclusions>
<exclusion>
<groupId>org.eclipse.jetty</groupId>
<artifactId>apache-jsp</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
This worked for me. Thanks :)
I saw this error when I recently upgraded to GWT 2.8.0. Please try to exclude jetty-apache-Jsp related dependencies from your project.
You may see other jetty related issues as well, so please also make sure you are using exactly the same jetty version as GWT 2.8.0 is using.
I'm on mobile at the moment, unable to add more details, but I hope that can be a useful direction to go. Please add your comments if you still see issues, I will then have a look and update the answer when I'm on my laptop.
I have just ran into this exception after adding gwt-test-utils:0.53 dependency (with GWT 2.8.1)
I am using ant and all information found regarding this error indicated there was 2 versions of Juli Logging in the classpath, but every search came up with only gwt-dev.jar. Production builds worked fine, but dev mode did not which needs gwt-dev.jar.
Part of the build process has the jars copied from a local lib directory to war/WEB-INF/lib to pack into the war. The ant script points to the local lib directory for debugging, not the ones meant for the war file. Despite the war location not being listed in the ant file as a class path, it was still loading it.
Ultimately, gwt-dev.jar was conflicting with the copied version of itself.
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 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");
i am executing simple Dependency Injection program of spring & getting this exception.
I have already included common-logging1.1.1.jar and spring.jar file. Could you please help to out?
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory
at org.springframework.context.support.AbstractApplicationContext.<init>(AbstractApplicationContext.java:119)
at org.springframework.context.support.AbstractXmlApplicationContext.<init>(AbstractXmlApplicationContext.java:55)
at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:77)
at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:65)
at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:56)
at com.client.StoryReader.main(StoryReader.java:15)
Caused by: java.lang.ClassNotFoundException: org.apache.commons.logging.LogFactory
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
... 6 more
If you're using maven for managing dependencies, add the following lines in your pom.xml:
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.1.1</version>
</dependency>
I have also faced the same issues, to fix, download the jar files from the below url
http://commons.apache.org/logging/download_logging.cgi
and copy to your lib folder, will resolve your issue.
You just download commons-logging-1.1.2.jar and then copy this file in to libs
finally, it works.
commons-logging-1.1.1.jar or jcl-over-slf4j-1.7.6.jar al
If you are using maven, use the below code.
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>${slf4j.version}</version>
</dependency>
I had the same problem, and solved it by just adding the commons-logging.jar to the class path.
Setting the scope to compile did it for me
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.2</version>
<scope>compile</scope>
</dependency>
Adding commons-logging.jar or commons-logging-1.1.jar will solve this...
I have already included common-logging1.1.1.jar and ...
Are you sure you spelled the name of the JAR file exactly right? I think it should probably be commons-logging-1.1.1.jar (note the extra - in the name). Also check if the directory name is correct.
NoClassDefFoundError always means that a class cannot be found, so most likely your class path is not correct.
Try doing a complete clean of the target/deployment directory for the app to get rid of any stale library jars. Make a fresh build and check that commons-logging.jar is actually being placed in the correct lib folder. It might not be included when you are building the library for the application.
Issue solved by adding commons-logging.jar
Imp files are ,
antlr-runtime-3.0.1
org.springframework.aop-3.1.0.M2
org.springframework.asm-3.1.0.M2
org.springframework.aspects-3.1.0.M2
org.springframework.beans-3.1.0.M2
org.springframework.context.support-3.1.0.M2
org.springframework.context-3.1.0.M2
org.springframework.core-3.1.0.M2
org.springframework.expression-3.1.0.M2
commons-logging-1.1.1
Two options (at least):
Add the commons-logging jar to your file by copying it into a local folder.
Note: linking the jar can lead to problems with the server and maybe the reason why it's added to the build path but not solving the server startup problem.
So don't point the jar to an external folder.
OR...
If you really don't want to add it locally because you're sharing the jar between projects, then...
If you're using a tc server instance, then you need to add the jar as an external jar to the server instance run configurations.
go to run as, run configurations..., {your tc server instance}, and then the Class Path tab.
Then add the commons-logging jar.
I got the same trouble than you.
Finally I checked the version of apache possessing the class.
I found that the version 1.0.4 has the class.
Try to use the version 1.0.4 instead of 1.1.X or 1.2.X
My dependencies :
<dependencies>
<dependency>
<groupId>org.jolokia</groupId>
<artifactId>jolokia-core</artifactId>
<version>1.3.5</version>
</dependency>
<dependency>
<groupId>org.jolokia</groupId>
<artifactId>jolokia-client-java</artifactId>
<version>1.3.5</version>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<version>1.0.4</version>
</dependency>
</dependencies>
My Java Code
J4pClient j4pClient = new J4pClient("http://localhost:8080/jolokia");
J4pReadRequest req = new J4pReadRequest("java.lang:type=Memory","HeapMemoryUsage");
req.setPath("used");
J4pReadResponse resp = j4pClient.execute(req);
System.out.println(resp.getValue());
My Result :
130489168
Double check also that your maven dependencies are well imported.
http://commons.apache.org/logging/download_logging.cgi
use this url to download jar files and include them in your class path, issue will be solved
The topic is very outdated. But it still can be met ourdays.
commons-logging, or also known as jcl is a deprecated library. The last version was exposed in 2014
You should avoid adding dependency on it directly in your projects. I assume the most of answers and the accepted one are not actual anylonger.
A preferrable way to use in your projects new alternatives, like slf4j or log4j2, which play the same role, as jcl. The reasons and motivation is another big topic, not for the scope of this issue.
If your application uses log4j2, and you meet the error, add dependency:
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-jcl</artifactId>
<version>2.y.z</version>
</dependency>
If you prefer slf4j, (already offered in previous comments/replies ) use:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>${slf4j.version}</version>
</dependency>
If you use Spring, most probably you have in the dependency tree:
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-jcl</artifactId>
</dependency>
and it solves the issue as well.
In the examples I skipped certain versions by purpose, they get deprecated very quickly, see Offitial Maven repository.
In some cases you should not use version attribute at all, preferring using dependencies from BOM files. Spring is an example.
Just check whether the commons-logging.jar has been added to your libs and the classpath.. I had the same issue and that was because of this.
dhammikas-
I generally assign the classpath to a variable and then verify it. I've written a small ruby script which I include in a my startup scripts which validates the classpath before launching java. Validating the classpath before the JVM starts has saved me lots of time troubleshooting these types of problems.
Hey I was following the tutorial on tutorialpoint.com. Add after you complete Step 2 - Install Apache Common Logging API: You must import external jar libraries to the project from the files downloaded at this step. For me the file name was "commons-logging-1.1.1".
If you're running this on Android then note that apparently java.beans package is not complete on Android. To attempt to fix it on Android try the following:
Download android-java-air-bridge.jar (currently the download button is on the bottom of the page or direct link here)
Copy the downloaded jar to your [APPROOT]/app/libs directory (or link the jar in any other way)
Change the import *** statements to that of air-bridge. Eg import javadz.beanutils.BeanUtils instead of import org.apache.commons.beanutils.BeanUtils;
Clean and rebuild the project
source 1, source 2
I apologise as I realise this is not exactly answering the question, though this SO page comes up a lot when searching for android-generated NoClassDefFoundError: Failed resolution of: beanUtils errors.
I was getting the same error while the jar was present. No solution worked. What worked was deleting the jar from the file system (from .m2 directory) and then cleaning the maven project.
I have the same problem in eclipse IDE, my solution was:
Right click in My project > Properties
Click in Maven and write: jar in the Active Maven Project
Finally, Apply and Close
In my case I was testing a Tomcat app in eclipse and got this error. I solved it by checking the .classpath file and corrected this entry:
<classpathentry kind="con" path="org.eclipse.m2e.MAVEN2_CLASSPATH_CONTAINER">
<attributes>
<attribute name="maven.pomderived" value="true"/>
<attribute name="org.eclipse.jst.component.dependency" value="/WEB-INF/lib"/>
</attributes>
</classpathentry>
The attribute org.eclipse.jst.component.dependency had been missing.
Check whether the jars are imported properly. I imported them using build path. But it didn't recognise the jar in WAR/lib folder. Later, I copied the same jar to war/lib folder. It works fine now. You can refresh / clean your project.
Hello friends if your getting any not class found exception in hibernate code it is the problem of jar files.here mainly two problems
1.I mean to say your working old version of hibernate may be 3.2 bellow.So if u try above 3.6 it will works fine
2.first checkes database connection.if it database working properly their was a mistake in ur program or jar file.
please check these two prioblems if it also not working you tried to IDE . I am using netbeanside 6.9 version.here hibernate working fine.you dont get any error from class not founnd exception..
I hope this one helps more
try adding this dependency
org.apache.commons
commons-exec
1.3
If all else fails, as it had for me, try putting the commons-logging-x.y.z.jar in your Tomcat lib directory. It solved the problem! BTW, I am using Tomcat 6.
Solution is to Add common-logging.x.x jar file