How to run Jetty on IKVM? - jetty

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.

Related

cannot use google or tools on AWS lambda

I am trying to solve a VRP using google or tools. I use java for my program and everything works fine locally.
After deploying the program on lambda I get an error
java.lang.IllegalArgumentException: Path component should be '/'
2021-08-13T12:40:59.915+04:00 at java.base/sun.nio.fs.UnixFileSystemProvider.checkUri(Unknown Source)
2021-08-13T12:40:59.915+04:00 at java.base/sun.nio.fs.UnixFileSystemProvider.newFileSystem(Unknown Source)
2021-08-13T12:40:59.915+04:00 at java.base/java.nio.file.FileSystems.newFileSystem(Unknown Source)
2021-08-13T12:40:59.915+04:00 at java.base/java.nio.file.FileSystems.newFileSystem(Unknown Source)
2021-08-13T12:40:59.916+04:00 at com.google.ortools.Loader.unpackNativeResources(Loader.java:88)
2021-08-13T12:40:59.916+04:00 at com.google.ortools.Loader.loadNativeLibraries(Loader.java:106)
this is caused by Loader.loadNativeLibraries() method call.
I built the jar package using maven with shade plugin.
I am using Ubuntu 20.04 if that is related.
I use com.google.ortools:ortools-java
Thank you in advance.
UPDATE :
I manually downloaded native library files and put the full path with System.load(path) . This gave the following error when executing on Lambda
Can't load library: /var/task/src/main/resources/darwin-x86-64/libjniortools.so: java.lang.UnsatisfiedLinkError
java.lang.UnsatisfiedLinkError: Can't load library: /var/task/src/main/resources/darwin-x86-64/libjniortools.so

WSO2 Developer Studio 3.6 creating car file fail

On a completely fresh install of Developer Studio 3.6 (not the plugin) I have created a very simple ESB config project and tried to create a car from the pom editor (using the button in the top right hand corner (as per doc). I get a failure message in the UI "an error occurred while creating the carbon archive file. For more details view the log". The log just shows "java.io.FileNotFoundException: C:\wso2workspace\AthenaHRInterfaceApplication\target\AthenaHRInterfaceApplication_0.1.car (The system cannot find the file specified)".
If I view the target directory as I do this, one can see the file created halfway through the process (i.e. when selecting which directory to save .car file to), but then on completion (ie. OK button), the error is displayed and the file size of .car file goes to 0kb
This is really frustrating and doesn't seem to make any sense. I did get this to work (not with this project) before, but this one just doesn't want to play ball. I can get the car file to be generated external to Dev Studio through maven, but then it isn't deployable from within Studio and appears to be affected by the above error in any case.
Any suggestions to where I may be going wrong?
This is the stacktrace in my log file...
!ENTRY org.wso2.developerstudio.eclipse.distribution.project 4 0 2014-05-14 08:55:30.677
!MESSAGE An error occured while creating the carbon archive file
!STACK 0
java.io.FileNotFoundException: C:\wso2workspace\AthenaHRInterfaceApplication\AthenaHRInterfaceCAP\target\AthenaHRInterfaceCAP_0.1.car (The system cannot find the file specified)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.(FileInputStream.java:146)
at org.wso2.developerstudio.eclipse.utils.file.FileUtils.copy(FileUtils.java:227)
at org.wso2.developerstudio.eclipse.distribution.project.editor.DistProjectEditorPage.exportCar(DistProjectEditorPage.java:791)
at org.wso2.developerstudio.eclipse.distribution.project.editor.DistProjectEditorPage$8.run(DistProjectEditorPage.java:755)
at org.eclipse.jface.action.Action.runWithEvent(Action.java:499)
at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:584)
at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:501)
at org.eclipse.jface.action.ActionContributionItem$6.handleEvent(ActionContributionItem.java:452)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1057)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4170)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3759)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine$9.run(PartRenderingEngine.java:1113)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.e4.ui.internal.workbench.swt.PartRenderingEngine.run(PartRenderingEngine.java:997)
at org.eclipse.e4.ui.internal.workbench.E4Workbench.createAndRunUI(E4Workbench.java:140)
at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:611)
at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:567)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:150)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:124)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:354)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:181)
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:606)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591)
at org.eclipse.equinox.launcher.Main.run(Main.java:1450)
at org.eclipse.equinox.launcher.Main.main(Main.java:1426)
is this a bug - it looks like it. Happens with a fresh install of DS and new project.
Not that anyone appears to be following this other than the on comments on java version, but for the sake of completeness, I will keep adding to this thread.
It appears that the error was being caused by me selecting the location of the 'target' directory, I suspect that behind the scenes DS is using the same location (as in maven) which is trying to write to the same directory with the same file name which is causing the file not found exception. Saving to a different directory appears to at least get past this error. However, the new issue I have is that Registry Resources aren't being included in the resultant .car file using the button at the top right hand corner of the Composite Application POM editor. If I mvn install (from either command line or from Run(ing) the pom within DS, the correct .car file is generated.
I think I should create another thread with this specific issue and answer this one myself.
Views?

J2EE :[Bad version number in .class file]

I have deleted the earlier class and .ear-files, cleaned the workspace, compiled the code with JavaSE 1.6, set the system library to 1.6 then compiled and created the .ear. I am getting this error when I have installed the ear on server and try to open with url:
WebApp E [Servlet Error]-[Bad version number in .class file]: java.lang.UnsupportedClassVersionError: Bad version number in .class file
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at com.ibm.ws.classloader.CompoundClassLoader._defineClass(CompoundClassLoader.java:577)
at com.ibm.ws.classloader.CompoundClassLoader.findClass(CompoundClassLoader.java:529)
at com.ibm.ws.classloader.CompoundClassLoader.loadClass(CompoundClassLoader.java:403)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at com.ibm.ws.jsp.webcontainerext.JSPExtensionClassLoader._loadClass(JSPExtensionClassLoader.java:103)
at com.ibm.ws.jsp.webcontainerext.JSPExtensionClassLoader.loadClass(JSPExtensionClassLoader.java:70)
at com.ibm.ws.jsp.webcontainerext.JSPExtensionClassLoader.loadClass(JSPExtensionClassLoader.java:52)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
This error happens when your VM has another version (a lesser version) than the compiled class files.
Could it be that your server still run with java 1.5?

Any alternative to #GrabConfig?

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' ]
}

jetty throws exception after `java -jar start.jar`

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.