Eine schöne Sache an der Android-Plattform ist, dass man auch unter Linux Apps entwickeln kann. Java und die Entwicklungsumgebung Eclipse steht als fertiges Paket zur Verfügung, und bei Google können die Entwicklertools kostenlos heruntergeladen werden.

Das Testen erfolgt entweder über einen Emulator, oder man geht gleich ans Eingemachte und testet seine Anwendung auf echter Hardware. Bevor das möglich ist, muss Fedora das Smartphone bekannt gemacht werden. Dazu wird mit Root-Rechten die Datei /etc/udev/rules.d/51-android.rules angelegt und mit folgendem Inhalt versehen:

SUBSYSTEM=="usb",SYSFS{idVendor}=="0bb4",SYMLINK+="android_adb",MODE="0666"

Unter idVendor wird die jeweilige Hersteller-ID des Smartphone-Herstellers eingetragen. Eine Tabelle der Vendor IDs gibt es ebenfalls bei Google. Wenn mehrere Smartphones verschiedener Hersteller zum Einsatz kommen, können entsprechend weitere Zeilen ergänzt werden.

Als nächstes muss auf dem Android-Phone das USB-Debugging aktiviert werden. Den Menüpunkt findet man unter Einstellungen → Anwendungen → Entwicklung → USB-Debugging aktivieren.

Wenn man nun seinen Androiden per USB anstöpselt und in dem Android-SDK das Kommando

platform-tools/adb devices

aufruft, sollte das Smartphone aufgelistet werden. Es steht dann als Zielplattform für die Entwicklung zur Verfügung.

For String properties that may contain more than 255 characters, it is advised to add a @Lob annotation to the appropriate property. For example, to keep a comment text in an entity, one would write:

@Lob
public String getComment() { return comment; }
public void setComment(String comment) { this.comment = comment; }

On PostgreSQL, a large string is usually kept in a TEXT column (instead of VARCHAR). However, after updating to Hibernate 3.6, an exception was suddenly thrown when accessing such a property (along with an SQLState: 22003 from PostgreSQL):

org.postgresql.util.PSQLException: Bad value for type long : This is some text...
	at org.postgresql.jdbc2.AbstractJdbc2ResultSet.toLong(AbstractJdbc2ResultSet.java:2796)
	at org.postgresql.jdbc2.AbstractJdbc2ResultSet.getLong(AbstractJdbc2ResultSet.java:2019)
	at org.postgresql.jdbc4.Jdbc4ResultSet.getClob(Jdbc4ResultSet.java:43)
	at org.postgresql.jdbc2.AbstractJdbc2ResultSet.getClob(AbstractJdbc2ResultSet.java:384)
        ... and more

Obviously, the PostgreSQL connector tried to interprete the textual content as a long integer now, which - of course - results in a failure. PostgreSQL knows two ways of storing binary large objects, either as BYTEA within the table space, or as OID in a separate place and referenced by a numerical identifier. It seems that Hibernate 3.6 suddenly treats TEXT columns like OID columns as well.

In the internet, I have found similar problems related to @Lob annotated byte[] properties. A common solution was to add a @Type annotation to the property.

An attempt to add @Type(type = "org.hibernate.type.MaterializedClobType") did not help at all. Instead, @Type(type = "org.hibernate.type.TextType") did the trick:

@Lob
@Type(type = "org.hibernate.type.TextType")
public String getComment() { return comment; }
public void setComment(String comment) { this.comment = comment; }

Update: An alternative proposed by valsaraj is to use @Column(columnDefinition = "text"), which requires not to use @Lob at Strings at all:

@Column(columnDefinition = "text")
public String getComment() { return comment; }
public void setComment(String comment) { this.comment = comment; }

I think this is the better solution, however it requires the underlying database to support the text column type.

For PostgreSQL, it now works fine again, even without needing to alter the table column type. However I couldn't check the impact of the annotation on other DBMS (like Oracle). Your feedback is welcome.

Soeben habe ich die wichtigsten Artikel aus dem früheren Fedorablog freigegeben. Sie sind (zusammen mit mittlerweile ein paar neuen Artikeln) unter der Kategorie Fedorado zu finden.

