public Foo() {
super();
this.id = String.valueOf(System.currentTimeMillis());
for(int i=0; i<1000000; i++);
}

The modern way of creating UUIDs: get current time as UUID, count until 1.000.000, get next UUID.

Über den Wikipedia-Artikel über Prosa bin ich auch einen Bericht von Emil Zopfi über die ebenfalls PROSA (“Programmieren mit Symbolischen Adressen”) genannte Programmiersprache von Siemens gestoßen. Echt interessant, auch wenn das damalige Vorgehen einem heute natürlich wie aus der Steinzeit vorkommt:

Man soll jetzt nicht denken, wir hätten die PROSA-Programmtexte direkt auf Lochstreifen geknipst. Wir programmierten weitgehend im Kopf, zeichneten Flussdiagramme mit Schablone, schrieben den Code in sauberen Druckbuchstaben in Programmformulare, Null immer durchgestrichen zur Unterscheidung von O, schickten die Formulare in die Locherei zu den flinken Locherinnen, bekamen nach ein paar Tagen die gestanzten Karten, lieferten sie in die Programmübersetzung, erhielten nach einem oder zwei Tagen eine gedruckte Liste, meist voller Fehlermeldungen, und einen Lochstreifen mit dem Maschinencode. So ging alles seinen geordneten Lauf. Korrigieren, fehlerhafte Karten ersetzen, nochmals übersetzen, dann Rechenzeit buchen auf einem Testrechner ­ wie bitte? Eine Stunde am Sonntag morgen zwischen drei und vier Uhr? Hart war das Leben.
(aus Emil Zopfi – Prozessrechnerprosa)

Schon lange gab’s keine Berichte mehr zum Thema “Spaß mit Web Services”, heute ist es mal wieder soweit. Ich habe jetzt kaum einen kompletten Arbeitstag mit einem Problem verschwendet, dass sich mal wieder als äußerst trivial darstellt – ein einziges Attribut in der XML Schema-Definition passend gesetzt und alles geht, ansonsten geht halt nichts.

Kurz zum Hintergrund: ich versuche gerade, einen WS-Agreement Web Service von GT4 auf UNICORE/WSRFLite zu portieren und darüber einen Artikel zu schreiben. Das hat bis gestern auch alles funktioniert, nur habe ich dann festgestellt, dass ich keine Attribute setzen kann, ohne dass es knallt: “Unbound namespace URI ‘http://schemas.ggf.org/graap/2007/03/ws-agreement’” ist die wenig aussagekräftige Fehlermeldung.

Gut, dachte ich mir, vielleicht geht, warum auch immer, nur dieses eine Attribut nicht, also ein anderes gesetzt – nichts. Es lagen auch keinen alten Bibliotheken irgendwo rum, also sehr komisch. “Definierst du dir halt eigenes Element mit Attribut, vielleicht geht’s dann”, dachte ich mir – half aber auch nichts. Also nochmal an den WSRFLite-Beispielservice, dort ein Element um ein Attribut erweitern und testen – geht. Äh, wie jetzt nochmal? Dann habe ich mal mein eigenes Element in eine eigene Schema-Datei extrahiert und auch das ging. Beim vergleichen meiner Schema-Datei mit der von WS-Agreement ist mir dann aufgefallen, dass bei WS-Agreement »attributeFormDefault=”qualified”« gesetzt ist, in meinem Schema aber nicht. Und, oh Wunder, als ich dies entfernt habe, ging’s auf ein Mal.

Mir ist allerdings im Moment nicht klar, wo genau das Problem liegt. Möglicherweise liegt es an der WSRFLite (respektive XFire)-Version, vielleicht auch an der Kombination von »elementFormDefault« (“qualified” bei WS-Agreement) und »attributeFormDefault« (“auch qualified”). Wenn ich dazu noch Muse habe – immer eher unwahrscheinlich, wenn das initiale Problem gelöst ist, aber vielleicht doch, da ich ja immer gerne weiß, warum etwas nicht ging -, werde ich mal untersuchen, wie sich die verschiedenen Kombinationen auswirken; bei Oracle gibt’s zu diesem Thema ein nettes Dokument, XML Schema: Understanding Namespaces.

Nachdem ich schon so viel mit PHP und MySQL rumgespielt habe, kann ich mittlerweile echt sagen dass die Entwicklung von Webseiten damit zwar an sich Spaß macht, man im wesentlichen aber immer das gleiche macht – blöde Eingabe-Formulare schreiben. Deswegen habe ich mir für ein total geheimes Projekt – Daniel, Geschäftsidee! – mal Ruby on Rails mit SQLite angeschaut. Das verspricht eine tolle Automatisierung und soll an sich einfach gut sein.

Selbst dem professionellen Herrn K. ist dabei aber ein total bescheuerter Fehler unterlaufen: lässt man Ruby die nötigen Dateien für eine Tabelle generieren – zum Beispiel per script/generate scaffold ratings, so bekommt man immer abstruse Fehlermeldungen und es scheint so, als sei kein Bezug zur Datenbank gegeben. Stimmt auch, denn Ruby/Rails war in dem Fall einfach zu schlau für mich. Denn der anzugebende Begriff sollte der Tabellenname im Singular sein. Wieder was gelernt, damit ist heute schon mal kein verlorener Tag.

Sowohl Subclipse als auch Subversive, beides SVN Plug-ins für Eclipse, gaben mir beim Zugriff auf ein SVN-Repository die folgende Fehlermeldung:

svn: PROPFIND request failed on ‘/svn/FOO’
svn: decompression_failure: remotely generated; fatal

Die Subclipse FAQ beschreibt einen Weg, wie man Eclipse beibringen kann, nach weiteren Bibliotheken zu suchen und dieser Thread aus der subclipse-users Mailingliste gibt an, dass es wohl am fehlenden libsvn-java liegen könnte.

Wahrscheinlich ist es aber viel einfacher, das Problem zu lösen, was man merkt, wenn man mal in Windows->Preferences->Team->SVN schaut. Dort wurde mir die folgende Fehlermeldung präsentiert:

Im Preferences-Dialog kann man dann zwar JavaHL auswählen – was man aber noch installieren müsste -, aber nicht SVNKit, obwohl das mit Subclipse installiert wurde. Der Fehler steckt hier im Detail, denn es liegt daran, dass Eclipse die falsche VM zum Ausführung benutzt. Eclipse nimmt keine Rücksicht auf die Einstellung in /etc/alternatives/java sondern nimmt die erste VM die es findet, was bei mir die GCJ war, welche bekanntlich einige Probleme hat und auch mit SVNKit nicht funktioniert.

Problemlösung: Eclipse mit eclipse -vm /path/to/java starten, zum Beispiel eclipse -vm /usr/lib/jvm/java-6-sun/bin/java – et voilà, SVN funktioniert tadellos.