Problem mit ImageIO.write()

[Brainiac]

Ich hab folgende Code Passage:

            try {
                if (scaled) {
                    ImageIO.write(getScaledInstance(active.getFloorImage(x), 227, 120, RenderingHints.VALUE_INTERPOLATION_BICUBIC, true), "jpg", new File(khpSaveFilePath, activeForumImageFileName));
                    ImageIO.write(getScaledInstance(planning.getFloorImage(x), 227, 120, RenderingHints.VALUE_INTERPOLATION_BICUBIC, true), "jpg", new File(khpSaveFilePath, planningForumImageFileName));
                } else {
                    JOptionPane.showMessageDialog(this, new File(khpSaveFilePath, activeImageFileName).toString());
                    ImageIO.write(active.getFloorImage(x), "png", new File(khpSaveFilePath, activeImageFileName));
                    ImageIO.write(planning.getFloorImage(x), "png", new File(khpSaveFilePath, planningImageFileName));
                }
            } catch (Exception ex) {
                JOptionPane.showMessageDialog(this, ex.getMessage());
                Logger.getLogger(KHPlanner.class.getName()).log(Level.SEVERE, null, ex);
            }

Auf meinem lokalen Test Webserver gehen die ImageIO.write zeilen Problemlos. Egal ob ich das Programm als Applet oder über JNLP starte. Aber sobald ich das auf meinen Webspace ziehen. Schmiert er bei der ersten ImageIO.write Zeile ab. In der Exception wird aber auch nix ausgegeben. Wenn ich die ImageIO.write auskommentiere geht er weiter. Den Pfad für die Datei gibt er jeweils völlig korrekt aus. Das Jar ist signiert. Irgendwer ne Idee? Ich stehe da im Moment total auf dem Schlauch.

 

[Ark]

Ein Stacktrace wäre schon interessant … oder zumindest die konkrete Fehlermeldung.

Ark

 

[Brainiac]

Das ist ja das Problem es gibt keine. Ich dachte auch an ne AccessViolation geschichte oder so.

@Edit:
Und warum geht es wenn die url fürs Applet mit localhost beginnt und nicht mehr wenn sie mit khplanner.kilu.de beginnt? Das macht irgendwie keinen Sinn für mich.

 

[SlaterB]

was bedeutet denn
> Schmiert er bei der ersten ImageIO.write Zeile ab.

wie genau stellst du das fest, was passiert oder passiert nicht konkret?
bist du dir mit deinem Logging und Exception-Handling sicher?
im Zweifel auch auf einfache Varianten zurückgreifen, z.B. Fehlermeldung als String in statischer Liste abspeichern,
diese in einem späteren Request abfragen, gerne auch eigenen Datei öffnen und dort hineinschreiben,
zwischen jede einzelne Zeile gehört im Extremfall ein Log um alles genau nachvollziehen zu können:

log("vor"); // muss auf jeden Fall im Log erscheinen
try {
  // erste böse Codezeile
  log("nach 1");
  // zweite böse Codezeile
  log("nach 2");
  ..
} catch (Exception e) {
  log("Exception");
} finally {
   log("finally"); // muss auf jeden Fall im Log erscheinen
}

was genau bleibt an Log über? wenn 'vor' oder 'finally' fehlt, dann ist generell irgendwas mit Log kaputt, solange kann man nichts schaffen,
oder das Programm ist in einer Endlosschleife,
ansonsten ist nun interessant was dazwischen ankommt, alle Log-Ausgaben aller Zeilen oder wird doch Exception-Block angesteuert usw

 

[Brainiac]

Der ImageIO.write befindet sich in einer Schleife die eigentlich 5 Bilder rausschreiben soll.

Das Abschmieren gestalltet sich folgendermaßen:
Er loggt alles vor dem Try, vor dem ImageIO.write und alles im Finally Block.
Den ImageIO.write führt er nicht aus. Es entsteht keine Datei. Im catch kommt er aber nicht mit einer Exception. Bzw. Kommt nie im Catch-Block an.

Und die Schleife wird im ersten Durchlauf abgebrochen.

Das mir nicht Verständliche ist, das wenn ich das ganze aus Netbeans herraus starte (Application): geht alles wie gewünscht. Teste ich mit meinem lokalen Webserver, das Applet. Gehts auch. Starte ich die Application über den lokalen Webserver per JNLP gehts auch.

Starte ich das Applet, oder die Application von dem hoster kilu.de habe ich oben beschriebenes Verhalten. Macht das Sinn?

 

[SlaterB]

zum Hoster kann ich zunächst nichts direkt sagen,
eine kleine Hoffnung noch: fange Throwable statt Exception, gibts dann was im catch-Block?

im catch-Block bewege dich extrem vorsichtig, vielleicht wirft sowas komisches wie
> JOptionPane.showMessageDialog(this, ex.getMessage());
auf einem Rechner ohne Grafikkapazität wieder eine Exception, dann wird die ursprüngliche überhaupt nicht mehr geloggt,
falls du Zeile 11 noch drinhast, versuche es ohne

 

[Brainiac]

Der Tipp mit dem Throwable hats gebracht. Fehlermeldung bekommen und konnte behoben werden. Problem lag in einem von mir benutzten jar-File. Da hatte ich lokal ne andere Version als auf dem Server. In der Entstand der Fehler. Nun haben beide die gleiche Version und es passt wieder. Ich bin ja von einer Exception ausgegangen nur das keine kam, hatte mich sehr irritiert.

 

[SlaterB]

dass das höhere Throwable dieses catch überspringt ist ja halbwegs zu akzeptieren,
etwas bedenklicher dagegen, dass dann allgemein weiter außen nirgendwo mehr aufpasst?
nicht mal eine Standardausgabe des Server-Containers?

überlege ernsthaft eine allgemeine Struktur einbauen und diese durch try/catch zu sichern,
z.B. Basisklasse für alle Servlets oder vergleichbare Aktionsklassen