The best way of doing this avoiding endless recursion is to use apaches RedirectMatch rule, like this:


RedirectMatch ^/$ http://targethost/mywebapp


Easy, agreed. But i’ve seen (and done it wrong my self) quite often…

    <filter>
        <filter-name>springContextFilter</filter-name>
        <filter-class>org.springframework.web.filter.RequestContextFilter</filter-class>
    </filter>

    <filter-mapping>
        <filter-name>springContextFilter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>

Mehr dazu gibt’s natürlich in der spring-doku!


INFO: The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: ...


Zumindest dann, wenn die APR-Komponente in der server.xml konfiguriert ist:

<Server port="..." shutdown="SHUTDOWN">
   ...
  <Listener className="org.apache.catalina.core.AprLifecycleListener" />
  ...

Dies liegt daran, dass diese Komponenten eine Abhängigkeit auf native Bibliotheken hat, welche auf dem System installiert sein müssen und deren Pfad in die java.library.path-Variable eingetragen sein sollte.

Das ist kein kritischer Fehler, aber es ist wahr, dass die APR auf Produktivsystemen einen spürbaren Vorteil bietet.

Im Javablog gibt es dazu zwei exzellente Beiträge:

Dieser Beitrag schildert die Installation der APR.

In dieser Beitrag wird der gemessene Performance-Gewinn durch APR gezeigt.

Beides sehr lesenswert!

Zugriff von einem Context auf einen anderen über die Servlet-API

Will man von einem anderen Context auf einen anderen zugreifen, lässt sich der gewünschte Context recht einfach aus dem ServletContext erhalten:

 ...
 ServletContext otherContext = servletContext.getContext("/othercontext");
 // The context may be null if the application server does not permit cross-context access.
 if (otherContext != null) {
     ...
 }
 ...

Wobei man sich den aktuellen Context beispielsweise über einen Listener oder Filter besorgen kann.

Zugriff ermöglichen: Context-Konfiguration in tomcat

Im tomcat application server liefert der Aufruf dieser Methode jedoch stets null zurück – Die Sicherheitseinstellungen von tomcat lassen den Zugriff auf andere Webapps per default nicht zu.

Der Zugriff funktioniert erst, wenn im Context, aus welchem man auf die anderen Contexts zugreifen möchte, das Attribut crossContext auf true gesetzt ist.

   <Context path="[Pfad]" crossContext="true" ... />

(siehe dazu die Context-Doku von tomcat 6).

Allerdings funktioniert diese Konfiguration erst ab tomcat 6 ohne Schwierigkeiten. in Tomcat 5 gibt es eine Reihe von Bugs, insbesondere dann, wenn die crosscontext-webapp die ROOT-webapp ist. Damit crossContext im 5′er-Tomcat läuft, darf das path-Attribut nicht auf “/” gesetzt sein (Dies ist ohnehin ein ärgerlicher Verstoss gegen die servlet-Spezifikation), sonder muss “” lauten. Ansonsten greift crossContext=”true” nicht.

Demenstprechend sähe eine context-Konfiguration für die ROOT-webapp so aus:

   <Context path="" crossContext="true" ... />

Wer jedoch WAR-Deployment
im 5′er Tomcat verwendet wird nun feststellen müssen, dass tomcat die WAR-Dateien nicht mehr entpackt und die Applikation nicht mehr ausliefert – ohne eine Fehlermeldung.

Dieses Verhalten lässt sich erst dadurch beheben, dass man als appBase-Attribut den Dateinamen des .war-Archives angibt, welches unter $CATALINA_BASE/webapps deployt ist, bspw. ROOT.war:

   <Context path="" crossContext="true" appBase="ROOT.war" />

Jetzt wird auch die .war-Datei wieder entpackt.
Dummerweise ist es nun möglich, dass Tomcat die welcome-files (index.jsp) nicht mehr beim Aufruf von “/” ausliefert, was weitere workarounds nach sich zieht.

Fazit

