Open-Source Perlen: Mit XDoclet EJBs generieren

Beans aufblasen

Stefan Edlich

In dieser Serie, die mit der vorliegenden Ausgabe des Java Magazins startet, werden künftig verschiedene Open Source-Perlen vorgestellt werden – kleine, aber sehr nützliche Open-Source Werkzeuge. Gestartet wird mit XDoclet, einer erweiterten Javadoc-Engine, mit der man auf einfache Weise EJBs, Deployment-Deskriptoren und vieles – für das Web-Development nützliche – mehr generieren kann.

Als Entwickler steht man des öfteren vor dem Problem, welches Tool man für die Erstellung von EJBs und den dazugehörigen Deployment-Deskriptoren auswählen soll. Neben der reinen Handcodierung – die nicht wirklich Spaß macht – gibt es eine Reihe von leistungsfähigen IDEs, die in den zurückliegenden Ausgaben vorgestellt wurden. JBuilder und Together sind mit Ihren Wizards oder Apply-Pattern-Features zwar sehr nützliche Werkzeuge, sie können aber für Privatentwickler preislich nicht gerade als Schnäppchen bezeichnet werden.

Seit kurzem ist hier aber aus der Open-Source-Szene Hilfe durch eine Vielzahl von neuen Werkzeugen verfügbar, wie z.B.:

  • XDoclet [1]
  • EJBgen [2]
  • UML2EJB [3]
  • MiddleGen [4]

UML2EJB und MiddleGen sind grafische Werkzeuge, die aus UML oder Datenbankschema EJBs generieren und im ersten Fall sogar auf XDoclet aufsetzen. Das interessante an XDoclet oder dem von BEA favorisierten EJBgen ist aber, daß es durch einfache Javadoc-Tags im Code der Komponente nahtlos in den Entwicklungszyklus der eigenen IDE integriert werden kann und so keinen Werkzeugbruch erfordert.

XDoclet kann mittlerweile Deskriptoren für über zehn Application Server generieren und unterstützt auch andere Bereiche wie JDO-Produkte, SOAP, Struts, JSP-Taglibs und vieles mehr. Dafür wird in der aktuellen Version sogar ein eigenes Doclet und nicht mehr die Javadoc Parser-Klasse verwendet.

... // imports
/**
* @ejb.bean	type=stateless
*		name=SessionTemplate
* 		jndi-name=template
* 		display-name=Template Session Bean Stateless
*/

public class SessionTemplateBean implements SessionBean {
/**
* @ejb.interface-method
*/
public int methodA(int a, int b) {
return a + b; // Do sth
}
/**
* @ejb.interface-method
*/
public int methodB(int a, int b) {
return a * b;  // Do sth
}
... // sonstige (EJB)-Methoden
}

Listing 2: Ant-Skript für XDoclet


Die beiden Codebeispiele der Version 1.1.2 zeigen die Generierung einer einfachen Session Bean. Folgende Schritte sind zum erfolgreichen Generieren mit XDoclet nötig:

  • Download der Jar-Bibliotheken
  • Einbettung der Javadoc-Tags in den Bean-Code
  • Einbettung oder Entwicklung des Ant-Tasks ejbgen in das Build-Skript

Beim Betrachten der Beispiele fallen drei Dinge auf:

  • Im Bean-Header wird mit der Syntax @ejb:bean (neuerdings wird nur noch ein einfacher Punkt verwendet) gefolgt von Attributen name=value, die Bean oder anderer Code näher ausgezeichnet.
  • Die eigentlichen Beanmethoden werden wie im Codebeispiel mit Kommentaren vor der Methode selbst ausgezeichnet. Möglich sind hier Tags wie @ejb:relation, ejb:home-method, ejb:persistent-field, ejb:pk-field, etc.
  • Im Ant-Task wird ein durch die XDoclet-Bibliothek definierter Task ejbdoclet aufgerufen. Die Art der Bean oder des Source-Codes bestimmen hier, was der Entwickler generieren kann: EJBs, Web-Dateien oder -Deskriptoren, JDO-Information, usw. In unserem Fall der EJB-Generierung können im ejbdoclet-Task Elemente wie , , , und andere angegeben werden, um die gewünschten Informationen zu generieren.

Für eine CMP Entity Bean (Message Driven Beans können auch generiert werden) muss nicht viel mehr als in den Beispielen angegeben eingefügt werden:

  • Im Javadoc-Code muss z.B. ein anderer Type (CMP), ein Primary-Key Feld und im Namespace @ejb:finder die entsprechende Methode angegeben werden.
  • Im Ant-Script wird dann meistens nicht mehr als mit z.B. und die entsprechenden Klassen generiert und für die Application-Server (z.B. ) spezifische Informationen wie DataSources angegeben.

Beispiele dafür sind im Netz und in der XDoclet-Distribution (build.xml) ausreichend vorhanden.

In der Praxis zeigt sich, dass sich der Installationsaufwand in Grenzen hält und das XDoclet für Ant-basierte Projekte ziemlich gut passt. Hilfreich ist dabei, wenn sich der Entwickler mit der Zeit einen Satz an korrekten (Javadoc)-Templates definiert, die die von ihm verwendeten Beans auszeichnen. Diese sollten dann zusätzlich einen Hinweis auf die zu verwendenden Ant-Teile im EJB-Task enthalten.

Weiterhin sind komplexe (EJB 2.*)-Projekte mit XDoclet aufgrund der Vielzahl der XML relationships aber nicht trivial beherrschbar, da XDoclet kein Modellierungswerkzeug ist. Da solche Projekte aber eher im professionellen Projektumfeld auftreten, würde man hier wahrscheinlich doch eher auf (evtl. teurere) grafische IDEs zurückgreifen.

Geschrieben von
Stefan Edlich
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.