http://blog.gmane.org/gmane.comp.java.jetty.support hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.java.jetty.support/15115 <pre>Thanks Thomas, that worked. On Mon, May 21, 2012 at 4:19 PM, Thomas Becker &lt;tbecker&lt; at &gt;intalio.com&gt; wrote: </pre> Rohit Reddy 2012-05-21T14:04:04 http://permalink.gmane.org/gmane.comp.java.jetty.support/15114 <pre>Hi Rohit, if you start jetty by using "java -jar start.jar" you're already using a java commandline and thus you can specify any java commandline arg you like. For example: "java -Xms1024m -Xmx1024m -jar start.jar". Cheers, Thomas On Mon May 21 07:32:57 2012, Rohit Reddy wrote: -- thomas becker tbecker&lt; at &gt;intalio.com http://webtide.com / http://intalio.com (the folks behind jetty and cometd) --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email </pre> Thomas Becker 2012-05-21T10:49:33 http://permalink.gmane.org/gmane.comp.java.jetty.support/15113 <pre>I'm trying to install a standalone jetty 7.6.3 server in CENTOS. I was able successfully deploy and run a sample application with default settings. Now i want to increase the JVM memory, that is set the Xmx and Xms parameters. After reading through the documentation i have set them in start.ini file. But this is not getting reflected when i start the server. I have tried using --exec parameter in start.ini, but this spawns a separate VM. I'm using java -jar start.jar to start the server How do i configure the JVM memory GC setting in a jetty standalone server Thanks Rohit </pre> Rohit Reddy 2012-05-21T05:32:57 http://permalink.gmane.org/gmane.comp.java.jetty.support/15112 <pre>Yes, I've seen the documentation on max-age. I do want to set up the expiry header. I'm using scala/lift with sbt and I found this http://www.vineetmanohar.com/2010/10/java-expiry-date-header/ but it doesn't seem to be setting the headers correctly (I inspected in chrome and firebug) Anyone have a filter hanging around for this purpose? Thanks On Thu, May 3, 2012 at 4:48 AM, Jan Bartel &lt;janb&lt; at &gt;intalio.com&gt; wrote: </pre> Justin Phillips 2012-05-03T17:05:39 http://permalink.gmane.org/gmane.comp.java.jetty.support/15111 <pre>Hi all,I want to use jetty as reverse proxy server(replace apache httpd),what need pay attention to?How to config static resource cache? Best Rgds L.J.W -- View this message in context: http://jetty.4.n6.nabble.com/What-need-pay-attention-if-I-use-jetty-as-reverse-proxy-server-tp4949351.html Sent from the Jetty Support mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email </pre> ljw79618 2012-05-03T14:04:35 http://permalink.gmane.org/gmane.comp.java.jetty.support/15110 <pre>You can use the max-age on the cacheControl to control expiry. Alternatively, you'd need to make a small filter to set the expires header. Jan On 2 May 2012 20:27, Justin Phillips &lt;justin.phillips&lt; at &gt;locusenergy.com&gt; wrote: --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email </pre> Jan Bartel 2012-05-03T11:48:48 http://permalink.gmane.org/gmane.comp.java.jetty.support/15109 <pre>Hi all, I'm trying to set the expires entity-header field in static content http headers. I see the cacheControl bit which can be set through webdefaults.xml. Is there a parameter for expiry as well? Thanks in advance. </pre> Justin Phillips 2012-05-02T18:27:26 http://permalink.gmane.org/gmane.comp.java.jetty.support/15108 <pre>All, I have an embedded Jetty 6 where I would like to share session data between several webapps. The simplest approach would be if there was a way to declare a set of web apps as "friendly" and automatically get the same session instance for the same session cookie in each web apps context. Unfortunately is explicitly forbidden (on presumed "security" grounds) in the Servlet spec. Now, I don't have any problems breaking against the spec if it can help in my programming model. If I actually were to achieve to share session objects between friendly contexts, are there any actual problems in doing so? Let's say that I programmatically inject the same SessionManager into all contexts concerned, would it work as expected when sessions are serialized, times out or are otherwise invalidated? Would the session be kept from timing out in all contexts when being accessed in one? Do the answers depend on the SessionManager implementation, or is it part of the session manager contract to do what I want (or not)? I understand I can achieve the same thing by indexing some external storage (a db, various enterprise frameworks or some homegrown session manager that I inject into all contexts as a resource), but I would be nifty if I could rely on already existing code. /Simon --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email </pre> Simon Tardell 2012-04-29T11:06:06 http://permalink.gmane.org/gmane.comp.java.jetty.support/15107 <pre>Hi all, as people have already asked we'd like to inform you about some changes that happened to GzipFilter.java. We've added deflate support for the GzipFilter and to do so we applied some api changes which might have been a bit harsh on a minor release. Here's the initial bugzilla for the change: https://bugs.eclipse.org/bugs/show_bug.cgi?id=375692 The changes include: - Removal of GzipStream.java. There's now an abstract class called AbstractCompressedStream which includes all the logic. A "GzipStream" is now instantiated inline in GzipFilter.java line 276. - Removal of GzipResponseWrapper.java which is now instantiated inline as well and inherits from it's abstract base class: CompressedResponseWrapper Have a look at GzipFilter.createWrappedResponse(..) on how to create a formerly named "GzipStream" or "GzipResponseWrapper". Cheers, Thomas On 3/9/12 8:51 PM, Jesse McConnell wrote: </pre> Thomas Becker 2012-04-23T14:39:35 http://permalink.gmane.org/gmane.comp.java.jetty.support/15106 <pre>I have an application that uses org.eclipse.jetty.http.gzip.GzipStream. This class is gone from 8.1.3. What happened to it? I've searched but didn't find anything. -- View this message in context: http://jetty.4.n6.nabble.com/What-happened-to-org-eclipse-jetty-http-gzip-GzipStream-in-8-1-3-tp4909724p4909724.html Sent from the Jetty Support mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email </pre> tweitzel 2012-04-23T09:58:58 http://permalink.gmane.org/gmane.comp.java.jetty.support/15105 <pre>We have finally pushed the releases out to maven central and updated all the relavent download artifacts in the download areas of eclipse and codehaus. There have been a number of issues addressed with the recent SPDY support. Below are the patch notes for each of the releases! cheers, jesse jetty-7.6.3.v20120416 - 16 April 2012 + 367172 Remove detection for slf4j NOPLogger + 373269 Make ServletHandler.notFound() method impl do nothing - override to send back 404. + 373421 address potential race condition related to the nonce queue removing the same nonce twice + 373952 bind called too frequently on refresh + 374018 correctly handle requestperminuted underflow + 374252 SslConnection.onClose() does not forward to nested connection. + 374258 SPDY leaks SSLEngines. Made the test more reliable. + 374367 NPE in QueuedThreadPool.dump() with early java6 jvms + 374475 Response.sendRedirect does not encode UTF-8 characters properly + 374881 Set copyWebInf to false by default + 374891 enhancement to how ProxyServlet determines the proxy target + 375009 Filter initialization error will throw MultiException + 375083 Flow control should take in account window size changes from concurrent SETTINGS + 375096 If starting a server instance fails in osgi it is cleaned up. + 375490 NPE with --help on command line + 375509 Stalled stream stalls other streams or session control frames. Now using a "death pill" instead of a boolean in order to avoid race conditions where DataInfos were read from the queue (but the boolean not updated yet), and viceversa. + 375594 fixed SSL tests so they are not order dependent + 375709 Ensure resolveTempDirectory failure does not deadlock; improve error message + 375970 HttpServletRequest.getRemoteAddr() returns null when HTTP is over SPDY. + 376201 HalfClosed state not handled properly. Addendum to restore previous behavior, where a closed stream was also half closed. + JETTY-1504 HttpServletResponseWrapper ignored when using asyncContext? jetty-8.1.3.v20120416 - 16 April 2012 + 349110 MultiPartFilter records the content-type in request params + 367172 Remove detection for slf4j NOPLogger + 372678 Embedded Examples need updates for new LoginService requirement + 373269 Make ServletHandler.notFound() method impl do nothing - override to send back 404. + 373421 address potential race condition related to the nonce queue removing the same nonce twice + 373952 bind called too frequently on refresh + 374018 correctly handle requestperminuted underflow + 374152 jetty-all-server MANIFEST contains wrong import: javax.servlet.annotation;version="[2.6,3)" + 374252 SslConnection.onClose() does not forward to nested connection. + 374258 SPDY leaks SSLEngines. Made the test more reliable. + 374367 NPE in QueuedThreadPool.dump() with early java6 jvms + 374475 Response.sendRedirect does not encode UTF-8 characters properly + 374881 Set copyWebInf to false by default + 374891 enhancement to how ProxyServlet determines the proxy target + 375009 Filter initialization error will throw MultiException + 375083 Flow control should take in account window size changes from concurrent SETTINGS + 375096 If starting a server instance fails in osgi it is cleaned up. + 375490 NPE with --help on command line + 375509 Stalled stream stalls other streams or session control frames. Now using a "death pill" instead of a boolean in order to avoid race conditions where DataInfos were read from the queue (but the boolean not updated yet), and viceversa. + 375594 fixed SSL tests so they are not order dependent + 375709 Ensure resolveTempDirectory failure does not deadlock; improve error message + 375906 Part.getHeader method not case insensitive + 375970 HttpServletRequest.getRemoteAddr() returns null when HTTP is over SPDY. + 376201 HalfClosed state not handled properly. Addendum to restore previous behavior, where a closed stream was also half closed. + 376324 &lt;max-file-size&gt; is not respected in &lt;multipart-config&gt; + JETTY-1495 Ensure dynamic servlet addition does not cause servlets to be inited. + JETTY-1500 form parameters from multipart request not available via request.getParameter + JETTY-1504 HttpServletResponseWrapper ignored when using asyncContext? jetty&lt; at &gt;codehaus-7.6.3.v20120416 - 16 April 2012 + JETTY-1487 umask setting for SetUID can't be set to 0 + JETTY-1497 jetty-jspc-maven-plugin has problems with spaces in classpath filenames + JETTY-1498 Add ability to put &lt;scope&gt;provided&lt;/scope&gt; artifacts on system classpath for jetty-jspc-maven-plugin jetty&lt; at &gt;codehaus-8.1.3.v20120416 - 16 April 2012 + JETTY-1487 umask setting for SetUID can't be set to 0 + JETTY-1497 jetty-jspc-maven-plugin has problems with spaces in classpath filenames + JETTY-1498 Add ability to put &lt;scope&gt;provided&lt;/scope&gt; artifacts on system classpath for jetty-jspc-maven-plugin + JETTY-1499 WEB-INF/classes not scanned with mvn jetty:run-war -- jesse mcconnell jesse.mcconnell&lt; at &gt;gmail.com --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email </pre> Jesse McConnell 2012-04-17T17:12:26 http://permalink.gmane.org/gmane.comp.java.jetty.support/15104 <pre>Greetings, Jetty is great, we love it so much, you are all doing such a wonderful work ! We are experiencing a high priority problem at one of our customer sites. The symptoms we are seeing are, that simple browser GET requests for images or static resources just hang for up 50 seconds with no apparent reason. We are using: Jetty 6.x (latest) with BIO connector running on Windows 2008 32 bit with Java 1.6.x (latest) We are using the following thread pool settings in jetty.xml: &lt;Set name="ThreadPool"&gt; &lt;New class="org.mortbay.thread.QueuedThreadPool"&gt; &lt;Set name="minThreads"&gt;10&lt;/Set&gt; &lt;Set name="maxThreads"&gt;200&lt;/Set&gt; &lt;Set name="lowThreads"&gt;20&lt;/Set&gt; &lt;Set name="SpawnOrShrinkAt"&gt;2&lt;/Set&gt; &lt;/New&gt; &lt;/Set&gt; On the client side the problem only occurs when using IE8 and IE9 but not with IE7 (probably since IE7 is limited to two concurrent requests but we are not sure) When the problem occurs we can see in the server logs the following events: 1. A new web page is sent is to the browser as a response to a client request. 2. The client browser then submits 10 concurrent requests at once, for loading static resources such as images, JavaScripts, CSS etc. 3. Jetty dispatches all 10 threads in its thread pool to serve these resource. 4. All Jetty threads are now hang, with the following stack trace waiting for something: "9543875&lt; at &gt;qtp-23978087-3" prio=6 tid=0x07b07c00 nid=0x1f6c runnable [0x0908f000..0x0908fbe8] java.lang.Thread.State: RUNNABLE at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:129) at org.mortbay.io.ByteArrayBuffer.readFrom(ByteArrayBuffer.java:382) at org.mortbay.io.bio.StreamEndPoint.fill(StreamEndPoint.java:107) at org.mortbay.jetty.bio.SocketConnector$Connection.fill(SocketConnector.java:198) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:290) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228) at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:520) 5. At some point around 50 seconds later we receive the following exception in the log: java.net.SocketTimeoutException: Read timed out at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:150) at java.net.SocketInputStream.read(SocketInputStream.java:121) at org.mortbay.io.ByteArrayBuffer.readFrom(ByteArrayBuffer.java:382) at org.mortbay.io.bio.StreamEndPoint.fill(StreamEndPoint.java:107) at org.mortbay.jetty.bio.SocketConnector$Connection.fill(SocketConnector.java:198) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:290) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404) at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228) 6. After this exception the Jetty threads are operational again freeing the client browser to finish rendering the page. We are able to reproduce this problem fairly easily in our test environment even with a single session. We have two questions: 1. Why are the Jetty threads hanging on socket read after serving a static resources ? 2. Why doesn’t the Jetty thread pool spawn more threads up to 200 when all initial 10 threads are locked ? We already made the following observation: 1. If we change SpawnOrShrinkAt to 0 then the thread pool is able to spawn more threads and this improves the situation and delays the occurrence of the problem. Any advice on this would be much appreciated, Best regards, Lior </pre> Lior Yaffe 2012-04-04T12:47:27 http://permalink.gmane.org/gmane.comp.java.jetty.support/15103 <pre>Kirk, Fixed the NPE with the start line: https://bugs.eclipse.org/bugs/show_bug.cgi?id=375490 Are you sure you haven't got $JETTY_HOME/webapps and $JETTY_HOME/contexts configured in one of the xml config files? thanks Jan On 24 March 2012 20:43, Kirk Pepperdine &lt;kirk.pepperdine&lt; at &gt;gmail.com&gt; wrote: --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email </pre> Jan Bartel 2012-03-28T03:50:07 http://permalink.gmane.org/gmane.comp.java.jetty.support/15102 <pre>Hi Using pack200 to compress .jars can make quite a difference. One of our largest JARs goes from 10 MB to 1.5 MB. Although URLClassLoader can handle them just fine no container I saw to far seems to support .jar.pack.gz in WEB-INF/lib/. Probably because section 10.5 of the servlet spec mentions only WEB-INF/lib/*.jar. Is there any reason pack200 was not considered so far? I posted this on the servlet mailing list [1] but of course got no reply. [1] http://java.net/projects/servlet-spec/lists/users/archive/2012-03/message/31 Cheers Philippe --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email </pre> Philippe Marschall 2012-03-26T09:12:56 http://permalink.gmane.org/gmane.comp.java.jetty.support/15101 <pre>Hi, I've trying to configure 8.1.2 to run with a webapp that I cannot keep in the distribution. I'm using the command line as follows. java -Dapp.properties=webapp.properties -Djetty.home=../bin/jetty-distribution-8.1.2 -jar ../bin/jetty-distribution-8.1.2/start.jar ./jetty/etc/jetty.xml The problem is in addition to scanning my webapp and context directories, it is also scanning the $JETTY_HOME/webapps and $JETTY_HOME/contexts first. This causes the script fails with a BindException: address already in use. If I switch ports on my listener then all is well. So the question is, how do I get jetty to not scan the configuration in the distribution. Note that I've gone through jetty-context.xml and jetty-webapps.xml to change the deployment directory to my local directory. Just having difficulty seeing what I've missed. One other point, when I run java -Djetty.home=../bin/jetty-distribution-8.1.2 -jar ../bin/jetty-distribution-8.1.2/start.jar --help from the same directory as I'm trying to run my webapp from (not the jetty distribution dir) I get the following output: &lt;loads of good stuff snipped out&gt; The current start.ini arguments are: java.lang.NullPointerException at org.eclipse.jetty.start.Main.loadStartIni(Main.java:1053) at org.eclipse.jetty.start.Main.usage(Main.java:384) at org.eclipse.jetty.start.Main.start(Main.java:517) at org.eclipse.jetty.start.Main.main(Main.java:82) &lt;good stuff snipped out&gt; Appreciate any pointers. Kind regards, Kirk Pepperdine --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email </pre> Kirk Pepperdine 2012-03-24T09:43:14 http://permalink.gmane.org/gmane.comp.java.jetty.support/15100 <pre> I see the bug is fixed for jetty-7.6.3/8.1.3.  Thanks for the quick work Jan! Jake On Thu, 22 Mar 2012 11:30:28 +1100  Jan Bartel &lt;janb&lt; at &gt;intalio.com&gt; wrote: --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email </pre> Jacob Kjome 2012-03-23T16:32:14 http://permalink.gmane.org/gmane.comp.java.jetty.support/15099 <pre>Hello everyone, Here is my first post to the Jetty mailing list. I discovered the Jetty world a few weeks ago, and, well: it's great! I hope you could help me in resolving my issue. I have developed a WebService using: - JAX-WS 2.2.5 - Jetty 8.1.2, embedded, no web.xml - jetty-http-spi-8.1.0.RC4.jar (for using org.eclipse.jetty.http.spi.JettyHttpServer) The Web Service works pretty well using https. I need now to add a client authentifcation. I would like to use HttpSessionScope, however, HttpSessionScope needs to access the servlet request from the WebServiceContext (SERVLET_REQUEST), which is in my case always NULL. Do you know how to configure an embedded Jetty with HttpSessionScope working ? If not, do you know how to get the servlet request not NULL ? FYI, I have posted this question to the JAX-WS forum as well with no answer yet ( http://www.java.net/forum/topic/glassfish/metro-and-jaxb/using-httpsessionscope-embedded-jetty ) Hope you can help, Mabda Here is my (really simple) code: *Server* import ht.controler.server.service.ControlerImpl; import javax.xml.ws.Endpoint; import org.eclipse.jetty.http.spi.JettyHttpServer; import org.eclipse.jetty.server.Connector; import org.eclipse.jetty.server.Server; import org.eclipse.jetty.server.handler.ContextHandlerCollection; import org.eclipse.jetty.server.ssl.SslSelectChannelConnector; import org.eclipse.jetty.util.ssl.SslContextFactory; (...) Server server = new Server(8081); SslContextFactory sslFactory = new SslContextFactory("e:/keystore.jks"); sslFactory.setKeyStorePassword("password"); SslSelectChannelConnector selectChannelConnector = new SslSelectChannelConnector(sslFactory); selectChannelConnector.setPort(8081); server.setConnectors(new Connector[] {selectChannelConnector }); JettyHttpServer jettyServer = new JettyHttpServer(server, true); Endpoint endpoint = Endpoint.create(new ControlerImpl()); ContextHandlerCollection collection = new ContextHandlerCollection(); server.setHandler(collection); endpoint.publish( jettyServer.createContext("/Service") ); server.start(); *WebService Class (I removed the &lt; at &gt;HttpSessionScope to check that the servlet request was NULL)* &lt; at &gt;WebService(endpointinterface="service.Controler") //&lt; at &gt;HttpSessionScope public class ControlerImpl implements Controler { &lt; at &gt;Resource private WebServiceContext wsContext; &lt; at &gt;WebMethod public String executeCommand(String name) { System.out.println(wsContext.getMessageContext().get(MessageContext.SERVLET_REQUEST)); // NULL return "Command executed"; } } If I use &lt; at &gt;HttpSessionScope, I get the following exception: [image: Images intégrées 1] </pre> choco vanille 2012-03-22T22:29:35 http://permalink.gmane.org/gmane.comp.java.jetty.support/15098 <pre>Jacob, You're right - we're handling filter initialization exceptions differently than servlet initialization exceptions. Raised: https://bugs.eclipse.org/bugs/show_bug.cgi?id=375009 thanks Jan On 22 March 2012 06:07, Jacob Kjome &lt;hoju&lt; at &gt;visi.com&gt; wrote: --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email </pre> Jan Bartel 2012-03-22T00:30:28 http://permalink.gmane.org/gmane.comp.java.jetty.support/15097 <pre> No comment on this Jetty behavioral change which appears pretty clear to me to be a bug? Jake On Mon, 19 Mar 2012 17:17:39 -0500  "Jacob Kjome" &lt;hoju&lt; at &gt;visi.com&gt; wrote: --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email </pre> Jacob Kjome 2012-03-21T19:07:22 http://permalink.gmane.org/gmane.comp.java.jetty.support/15096 <pre> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 JBoss Service might be worth a look. http://www.jboss.org/jbossweb/install/service.html https://community.jboss.org/wiki/RunJBossAsAServiceOnWindows Note that it apparently can run more than just JBoss (with some tweaking, of course!). And its completely opensource. Regards, Steve On 03/16/2012 04:29 PM, Filipe Sousa wrote: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9osucACgkQSphIUSiVzgbhVQCfSP7ACj8uaIq+06jIzZWVAC26 y7QAnjTYFFgpbQ7Gt6oabP+c0JlKs8Nu =L+lN -----END PGP SIGNATURE----- </pre> Stephen Davidson 2012-03-20T16:40:07 http://permalink.gmane.org/gmane.comp.java.jetty.support/15095 <pre>Wow that was quick. Thank you very much Jan. One last question, when will the 8.1.3 jetty maven plugin be released and pushed into maven repos? Thanks, Shane. Shane Rowatt Architect T M F E W+61 7 3252 1650 +61 401 550 697 +61 7 3252 1350 srowatt&lt; at &gt;gcpgroup.com gcpgroup.com &lt;http://www.gcpgroup.com/&gt; GCP Brisbane 24 Chester Street Newstead QLD 4006 Australia GCP Australia Limited | Sydney | Brisbane | Singapore | London Important Notice: The information in this email and/or any of the attachments may contain Confidential, Legally Privileged and/or Copyright material of GCP Australia Limited or third parties. If you are not an authorised recipient of this email, please contact GCP Australia Limited immediately by return email or by telephone on +61 7 3252 1650 and delete the email from your system. We do not accept any liability in connection with any computer virus, data corruption, interruption or any damage generally as a result of transmission of this email. On 19/03/12 4:56 PM, "Jan Bartel-3 [via Jetty]" &lt;ml-node+s4n4632237h78&lt; at &gt;n6.nabble.com&gt; wrote: -- View this message in context: http://jetty.4.n6.nabble.com/Jetty-8-and-Maven-Jetty-Plugin-jetty-run-war-not-working-tp4627356p4635598.html Sent from the Jetty Support mailing list archive at Nabble.com.</pre> rowatt 2012-03-20T03:59:06 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.java.jetty.support