Java

Um Jira4 mit SSL im Tomcat und selbstsigniertem Zertifikat ans Laufen zu bringen war ein bisschen knobeln angesagt.

SSl selbst geht ja erstmal einfach: http://wiki.blackslash.de/software/ssl

Allerdings meldet das Jira dann den Fehler "Error loading gadget: org.apache.shindig.gadgets.GadgetException: Unable to retrieve gadget xml. HTTP error 500". Das Problem dabei ist, dass Jira dem selbst signierten Zertifikat ersteinmal vertrauen muss, bevor Inhalte inkludiert werden.


usermod -d /var/lib/tomcat-6 -s /bin/bash tomcat
su - tomcat
keytool -export -alias tomcat -file /tmp/cert.crt
exit
usermod -s /sbin/nologin tomcat
keytool -import -file /tmp/cert.crt -alias jiratomcat -keystore /etc/java-config-2/current-system-vm/jre/lib/security/cacerts



keytool -import -file /tmp/cert.crt -alias jiratomcat -keystore /etc/java-config-2/current-system-vm/jre/lib/security/cacerts
Enter keystore password:
Owner: CN=jira.fem.tu-ilmenau.de, OU=Technik Team, O=Forschungsgemeinschaft elektronische Medien e.V. (FeM e.V.), L=Ilmenau, ST=Thueringen, C=DE
Issuer: CN=jira.fem.tu-ilmenau.de, OU=Technik Team, O=Forschungsgemeinschaft elektronische Medien e.V. (FeM e.V.), L=Ilmenau, ST=Thueringen, C=DE
Serial number: 4baacb63
Valid from: Thu Mar 25 03:33:07 CET 2010 until: Sat Mar 24 03:33:07 CET 2012
Certificate fingerprints:
MD5: CF:3B:BB:54:29:7E:41:D7:D8:95:33:66:12:87:AF:1B
SHA1: 0F:22:52:9F:1C:DB:83:31:26:DD:C2:8C:4C:E3:37:12:43:B8:8C:FC
Signature algorithm name: SHA1withRSA
Version: 3
Trust this certificate? [no]: yes
Certificate was added to keystore


Seit fast drei Jahren arbeite ich nun mit Maven. Vor kurzen habe ich jedoch erst die Software Sonatype Nexus entdeckt - ein Proxy und Artifaktmanager für Maven-Artefakte.

Wolf-u.li bescheibt die Installation von Nexus unter Gentoo.

Da mir die beschriebene manuelle Installation zu langwierig ist, habe ich dazu mal ein EBuild [1] gebaut. Dieser ist im Gentoo-FeM-Overlay zu finden, welchen man idealerweise mit Layman benutzt. Die Einrichtung des FeM-Overlays ist in diesem Beitrag erklärt.

Anschließend kann man Nexus mit folgendem Kommando installieren:

emerge nexus -avt


[1] http://subversion.fem.tu-ilmenau.de/repository/fem-overlay/trunk/dev-java/nexus/

Das Verhalten von Cocoon läßt sich sowohl in Spring und Avalon-Konfigurationsdateien, als auch über Properties steuern.
In welcher Reihenfolge nach Property-Dateien gesucht wird, ist hier beschrieben.

In Cocoon 2.2 einen Dateiupload zu realisieren ist relativ trivial. Jedoch sind die dazu nötigen Parameter recht spärlich dokumentiert, sodass ich schon eine Weile suchen musste, bis der Upload funktionierte.

So muss man in einer beliebig benannten properties-Datei im Verzeichnis META-INF/cocoon/properties folgende Eigenschaften setzen:

org.apache.cocoon.uploads.enable=true
org.apache.cocoon.uploads.maxsize=10000000


Anbei ein Minimalbeispiel: cocoon-uploaddemo.zip

Wenn man sich mit Hibernate [1] eine Datenstruktur erzeugen lässt, dann haben die Foreignkeys standardmäßig kryptische Namen. Das liegt daran, dass normalerweise einfach ein Hash über den Tabellen- und Spaltennamen gebildet wird. Möchte man andere Namen verwenden, etwa um eine mögliche Fehlermeldung besser deuten zu können, so kann man diese mit einer Annotation [2] festlegen.


@ForeignKey(name="FK_PARENT")


[1] http://www.hibernate.org
[2] http://www.hibernate.org/hib_docs/annotations/reference/en/html/entity.html#entity-hibspec-singleassoc

Für Java gibt es ein interessantes Projekt namens urlrewrite [1], welches das bekannte mod_rewrite für den Apache Webserver nachzubilden versucht.
Mit diesem Filter, ist es möglich, eine Java-Webanwendungen nachzurüsten und beliebige URLs umzuschreiben.

Ein Beispiel habe ich hier hinterlegt.

[1] http://code.google.com/p/urlrewritefilter/

