Java-Applet: Problem mit Datei-Lese-Zugriff

d@niel · 11. Februar 2003

Hallo Experten,
ich mache nun meine ersten (sehr wackeligen) Schritte in Java, und stehe schon vor einem hässlichen Problem:
Ich möchte mit einem Java-Applet eine lokale Datei einlesen (Datei liegt nur zum Testen lokal, soll dann mal im Web liegen, da wo auch die Applet-Seite lebt). Dazu habe ich einen Quelltext gebaut, der sich im JCreator (Freeware) auch ausführen lässt und prima funktioniert. Das war ja schonmal ein Erfolg. Doch nun:
Nachdem ich mir die (ziemlich brauchbare) NetBeans-IDE installiert habe, funktioniert das Applet darin nicht mehr (aus dem JCreator läuft es nach wie vor). Ich bekomme beim Zugriff auf die Datei einen Fehler:
java.security.AccessControlException: access denied (java.io.FilePermission xyz.txt read)
Scheint also so, als ob dem Applet die Berechtigung fehlt, das File xyz.txt zu lesen. Irgendwie hab ich gelesen, dass Applets sowas nicht immer dürfen. Ok, schön.... aber warum klappt´s dann im JCreator? Beide verwenden den gleichen Applet-Viewer aus dem Sun SDK 1.3. Und: was kann ich tun, um ein Applet zu schreiben, welches eine Datei lesen kann? Die Datei soll dabei ebenso auf dem Webspace liegen wie die HTML-Seite mit dem Applet. Es wird also nix lokales gelesen, und daher sollte es sicherheitstechnisch ja keine Bedenken geben.

hier die File-Lese-Routine (die ja aber - wie erwähnt- z.B. im JCreator keine Probleme macht)

public StringBuffer getCruFileData(String fileName) throws IOException {
FileReader inputstream = new FileReader(fileName);
int readvalue;
StringBuffer text = new StringBuffer();
while ((readvalue = inputstream.read()) != -1) {
text.append((char) readvalue);
}
return text;
}

Wer kann da helfen????

d@niel

P.S. bitte kein exgtremes fach-chinesisch.... bin - wie gesagt - ziemlicher Java-Neuling

jaBernet · 11. Februar 2003

Also da Du das File ja eh vom Server holen wirst, ist ja nicht so schlimm, das bei NetBeans ein Permission Error kommt, weshalb ich dieses Prob mal ausenvor lasse.
Um eine Datei vom Server zu lesen ist es wohl am einfachsten diese wie ein Webbrowser dies tun wurde zo holen, also über eine Http-Connection. Habe leider gerade die JavaDoc-Hilfe nicht zur Hand, weiss also nicht wie es genau geht, sollte aber irgend wie so aussehen:

Code

Socket aSocket = new Socket("http://www.host.com/data.txt", 80);
aSocket.open();
InputStreamReader inputstream = new InputStreamReader(aSocket.getInputStream());

und von da aus dann eigentlich wie gehabt weiter. Villeicht musst Du aber auch zuerst noch eine HTTP GET abschicken. Meines Wissens sollte es auch eine Möglichkeit geben nicht über Sockets sonder direkt über eine HTTP-Connection die Datei zu erhalten. Werde das mal posten, wenn ich die Dok wieder zur Hand habe.

Gruss
inflagranti

d@niel · 11. Februar 2003

danke für die schnelle Antwort... die ich leider nur in Ansätzen verstehe Der NetBeans-Fehler stört schon, da ich die datei eben nicht öffnen/einlesen kann und folglich den restlichen Code nicht testen kann, da dieser eben die Daten aus dem File braucht. Mein naiver Gedanke war folgender:
- Applet liegt auf Web-Resource, ebenso wie das HTML-File
- auf der gleichen Resource liegt zu lesende Text-File.
Aber vermutlich geht dass so gar nicht, da das Applet ja dann "lokal" beim Benutzer läuft und die Resource dann nix "lokales" mehr ist, oder?
Naja... da ich erst seit letzten Freitag intensiv mit Java spiele halte ich meine Unwissenheit noch für verschmerzbar Man wächst mit seinen Aufgaben.
Für nützliche Tips bin natürlich trotzdem sehr dankbar.

