everflux

Firefox 4 ist seit gestern offiziell veröffentlicht worden – auch fuer Linux bzw. Ubuntu. Firefox 4 ist wesentlich schneller als der alte Firefox und verfügt über HTML5 Kompatibilität sowie ein aufgeräumteres Userinterface.

Wer ein Debian basiertes Linux System, wie z.B. Ubuntu, hat, sollte nach Möglichkeit Software über Pakete installieren. Zum Glück gibts es für Ubuntu ein eigenes PPA in dem stabile Versionen von Mozilla nach Veröffentlichung  bereitgestellt werden. Das spart einiges an Arbeit und bietet gegenüber dem Mozilla-Daily PPA den Vorteil, wirklich eine stabile Version zu nutzen.

Wer also unter Ubuntu Firefox 4 schon jetzt nutzen möchte, bevor dieser in den normalen Paketquellen bereitgestellt wird (falls das überhaupt geschieht und nicht erst im nächsten Ubuntu Release), der kann folgendes in eine Kommandozeile eintippen:

sudo add-apt-repository ppa:mozillateam/firefox-stable
sudo apt-get update
sudo apt-get upgrade

Viel Spaß mit Firefox 4 unter Ubuntu!

Weitere Neuerungen in Firefox 4:

• Firefox Sync bietet die Synchronisierung von Bookmarks und Einstellungen über mehrere Rechner
• Von der neuen – stark beschleunigten – JavaScript Engine profitiert das gesamte Userinterface, nicht nur Webseiten
• Firefox 4 ist mit vielen Erweiterungen nicht kompatibel (ok, das ist nichts neues nach einem Firefox Update)
• „do not track“ Einstellung für verbesserte Privatssphäre
• Mein derzeitiger Favorit: App Tabs, mittels Rechtsklick auf ein Tab kann dieser als „permanent“ gespeichert werden – praktsch für Twitter, Facebook und co

Wer ein wenig schauen möchte, wo Firefox eingesetzt wird: http://glow.mozilla.org/

JUnit 4 bringt die (bessere) Syntax von assertThat über Hamcrest Matcher mit. Und nicht nur die Syntax ist besser, es gibt für viele Testfälle bereits „Matcher“, die das Leben erleichtern können.
Genauso kann einem das Leben aber auch erschwert werden: JUnit bringt eben nur ein Subset der Hamcrest Funktionalität mit. Den Rest kann man über die entsprechenden Hamcrest Bibliotheken hinzufügen. Und genau da gilt es nun aufzupassen: JUnit bringt eben bestimmte Versionen der Bilbiotheken mit – und dann kann es zu Konflikten kommen, die sich zur Test-Laufzeit erst zeigen:

