Category Archives: Java

Java machts richtiger, aber leider auch komplizierter.

Posted on by

Vor einigen Monaten hatte Java bekanntlich ein schweres Problem in Sachen Sicherheit. Damals jagte eine Hiobsbotschaft die Nächste. Die Javaentwickler haben viel Häme über sich ergehen lassen müssen, haben aber daraus gelernt .

Java Applets werden nun nicht mehr direkt ausgeführt. Dazu kommen sehr restriktive Einstellungen unter denen Applets ausgeführt werden. Deswegen hier eine kurze Anleitung, wie Sie Applets wieder auf Webseiten aktivieren, denen Sie vertrauen können.

Windows:  „Startmenü“ -> „Einstellungen“ -> „Systemsteuerung“ -> „Java“

Sicherheitseinstellungen von Java unter Windows

Sicherheitseinstellungen von Java unter Windows

 

Um neue Webseiten einzutragen, klicken Sie auf „Siteliste bearbeiten“.

java-panel.windows-liste

Sicherheitseinstellungen Java: Domains freigeben

Einmal auf „Hinzufügen“ auswählen und dann einfach die Domain eingeben. Das wars schon.

Danach wird Java in der Webseite wieder korrekt ausgeführt. Wichtig ist das z.b. wenn Sie eine VNC Konsole benutzen wollen, da diese Anwendungen fast nur in Java zu haben sind.

Java Swing und das Repainten von Komponenten

Posted on by

Von Zeit zu Zeit muß man Dinge tun, welche die Entwickler von Swing nicht vorgesehen hatten. Da wäre z.B. das Updaten einer JTextArea, während das Programm läuft.

Kleines Beispiel:

        for(int i=0;i<names.length;i++ ) {
            infotext = "Uploading file ... "+names[i];
            if ( infotext.length()> 55 ) 
                    infotext = infotext.substring(0, 55);
            updateInfo( infotext );
            String link = p.uploadFile(names[i].trim(),"/");
            result += "File: "+names[i].trim()+"\nShare: "+link+"\n";
        }
    JTextArea text = new JTextArea("");

    public void updateInfo(String text) {
            this.text.setText(text);
    }

Jetzt sollte man annehmen, daß die JTextArea jeweil nach dem setText() den neuen Text anzeigt. Tut sie aber nicht und das betrifft nicht nur JTextArea, sondern so ziemlich alle Komponenten von Swing.

Warum ist das so ?

Swing cacht quasi die ganzen Änderungen und führt diese erst durch, wenn Ruhe eingekehrt ist, d.b. wenn das Programm wartet. Das passiert z.b. wenn eine Dialogbox angezeigt wird. Die Verarbeitung des Programms ist dann eingestellt und es wartet z.B. auf das Drücken des OK Buttons in einem InfoRequester.

Solange das Programm aktiv läuft, gibt es keine Updates, weil das Rechenleistung kostet und sich mit der Zeit einige Inhalteänderungen ergeben haben können, die man dann gemeinsam durchführen kann. So spart das Guisystem Zeit und Resourcen.

Nun ist das Delay einer solchen Sparmaßnahme natürlich kontraproduktiv, wenn es um die kontinuierliche Anzeige neuer Inhalte geht, wie z.b. einem Progressbar oder eben einem textlichen Infofeld wie einer JTextArea.

Die Swing API bietet für Komponenten nun eine Methode repaint() an, die Swing mitteilt, daß die Komponente sich geändert hat und neu gezeichnet werden muß. Soweit, so gut. Leider wird der Rendercall wie schon erwähnt irgendwann gemacht und damit kann man repaint() solange aufrufen, bis man schwarz wird.

Dies Problem haben viele Javaentwickler. Auf den diversen Hilfeseiten findet man die wildesten und vor allem komplett falschen Lösungen für das Problem, in dem Mantraähnlich repaint() oder validate() empfohlen wird.

Alles falsch Leute, die Lösung sieht so aus:

	
        public void updateInfo(String text) {
			this.text.setText(text);
			this.paintComponents( this.getGraphics() );
	}

this bezieht sich dabei auf den eigentlichen Frame z.B. das Panel in dem die Komponente untergebracht ist. paintComponents(g) zeichnet alles neu und damit auch den aktualisierten Text der Area. Der Grund wieso Swing mit Delays arbeitet zeigt sich deutlich, wenn man mehrfach pro Sekunde paintComponents(g) aufruft. Nicht nur daß man die Updates im Viewport sehen kann, es dauert auch so lange, daß man tatsächlich Performanceeinbrüche haben kann. Damit wäre geklärt, wieso es normalerweise delayed ist.

