Security Update "Low Priority" bei Datanucleus?

Nachdem die Software ja nun ein paar Monate auf github verfügbar ist, fallen in freier Wildbahn natürlich Kleinigkeiten auf, die im 0.7-Zweig bereinigt sind. Alle? Nicht ganz alle: Eine Kleinigkeit liegt ein wenig Außerhalb meines Einflußbereiches...
Der Bytecode "Enhancer" der datanucleus Implementierung von JDO funktioniert in der Fassung, wie ich sie für die Google App Engine und auch die RDBMS Variante als "Compiler Processor" benutze, nicht mit den aktuellen Versionen von Java, die seit Juni Verfügbar gemacht wurden. 1.6.0_26 ist die letzte Version, die noch läuft.
Mein Problem mit der Software fühlt sich so ähnlich an wie http://www.datanucleus.org/servlet/forum/viewthread_thread,6958 und die Antwort dort macht mir Sorge, denn es ist wohl nun auch der Java 6 Strang betroffen - und Security Updates wollen meine "Commercial Clients" alle gerne haben :-). Also für's Bauen bitte die o.g. Version benutzen oder den Enhancer auf aktuelle Software erweitern. Danke.
Auch wenn erfreuliche Zeichen aus der Google App Engine Welt zu hören sind und der Code zwischen RDBMS und GAE vereinheitlicht werden kann, bleibt also mit datanucleus 3.0.4 das Problem bestehen! Version  3.0.5 suche ich nocht zum Download.

Endlich in's CoMA gefallen

Habe eben gerade einmal die neuen Errungenschaften des Wochenendes nach github geschoben - gepuscht auf neudeutsch. Ein kleines Update auf den neuesten Meilenstein von Gradle habe ich auch gleich noch eingezogen, weil Gradle langsam immer schneller wird und ich damit keinen nennenswerten Migrationsaufwand hatte. - Sehr zu empfehlen!
Letzte Woche hatten einmal wieder ein paar Leute gefragt, ob man nicht auch direkt auf eine CoreMedia Datenbank zugreifen kann. Kann man - aber wer will das schon.
Also habe ich jetzt endlich meinen CoreMedia Adapter (CoMA) in seiner schlichtesten Ausprägung in tangram integriert.
Nein, ich bin nicht zu doof, es ausgefeilter zu machen, aber ich will weder das Copyright von CoreMedia verletzen noch deren System nachbauen. Ich muß auch erst noch am Textkovertierer für den Richtext arbeiten.
Gemäß der neuen Doktrin seit Oktober ist nun ein Beispiel natürlich anbei. Wobei man für die Sache das Original-Beispiel von CoreMedia benötigt. Da meine Teile ohnehin nur als Ergänzung zu verstehen sind, ist das ja aber wohl keine Einschränkung.

Beispielhaft

Leider fehlt mir immernoch der Ansatz, wie ich, ohne viel Code zu schreiben, Daten zwischen verschiedenen Datenbanksystemen austauschen kann. Ich hatte da schon auf vorgefertigte Techniken wie den XML-Export gehofft, die mir aber mit den internen IDs der Datenbanken bzw. von JDO Probleme machen.
Also habe ich das erst einmal aufgesteckt und statt dessen einfach die gute alte hsqldb eingesetzt, für die ich die Daten sehr einfach mitliefern kann. Dafür gibt's nun im rdbms Beispiel ein wenig Inhalt mit Velocity Templates und Groovy Code.
Das auf Gradle basierende Buildsystem kommt nun langsam in einen brauchbaren Zustand. Den CoreMedia CMS Adapter halte ich noch zurück, bis ich dort ein Beispiel für den Einsatz liefern kann.
Also: Beispiele und System stehen auf github bereit

Raus aus dem Deadlock