Der Fedorablog war ein von mir betriebener Blog, der sich auf Fedora-Linux spezialisiert hatte und auf fast vier Jahre Laufzeit zurückblicken konnte. Vor etwa anderthalb Jahren habe ich den Blog dann offline gestellt. Seitdem waren die Artikel nicht mehr verfügbar.

Eigentlich hatte ich geplant, sie schnellstmöglich in meinen privaten Blog, der shredzone, umzuziehen, aber die Arbeiten an der eigenen Blogsoftware dauerten dann doch wesentlich länger als erwartet. Wie auch immer: jetzt sind sie wieder da! 😀

Ich habe nicht alle Artikel aus dem alten Blog übernommen. Weggefallen sind im Wesentlichen veraltete Artikel, die inhaltlich mittlerweile keine Relevanz mehr haben (zum Beispiel waren das Ankündigungen zu früheren Fedora-Releases).

Viel Spaß beim Stöbern! Ich freue mich schon, jetzt auch wieder mehr über Fedora schreiben zu können, wenn auch nicht mehr in dem Umfang wie im früheren Fedorablog.

I stumbled upon a strange issue when I recently deployed a JSF 2.0 web application. The application was developed using Jetty, and was working fine there. However when I deployed the application on a server, the page layout was utterly broken and Firefox complained that it would not load some CSS resources because of the wrong content type application/xml+xhtml.

On the server, a Tomcat is connected to an Apache web server via mod_proxy and mod_proxy_ajp. I found out that the Tomcat itself delivered the CSS resources without a Content-Type header, but the Apache web server returned a Content-Type: application/xml+xhtml. Actually, mod_proxy always adds a Content-Type header if it is missing, and tries to guess the right content type by the file suffix.

I searched the net for a proper solution of this issue, but found none. After some experiments, a working solution was to configure the Apache web server to force the content type of all .css.xhtml files to text/css:

<LocationMatch "\.css\.xhtml$">
    ForceType text/css
</LocationMatch>

However I don’t know if this is the best practice. A likely better solution would be the Mojarra Faces servlet to return a proper content type for the CSS files.

Nachdem die Installation von Fedora 13 auf dem Lenovo ThinkPad X100e nicht gerade besonders glatt lief, war ich sehr gespannt, wie sich Fedora 14 alias Laughlin auf dem System macht und welche Probleme zwischenzeitlich behoben wurden.

Schon beim ersten Start gab es eine positive Überraschung. Waren bei Fedora 13 noch Kernel-Optionen notwendig, um das System zu starten, fährt es nun bei Fedora 14 ohne Murren mit Plymouth hoch. Probleme gab es bei Fedora 13 außerdem mit der Steuerung der Hintergrundbeleuchtung und mit der Audioschnittstelle. Laughlin konnte auch hier punkten. Die Helligkeit lässt sich regeln, und endlich verstummen auch die eingebauten Lautsprecher, wenn man einen Kopfhörer anschließt. Das Suspend/Resume arbeitet nun ebenfalls einwandfrei, ohne dass ein Quirk notwendig ist. Das X100e geht problemlos schlafen und steht nach dem Aufwachen sofort wieder bereit.

Der für WLAN notwendige Treiber hat offenbar immer noch keinen Einzug in den Kernel erhalten, so dass es bei Fedora 14 weiterhin notwendig ist, den Treiberquelltext von Realtek herunterzuladen und selbst zu kompilieren. Hoffen wir, dass diese Schritte mit Fedora 15 der Vergangenheit angehören werden.

Eine Überraschung war, dass das Touchpad nun auch Multitouch unterstützt. Nach Installation des Pakets gpointing-device-settings konnten die entsprechenden Optionen ausgewählt werden, um zum Beispiel zum Scrollen mit zwei Fingern über das Touchpad zu wischen.

Vom fehlenden WLAN-Treiber abgesehen, zeigt sich Fedora 14 auf dem X100e von seiner besten Seite. Es macht richtig Spaß, mit dem Netbook zu arbeiten.