Möchte man mit einem Java Webservice auf einen anderen Webservice über eine HTTPS-Verbindung zugreifen (z.B. von einem Jira zu einem Fisheye), dann muss man zunächst das Serverzertifikat im Truststore vom Client installieren.

Solange das Zertifikat nicht installiert ist, meldet der Client:

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target when trying to open an SSL connection to a host using JSSE


Zur Installation des Zertifikats hat Andreas Sterbenz [1] ein nettes kleines Tool namens "InstallCert" [2] geschrieben, was den Vorgang etwas vereinfacht. Zunächst muss man das Tool herunterladen und kompilieren:

wget http://blogs.sun.com/andreas/resource/InstallCert.java
javac InstallCert.java


Danach wird das Tool ausgeführt und das Zertifikat wird in einen lokalen Truststore installiert:

java InstallCert subversion.meinserver.de


Eine Datei namens "jssecacerts" wird erstellt. Anschließend muss man sein Javaprogramm nur mit einem weiteren Systemproperty mit dem Pfad zum Truststore aufrufen und der Zugriff über HTTPS kann nun erfolgen:

-Djavax.net.ssl.trustStore=/etc/java-config-2/jssecacerts


Verbindung erfolgreich.

[1] http://blogs.sun.com/andreas/entry/no_more_unable_to_find
[2] http://blogs.sun.com/andreas/resource/InstallCert.java

Möchte man die Dependency Injection von Spring nutzen, muss man mittweilen die zu injizierenden Resourcen mit der Annotation javax.annotation.Resource markieren.

Nach dem Umstieg von Eclipse 3.3 (Europa) auf Eclipse 3.4 (Ganymede) begrüßten mich in meinen Projekten viele der folgenden Fehlermeldungen: "Access restriction: The type Resource is not accessible due to restriction on required library <jre_path>/lib/rt.jar". Das Projekt ließ sich nicht kompilieren.

Nach einigen Recherchen fand ich heraus, dass derartige Fehlermeldungen vom Eclipse JDT erzeugt werden, falls man Nicht-API Klassen [1] wie sun.* verwendet. Dummerweise wird diese Fehlermeldung in diesem Fall fälschlicherweise auch erzeugt.

Um Weiterarbeiten zu können kann man die Fehlererzeugung für diesen Fehler abschalten:
Window -> Preferences -> Java -> Compiler -> Errors/Warnings -> Deprecated and restricted API -> Forbidden reference (access rules) -> Warning

[1] http://java.sun.com/products/jdk/faq/faq-sun-packages.html

Um EJB3 und Spring Komponenten gemeinsam zu verwenden, und ggf. gegenseitig auf sich zugreifen zu lassen, müssen diese auf einem Server gemeinsam installiert (deploy-t) werden. Da es keinen Sinn macht, für jede Spring Anwendung die kompletten Bibliotheken zu hinterlegen (und damit mehrfach auf dem Server), haben Ales Justin [1] und mittlerweile 78 weitere Entwickler einen JBoss-Spring-Deployer [2] gebaut.

Um diesen zu verwenden, muss man sich zunächst den JBoss Application Server installieren. Dazu läd man von [3] den aktuellen JBoss 5.0.0.CR2 herunter und entpackt diesen.

Den JBoss-Spring-Deployer kann man in der aktuellen Version 3.1 von [2] (jboss-spring-3.1.deployer) beziehen. Die Datei muss lediglich im Verzeichnis jboss-5.0.0.CR2/server/default/deployers hinterlegt werden.

So weit so gut: Prinzipiell könnte man jetzt die erste Spring-Anwendung deploy-en.

Spring-Archive können als normale JAR-Datei gepackt werden. Der JBoss-Spring-Deployer sucht nach Spring-Konfigurationsdateien nach dem Muster *-spring.xml. Es empfiehlt sich eine solche Datei im Verzeichnis META-INF der Anwendung zu hinterlegen. Findet der Deployer eine solche Datei, werden die darin definierten Beans in einem Spring-Kontext geladen.

ABER (was mich mal wieder einen Nachmittag gekostet hat): Beim JBoss 5 CR2 hat sich eine Schnittstelle [4] geändert, sodaß man noch eine Anpassung machen muss, bevor der Deployer [5] funktioniert. Man muss zunächst mit einem Packprogramm die Datei jboss-spring-3.1.deployer entpacken und die Datei META-INF/spring-deployers-beans.xml zu META-INF/spring-deployers-jboss-beans.xml umbenennen. Fertig.

Bleibt nur noch zu klären, ob es Wechselwirkungen mit dem Cocoon-Spring-Configurator [6] gibt...

[1] http://java.sys-con.com/node/180386
[2] http://sourceforge.net/project/showfiles.php?group_id=22866&package_id=161914
[3] http://www.jboss.org/jbossas/downloads/
[4] https://jira.jboss.org/jira/browse/JBAS-5803
[5] http://www.jboss.com/index.html?module=bb&op=viewtopic&t=143666
[6] http://cocoon.apache.org/subprojects/configuration/1.0/spring-configurator/2.0/1304_1_1.html

