How to make Jetty dynamically load “static” pages

Question

I am building Java web applications, and I hate the traditional "code-compile-deploy-test" cycle. I want to type in one tiny change, then see the result INSTANTLY, without having to compile and deploy.

Fortunately, Jetty is great for this. It is a pure-java web server. It comes with a really nice maven plugin which lets you launch Jetty reading directly from your build tree -- no need to package a war file or deploy. It even has a scanInterval setting: put this to a non-zero value and it will watch your java files and various config files for changes and automatically re-deploy a few seconds after you make a change.

There's just one thing keeping me from nirvana. I have javascript and css files in my src/main/webapp directory which just get served up by Jetty. I would like to be able to edit these and have the changes show up when I refresh the page in the browser. Unfortunately, Jetty holds these files open so I can't (on Windows) modify them while it is running.

Does anyone know how to make Jetty let go of these files so I can edit them, then serve up the edited files for subsequent requests?

Answer 1

Jetty uses memory-mapped files to buffer static content, which causes the file-locking in Windows. Try setting useFileMappedBuffer for DefaultServlet to false.

Troubleshooting Locked files on Windows (from the Jetty wiki) has instructions.

Answer 2

While one of the answers above is exactly right for configuring jetty by xml, if you want to configure this option in code (for an embedded server) the answer is different and not found on that page.

You'll find a number of suggestions online including

context.getInitParams().put("useFileMappedBuffer", "false");

Or overriding the WebAppContext, or using a fully qualified name for the init parameter. None of these suggestions worked for me (using Jetty 7.2.2). Part of the problem was that the useFileMappedBuffer option needs to be set on the servlet that the WebAppContext is using to serve the static files, rather than on the context.

In the end I did something like this on a straightforward ServletContextHandler

// Startup stuff
final Server server = new Server(port);
ServletContextHandler handler = new ServletContextHandler();
handler.setResourceBase(path);

SessionManager sm = new HashSessionManager();
SessionHandler sh = new SessionHandler(sm);
handler.setSessionHandler(sh);

DefaultServlet defaultServlet = new DefaultServlet();
ServletHolder holder = new ServletHolder(defaultServlet);
holder.setInitParameter("useFileMappedBuffer", "false");
handler.addServlet(holder, "/");

server.setHandler(handler);
server.start();
server.join();

Answer 3

Although this is a Old problem but i found this post very helpful, in short just change your config to

            <plugin>
                <groupId>org.mortbay.jetty</groupId>
                <artifactId>jetty-maven-plugin</artifactId>
                <configuration>
                <connectors>
                    <connector implementation="org.eclipse.jetty.server.bio.SocketConnector">
                        <port>8080</port>
                    </connector>
                </connectors>
                </configuration>
            </plugin>

This disables the NIO support in Jetty ( but it should not be problem for debug puropse for simple cases ).

Answer 4

Jetty 9.2 documentation gives a Jetty Embedded example to serve static files using a ResourceHandler instead of a servlet :

// Create a basic Jetty server object that will listen on port 8080.  Note that if you set this to port 0
// then a randomly available port will be assigned that you can either look in the logs for the port,
// or programmatically obtain it for use in test cases.
Server server = new Server(8080);

// Create the ResourceHandler. It is the object that will actually handle the request for a given file. It is
// a Jetty Handler object so it is suitable for chaining with other handlers as you will see in other examples.
ResourceHandler resource_handler = new ResourceHandler();
// Configure the ResourceHandler. Setting the resource base indicates where the files should be served out of.
// In this example it is the current directory but it can be configured to anything that the jvm has access to.
resource_handler.setDirectoriesListed(true);
resource_handler.setWelcomeFiles(new String[]{ "index.html" });
resource_handler.setResourceBase(".");

// Add the ResourceHandler to the server.
HandlerList handlers = new HandlerList();
handlers.setHandlers(new Handler[] { resource_handler, new DefaultHandler() });
server.setHandler(handlers);

// Start things up! By using the server.join() the server thread will join with the current thread.
// See "http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Thread.html#join()" for more details.
server.start();
server.join();

Jetty uses NIO (in-memory file mapping) and thus locks files on Windows operating systems. This is a known issue and many workarounds can be found for servlets.

However, as this example does not rely on servlets, the associated answers based on webapp parameters (useFileMappedBuffer, maxCachedFiles) do not work.