Fazit: Swing ist eindeutig zu langsam konstruiert.

Jersey, Pydio & the next Big thing – Part II

Posted on by

Ja, es hat länger gedauert als erwartet. Nicht nur Jersey steckt voller Ungereimtheiten, auch Pydio hat tolle Bugs auf Lager. Kombiniert man das, verschwendet man richtig viel Zeit.

Status: Es geht.

Update der verwendeten Tools: Jersey 1.18 ( jsr311-api-1.1.jar, asm-3.1.jar, jersey-bundle-1.18.jar, NEU: jersey-multipart-1.18.jar)

Der Fileupload:

Der FileUpload stellt sich in Jersey schwieriger dar, als man annehmen sollte, denn die spärlichen Beispiele sind einfach mal falsch, solange man nicht die Suchbegriffe benutzt,
die einen ohnehin schon auf die richtige Fährte gebracht haben : MultiPart.

Aber auch da gibt es Fallstricke die es zu umschiffen geht und weil das einfach nur nervt, gibts hier gleich die Lösung der Probleme:

Schritt 1:

                FormDataMultiPart form = new FormDataMultiPart();
                FormDataBodyPart p = new FormDataBodyPart(
                            FormDataContentDisposition
                                .name("userfile_0")
                                .fileName("Dateiname")
                                .build()
                            , new File("Dateiname")
                            , MediaType.MULTIPART_FORM_DATA_TYPE);
                form.bodyPart(p);

Damit man FormDataMultiPart benutzen kann, muß oben erwähntes JAR-File zum Projekt hinzugefügt werden. Danach ist es aber ganz einfach das File dann wirklich per REST hochzuladen. Wobei REST hier wohl der falsche Ausdruck ist, denn es ist ein simples MultiPart-Form, daß per POST hochgeladen wird. Das macht jeder Webbrowser genauso.

Schritt 2:

                response = resource.queryParam("get_action","upload")
                           .queryParam("dir","/")
                           .queryParam("secure_token", securetoken )
                           .header("Cookie", cookieheader )
                           .accept(MediaType.APPLICATION_XML)
                           .type(MediaType.MULTIPART_FORM_DATA)
                           .post(ClientResponse.class, form);

Jetzt muß man natürlich noch den Share Call per API iniziieren werden, damit ein Downloadlink für die Datei erzeugt wird. Das sagt sich jetzt so leicht, denn Pydio 5.2.0 und 5.2.1 sind an der Stelle einfach mal defekt. Da wir mit der REST API arbeiten, erwartet unser Client zurecht auch eine korrekt formulierte Antwort und dazu gehört auch die korrekte Länge der Antwort vom Server. Die Entwickler von Pydio haben es nun geschafft diesen Teil der API erfolgreich zu entschärfen. Statt der korrekten Länge des Links, kommt ein

Content-Length:  0

und damit kann Jersey nicht umgehen. Daher darf man nun erstmal das Pydio Quickfixen.Von der Isolation des Fehlers bis zum funktionierenden Fix der PHP Anwendung, vergingen rund 80 Minuten.

Ich hege ja die Hoffnung, daß mein Bugreport gelesen und bearbeitet wird. Zur Sicherheitslücke die ich letzte Woche an das Team von Charles geschickt habe, kam nur ein : „Wir schicken Dir Deine Mail zurück-kam also an“ Nachricht zurück. Ein Umgang mit Securityproblemen muß sich wohl erst noch entwickeln. Was übrigens für den an sich sicheren Code von Pydio spricht. „Gut“ ist allerdings was anderes. Kommentare fehlen da fast vollständig 🙂

Nachdem nun diese Klippen umschifft sind, kann die eigentliche Arbeit an der Anwendung beginnen.

JAXB XML Parsing kann man übrigens getrost vergessen, der XML Code der von Pydio kommt überfordert den Parser, so daß Elemente einfach verloren gehen. Ob da der Fehler bei Pydio liegt, oder der Parser Bugs hat, mag ich nicht beurteilen. Ich habe mir dann flugs einen eigenen SimpleXML-Parser mit XML-zu-Objekt Komponente geschrieben. Reflektion ist ne schöne Sache in Java.

Wenn Sie also vorhaben sollten, für Pydio in Java zu entwickeln, kommt einiges auf Sie zu. Sie dürfen sich aber gern melden, wenn Sie Fragen haben. Aufgrund der Bots die mein Blog zum Abladen von Schrott missbrauchen wollen, kann ich leider keine Kommentarfunktion freischalten 🙁