Wer crossContext-Zugriffe benötigt, ist gut beraten, den aktuellen tomcat 6 zu verwenden bzw. auf diesen umzusteigen – erst die 6′er Reihe verhält sich diesbezüglich spezifikationsgemäss.

Hin und wieder ist man in der Universität mit der vergnüglichen Tatsache konfrontiert, dass es weder eine brauchbare vorhandene Anzahl an Entwicklungswerkzeugen gibt, noch dass sich irgend jemand – ausserhalb von Lehrveranstaltungen – um Prozesse in der Softwareentwicklung kümmert.

Sprich: Ein Projekt soll umgesetzt werden, und außer einem SVN-Account gibt’s nichts.

Bei einem Team von 8 Leuten ist das völlig unzureichend. Neben einem ordentlichen Issue tracking bin ich auch daran gewöhnt, mittels eines Continous Integration-Systems aktuelle Buildstände abzurufen und den Stand der Dinge im Auge behalten zu können. Von einem ordentlichen WIKI zur Projektdoku ganz zu schweigen.

Da der Code an sich mittels Maven2 verwaltet wird, hatte ich sofort continuum ins Auge gefasst – schließlich ist continuum selbst Java-basiert und speziell für maven – Projekte entwickelt.

1.1: Voraussetzungen

Da Continuum eine J2EE-Webapplikation ist, muss zunächst einmal ein entsprechender Servletcontainer her.
Im recht schwachbrüstigen WIKI werden Resin, JBOSS, tomcat und glassfish als Referenzen angeführt.
Da ich mich gut mit Tomcat auskenne entschloss ich mich, continuum mit diesem zu installieren. als JDK entschied ich mich für Sun’s JDK 1.6.3, Datenbank sollte nicht die integrierte Derby, sondern ein vorhandenes MYSQL werden.

1.2: Die richtige Distribution herunterladen

Auf der continuum-Downloadseite stehen unterschiedliche Arten des 1.1-Releases zur Verfügung:
Die etwas schräge standalone-Distribution (Warum sollte man so etwas benutzen, wo es ein schönes, Standardkonformes WAR-Deployment gibt?), und die webapp-Distribution.
Ich empfehle in jedem Fall letztere zu verwenden, da somit kein Herumgefrickel in irgendwelchen Scripten notwendig wird.

1.3: continuum deployen und konfigurieren

1.3.1: Tomcat installieren

Der gute Tomcat lässt sich sehr einfach installieren. Ist das JDK vorhanden muss lediglich die Umgebungsvariable JAVA_HOME gesetzt sein.
Dann reicht es, wenn man keine weiteren Anpassungen braucht, die tomcat 6 core-distribution herunterzuladen und zu entpacken. Unix-typisch sind unter bin/ die ausführbaren Dateien, sprich start-Scripts (auch das weiter unten erwähnte catalina.sh – Script).
Unter conf/ findet man die server.xml, in welcher man die unten angeführten Anpassungen für die mysql-Anbindung durchführen kann.

1.3.2: continuum-Parameter in Umgebungsvariablen

Aus einem mir unklaren Grund brauch die continuum-webapp zwei JVM-Parameter um sich “zu orientieren”:
appserver.home und appserver.base sollten entsprechend auf das CATALINA_HOME und CATALINA_BASE Verzeichnis zeigen.
Bei einer sauberen default- Installation sind diese Verzeichnisse identisch. Ich habe das durch einen Eintrag am Anfang der catalina.sh erledigt:

export CATALINA_OPTS="-Dappserver.home=$CATALINA_HOME -Dappserver.base=$CATALINA_HOME"

1.3.3: MYSQL anbinden

Out-Of-The-Box verwendet Continuum Derby als Datenbank. Da ich MYSQL verwenden wollte war es notwendig, eigene DataSource-Konfigurationen vorzunehmen.
DataSources können Global oder Kontext-spezifisch in Tomcat Konfiguriert werden. Ich entschied mich, sie im <Context> Element der server.xml zu konfigurieren:

<Context path="/continuum" docBase="continuum">
<Resource name="jdbc/users"
            auth="Container"
            type="javax.sql.DataSource"
            username="..."
            password="..."
            driverClassName="com.mysql.jdbc.Driver"
            url="jdbc:mysql://localhost/...?autoReconnect=true" />

  <Resource name="jdbc/continuum"
            auth="Container"
            type="javax.sql.DataSource"
            username="..."
            password="..."
            driverClassName="com.mysql.jdbc.Driver"
            url="jdbc:mysql://localhost/...?autoReconnect=true" />

  <Resource name="mail/Session"
            auth="Container"
            type="javax.mail.Session"
            mail.smtp.host="localhost"/>
</Context>

Dazu muss der passende mysql-connector natürlich im lib-Verzeichnis des Tomcats platziert werden. (Bei 5′er Tomcats unter common/lib, ab 6 einfach “lib”).
Wichtig ist, dass der Datenbanknutzer Tabellen etc. anlegen darf. Zudem ist bei der Anbindung von continuum an MYSQL oft folgende Fehlermeldung zu sehen:


Error thrown executing CREATE TABLE '.....'
...
com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Specified key was too long; max key length is 765 bytes


Das Problem existiert, da Continuum PRIMARY KEY-Constraints über mehrere varchar-Felder (als composite primary key) verwendet und tritt auf, wenn für
das Encoding der für continuum verwendeten Datenbank ein Encoding gewählt wurde, wass mehr als ein Byte pro Character verwendet – Beispielsweise “utf8_general_ci”.
Ich habe aus diesem Grund ein latin1-Encoding verwendet – Danach lief alles glatt.

1.3.4: Richtiges ablegen der .war-Datei

Extrem wichtig ist, dass Verzeichnis der continuum webapp unter “webapps” genau so zu nennen wie den Contextnamen:

<Context path="/continuum" docBase="continuum">

Da es ansonsten zu unangenehmen Fehlern bei der Auflösung der konfigurierten Datasource kommt.
Das continuum….war-File sollte also unter “webapps” am besten als “continuum.war” gespeichert werden.

1.3.5: Start!

Mit diesen Einstellungen sollte die Continuum webapp starten. Der Startvorgang wird recht ausführlich im logs-verzeichnis von catalina protokolliert.

1.4: Konfiguration verbessern

Die Out-Of-The-Box Konfiguration hat noch ein paar Defizite, welche in der application.xml der ausgepackten .war-Datei verbessert werden können.
Diese findet sich unter …/webapps/continuum/WEb-INF/classes/META-INF/plexus.

Unter

    <!--
    | The mail notifier
    |-->
    <component>
      <role>org.codehaus.plexus.notification.notifier.Notifier</role>
      <role-hint>mail</role-hint>
      <implementation>org.apache.maven.continuum.notification.mail.MailContinuumNotifier</implementation>
    ...

Sollte beispielsweise die sender-mailbox konfiguriert werden, da continuum sonst als continuum@localhost Nachrichten per SMTP versendet:

    <configuration>
        <from-mailbox>continuum@myhost.domain</from-mailbox>
        <from-name>Continuum Server</from-name>

1.5: Problem mit Jsch beheben

In der mit Continuum ausgelieferten Version enthält die java secure channel-Blibliothek Noch einen Nullpointer-Fehler, der sich
allerdings erst dann zeigt, wenn tatsächlich ein build in continuum durchgeführt wird. Dann erscheint folgendes im build-log:


...
java.lang.NullPointerException
at com.jcraft.jsch.ChannelSession.run(Unknown Source)
...


Zum Beheben einfach das jsch….jar File aus dem WEB-INF/lib Verzeichnes der continuum webapp mit einer aktuelleren Version, in meinem Fall jsch-0.1.36.jar, ersetzen.

Weiter geht es in Maven2-Projekt in Continuum konfigurieren.