In order to prevent in-memory file mapping, you need to add the following configuration line:

resource_handler.setMinMemoryMappedContentLength(-1);

Note: as written in the Javadoc (and noticed by nimrodm) : the minimum size in bytes of a file resource that will be served using a memory mapped buffer, or -1 for no memory mapped buffers. I however got the same behavior with value Integer.MAX_VALUE.

Once this parameter is set, your Jetty can serve static files on Windows AND you can edit them.

Answer 5

Setting false to useFileMappedBuffer in webdefault.xml did NOT work for me (Jetty 8.1.10.v20130312). Fortunately setting maxCachedFiles to 0 (also in webdefault.xml) did the trick.

Answer 6

Similar to @kybernetikos answer, but without having to recreate the DefaultServlet:

// Startup stuff
final Server server = new Server(port);
WebAppContext webAppContext = new WebAppContext(path, "/")
webAppContext.setInitParam(
        "org.eclipse.jetty.servlet.Default.useFileMappedBuffer", "false");

server.setHandler(webAppContext);
server.start();
server.join();

DefaultServlet will look for it's own copy of useFileMappedBuffer, which seems to be set deep inside of Jetty. But by prefixing the property name with as above, this value is preferred.

Answer 7

I also had this problem.

And I didn't want to create any additional classes and messing with web.xml

So here is what you can do:

Assuming you project is maven based and (lets say) called 'my-web-app'

1) create a file my-web-app/jetty/jetty-config.xml

2) put this stuff inside:

<?xml version="1.0" encoding="UTF-8"?>
<Configure class="org.eclipse.jetty.webapp.WebAppContext">
  <Call name="setInitParameter">
    <Arg>org.eclipse.jetty.servlet.Default.useFileMappedBuffer</Arg>
    <Arg>false</Arg>
  </Call>
</Configure>

3) Here is your jetty config:

<plugin>
    <groupId>org.eclipse.jetty</groupId>
        <artifactId>jetty-maven-plugin</artifactId>
        <configuration>
            <httpConnector>
                <host>localhost</host>
                <port>8801</port>
            </httpConnector>
            <webApp>
                <contextPath>/${project.artifactId}</contextPath>
            </webApp>
        <contextXml>${project.basedir}/jetty/jetty-config.xml</contextXml>
    </configuration>
</plugin>

This solution will add an attribute to you servlet-context which will disable static resources locking.

Have fun :)

Answer 8

When using embedded Jetty 8.1.10, the 'useFileMappedBuffer=false' setting doesn't work any mode. I read the code for DefaultServlet, and it reads the property but it's not used for anything.

Instead I looked at where the buffer creation was configured, and found I could subclass SelectChannelConnector to get the benefits of Continuation, but without locking files on windows. If you simply use org.mortbay.jetty.bio.SocketConnector, then you will not get continuation support.

Here is my example:

import org.eclipse.jetty.io.Buffers.Type;
import org.eclipse.jetty.server.nio.SelectChannelConnector;

/**
 * A Connector that has the advantages NIO, but doesn't lock files in Windows by
 * avoiding memory mapped buffers.
 * <p> 
 * It used to be that you could avoid this problem by setting "useFileMappedBuffer" as described in 
 * http://stackoverflow.com/questions/184312/how-to-make-jetty-dynamically-load-static-pages
 * However that approach doesn't seem to work in newer versions of jetty.
 * 
 * @author David Roussel
 * 
 */
public class SelectChannelConnectorNonLocking extends SelectChannelConnector {

    public SelectChannelConnectorNonLocking() {
        super();

        // Override AbstractNIOConnector and use all indirect buffers
        _buffers.setRequestBufferType(Type.INDIRECT);
        _buffers.setRequestHeaderType(Type.INDIRECT);
        _buffers.setResponseBufferType(Type.INDIRECT);
        _buffers.setResponseHeaderType(Type.INDIRECT);
    }
}

I've tested this for the locking problem, and it fixes the problem. I've not tested that it works with Continuations yet.

Answer 9

When using IntelliJ and Jetty 9 with a ResourceHandler one of the solutions is to edit the static content in the target directory, instead of the source file.

Answer 10

It is probably the browser that is holding on to it.

inside I.E : Tools | Internet Options | Temporary Internet Files > Settings, click the Radio button "Every visit to the page". press OK.

Before you do that, Delete all the temporary internet files.