d@niel

Kathrin · 11. Februar 2003

Hallo Daniel,
das Applet darf generell nicht auf lokale Dateien zugreifen, deswegen die Fehlermeldung, wohl aber auf die Dateien des Servers, auf dem es liegt. Ich würde den Zugriff evt. mal so ausprobieren:

url = new URL( location );
input = new BufferedReader(
new InputStreamReader( url.openStream() ) );

StringBuffer text = new StringBuffer("");
int readvalue;

while ((readvalue = inputstream.read()) != -1) {
text.append((char) readvalue);
}

Bei Bedarf solltest du dir die API zu java.net.URL vielleicht genauer anschauen.

Tschüss, Kathrin

d@niel · 12. Februar 2003

das erscheitn mir zwar ziemlich logisch, aber leider führt es auch nicht zum Erfolg. das problem verschiebt sich damit vom lokalen Rechner zur Web-Resource:

java.security.AccessControlException: access denied (java.net.SocketPermission 9.xxx.xxx.xxx:80 connect,resolve)

Also das gleich wie ursprünglich, nur anders halt. Den ganzen Kram mit den SecurityManagern verstehe ich (noch) nicht.
Java ist offenbar höllisch umständlich. Mit einem VB-Programm wäre ich längst fertig und es liefe schneller. Nur leider treffen ja andere die Entscheidungen, womit hier in Zukunft gearbeitet werden soll
:flop:

d@niel

stadolf · 16. Februar 2003

Habe Kathrins Code nochmal ausprobiert. Der funktioniert auf jeden Fall mit Connections zum localhost (also, wenn Du einen Webserver auf Deinem Rechner ansprichst). Werfen wir einen Blick in die Sun FAQs:

* Ein Applet darf _nicht_ auf das lokale Filesystem zugreifen !
* Diese Einschränkung besteht dann _und nur dann_ nicht, wenn der User dies explizit zulässt (Netscape hat so eine Option, oder man schreibt sich selbst ein .hotspot - properties file).
* Ein Applet darf aber _sehr wohl_ auf Server zugreifen, aber nur auf localhost oder genau den Server _von dem es geladen wurde_ .

Das heisst für Dich, Daniel, zum Testen: installier Dir entweder nen lokalen Webserver, sofern noch nicht vorhanden. Oder schieb das Applet auf den Server, von dem es lesen soll. Eine andere Möglichkeit gibt es nicht.

Das heisst - doch ! Aber nur, wenn es Deine Projektspezif. zulässt: Du kannst auf JNLP / Java Web Start umsatteln. Diese Plattform erlaubt sehr elegant die Installation von Java-Applikationen auf dem User-Client. Dafür ist nur eine installierte JWS-Version notwendig (ist die bei Windows XP seit dem neuesten Gerichtsurteil vorhanden ?!).

Ich habe folgenden Code sowohl lokal als auch auf dem Server (meineseite.de, ersetze mit Deiner URL) getestet, und es funktioniert !

Java

import java.io.*;
import java.net.*;


public class TestURLReaderApplet extends java.applet.Applet
{
  public void init()
  {
    try
    {
      String location= new String("http://www.meineseite.de/index.htm");
      URL url = new URL( location );
      BufferedReader input = new BufferedReader(new InputStreamReader( url.openStream() ) );
      StringBuffer text = new StringBuffer("");
      int readvalue;

      while ((readvalue = input.read()) != -1) 
      {
        text.append((char) readvalue);
      }

      System.out.println(new String(text));
    } 
    catch(Exception e)
    {
      e.printStackTrace();
    }
  }
}

