war file entpacken oder in RAM laden lassen

[snippet]

Was sind die Gründe, warum man ein war file beim deployen in den tomcat container un-entpackt lässt?
Ich habe gehört dass es angeblich viele so machen damit die Dateien nicht runtergeladen werden können falls der tomcat mal down ist.
Find ich komisch, da muss es doch andere Sicherheitsmechanismen geben?

Oder die Anwendung soll schneller werden, weil alles schon im RAM? Dann erkauft man sich die Geschwindigkeit durch Speicherhungrigkeit?

Andererseits kriegt man Probleme mit manchen Frameworks, wie z.B. das springframework, wenn keine Verzeichnisstruktur vorhanden?

Stimmt das?

Hat jemand Erfahrung mit dem Für und Wider vom war file entpacken?

bedankt
snip

[Christian Marquardt]

Weil es praktischer ist, das dem Tomcat zu überlassen, weil es einfacher ist das auf den Server zu bringen, weil es platzsparender ist.....

Ich habe gehört dass es angeblich viele so machen damit die Dateien nicht runtergeladen werden können falls der tomcat mal down ist.

Aha, von alles Webservern die down sind kann man die Dateien runterladen. Glaube nicht

Oder die Anwendung soll schneller werden, weil alles schon im RAM? Dann erkauft man sich die Geschwindigkeit durch Speicherhungrigkeit?

Es ist bei eine WAR noch nichts im RAM.

Andererseits kriegt man Probleme mit manchen Frameworks, wie z.B. das springframework, wenn keine Verzeichnisstruktur vorhanden?

Nein, die Verzeichnisstruktur ist ja da

[snippet]

Weil es praktischer ist, das dem Tomcat zu überlassen, weil es einfacher ist das auf den Server zu bringen

Hmm, was ist da einfacher? Das war file deployen muss ich so oder so, die Frage ist nur ob ich unpackWARs="false" oder "true" setze. Was ist da praktischer oder einfacher?

Nein, die Verzeichnisstruktur ist ja da

Nö, bei mir nicht, Java meckert folgendes:
Cannot set web app root system property when WAR file is not expanded

Danke auch dass ich mich jetzt noch mehr wie ein Idiot fühle....

[Christian Marquardt]

Das war file deployen muss ich so oder so,

Also hier nicht. Man schmeisst das WAR in das Verzeichnis und wenn der Tomcat merkt, das ein neues da ist, deployt er es. Nun das finde ich schon praktischer...Des Weiteren laufen hier Spring-Server-Applikationen ohne Probleme.

nutze mal den Manager unter 8080

[snippet]

Scheint, du hast die Frage nicht verstanden

Die Frage war ob upackWar = true oder unpackWar = false die bessere Lösung ist.

Also: Du haben ein war file und du es in den tomcat schmeissen. Dann alles weitere tomcat selber machen, klaro. Egal ob mit manager oder einfach datei ins richtige verzeichnis kopieren, das keine rolle spielen, denn manager genau das machen. Aber Frage ist, ob tomcat war file entpacken soll oda nich.



Gibts hier eigentlich einen Preis für möglichst viele Posts oder ähnlich??

[Alwin Ibba]

Die Frage war ob upackWar = true oder unpackWar = false die bessere Lösung ist.

Die Frage ist auch so pauschal nicht zu beantworten. Ein nicht-enpacktes war-File hat, wie von Christian angemerkt, Vorteile beim Deployment. Alles was im war-File ist gehört zusammmen und man braucht sich keine Gedanken machen, das einzelne Dateien in der Verzeichnisstruktur vielleicht noch auf dem alten Stand sind (weil sie ev. gelockt sind und deshalb nicht ausgetauscht werden konnten). Wenn man beispielsweise eine Anwendung clusterweit deployen will, kann man sich sicher sein, das überall dieselbe Anwendung läuft, wenn überall dasselbe war im Verzeichnis liegt. Auf Applikationsservern werden Anwendungen üblicherweise als ear deployt und es ist absolut unüblich in Produktionsumgebungen das komplette Archiv beim Deployment zu entpacken (einschließlich der darin enthaltenen wars, jars usw.). Die Performance bzw. Speicherfrage würde ich, wie auch von Christian angedeutet, dem Server überlassen. Der ist darauf optimiert und entpackt das ev. in ein temporäres Verzeichnis oder im Speicher. Man verwendet in Java ja auch jar-Files ohne sich die Frage zu stellen ob der Classloader ev. schneller wäre, wenn man die class-Files vorher entpackt.

Und ja, es ist möglich Webanwendungen so zu programmieren, das sie aus einem war (ohne entpacken) nicht laufen. Man braucht nur die Methode ServletContext.getRealPath() zu verwenden und immer einen Rückgabewert erwarten. Da Spring das unter bestimmten Umständen tut läuft es unter eben diesen Umständen nicht direkt aus war-Dateien. Das hatte was mit der Log4J-Konfiguration zu tun und ließ sich auch dementsprechend ändern, so das der Fehler nicht mehr auftritt und Spring ohne entpacken des wars funktioniert. Genaueres weiß ich nicht mehr.

Grundsätzlich ist es immer besser die Anwendung so zu programmieren, das sie auch im gepackten Zustand läuft.

[ngomo]

Seid lieb zueinander ;-)

Hallo,

immer schön lieb sein .

unpackWar= true oder false, sollte man sich wegen der Performance keine Gedanken machen. Grundsätzlich gilt, was Alwin schreibt (freut mich, mal wieder was von Dir zu lesen Awin. Deine Posts sind immer sehr gehaltvoll!). Ergänzend dazu noch ein Link auf die Tomcat-Doku, die beschreibt, was für Probleme es bei ausgepackten wars geben kann: http://tomcat.apache.org/tomcat-6.0-...n%20Deployment

Ich finde unpackWar=true aus einem Grund doch ganz praktisch. Man kann on the fly mal Dateien austauschen, um z.B. ein neues Hintergrundbild zu laden, an css-Dateien rumzubasteln, Schreibfehler in Properties-Dateien zu beheben. etc. ohne den kompletten Deploymentzyklus zu durchlaufen. Das geht nicht, wenn man nur ein war hat. Ich weiß ist nicht gerade sauberes Vorgehen, aber ab und zu brauch ichs eben doch.

Gruß ngomo

[Alwin Ibba]

Hallo,

Man muß auch zwischen Entwicklung und Produktion unterscheiden. Während der Entwicklung arbeitet man sinnvollerweise expanded, damit man die Dateien on-the-fly editieren kann. Tomcat deployt Anwendungen ja auch ganz ohne war-File und ohne war ist auch die Frage nach unpackWar sinnlos. Auch die gängigen Applikationsserver unterstützen das exploded-Format.

Man kann auch in der Produktion expanded fahren und hat grundsätzlich die Möglichkeit dem Server das entpacken zu überlassen, wenn er es unterstützt (z.b. Tomcat mit unpackWar) oder sein Deployskript so zu gestalten, das es die deployte Version komplett löscht und die neuen Dateien hinkopiert. Dann wird nie ein war oder ear gebaut, das entpackt werden müsste. Aus meiner Erfahrung heraus macht das aber mehr Probleme als das gepackte Format, speziell bei großen Installationen mit mehreren Serverinstanzen, wenn dann doch mal alte Dateileichen rumliegen. Bei kleineren Installationen kann man das natürlich so pragmatisch gestalten wie man selbst noch den Überblick behält und auch on-the-fly Dateien austauschen.

Viele Grüße,

Alwin