# Am Server Dateien ablegen



## Generic1 (12. Dez 2011)

Hi,

Ich verwende bei meiner Web- Applikation den Tomcat und kann in meiner Web - Applikation Dateien (Images, ...) zum Server hochladen. Diese Speichere ich momentan unter ${tomcat}/webapps/myFiles.

Wenn ich Tomacat neu starte ist natürlich der Ordner myFiles wieder weg und die hochgeladenen Dateien sind auch wieder weg. 
Meine Frage wäre jetzt, wo ihr diese Dateien speichern würdet, es soll ja für Linux und für Windows gültig sein.

Angenommen unter Windows: kann ich diese Dateien irgendwo speichern (C:\Eigene Dateien o.ä) oder wo würdet Ihr das machen? 
lg
Generic1


----------



## maki (12. Dez 2011)

Du könntest den Pfad in der web.xml als Servlet Init Parameter hinterlegen.
Wo dieser dann hinzeigt ist deine Entscheidung.


----------



## Generic1 (12. Dez 2011)

ich arbeite mit Spring 3.0, also auch mit Spring MVC, weiß vielleicht jemand ob ich da auch mit Servlet Init Parameter das machen kann? 
lg
Generic1


----------



## Generic1 (14. Dez 2011)

OK, ich habs gerafft, einfach einen <context-param> ins web.xml und passt schon. 
Ich hab leider immer noch ein Verständnisproblem, wenn ich also in der web.xml folgendes habe. 

[XML]
<context-param>
       <description>Path to the files (avatar) and uploaded files</description>
        <param-name>fmyfiles</param-name>
        <param-value>C:\MeineFiles</param-value>
    </context-param>
[/XML]

und dann Files hochlade, dann landen diese in C:\MeineFiles, das passt soweit,
die Upgeloadeten Fotos möchte ich auch anzeigen können,
wenn der Client/Browser dieses html vom Server bekommt: 

[XML]
<html>

<body>
 <img src="C:\MeineFiles\test.JPG" alt="Das ist ein Image" />
</body>
</html>
[/XML]

schaut dann der Browser local auf dem Rechner nach C:\Meine... nach oder am Server bzw. wie kann man das machen?
Vielen Dank,
lg


----------



## FArt (14. Dez 2011)

Eine von vielen Möglichkeiten:
Du musst die physikalische Stelle auf eine URL mappen. Diese könnte ein Servlet bedienen, welches dann auf Serverseite wieder Zugriff hat.


----------



## Generic1 (14. Dez 2011)

FArt hat gesagt.:


> Eine von vielen Möglichkeiten:
> Du musst die physikalische Stelle auf eine URL mappen. Diese könnte ein Servlet bedienen, welches dann auf Serverseite wieder Zugriff hat.



Wie meinst du das >> die physikalische Stelle auf eine URL mappen << ? 
d.h. ich hab z.B.: ein png in C:\MeineFiles\test.png und diesen Pfad muss ich mappen, wie geht sowas? 
Vielleicht kannst du das für einen Dummy wie mich erklären, ich hab in dieser Hinsicht keine Erfahrung.


----------



## nocturne (14. Dez 2011)

Ich speichere diese Daten in SQL-Datenbanken. Lässt sich leichter Archivieren.


----------



## maki (14. Dez 2011)

FArt meint ein sog. "Stream Servlet", hatten wir öfters hier im Forum, kommt imer in diesem Zusammenhang auf.

Wenn es sich nicht um größere Datenmengen handelt ist nocturnes Vorschlag auch einen Überlegung wert, hättest dann auch gleichzeitig Transaktionssicherheit und Referenzielle Integrität.

Content Repositories wie JackRabbit wären auch eine Alternative.


----------



## Generic1 (14. Dez 2011)

Ich hab jetzt ein bisschen recherchiert, aber nichts vernünftiges gefunden, ich denke mir das ist ja ein gängiger Fall, für "Stream Servlet" hab ich nicht wirklich was gefunden. 
Das kann ja aber auch nicht die Lösung sein, denk ich mir, das Problem ist ja der Pfad oder hat jemand einen Link wo das erklärt ist?

