I've just upped to Jetty 9 from 8 and have an odd issue. My development environment is an exploded war, so I simply drop a symlink (ROOT) into my jetty/webapps directory pointing to my exploded war. This worked just fine for Jetty 8, but seems to fail for Jetty 9.
First, the symlink is now 'root', per the documentation. But when I hit my server '/' it gives me a 404 and this:
Error 404 - Not Found.
No context on this server matched or handled this request.
Contexts known to this server are:
/war ---> o.e.j.w.WebAppContext#613714d3{/war,file:/home/george/git/s/web_app/war/,AVAILABLE}{/home/george/git/s/web_app/war}
meaning that I can find my application served under '/war' instead of just '/'. Wacky.
This is due to a host of changes, mainly pointing at the use of Java 7 and requirements for the more recent Servlet specs.
Easy enough to fix for your situation tho.
Don't use OS symlinks.
Create a file called ${jetty.home}/webapps/mywebapp.xml with the following contents
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN"
"http://www.eclipse.org/jetty/configure_9_0.dtd">
<Configure class="org.eclipse.jetty.webapp.WebAppContext">
<Set name="contextPath">/</Set>
<Set name="war">/home/george/git/s/web_app/war/</Set>
</Configure>
All done, you are now essentially using a Jetty Deployable XML Descriptor which sets the contextPath to / (aka Servlet Spec Root) and pointing to the war that you want to deploy.
Related
I am using Jetty 9.3.9.v20160517 in my embedded application, and I have configured the logging using jetty-requestlog.xml like so:
<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure_9_3.dtd">
<!-- =============================================================== -->
<!-- Configure the Jetty Request Log -->
<!-- =============================================================== -->
<Configure id="Server" class="org.eclipse.jetty.server.Server">
<!-- =========================================================== -->
<!-- Configure Request Log for Server -->
<!-- (Use RequestLogHandler for a context specific RequestLog -->
<!-- =========================================================== -->
<Set name="RequestLog">
<New id="RequestLog" class="org.eclipse.jetty.server.AsyncNCSARequestLog">
<Set name="filename"><Property name="jetty.base" default="." /><Property>
<Name>jetty.requestlog.filePath</Name>
<Deprecated>requestlog.filename</Deprecated>
<Default><Property name="jetty.requestlog.dir" default="/logs"/>/yyyy_mm_dd.request.log</Default>
</Property>
</Set>
<Set name="filenameDateFormat"><Property name="jetty.requestlog.filenameDateFormat" deprecated="requestlog.filenameDateFormat" default="yyyy_MM_dd"/></Set>
<Set name="retainDays"><Property name="jetty.requestlog.retainDays" deprecated="requestlog.retain" default="90"/></Set>
<Set name="append"><Property name="jetty.requestlog.append" deprecated="requestlog.append" default="true"/></Set>
<Set name="extended"><Property name="jetty.requestlog.extended" deprecated="requestlog.extended" default="false"/></Set>
<Set name="logCookies"><Property name="jetty.requestlog.cookies" deprecated="requestlog.cookies" default="false"/></Set>
<Set name="LogTimeZone"><Property name="jetty.requestlog.timezone" deprecated="requestlog.timezone" default="GMT"/></Set>
</New>
</Set>
</Configure>
However, at runtime when Jetty actually tries to log anything I get the following NPE each time I make a request to the server, even though the logs do seem to be written to $jetty.base/logs/2016_06_15.request.log.
2016-06-15 22:19:23,302 [eXistThread-29] WARN (HttpChannel.java [handle]:479) - //localhost:8080/exist/apps/dashboard/modules/get-icon.xql?package=http://exist-db.org/apps/eXide
java.lang.NullPointerException
at org.eclipse.jetty.server.RequestLogCollection.log(RequestLogCollection.java:44) ~[jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
at org.eclipse.jetty.server.HttpChannel.onCompleted(HttpChannel.java:620) ~[jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:453) [jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:253) [jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:273) [jetty-io-9.3.9.v20160517.jar:9.3.9.v20160517]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:95) [jetty-io-9.3.9.v20160517.jar:9.3.9.v20160517]
at org.eclipse.jetty.io.SelectChannelEndPoint$2.run(SelectChannelEndPoint.java:93) [jetty-io-9.3.9.v20160517.jar:9.3.9.v20160517]
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.executeProduceConsume(ExecuteProduceConsume.java:303) [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.produceConsume(ExecuteProduceConsume.java:148) [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
at org.eclipse.jetty.util.thread.strategy.ExecuteProduceConsume.run(ExecuteProduceConsume.java:136) [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:671) [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:589) [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
at java.lang.Thread.run(Thread.java:745) [?:1.8.0_92]
So... What is causing these NPE's and how do I fix them please?
Your XML load order is bad (see etc/enabled-jetty-config in your source)
I mentioned this in an earlier answer.
Here's a way you can see how this order works.
Use the jetty-distribution :-)
# Use a new empty base
$ cd /path/to/mybase
# Lets add the modules into this base
$ java -jar /path/to/jetty-dist/start.jar --add-to-start=annotations,deploy,https,gzip,jmx,requestlog
INFO: server initialised (transitively) in ${jetty.base}/start.ini
INFO: gzip initialised in ${jetty.base}/start.ini
INFO: jmx initialised in ${jetty.base}/start.ini
INFO: requestlog initialised in ${jetty.base}/start.ini
INFO: ssl initialised (transitively) in ${jetty.base}/start.ini
INFO: https initialised in ${jetty.base}/start.ini
INFO: deploy initialised in ${jetty.base}/start.ini
INFO: annotations initialised in ${jetty.base}/start.ini
MKDIR: ${jetty.base}/logs
DOWNLOAD: https://raw.githubusercontent.com/eclipse/jetty.project/master/jetty-server/src/test/config/etc/keystore?id=master to ${jetty.base}/etc/keystore
MKDIR: ${jetty.base}/webapps
INFO: Base directory was modified
# Lets ask the jetty-distribution what its XML load order is
java -jar /path/to/jetty-dist/start.jar --list-config
...(snip lots of output)...
Jetty Active XMLs:
------------------
${jetty.home}/etc/jetty.xml
${jetty.home}/etc/jetty-gzip.xml
${jetty.home}/etc/jetty-jmx.xml
${jetty.home}/etc/jetty-requestlog.xml
${jetty.home}/etc/jetty-ssl.xml
${jetty.home}/etc/jetty-ssl-context.xml
${jetty.home}/etc/jetty-https.xml
${jetty.home}/etc/jetty-deploy.xml
${jetty.home}/etc/jetty-plus.xml
${jetty.home}/etc/jetty-annotations.xml
Note: this load order can (and does!) change between releases of Jetty.
Don't rely on this being the one true load order for all versions of Jetty going forward. You'll either have to implement the same start.jar module logic, or redo this jetty-distribution/start.jar --list-config with each upgrade of your project.
WARNING: Don't do this, don't mix jetty-distribution and embedded-jetty, you are just creating lots of extra work for yourself, increasing your maintenance tasks, etc. Use embedded-jetty *or* jetty-distribution directly.
I am using Solr which comes with Jetty by default. The solr.war is deployed using the following configuration in the solr-jetty-context.xml file
<Configure class="org.eclipse.jetty.webapp.WebAppContext">
<Set name="contextPath"><SystemProperty name="hostContext" default="/solr"/></Set>
<Set name="war"><SystemProperty name="jetty.home"/>/webapps/solr.war</Set>
<Set name="defaultsDescriptor"><SystemProperty name="jetty.home"/>/etc/webdefault.xml</Set>
<Set name="tempDirectory"><Property name="jetty.home" default="."/>/solr-webapp</Set>
</Configure>
Now I want to deploy a custom html page say "home.html" on the same jetty server. How can I make sure that the "home.html" page and the solr.war both are deployed on jetty at the same time. I tried placing home.html in the webapps folder but it does not work.
Put home.html into a .war named root.war and deploy. Your home.html file will be available at http://.../home.html while Solr will still be http://.../solr/.
For reference, see http://wiki.eclipse.org/Jetty/Howto/Deploy_Web_Applications.
When I'm deploying my app by copying it inside jetty/webapps it deploys ok. But I want to deploy it from external directory. For that I've created following myconf.xml:
<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure_9_0.dtd">
<Configure id="myapp" class="org.eclipse.jetty.webapp.WebAppContext">
<Set name="server">
<Ref refid="Server" />
</Set>
<Set name="contextPath">/myapp</Set>
<Set name="war">
<SystemProperty name="myapp.war" /><!-- points to the external war -->
</Set>
</Configure>
Then jetty is ran with:
java -XX:-UseSplitVerifier -jar start.jar myconf.xml.
In the console I see that application is being deployed, it accesses db etc, but when I try to reach it I got 404. Any help is highly appreciated :)
Best regards, Eugene.
That's not how you use Jetty.
Option 1: Standard Automatic Deployment
Since you are not customizing anything with the deployment, just delete the myconf.xml entirely.
Copy your myapp.war into the ${jetty.home}/webapps/ directory.
Start Jetty. $ java -jar start.jar
This is known as Automatic Web Application Deployment.
Option 2: Standard Context Deployment
Now, if you want to customize the deployment, (say for example you want to tweak the context path it listens on, or if you want to disable the extractWar process, or you have custom init parameters, or you even want to change the behavior of the Default servlet, etc...), then do the following ...
Copy your existing myconf.xml to ${jetty.home}/webapps/myapp.xml (note the name change)
Copy your myapp.war to ${jetty.home}/webapps/myapp.war (note, the basename for this file should be the same as your XML)
Edit your ${jetty.home}/webapps/myapp.xml to change the deployment behavior (eg: <Set name="contextPath">/app/1</Set>)
Start Jetty. $ java -jar start.jar
This is known as Configuring Specific WebApp Deployment.
Option 3: Customized Context Deployment
If you want to keep your war file somewhere other than ${jetty.home}/webapps/, you will still need to do the following:
Copy your existing myconf.xml to to ${jetty.home}/webapps/myconf.xml.
Leave your myapp.war where you want it. For example /opt/webapps/myapp.war
Edit your ${jetty.home}/webapps/myconf.xml to set the contextPath and war entries.
Start Jetty. $ java -jar start.jar
<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN"
"http://www.eclipse.org/jetty/configure_9_0.dtd">
<Configure id="myapp" class="org.eclipse.jetty.webapp.WebAppContext">
<Set name="server">
<Ref refid="Server" />
</Set>
<Set name="contextPath">/myapp</Set>
<Set name="war">
<SystemProperty name="/opt/webapps/myapp.war" />
</Set>
</Configure>
Option 4: Jetty Base Automatic Deployment (Available in Jetty 9.1+)
There is another technique, available starting with Jetty 9.1, using the split ${jetty.home} and ${jetty.base} concepts + the Automatic Deployment from above.
Lets say you have jetty-distribution-9.1.x unpacked into /opt/jetty/ and you have your webapp + configuration in /opt/myapps/. You can do the following commands.
[user]$ cd /opt/myapps
[myapps]$ java -jar /opt/jetty/start.jar --add-to-start=server,deploy,websocket,ext,resources
server initialised in ${jetty.base}/start.ini (appended)
server enabled in ${jetty.base}/start.ini
deploy initialised in ${jetty.base}/start.ini (appended)
deploy enabled in ${jetty.base}/start.ini
MKDIR: ${jetty.base}/webapps
server enabled in ${jetty.base}/start.ini
websocket initialised in ${jetty.base}/start.ini (appended)
websocket enabled in ${jetty.base}/start.ini
server enabled in ${jetty.base}/start.ini
ext initialised in ${jetty.base}/start.ini (appended)
ext enabled in ${jetty.base}/start.ini
MKDIR: ${jetty.base}/lib
MKDIR: ${jetty.base}/lib/ext
resources initialised in ${jetty.base}/start.ini (appended)
resources enabled in ${jetty.base}/start.ini
MKDIR: ${jetty.base}/resources
[myapps]$ ls -l
total 16
drwxrwxr-x 3 user group 4096 Oct 31 08:32 lib/
drwxrwxr-x 2 user group 4096 Oct 31 08:32 resources/
-rw-rw-r-- 1 user group 369 Oct 31 08:30 start.ini
drwxrwxr-x 2 user group 4096 Oct 31 08:30 webapps/
[myapps]$ cat start.ini
--module=server
threads.min=10
threads.max=200
threads.timeout=60000
jetty.dump.start=false
jetty.dump.stop=false
--module=deploy
--module=websocket
--module=ext
--module=resources
[myapps]$ java -jar /opt/jetty/start.jar --list-config | grep -E "jetty.(base|home)="
jetty.home=/opt/jetty
jetty.base=/opt/myapps
[myapps]$ cp /home/user/project/myapp/target/myapp-1.0.war /opt/myapps/webapps/myapp.war
[myapps]$ java -jar /opt/jetty/start.jar
2013-10-31 08:35:58.919:INFO:oejs.Server:main: jetty-9.1.0.RC0
2013-10-31 08:35:58.939:INFO:oejdp.ScanningAppProvider:main: Deployment monitor [file:/opt/myapps/webapps/] at interval 1
2013-10-31 08:35:59.109:INFO:oejw.StandardDescriptorProcessor:main: NO JSP Support for /myapp, did not find org.apache.jasper.servlet.JspServlet
2013-10-31 08:35:59.189:INFO:oejsh.ContextHandler:main: Started o.e.j.w.WebAppContext#223ff173{/myapp,file:/tmp/jetty-myapp.war-_myapp-any-/webapp/,AVAILABLE}{/myapp.war}
What you'll notice is that you have 2 locations you can work with.
${jetty.home} - where your jetty-distribution is located
${jetty.base} - where your app's specific configuration and wars are located
This is a pretty powerful option, and I've only touched the surface of its capabilities.
Here is my brief background of environment.
I am trying to convert a myapp WAR to an OSGi compliant by making the MANIFEST.MF as shown below, and wanted to deploy this war in ServiceMix an OSGi based container.
MANIFEST.MF
Manifest-Version: 2.0
Bundle-SymbolicName: myapp
Bundle-Version: 2.1.dev
Bundle-Name: Jetty.myapp
Bundle-Vendor: ABC
Created-By: 1.6.0_25-b06 (Sun Microsystems Inc.)
Bundle-ClassPath: .,WEB-INF/lib, WEB-INF/classes, xforms/xsltforms
Web-ContextPath: myapp
Webapp-Context: myapp
Import-Package: javax.servlet
Built-By: root
Project-Name: ABC_PRJ
Project-Version: 2.1.dev
Project-Build: ${DSTAMP}
SVN-Revision: ${svn.revision}
The ContextPath is getting set to null, where should I set the contextPath and how? You may observe the 'null' string in the FileNotFound Exception.
log:
java.io.FileNotFoundException: null/WEB-INF/myForms-config.xml (No such file or
directory)
My web.xml in myapp is :
<contextPath>/</contextPath>
<context-param>
<param-name>myForms.configfile</param-name>
<param-value>WEB-INF/myForms-config.xml</param-value>
</context-param>
Is it the problem with myapp or jetty or serviceMix? Any Clue?
You need to set the web-contextpath via the Manifest and not via the web.xml
for more information take a look at Pax-Web
For testing purposes I want to use Jetty 8 to serve only static content. I know how to start the webserver from the command line:
java -jar start.jar jetty.port=8082
I would like to be able to use a vanilla Jetty, preferably 8 or 7, and start it using something like:
java -jar start.jar OPTIONS=resources resources.root=../foo jetty.port=8082
The files should then be accessible from the root of the server. A file called ../foo/x.html should be accessible via http://localhost:8082/x.html.
I don't want to create a WAR file or anything fancy. Preferably it shouldn't do any caching on the server side, leaving the files unlocked on Windows machines. Also, I only want to serve files, even located in subdirectories, no fancy file browser or ways to modify them from a client.
Is this possible? If not, what is the minimum configuration needed to accomplish such behavior?
Additional information
I've tried the following command. I expected to be able to browse the javadoc shipped with Jetty 8 using http://localhost:8080/javadoc/, but it always gives me a 404
java -jar start.jar --ini OPTIONS=Server,resources etc/jetty.xml contexts/javadoc.xml
The simplest way to start Jetty and have it serve static content is by using the following xml file:
static-content.xml:
<?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure.dtd">
<Configure id="FileServer" class="org.eclipse.jetty.server.Server">
<Call name="addConnector">
<Arg>
<New class="org.eclipse.jetty.server.nio.SelectChannelConnector">
<Set name="host"><Property name="jetty.host" /></Set>
<Set name="port"><Property name="jetty.port" default="8080"/></Set>
</New>
</Arg>
</Call>
<Set name="handler">
<New class="org.eclipse.jetty.server.handler.ResourceHandler">
<Set name="resourceBase"><Property name="files.base" default="./"/></Set>
</New>
</Set>
</Configure>
Than you can start Jetty using:
java -jar start.jar --ini static-content.xml files.base=./foo jetty.port=8082
If you omit files.base, the current direcory will be used; if you omit jetty.port, port 8080 will be used.
The --ini will disable the settings from start.ini, therefore also make sure no other handlers etc. will be activated.
A bit of offtopic, but somebody using maven may wish to this something like this (supposing that static resources have been copied to target/web):
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>8.1.9.v20130131</version>
<executions>
<execution>
<id>start-jetty</id>
<phase>install</phase>
<goals>
<goal>start</goal>
</goals>
<configuration>
<webAppConfig>
<resourceBases>
<contextPath>/</contextPath>
<resourceBase>${project.build.directory}/web</resourceBase>
</resourceBases>
</webAppConfig>
</configuration>
</execution>
</executions>
</plugin>
In your distribution under the contexts directory is a javadoc.xml that you can use as an example on how to do this easily enough.
http://git.eclipse.org/c/jetty/org.eclipse.jetty.project.git/tree/jetty-distribution/src/main/resources/contexts/javadoc.xml
that is what it actually looks like
you are looking to change the context path and the resource base
would also recommend just removing jetty-webapps.xml from the startup in the start.ini file and also removing the context files you don't want to deploy with
you can look at setting some of the other options in the start.ini file as well if you like
http://wiki.eclipse.org/Jetty/Feature/Start.jar
go there for information the start process
cheers