This question already has an answer here:
Your vm does not find the class
org/apache/juli/logging/LogFactory check if this class is present in the tomcat-juli.jar that you use (unzip it and search the file), if it's not present download the library from apache web site else if it's present put the tomcat-juli.jar in a path (the lib directory) that Tomcat use to load classes. If your Tomcat does not find it you can copy the jar in the lib directory of the JRE that you are using.
If you are using jsvc to run tomcat as tomcat (run
/etc/init.d/tomcat as root), edit
/etc/init.d/tomcat and add
This happened to me because I was using a Tomcat 5.5
catalina.sh file with a Tomcat 7 installation. Using the
catalina.sh that came with the Tomcat 7 install fixed the problem.
I ran into this problem when using
tomcat-embed-core::7.0.47, from Maven. I'm not sure why they didn't add
tomcat-util as a runtime dependency, so I added my own runtime dependency to my own project.
<dependency> <groupId>org.apache.tomcat</groupId> <artifactId>tomcat-util</artifactId> <version><!-- version from tomcat-embed-core --></version> <scope>runtime</scope> </dependency>
In our case, the wrong version of the Sysdeo Tomcat plugin for Eclipse 3.5 was being used. The fix:
DevloaderTomcat7.jarwas placed in the tomcat
This problem may have been unique to our environment; but, I'll record it here anyway, for posterity's sake.
I had the same problem, What helped me was:
On Ubuntu 14.04 LTS
/usr/share# mv /opt/tomcat/apache-tomcat-7.0.56/ tomcat7
fixed the issue for me. There was a symbolic link there to /opt. Inside that opt directory there where ../../java links that would not point to /usr/share/java since the files physically were in /opt