I get the following error when I run java -jar start.jar. sudo service jetty start works just fine. What seems to be the problem? There are no webapps deployed, its a new install. I have changed the /etc/default/jetty file to enable the service to start.
wissen12#wissen12:/usr/share/jetty$ java -jar start.jar
7 [main] INFO org.mortbay.util.FileResource - Checking Resource aliases
396 [main] WARN org.mortbay.xml.XmlConfiguration - EXCEPTION
java.lang.NoSuchMethodException: class org.mortbay.jetty.Server.setThreadPool(class org.mortbay.thread.QueuedThreadPool)
at org.mortbay.xml.XmlConfiguration.set(XmlConfiguration.java:417)
at org.mortbay.xml.XmlConfiguration.configure(XmlConfiguration.java:231)
at org.mortbay.xml.XmlConfiguration.newInstance(XmlConfiguration.java:198)
at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:880)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at org.mortbay.start.Main.invokeMain(Main.java:194)
at org.mortbay.start.Main.start(Main.java:534)
at org.mortbay.start.Main.start(Main.java:441)
at org.mortbay.start.Main.main(Main.java:119)
Thanks.
I had the exact same problem. Upgrading from Jetty 7.1.x to 7.4.x solved it. Looking at the source code, it looks like Jetty's XML bean handling added a lot more fallback cases for non-exact type matching in setters.
There are 2 possibilities that stand out as the most likely cause:
The server configuration file (jetty.xml) that you're using does not match the version of Jetty that you're using.
The versions do match, but the setThreadPool method is throwing an exception which is being lost
The 2nd seems more likely, so you should follow the instructions on this page
http://docs.codehaus.org/display/JETTY/Debugging
to turn on "ignored exception" logging.
I expect you'll find that an exception is being throw during the call to "Server.setThreadPool" and that is being "ignored" and treated as a "NoSuchMethod" exception.
Related
we are struggling here with a java.lang.NoClassDefFoundError that makes no sense.
The same WAR file runs perfectly in the server B, but throws a java.lang.NoClassDefFoundError on server A.
Configurations are:
Server A (throws Exception):
OS:
NAME="SLES"
VERSION="12-SP4"
VERSION_ID="12.4"
PRETTY_NAME="SUSE Linux Enterprise Server 12 SP4"
Apache Tomcat 8.5.49
Oracle Java dk1.8.0_231
Server B (works perfectly):
OS:
NAME="Ubuntu"
VERSION="16.04.6 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
VERSION_ID="16.04"
PRETTY_NAME="Ubuntu 16.04.6 LTS"
Apache Tomcat 8.5.37
Oracle Java jdk 1.8.0_201-b09
The exception is:
2020-01-27 15:57:27.103 [http-nio-8081-exec-10] ERROR o.g.w.errors.GrailsExceptionResolver - NoClassDefFoundError occurred when processing request: [GET] /server-0.1/cenario/getCenarioJson
Could not initialize class clojure.java.api.Clojure. Stacktrace follows:
org.springframework.web.util.NestedServletException: Handler dispatch failed; nested exception is java.lang.NoClassDefFoundError: Could not initialize class clojure.java.api.Clojure
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:982)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:901)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:970)
...
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.NoClassDefFoundError: Could not initialize class clojure.java.api.Clojure
at com.nitryx.brkmopt.util.ClojureHandler.invoke(ClojureHandler.java:176)
at com.nitryx.brkmopt.util.ClojureHandler.invoke(ClojureHandler.java:173)
at com.nitryx.brkmopt.CenarioService.$tt__getCenarioJson(CenarioService.groovy:35)
...
The WAR file runs perfectly on server B but throws the exception on server A.
We inspected the ~/WEB-INF/lib/ folder under tomcat, and the necessary dependency (clojure-1.9.0.jar) is there and is consistent. On a desperate action, we have even tried to replace the jar file for a newer one manually, and it did not work.
From Why am I getting a NoClassDefFoundError in Java? :
java.lang.NoClassDefFoundError This exception indicates that the JVM
looked in its internal class definition data structure for the
definition of a class and did not find it. This is different than
saying that it could not be loaded from the classpath. Usually this
indicates that we previously attempted to load a class from the
classpath, but it failed for some reason
Please advise!
Edit:
Full stacktrace: (many thanks to clojurians #jumar #alexmiller #ghadi #seancorfield)
2020-02-05 16:00:02.342 [http-nio-8081-exec-10] ERROR o.g.w.errors.GrailsExceptionResolver - NoClassDefFoundError occurred when processing request: [GET] /server-0.1/cenario/getCenarioJson
Could not initialize class clojure.java.api.Clojure. Stacktrace follows:
org.springframework.web.util.NestedServletException: Handler dispatch failed; nested exception is java.lang.NoClassDefFoundError: Could not initialize class clojure.java.api.Clojure
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:982)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:901)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:970)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:861)
at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:846)
at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:239)
at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:215)
at org.springframework.boot.web.filter.ApplicationContextHeaderFilter.doFilterInternal(ApplicationContextHeaderFilter.java:55)
at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:239)
at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:215)
at org.grails.web.servlet.mvc.GrailsWebRequestFilter.doFilterInternal(GrailsWebRequestFilter.java:77)
at org.grails.web.filters.HiddenHttpMethodFilter.doFilterInternal(HiddenHttpMethodFilter.java:67)
at org.springframework.boot.web.support.ErrorPageFilter.doFilter(ErrorPageFilter.java:130)
at org.springframework.boot.web.support.ErrorPageFilter.access$000(ErrorPageFilter.java:66)
at org.springframework.boot.web.support.ErrorPageFilter$1.doFilterInternal(ErrorPageFilter.java:105)
at org.springframework.boot.web.support.ErrorPageFilter.doFilter(ErrorPageFilter.java:123)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.NoClassDefFoundError: Could not initialize class clojure.java.api.Clojure
at com.nitryx.brkmopt.util.ClojureHandler.invoke(ClojureHandler.java:176)
at com.nitryx.brkmopt.util.ClojureHandler.invoke(ClojureHandler.java:173)
at com.nitryx.brkmopt.CenarioService.$tt__getCenarioJson(CenarioService.groovy:35)
at grails.melody.plugin.MelodyInterceptorEnhancer$_enhance_closure1$_closure2.doCall(MelodyInterceptorEnhancer.groovy:77)
at grails.gorm.transactions.GrailsTransactionTemplate$2.doInTransaction(GrailsTransactionTemplate.groovy:94)
at org.springframework.transaction.support.TransactionTemplate.execute(TransactionTemplate.java:133)
at grails.gorm.transactions.GrailsTransactionTemplate.execute(GrailsTransactionTemplate.groovy:91)
at grails.melody.plugin.MelodyInterceptorEnhancer$_enhance_closure1$_closure2.doCall(MelodyInterceptorEnhancer.groovy:77)
at com.nitryx.brkmopt.CenarioController.getCenarioJson(CenarioController.groovy:20)
at org.grails.core.DefaultGrailsControllerClass$MethodHandleInvoker.invoke(DefaultGrailsControllerClass.java:223)
at org.grails.core.DefaultGrailsControllerClass.invoke(DefaultGrailsControllerClass.java:188)
at org.grails.web.mapping.mvc.UrlMappingsInfoHandlerAdapter.handle(UrlMappingsInfoHandlerAdapter.groovy:90)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:967)
... 18 common frames omitted
It looks like Tomcat 8.5.50 contains a bunch of regression fixes in Catalina with resource loading which may be affecting the loading of Clojure source files. Suggest either downgrading to same as the working one or upgrading to 8.5.50.
https://tomcat.apache.org/tomcat-8.5-doc/changelog.html
When I try to run the script, I get this error. This is a Python script. Does anyone have this problem?
[cloudera-scm#ivana-namenode2 /opt/MapReduce/wordcount]$ pydoop script wc.py /user/cloudera-scm/MapReduce/wordcount/data/text /user/cloudera-scm/MapReduce/wordcount/output
Exception in thread "main" java.lang.UnsupportedClassVersionError: it/crs4/pydoop/mapreduce/pipes/Submitter : Unsupported major.minor version 52.0
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:482)
ERROR - RunCmdError: command exited with 1 status
When you turn to this existing question you find the explanation for the error message: you have some java class that was compiled for Java8.
But the JVM asked to execute that class is older than Java8.
In other words: you have an inconsistent setup. Some part of your environment wants to use something build for Java8, but that part that executes things is running an older version of Java.
So, the answer here is that you have to understand better what your setup is composed of, to either use an "older" version of the underlying library/tool, or to make sure that a Java8 JVM is available to run classes.
I am using AWS SDK to upload files to S3 bucket when set java classpath to "aws-java-sdk-1.10.49.jar", the program works fine, but when replacing jar file to a later version "aws-java-sdk-1.11.35.jar", I get an exception "AmazonServiceException class not found as below."
Exception in thread "main" java.lang.NoClassDefFoundError: com/amazonaws/AmazonServiceException
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2701)
at java.lang.Class.privateGetMethodRecursive(Class.java:3048)
at java.lang.Class.getMethod0(Class.java:3018)
at java.lang.Class.getMethod(Class.java:1784)
at sun.launcher.LauncherHelper.validateMainClass(LauncherHelper.java:544)
at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526)
Caused by: java.lang.ClassNotFoundException: com.amazonaws.AmazonServiceException
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
any help?
here we have three possible problems:
A simple example of NoClassDefFoundError is class belongs to a missing JAR file or JAR was not added into classpath or sometimes jar's name has been changed by someone like in my case one of my colleagues has changed tibco.jar into tibco_v3.jar and the program is failing with java.lang.NoClassDefFoundError and I were wondering what's wrong.
The class is not in Classpath, there is no sure shot way of knowing it but many times you can just have a look to print System.getproperty("java.classpath") and it will print the classpath from there you can at least get an idea of your actual runtime classpath.
Just try to run with explicitly -classpath option with the classpath you think will work and if it's working then it's a sure short sign that someone is overriding java classpath.
Take a look at this article
I'm using the javax.mail library to send emails that may or may not contain attachments.
I'm also using Groovy 2.0.6 for writing this script and am developing it in Eclipse and running unit tests using Gradle 1.5. The script I'm writing will be deployed in a jar to many different locations in the future. Therefore, the javax.mail needs to be referenced to from my script and not just manually added to the machine's classpath.
To do this, I am using the following statements in my script:
#GrabConfig(systemClassLoader=true)
#Grab(group='javax.mail', module='mail', version='1.4.7')
My issue is that I am unable to run unit tests with Gradle while the #GrabConfig statement is included. It runs fine with just the #Grab statement but fails when the #GrabConfig is in there. The error message I'm receiving is:
:compileJava UP-TO-DATE
:compileGroovy
startup failed:
General error during conversion: No suitable ClassLoader found for grab
java.lang.RuntimeException: No suitable ClassLoader found for grab
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:77)
at org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:102)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:57)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:182)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:190)
at groovy.grape.GrapeIvy.chooseClassLoader(GrapeIvy.groovy:181)
at groovy.grape.GrapeIvy$chooseClassLoader.callCurrent(Unknown Source)
at groovy.grape.GrapeIvy.grab(GrapeIvy.groovy:247)
at groovy.grape.Grape.grab(Grape.java:141)
at groovy.grape.GrabAnnotationTransformation.visit(GrabAnnotationTransformation.java:312)
at org.codehaus.groovy.transform.ASTTransformationVisitor$3.call(ASTTransformationVisitor.java:319)
at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:903)
at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:566)
at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:542)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:519)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:498)
at org.gradle.api.internal.tasks.compile.ApiGroovyCompiler.execute(ApiGroovyCompiler.java:118)
at org.gradle.api.internal.tasks.compile.ApiGroovyCompiler.execute(ApiGroovyCompiler.java:39)
at org.gradle.api.internal.tasks.compile.daemon.CompilerDaemonServer.execute(CompilerDaemonServer.java:52)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:355)
at org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:66)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
1 error
:compileGroovy FAILED
FAILURE: Build failed with an exception.
According to No suitable classloader found for grab , #GrabConfig makes code untestable.
Is there any alternative to #GrabConfig for my situation?
You can use the gradle-one-jar plugin to package your own and third-party code into a single executable Jar. Alternatively, you can use Gradle's application plugin to create a Zip distribution with start scripts.
You can disable grapes in build.gradle like so:
test {
systemProperty 'groovy.grape.enable', 'false'
}
compileGroovy {
groovyOptions.forkOptions.jvmArgs = [ '-Dgroovy.grape.enable=false' ]
}
compileTestGroovy {
groovyOptions.forkOptions.jvmArgs = [ '-Dgroovy.grape.enable=false' ]
}
I am new in jetty. I am trying to run Jetty with IKVM. However, it throws exception. I am not sure what should I do.
alex#AlexUbuntu:/usr/share/jetty$ ikvm -jar start.jar
5 [main] INFO org.mortbay.log - Logging to org.slf4j.impl.SimpleLogger(org.mortbay.log) via org.mortbay.log.Slf4jLog
java.lang.reflect.InvocationTargetException
at java.lang.reflect.Method.invoke(Method.java:
at org.mortbay.start.Main.invokeMain(Main.java:179)
at org.mortbay.start.Main.start(Main.java:508)
at org.mortbay.start.Main.start(Main.java:439)
at org.mortbay.start.Main.main(Main.java:99)
Caused by: cli.System.TypeLoadException: Could not load type 'org.apache.xerces.util.NamespaceSupport' from assembly 'ikvm_dynamic_assembly__40326550, Version=2011.611.1039.16726, Culture=neutral, PublicKeyToken=null'.
at org.apache.xerces.parsers.XIncludeAwareParserConfiguration.<init>(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Constructor.java:517)
at java.lang.Class.newInstance0(Class.java:333)
at java.lang.Class.newInstance(Class.java:320)
at org.apache.xerces.parsers.ObjectFactory.newInstance(Unknown Source)
at org.apache.xerces.parsers.ObjectFactory.createObject(Unknown Source)
at org.apache.xerces.parsers.ObjectFactory.createObject(Unknown Source)
at org.apache.xerces.parsers.SAXParser.<init>(Unknown Source)
at org.apache.xerces.parsers.SAXParser.<init>(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.<init>(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl.<init>(Unknown Source)
at org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source)
at org.mortbay.xml.XmlParser.setValidating(XmlParser.java)
at org.mortbay.xml.XmlParser.<init>(XmlParser.java:68)
at org.mortbay.xml.XmlConfiguration.initParser(XmlConfiguration.java)
at org.mortbay.xml.XmlConfiguration.<init>(XmlConfiguration.java:105)
at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:958)
... 5 more
It seems that I need to install some external libraries in order to make it works. But what should I need to install.
The environment is fresh and clean:
Ubuntu 11.04
IKVM 0.40.0.1
Java 1.6.0_22
Mono 2.6.7
Update on 28 June 2010
I think I make it works. But I haven't try loading .NET classes in jetty. By the way, I used a dirty method that I replaced /usr/bin/java and /usr/lib/jvm/default-jvm/java with ikvm.exe. So everytime when I type java that actually is IKVM.
I will try to load .NET classes in jetty. But I am not familiar with jetty so I may take sometime.
Update on 1 July 2010
I have tried to load a .NET class. However, finally I got an error message.
HTTP ERROR 500
Problem accessing /hello/servlet. Reason:
ikvmstub generated stubs can only be used on IKVM.NET
Caused by:
java.lang.UnsatisfiedLinkError: ikvmstub generated stubs can only be used on IKVM.NET
at cli.CSharpClass.<init>(Unknown Source)
at HelloServlet.doPost(HelloServlet.java:28)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)
at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:943)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:756)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
Can you run Jetty with 'java -jar start.jar'?
I suspect you need at least a few base JAR files for jetty even if it's classloader dynamically loads everything that is needed. It looks like it is failing in the log initialization.
Add the xerces JAR file to the classpath when running IKVM.
ikvm -cp .:xerces.jar -jar startup.jar
Update
I just looked through jetty.sh and there are a few things the script file sets up. You'll need to go through that file and determine what you need out of it, or replace all the instances of java with ikvm and be aware that Jetty also uses tools.jar
The jar files that you generate with ikvmstub are only for the java compiler and not for the runtime. The java compiler can nor work with .NET dlls. For the runtime you need to use the dlls directly.
We use the jetty without problems with IKVM but we use a newer version 0.46. The simplest is you build all jar files in one step with a shared classloader. See the ikvm wiki for details.