Das Stream Servlet muss ja einen Pfad (z.B.: C:\MeinPfad\meinFile.xxx) irgendwie mappen, das es der Client erreicht, oder? 
Und nochwas kommt dazu, ich arbeite mit Spring MVC, gibts da vielleicht einen Möglichkeit, wie man das mit Spring machen kann? 

JackRappit ist glaub ich ein bisschen überdimmensioniert, ich erwarte so im Jahr ca. 200-300 neue Files

Besten Dank, 
lg


----------



## maki (14. Dez 2011)

Vielleciht hilft ja das hier: 
Returning an Image in a Servlet | Example Depot



> Das Stream Servlet muss ja einen Pfad (z.B.: C:\MeinPfad\meinFile.xxx) irgendwie mappen, das es der Client erreicht, oder?


Den Pfad erfährt es aus der web.xml, Clients (Browser) verbinden sich zum Servlet um bekommen das Bild geliefert. 

k.A. ob Spring MVC da was bereits mitbringt.


----------



## Generic1 (15. Dez 2011)

Hi maki,

die Zeile String filename = sc.getRealPath("image.gif"); versteh ich nicht ganz. Wo ist denn image.gif gespeichert?
Vor allem, wenn ich mir so einen Root- Server nehme, kann ich dann einfach sagen, ich leg meine Bilder unter ${tomcat}/webapps/.. ab? Das geht ja gar nicht, da ich ja den Tomcat und somit auch den webapps- Ordner alleine habe.
Ich bin verblüfft dass es da nichts out of the box gibt, das braucht man in der Web-Appl- Programmierung ja alltäglich, oder?  

lg


----------



## maki (15. Dez 2011)

Das getRealpath brauchst du nciht, du kennst deinen Pfad ja schon


----------



## fastjack (15. Dez 2011)

Normalerweise sieht der Tomcat alles, was in deinem "webapps" Ordner (außer WEB-INF) liegt. Diese Dateien kannst Du dann auch in HTML ansprechen. 
"C:\xyz" läuft nicht in JSP/HTML. Browsermäßig wird dann auf das Verzeichnis des Clients zugegriffen, nicht gut...

Du kannst die Daten  wie oben beschrieben mit einem Servlet laden und an die Client weitergeben, Du kannst aber auch eine Resourcen-WebApp machen. Die liegt neben Deiner WebApp und dort können Dateien hochgeladen und runtergeladen werden.

z.B.:

webapps/MeineApp/...
webapps/MeineResourcen/Pic1.jpg
webapps/MeineResourcen/Sound1.wav

Link von MeineApp auf webapps/MeineResourcen/Movie1.wmv :

[img src="../MeineResourcen/Pic1.jpg"/]

mußt Du mal probieren, dann sparst Du das mit den Servlets.

Vielleicht hilft virtual host weiter, ich weis es aber jetzt nicht genau.

Apache Tomcat 6.0 (6.0.35) - Virtual Hosting and Tomcat


----------



## maki (15. Dez 2011)

@fastjack
So eine "RessourcenWebApp" löst sein problem nciht 
denn auhc dort könnten die hochgeladenen Ressourcen gelöscht werden beim Serverneustart.


----------



## fastjack (15. Dez 2011)

Aber nicht durch den Neustart.


----------



## maki (15. Dez 2011)

fastjack hat gesagt.:


> Aber nicht durch den Neustart.


Kommt darauf an.

Wenn das war Archiv noch unter webapps liegt, wird Tomcat das entpacken und das alte löschen, samt hochgeladener Dateien 
Laut Spec. ist es aber ncihtmal sicher ob die WAR Datei an sich überhaupt entpackt wird und ob man dann auf den Ordner überhaupt zugriff hat... unter TC mag das schon gehen.


----------



## fastjack (15. Dez 2011)

Ja das stimmt. Wir hatten die Resourcen-WAR damals per Hand gelöscht. Okay nicht fein, lief aber.


----------



## Generic1 (18. Dez 2011)

