java.util.concurrent.ExecutionException

There are no available Samebug tips for this exception. Do you have an idea how to solve this issue? A short tip would help users who saw this issue last week.

  • {code} Nov 16, 2015 6:54:59 AM net.bull.javamelody.JavaLogger warn WARNING: exception while collecting data java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError: Could not initialize class net.bull.javamelody.I18N at hudson.remoting.Channel$2.adapt(Channel.java:810) at hudson.remoting.Channel$2.adapt(Channel.java:805) at hudson.remoting.FutureAdapter.get(FutureAdapter.java:59) at net.bull.javamelody.RemoteCallHelper.collectDataByNodeName(RemoteCallHelper.java:169) at net.bull.javamelody.RemoteCallHelper.collectJavaInformationsListByName(RemoteCallHelper.java:179) at net.bull.javamelody.NodesCollector.collectWithoutErrorsNow(NodesCollector.java:154) at net.bull.javamelody.NodesCollector.collectWithoutErrors(NodesCollector.java:143) at net.bull.javamelody.NodesCollector$1.run(NodesCollector.java:87) at java.util.TimerThread.mainLoop(Timer.java:555) at java.util.TimerThread.run(Timer.java:505) Caused by: java.lang.NoClassDefFoundError: Could not initialize class net.bull.javamelody.I18N at net.bull.javamelody.RemoteCallHelper$DelegatingTask.call(RemoteCallHelper.java:130) at hudson.remoting.UserRequest.perform(UserRequest.java:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) at ......remote call to master_git(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1413) at hudson.remoting.UserResponse.retrieve(UserRequest.java:221) at hudson.remoting.Channel$2.adapt(Channel.java:808) ... 9 more {code} seems to have started happening after an upgrade from an old version of both jenkins and the plugin
    via by Tomasz Śniatowski,
  • {code} Nov 16, 2015 6:54:59 AM net.bull.javamelody.JavaLogger warn WARNING: exception while collecting data java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError: Could not initialize class net.bull.javamelody.I18N at hudson.remoting.Channel$2.adapt(Channel.java:810) at hudson.remoting.Channel$2.adapt(Channel.java:805) at hudson.remoting.FutureAdapter.get(FutureAdapter.java:59) at net.bull.javamelody.RemoteCallHelper.collectDataByNodeName(RemoteCallHelper.java:169) at net.bull.javamelody.RemoteCallHelper.collectJavaInformationsListByName(RemoteCallHelper.java:179) at net.bull.javamelody.NodesCollector.collectWithoutErrorsNow(NodesCollector.java:154) at net.bull.javamelody.NodesCollector.collectWithoutErrors(NodesCollector.java:143) at net.bull.javamelody.NodesCollector$1.run(NodesCollector.java:87) at java.util.TimerThread.mainLoop(Timer.java:555) at java.util.TimerThread.run(Timer.java:505) Caused by: java.lang.NoClassDefFoundError: Could not initialize class net.bull.javamelody.I18N at net.bull.javamelody.RemoteCallHelper$DelegatingTask.call(RemoteCallHelper.java:130) at hudson.remoting.UserRequest.perform(UserRequest.java:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) at ......remote call to master_git(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1413) at hudson.remoting.UserResponse.retrieve(UserRequest.java:221) at hudson.remoting.Channel$2.adapt(Channel.java:808) ... 9 more {code} seems to have started happening after an upgrade from an old version of both jenkins and the plugin
    via by Tomasz Śniatowski,
  • A user of the Monitoring plugin reports seeing a repeated exception in the log: {code:none} java.lang.NoClassDefFoundError: com/sun/management/OperatingSystemMXBean at net.bull.javamelody.MemoryInformations.<init>(MemoryInformations.java:75) [javamelody-core-1.36.0.jar:1.36.0] at net.bull.javamelody.JavaInformations.<init>(JavaInformations.java:137) [javamelody-core-1.36.0.jar:1.36.0] at net.bull.javamelody.RemoteCallHelper$1.call(RemoteCallHelper.java:44) [:1.36.0] at net.bull.javamelody.RemoteCallHelper$1.call(RemoteCallHelper.java:36) [:1.36.0] at net.bull.javamelody.RemoteCallHelper$DelegatingTask.call(RemoteCallHelper.java:129) [:1.36.0] at hudson.remoting.LocalChannel$1.call(LocalChannel.java:52) [remoting-2.11.jar:] {code} Seems that {{operatingSystem}} was a {{com.sun.management.UnixOperatingSystem}} yet the JavaMelody code is not permitted to directly refer to {{com.sun.management.OperatingSystemMXBean}}. Indeed making static reference to classes outside of the packages defined by the JRE is not safe; it will definitely fail for example in a default OSGi environment, and Java vendors are free to restrict access to such packages. Such code must be written defensively by using reflection and recovering gracefully from any errors. By the way the {{isSunOsMBean}} checks for a class named {{com.sun.management.OperatingSystem}} but none such exists that I can see; was {{com.sun.management.OperatingSystemImpl}} meant? Would be better to use reflection to try loading {{com.sun.management.OperatingSystemMXBean}} from the same class loader as {{operatingSystem}}, check if the bean is assignable to this interface, and if so look up methods such as {{getProcessCpuTime}} on that interface and call them on the bean. (Alternately, do all this with static classes but in a separate method wrapped in a {{try}}-block catching {{LinkageError}}.) Then there is no need to hardcode the implementation class names, which is even less stable than the {{com.sun.management}} package as a whole.
    via by Jesse Glick,
  • A user of the Monitoring plugin reports seeing a repeated exception in the log: {code:none} java.lang.NoClassDefFoundError: com/sun/management/OperatingSystemMXBean at net.bull.javamelody.MemoryInformations.<init>(MemoryInformations.java:75) [javamelody-core-1.36.0.jar:1.36.0] at net.bull.javamelody.JavaInformations.<init>(JavaInformations.java:137) [javamelody-core-1.36.0.jar:1.36.0] at net.bull.javamelody.RemoteCallHelper$1.call(RemoteCallHelper.java:44) [:1.36.0] at net.bull.javamelody.RemoteCallHelper$1.call(RemoteCallHelper.java:36) [:1.36.0] at net.bull.javamelody.RemoteCallHelper$DelegatingTask.call(RemoteCallHelper.java:129) [:1.36.0] at hudson.remoting.LocalChannel$1.call(LocalChannel.java:52) [remoting-2.11.jar:] {code} Seems that {{operatingSystem}} was a {{com.sun.management.UnixOperatingSystem}} yet the JavaMelody code is not permitted to directly refer to {{com.sun.management.OperatingSystemMXBean}}. Indeed making static reference to classes outside of the packages defined by the JRE is not safe; it will definitely fail for example in a default OSGi environment, and Java vendors are free to restrict access to such packages. Such code must be written defensively by using reflection and recovering gracefully from any errors. By the way the {{isSunOsMBean}} checks for a class named {{com.sun.management.OperatingSystem}} but none such exists that I can see; was {{com.sun.management.OperatingSystemImpl}} meant? Would be better to use reflection to try loading {{com.sun.management.OperatingSystemMXBean}} from the same class loader as {{operatingSystem}}, check if the bean is assignable to this interface, and if so look up methods such as {{getProcessCpuTime}} on that interface and call them on the bean. (Alternately, do all this with static classes but in a separate method wrapped in a {{try}}-block catching {{LinkageError}}.) Then there is no need to hardcode the implementation class names, which is even less stable than the {{com.sun.management}} package as a whole.
    via by Jesse Glick,
    • java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError: Could not initialize class net.bull.javamelody.I18N at hudson.remoting.Channel$2.adapt(Channel.java:810) at hudson.remoting.Channel$2.adapt(Channel.java:805) at hudson.remoting.FutureAdapter.get(FutureAdapter.java:59) at net.bull.javamelody.RemoteCallHelper.collectDataByNodeName(RemoteCallHelper.java:169) at net.bull.javamelody.RemoteCallHelper.collectJavaInformationsListByName(RemoteCallHelper.java:179) at net.bull.javamelody.NodesCollector.collectWithoutErrorsNow(NodesCollector.java:154) at net.bull.javamelody.NodesCollector.collectWithoutErrors(NodesCollector.java:143) at net.bull.javamelody.NodesCollector$1.run(NodesCollector.java:87) at java.util.TimerThread.mainLoop(Timer.java:555) at java.util.TimerThread.run(Timer.java:505) Caused by: java.lang.NoClassDefFoundError: Could not initialize class net.bull.javamelody.I18N at net.bull.javamelody.RemoteCallHelper$DelegatingTask.call(RemoteCallHelper.java:130) at hudson.remoting.UserRequest.perform(UserRequest.java:121) at hudson.remoting.UserRequest.perform(UserRequest.java:49) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745)
    No Bugmate found.