glassfish verhindert deployment wenn bereits 1x fehlgeschlagen

[ruutaiokwu]

habe das problem bereits hier beschrieben, deshalb verweise ich darauf: glassfish disabled deployment at errors ??? | Java.net


schräg, dass mir diese frage niemand beantworten konnte? ich werde doch kaum der einzige sein, dem das auffällt...?


grüsse,
jan

 

[Stroker89]

Hatte genau das selbe Problem, seitdem stoppe ich zum deployen den Server kurz, leg die WAR File in den Autodeploy Ordner und starte den Server neu. Sehr lästig aber funktioniert.

Wie man das umgehen kann weiß ich leider auch nicht tut mir leid

 

[ruutaiokwu]

hallo Stroker99,

das file "WEBAPP_NAME_deployFailed" müsste also gar nicht von hand gelöscht werden? ich stoppe den server auch immer. reicht es also, wenn man das war-file nochmals reinkopiert, und dann den server wieder startet.

schaut der glassfish etwa auf den timestamp des war-files? sprich: wenn der timestamp des neuen (ersetzten, gleichnamigen) war-files höher als der des (fehlgeschlagenen) vorherigen ist, wird wieder deployt?

man könnte den glassfish-quelltext mal nach dem string "deployFailed" absuchen, und das kreieren dieses files auskommentieren. ein kleiner hack halt, dann würde sich das gezeigte verhalten wohl ändern...

...allerdings müssten solche änderungen stehts gut dokumentiert werden, und darauf habe ich auch nicht wirklich lust.


gruss, jan

 

[Stroker89]

Ich weiß zwar nicht genau wie der Glassfish Server das macht aber so könnte es schon sein.

Heißt wenn ich eine WebApp deploy und diese fehlerhaft ist wird die deployedfail Datei erzeugt.
Halte ich den Server nun an und ersetze die WebApp mit einer Korrekten (ohne Fehler) und starte den Server neu, so verschwindet diese deployedfail datei und wird mit einer deployed Datei ersetzt. Also dass es funktioniert hat.

Ich denke Der Glassfish wird die Infodatei immer löschen und immer durch die aktuelle ersetzen egal ob fehlgeschlagenes deployen oder nicht.

So sehen zumindest meine Beobachtungen aus

Vielleicht weiß darüber jemand mehr und kann uns ein paar Tipps geben wenn es welche gibt

 

[KYLT]

Hi,
grundsätzlich gilt, dass die Datei im Autodeploy Verzeichnis immer versucht wird zu deployen. Dabei ist es theoretisch egal, ob die Signatur (Timestamp) der Datei älter ist oder neuer. Entscheidender ist der Name der war Datei. Der Glassfish versucht die bereits vorhandene Datei zu überschreiben, bzw. zu ersetzen.

Ich vermute Ihr habt die War Datei manuell in den Autodeployordner gelegt. Bei Verwendung von IDE Netbeans oder Eclipse gibt es entsprechende möglichkeiten die Server direkt an das Web-Projekt zu binden (bzw. genau umgekehrt). Mag ich mich täuschen und mich jemand korregieren, aber bei vermeindlichen Problemen mit erneutem Deployment konnte man hier einfach per Mausklick den Cache des Servers leeren.

 

[ruutaiokwu]

hallo KYLT,

ja, habe den glassfish manuell heruntergeladen, ein wenig angepasst, die webapp in enpackter form in das deployment-verzeichnis gelegt und anschliessend gestartet.

wenn man (diverse) application server in die ide (eclipse, netbeans, etc.) integriert, ändert sich deren konfiguration, z.b. hot-deployment für jedes veränderte/neu compilierte .class-file...

gruss, jan

 

[ruutaiokwu]

evtl. ist die beschriebene problematik mittlerweilen jemand anderem aufgefallen??


grüsse, jan