Archiv verlassen und diese Seite im Standarddesign anzeigen : Apache <-> Tomcat
Kampfschildkroe
23.03.08, 08:23
Hallo,
ich habe folgendes Problem:
Ein Apache-Proxy nimmt die Webanfragen entgegen und leitet sie an einen Tomcatserver weiter. Dieser verarbeitet die Anfrage und gibt PHP code an den Apachy-Proxy zurück (ist die Vorgabe der Infrastruktur), kann dieser den Code irgendwie verarbeiten bevor er es an den Client Browser ausliefert bzw. muss man etwas bestimmtes einstellen?
Eventuell mit Ein-/Ausgangsfilter, aber da bin ich nicht richtig schlau draus geworden :( ?
Danke im Voraus.
hast du dir schon eine testumgebung aufgesetzt? evtl als virtual machine?
rein mit mod_proxy dürfte das AFAIK nicht gehen - da mod_proxy Request und Response ja nur durchreicht und sonst nicht weiter bearbeitet.
Du müsstest also dafür sorgen, dass der Apache den php-Code bearbeitet, z.B. in dem Du den Request nicht direkt an den Tomcat durchleitest sondern ihn auf dem Apache durch ein Wrapper-Script entgegennehmen lässt, diese leitet ihn an den Tomcat weiter und schickt dann den Response des Tomcat noch durch den php-Parser, bevor es den Output dann an den Client schickt...
Ob das auch über http://httpd.apache.org/docs/2.0/mod/mod_ext_filter.html funktioniert - hm, könnte gehen, müsste man mal Testen, von der Vorgehensweise her sieht es aber gut aus (siehe z.B. sed-Beispiel).
Die Performance dürfte aber eher bescheiden sein (eigener php-Prozess / Request), kein Sessionhandling und vermutlich auch kein Zugriff auf irgendwelche Umgebungsvariablen...
Kampfschildkroe
23.03.08, 09:21
hast du dir schon eine testumgebung aufgesetzt? evtl als virtual machine?
Nein, (noch nicht). Da ich damit noch keine Erfahrungen habe, habe ich erstmal so über Google gesucht und da ich dort nichts gefunden habe, wollte ich erstmal hier nachfragen, ob so etwas überhaupt möglich ist, bzw. schon jemand so etwas gemacht hat.
@marce:
Danke, das werde ich mir mal angucken.
Hi!
Tausch Tomcat mal gegen Resin. Resin kann PHP 5 selbst ausführen.
Gruß
fuffy
mmmh
es stellt sich halt nur die Frage warum die Java-Application erst noch mal php ausgeben soll, das dann erst wieder abgearbeitet werden muss. warum nicht gleich html / xml
es stellt sich halt nur die Frage warum die Java-Application erst noch mal php ausgeben soll, das dann erst wieder abgearbeitet werden muss. warum nicht gleich html / xml
Als Template-Sprache? Wobei sich da natürlich JSP oder Velocity eher anbieten würden.
Gruß
fuffy
Hi!
Tausch Tomcat mal gegen Resin. Resin kann PHP 5 selbst ausführen.
Gruß
fuffy
Das dürfte nichts bringen - der Tomcat gibt ja das php aus und dieses soll von einem Apache interpretiert werden - wenn ich da den Tomcat gegen Resin austausche ändere ich nichts am Problem, dass ein "eigentlich nur proxy" mehr als das sein soll.
Ansonsten - ja, klar - das Vorgehen prinzipiell ist nicht optimal (ich würde die komplette Proxy-php-Geschichte rauswerfen und das gesamte komplett vom Tomcat erledigen lassen...)
Hi!
Das dürfte nichts bringen - der Tomcat gibt ja das php aus und dieses soll von einem Apache interpretiert werden - wenn ich da den Tomcat gegen Resin austausche ändere ich nichts am Problem, dass ein "eigentlich nur proxy" mehr als das sein soll.
Naja, der Tomcat kann mit PHP nichts anfangen, Resin unterstützt PHP-Dateien als Alternative zu JSP. Sofern also die Anwendung auf PHP-Dateien innerhalb des docBase verweist, kann diese von Resins PHP-Servlet ausgeführt werden. Der Tomcat würde sie natürlich unverändert weiterreichen.
Wenn nicht, kann man immer noch einen ServletFilter davorschalten, der das Ergebnis durch Quercus jagt. Die Performance dürfte besser sein als mit mod_ext_filter.
Gruß
fuffy
Ein Apache-Proxy nimmt die Webanfragen entgegen und leitet sie an einen Tomcatserver weiter. Dieser verarbeitet die Anfrage und gibt PHP code an den Apachy-Proxy zurück
ich verstehe das so, dass der Tomcat aus php-Code generiert. Daher wäre es meiner Meinung nach egal, welcher Server den Code generiert.
Quercus kenne ich nicht - meine Resin-Zeiten sind lange her, wir habe noch zu 2.x-Zeiten aus mehreren Gründen auf TomCat umgestellt.
Wenn ich die Doku dazu aber richtig verstanden habe so wäre es vom Prinzip her die gleiche Vorgehensweise, nur dass alles im Resin erledigt würde anstatt den Code noch mal an den Apache zurückzuleiten und ihn dort verarbeiten zu lassen - das würde natürlich Performace bringen (wenn ich ein paar Google-Ergebnisse richtig deute sollte das Vorgehen aber auch im TomCat möglich sein)
Wobei das ganze Vorgehen aus meiner Sicht eigentlich eine komplette Fehlkonstruktion bleibt...
Kampfschildkroe
24.03.08, 09:53
Wobei das ganze Vorgehen aus meiner Sicht eigentlich eine komplette Fehlkonstruktion bleibt...
Das versuche ich ja rauszufinden (ist ne Aufgabe im Praxissemester). Nicht, dass jetzt der Verdacht aufkommt ich will die Arbeit hier abwälzen: Hatte schon andere Möglichkeiten geprüft, aber sollte nochmal mit dem Proxy überprüfen, aber da finde ich irgendwie nix richtiges zu im Netz. Könnte wohl daran liegen, dass die Möglichkeit Schwachsinn ist ;)?
//edit:
Der Tomcat sollte möglichst in diesem Zustand, daher die Sache mit dem Proxy.
Wie wäre es, wenn du deinen Szenario etwas genauer erläuterst?
Ich hab das bisher so verstanden, dein Tomcat generiert aus irgendwelchen java Dateien (z.B. jsp) php-Webseiten ala <phpinfo();> und gibt das an den Client zurück (indirekt über den Apache). Du willst den Apache nun veranlassen als PHP Interpreter zu fungieren um damit HTML an den echten Client zurückliefern. Hab ich das richtig verstanden?
Kampfschildkroe
24.03.08, 16:01
Wie wäre es, wenn du deinen Szenario etwas genauer erläuterst?
Ich hab das bisher so verstanden, dein Tomcat generiert aus irgendwelchen java Dateien (z.B. jsp) php-Webseiten ala <phpinfo();> und gibt das an den Client zurück (indirekt über den Apache). Du willst den Apache nun veranlassen als PHP Interpreter zu fungieren um damit HTML an den echten Client zurückliefern. Hab ich das richtig verstanden?
Jep, genauso.
zum Thema Proxy ;-)
http://de.wikipedia.org/wiki/Proxy_%28Rechnernetz%29
ich kann die von dir geschilderte Aufgabenstellung in der Beschreibung auf de.wikipedia.org leider nicht finden ...
wenn tomcat die quelle ist, die die daten liefert, dann macht es imho keinen Sinn diese erst in php ausliefern zu lassen.
welche Lösungsmöglichkeiten sich dir bieten kann aber ohne weitere Info zu der Aufgabe nicht gesagt werden
grüsse
zum Thema Proxy ;-)
http://de.wikipedia.org/wiki/Proxy_%28Rechnernetz%29
ich kann die von dir geschilderte Aufgabenstellung in der Beschreibung auf de.wikipedia.org leider nicht finden ...
Es ist üblich, nicht den HTTP-Server vom Tomcat zu nutzen, da dieser nicht "production-ready" ist. Stattdessen wird selbst von den Tomcat-Entwicklern empfohlen, nen Apache als Proxy davorzusetzen (mod_jk). Deshalb ist es ok, den Apachen als Proxy zu bezeichnen. Er selbst reicht ja nur HTTP-Requests mittels AJP weiter bzw. die Antwort zurück.
PHP hat damit erstmal nichts zu tun.
Gruß
fuffy
Es ist üblich, nicht den HTTP-Server vom Tomcat zu nutzen, da dieser nicht "production-ready" ist. Stattdessen wird selbst von den Tomcat-Entwicklern empfohlen, nen Apache als Proxy davorzusetzen (mod_jk). Deshalb ist es ok, den Apachen als Proxy zu bezeichnen. Er selbst reicht ja nur HTTP-Requests mittels AJP weiter bzw. die Antwort zurück.
PHP hat damit erstmal nichts zu tun.
Gruß
fuffy
Jup, aber darum geht es nicht. Es geht darum, dass gemäß Post 1 der apache auf dem weg Client-> Server (Tomcat) als Proxy fungieren soll, auf dem Weg Server -> Client aber die Daten verarbeiten soll. Ich gebe zu, dass mein Post nicht sehr ausführlich war. Deine Erläuterung war informativ erklärt aber nicht was der Threadersteller eigentlich mit diesem Umweg bewerkstelligen möchte / was der Grund für diese ungewöhnliche Vorgehensweise ist.
vielleicht möchte er ja dynamische Seiten in php mit dem tomcat dynamisch erstellen. Es bleibt dann natürlich die Frage wieso das ganze nicht gleich von Tomcat in der entgültigen Form bereitgestellt werden kann / soll. In diesem Fall könnte der Apache dann seiner Aufgabe als Proxy zu fungieren gerecht werden. Im anderen Fall wäre das auf den ersten Blick recht umständlich. Da in den allermeisten Fällen wohl der von dir geschilderte Weg gegangen wird, ist wohl kaum mit Dokumentation für die in Post 1 geschilderte Aufgabenstellung zu finden. Es wäre jedoch zu prüfen ob es möglich ist dem Apache die Daten des Tomcat als Dateien unterzuschieben oder das phpmodul / Apache dazu zu bewegen die daten aus einem Socket oder einer Pipe entgegenzunehmen und zu verarbeiten. Dann ist der Apache aber kein reiner Proxy mehr ;-). Außerdem denke ich, dass das Verarbeiten der PHP-Daten die Möglichkeiten des Proxies in Bezug auf die Änderung der Daten, wie sie m verlinkten Artikel angedeutet werden, sprengen.
Grüße
Reinhard
Hi!
Es geht darum, dass gemäß Post 1 der apache auf dem weg Client-> Server (Tomcat) als Proxy fungieren soll, auf dem Weg Server -> Client aber die Daten verarbeiten soll.
Auch das darf ein (Reverse) Proxy. Er darf auch Content manipulieren, was z.B. Privoxy macht, um Javascript oder ähnliche Dinge aus HTML-Seiten zu entfernen. Welche Daten und in welchem Format sie den Client erreichen liegt im Ermessen des Proxys. Ich sehe da nicht das Problem.
Gruß
fuffy
Hi!
Auch das darf ein (Reverse) Proxy. Er darf auch Content manipulieren, was z.B. Privoxy macht, um Javascript oder ähnliche Dinge aus HTML-Seiten zu entfernen. Welche Daten und in welchem Format sie den Client erreichen liegt im Ermessen des Proxys. Ich sehe da nicht das Problem.
Gruß
fuffy
mmhh irgendwie reden wir aneinander vorbei. Er darf Content manipulieren aber ich würde mich heftigst dagegen wehren, wenn ein Proxy den Code, den man ihm unterschiebt auch noch ausführt ....
naja, der Definition eines Proxys widerspricht es nicht - es ist nur in dieser speziellen Ausführung nicht "üblich"...
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.