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...

Hallo Nachbarn

Nachdem ich mir ja nicht so sicher war, ob man die Lösung mit Google App Engine nun als Schmalspurvariante sehen muß, weil in mener Umgebung - gerade bei den ach so konstebewußten Kunden - noch so viele auf dedizierte Serverchen im eigenen Schrank setzen (was ja an einigen Stellen definitiv eine Berechtigung hat und behalten wird, aber man sollte doch bei ohnehin veröffentlichten Web-Inhalten drüber nachdenken können), fand ich heute bei auf welt.de (http://www.welt.de/fernsehen/specials/eurovision-grand-prix/article13361306/Lena-unheimlich-sexy-und-duester-beim-Grand-Prix.html) ein "Widget". (Sie nennen's Gadget, werde die Lieferung der Hardware verlangen! Ein Gadget ist bei mir immer ein Stück Blech oder Plastik und keine Software... ;-) )

Und siehe da, das Ding läuft auf appspot.com. Wir sind also quasi Nachbarn und die Frage der Lasttauglichkeit ist bei so einem Ereignis dann wohl auch beantwortet. (http://eurovisiongadget.appspot.com/?lang=de) Sie habe sich also nicht einmal die Mühe gemacht, eine eigene Domain dafür zu buchen (jaja, wozu auch in diesem Fall).

Wenn es Probleme damit gibt, liegt's als an meinen eingesetzten Frameworks und der Beschränktheit des Entwicklers. Das kann man ja alles noch ausmerzen, wenn es im Betrieb zuschlagen sollte. Auch in Anbetracht dessen, welchen Aufwand eine Deployment für eine eigene Umgebung bereitet und wieviel man leisten muß, um all die Möglichkeiten des Betriebs, die Google bietet, selbst bereitzustellen, sehe ich Google App Engine weiterhin als den Schwerpunkt an, wenn nicht bald ein Projekt zuschläft, das es anders braucht.

Für alle, die es lieber dediziert haben, gibt's ja schon, wie erwähnt die Möglichkeit mit eigenem Servlet/JSP Container und RDMBS nach Wahl. Außerdem bastele ich weiterhin an einem anderen Adapter...

"Erste" Web Site online

Auch wenn natürlich schon seit Monaten einige Sites mit Tangram laufen und auch schon die Integration über Google Apps und eigene Domainsnamen länger genutzt wird, verkünde ich heute mal offiziell, daß wir eine Site in Betrieb genommen haben (indem wir nur den globalen Login entfernt haben).
http://www.themen-geburtstag.de/
beschäftigt sich mit Konzepten zur Ausgestaltung von Kindergeburtstagen zu verschiedenen Themen - und es werden immer mehr - inklusiver aller Vorbereitungen, eines Leitfadens für den Ablauf. Dazu noch ein allgemeiner Teil. In Zukunft sollen hier noch mehr Themen und Hilfestellungen hinzukommen für alle, die nicht einfach eine Party irgendwo "einkaufen" wollen.

Vendor Lock in II

Leider habe ich hier über die weitere Entstehungsgeschichte von Tangram nicht mehr berichtet. Es ist aber einiges passiert.
Als nächstes wollte ich eigentlich unter dieser Überschrift darüber schreiben, wie ich unter das Tangram Modul statt JDO und Google App Engine eine CoreMedia-Datenbank geschraubt habe und mit als Modul "CoMA" einen CoreMedia CMS Adapter gebaut habe. Das habe ich zwar auch, aber das interessiert im Moment anscheinend niemanden. Wer's haben möchte: Mailen ;-) (GIT Zugange inkl.  aller Vorarbeiten den Code herauszugeben fehlen ohnehin noch, aber ich geb's gerne her)
Was ich jetzt allerdings kurzfristig beweisen wollte, war, daß das JDO-Modul auch mit anderen Spezialisierungen nutzbar ist. Das klappt derzeit auch recht gut. Der Editor, mit dem sich die JDO-Beans generisch bearbeiten lassen, läuft nun brav auch ohne Google App Engine. Der einzige "Nachteil" ist, daß die Version des GAE-Moduls nicht angezeigt werden kann, weil das ja die Spezialisierung ist. Mit dieser neuen Varianten bin ich aber wieder einem Lieferunanten ausgeliefert: Datanucleus. Das ist auch unter Google App Engine drin und die einzige JDO Implementierung, die bei meiner Recherche den wenigen Kriterien nach Lizenz und aktiver Entwicklung standhielt.
Die größte Schwierigkeit wäre nun, das Architektur-Diagramm aus dem letzten Posting wieder anzupassen.
Wer jetzt also nicht in die Cloud wollte, kann nun loslegen. Er muß nur noch das Themen Benutzerverwaltung angehen, weil sonst jeder seine Website editieren kann. ;-) Eine integration mit Springsecurity für die elementaren Notwendigkeiten, wie sie in der App Engine zur Verfügung stehen, scheint schlank zu sein, aber ich hatte dieses Wochenende einfach keine Lust dazu. Ich ziehe die Lösung aber jedem kleinen CMS vor.