Umgang mit Ressourcen bei Web-Anwendungen

[Guest]

Hi,

wie geht ihr eigentlich mit diversen, vom Anwender uploadbaren Dateien
um? Kopiert ihr sie irgendwohin ausserhalb des Webverzeichnisses bzw.
des Verzeichnisses der Anwendung oder landen sie in einem Unterverzeichnis,
wo sie direkt erreichbar sind? Erlaubt ihr einen direkten Zugriff darauf, oder
schleust ihr sie durch ein Servlet?
z.B. in Links: "/document?id=1234". Hinter dem Kontext "document" steht
ein Servlet, welches das entsprechende Dokument, ahhand der Id, zurückgibt.

Ein Beispiel: Auf einer Webseite hat der Anwender die Möglichkeit PDF Dateien
hoch zu laden. Diese sollen auch anderen zur Verfügung gestellt werden.
Die Webanwendung wird als WAR deployed. Wohin mit den Dokumenten?

Gruß,
Michael

 

[bronks]

Wenn es sich nicht um temporäre Daten handelt, dann immer ausserhalb des WebAppDir, weil man die Daten bei einem Update der App verliert oder diese umgehen muß.

Da man Dateien jenseits des AppDir schwer verlinken kann wird das von Dir genannte Streaming durch ein Servlet die sinnvollste Möglichkeit sein, die Daten nach aussen zu bringen.

 

[Guest]

Danke für die schnelle Antwort. Gibt es vielleicht irgendeine Connector-Lösung für solche
Aufgaben (eine Art lokales Webverzeichnis o.ä.)? Ein CMS will ich nicht einsetzen, da es
etwas überdimmensioniert ist und bei kleinen Anwendungen den Aufwand nicht rechtfertigt.
Mir erscheint aber eine Trennung der Dokumentverwaltung vom Rest der Anwendung immer
sinnvoller. Lokal erreichbar und der Zugriff darauf über eine kleine Schnittstelle, die bei Bedarf
in jede Web-Anwendung eingebunden werden kann.

 

[bronks]

Symlinks bzw. Hardlinks könnten evtl. helfen, aber ich wüde es damit nicht machen, da ich schon so bestimmte Probleme beim Redeployment vermute.

Bei der Datenhaltung bin ich ein rücksichtsloser Fall und würde persönlich die PDFs als Blobs in eine Datenbank schreiben und beim Abruf streamen.

 

[Bleiglanz]

jo, das ist ein kleiner (oder auch grosser Haken) des .war Deployments, da kann man erstmal nix dagegen machen

ich reservier mir in so einem Fall immer einen festen Ordner irgendwo im Dateisystem; ist aber Geschmacksache; am besten ist natürlich bronks Idee (DB + Streaming + Caching selber machen)

in einfacheren Fällen würde ich für den Fall "explodiertes Deployment" vorziehen (d.h. die App entpackt über eine config.xml bereitstellen); das hat den Vorteil dass man dann alles relativ machen kann (getRealPath(...) usw) und dass der Zeugs dann gleich im "Auslieferungsmechanismus für statische Files" mit dabei ist

 

[Guest]

Ich versuche immer die Datenbanken so schlank wie nur möglich zu halten.
Die Streaming-Lösung war auch die erste, die mir einfiel. So habe ich es
schon früher gemacht, auch bei Perl oder PHP. Problematisch wird das
ganze, wenn die Dateien zu gross werden, oder wenn wirklich viele Leute
"gleichzeitig" auf den Server zugreifen. Da kommt man schnell in eine
Situation, wo der Speicher permanent am Limit genutzt wird. Eine Datei
vom Dateisystem direkt weiter zu leiten kostet weniger.
Vorteil der DB Lösung ist aber die Transaktionssicherheit, die mit Dateien,
die auch aus einem anderen Kontext heraus manipuliert werden können
(z.B. durch ein Interface für den Admin o.ä.), etwas schwieriger zu realisieren
ist. Arghh... ich schlafe noch drüber. Es ist kein wichtiges Projekt, eher ein
kleines Experiment mit JSF, um eine Idee reifen zu lassen.

OK, danke für Eure Beiträge. Es hilft manchmal "auf dem Boden zu bleiben",
bevor man sich in ausgefallene Designideen verrent.