Frage

Ich baue Java Web-Anwendungen, und ich hasse die traditionelle "Code-Kompilierung deploy-Test" -Zyklus. Ich möchte in einer winzigen Änderung eingeben, dann sah das Ergebnis SOFORT, ohne kompilieren mit und bereitstellen.

Zum Glück Jetty für diese groß ist. Es ist ein reiner Java-Web-Server. Es kommt mit einem wirklich schönen Maven Plugin , die Sie Jetty können starten Lesen direkt von Build Baum - keine Notwendigkeit, eine wAR-Datei oder bereitstellen zu verpacken. Es hat sogar eine ScanInterval Einstellung. Setzen diese auf einen Wert ungleich Null und es wird Ihre Java-Dateien und verschiedene Konfigurationsdateien für Änderungen beobachten und automatisch ein paar Sekunden erneut bereitstellen, nachdem Sie eine Änderung vornehmen

Es gibt nur eine Sache, mich von Nirwana zu halten. Ich habe Javascript und CSS-Dateien in meinem src / main / webapp Verzeichnis, das nur nach oben von Jetty serviert bekommen. Ich möchte in der Lage sein, zu bearbeiten diese und haben die Änderungen angezeigt, wenn ich die Seite im Browser aktualisieren. Leider hält Jetty diese Dateien öffnen, so kann ich nicht (unter Windows) ändern sie, während er ausgeführt wird.

Wer weiß, wie Jetty machen lassen diese Dateien gehen so ich sie bearbeiten können, dann die bearbeiteten Dateien für nachfolgende Anforderungen dienen up?

War es hilfreich?

Lösung

Jetty verwendet Memory-Mapped-Dateien statische Inhalte zu puffern, die die Datei-Sperren in Windows verursacht. Versuchen Sie, useFileMappedBuffer für DefaultServlet auf false gesetzt.

Fehlerbehebung Gesperrte Dateien auf Windows (ab die Jetty wiki) Anweisungen hat.

Andere Tipps

Während einer der oben genannten Antworten ist genau das richtige für die Konfiguration von Anlegesteg von xml, wenn Sie diese Option in Code konfigurieren möchten (für einen eingebetteten Server) die Antwort anders ist und nicht auf dieser Seite gefunden.

Sie werden eine Reihe von Vorschlägen Online einschließlich finden

context.getInitParams () setzen ( "useFileMappedBuffer", "false").

oder den WebAppContext überschreibt, oder einen vollständig qualifizierten Namen für die init-Parameter verwendet wird. Keiner dieser Vorschläge war für mich (mit Jetty 7.2.2). Ein Teil des Problems war, dass die useFileMappedBuffer Option auf der Servlet gesetzt werden muss, dass der WebAppContext die statischen Dateien zu dienen, anstatt auf dem Kontext.

Am Ende habe ich so etwas wie dies auf einem einfachen ServletContextHandler tat

// 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();

Das ist zwar ein altes Problem, aber ich fand

Jetty 9.2 Dokumentation gibt einen Jetty Embedded Beispiel statisch zu dienen Dateien einen ResourceHandler anstelle eines Servlets mit:

// 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 verwendet NIO (In-Memory-Dateizuordnung) und damit Schlösser Dateien auf Windows-Betriebssystemen . Dies ist ein bekanntes Problem, und viele Abhilfen für Servlets gefunden werden.

Doch wie dieses Beispiel auf Servlets beruht nicht, basierend die dazugehörigen Antworten auf Webapp Parameter (useFileMappedBuffer, maxCachedFiles) funktionieren nicht.

Um In-Memory-Dateizuordnung zu verhindern, müssen Sie die folgende Konfigurationszeile hinzuzufügen:

resource_handler.setMinMemoryMappedContentLength(-1);

Hinweis: wie in der Javadoc geschrieben (und bemerkte von 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. Ich habe aber das gleiche Verhalten mit dem Wert Integer.MAX_VALUE.

Wenn diese Parameter gesetzt ist, Ihre Jetty statische Dateien auf Windows dienen kann, und Sie können sie bearbeiten.

Einstellung falsch useFileMappedBuffer in webdefault.xml hat nicht Arbeit für mich (Jetty 8.1.10.v20130312). Zum Glück maxCachedFiles auf 0 (auch in webdefault.xml) hat den Trick zu setzen.

ähnliche Antwort auf @kybernetikos, aber ohne die DefaultServlet neu erstellen zu müssen:

// 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 sucht nach seiner eigenen Kopie useFileMappedBuffer, die tief in der Jetty gesetzt scheint. Aber durch die Eigenschaftsnamen mit wie oben prefixing dieser Wert bevorzugt wird.

Ich habe auch dieses Problem.

Und ich wollte keine zusätzliche Klassen erstellen und Messing mit web.xml

So, hier ist das, was Sie tun können:

Angenommen, Sie projizieren ist Maven basiert und (sagen wir mal) genannt 'my-web-app'

1) Erstellen Sie eine Datei my-web-app / Anlegesteg / Anlegesteg-config.xml

2) setzt das Zeug innen:

<?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) Hier ist Ihre Anlegestelle 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>

wird diese Lösung ein Attribut in dem Sie-Kontext Servlet die statischen Ressourcen Verriegelung deaktivieren wird.

Viel Spaß:)

Wenn eingebetteten Jetty mit 8.1.10, die 'useFileMappedBuffer = false' Einstellung funktioniert nicht jede Mode. Ich lese den Code für DefaultServlet, und es liest die Eigenschaft, aber es ist nicht für alles verwendet.

Stattdessen schaute ich auf, wo der Puffer Erstellung konfiguriert wurde, und ich fand SelectChannelConnector Unterklasse könnte die Vorteile der Fortsetzung zu bekommen, aber ohne Dateien auf Fenster zu verriegeln. Wenn Sie einfach org.mortbay.jetty.bio.SocketConnector verwenden, dann werden Sie nicht Fortsetzung Unterstützung.

Hier ist mein Beispiel:

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);
    }
}

Ich habe dies für das Verriegelungs Problem getestet, und es behebt das Problem. Ich habe nicht getestet, dass es mit Fortsetzungen funktioniert noch.

Bei der Verwendung von IntelliJ und Jetty 9 mit einem ResourceHandler eine der Lösungen ist es, die statischen Inhalte in dem Zielverzeichnis zu bearbeiten, statt der Quelldatei.

Es ist wahrscheinlich der Browser, der es hält an.

innen I.E: Tools | Internetoptionen | Temporäre Internetdateien> Einstellungen, klicken Sie auf den Radiobutton „Bei jedem Zugriff auf die Seite“. drücken Sie OK.

Bevor Sie das tun, löschen Sie alle temporären Internet-Dateien.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top