tiger rag

Beim Schreiben meines letzten Beitrags fiel mir auf, daß Firefox 3.0 unter Mac OS X und unter Windows Vista (nicht jedoch unter Linux) ein Problem mit dem CSS-Attribut overflow: auto hat. Über diesen Fehler fand ich nichts im Netz, daher hier eine Beschreibung und die Lösung des Problems.

Das Problem betrifft einzeilige Blockelemente, in meinem Fall Codebeispiele, die so notiert sind:

<pre><code>print "That's a string with plenty of characters, but not too much sense"</code></pre>

Theoretisch sollte es ausreichen, das <pre>-Element mit overflow: auto zu formatieren. Jedoch nicht so will es der Firefox. Im Gegensatz zu Safari und Opera zeigt er dort, wo er sollte, bei Einzeilern keinen Scrollbar an.

Beheben läßt sich das Problem relativ einfach. Hat man beispielsweise font-size: 11px; definiert, so läßt sich der Mac OS X-Firefox hiermit zu einer korrekten Anzeige überreden:

pre {
    min-height: 15px;
    overflow: auto;
}

Leider machen es einem weder Internet Explorer noch Windows-Firefox so einfach. Um auch diese beiden zur Anzeige eines Scrollbar zu bewegen, muß min-height: 20px; notiert werden. Das sieht dann leider nicht mehr ganz so hübsch aus … Wer möchte, kann ja noch eine Weiche einbauen ;)

Letztens wollten wir auf Arbeit aus Second Life heraus die Twitter-API benutzen. Sollte wohl kein Problem sein, gibt es doch eine schöne Dokumentation zu letzterer. Da heißt es unter anderem:

The Twitter API tries to conform as much as possible to the design principles of Representational State Transfer (REST) … Twitter presently supports the following data formats: XML, JSON, and the RSS and Atom syndication formats.

Na prima, dann gibt’s wohl keine Schwierigkeiten ;) Wenn man wie z.B. in Linden Scripting Language nicht die Möglichkeit hat, Authentifizierungsdaten mit in den HTTP-Header zu packen, kann man diese REST-Resource verwenden, um ein Update an einen Twitter-Account zu schicken:

http://<username>:<password>@twitter.com/statuses/update.xml

Das .xml bezeichnet keine Datei, sondern eine Resource, die in der HTTP-Response etwas im XML-Format liefert. Analog dazu gibt es auch diese Resource, die eine Antwort als JSON-String zurückgibt:

http://<username>:<password>@twitter.com/statuses/update.json

Jetzt will man natürlich ganz toll RESTful sein und einen POST an diese Resource schicken. Aber es will und will nicht funzen. Kein Twitter-Update ist zu sehen, auch keine Fehlermeldung, sondern ein braver Status 200 kommt zurück. Nach etlichen Stunden Haareraufens und unzähligen Verwünschungen fand ich dann endlich irgendwo in einer Google Group klitzeklein und ganz am Rande die Lösung.

Man muß zwar den Request als POST abschicken, aber trotzdem wie einen GET aufbauen. Also so:

http://<username>:<password>@twitter.com/statuses/update.xml?status="Dieser Text soll bei Twitter zu lesen sein!"

Vielleicht sollte man ein solches bizarres Feature auch dokumentieren, wenn man schon eine API zur Verfügung stellt und wohl auch wünscht, daß diese benutzt wird?!? Nicht jeder hat die Nerven dafür, sich sowas zu erärgern!

Zum Exportieren von MySQL-Datenbanken nach SQLite gibt es bei http://www.sqlite.org/ ein kleines Shellscript, das aber bei mir leider nicht so ganz zufriedenstellend funktionieren wollte. Vor allem nicht mit diesem Beitrag hier ;) Darum habe ich mir erlaubt, das Script ein wenig zu modifizieren:

#!/bin/sh
if [ "x$1" == "x" ]; then
    echo "Usage: $0 <dbname>"
    exit
fi