Eigentlich wollte ich ja schon vor Monaten Code veröffentlicht haben, aber es gibt leider drei wesentliche Probleme, von denen wenigstens eines gelöst werden sollte, bevor man daran geht.
Um überhaupt etwas herausgeben zu können braucht man ein Build-System, das ich mit Gradle umsetzen wollte.Dabei mußte ich feststellen, daß dann alle meine Google App Engine Codes im JDO Bereich nicht mehr funktionierten, wenn man sie mit Gradle baut.
Also wollte ich mich der Lösung mit relationalen Datenbanksystemen zuwenden. Das funktioniert im Unterschied zur Google App Engine auch ganz wunderbar, nur muß ich natürlich ein Bepiel bereitstellen, damit jeder am Ende auch die Funktionsweise nachvollziehen kann. Da wiederum trat als nächstes Problem die Schwierigkeit auf, daß ich bisher keine Lösung gefunden habe, unabhängig vom darunterliegenden System einen JDO-Datastore mit Datenzu befüllen, die ich aus einem andere gewonnen habe. Klingt nach einer einfachen Fingerübung mit XML oder JSON als Übertragungsformat, aber bisher habe ich da nicht nichts gefunden, das nicht in erheblicher Eigenarbeit oder viele Exceptions mündet. Ideen und Anregungen sind willkommen!
Das dritte Problem? Naja, ich müßte das Beispiel schreiben. :-)
Die völlig unverständlichen Probleme beim Bauen mit Gradle habe ich nun aber endlich umschiffen können. Damit kann ich für die Google App Engine nun auch ein Beispiel bereitstellen, indem ich einfahc das Austauschformat dort verwende. Ein Teil des Problems war "recht schnell" gefunden: Binnen einiger weniger Tage findet man heraus, daß die Dateien im JAR verpackt wurden, bevor der JDO-Enhancer sie in die Finger bekam. Der andere Trick ist hartnäckiger gewesen und ich bin ihm er jetzt auf die Schliche gekommen: Die Google Datentypen für Text und Blob wurden nicht als persistent angesehen, wie es bei der indirekten Benutzung mit dem Google App Engine Plugin für Eclipse der Fall ist. Was auch immer da genau los ist: Man muß einfach nur @Persistent an ein paar mehr Stellen schreiben. Ich will hier die Problematik von Datanucleus und App Engine gar nicht auswalzen, aber ich bin da technisch wohl ein wenig zwischen die Fronten geraten. Resultat ist jedenfalls ein ArrayIndexOutOfBounds irgendwo ganz tief im nur binär vorliegenden, enhancten Code. Eine kleine Reverse Engineering Runde durhc den Enhancer brachte nun endlich Klarheit.
Nun kann es also endlich weitergehen!
Wer doch lieger mit (a) RDBMS oder (b) CoreMedia als Speicher arbeiten möchte: Dort brauche ich also noch die (a) Datenübertragungsmöglichkeit (s.o.) und (b) Code, der mir den Richtext aus der Datenbank fischt. Anyone?

Vendor Lock In - III

Und nun wieder zurück zu dem Thema, welche Wege man sich verbaut und welche man sich offen halten möchte.

Bisher habe ich nur darüber geschrieben, daß ich mich auf Google App Engine wohlfühle und daß es nun belegt und testweise umgesetzt ist, daß es auch mit dedizierter Datenbank, JSP-Contaienr etc. geht.

Aber da war ja immernoch eine Ausbaustufe vorgesehen, die sich nicht darauf verläßt, daß JDO als ORM Layer benutzt wird. Letztlich läßt sich auf das Kernmodul alles aufsetzen, was irgendwelche Java Objekte erzeugt ,und mit diesen kann man dann objektorientiert Templates für die HTML Ausgabe schreiben.

Mein prominentes Beispiel war die (read only) Nutzung einer Datenbank, wie sie vom CoreMedia CMS beschrieben wurde. Exemplarisch habe ich das umgesetzt, nur mit den Richtext-Elementen habe ich noch so meine Probleme. Und für dieses Szenario gibt's nun tatsächlich ganz praktisch Systeme, für die das nützlich wäre. Mal sehen, ob sich endlich jemand "traut" diesen Weg zu gehen.

Die Lösung dient natürlich nicht dazu, ein CoreMedia CMS abzulösen. Die Kernkomponenten Content Management Server, Master Live Server, Workflow Server und Editoren bleiben notwendig. Wenn man aber unter Aufgabe aller Skalierungsoptionen eine datenausspielende Webanwendung mit dem vorhandenen Content umsetzen will, kann Tangram ein zusätzlicher Baustein sein.

Für diese Zusätzlichen Komponenten könnte der Deal dann so aussehen: Keine Lizenzkosten - Keine Performance.

Die Architektur ist einfach, hat keine zusätzlichen Serverkomponenten, benötigt ggf. die Replikation auf Datenbankebene und skaliert damit nicht ansatzweise so weit wie das "Original". Synergien mit Webanwendungen auf Basis der CAE / Unified API gibt es dann auch nicht mehr. Über Integrationen mit Suchmaschinen etc. habe ich mir nicht einmal große Gedanken gemacht. Was bleibt ist einfach, aber essenziell: Man bekommt seinen Content in's Web.

Muß es denn Maven sein?

Im Moment ist mein Code hier für mich total gut zu benutzen, aber es ist eben ein Workspace für genau einen Benutzer, der eine Reihe von Websites (z.B. www.themen-geburtstag.de und www.dragon-map.de) bastelt.

Dabei fehlt natürlich auch mir ein gutes Dependency-Management für die eingesetzte Libraries (ja ich habe síe total unzivilisiert einfach in meine jeweiligen lib/-Verzeichnisse gelegt). Im Moment pushen die einzelnen Module ihre Ergebnisse in die jeweils nächsten Schichten.

Klingt gruselig? Ist aber einfach sehr schnell und effizient zu benutzen, und das will ich auf keinen Fall verlieren!

Gewohnheitsmäßig benutzen zur Zeit viele Projekte Maven. Dabei mußten wir alle lernen, daß man nicht Maven an seine Bedürfnissen anpassen kann, sondern sich an Mavens Bedürfnisse anpassen muß. Emotionaler ausgedrückt meinte ein Kollege, daß Maven ihn nicht möge. Aber wir stellten fest, daß es noch viel schlimmer war: Maven ignoriert ihn!