Alles anzeigen

Noch ein Wort zu Deinem "Frustausstoß am Ende":

Zitat

Den ganzen Kram mit den SecurityManagern verstehe ich (noch) nicht.Java ist offenbar höllisch umständlich. Mit einem VB-Programm wäre ich längst fertig und es liefe schneller. Nur leider treffen ja andere die Entscheidungen, womit hier in Zukunft gearbeitet werden soll

Java ist alles andere als höllisch umständlich. Es ist gegen alle landläufigen Meinungen eher höllisch sicher. Das ist für Entwickler und User manchmal nicht grad bequem und wird meistens als umständlich abgetan. Aber so ists nunmal im Leben - Sekt oder Selters. Ein VB-"Programm" kannst Du IMHO auch nicht ohne ActiveX in Deine Seite einbauen wie ein Applet, und ich kenne auch niemanden, der den M$ Scripting Host aktiviert hat - weil der eine wirklich monsterfette Sicherheitslücke in Windows-Systemen darstellt (wie viele Würmer der letzten Jahre bewiesen haben).

Ein Wort zu Security-Managern: Diese Teile kannst Du zumindest in Applets nicht selbst konfigurieren. Ein Security-Manager ist eine definierte Schnittstelle zu JAVAs Umgebung, man kann keinen Security-Manager schreiben, der in der Lage wäre, nicht gesetzte Permissions einfach zu überladen ! Ein selbstgeschriebener Security-Manager ist vielmehr in der Lage, angemessen auf Sicherheitslücken hinzuweisen - wenn zB das Applet keine Leseberechtigung hat, kann man so dem User eine MessageBox anzeigen, etc.

Hoffe, das hat geholfen. Grüße, Stefan aus Berlin.

Achso, Berliner: Java-Fragen ? http://www.jug-berlin.de.vu

d@niel · 18. Februar 2003

im Vergleich zu VB ist Java höllisch umständlich, das ist sicher. A propos "sicher": die Sicherheit des Projektes ist mir absolut Wurscht, darum geht es dabei gar nicht.
Fakt ist auch, dass der o.g. Code bei mir nicht läuft. Ich habe das exakt so verwendet und natürlich "meine Seite...." durch was reales ersetzt. Es geht trotzdem nicht, sondern produziert diesen Müll hier:

java.security.AccessControlException: access denied (java.net.SocketPermission 9.xxx.xxx.xxx:80 connect,resolve)

Die angegebene Datei existiert definitiv und lässt sich z.B. mit dem Browser öffnen.
Java frustet weiterhin und ich sehe leider immer weniger sinnvolle Anwendungen, da ich keine Internet-Geschichten programmieren will, sondern in erster Linie lokale Anwendungen. Das o.g. Beispiel war eben nur mal ein Versuch. Aber wenn schon so wenige Zeilen Code mehr Zeilen Fehlertext produzieren.... Gute Nacht. Einfacher als Java verstehen ist wohl, die Strategen davon zu überzeugen, dass Java für meine(!!!) Zwecke ungeeignet scheint.

d@niel

jaBernet · 18. Februar 2003

Zitat

Original geschrieben von d@niel
im Vergleich zu VB ist Java höllisch umständlich, das ist sicher.

Das ist doch eine total blöde Aussage! Was meinst Du was einer sagen wird, der von Java auf VB umgestiegen ist? Es ist hier vor allem eine gewöhnungssache. Java ist sicherlich nicht umständlicher als VB. Sprachen wie Pascal, die Dich zwingen alle Variablen im Head zu deklarieren halte ich für umständlich.

Gruss
inflagranti

stadolf · 18. Februar 2003

Eine Aussage kann gar nicht so blöd sein Immerhin ist dieses Forum dafür da, um Aussagen zu treffen....

Ich bin absichtlich nicht auf diesen Satz eingegangen, weil dann immer 1000 FollowUps folgen, bis irgendein Moderator sich erbarmt und dem Krieg ein Ende setzt.

