Inhalt
Installation JBoss/Eclipse
Eclipse und WebTools-Plugin konfigurieren:
JBoss-KnowHow:
Installation JBoss/Eclipse
Benötigte Komponenten
- JDK 1.5.0 (http://java.sun.com/) installieren. Aktuell ist dies 1.5.0_13 (http://java.sun.com/javase/downloads/index_jdk5.jsp)
- JBoss 4.2.2 GA (http://www.jboss.org/) installieren
Eine gute JBoss-Doku findet man hier: http://docs.jboss.org/jbossas/jboss4guide/. Aktuell ist dies Release 5 ("r5") der Doku,
allerdings ist der J2EE-Teil noch auf dem Stand von 1.4. Die Doku eignet sich nur zum Kennenlernen der JBoss-Architektur.
Die Einführung in EJB3 aus JBoss-Sicht gibt es im "EJB3 Trailblazer" (http://www.jboss.com/docs/trailblazer),
wobei diese Beispiele noch weniger in die Tiefe gehen als meine eigenen ;-). Für den Download muss man sich bei JBoss online registrieren,
ich kann aber auf Anfrage den Trailblazer zur Verfügung stellen.
- Eclipse 3.3.1.1 (http://www.eclipse.org/ bzw.
http://download.eclipse.org/eclipse/downloads/drops/R-3.3.1.1-200710231652/index.php).
Achtung: hierbei handelt es sich nicht um eines der von Eclipse vorgebündelten Pakete sondern nur um die Basisvariante.
- Eclipse-Plugins:
-
Für Mac-User (alle Tips aus Studenten-Hand, ich weiß von nix ;-) ):
- 1. Scheinbar macht Subclipse Probleme. Nach Eclipse direkt Subclipse zu installieren,
danach erst die Plugins ins Eclipse-Verzeichnis entpacken.
- 2. Kopieren per Finder: Wichtig - der Finder überschreibt (!) ganze Verzeichnisse und kopiert nicht die Inhalte hinein.
Das geht mit dem cp-Befehl mit R-Schalter per Terminal. Sonst ist beim Verschieben von Plugins plötzlich der Original-Inhalt weg...
Eclipse und WebTools-Plugin konfigurieren
JBoss 4.2.2
In "Window" -> "Preferences..." gehen und links in der Übersicht den Punkt "Server" -> "Installed Runtimes" wählen.
Über "Add..." einen neuen Server zufügen.
Wir wählen einen Server vom Typ "JBoss v4.2" aus.
Die Checkbox "Also create new local server" können wir ignorieren, den lokalen Server kann man später auch per Hand anlegen.
Im nächsten Schritt als Runtime die Default-Java-Runtime (sollte ein JDK 1.5 sein) auswählen und als "Application Server directory"
das Wurzel-Verzeichnis des JBoss auswählen. Liegen wir beim "Application Server Directory" falsch wird uns das durch Fehlermeldungen mitgeteilt.
WebTools-Plugin goes Internet
Jedesmal wenn man eine XML-Datei öffnet oder sie von einem Buildprozess berührt wird versucht der Plugin sie
gegen ihre DTD oder ihre Schemadefinition zu validieren.
An der FH müßt ihr den Proxy unter "Window" -> "Preferences" im Punkt "General"-> "Network Connections" eintragen.
Die DTDs und XSDs werden nach dem Laden aus dem Internet und in einem lokalen Cache gespeichert.
Den Inhalt des Caches kann man unter "Window" -> "Preferences" im Punkt "Internet" ->
"Cache" anschauen, oder im Dateisystem im Workspace-Unterzeichnis ".metadata\.plugins\org.eclipse.wst.internet.cache".
ACHTUNG: Falls euer Internetprovider die Angewohnheit hat den ersten Zugriff nach Aufbau der Verbindung auf die
eigene Homepage umzuleiten kann es sein dass dies genau die DTD-Definition ist die der WTP-Plugin laden will. Und schon hat
er eine HTML-Datei gefressen und meckert über das falsche Format.
Eclipse-Tuning
Folgende Einstellungen empfehle ich, um Eclipse schneller und Resourcenschonender einzustellen:
Automatischen Build ausschalten
Die Option "Build Automatically" im Menü "Project" wird ausgeschaltet:
Das bedeutet dass man das Compilieren vor einem Deploy per Hand durch "Build Project" bzw. "Build All" anstoßen muss.
Server-Publish
In der Default-Einstellung führt Eclipse regelmäßig ein Deploy auf den Server durch, auch wenn wir das garnicht wollen weil wir
sowieso mitten im Coden stecken. Deshalb in den Preferences die Optionen "Automatically Publish to local/remote servers" abschalten:
Die Option "Automatically publish when server startup" wird ebenfalls abgeschaltet.
Rechtschreibprüfung abschalten
Die integrierte Rechtschreibprüfung (per Default sowieso nur englisches Wörterbuch) wird abgeschaltet da dies sehr viele Resources kostet:
Eclipse-Codeformatter
Damit der Quellcode zumindest innerhalb einer Projektgruppe bei allen gleich aussieht empfehle
ich die Codeformatierungs-Optionen von Eclipse zu vereinheitlichen. Dies geschieht über "Window" ->
"Preferences" -> "Java" -> "Code Style" -> "Formatter", wo man ein neues Profile zufügt.
Im folgenden die in meinen Beispielen verwendeten Einstellungen:
Eine Mischung aus Tabs und Leerzeichen sieht in einem anderen Editor meistens müllig aus,
deshalb nur Leerzeichen für Einrückung verwenden. Und mit nur 2 Leerzeichen sparen wir Platz.
Ich bevorzuge öffnende Klammern auf der gleichen Spalte wie die schließende Klammer, also
viele Zeilenumbrüche.
Passend zu den Zeilenumbrüchen vor öffnenden Klammern mag ich sie auch nach schließenden Klammern.
Die maximale Zeilenlänge bis zu einem vom CodeFormatter erzwungenen Zeilenumbruch würde
ich von 80 auf 120 erhöhen.
Angewendet werden diese Einstellungen automatisch beim Tippen. Man kann aber auch nachträglich eine Datei formatieren,
indem man sie öffnet und im Editor-Contextmenü den Punkt "Source" - "Format" wählt:
Für die Formatierung von HTML-/JSP-Seiten finden wir die Formatierungseinstellungen unter "Window" -> "Preferences" ->
"Web and XML" -> "HTML Files" -> "HTML Source". Auch hier werden Tabs abgeschaltet sowie die Zeilenlänge auf 120 Zeichen hochgedreht.
Javadoc
In den Preferences werden die JavaDoc-Warnungen eingeschaltet:
Projektstruktur
Die Struktur eines Projekts (im Beispiel das Stateless-Beispiel mit EJB-Projekt, Webprojekt
und ApplicationClient) sieht auf Festplatte so aus:
- Im Verzeichnis "StatelessClient\appClientModule" finden wir die Java-Quelldateien und im
Unterverzeichnis "META-INF" die von XDoclet erzeugten Deskriptoren. In "StatelessClient\build\classes"
werden beim Build des Projekts die compilierten "class"-Dateien sowie benötigte Deployment-Deskriptoren
abgelegt.
- Dito für "StatelessEJB\ejbModule": hier liegen die Java-Quelldateien und im
Unterverzeichnis "META-INF" die von XDoclet erzeugten Deskriptoren. In "StatelessEJB\build\classes"
laden beim Build die "class"-Dateien und die Deployment-Deskriptoren.
- Beim Webprojekt liegen die Java-Dateien im Unterverzeichnis "JavaSource", während die Deskriptoren
und die JSP-Dateien im Verzeichnis "WebContent" liegen. In "StatelessWeb\build\classes"
werden beim Build des Projekts die compilierten "class"-Dateien erstellt (hier werden allerdings keine
Dateien aus WEB-INF kopiert).
- In "Stateless\EarContent" liegen die Deployment-Deskriptoren der EAR-Anwendung.
Wird das Projekt auf einen Server geschoben (im Beispiel ein JBoss) muss die EAR-Datei erstellt werden.
Dazu werden alle relevanten Daten in das Verzeichnis
"%WORKSPACE%\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\Stateless\"
geschoben.
Hier landen die JAR-Dateien für die einzelnen Module (StatelessClient.jar, StatelessEJB.jar und StatelessWeb.war)
sowie der Deployment-Deskriptor der gesamten Anwendung. Aus diesen Daten wird die EAR-Datei erzeugt und auf den Server verschoben.
Debugging
Zum Debuggen dürfen wir den JBoss nicht "normal" starten sondern im Debug-Modus (Rechtsklick auf den Server, "Debug"
wählen).
Im folgenden beziehe ich mich auf Klassen aus dem ersten Beispiel, "Stateless".
Wir setzen einen Breakpoint im doPost von GeometricModelServlet. Anschließend im Browser zu dieser URL navigieren:
http://localhost:8080/StatelessWeb/servlet/GeometricModelServlet.
Wenn wir alles richtig gemacht haben schiebt sich Eclipse in den Vordergrund, und wir werden gefragt ob wir
in die Debug-Perspective wechseln wollen (machen wir natürlich).
In der Toolbar können wir jetzt Einzelschritte ausführen, in Funktionen springen oder aus einzelnen Funktionen hinausspringen. Über die Schaltfläche "Resume"
können wir die Verarbeitung bis zum nächsten Breakpoint weiterlaufen lassen.
Anmerkung: beim Testversuch war in der View "Debug" ein völlig falscher, bereits beendeter Prozess gewählt. Hier muss eventuell erst der Thread
gesucht und gewählt werden in dem unser Breakpoint liegt.
Auf diese Weise können wir sogar JSP-Seiten debuggen !
JBoss-Knowhow
Generierte JSP-Java-Klassen
Zu JSP-Seiten generiert der in den JBoss integrierte Tomcat 5.5 Java-Dateien, diese wiederum
werden ganz normal compiliert. Die generierten Java-Dateien findet man hier:
JBOSS_DIR\server\default\work\jboss.web\localhost\WEBAPP\org\apache\jsp.
Ein Blick in diese Dateien ist bei Compilefehlern in der JSP-Seite nötig, da die Zeilenangaben
sich auf die Java-Datei beziehen und nicht auf auf die JSP-Datei.
JMXConsole und JNDIView
Unter http://localhost:8080/jmx-console
erreicht man die JMXConsole, über die JBoss seine MBeans für die interne Serververwaltung
anzeigt. In der Gruppe "jboss" finden wir service=JNDIView
Der Service ist auch direkt über diese URL zu erreichen: http://localhost:8080/jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss%3Aservice%3DJNDIView.
Diesen Service öffnen. Wir sehen einige Properties der MBean sowie einige Operations.
Uns interessiert java.lang.String list()
. Wir führen sie aus indem wir auf Invoke
klicken.
Die folgenden Ausgaben entstanden als das Stateless-Beispiel deployed war:
Im "Global JNDI Namespace" finden wir unsere diversen Beans (Remote- und Local-Home-Interfaces) sowie den Environment Naming Context
des Clients hinterlegt. Web-Projekte sind in einer eigenen Kategorie aufgelistet (im Beispiel "java:comp namespace of the Stateless.ear/StatelessWeb.war application",
ich habe die beiden Ausschnitte auf dem Screenshot näher zusammen gebracht)
Logging
In allen Beispielen wird das Logging mittels der Klassen des Packages java.util.logging
verwendet. Im Code sieht das so aus:
Auf Klassenebene wird ein Logger deklariert (Codefragmente aus dem Stateless-Beispiel):
protected static final Logger logger = Logger.getLogger(GeometricModelBean.class.getName());
Die Logausgabe erfolgt so:
logger.info("computeCuboidVolume mit a = " + a + ", b = " + b + ", c = " + c);
Die Logdatei ist beim JBoss im Default in "JBOSS_DIR\server\default\log\server.log" und enthält z.B. nützliche Infos
zu den EJB-QL-Abfragen.
Das Verhalten des Logger-Moduls wird über eine Property-Datei konfiguriert. Im Default
ist dies "JRE_DIR\lib\logging.properties".
Im folgenden der Inhalt des Sun-JDK 1.5.0 (Kommentare entfernt):
# Global properties
handlers= java.util.logging.ConsoleHandler
.level= INFO
# Handler specific properties.
# Describes specific configuration info for Handlers.
# default file output is in user's home directory.
java.util.logging.FileHandler.pattern = %h/java%u.log
java.util.logging.FileHandler.limit = 50000
java.util.logging.FileHandler.count = 1
java.util.logging.FileHandler.formatter = java.util.logging.XMLFormatter
# Limit the message that are printed on the console to INFO and above.
java.util.logging.ConsoleHandler.level = INFO
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
Es wird ein Console-Logger definiert (d.h. alle Logausgaben landen auf System.out).
Ein File-Handler wird zwar initialisiert, aber nicht aktiviert. Der FileHandler verwendet
das XML-Format.
Um jetzt einen Logger zu aktivieren, der die Ausgabe in eine Datei umleitet und nur Ausgaben
unseres Stateless-Loggers anzeigt, wird die Datei so modifiziert (am besten eine Kopie an beliebiger
Stelle anlegen und diese ändern !).
# Global properties
handlers= java.util.logging.FileHandler
.level= INFO
# Handler specific properties.
# Describes specific configuration info for Handlers.
java.util.logging.FileHandler.pattern = c:/PFAD/ZUR/LOGDATEI/logdatei.log
java.util.logging.FileHandler.limit = 50000
java.util.logging.FileHandler.count = 1
java.util.logging.FileHandler.formatter = java.util.logging.SimpleFormatter
# Facility specific properties.
# Provides extra control for each logger.
de.fhw.swtvertiefung.knauf.stateless.level = INFO
Der Konsolen-Logger wird durch einen Datei-Logger ersetzt, der statt XML einfachen Text ausgibt.
Für alle Klassen deren Package mit "de.fhw.swtvertiefung.knauf.stateless" beginnt wird das Loglevel auf "INFO" gesetzt.
Würden wir hier das globale Log-Level (".level = INFO") auf einen Wert wie WARNING oder SEVERE
setzen würden wir keine Ausgaben (bzw. nur noch wirkliche Fehler) aus den anderen Packages
erhalten.
Dem Logger müssen wir noch erzählen wo unsere Config-Datei liegt. Dies geschieht durch das
Kommandozeilenargument
-Djava.util.logging.config.file=c:/PFAD/ZUR/CONFIGDATEI/logging.properties
Für den JBoss-Server ist das Vorgehen so:
Im Default geht die Logausgabe über das java.util.logging-Package auf die Konsole.
Um den Server dazu zu bringen, diese Konfigurationsdatei zu verwenden müssen wir folgendes tun:
Rechtsklick auf einen vorhandenen Server, "Open" wählen. Es erscheint die "Server Overview".
Wir klicken auf "Open Launch Configuration". Auf der Karteikarte "Arguments" geben wir den Pfad zur Config-Datei an.
Schon haben wir die Logausgaben in der angegebenen Datei. Für den JBoss führt das erfreulicherweise sogar dazu dass
NUR die Ausgaben unseres eigenen Packages in dieser Datei ausgegeben werden, die des JBoss landen weiterhin
in der Standard-Datei "server.log". Dadurch haben wir alle unseren Logausgaben übersichtlich auf einem Haufen.
Stand 28.12.2007
Historie:
23.09.2007: Erstellt
26.09.2007: Abschnitt über Eclipse-Tuning zugefügt
30.09.2007: Eclipse 3.3.1
01.10.2007: Link zum modifizierten JBoss-Deployer
21.10.2007: Überschüssige Leerzeichen aus "logging.properties" entfernt, neues Eclipse-Paket
22.10.2007: Mac-Hinweis
25.10.2007: JavaDoc-Einstellungen, JBoss 4.2.2 (Aktivierung der Java-1.5-Unterstützung ist nicht mehr nötig)
30.10.2007: Mehr Mac-Tips
01.11.2007: Eclipse 3.3.1.1
05.11.2007: Verweis auf Data Tools Platform fehlte in Installationsanleitung
19.12.2007: JBoss-Paket aktualisiert mit neuer JSF-Version
28.12.2007: JSF-Workaround wieder rückgebaut, JBoss-Paket wieder auf den Standard gesetzt