Folgende Bücher helfen mir gerade sehr bei dem Thema:

• On Lisp. Der Klassiker von Paul Graham. Inzwischen frei und kostenlos im Web verfügbar.
• Land of Lisp
• Clojure in Action
• Programming Clojure

Für die Verwaltung von Clojure Projekten hat sich Leiningen als hilfreich erwiesen. Es bietet unter anderem die einfach Einbindung von Libraries über Maven-Repositories, allerdings ohne die Umständlichkeit von Maven selbst.

Libraries aktuell auf meinem Radar rund um Clojure:

• Ring: kompakte HTTP Abstraktion, eine gute Basis für Web-Applikationen
• Compojure: Web-Framework, das auf Ring aufsetzt. Bietet unter anderem Möglichkeiten zur einfachen Definition von Routen und stellt grundlegende Middleware bereit.
• Hiccup zur Generierung von HTML
• Midje für Test Driven Development

Das ist doch mal wirklich nett

Bin u. a. vertraut mit

• Spring Framework
• Hibernate
• Groovy
• Grails
• Eclipse
• Java Servlets
• JavaScript
• Dojo, jQuery, YUI
• SQL, HQL
• …

Einblenden kann man ihn über das Menü Window -> Show View -> Other. Dann erscheint der Show View Dialog und der Display-View befindet sich dort im Ordner “Debug”.

Wenn man dann beim Debugging bei einem Breakpoint angehalten hat, kann man in diesem View Code-Schnippsel eintippen, die entweder einen Ausdruck darstellen oder auch Methoden von Objekten aufrufen, die an der aktuellen Codestelle zur Verfügung stehen.

Wenn man einen Ausdruck eingegeben hat, markiert man ihn und kann dann entweder per Context-Menü -> Display oder dem Shortcut Ctrl+Shift+D das Ergebnis dieses Ausdrucks ausgeben lassen:

Bei einer Anweisung, die man ausführen möchte (also beispielsweise eine Methode eines Objekts im aktivem Debugging-Context). Geht man ebenso vor – Code eintippen, markieren – nur drückt man dann Ctrl+U oder wählt im Context-Menü -> Execute.

Soweit so gut. Was ich jedoch bei einer der letzten Debugging-Sessions entdeckt hatte: der Code, der mit Execute ausgeführt werden kann, kann über den Aufruf einer einzelnen Methode hinausgehen. Man kann ihn beliebig komplex formulieren, solange er syntaktisch korrekt ist, und nur auf Variablen und Objekte Bezug nimmt, die im aktivem Debugging-Context erreichbar sind:

Wenn man sich beispielsweise komplexere Strukturen per for-Schleife durchsuchen lassen möchte, und dabei mit System.out.println() Daten ausgibt, erscheinen diese in der Eclipse-Console-View.

Eine letzte Anmerkung noch: wenn man bei der Ausführung von Ausdrücken oder Code-Blöcken wieder durch Code läuft, in dem man Breakpoint platziert hat, wird Eclipse dort nicht anhalten, sondern eine Meldung ausgeben: verschachteltes Debugging wird nicht unterstützt.

Das ist für 99,9% der Einsatzzwecke wohl richtig und sinnvoll.

Wenn man in einem Projekt jedoch unterschiedliche Deployment-Descriptoren vorhält (beispielweise um verschiedene Staging-Systeme abzubilden, oder für unterschiedliche Einstellungen einer Applikation für Backend- und Frontend-Modus) muss man vor dem Server-Start immer die “richtige” Datei zur WEB-INF/web.xml umbennen.

In diesen Fällen wäre es praktisch, wenn man Tomcat sagen könnte, die Web-Application aus einem anderen Descriptor-File zu holen.

Ein undokumentiertes Feature des Tomcat erlaubt genau diese Angabe eines alternativen Descriptor-Files:

<Engine defaultHost="localhost" name="Catalina">
  <Host appBase="webapps" autoDeploy="false" name="localhost" unpackWARs="false"
        xmlNamespaceAware="false" xmlValidation="false">
    <Context docBase="my-application-path" path="" reloadable="false"
        altDDName="my-application-path\web\WEB-INF\web-beta.xml"/>
  </Host>
</Engine>

Dem Context wrid über das altDDName Attribut der Name des alternative deployment descriptors bekanntgegeben.

Damit wird der Tomcat noch flexibler einsetzbar.