Dennoch ein paar virtuelle Schüsse in die Richtung :
Für VB Programmierer _ist_ Java sicherlich ein wenig schwer zu verstehen. Das seh ich als C++ _und_ Java Programmierer ähnlich. Aber Java hat im Gegensatz zu VB ein wirklich durchdachtes Klassenkonzept, das mit dem von C++ korrespondiert, aber die komplizierten Sachen weglässt. VB ist eigentlich IMHO als reine Programmiersprache ziemlich ungeeignet, da sie komplett (!) auf M$s COM-Klassenmodell aufsetzt und "nur" eine Schnittstellensprache zu den eigentlichen Komponenten darstellt - der eigentliche Grund, warum VB entworfen wurde war ja IMO der, dass M$ eine Sprache zur Automatisierung ihrer Businesssoftware (zB Office) benötigte. Daraus wurde dann VBA und daraus wird heute in Verbindung mit ASP.NET VB.NET.

Und das tragische dabei: M$s .NET Strategie ist zunächst nichts anderes als der verzweifelte Versuch, dem Business-Framework, das sich in den letzten Jahren etabliert hat und das zu weiten Teilen aus Java-Komponenten (EJB, J2EE, RMI, ...) besteht, endlich Paroli zu bieten. M$ geht dafür noch ein paar Schritte weiter, aber das ist nebensächlich.

Meine Empfehlung an alle VB Programmierer, die nicht bös gemeint ist: Tut Euch einen Gefallen und versucht, eine "richtige" Sprache zu lernen -> C++ oder Java. Damit werdet Ihr in der Welt ausserhalb von Microsoft und teilweise auch _in_ deren Welt viel besser dastehen. Jedenfalls, wenn Ihr was anderes ausser Automatisierungsapplikationen, Webfrontends oder Beispielprogramme für DLLs schreiben wollt. M$ bietet nebenbei gesagt auch etwas an, das fast aufs Haar genauso aussieht wie Java, aber nicht Java ist: es nennt sich C#.

Viele gutgemeinte Grüße. Mögen nun die 1000 FollowUps folgen.

d@niel · 18. Februar 2003

ich denke, es kommt immer auch auf die Art der Applikationen an. Und darauf, was am Ende für ein Produkt entsteht. Es gibt sicher Sachen, für die sich Java ganz hervorragend eigent, und für andere Dinge eben weniger.
Was nützt denn ein "sauberes, modernes und nicht M$iges" Programm, welches sagenhaft hässlich ist, sagenhaft langsam und vor dem sich der Benutzer gruselt. Dann doch lieber das "unkorrekte, unsaubere" VB-Programm, das aber seinen Zweck erfüllt, eine akzeptable Oberfläche bietet (die ohne sagenhafte Handstände manuell zusammenprogrammiert werden musste) und ordentlich läuft. Wie gesagt: es kommt auf die Anwendung an! Bisher geben mir meine VB-Applikationen recht. Und die Anwender derselben sind überwiegend zufrieden. Die Entscheidung in Richtung Java wurde mir auch mehr versucht aufzudrängen, von Leuten, die noch nie eine Zeile Code geschrieben haben, aber mal was von "java ist modern" gelesen haben. Das ärgert mich daran.
Und ausserdem soll/muss meine Applikation eine vorhandene (und definitiv nicht erstezbare, nicht änderbare, nicht selbstschreibbare) DLL eines ebenso vorhandenen Produktes nutzen (also Aufrufe aus dieser DLL). das scheint mir mit Java schlichtweg unmöglich, scheinbar geht das auch per JNI nicht. Noch ein Killer-Feature.
Da erscheint mir C# schon ehr als Alternative. Jedenfalls für meine Projekte.
Und nun Schluss damit, das war ja gar nicht Inhalt dieses Threads

d@niel

Jetzt mitmachen!

Teilen