Wenn man Bamboo z.B. auf einem JBOSS benutzen möchte, muss man die bamboo.war nach kleinen Änderungen neu verpacken, damit diese lauffähig ist. So müssen z.B. die WEB-INF/lib/activation.jar und die WEB-INF/lib/mail-1.3.2.jar entfernt werden, damit es nicht zu Classloader-Problemen kommt. Nachdem der Inhalt des Archives in einem Verzeichnis extrahiert wurde, kann mit folgenden Befehl wieder ein WAR-Archiv erstellt werden:


jar -cf atlassian-bamboo-2.1-mod.war -C atlassian-bamboo-2.1 .


Hier die Eclipse-Update-URLs:

Maven4Eclipse: http://m2eclipse.codehaus.org/update/ bzw. http://m2eclipse.sonatype.org/update-dev/

Subclipse: http://subclipse.tigris.org/update_1.2.x

Eclipse Checkstyle: http://eclipse-cs.sourceforge.net/update

Wenn man mit Maven eine JAR-Datei baut, werden die abhängigen Bibliotheken, im Gegensatz zu WAR-Archiven, normalerweise nicht mit in das erstellte Artefakt inkludiert. Dies ist meistens auch sinnvoll, da die notwendigen Resourcen nicht mehrfach abgelegt werden sollen und bei Bedarf leicher austauschbar sind. Möchte man jedoch eine lauffähige Anwendung verbreiten, ist es zwingend notwendig, dass alle Abhängigkeiten vorhanden sind.

Als Lösung dafür sieht Maven das maven-assembly-plugin vor, welches alle Dateien (wie z.B. die Klassen-Dateien, Skripte, Property-Dateien, Bibliotheken, etc), die für einen Release notwendig sind, in einem Archiv (z.B. jar, zip, tar, gzip tar, als Verzeichnis, etc.) zusammenstellt.

Das Assembly-Plugin kann auch verwendet werden, um eine ausführbare JAR-Datei zu erstellen.

So wäre es schön, eine ausführbare JAR-Datei zu erstellen, die den eigenen Programmcode und alle Abhängigkeiten enthält.
Leider kann Java die benötigten Bibliotheken nicht aus der selben JAR-Datei laden, die auch die Main-Klasse enthält, sodass man entweder

1. einen eigenen (angepassten) Class-Loader verwenden muss,


2. oder alle Klassen auspacken und anschließend in eine einizige JAR-Datei verpackt (Scheidet aus, wenn man vorhandene signierte JAR-Dateien verwenden muss.)


3. oder die JAR-Dateien in eine weitere JAR-Datei verpacken muss.

"Maven: JAR mit Abhängigkeiten bauen" vollständig lesen

Um ein JAR-Archiv lauffähig zu machen, muss die Konfiguration des maven-jar-plugins in der pom.xml angepasst werden, aufdass die Hauptklasse im MANIFEST.MF aufgeführt wird:


<project>
...
  <build>
    <plugins>
      <plugin>
        <artifactId>maven-jar-plugin</artifactId>
        <configuration>
          <archive>
            <manifest>
              <mainClass>com.example.App</mainClass>
            </manifest>
          </archive>
        </configuration>
      </plugin>
    </plugins>
  </build>
  <dependencies>
...
<project>


Nach einem

$ mvn clean package

kann man das Archiv mit

$ java -jar ./target/Artifakt-1.0-SNAPSHOT.jar

nun direkt ausführen (Artifakt-1.0-SNAPSHOT.jar durch den Namen der erzeugten Datei ersetzen).

Schreibt man ein Programm, dass mehrere Frameworks benutzt, kann es vorkommen, dass diese Bibliotheken verschiedener Versionen benutzen, die nicht zueinander kompatibel sind. Eine typische Fehlermeldung, die auf diesen Fakt hinweist, ist z.B. ein java.lang.NoSuchMethodError. Diese begegnet mir z.b. ständig, wenn verschiedene Versionen von commons-collections benutzt werden.

Mit dem Befehl

mvn dependency:tree -Dverbose -Dincludes=commons-collections

listete Maven einen Baum von Abhängigkeiten zu z.B. commons-collections auf.
"Maven: Abhängigkeitskonflikte finden" vollständig lesen

(Notiz an mich)

Unter Gentoo geht das Installieren eines Java SDKs bekanntlich einfach:
emerge sun-sdk -avt

Was ich jedoch immer wieder vergesse:
Nach einem Update des SDKs kann es unter Umständen passieren, dass man das verwendete SDK noch umschalten muss:
java-config --set-system-vm sun-jdk-1.6

Die aktuelle Konfiguration kann man mit
java-config --show-active-vm
und
java-config --list-available-vms
überprüfen.

Quelle:
http://www.gentoo.org/doc/de/java.xml