- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Vorschau und WebEdit mit Velocity?
Hallo zusammen,
ich stehe vor einer besonderen Herausforderung, und zwar sollen mit FirstSpirit (5.0) ausschlieรlich Dateien im Format Velocity Template erzeugt werden, die in einer Webapplikation ausgewertet werden. Die Dateien enthalten zwar den vollstรคndigen HTML Code (also nicht nur Schnipsel), sind aber natรผrlich in der Vorschau relativ unbrauchbar fรผr die direkte Anzeige.
Nun haben wir uns was ausgedacht, wie man die Vorschau umkonfigurieren kรถnnte, dass eine Instanz der Webapplikation auf das /fs5preview Verzeichnis zugreifen kann. Wir haben das noch nicht getestet, aber ich gehe davon aus, das wir das hinbekommen.
Jetzt will der Kunde aber unbedingt WebEdit benutzen und da habe ich etwas bedenken. Hier meine eigentliche, ganz allgemeine Frage:
Lรคuft WebEdit automatisch รผber die Applikation, wenn man die Vorschau umkonfiguriert oder was muss man da noch speziell beachten? Kann das รผberhaupt funktionieren oder funktioniert dann das Servlet fรผr WebEdit gar nicht mehr?
Grรผรe
Matthias
- Labels:
-
Developers
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Das Login-Ticket ist eine gewisse Zeit gรผltig. Ein Web-Proxy zwischen dem Browser und Preview-Server kรถnnte beispielsweise mehrere Requests abrufen, bevor er die Seite an den Client weitergibt. Wenn dabei keine Session-Cookies verwendet werden, wird erneut nach der Anmeldung gefragt.
Die IP-Adresse in den FirstSpirit-Logmeldungen ist vermutlich die lokale des Clients, also nicht die, die tatsรคchlich aus Sicht des Servers fรผr die Verbindung verwendet wird, sofern ein NAT-Router dazwischen liegt.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hallo nochmal,
leider konnten wir den Fehler bislang immer noch nicht beheben, aber vermutlich haben wir jetzt die Ursache identifiziert:
Die JSESSIONID wird beim ersten Aufruf (z.B. neu gestarteter Browser) nicht bzw. zu spรคt gesetzt. Im Gegensatz zur Vorschau รผber Jetty, wo das beim ersten Request gesetzt wird (siehe Screenshot im Anhang), wird das bei der Vorschau รผber die externe Applikation erst beim zweiten Request (bei der ersten eingebundenen Datei lib.js) gesetzt und da nรผtzt es offenbar nicht mehr fรผr den Rest der ersten geladenen Seite. Dadurch werden sรคmtliche Ressourcen (JS, CSS, Bilder etc.) in der Seite nicht geladen. Das erklรคrt aber andererseits auch, warum es bei nachfolgenden Versuchen dann auf Anhieb klappt - da ist die JSESSIONID dann bereits vorhanden.
Kรถnnte das evtl. doch ein Bug sein? Oder gibt es noch eine spezielle Konfiguration, die ich nicht finde?
Grรผรe
Matthias
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hallo Matthias,
weil das Problem zumindest bei PHP als Dateityp, also mod_php im Apache httpd nicht auftritt, kann es eigentlich kein Fehler in der WebApp fs5preview sein. Weil Velocity aber Java-basiert ist, PHP nicht, kรถnnte eine Ursache die doppelte Verwendung des Cookie-Namens "JSESSIONID" sein. Falls Velocity ein Cookie mit Namen JSESSIONID definiert: Kann man Velocity so einstellen, dass es kein JSESSIONID selbst definiert oder einen anderen Namen fรผr die Sessioninformationen verwendet?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hallo Holger,
nicht schlecht, Deine Vermutung!
Wir hatten tatsรคchlich eine Verdopplung von JSESSIONID drin. Das haben wir aber gestern geรคndert, die Anwendung erzeugt jetzt eine andere Variable. Jetzt frage ich mich nur warum der Jetty (der setzt doch den ersten Request ab, oder?) in diesem Fall die JSESSIONID nicht beim ersten Request setzt (wie in meinem Screenshot oben), sondern erst beim zweiten? Ich glaube, wenn wir das verstehen, haben wir vermutlich auch die Lรถsung gefunden. Aber momentan verstehe ich es nicht.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jetzt frage ich mich nur warum der Jetty (der setzt doch den ersten Request ab, oder?) in diesem Fall die JSESSIONID nicht beim ersten Request setzt (wie in meinem Screenshot oben), sondern erst beim zweiten?
Anhand des Screenshots kann ich das Verhalten nicht nachvollziehen. Verhรคlt sich denn ein Tomcat genauso?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ein รคhnliches Problem hatten wir schon einmal beim Einsatz von Web Application Firewalls (Reverse Proxy), die auch gerne JSESSIONID als Standard verwenden.
Aber warum es jetzt immer noch nicht funktioniert, erklรคrt es somit nicht. Es gibt manchmal Situationen bei WebApp-Servern, wo ein Servlet den Response-Header nicht mehr erweitern kann, also z.B. eben kein Cookie mehr eintragen kann, was von der Grรถรe des Output-Buffers abhรคngt. Das kรถnnte hier so etwas sein. Um das auszuschliessen, einmal eine sehr kurze .vm-Datei erstellen, nur wenige Bytes, und nur 1 externe Resource wie .css dort verlinken.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@ Peter: der Screenshot zeigt den ersten Request in Firebug fรผr eine Vorschau in Jetty - also die funktionierende Variante. Bei unserer Applikation (รผbrigens Weblogic) fehlt die gelb markierte Zeile, dieser Eintrag ist dann beim zweiten Request drin (bei der 1. externen Ressource, die geladen wird).
@ Holger: okay, das werde ich mal ausprobieren. In der Tat sind die Dateien sehr groร, weil sie neben diversen XML-Metadaten auch noch die komplette Zeitsteuerung enthalten, d.h. pro Zeitabschnitt einen kompletten HTML/Velocity-Code...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So, wieder neue Erkenntnisse:
eine kurze Datei hat auch kein anderes Ergebnis geliefert, die Ressource wird nicht geladen. Aber wir haben inzwischen noch etwas anderes herausgefunden:
Wir haben festgestellt, dass anscheinend Cookies, welche durch die externe Preview-Anwendung gesetzt werden, zu dem Fehler fรผhren. Wenn diese einen Cookie setzt (und dabei ist der Cookie-Name beliebig), so fรผgt der FirstSpiritServer den eigenen SessionCookie nicht an den Response an. Wenn die externe Anwendung keinen Cookie setzt, so wird der Session-Cookie durch FirstSpirit gesetzt und die nachfolgenden Requests sind erfolgreich. Wie kann das sein?
Den Cookie nicht zu setzen ist fรผr uns leider keine Option, da wir die Session in der externen Anwendung fรผr unterschiedliche Szenarien benรถtigen.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ich lasse das prรผfen unter der internen ID #155446.
Kannst du parallel dazu ein Ticket beim Helpdesk รถffnen?
Ich melde mich dann hier wieder, wenn wir neue Erkenntnisse haben.


- ยซ Previous
-
- 1
- 2
- Next ยป
- ยซ Previous
-
- 1
- 2
- Next ยป