if [ -e "$1.db" ]; then
    echo "$1.db already exists.  I will overwrite it in 15 seconds if you do not press CTRL-C."
    COUNT=15
    while [ $COUNT -gt 0 ]; do
        echo "$COUNT"
        sleep 1
        COUNT=$((COUNT - 1))
    done
    rm $1.db
fi

mysqldump -u root -p --compact --compatible=ansi --default-character-set=binary $1 |
grep -v '^\(  KEY "\)' |
grep -v '^\(  UNIQUE KEY "\)' |
grep -v '^\(  PRIMARY KEY \)' |
grep -v '^\(SET \)' |
sed 's/ / /g' |
sed 's/ primary key autoincrement/ primary key autoincrement/gi' |
sed 's/ smallint([0-9]*) / integer /gi' |
sed 's/ tinyint([0-9]*) / integer /gi' |
sed 's/ int([0-9]*) / integer /gi' |
sed 's/ ]* / /gi' |
sed 's/ enum([^)]*) / varchar(255) /gi' |
sed 's/,]*//gi' |
sed 's/\\//g' |
sed 's/\\"/"/g' |
perl -e 'local $/;$_=<>;s/,\n\)/\n\)/gs;print "begin;\n";print;print "commit;\n"' |
perl -pe '
if (/^(INSERT.+?)\(/) {
    $a=$1;
    s/\\'\''/'\'\''/g;
    s/\\n/\n/g;
    s/\),\(/\);\n$a\(/g;
}
' > $1.sql

cat $1.sql | sqlite3 $1.db > $1.err
ERRORS=`cat $1.err | wc -l`
if [ "$ERRORS" == "0" ]; then
    echo "Conversion completed without error. Output file: $1.db"
    rm $1.sql
    rm $1.err
else
    echo "There were errors during conversion. Please review $1.err and $1.sql for details." fi

Leider werden mit dieser Version alle Zeilenumbrüche, die innerhalb eines INSERT INTO <table> in der Form \n erscheinen, durch tatsächliche Zeilenumbrüche ersetzt. In Codebeispielen innerhalb von Artikeln können aber auch \n vorkommen, siehe oben. Solche Codebeispiele werden dann zu wirrem Wirrwarr. Also muß noch eine weitere Verbessserung eingebaut werden.

Allerdings ist es etwas kniffelig, mit Regexen die zu ersetzenden \n von denen, die in Codebeispielen drinbleiben sollen, zu unterscheiden. Ich habe zwar ein paar Sachen mit Backreferences ausprobiert, aber aus Zeitmangel gab ich mich vorerst damit zufrieden, in obigem Script die Zeile

s/\\n/\n/g;

durch

s/(?<!(\s<code>))(\\n)(?!(\\\)|(\"))|(\/)|(\$)|(\)))/\n/g;

zu ersetzen. Das ist vielleicht nicht besonders elegant und deckt natürlich lange nicht alle denkbaren Fälle ab, in denen \n in Codebeispiel-Zeilen erscheinen kann. Wenn meine Muße es zuläßt, werde ich demnächst eine bessere Lösung suchen, hoffentlich finden und hier veröffentlichen.

Nun ist es wieder einmal Zeit für einen Relaunch meiner Homepage, nachdem ich bereits vor einiger Zeit beruflich unter die Django-Coder gegangen und ohnehin längst bei Wordpress an die Grenzen dessen kruden Codes gestoßen war. Auf der Suche nach einer Codebase für einen Django-basierten Blog stieß ich alsbald auf Byteflow, welches bereits sehr gut ausgereift ist und alles bietet, was ich brauche. Vielen Dank an die Byteflow-Programmierer aus der Ukraine für ihre exzellente Arbeit! Большое спасибо украинским программистам Byteflow за отличную работу!

Bei der Gelegenheit stand auch gleich ein Umstieg auf Lighty mit FastCGI an, da der Apache mir für meine Privatzwecke langsam zu schwerfällig wurde. Ebenso ist die Datenbank der Wahl nunmehr SQLite.

Was dagegen die Entwicklungsumgebung für’s Webworking angeht, bleibe ich sowohl auf der Arbeit als auch privat weiterhin Eclipse treu. Als Plugins verwende ich Pydev Extensions für Python, Amateras HTML Editor für HTML, CSS und Javascript sowie ByronStar für Linden Scripting Language. Die Anbindung an SVN übernimmt wie immer Subclipse.

Wie die Erfahrung lehrt, tauchen bei PHP immer wieder seltsame undokumentierte Fehler auf, die ein bestimmtes Minor Release betreffen. So wieder einmal geschehen bei meinem ersten Ansatz, Typo3 auf meinem Entwicklungsrechner zu installieren.

Aber der Reihe nach. Der Einfachheit halber entschied ich mich für YAML für TYPO3, um schnell und ohne große Mühe eine vorgefertigte Seitenstruktur zu erhalten, die ich als Ausgangsbasis für meine Privathomepage benutzen konnte. Dessen Installation sowie die der Extensions, die ich vorderhand für eine schicke Ajax-Bildergalerie benutzen wollte (ce_gallery, dam, dam_catedit, dam_file und ameos_dragndropupload), lief auch problemlos ab. Schien ja eine feine Sache zu sein! Doch beim ersten Hineinfummeln in dam kam gleich die Ernüchterung. Der Aufruf von Media / Datei im Typo3-Backend lieferte diese “hübsche” Fehlermeldung:

Fatal error: Cannot re-assign $this in /home/user/public_html/typo3/typo3conf/
ext/static_info_tables/class.tx_staticinfotables_syslanguage.php on line 43

Nun war für mich als Typo3-Anfänger erstmal guter Rat teuer! Was kann das sein? Vielleicht braucht man eine neuere Version der Extension static_info_tables? Mit der scheint es ja irgendwas zu tun zu haben. Aber leider gibt’s keine neuere Version. Es muß wohl an was anderem liegen.

Irgendwo in den Tiefen des Web fand ich dann eine vage Vermutung, daß der Fehler mit PHP 5.2 zu tun haben könnte. Solche Sachen kamen mir irgendwie bekannt vor. Also wurde die bei mir vorhandene PHP-Version 5.2.4 kurzerhand mittels

~$ apt-get remove php5

entfernt und unter
http://museum.php.net/php5/php-5.1.6.tar.bz2
die Version 5.1.6 heruntergeladen. Leider sind in den offiziellen Debian-Repositories keine fertig kompilierten Pakete für diese “museumsreife” Version mehr vorhanden, also muß mal wieder selber kompiliert werden.

Dazu werden vorher gegebenenfalls noch ein paar zusätzliche Pakete benötigt:

~$ apt-get install flex libxml2-dev libmysqlclient15-dev \
libpng3 libpng3-dev libjpeg62 libjpeg62-dev \
libgmp3c2 libgmp3-dev libmcrypt4 libmcrypt-dev \
libreadline5 libreadline5-dev

Dann wird das Quellcodepaket von PHP 5.1.6 entpackt, in das entstandene Verzeichnis gewechselt und dort das configure-Skript mit einer Reihe von Parametern aufgerufen:

~$ ./configure --with-apxs2=/usr/bin/apxs2 --with-dom --with-ftp \
--with-gettext --with-gmp --with-mcal \
--with-mcrypt --with-mysql --with-readline \
--with-ttf --with-xml --with-zlib=yes \
--with-gd --with-openssl --with-iconv \
--with-soap --with-pear --disable-debug \
--enable-bcmath --enable-calendar --enable-ctype \
--enable-dbase --enable-discard-path --enable-exif \
--enable-filepro --enable-force-cgi-redirect --enable-ftp \
--enable-gd-imgstrttf --enable-gd-native-ttf --enable-inline-optimization \
--enable-magic-quotes --enable-mbstr-enc-trans --enable-mbstring \
--enable-mbregex --enable-memory-limit --enable-safe-mode \
--enable-shmop --enable-sigchild --enable-sockets \
--enable-sysvsem --enable-sysvshm --enable-track-vars \
--enable-trans-sid --enable-versioning --enable-wddx \
--enable-yp

Es folgt der Compilerlauf:

~$ make

Danach könnte das neu kompilierte PHP 5.1.6 mittels

~$ make install

installiert werden. Allerdings an der Debian-Paketverwaltung “vorbei”. Da ich jedoch Wert auf ein gepflegtes System lege, bei dem sich alle Pakete jederzeit wieder sauber deinstallieren lassen, verwende ich zum Installieren von selbstkompilierter Software stets das Programm checkinstall. Dieses wird gegebenenfalls installiert:

~$ apt-get install checkinstall

checkinstall erstellt aus den kompilierten Binaries zunächst ein Debian-Paket (in diesem Fall namens php_5.1.6-1_i386.deb) und installiert dieses danach mittels dpkg. Der Aufruf dazu lautet einfach:

~$ checkinstall make install

Dieses Paket läßt sich dann, falls man es jemals wieder loswerden möchte, einfach mit:

~$ dpkg -r php

sauber deinstallieren.

Weitere Informationen zu checkinstall finden sich auf der Projekthomepage:
http://www.asic-linux.com.mx/~izto/checkinstall/
und in Linuxwiki:
http://linuxwiki.de/CheckInstall

Wenn soweit alles geklappt hat, wird der Apache neugestartet:

~$ /etc/init.d/apache2 restart

Dabei kann es noch zu folgendem Fehler kommen:

apxs:Error: Activation failed for custom /etc/apache2/httpd.conf file..
apxs:Error: At least one `LoadModule' directive already has to exist..

Dann muß in /etc/apache2/httpd.conf folgender Eintrag vorgenommen werden:

<IfModule mod_php5.c>
AddType application/x-httpd-php .php .phtml .php3
AddType application/x-httpd-php-source .phps
</IfModule>
LoadModule php5_module /usr/lib/apache2/modules/libphp5.so

Nun nochmals ein Apache-Neustart:

~$ /etc/init.d/apache2 restart

Jetzt sollte alles wie gewünscht laufen – der Fehler im Typo3-Backend ist weg, und der Konfiguration der schicken Ajax-Bildergalerie steht nichts mehr im Wege.

Natürlich ist so ein Downgrade nicht gerade eine sehr elegante Angelegenheit. Besonders unschön finde ich, daß die seit PHP 5.2.0 vorhendene JSON-Funktionalität (JavaScript Object Notation; diese wandelt PHP-Arrays in Transportstrings um, die bei einem Ajax-Request auf der aufrufenden Seite mittels Javascript in Objekte “dekodiert” werden können, siehe http://www.json.org/) damit futsch ist. Tja … das sind halt so die Kompromisse, die man manchmal eingehen muß … Hauptsache ist, daß ich jetzt mit Typo3 weiterfrickeln kann :)

Leider gibt es im Moment keine einfache Möglichkeit, Tomcat aus Debian-Paketquellen zu installieren. Man hört auch häufig, Tomcat sei besonders schwierig und kryptisch zu installieren, aber so schlimm ist es wieder nicht, wenn man sich schon ein bißchen mit Linux auskennt ;)

Hier eine kleine Einführung dazu, was Tomcat eigentlich ist und was er macht:
http://tomcat.apache.org/tomcat-5.5-doc/jasper-howto.html

Ich gehe in diesem Tutorial davon aus, daß man sich eine lokale Entwicklungs- und Testumgebung für die JSP- und Servlet-Entwicklung schaffen möchte und daß Apache 2.2.x bereits installiert und lauffähig ist. Daher sollte man als allererstes nachsehen, welche Java-Version überhaupt installiert ist:

~$ java -version
java version "1.5.0_13"

Wenn eine Version älter als 1.5.0 (Java 5) vorhanden ist, sollte unbedingt ein Update auf diese gemacht werden. Unter Debian geschieht dies mittels

~$ apt-get install sun-java5-jre sun-java5-jdk

Zur Konfiguration von Eclipse als IDE der Wahl für die JSP- und Servlet-Entwicklung empfehle ich einen Blick auf dieses hervorragende Tutorial in deutscher Sprache:
Teil 1: http://dm.zimmer428.net/index.php/archives/238
Teil 2: http://dm.zimmer428.net/index.php/archives/239

Seit neuestem gibt es auch bereits fertig vorkonfigurierte Eclipse-Pakete für die JSP- und Servlet-Entwicklung, darauf werde ich jedoch in meinem nächsten Tutorial über die Installation von kompletten J2EE-Umgebungen mit JBoss unter Debian zurückkommen.

Tomcat installieren und konfigurieren

Dazu wird zunächst die neueste Version von Tomcat 5.5 von der Downloadseite heruntergeladen:
http://tomcat.apache.org/download-55.cgi

Das erhaltene Archiv hat eine Bezeichnung ähnlich dieser:

apache-tomcat-5.5.x.tar.gz

wobei das x die Versionsnummer des jeweiligen Minor Release anzeigt, im Moment also apache-tomcat-5.5.25.tar.gz. Unter der Annahme, daß das Archiv nach /home/user/tmp heruntergeladen wurde, wird das Archiv entpackt:

~$ cd /home/user/tmp
~$ tar xvzf apache-tomcat-5.5.25.tar.gz

Nun wird das Verzeichnis apache-tomcat-5.5.25 an das gewünschte Ziel kopiert, hier beispielhaft nach /opt:

~$ mv apache-tomcat-5.5.25 /opt
~$ cd /opt
~$ ln -s apache-tomcat-5.5.25 tomcat

Tomcat soll als Daemon laufen, daher benötigen wir das Tool jsvc. Dieses ist in dem heruntergeladenen Archiv enthalten, muß jedoch kompiliert werden:

~$ cd apache-tomcat-5.5.25/bin
~$ tar xvzf jsvc.tar.gz
~$ cd jsvc-src
~$ ./configure --with-java=/usr/lib/jvm/java-1.5.0-sun
~$ make
~$ cp jsvc /opt/tomcat/bin/

Als nächstes wird das mitgelieferte Init-Skript an die richtige Stelle kopiert …

~$ cd native
~$ cp Tomcat5.sh /etc/init.d/tomcat

… und angepaßt:

~$ vi /etc/init.d/tomcat
JAVA_HOME=/usr/lib/jvm/java-1.5.0-sun
CATALINA_HOME=/opt/tomcat
DAEMON_HOME=/opt/tomcat
TOMCAT_USER=tomcat
CATALINA_BASE=/opt/tomcat\n$DAEMON_HOME/bin/jsvc \

Achtung, die letzte Zeile kommt sowohl in der Sektion “start” als auch in der Sektion “stop” vor und ist an beiden Stellen zu ändern!

Dann werden noch für den gewünschten Runlevel, in dem Tomcat automatisch gestartet und gestoppt werden soll, die symbolischen Links gesetzt:

~$ cd /etc/rc5.d
~$ ln -s ../init.d/tomcat S65tomcat
~$ ln -s ../init.d/tomcat K65tomcat

Tomcat soll, wie das auf Linux-Systemen aus Sicherheitsgründen für solche Applikationen allgemein üblich ist, unter einem eigenen User laufen. Also fügen wir dem System einen User und eine Gruppe — beide namens “tomcat” — hinzu, wobei der User tomcat außerdem zu der Gruppe www-data gehören soll:

~$ groupadd -g 65 tomcat
~$ useradd -u 65 -g 65 -d /opt/tomcat -s /bin/false -c "Tomcat User" tomcat
~$ chown -R tomcat:tomcat /opt/apache-tomcat-5.5.25
~$ usermod -G www-data tomcat

Jetzt kann Tomcat gestartet werden:

~$ /etc/init.d/tomcat start

Die Beispielapplikationen, die Tomcat mitbringt, sind im Dateisystem unter /opt/tomcat/webapps zu finden. Daher wird jetzt, wenn alles richtig gemacht wurde, unter
http://localhost:8080
die Tomcat-Startseite zu sehen sein! Unter
http://localhost:8080/jsp-examples/
sind dann die mitgelieferten JSP-Beispiele zu bewundern.

Nun ist es aber sicher nicht sinnvoll, jeden Aufruf an den neu installierten Tomcat über dessen Default-Port 8080 am Webserver laufen zu lassen. Darum wird im nächsten Schritt der Tomcat Connector mod_jk installiert.

mod_jk installieren und konfigurieren

Dazu wird gegebenenfalls zunächst weitere Software benötigt, die mit folgendem Kommando installiert wird:

~$ apt-get install libtool autoconf \
gcc g++ apache2-prefork-dev

Nun wird die neueste Version von mod_jk 1.2, zur Zeit ist das 1.2.25, von der Downloadseite heruntergeladen:
http://tomcat.apache.org/download-connectors.cgi

Das Archiv hat eine Bezeichnung ähnlich tomcat-connectors-1.2.x-src.tar.gz, siehe oben.

Lustigerweise ist die Entwicklung des präsumptiven Nachfolgers mod_jk2 eingestellt und stattdessen mod_jk einer Auffrischung unterzogen worden, was aber nicht weiter stören soll ;)

Das Archiv wird entpackt und kompiliert:

~$ cd /home/user/tmp
~$ tar xvzf tomcat-connectors-1.2.25-src.tar.gz
~$ cd tomcat-connectors-1.2.25-src/native
~$ ./configure --with-apxs=/usr/bin/apxs2
~$ make
~$ make install

Als nächstes müssen eine Reihe von Skripten angelegt werden:

~$ cd /etc/apache2
~$ vi workers.properties
# Tomcat and Java configuration
workers.tomcat_home=/opt/tomcat
workers.java_home=/usr/lib/jvm/java-1.5.0-sun
ps=/
worker.list=mainworker
# Definition for local worker using AJP 1.3
worker.mainworker.type=ajp13
worker.mainworker.host=localhost
worker.mainworker.port=8009
worker.mainworker.cachesize=20

~$ cd /etc/apache2/mods-available
~$ vi jk.load
LoadModule jk_module /usr/lib/apache2/modules/mod_jk.so
~$ vi jk.conf
<IfModule mod_jk.c>
JkWorkersFile /etc/apache2/workers.properties
JkLogFile /var/log/apache2/mod_jk.log
JkLogLevel error
</IfModule>

Jetzt werden jk.load und jk.conf noch für Apache verfügbar gemacht …

~$ cd /etc/apache2/mods-enabled
~$ ln -s ../mods-available/jk.conf jk.conf
~$ ln -s ../mods-available/jk.load jk.load

.. und schließlich Tomcat neu gestartet:

~$ /etc/init.d/tomcat stop
~$ /etc/init.d/tomcat start

Nun ist nur noch ein letzter Schritt notwendig, nämlich dem Apachen zu sagen, was genau er an Tomcat weiterleiten soll.

Apache konfigurieren

Wie oben schon gesagt, bezieht sich dies alles auf Apache 2.2.x. Die Virtual Hosts, die der jeweilige Apache kennen soll, sind im Verzeichnis /etc/apache2/sites-available konfiguriert. Dort findet sich eine Datei namens “default”, in der die Vorgabe enthalten ist. Da im Moment keine weiteren Virtual Hosts benötigt werden, wird der Einfachheit halber diese Konfiguration verwendet.

Die Beispielapplikationen, die Tomcat mitbingt, sind wie erwähnt unter /opt/tomcat/webapps zu finden. Wenn nun eigene Projekte unter /opt/tomcat/webapps/myprojects abgelegt werden und im Browser unter
http://localhost/myprojects/
erreichbar sein sollen, wird in der Datei default innerhalb des Virtual Host ein Eintrag hinzugefügt:

~$ cd /etc/apache2/sites-available
~$ vi default
Alias /myprojects/ "/opt/tomcat/webapps/myprojects/"
<Directory "/opt/tomcat/webapps/myprojects/">
Options Indexes +FollowSymLinks
</Directory>
JkMount /myprojects/* mainworker

Die letzte Zeile weist Apache an, mittels des (siehe oben) in /etc/apache2/workers.properties definierten Workers “mainworker” alle Aufrufe an
http://localhost/myprojects/

an Tomcat weiterzuleiten.

Um dies zu testen, bietet es sich an, die Beispielapplikationen aus /opt/tomcat/webapps/jsp-examples nach /opt/tomcat/webapps/myprojects zu kopieren:

~$ cp /opt/tomcat/webapps/jsp-examples /opt/tomcat/webapps/myprojects

Nach einem Neustart von Apache mittels

~$ /etc/init.d/apache2 restart

sollte nun
http://localhost/myprojects/jsp-examples/
im Browser erreichbar sein!

Weiteres zur Konfiguration von Apache mit mod_jk ist hier zu finden:
http://tomcat.apache.org/connectors-doc/

Damit sind Installation und Konfiguration abgeschlossen, und der Entwicklung eigener JSPs und Servlets steht nichts mehr im Wege!

Leider habe ich bis jetzt noch keine Möglichkeit gefunden, wie man Apache und Tomcat dazu überreden kann, JSPs und Servlets aus User-Homeverzeichnissen heraus auszuführen. Sollte ein geneigter Leser über diesbezügliche Erfahrungen verfügen, freute ich mich sehr über Feedback!

Hier noch ein Link zu weiterführenden Informationen zum Finetuning von Tomcat in Produktionsumgebungen:
http://jspwiki.org/wiki/DeploymentOptimizations

Quellen:
http://daff.neyeon-digital.de/blog/2007/02/07/apache2-tomcat-55x-mod_jk-12x/
http://www.crazysquirrel.com/computing/debian/servers/tomcat55.jspx

Für alle Programmierer, die sich einen Überblick über J2EE verschaffen wollen, bietet Herr Sang Shin einen kostenlosen Online-Kurs an, der sich mit den Grundlagen von Servlet, JSP (Java Server Pages), MVC (Model View Controller), Struts, JSF (Java Server Face), EJB (Enterprise Java Beans), JPA (Java Persistence API), Hibernate und Spring Framework befaßt.

So ein Angebot findet man nicht alle Tage! Die Sache ist recht umfangreich und setzt einiges an persönlichem Engagement voraus. Zwar heißt es an vielen Stellen im Web und in den einschlägigen Printmedien, daß Ruby on Rails derzeit der hellste “Shooting Star” am Webhimmel sei, aber meiner eigenen Erfahrung nach werden die gängigen J2EE-Technologien real im Moment doch am meisten nachgefragt.

Der Kurs beginnt am 19. November 2007. Alles weitere gibt es unter:

http://www.javapassion.com/j2ee/

Allen Teilnehmern wünsche ich viel Erfolg, und vielen Dank für dieses tolle Angebot an Herrn Sang Shin!

Dieses Tutorial hatte ich bereits auf meiner früheren Wordpress-basierten Homepage veröffentlicht. Angesichts der großen Anzahl derzeit vorhandener Wordpress-Installationen stelle ich es hier erneut ein.

Die ganze Sache basiert auf dem Wordpress-Plugin LanguageSwitcher. Über dessen Konfiguration existiert ein hervorragendes Tutorial in deutscher Sprache. Darum möchte ich hier mehr auf die Verwendung der gettext-Funktionen von PHP eingehen, da deren Kenntnis notwendig ist, um das verwendete Wordpress-Theme möglichst durchgängig mehrsprachig zu gestalten. Das Theme, das die Vorlage für meine alte Homepage war, erforderte einige Anpassung.

Das ganze funktioniert so wie hier beschrieben nur unter Linux, auch der Webserver muß unter Linux/Unix laufen, da gettext auf Funktionen in systemnahen C-Bibliotheken zurückgreift. Diese sind meines Wissens auf Windows-Systemen nicht vorhanden.

Nun aber zur praktischen Umsetzung. Zunächst benötigen wir das Paket gettext, das sich unter Debian folgendermaßen installieren läßt:

~$ apt-get install gettext

Nun müssen alle hartkodierten Strings, die irgendwie zur Ausgabe kommen, in allen PHP-Dateien des verwendeten Themes “gettexted” werden, soweit sie es nicht schon sind. Im Standardtheme “default” sind die meisten Strings bereits gettexted, aber bei Verwendung eines eigenen Themes werden wir wohl einiges anpassen müssen.

Strings, die als solche ausgegeben werden, gettexten wir auf diese Weise:

<?php _e('Hallo gettext!') ?>

Und Strings, die einer Methode als Argument übergeben werden, auf jene:

<?php comments_popup_link(_('dieses'), _('jenes')); ?>

Aber Achtung Fallstrick! xgettext, siehe unten, erkennt beim Parsen nämlich nur die zweite Variante als gettexte! Man sollte also erst alle Strings mit der zweiten Variante gettexten, dann den nächsten Schritt durchführen, und erst danach dort, wo nötig, die

_()

mit

_e()

ersetzen.

Im nächsten Schritt lassen wir xgettext die soeben geänderten (und getesteten!) PHP-Dateien parsen, um unsere Sprachdatei, die wir dann übersetzen wollen, zu erzeugen. Das geschieht etwa folgendermaßen:

~$ xgettext -o sprachdatei.po mehrsprachig.php

sprachdatei.po sieht dann so aus, wenn die beiden obigen Zeilen php-Code in mehrsprachig.php drinstanden:

#: mehrsprachig.php:1
msgid "Hallo gettext!"
msgstr ""
#: mehrsprachig.php:2
msgid "dieses"
msgstr ""
#: mehrsprachig.php:2
msgid "jenes"
msgstr ""

Wir übersetzen die Strings und speichern die Datei als cs.po:

#: mehrsprachig.php:1
msgid "Hallo gettext!"
msgstr "Ahoj gettext!"
#: mehrsprachig.php:2
msgid "dieses"
msgstr "tento"
#: mehrsprachig.php:2
msgid "jenes"
msgstr "tamto"

Das ist natürlich nur beispielhaft. Selbstverständlich sollte man alle zu übersetzenden Strings aus allen gettexteden PHP-Dateien in einer eigenen .po-Sprachdatei zusammenfassen, auch deswegen, weil diese Datei ebenfalls als Vorlage für alle anderen Übersetzungen in weitere Sprachen dient. Diese .po-Sprachdateien (portable object) werden in der gettext-Terminologie auch Kataloge genannt.

Alle Ergänzungen und individuellen Anpassungen, die wir auf diese Weise vorgenommen haben, führen wir nunmehr mit dem tschechischen Original-Sprachkatalog für Wordpress zusammen. Falls noch nicht vorhanden, gibt es diesen Katalog hier:
cs_CZ.po für Wordpress

Wenn Wordpress für Sprachen mit unterschiedlichen diakritschen und Sonderzeichen sowie unterschiedlichen Schriften, wie etwa für Deutsch, Tschechisch und Russisch, fit gemacht werden soll, ist natürlich UTF-8 die Zeichenkodierung der Wahl. Wordpress muß dann bereits mit Unterstützung für UTF-8 installiert worden sein.

Daher muß darauf geachtet werden, daß im Header von cs_CZ.po diese Zeile steht:

"Content-Type: text/plain; charset=UTF-8\n"

Den Katalog übersetzen wir jetzt in das notwendige Binärformat (.mo für machine object):

~$ msgfmt cs_CZ.po -o cs.mo

Die entstandene binäre Sprachdatei cs.mo kopieren wir als letzten Schritt in das Verzeichnis wordpress/wp-includes/languages. Nun sollten bei korrekter Konfiguration des Webservers und installiertem LanguageSwitcher-Plugin beim Umschalten der Sprache mittels Klick auf die jeweiligen kleinen Landesflaggen die jeweiligen Sprachversionen zu sehen sein :)

Hier noch einige weiterführende Links:
Ein sehr interessanter Artikel zum Thema UTF-8 von meinem Vater
Übersetzers Liebling
Programme von Welt