I am getting below error when I executing my JUnit test case. I am using Expectations plugin for Grails Domain Test case.
BuildConfig.groovy file code:
plugins {
compile ":domain-expectations:0.6.1"
}
Error which I am getting:
java.lang.ExceptionInInitializerError
at org.codehaus.groovy.runtime.InvokerHelper.<clinit>(InvokerHelper.java:61)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.createCallStaticSite(CallSiteArray.java:72)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.createCallSite(CallSiteArray.java:159)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
at com.lonecyprus.grails.test.Specification.<clinit>(Specification.groovy)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at junit.framework.TestSuite.createTest(TestSuite.java:63)
at junit.framework.TestSuite.addTestMethod(TestSuite.java:310)
at junit.framework.TestSuite.addTestsFromTestCase(TestSuite.java:153)
at junit.framework.TestSuite.<init>(TestSuite.java:132)
at org.junit.internal.runners.JUnit38ClassRunner.<init>(JUnit38ClassRunner.java:72)
at org.junit.internal.builders.JUnit3Builder.runnerForClass(JUnit3Builder.java:11)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:26)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:59)
at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:26)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.<init>(JUnit4TestReference.java:33)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestClassReference.<init>(JUnit4TestClassReference.java:25)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.createTest(JUnit4TestLoader.java:48)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.loadTests(JUnit4TestLoader.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:444)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)
Caused by: groovy.lang.GroovyRuntimeException: Conflicting module versions. Module [groovy-all is loaded in version 2.3.10 and you are trying to load version 2.3.7
at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl$DefaultModuleListener.onModule(MetaClassRegistryImpl.java:509)
at org.codehaus.groovy.runtime.m12n.ExtensionModuleScanner.scanExtensionModuleFromProperties(ExtensionModuleScanner.java:77)
at org.codehaus.groovy.runtime.m12n.ExtensionModuleScanner.scanExtensionModuleFromMetaInf(ExtensionModuleScanner.java:71)
at org.codehaus.groovy.runtime.m12n.ExtensionModuleScanner.scanClasspathModules(ExtensionModuleScanner.java:53)
at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.<init>(MetaClassRegistryImpl.java:110)
at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.<init>(MetaClassRegistryImpl.java:71)
at groovy.lang.GroovySystem.<clinit>(GroovySystem.java:33)
... 29 more
It means that you have 2 versions of Groovy on classpath: 2.3.10 and 2.3.7. One is probably brought by Grails while the other is by the plugin, which means they are incompatible. You should try to exclude Groovy from the plugin dependency.
maybe you had use groovy in two different denpendencies. For example : in com.jayway.restassured and io.rest-assured, both of them include groovy-xml.
For this 1st of you have chack the version of groovy in Maven Dependencies library and Built path. Version of groovy should be match so that this error will go else error will come because of version conflict.
Related
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'm trying to write a test for a Webservice using the approach described at http://antoniogoncalves.org/2012/10/24/no-you-dont-need-to-mock-your-soap-web-service-to-test-it/
But on calling Endpoint.publish I get the following exception
java.lang.NoClassDefFoundError: com.ibm.ffdc.impl.Ffdc
at com.ibm.ffdc.Manager.<clinit>(Unknown Source)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:235)
at com.ibm.ws.ffdc.FFDCFilter.processException(FFDCFilter.java:82)
at com.ibm.ws.webservices.engine.components.logger.LogFactory$2.run(LogFactory.java:159)
at com.ibm.ws.security.util.AccessController.doPrivileged(AccessController.java:63)
at com.ibm.ws.webservices.engine.components.logger.LogFactory.createLogFactory(LogFactory.java:141)
at com.ibm.ws.webservices.engine.components.logger.LogFactory.<clinit>(LogFactory.java:98)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:235)
at com.ibm.ws.webservices.engine.soap.MessageFactoryImpl.<clinit>(MessageFactoryImpl.java:103)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:235)
at com.ibm.ws.webservices.engine.soap.SAAJMetaFactoryImpl.newMessageFactory(SAAJMetaFactoryImpl.java:56)
at javax.xml.soap.MessageFactory.newInstance(MessageFactory.java:143)
at com.sun.xml.internal.ws.api.SOAPVersion.<init>(SOAPVersion.java:179)
at com.sun.xml.internal.ws.api.SOAPVersion.<clinit>(SOAPVersion.java:84)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:235)
at com.sun.xml.internal.ws.api.BindingID.<clinit>(BindingID.java:336)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:235)
at com.sun.xml.internal.ws.spi.ProviderImpl.createAndPublishEndpoint(ProviderImpl.java:104)
at javax.xml.ws.Endpoint.publish(Endpoint.java:181)
at <junit stuff>
Caused by: java.lang.ClassNotFoundException: com.ibm.ffdc.impl.Ffdc
at java.net.URLClassLoader.findClass(URLClassLoader.java:434)
at java.lang.ClassLoader.loadClassHelper(ClassLoader.java:701)
at java.lang.ClassLoader.loadClass(ClassLoader.java:680)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:358)
at java.lang.ClassLoader.loadClass(ClassLoader.java:663)
... 48 more
Which is I assume because I'm running in an IBM JRE (Websphere 8.0.x) (Thx for the condolence)
Can I use Endpoint.publish in a IBM JRE, without starting a complete Websphere?
The test or the JRE configuration that produced this stack trace has somehow included com.ibm.ws classes that are shipped with Websphere. If you have removed all reference to Websphere classes from your test, then you could get a standalone JRE with no Websphere changes to test with. You can download for AIX, Linux or z/OS from:
https://www.ibm.com/developerworks/java/jdk/
I'm having a painful time resolving a Camel-CXF ClassNotFoundException. I've included a sample program exhibiting the problem
You can find the source code at:
git#bitbucket.org:levonk/camel-cxf-example.git
To run the program after checking out the project run:
mvn test exec:java
Here is the exception stack trace:
Caused by: org.apache.camel.FailedToCreateRouteException: Failed to create route route1: Route(route1)[[From[cxf://http://www.webservicex.net/globalw... because of Failed to resolve endpoint: cxf://http://www.webservicex.net/globalweather.asmx/GetWeather?publishedEndpointUrl=http%3A%2F%2Fwww.webservicex.net%2Fglobalweather.asmx&serviceClass=net.webservicex.GlobalWeather.class due to: net.webservicex.GlobalWeather.class
at org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:181)
at org.apache.camel.impl.DefaultCamelContext.startRoute(DefaultCamelContext.java:750)
at org.apache.camel.impl.DefaultCamelContext.startRouteDefinitions(DefaultCamelContext.java:1829)
at org.apache.camel.impl.DefaultCamelContext.doStartCamel(DefaultCamelContext.java:1609)
at org.apache.camel.impl.DefaultCamelContext.doStart(DefaultCamelContext.java:1478)
at org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61)
at org.apache.camel.impl.DefaultCamelContext.start(DefaultCamelContext.java:1446)
at org.apache.camel.main.Main.doStart(Main.java:109)
at org.apache.camel.support.ServiceSupport.start(ServiceSupport.java:61)
at org.apache.camel.main.MainSupport.run(MainSupport.java:148)
at org.apache.camel.main.MainSupport.run(MainSupport.java:343)
at com.levonk.app.example.camel.MainApp.main(MainApp.java:17)
... 6 more
Caused by: org.apache.camel.ResolveEndpointFailedException: Failed to resolve endpoint: cxf://http://www.webservicex.net/globalweather.asmx/GetWeather?publishedEndpointUrl=http%3A%2F%2Fwww.webservicex.net%2Fglobalweather.asmx&serviceClass=net.webservicex.GlobalWeather.class due to: net.webservicex.GlobalWeather.class
at org.apache.camel.impl.DefaultCamelContext.getEndpoint(DefaultCamelContext.java:508)
at org.apache.camel.util.CamelContextHelper.getMandatoryEndpoint(CamelContextHelper.java:62)
at org.apache.camel.model.RouteDefinition.resolveEndpoint(RouteDefinition.java:191)
at org.apache.camel.impl.DefaultRouteContext.resolveEndpoint(DefaultRouteContext.java:108)
at org.apache.camel.impl.DefaultRouteContext.resolveEndpoint(DefaultRouteContext.java:114)
at org.apache.camel.model.FromDefinition.resolveEndpoint(FromDefinition.java:72)
at org.apache.camel.impl.DefaultRouteContext.getEndpoint(DefaultRouteContext.java:90)
at org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:861)
at org.apache.camel.model.RouteDefinition.addRoutes(RouteDefinition.java:176)
... 17 more
Caused by: java.lang.ClassNotFoundException: net.webservicex.GlobalWeather.class
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
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:423)
at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
at org.apache.cxf.common.classloader.ClassLoaderUtils.loadClass2(ClassLoaderUtils.java:287)
at org.apache.cxf.common.classloader.ClassLoaderUtils.loadClass(ClassLoaderUtils.java:261)
at org.apache.camel.component.cxf.CxfEndpoint.setServiceClass(CxfEndpoint.java:653)
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:601)
at org.apache.camel.util.IntrospectionSupport.setProperty(IntrospectionSupport.java:492)
at org.apache.camel.util.IntrospectionSupport.setProperty(IntrospectionSupport.java:546)
at org.apache.camel.util.IntrospectionSupport.setProperties(IntrospectionSupport.java:434)
at org.apache.camel.util.EndpointHelper.setProperties(EndpointHelper.java:249)
at org.apache.camel.impl.DefaultComponent.setProperties(DefaultComponent.java:258)
at org.apache.camel.component.cxf.CxfComponent.createEndpoint(CxfComponent.java:84)
at org.apache.camel.impl.DefaultComponent.createEndpoint(DefaultComponent.java:119)
at org.apache.camel.impl.DefaultCamelContext.getEndpoint(DefaultCamelContext.java:488)
... 25 more
This is an issue with the maven Exec Maven plugin not picking up the classes generated from your WSDL at runtime.
The correct way to do structure this sort of thing in Maven is to separate your WSDL -> Java generation out into a seperate project, and add a dependency on that project in your cxf-client. This way, the generated code is just a dependency like any other. See https://github.com/FuseByExample/smx-ws-examples for an example of how to do this.
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.