org.hamcrest.core.AnyOf.anyOf([Lorg/hamcrest/Matcher;)Lorg/hamcrest/core/AnyOf;
java.lang.NoSuchMethodError: org.hamcrest.core.AnyOf.anyOf([Lorg/hamcrest/Matcher;)Lorg/hamcrest/core/AnyOf;
at org.hamcrest.text.IsEmptyString.(IsEmptyString.java:18)

Die Lösung ist dann JUnit ohne eigene Versionen von Hamcrest etc. zu verwenden (die „no-dependencies“ Version), und entsprechend die Abhängigkeiten selber aufzulösen.

Mit Maven sieht dann der Einsatz von JUnit, Mockito und Hamcrest z.B. folgendermaßen aus:

<dependency>
  <groupId>junit</groupId>
  <artifactId>junit-dep</artifactId>
  <version>4.8.2</version>
  <scope>test</scope>
</dependency>
<dependency>
  <groupId>org.mockito</groupId>
  <artifactId>mockito-core</artifactId>
  <version>1.8.5</version>
  <scope>test</scope>
</dependency>
<dependency>
  <groupId>org.hamcrest</groupId>
  <artifactId>hamcrest-core</artifactId>
  <version>1.2.1</version>
  <scope>test</scope>
</dependency>
<dependency>
  <groupId>org.hamcrest</groupId>
  <artifactId>hamcrest-library</artifactId>
  <version>1.2.1</version>
  <scope>test</scope>
</dependency>

Pidgin ist mein bevorzugter IM Client – auch unter Ubuntu Linux. Seit geraumer Zeit jedoch ärgerte mich Pidgin, es gab Probleme mit der Bonjour Kommunikation. Pidgin meldete
Unable to send the message, the conversation couldn't be started.
obwohl mein Gesprächspartner aufgeführt war. Die Umstände waren etwas schwer zu reproduzieren – mit einigen Rechnern funktionierte es, mit anderen nicht. Und genau das half mir auch eine „Lösung“ zu finden: Wurde die Kommunikation von einem Rechner aus initiiert, bei dem ipv6 deaktiviert war, funktionierte das ganze. Sonst nicht.

Unter der Haube kommt „avahi“ zum Einsatz – übrigens auch wenn es um remote Desktop Verbindungen geht. Hier hatte ich nämlich vergleichbare Probleme. Um das Bonjour und Remote-Desktop Problem zu loesen habe ich in der /etc/avahi/avahi-daemon.conf die Einstellung
use-ipv6=yes
auf
use-ipv6=no
geändert. Danach noch schnell den Avahi Dienst neu starten, und die  Probleme sind behoben. Pidgin selber wird in der nächsten Version auch einen Bugfix für dies Problem beinhalten, solange wollte ich aber nicht warten.

Lange Suche, kleine Ursache: Wenn man sich mit einem Linux Rechner nicht mit einem Linksys / Cisco WLAN Router verbinden kann, und dabei Meldungen wie z.B.


NetworkManager[1036]: (wlan0): supplicant connection state: associating -> disconnected
NetworkManager[1036]: (wlan0): supplicant connection state: disconnected -> scanning
wpa_supplicant[1234]: Trying to associate with 00:14:bf:29:c4:23 (SSID='sforce-wpa' freq=2447 MHz)
NetworkManager[1036]: (wlan0): supplicant connection state: scanning -> associating
kernel: [ 417.694909] wlan0: authenticate with 00:14:bf:29:c4:23 (try 1)
kernel: [ 417.696781] wlan0: authenticated
kernel: [ 417.697518] wlan0: associate with 00:14:bf:29:c4:23 (try 1)
kernel: [ 417.700259] wlan0: RX AssocResp from 00:14:bf:29:c4:23 (capab=0x431 status=17 aid=0)
kernel: [ 417.700267] wlan0: 00:14:bf:29:c4:23 denied association (code=17)
kernel: [ 417.700297] wlan0: deauthenticating from 00:14:bf:29:c4:23 by local choice (reason=3)


auftauchen, dann handelt es sich um folgende Phänomen: Der Router ist der Meinung, dass er voll ist, und bittet den Client, sich mit einem anderen WLAN Access Point zu verbinden.

Windows Rechner ignorieren das, und verbinden sich dennoch mit dem Access Point, während Linux – in diesem Fall ein mit Ubuntu Maverick ausgestatteter Thinkpad – der Bitte Folge leistet. Er bricht den Verbindungsaufbau mit dem Router bzw. WLAN Access Point ab.

Leider ist davon in der GUI von Ubuntu (Network Manager) nichts zu sehen, sondern es dauert einfach sehr lange, bis erneut der Dialog zur Eingabe des WLAN Passwort auftaucht. Ein Blick in „dmesg“ oder die Protokolldateien offenbart dann das Problem.

In meinem Fall ist der Router ein Linksys WRT mit Tomato Firmware – hier habe ich dann einfach die Anzahl der erlaubten Clients erhöht.

Wie bereits in meinem anderen Eintrag zu Glassfish 3.1 beschrieben, ist seit der Implementierung der Servlet 3.0 Spezifikation in Glassfish 3.1 der Session Cookie standardmäßig auf „httpOnly“ gesetzt – dies kann Probleme mit einigen JavaScript Frameworks verursachen.

In dem web.xml Deploymentdescriptor kann dies umkonfiguriert werden, im glassfish-web.xml Descriptor ist dafür leider keine Möglichkeit vorgesehen. Weblogic, auch von Oracle mit BEA zugekauft, verhält sich dabei genauso, auch hier ist der Session Cookie auf httpOnly gesetzt – kann jedoch über den Weblogic spezifischen Deployment Descriptor unabhängig von der web.xml umkonfiguriert werden.

Und Glassfish 3.1 unterstützt nun auch ein Subset des Weblogic Deployment Descriptors um Weblogic kompatibel zu sein. (Vermutlich ist dies auch ein Grund, aus dem die Cookies httpOnly sind, um mit Weblogic konform zu sein.) Auch wenn es komisch ist, dass Glassfish selber keine Möglichkeit vorsieht das Verhalten im eigenen Deployment Deskriptor zu konfigurieren – über den Umweg des Weblogic spezifischen Descriptors geht es dann:

<?xml version="1.0" encoding="UTF-8"?>
<weblogic-web-app xmlns="http://xmlns.oracle.com/weblogic/weblogic-web-app">
<session-descriptor>
<cookie-http-only>false</cookie-http-only>
</session-descriptor>
</weblogic-web-app>