Wenn ich Maven einsetze verliere ich die schöne, einfache Deploybarkeit meiner Projekte nach Google App Engine aus der IDE heraus (denke ich) und ich verliere die enorm kurzen Round-Trips beim Entwickeln, die es ermöglichen das Framework weiterzuentwickeln und die notwendigen Änderungen an den benutzenden Appliaktionen sofort zu sehen. - Sofort, nicht 4min später! Dafür bekomme ich ein sauberes Dependecy-Management und ein etwas unverständliches Build- und Packaging System. Das klingt also genauso gruselig wie der Status quo.

Also habe ich mal nach Möglichkeiten gegooglet. Dabei entdeckt man natürlich sofort JAppStart als Startpunkt für die Entwicklung einer Java-Anwendung für die App Engine. Leider bin ich über den Punkt schon seit Monaten hinaus. - Danke Jungs - zu spät. Außerdem habe ich ja einen modularen Ansatz und nicht einfach nur ein Webprojekt. Dann gibt's da die angeblichen Alternativen zu Maven (z.B. http://www.streamhead.com/maven-alternatives/). Davon habe ich mir mal Gradle genauer angesehen, weil die anderen nicht erstrebenswert schienen. Die Beschreibungsdateien für den Build-Prozeß mit Gradle sind einfacher als bei Maven, obwohl ich hier ja bei der Lernkurve bei Null anfange (bei Maven bin ich doch schon kanpp über Null nach ein paar Jahren), andererseits muß ich mir nun doch auf einmal ein komplettes Build-System aufbauen und nicht einfach etwas funktionierendes zusammenstöpseln. Das gefällt mir noch nicht. Verstanden hat der Autor aber anscheinend, daß XML nicht als Sprache zum Schreiben für Menschen gedacht ist. Gradle schreibt sich als DSL zielorientierter als das Maven XML. Das Dependency-Management kann auf Maven Repositories zurückgreifen (die sind ja in jedem Fall genau das was ich brauche) und sogar mein lokales Repository findet Berücksichtigung. Ich traue mich nun nach dem Posting gestern nicht "Maven done right" zu Gradle zu sagen, aber es fühlt sich gut an. Einziger Wehrmutstropfen: Es werden als Default Ivy-Repositories genutzt und angelegt. Ivy ist bei mir nicht positiv besetzt. Liegt das an mir?

Aber mit Gradle wie mit Maven müßte ich nun wieder alles selbst erstellen. Dazu habe ich eigentlich keine Lust. Möchte jemand übernehmen oder Tips geben?

Bekehrung zu GIT

Hat schon jemand von dem Zeug, über das ich hier schreibe, den Source Code gesehen? Nein? Ok, einer hat es, aber der liest hier wohl gerade nicht.
Das hat zwei einfache Gründe: Der Code ist noch nicht in einem Zustand zusammengestellt, den ich herausgeben mag, und ich habe mich noch nicht für das "richtige" Source-Code-Verwaltungssystem und entsprechende, konkrete Repository entscheiden können.
Zum ersten Punkt gibt es entschuldigend nur zu sagen, daß die Module alle brav sauber geschrieben und zugeschnitten sind, aber das Buildsystem einfach nicht existiert. Ich fürchte mich einfach vor dem Verlust an Produktivität den mir Maven bringen würde. Gibt es Alternativen?
Für die Source-Code-Verwaltung dachte ich bisher, daß man im Open Source Bereich nun einfach mal so GIT (http://git-scm.com/) nimmt. Das lag hier so als Entscheidung herum und ich wartete nur auf den Zustand des Codes ihm bereitzustellen. Nun habe ich aber endlich Verstanden, was GIT für mich leisten kann und frage mich, worauf ich die ganze Zeit gewartet habe. Ich bin absolut bekehrt! Der Vortrag von Linus Torvalds bei Google dazu ist zwar erschreckend überheblich und er scheint auch zu wenig Erfahrung mit den anderen Arbeitsweisen im kommerziellen Umfeld zu haben (http://www.youtube.com/watch?v=4XpnKHJAok8), aber wahr bleibt wohl, daß ich mit dem Werkzeug alle Abläufe, die ich in verschiedenen Projekten brauche, damit abdecken kann. Egal, was Ihr mit Source Code macht, legt Euch einfach ein GIT-Repository an! (http://code.google.com/p/tortoisegit/) Man kann nichts falsch machen. Ich jedenfalls werde mich nun bemühen, das Backup des Tangram Workspaces (er enthält leider auch noch das halbe Dutzend Sites, die damit umgesetzt sind) durch ein GIT-Repository zu ersetzen. Das muß ich natürlich wieder sichern, aber das war es schon. Der einzige Kampf, der dann einer Herausgabe noch entgegensteht ist die Frage, ob ich ein "Superproject" in GIT brauche...