In Jetty 8 I was passing values like -Djetty.port=8888 -DSTOP.PORT=8887 -DSTOP.KEY=STOP but in Jetty 9 these don't seem to work.
I am able to set the port with --module=http jetty.port=8888 but am not sure how to set the other values?
Also, I used to use the command java -DSTOP.PORT=8887 -DSTOP.KEY=STOP -jar start.jar --stop but am not sure how to run the stop command now?
The docs at http://www.eclipse.org/jetty/documentation/current/start-jar.html#d0e8360 suggest that stopping hasn't changed, but when I try that I get
java.net.ConnectException: Connection refused: connect
at java.net.DualStackPlainSocketImpl.connect0(Native Method)
at java.net.DualStackPlainSocketImpl.socketConnect(Unknown Source)
at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source)
at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source)
at java.net.AbstractPlainSocketImpl.connect(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.<init>(Unknown Source)
at java.net.Socket.<init>(Unknown Source)
at org.eclipse.jetty.start.Main.stop(Main.java:761)
at org.eclipse.jetty.start.Main.stop(Main.java:740)
at org.eclipse.jetty.start.Main.start(Main.java:648)
at org.eclipse.jetty.start.Main.main(Main.java:103)
Usage: java -jar start.jar [options] [properties] [configs]
java -jar start.jar --help # for more information
TIA
I have experienced the same problem, but found it has always been an overlooked mistake on my part. With that being said, I think you are actually on the right track.
This should work
With
jetty-distribution-9.2.7.v20150116
the following sequence does work:
# setting up jetty config
java -jar mypath/start.jar --add-to-startd=http,deploy
# check to see if the ports are available
netstat -tapn | grep "808[07]"
# starting server
java -DSTOP.PORT=8087 -DSTOP.KEY=STOP -jar mypath/start.jar
# check to see if the ports are now monitored
netstat -tapn | grep "808[07]"
# starting server
java -DSTOP.PORT=8087 -DSTOP.KEY=STOP -jar mypath/start.jar --stop
# check to see if the ports are now free
netstat -tapn | grep "808[07]"
Preferred syntax
The above -D syntax works, but the following syntax is better supported:
java -jar mypath/start.jar STOP.PORT=8087 STOP.KEY=STOP
java -jar mypath/start.jar STOP.PORT=8087 STOP.KEY=STOP --stop
java -jar mypath/start.jar STOP.PORT=8087 STOP.KEY=STOP --list-config
java -jar mypath/start.jar STOP.PORT=8087 STOP.KEY=STOP --dry-run
You can easily confirm that this syntax does work by trying it.
Additional steps
Those last two commands (--list-config and --dry-run) can be very handy for checking a variety of problems.
The --help command is also very useful to sanity checking odd problems like this. It does reveal nuances like the above preferred syntax that you found difficult to find:
java -jar mypath/start.jar --help
If you've already tried these steps, try upgrading to a newer version of Jetty in case the problem you experienced was an actually bug that was subsequently fixed.
If it still doesn't work, I'll try to help you and update this "answer" appropriately.
Related
I'm trying to run the sample program here http://docs.aws.amazon.com/ses/latest/DeveloperGuide/send-using-smtp-java.html
here's the command output...
$ java AmazonSESSample -cp "javamail-1.4.3/mail.jar"
java.lang.NoClassDefFoundError: javax/mail/Address
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)
atsun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:526)
Caused by: java.lang.ClassNotFoundException: javax.mail.Address
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)
... 7 more
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main"
I tried to Google for answers by using this search string...
search string = java mail.jar "Error: A JNI error has occurred, please check your installation and try again"
i didn't see anything useful in the search results :-(
Any ideas?
I think the JAR file (javamail-1.4.3/mail.jar) you indicated is not being found..
java AmazonSESSample -cp "javamail-1.4.3/mail.jar"
Try providing the full path like below (below is an example only)
java AmazonSESSample -cp "/usr/lib/javamail-1.4.3/mail.jar"
UPDATE: On Windows try the below
java AmazonSESSample -classpath "C:\Users\MichaelDocuments\GitHub\guesstimate\scratch\javamail-1.4.3\mail.jar"
Ok so the answer is that the classpath option was AFTER the main class. So the -cp and jar value are being passed as 'args' to the 'main' method - doh!!!!!!!!!!!!!!
By simply moving this option as shown below, the jar is loaded and the class is found as expected..
A useful outcome of this frustrating puzzle is that i discovered '-verbose:class' which will be useful for other problems in the future i'm sure :)
$ java -verbose:class -cp '.;mail.jar' AmazonSESSample | grep Session
[Loaded javax.mail.Session from file:/C:/Users/Michael/Documents/GitHub/guesstimate/scratch/mail.jar]
[Loaded javax.mail.Session$1 from file:/C:/Users/Michael/Documents/GitHub/guesstimate/scratch/mail.jar]
[Loaded javax.mail.Session$3 from file:/C:/Users/Michael/Documents/GitHub/guesstimate/scratch/mail.jar]
[Loaded javax.mail.Session$5 from file:/C:/Users/Michael/Documents/GitHub/guesstimate/scratch/mail.jar]
[Loaded javax.mail.Session$4 from file:/C:/Users/Michael/Documents/GitHub/guesstimate/scratch/mail.jar]
[Loaded javax.mail.Session$2 from file:/C:/Users/Michael/Documents/GitHub/guesstimate/scratch/mail.jar]
Michael#mikeToshSpare /cygdrive/c/Users/Michael/Documents/GitHub/guesstimate/scratch
$ java -verbose:class AmazonSESSample -cp '.;mail.jar' | grep Session
Exception in thread "main" java.lang.NoClassDefFoundError: javax/mail/Session
at AmazonSESSample.main(AmazonSESSample.java:56)
Caused by: java.lang.ClassNotFoundException: javax.mail.Session
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)
... 1 more
When I try to import a webservice I get the following output:
ant -f /home/bence/NetBeansProjects/WebClient wsimport-client-clean-AdminService_1 wsimport-client-generate
wsimport-client-clean-AdminService_1:
Deleting directory /home/bence/NetBeansProjects/WebClient/build/generated/jax-wsCache/AdminService_1
init:
wsimport-init:
wsimport-client-AdminService_1:
Created dir: /home/bence/NetBeansProjects/WebClient/build/generated/jax-wsCache/AdminService_1
command line: wsimport -d /home/bence/NetBeansProjects/WebClient/build/generated/jax-wsCache/AdminService_1 -extension -Xnocompile -Xendorsed -keep -s /home/bence/NetBeansProjects/WebClient/build/generated/jax-wsCache/AdminService_1 -encoding UTF-8 -catalog /home/bence/NetBeansProjects/WebClient/catalog.xml -verbose /home/bence/NetBeansProjects/WebClient/xml-resources/web-service-references/AdminService_1/wsdl/localhost_8084/WebFormsTest/AdminService.wsdl -p org.czentral.test.service -wsdllocation http://localhost:8084/WebFormsTest/AdminService?wsdl
parsing WSDL...
/home/bence/NetBeansProjects/WebClient/nbproject/jaxws-build.xml:22:
java.lang.NoClassDefFoundError: com/sun/tools/xjc/Plugin
at java.lang.ClassLoader.findBootstrapClass(Native Method)
at java.lang.ClassLoader.findBootstrapClassOrNull(ClassLoader.java:1058)
at java.lang.ClassLoader.loadClass(ClassLoader.java:413)
at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at org.apache.tools.ant.AntClassLoader.findBaseClass(AntClassLoader.java:1385)
at org.apache.tools.ant.AntClassLoader.loadClass(AntClassLoader.java:1064)
at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
at com.sun.istack.tools.MaskingClassLoader.loadClass(MaskingClassLoader.java:82)
at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
at java.lang.ClassLoader.loadClass(ClassLoader.java:411)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:270)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:363)
at java.util.ServiceLoader$1.next(ServiceLoader.java:445)
at com.sun.tools.xjc.Options.findServices(Options.java:952)
at com.sun.tools.xjc.Options.getAllPlugins(Options.java:374)
at com.sun.tools.xjc.reader.AbstractExtensionBindingChecker.<init>(AbstractExtensionBindingChecker.java:100)
at com.sun.tools.xjc.reader.ExtensionBindingChecker.<init>(ExtensionBindingChecker.java:81)
at com.sun.tools.xjc.ModelLoader$XMLSchemaParser.parse(ModelLoader.java:265)
at com.sun.xml.xsom.impl.parser.NGCCRuntimeEx.parseEntity(NGCCRuntimeEx.java:347)
at com.sun.xml.xsom.impl.parser.ParserContext.parse(ParserContext.java:128)
at com.sun.xml.xsom.impl.parser.ParserContext.<init>(ParserContext.java:100)
at com.sun.xml.xsom.parser.XSOMParser.<init>(XSOMParser.java:110)
at com.sun.tools.xjc.ModelLoader.createXSOMParser(ModelLoader.java:431)
at com.sun.tools.xjc.ModelLoader.createXSOMParser(ModelLoader.java:439)
at com.sun.tools.xjc.ModelLoader.createXSOM(ModelLoader.java:521)
at com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImpl.java:268)
at com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImpl.java:94)
at com.sun.tools.ws.processor.modeler.wsdl.JAXBModelBuilder.bind(JAXBModelBuilder.java:142)
at com.sun.tools.ws.processor.modeler.wsdl.WSDLModeler.buildJAXBModel(WSDLModeler.java:2244)
at com.sun.tools.ws.processor.modeler.wsdl.WSDLModeler.internalBuildModel(WSDLModeler.java:191)
at com.sun.tools.ws.processor.modeler.wsdl.WSDLModeler.buildModel(WSDLModeler.java:137)
at com.sun.tools.ws.wscompile.WsimportTool.buildWsdlModel(WsimportTool.java:381)
at com.sun.tools.ws.wscompile.WsimportTool.run(WsimportTool.java:198)
at com.sun.tools.ws.wscompile.WsimportTool.run(WsimportTool.java:179)
at com.sun.tools.ws.ant.WsImport2.execute(WsImport2.java:835)
at com.sun.istack.tools.ProtectedTask.execute(ProtectedTask.java:103)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
at sun.reflect.GeneratedMethodAccessor59.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:435)
at org.apache.tools.ant.Target.performTasks(Target.java:456)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1393)
at org.apache.tools.ant.Project.executeTarget(Project.java:1364)
at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1248)
at org.apache.tools.ant.module.bridge.impl.BridgeImpl.run(BridgeImpl.java:286)
at org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:555)
at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:153)
BUILD FAILED (total time: 1 second)
I looked around and everything seems OK:
The project's Libraries include JAXB 2.2.5 - jaxb-xjc.jar which indeed contains the class in question.
My jaxws-build.xml contains a classpath ${libs.jaxws21.classpath}
The value of libs.jaxws21.classpath defined in ~/.netbeans/8.0/build.properties has a valid value, containing correct access to jaxb-xjc.jar
When I manually run the wsimport command displayed above it gives unrecognized parameter -encoding (an other version is run maybe in: /usr/bin/wsimport). With this parameter removed it works and generates the .java files. Manually moving them to build/generated-sources/jax-ws will let me compile the project.
I'm using Netbeans 8 (just installed) with Java 7 (openjdk-7-jdk) , I removed any previous versions (configurations moved to backup).
I'm pretty much out of ideas. Anyone else having the same problem? Are there any other settings I can check?
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.
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.
I can't seem to find a way to launch the Clojure REPL with the contrib library included. If I understood the documentation correctly then this command should do it:
C:\clojure-1.1.0>"%ProgramFiles%\Java\jre6\bin\java.exe" -cp clojure.jar:clojure
-contrib.jar clojure.main
Exception in thread "main" java.lang.NoClassDefFoundError: clojure/main
Caused by: java.lang.ClassNotFoundException: clojure.main
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
Could not find the main class: clojure.main. Program will exit.
But as you can see, it fails. I did copy the clojure-contrib.jar to the C:\clojure-1.1.0 folder.
Can someone help me get it right?
Update
Thanks to MichaĆ's post I noticed that my error was using a colon where I had to use a semi-colon. This works:
C:\clojure-1.1.0>"%ProgramFiles%\Java\jre6\bin\java.exe" -cp clojure.jar;clojure-contrib.jar clojure.main
Clojure 1.1.0
user=>
(Answer updated to make the actual solution explicit, whereas it was somewhat hidden in the original...)
The classpath string on Windows uses ; as the separator. E.g.
java.exe -cp "C:\clojure-1.1.0\clojure.jar;C:\clojure-1.1.0\clojure-contrib.jar" clojure.main
Alternatively, you can use a wildcard to include all jars in the given directory in the classpath (that's a JDK 1.6 addition, wouldn't work with 1.5):
java.exe -cp "C:\clojure-1.1.0\*" clojure.main
(I think using double quotes here is ok in Windows, can't check though...)