Also ich komm auf keine vernünftige Lösung auf dem Server, wenn ich da so eine Krücke wie eine Resource-war o.ä mache, da muss ich zu viel einrichten auf dem Rootserver - brauch daher support, und das kostet auch alles, 

ich hab mir daher jetzt folgende Lösung überlegt: ich mach mir in meiner Applikation einen WS- Client zu der Flickr WADL und lad die Images usw. volley da rauf und hole sie mir wieder wenn ich sie brauche.
Dann kann ich die Bilder sogar extern einsehen und wenn ich eine neue war/ear deploy dann ist alles noch da was ich brauch - halt auf einem anderen Server - find ich eigentlich ziemlich genial (wenn die Netzwerkverbindung zum anderen Server steht  )

Was sagt ihr zu dieser Lösung? 


lg
Generic1


----------



## FArt (19. Dez 2011)

Umständlich und nur sinnvoll, wenn man den Mehrwert benötig. 

Ich verstehe nicht, was so schwer daran ist, eine Servlet-URL auf eine physikalische Datei zu mappen. Die URL http://myapp/images/xy.jpg mappt z.B.  auf /myimages/xy.jpg oder c:\theimages\xy.jpg und dann werden die Daten als MIME jpg vom Servlet zum Client gestreamt.

Ich weiß ja nicht was das für Bilder sind, aber evtl. muss man datenschutzrechtliche Belange berücksichtigen. Wo stehen die Flickr-Server?


----------



## Generic1 (19. Dez 2011)

FArt hat gesagt.:


> Ich verstehe nicht, was so schwer daran ist, eine Servlet-URL auf eine physikalische Datei zu mappen. Die URL http://myapp/images/xy.jpg mappt z.B.  auf /myimages/xy.jpg oder c:\theimages\xy.jpg und dann werden die Daten als MIME jpg vom Servlet zum Client gestreamt.
> 
> Ich weiß ja nicht was das für Bilder sind, aber evtl. muss man datenschutzrechtliche Belange berücksichtigen. Wo stehen die Flickr-Server?



Was mich an dieser Lösung so stört ist, dass ich das ganze was ich bis jetzt programmiert habe wieder umschreiben kann, ich kann ja vom Client zum Server nicht nur Images sondern auch Videos hochladen.
Beim hochladen speichere ich momentan das Image einfach in einen "webapps"- Ordner und einen relativen Pfad zu dem Image und schick dann einfach den relativen Pfad an den Client zurück - Dann brauch ich nur den Pfad im Client in <img src="meinrelativerPfad" einbauen und schon wird das Image angezeigt.

Wenn ich das jetzt mit dem Streaming mache muss ich das Image wieder am Server laden/streamen und dann vom Server zum Client streamen und am Client muss ich dann den stream auch wieder bearbeiten - das Ganze funktioniert auch noch mit jQuery- ajax, was die Sache dann auch nicht gerade einfacher macht.


Wo der Flickr- Server steht muss ich zugeben, das wär mir egal - das schreib ich einfach ins Kleingedruckte. 

Aber ich find das mit dem Flickr sonst eine geniale Idee, bis auf Performance- Probleme sehe ich da keine Schwierigkeiten, oder wisst ihr da was, das nicht so optimal wäre?


----------



## FArt (19. Dez 2011)

Generic1 hat gesagt.:


> Wenn ich das jetzt mit dem Streaming mache muss ich das Image wieder am Server laden/streamen und dann vom Server zum Client streamen und am Client muss ich dann den stream auch wieder bearbeiten - das Ganze funktioniert auch noch mit jQuery- ajax, was die Sache dann auch nicht gerade


Nein, das stimmt nicht. Der Client kann auch mit plain HTML arbeiten. Der Server muss die Ressourcen auch nicht erst laden, er kann sie direkt zum Client pipen.
Ich sehe sogar Vorteile darin, wenn die Ressourcen nicht direkt über den Webspace mit HTTP abrufbar sind. Das kann sich auf Sicherheitsaspekte positiv auswirken und abstrahiert den phyiskalischen Ablageort der Ressourcen.


----------

