If you use something like jetty:run while developing webapps on windows, sooner or later you’ll run into a problem with file locking. Any editor worth using normally lets you edit jsp files, css or js files and have the changes immediately be visible, without having to start/stop the servlet container, or (heaven forbid) rebuild the .war.

Jsp files don’t seem to be affected, because they have to be recompiled, but editing js and css files, say in a resources directory, fail.
Jetty has an extensive reference on this and if you search the web you’ll find hundreds of people parroting this in one form or another.

In my opinion, it’s a terrible solution. I most certainly do _NOT_ want to have to copy a jetty webdefault.xml file into my project, and maintain any changes made in the plugin upstream. I do _NOT_ want to have to hardcode a path to a local jetty install. I DO use more than one servlet container, and have no desire to include jetty specific garbage in my main web.xml file. But all this talk of changing the value of useFileMappedBuffer can be avoided completely.

Step back a bit, the problem is caused by NIO on windows. If you’re running jetty for embedded development purposes via jetty:run, do you really give a shit about the performance difference with hundreds of threads vs traditional blocking IO? No. Not in the least. So instead of hacking and poking jetty files, just change the plugin config to not use NIO. Like so…..

<plugin>
    <groupId>org.mortbay.jetty</groupId>
    <artifactId>maven-jetty-plugin</artifactId>
    <version>6.1.18</version>
    <configuration>
        <contextPath>${project.parent.artifactId}</contextPath>
        <connectors>
            <!-- work around file locking on windows -->
            <connector implementation="org.mortbay.jetty.bio.SocketConnector">
                <port>8080</port><!-- this connector defaults to 1300 for some reason -->
            </connector>
        </connectors>
    </configuration>
</plugin>