I start working on older Spring application and when I start it, it produces such log messages (~100 messages):
2015-02-10 15:53:11,757 INFO
[org.springframework.context.annotation.AnnotationConfigApplicationContext:510]
- Refreshing org.springframework.context.annotation.AnnotationConfigApplicationContext#50533643:
startup date [Tue Feb 10 15:53:11 CET 2015]; root of context hierarchy
And terminates with this exception:
Exception in thread "main" java.lang.NoClassDefFoundError:
org.springframework.beans.FatalBeanException
I am running it in IntelliJ IDEA and I use Maven for dependency management.
It never happed before - what could be wrong?
I recommend to build it again with maven and build a new IDEA project. This problem is a dependency issue.
To build:
mvn clean install
and to create new IDEA project
mvn idea:clean idea:idea
Related
I am facing issue while installing any of the Jenkins plugins suggested.
Actually after downloading,Jenkins.war file(which is latest 2.141) when i tried to execute the jar with
java -jar jenkins.war so it gave me an error of Jenkins require java 8 but you are using 10. Also,it says that java class version 54.0 is running,but it requires java 52.0.
But I was able to resolve this issue by setting --enable-future-java flag.
java -jar jenkins.war --enable-future-java flag
Now,after writing this command,jenkins is up and running but i am unable to install the plugins.
Also,im cmd prompt after the Jenkins is upa d running.There is one error also.
PFB :-
Sep 17, 2018 4:38:49 PM hudson.WebAppMain$3 run
INFO: Jenkins is fully up and running
[31mSep 17, 2018 4:39:02 PM hudson.model.UpdateSite updateData
SEVERE: ERROR: SHA-512 based signature in the update center doesn't match with the certificate in 'update site 'default''
[0mSep 17, 2018 4:39:02 PM hudson.model.AsyncPeriodicWork$1 run
INFO: Finished Download metadata. 15,407 ms
You need to add a flag which allows starting Jenkins with unsupported Java versions. You can do some google research on this.
If we change the Jenkins war file version from 2.141 to 2.814 then it is suitable with Java 10 and works fine for plugins installation of Jenkins
I am running a war on Heroku using webapp-runner. I deploy the application using the heroku-maven-plugin version 1.2 via the following command: mvn heroku:deploy-war. Initially, the app works and all endpoints return valid responses. However, if I allow the app to idle long enough for Heroku to put it to sleep and then invoke an endpoint which calls into guava I receive a NoSuchMethodError:
2017-09-23T19:19:45.388865+00:00 app[web.1]: SEVERE: Servlet.service() for servlet [jersey-serlvet] in context with path [] threw exception [org.glassfish.jersey.server.ContainerException: java.lang.NoSuchMethodError: com.google.common.base.CharMatcher.ascii()Lcom/google/common/base/CharMatcher;] with root cause
2017-09-23T19:19:45.388866+00:00 app[web.1]: java.lang.NoSuchMethodError: com.google.common.base.CharMatcher.ascii()Lcom/google/common/base/CharMatcher;
2017-09-23T19:19:45.388867+00:00 app[web.1]: at com.google.common.io.BaseEncoding$Alphabet.<init>(BaseEncoding.java:453)
2017-09-23T19:19:45.388868+00:00 app[web.1]: at com.google.common.io.BaseEncoding$Base64Encoding.<init>(BaseEncoding.java:892)
2017-09-23T19:19:45.388869+00:00 app[web.1]: at com.google.common.io.BaseEncoding.<clinit>(BaseEncoding.java:317)
...application specific stack trace
All subsequent calls to the same API produce a NoClassDefFoundError at the same point
2017-09-23T19:22:24.454901+00:00 app[web.1]: SEVERE: Servlet.service() for servlet [jersey-serlvet] in context with path [] threw exception [org.glassfish.jersey.server.ContainerException: java.lang.NoClassDefFoundError: Could not initialize class com.google.common.io.BaseEncoding] with root cause
2017-09-23T19:22:24.454903+00:00 app[web.1]: java.lang.NoClassDefFoundError: Could not initialize class com.google.common.io.BaseEncoding
...application specific stack trace
These issues seem to suggest that the guava jar is present at compile time but not present at runtime. However, I logged-in to the web dyno and verified that the guava jar was included in my warfile
my-mbp:TrickServer me$ heroku ps:exec
Establishing credentials... done
Connecting to web.1 on ⬢ myapp...
~ $ cd target/
~/target $ ls
MyApp.war dependency mvn-dependency-list.log tomcat.52079
~/target $ jar -tf MyApp.war
...lots of dependencies...
WEB-INF/lib/google-oauth-client-1.20.0.jar
WEB-INF/lib/gson-2.2.4.jar
WEB-INF/lib/guava-23.0.jar <---guava
WEB-INF/lib/guava-jdk5-13.0.jar
...lots more dependencies...
I am struggling to explain why the endpoints work immediately after the app is deployed but later produce these errors. To me this behavior seems to suggest that Heroku is potentially supplying a different classpath when my app wakes up from sleep than when it is initially run or that Heroku is moving/cleaning up the guava jarfile.
Contents of my Procfile:
web: java $JAVA_OPTS -jar target/dependency/webapp-runner.jar --port $PORT --expand-war target/MyApp.war
Java Processes runnning on my web dyno:
~/target $ ps -ef | grep java
u30439 4 1 0 18:50 ? 00:00:44 java -Xmx300m -Xss512k -Dfile.encoding=UTF-8 -Duser.timezone=UTC -jar target/dependency/webapp-runner.jar --port 52079 target/MyApp.war
u30439 27 4 0 18:50 ? 00:00:00 bash --login -c java $JAVA_OPTS -jar target/dependency/webapp-runner.jar $WEBAPP_RUNNER_OPTS --port 52079 target/MyApp.war
Update 1
Since I am invoking my webapp with the --expand-war argument I also checked the jarfiles in the expanded directory to verify that guava was present. It is:
~/target/tomcat.55320/webapps/expanded/WEB-INF/lib $ ls
...dependencies...
google-oauth-client-1.20.0.jar
gson-2.2.4.jar
guava-23.0.jar
guava-jdk5-13.0.jar
...more dependencies...
Update 2
I added the following logic to the problematic web service to printout the classpath and the resources on it:
logger.info("System Classpath: " + System.getProperty("java.class.path"));
logger.info("Runtime Classes...");
ClassLoader cl = UserService.class.getClassLoader();
URL[] urls = ((URLClassLoader) cl).getURLs();
for(URL url: urls){
logger.info(url.getFile());
}
The next time the error occurred I examined the logs and to my surprise found that the guava jar was present on the runtime classpath!
2017-09-24T12:07:40.843438+00:00 app[web.1]: [heroku-exec] ERROR: Could not connect to proxy:
2017-09-24T12:07:40.844145+00:00 app[web.1]: [heroku-exec] ERROR: Too many reconnect attempts. Waiting 30 seconds...
2017-09-24T12:07:52.671620+00:00 app[web.1]: Sep 24, 2017 12:07:52 PM org.myorg.server.web.services.MyService authenticate
2017-09-24T12:07:52.671631+00:00 app[web.1]: INFO: System Classpath: target/dependency/webapp-runner.jar
2017-09-24T12:07:52.671931+00:00 app[web.1]: Sep 24, 2017 12:07:52 PM org.myorg.server.web.services.MyService authenticate
2017-09-24T12:07:52.671932+00:00 app[web.1]: INFO: Runtime Classes...
2017-09-24T12:07:52.672277+00:00 app[web.1]: Sep 24, 2017 12:07:52 PM org.myorg.server.web.services.MyService authenticate
2017-09-24T12:07:52.672279+00:00 app[web.1]: INFO: /app/target/tomcat.28304/webapps/expanded/WEB-INF/classes/
....
2017-09-24T12:07:52.690304+00:00 app[web.1]: Sep 24, 2017 12:07:52 PM org.myorg.server.web.services.MyService authenticate
2017-09-24T12:07:52.690306+00:00 app[web.1]: INFO: /app/target/tomcat.28304/webapps/expanded/WEB-INF/lib/google-oauth-client-1.20.0.jar
2017-09-24T12:07:52.690501+00:00 app[web.1]: Sep 24, 2017 12:07:52 PM org.myorg.server.web.services.MyService authenticate
2017-09-24T12:07:52.690503+00:00 app[web.1]: INFO: /app/target/tomcat.28304/webapps/expanded/WEB-INF/lib/guava-23.0.jar <--- Guava!!!
....
What is going on here? How do I debug this?
You probably have two versions of guava or its related jars on your classpath. See NoSuchMethodError exception when using com.google.common.base.Splitter
After some debugging, I discovered that my program had two different versions of Guava on the classpath (guava-23.0.jar & guava-jdk5-13.0.jar). The debugging tip suggested here was necessary but not sufficient for me to get to the bottom of this.
When working with ClassLoaders it's important to remember that the getClassLoader method defined in the .class object returns a reference to the ClassLoader that originally loaded the class. To find the duplicate jar, it was crucial to invoke classLoader.getResource("/com/google/common/base/CharMatcher.class") on the same ClassLoader which loaded the class that later failed with the NoSuchMethodError.
For posterity, the specific dependency which caused the conflict was com.google.api-client. I resolved it by adding the following exclusion to the dependency in my pom.xml
<dependency>
<groupId>com.google.api-client</groupId>
<artifactId>google-api-client</artifactId>
<version>1.22.0</version>
<exclusions>
<exclusion>
<groupId>com.google.guava</groupId>
<artifactId>guava-jdk5</artifactId>
</exclusion>
</exclusions>
</dependency>
I am running Jenkins job and afterwards I am getting timeout error:
get.hudson.release.version:
get.svn.build.version:
[echo] Determinating build version
[echo] Check SVN info for URL:
[svn] started ... Build timed out (after 30 minutes). Marking the build as failed. Build was aborted Archiving artifacts
I've checked configuration of job. It looks fine. URL is working. I can get it via the browser. How can I investigate/understand the root cause of problem?
Why does running failing tests within a Spring application context cause my Jenkins build to crash?
I am using Ant to build my application and run JUnit tests on Jenkins.
I have not experienced any problems while running my Ant build within Eclipse, with or without failing tests.
However, when I try to run the build with Jenkins, the build fails without recording an exception when it has finished running the JUnit tests:
...
[junit] INFO: Executing Stored Procedure with parameters {#pivoting=1, #ignoreReference=0}
[junit] Tests run: 7, Failures: 1, Errors: 0, Time elapsed: 7.831 sec
[junit] Sep 22, 2015 4:23:57 PM org.springframework.context.support.AbstractApplicationContext doClose
[junit] INFO: Closing org.springframework.context.support.GenericApplicationContext#8a590d1:
startup date [Tue Sep 22 16:23:52 BST 2015]; root of context hierarchy
BUILD FAILED
E:\Jenkins\jobs\workspace\AntBuilds\build.xml:336: Tests failed
Total time: 16 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Finished: FAILURE
The output above is unexpected, as I have configured the build to be simply UNSTABLE if tests fail, and I have configured a JaCoCo report to be published after the tests have been run.
Usually I would see something more like:
[junit] INFO: Closing org.springframework.context.support.GenericApplicationContext#6a38e598: display name [org.springframework.context.support.GenericApplicationContext#6a38e598]; startup date [Tue Sep 22 16:01:10 BST 2015]; root of context hierarchy
[junit] Tests FAILED
[jacoco:report] Loading execution data file E:\Jenkins\jobs\jacoco.exec
[jacoco:report] Writing bundle 'Coverage Report' with 117 classes
...etc
Removing the failing tests allows the build to continue as normal:
BUILD SUCCESSFUL
Total time: 36 seconds
Archiving artifacts
Recording test results
[JaCoCo plugin] Collecting JaCoCo coverage data...
[JaCoCo plugin] **/**.exec;**/dist/WEB-INF/classes;**/src; locations are configured
[JaCoCo plugin] Number of found exec files for pattern **/**.exec: 1
[JaCoCo plugin] Saving matched execfiles: E:\Jenkins\jobs\myJob\jacoco.exec
... etc
My answer so far
I have been successfully building other applications on Jenkins. The difference is that these tests are marked with a Spring application context:
#ContextConfiguration(locations="file:WEB-INF/MyJob-servlet.xml")
#RunWith(SpringJUnit4ClassRunner.class)
I have been wondering if Jenkins fails to close the Application Context when tests fail, as this line appears for the failed build just before the 'BUILD FAILED' message:
Closing org.springframework.context.support.GenericApplicationContext#8a590d1:
startup date [Tue Sep 22 16:23:52 BST 2015]; root of context hierarchy
I have needed to upgrade to:
JUnit-4.4
spring-integration-test-2.1.3.RELEASE
Is this hunch correct? If so, is this a bug with Jenkins / Spring / incompatible versions, or is my implementation incorrect?
If a test fails then Jenkins fails the build by default. The stability of the build is calculated by how much builds have been failing recently. So if failing tests didn't cause your build to fail, then test would have no influence on stability, and then you can't do stuff like email people that the build failed and what commit caused it, and what test failed, which is highly useful.
I am dealing with derby to perform database related functions in a Java Project. The java project is a command line project. To accomplish this, I have added derby.jar into libs folder of my project, though on running application into netbeans, I am getting this error :
Mon Aug 18 17:32:23 IST 2014 Thread[AWT-EventQueue-0,6,main] java.lang.ClassNotFoundException: DerbyLogSetting
----------------------------------------------------------------
Mon Aug 18 17:32:23 IST 2014:
Booting Derby version The Apache Software Foundation - Apache Derby - 10.8.1.2 - (1095077): instance a816c00e-0147-e8ff-2d32-000003436058
on database directory My_Database_Path\Database_Path with class loader sun.misc.Launcher$AppClassLoader#430e468f
Loaded from file:/My_Project_Path/derby.jar
java.vendor=Oracle Corporation
java.runtime.version=1.7.0_45-b18
user.dir=My_Project_Path
derby.system.home=null
derby.stream.error.method=DerbyLogSetting.disableDerbyLogFile
Database Class Loader started - derby.database.classpath=''
Same happening when I am running the exe of my project on command prompt. On goggling about the issue, I got that on adding derby-client into class path can solve my problem, but adding this jar (derbyclient-10.8.1.2.jar) into libs of my project not solving the issue.
What else needed to solve the issue ?