Hat man mal ein dynamisches Webprojekt in Eclipse mit Tomcat 6 angelegt und will nun zurück auf Tomcat 5.5, kann das scheinbar nicht ganz so einfach sein. Will man nämlich in den Projekt Facets einfach die Dynamic Web Modul API von 2.5 auf 2.4 ändern, geht dies nicht. Man kann es zwar auswählen, doch nicht bestätigen, da Eclipse die Übernahme der Optionen verweigert.
Doch lässt sich dies ganz einfach Lösen. Einfach nicht den Einstellungs-Dialog von Eclipse nutzen und schon wird alles ganz einfach. In Eclipse einfach den Navigator-View auf machen und im betroffenen Projekt den Ordner “.settings” öffnen. Hier finden wir nun einiges Konfigurationsdateien, die zwar ganz nett sind, die Interessante ist aber “org.eclipse.wst.common.project.facet.core.xml“. Diese öffnen wir und ändern dort einfach den Parameter “<installed facet=”jst.web” version=”2.5″/>“. Hier nur die 2.5 gegen 2.4 austauschen, speichern und fertig. Und schon haben wir unsere Servlet API geändert. Jetzt sollte das Projekt auch wieder im Tomcat 5.5 laufen.
Heute wollte ich endlich mal JMX für meine Tomcats aktivieren. Doch entgegen aller Beschreibungen wollte dies nicht wirklich funktionieren.
Normaler weise muss man ja nur in “/TOMCAT_HOME/bin/catalina.sh” folgendes eintragen:
export CATALINA_OPTS=”$CATALINA_OPTS \
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=9494 \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.authenticate=false \
Danach hat man erstmal grob Zugang zum Tomcat. Natürlich sollte man das noch mit SSL und nem Passwort absichern. Doch ich wollte erstmal die grundsätzliche Funktionalität Testen. Doch jegliche Versuche damit schlugen fehl. Ersteinmal sei auch gesagt, dass ein “export” davor muss und kein “set“, wie manche schreiben. Bei einer normalen Tomcat Installation ist es damit dann auch schon getan. Doch bei Gentoo muss das ganze nicht in die catalina.sh eingetragen. Trägt man es dort ein, wird es schlicht und einfach ignoriert. Also wohin nun damit? Für den an Gentoo gewöhnten Admin ist es klar das das nach “/etc/conf.d/tomcat-5.5” muss, für einen Debian/Ubuntu Admin ist dies allerdings nicht ganz so klar. Und auch Google verschwieg mir dies Information. Ich hatte mich dann nur daran erinnert das neulich beim Apache ähnlich schritte vollführt werden mussten. Da war es dann auf einmal auch ganz logisch, das dies beim Tomcat ähnlich sein würde. Doch darauf kam ich erst nach einer deprimierenden Suche und vielen im Nachhinein unnötigen Test.
In die “/etc/conf.d/tomcat-5.5” muss nun eben das ganze ohne “export” am Anfang eingetragen werden. Wenn man in der Datei ein wenig nach unten geht, findet man auch schon eine dafür vorbereitet Stelle, um die Daten dort einzufügen. Natürlich können sie innerhalb der Datei überall stehen, doch ein wenig Ordnung schadet ja auch nicht. Also hab ich dann dort Folgendes eingefügt:
export CATALINA_OPTS=”$CATALINA_OPTS \
-Dcom.sun.management.jmxremote \
-Dcom.sun.management.jmxremote.port=9494 \
-Dcom.sun.management.jmxremote.ssl=false \
-Dcom.sun.management.jmxremote.authenticate=false \
Nachdem ich also alles in “/etc/conf.d/tomcat-5.5” eingetragen hatte, den Tomcat zum X. mal neu gestartet hatte, konnte ich mich nun endlich per jconsole auf diesen verbinden und mir das innere der JVM ansehen.
Wenn man in Bezug auf ant mal nicht javac als Compiler nehmen will sondern ECJ, dann braucht man nicht viel zu tun. Als erste schnappt man sich das “org.eclipse.jdt.core_3.4.2.v_883_R34x.jar” aus einer Eclipseversion. Hier zum Beispiel aus Eclipse 3.4.1.. Das kopiert man dann in das “lib”-Verzeichnis von ant. Bei mir liegt dies unter “/usr/share/ant/lib”. Wenn man da keine Schreibrechte hat, kann man das JAR auch nach “~/.ant/lib” kopieren. Dort findet es ant dann auch. So die Theorie, leider klappe das nicht ganz so einfach auf meinen Fedora 9 System. Ich musste noch aus dem oben genannten JAR das darin enthaltende “jdtCompilerAdapter.jar” entpacken und auch in das lib-Verzeichnis von ant. Danach ging alles. Und dieses alles ist folgendes: in seiner “build.xml” muss man jetzt nur noch ein spezielles “property” setzen.
<property name="build.compiler" value="org.eclipse.jdt.core.JDTCompilerAdapter" />
Und damit wären wir auch schon fertig! Jetzt wird beim kompilieren mit dem “javac task” immer ECJ genommen anstatt der Compiler des System-JDK.
Und wenn man mal “fehlerhafte” Klassen kompilieren will, kann man jetzt das “javac Flag” “failonerror” auf “off” setzten. Anders als der Standard Java Compiler, welcher den build-Prozess dann zwar als erfolgreich markiert, aber nichts macht, kompiliert ECJ auch fehlerhafte Klassen. Also zum Beispiel Klassen wo wiederum andere Klassen importiert werden, welche aber nicht im “Classpath” stehen. Denn ECJ bietet das Feature “proceedOnError”, welche durch ”failonerror=off” gesetzt wird.
<javac failonerror="off"> blubb </javac>
Java
| 
ant, ant task, build.xml, Classpath, compile, compiler, ecj, eclipse, eclipse.jdt, eclipse.jdt.core, failonerror, Java, javac, javac-task, jdt, JDTCompilerAdapter, Kompiler, kompilieren, Linux, proceedOnError, task
Wenn man viel mit Java zutun hat, kennt man das Problem der Versionen vllt. Also in der einen unterversion im JDK 1.5 ging noch alles, nach einen vermeintlich harmlosen update, geht auf einmal nichts mehr. Brauch man nun also wieder eine ältere Version muss man meist einige zeit suchen bis man die gewünschte gefunden hat. ja die Java seite is dann auch nciht allzu auskunftsfreundlich und liefert einen nur die aktuellen dinge.
Doch ein wenig versteckt biete Sun alle seine Versionen doch noch an. Es gibt sogar ein nettes Interface was einem dies leicht zugänglich macht: Das SUN Java Archive
Kommentare (0) 
