{"id":847,"date":"2010-12-20T13:09:24","date_gmt":"2010-12-20T11:09:24","guid":{"rendered":"http:\/\/www.tutego.de\/blog\/javainsel\/2010\/12\/buchkritik-xdoclet-in-action\/"},"modified":"2010-12-20T13:09:24","modified_gmt":"2010-12-20T11:09:24","slug":"buchkritik-xdoclet-in-action","status":"publish","type":"post","link":"https:\/\/www.tutego.de\/blog\/javainsel\/2010\/12\/buchkritik-xdoclet-in-action\/","title":{"rendered":"Buchkritik: XDoclet in Action"},"content":{"rendered":"<p><a href=\"http:\/\/www.amazon.com\/Craig-Walls\/e\/B001JOVOZ6\/ref=ntt_athr_dp_pel_1\"><em>Craig Walls<\/em><\/a><a href=\"http:\/\/www.amazon.com\/XDoclet-Action-Craig-Walls\/dp\/1932394052\"><\/a><em>, <\/em><a href=\"http:\/\/www.amazon.com\/s\/ref=ntt_athr_dp_sr_2?_encoding=UTF8&amp;sort=relevancerank&amp;search-alias=books&amp;field-author=Norman%20Richards\"><em>Norman Richards<\/em><\/a><em>. Manning. ISBN 1-932394-05-2. 2004. 600 Seiten<\/em><\/p>\n<p>XDoclet selbst stammt von Rickard \u00d6berg, der auch das Vorwort f\u00fcr das Buch geschrieben hat, aber Craig (war selbst XDoclet Committer) und Norman leisten gute Arbeit, XDoclet vollst\u00e4ndig zu beschreiben \u2013 \u00d6berg hat Korrektur gelesen. Der Ursprung des Buches liegt laut Autoren in der Motivation XDoclet selbst besser zu verstehen, doch die Autoren sind allgemein und gr\u00fcndlich genug, damit Leser unterschiedlicher Bildungsschichten etwas davon haben. (Allerdings h\u00f6rt es in der Tiefe dann irgendwann einmal auf, das hat aber nichts mit XDoclet selbst zu tun, sondern etwa rund um EJB-Assoziationen.) Das erste Kapitel f\u00fchrt die Grundlagen von Codegenerierung ein und wie XDoclet ins Bild passt. Aktiver wird von passiver Codegenerierung unterschieden, unterschiedliche Ursprungsformen werden geschrieben und diskutiert ob und wie XDoclet ins eigene Projekt passt. Kapitel 2 ist technischer und f\u00fchrt Tags und Ant-Tasks ein, um Generierung von Todo-Listen zu zeigen. XDoclet Tasks und Subtasks werden kurz vorgestellt. Es folgt eine Kurzeinf\u00fchrung in Templates f\u00fcr die Codegenerierung, etwas detailliert vielleicht zu Anfang, aber in Ordnung. Im sp\u00e4teren Kapitel kommt das noch sehr genau zur Sprache. Es folgt das Konzept der wichtigen Merge-Points und das Kapitel schlie\u00dft mit dem Bigger-Picture und der Feststellung, dass Metadaten nur an einer Stelle stehen sollte und Redundanzen minimiert werden m\u00fcssen. Es folgt der zweite Abschnitt, der sich konkret mit dem EJB-Doclet, und XDoclet f\u00fcrs Web besch\u00e4ftigt. Kapitel 3 ist f\u00fcr die klassischen J2EE 1.4 Entwickler das wichtigste Kapitel. Das Beispiel ist mit einem Weblog gut und anschaulich gew\u00e4hlt. Dass die Property im UML-Diagramm allerdings \u201etest\u201c hei\u00dft ist ein Fehler; es sollte \u201etext\u201c hei\u00dfen. Alle zentralen Tags werden an Beispielen gezeigt, also wie ein Session-Bean getagt wird, eine Entity-Bean und die Beziehungen der Entiy Bean aufgebaut, und wie eine Fassade und Utility-Klasse generiert werden und was im Prinzip darin steckt (Quellcode w\u00e4re gut gewesen hier). Es folgt die Generierung eines Value Objects (VO) was die Autoren hier mit dem Data Transfer Object (DTO) gleichsetzen, aber heutzutage trennt man die Konzepte. Matcher f\u00fcr unterschiedliche VOs kommen zur Sprache genauso wie Aggregationen und Composites, also das auch die assoziierten Objekte einer CMP mit in das VO aufgenommen werden. Die Beschreibung k\u00f6nnte allerdings etwas detaillierter sein und es w\u00e4re eine Bereicherung, wenn die Autoren alle Szenarien, also 1:1, 1:n, n:m einem Bi- und einmal Unidirektional durchgespielt h\u00e4tten. Das Kapitel schlie\u00dft mit den Sicherheits-Tags, Finder\/Selector und einer \u00dcbersicht, welche Dateien XDoclet f\u00fcr das Blog-Beispiel generiert, Transaktionsattributen, DAOs f\u00fcr BMP und Message Driven Beans. Gew\u00fcnscht h\u00e4tte ich mir noch eine Zusammenfassung mit einer Gegen\u00fcberstellung der Tags mit dem Ergebnis im Deployment-Deskriptor bzw. Quellcode. Kapitel 4 widmet sich der Web-Tier. Der Ant-Task webdoclet wird vorgestellt und es beginnt mit dem Tag f\u00fcr Servlets, Filter, Listener und JSP-Tag-Libs, damit die web.xml erstellt wird. Das Beispiel f\u00fchrt die Idee des Blogs fort. Die Qualit\u00e4t der Quellcodebeispiel ist relativ gut wobei mir bei Listing 4.7 auff\u00e4llt, dass die Autoren folgendes f\u00fcr doEndTag() schreiben:<\/p>\n<p>try {<\/p>\n<p>if(date != null) {<\/p>\n<p>SimpleDateFormat formatter = new SimpleDateFormat(format);<\/p>\n<p>pageContext.getOut().write(formatter.format(date));<\/p>\n<p>}<\/p>\n<p>} catch (IOException e) { }<\/p>\n<p>return EVAL_PAGE;<\/p>\n<p>}<\/p>\n<p>Die IOException zu schlucken ist vielleicht nicht so toll (in den \u00fcbrigen Beispielen wird sch\u00f6n geloggt) und ich frage mich, warum der String format zwar in der Objektvariablen gehalten wird, aber warum nicht gleich SimpleDateFormat (und dann auch vom Basistyp DateFormat, der f\u00fcr format() reicht). M\u00f6glicherweise wissen die Autoren das die java.util.Format-Klassen nicht Thread-sicher sind, vergessen aber, dass die Tag-Objekte nicht wie die Servlet-Klassen geteilt werden, sondern der Servlet-Container wegen des Zustands der Tag-Objekte immer neue aufbaut (sogar bei jedem Request!) und es somit keine parallelen Zugriffe auf doEndTag() gibt. Es folgt das 5. Kapitel, welches die XDoclet-Unterst\u00fctzung f\u00fcr Struts und Web-Works vorstellt. Es werden zwei wichtige Merge-Points f\u00fcr web.xml vorgestellt, dann folgend Details \u00fcber die Struts-Actions und Validatoren und WebWork, bei dem sich die Aussage \u201eAnother web-layer framework that is gaining in popularity is OpenSymphony\u2019s WebWork\u201c nicht bewahrheitet hat. Kapitel 6 springt dann wieder in die Welt der Application-Server und beschreibt Tags f\u00fcr die Container-spezifischen Deployment-Deskriptoren exemplarisch an JBoss und WebLogic. Das beendet den zweiten Abschnitt und der dritte Abschnitt beginnt mit spezielleren Technologien Hibernate\/JDO\/Castor, der alten Axis-Version, JMX, Mock-Objekte und Portlets. Hibernate wird nicht allzu tief vorgestellt, was ein echtes Manko ist, denn die XDoclet-Unterst\u00fctzung ist\/war perfekt und Entwickler griffen gerne zu XDoclet, um sich die .hbm.xml generieren zu lassen. Hier muss dann die Dokumentation aus dem Anhang oder der Webseite aushelfen, denn das Buch kommt \u00fcber ein paar einfache Properties und Relationen nicht hinaus, denn sofort geht es zu JDO und dann Castor JDO, Castor XML. Es folgen Web-Services mit Apache SOAP (dem Vorg\u00e4nger von Axis 1) und Axis 1 dann in Kapitel 8 und wie XDoclet die Deployment-Deskriptoren generiert. Es folgt der Hinweis, das f\u00fcr die Serializer und Deserializer keine Tags existieren, stattdessen ein Merge-Point genutzt werden muss. Damit schlie\u00dft das Kapitel und das Kapitel 9 widmet sich einer Kurzeinf\u00fchrung zu JMX und kommt dann zu Generierung von MLET-Dateien und der unterschiedlichen Descriptoren f\u00fcr Container wie JBoss oder MX4J. Kapitel 10 entfernt sich komplett von Java EE-Technologien und geht auf Mock-Objekte ein; eine Schnittstelle Automobile wird getaggt und XDoclet erzeugt eine Klasse AutomobileMock. Warum die Autoren allerdings eine Schnittstelle mit 15 (!) Operationen deklarieren und nicht 1 und dann auch nicht bei Ihrem Blog-Beispiel bleiben bleibt im Dunkeln. Die 15 Operationen f\u00fchren jedoch dazu, dass die AutomobileMock.java \u00fcber 700 Zeilen dick ist und nicht abgebildet werden kann. Anschlie\u00dfend zeigt ein Beispiel wie im JUnit-Testfall das Mock-Objekt initialisiert und genutzt wird. Da XDoclet kein bekanntes Mock-Framework nutzt, ist die Bedeutung der L\u00f6sung gering. Kapitel 11 w\u00fcrde eigentlich viel besser an die Java EE Technologie passen, denn es beschreibt Portles und welche XDoclet-Tags es f\u00fcr welche Eintr\u00e4ge im Deployment-Deskriptor portlets.xml gibt. Der letzte Abschnitt, beginnend mit Kapitel 12, geht tiefer in die Architektur von XDoclet ein und beschreibt, wie das Templating funktioniert und eigene Tags und Tasks entwickelt werden. Der 4. Abschnitt nimmt viel Raum ein. Zun\u00e4chst stellte Kapitel 12 heraus, warum man sich mit Codegenerierung besch\u00e4ftigten sollte. Es beginnt mit der Aggregation, also dem Sammeln von Informationen und einem einfachen Template; dabei werden die Grundelemente vom .xdt-Format der XDoclet-Template-Dateien vorgestellt. Es folgt die Transformation mit einem Factory-Generator \u2013 das ist anschaulich und f\u00fcr jeden gut verst\u00e4ndlich. Danach spielen die Autoren den Template-Mechanismus f\u00fcr einen Command-Konfiguration weiter und stellen Tags vor um alle Attribute aus den Java-Klassen, etwa Felder, Konstruktoren auszulesen; das ganze erinnert ein wenig an Reflection. Es folgt ein eigener Content-Tag-Handler und Body-Tags, denn nicht alle l\u00e4sst sich in XDoclet so einfach umsetzen; es ist wie die JSTL unter Verbot von Skriptlets: Nur lesen ist einfach, aber Zwischenzust\u00e4nde halten wird schnell unleserlich. Das Kapitel schlie\u00dft mit einem Abschnitt, danit eigene Tags wie eingebaute aussehen \u2013 Ant steht naturgem\u00e4\u00df im Mittelpunkt. Im Kapitel 13 folgenden XDoclet-Erweiterungen und Tools, worunter die Autoren die IDE-Integration in IntelliJ und Eclipse (mit JBoss IDE) meinen und das MDA-Werkzeug AndroMDA und Middlegen, was Datenbanken ausliest und aus dem Schema XDoclet-versehene EJB-CMP-Klassen (oder JDO-Klassen) generiert. Abschlie\u00dfend gibt der Anhang A eine ausf\u00fchrliche Installationsanleitung f\u00fcr Ant und XDoclet und Anhang B listet die Tasks\/Subtasks auf, Anhang C gibt auf \u00fcber 100 Seiten eine sch\u00f6ne \u00dcbersicht \u00fcber alle XDoclet-Tags, Anhang D die XDt-Template-Syntax und zu aller letzt philosophiert Anhang E \u00fcber die Zukunftsaussichten von XDoclet. So kommt zu Sprache, dass es XDoclet 2 mit einer neuen Code-Generierungs-Engine Generame gibt sowie einem Code-Templating der auf Jelly bzw. Velocity zur\u00fcckgreift. Dass XDoclet durch Annotationen komplett sterben wird konnten die Autoren 2004 nicht ahnen; nur ein Jahr Mitte 2005 sp\u00e4ter bleibt die Uhr bei Version 1.2 stehen. Was ist also meine Zusammenfassung f\u00fcr das Buch? Wer mit XDoclet noch in alten Projekten zu tun hat, der wird dieses Buch m\u00f6gen. Es ist ausf\u00fchrlich und gut und die Beispiele sind hervorragend, fast immer durchgehend und zu abgehoben. Der Quellcode im Buch ist mehrheitlich in Ordnung, es gib immer wieder Kleinigkeiten, die mich an den Allgemeinen Java-API Kenntnissen und Wissen um die gesetzten Java-Idiomen der Autoren zweifeln lassen. Bei:<\/p>\n<p>String logLevel = config.getInitParameter(&quot;LogLevel&quot;);<\/p>\n<p>if(logLevel.equals(&quot;debug&quot;))<\/p>\n<p>muss man sich fragen, ob man wirklich auf einen potenziellen null-Kandidaten equals() aufrufen m\u00f6chte \u2013 die Variante &quot;debug&quot;.equals(logLevel) ist da eigentlich angebrachter. Im Listing 7.9 ist eine public Standardkonstruktor als einziger Konstruktor ohne JavaDoc aufgef\u00fchrt; die paar Zeilen h\u00e4tte sich die Autoren auch schenken k\u00f6nnen und im gleichen Beispiel sind die Parametervariablen nicht prickelnd:<\/p>\n<p>public void setEmail(String string) { email = string; }<\/p>\n<p>public void setId(String string) { id = string; }<\/p>\n<p>Das gleiche auch f\u00fcr Property name und owner. Vom Beispiel 8.1 bin ich entt\u00e4uscht. Die String-Variable VOWELS ist mit &quot;AEIOUaeiou&quot; vorbelegt und dann folgt in der Methode:<\/p>\n<p>Character c = new Character(word.charAt(i));<\/p>\n<p>if(VOWELS.indexOf(c+&quot;&quot;) &gt;= 0)<\/p>\n<p>\u2026<\/p>\n<p>endBuffer.append(c.charValue());<\/p>\n<p>Hier Character-Objekte aufzubauen ist grober Unfug, ein <\/p>\n<p>char c = word.charAt(i);<\/p>\n<p>if(VOWELS.indexOf(c) &gt;= 0)<\/p>\n<p>\u2026<\/p>\n<p>endBuffer.append(c);<\/p>\n<p>h\u00e4tte es voll getan (die String#contains(CharSequence)-Methode gab es damals noch nicht, sie wurde erst mit Java 5 eingef\u00fchrt). In Listing 9.2 im JMX-Kapitel ist die Variable home ohne Sichtbarkeitsmodifizierer, aber private final w\u00e4re korrekter. Oder Listing 11.5 im Portlet-Kapitel:<\/p>\n<p>private static String[] states = { \u2026 }<\/p>\n<p>private static Set stateSet = new HashSet();<\/p>\n<p>static {<\/p>\n<p>stateSet.addAll(Arrays.asList(states));<\/p>\n<p>}<\/p>\n<p>Was soll das? Zun\u00e4chst kann states und stateSet final sein, aber davon abgesehen ist der static-Block \u00fcberfl\u00fcssig denn der Konstruktor von HashSet nimmt gerne eine Collection an. Besser also \u2013 und auch gro\u00dfgeschrieben, wie es die Autoren bei den anderen static-Variablen auch gemacht haben \u2013 w\u00e4re:<\/p>\n<p>private final static Set STATE_SET = new HashSet( Arrays.asList(states) );<\/p>\n<p>Es fallen weiterhin Kleinigkeiten und Fl\u00fcchtigkeitsfehler auf, etwa bei<\/p>\n<p>public class Widget {<\/p>\n<p>Widget() {<\/p>\n<p>}<\/p>\n<p>\/\/ &#8230; widget methods &#8230;<\/p>\n<p>}<\/p>\n<p>in dem der Konstruktor nicht public ist, die Klasse aber schon, und im Folgenden<\/p>\n<p>public Widget new Widget() {<\/p>\n<p>return new Widget();<\/p>\n<p>}<\/p>\n<p>was mit dem Leerzeichen auf keinen Fall ein g\u00fcltiger Methodenname ist. In Kapitel 12 steht in Tabelle 12.1 bei \u201eField\u201c in der rechten Zelle \u201eWorking with method fields\u201c, aber den Autoren ist beim Copy\/Paste wohl das \u201emethod\u201c durchgerutscht. Dann ist ifDoesntHaveclassTag falsch geschrieben, es sollte ifDoesntHaveClassTag hei\u00dfen, ein anderes Mal stimmen die Einr\u00fcckungen nicht. Aber diese Kleinigkeiten kann man verzeihen und haben kein gro\u00dfes Gewicht. Aber die Gretchenfrage ist: Sollte man sich das Buch kaufen wenn man nicht aus einem Altprojekt XDoclet erbt? Die Antwort ist eindeutig: N\u00f6. Statt Metadaten \u00fcber JavaDoc zu setzen sind es heutzutage Annotationen der Standard. XDoclet hat den Dreh nicht bekommen, sich zu einem allgemeinen Code-Generator zu mausern. XDoclet 2 erwartet zwar die Metadaten nicht mehr zwingend in den JavaDocs, sondern kann durch seine Modulf\u00e4higkeit die Metadaten prinzipiell auch aus Annotationen lesen, aber irgendwie interessiert sich keiner daf\u00fcr; Das Projekt kam nie aus der Planungsphase. Ein anderer Grund, dass XDoclet heute keine dominante Rolle mehr spielt, ist der Wegfall \u00fcberfl\u00fcssiger Klassen und Descriptoren aus modernen Frameworks. XDoclet machte EJB 2 angenehm, doch in EJB 3 ist XDoclet einfach nicht mehr n\u00f6tig, genauso wenig wie f\u00fcr Hibernate oder Web-Services. Schade um das Buch, ich mag XDoclet aber seit auch Servlet 3.0 auf Annotationen setzt wird auch die web.xml zur Nussschale. Daher wird auch kein Buch-Update mehr geben und so bleiben Versionen f\u00fcr immer eingefroren: JBoss 3.2, Servlet 2.3, Hypersonic Database statt HSQLDB, drei MBean-Typen (es sind nun 4, da Open MBean dazugekommen ist) und MX4J lebt im Buch noch. Wie schnelllebig die IT-Zeit doch ist.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Craig Walls, Norman Richards. Manning. ISBN 1-932394-05-2. 2004. 600 Seiten XDoclet selbst stammt von Rickard \u00d6berg, der auch das Vorwort f\u00fcr das Buch geschrieben hat, aber Craig (war selbst XDoclet Committer) und Norman leisten gute Arbeit, XDoclet vollst\u00e4ndig zu beschreiben \u2013 \u00d6berg hat Korrektur gelesen. Der Ursprung des Buches liegt laut Autoren in der Motivation [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":"","_links_to":"","_links_to_target":""},"categories":[6],"tags":[],"class_list":["post-847","post","type-post","status-publish","format-standard","hentry","category-rezension"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/posts\/847","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/comments?post=847"}],"version-history":[{"count":0,"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/posts\/847\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/media?parent=847"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/categories?post=847"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tutego.de\/blog\/javainsel\/wp-json\/wp\/v2\/tags?post=847"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}