Archiv der Kategorie: Maven

Cargo remote deployment Tomcat7: Error writing request body to server

I tried to deploy a WAR into a TomEE/Tomcat7 application server and I received an exception: „Error writing request body to server„. No Tomcat log file has useful information about that.

I use maven with Cargo plugin to deploy via the manager application of the Tomcat.

The configuration of the plugin inside the pom.xml is:

<plugin><!-- http://stackoverflow.com/questions/6436351/cannot-redeploy-to-remote-tomcat-7-with-using-cargo-maven-plugin, http://cargo.codehaus.org/Deploying+to+a+running+container -->
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>1.4.2</version>
<configuration>
<path>${remote.deployment.path}/${project.artifactId}/DEPLOY    /${project.artifactId}-DEPLOY.war</path>
<skip>${xxxx.deployment.skip}</skip>
<container>
<containerId>tomcat7x</containerId>
<type>remote</type>
</container>
<configuration>
<type>runtime</type>
<properties>
<cargo.remote.username>${xxxx.user}</cargo.remote.username>
<cargo.remote.password>${xxxx.pwd}</cargo.remote.password>
<cargo.remote.uri>http://${xxxx.host}:8080/manager/text</cargo.remote.uri>
</properties>
</configuration>
</configuration>
</plugin>

The command line is: mvn -X cargo:deployer-redeploy -P testsystem

In the internet I found two hints to solve the problem. First I checked the amount of bytes to send to the management application. There were some restrictions in the webapps/manager/WEB-INF/web.xml file at multipart-config>max-***-size.

Unfortunately this wasn’t my problem. The second hint were the proxy settings. I disabled my Ubuntu network proxy. But I forgot the ~/.m2/settings.xml of maven itself. After I fixed the maven proxy setting no exception occured and the deployment was successful.

 

JBoss AS7, Jenkins und Continious-Integration light – jboss-as-maven-plugin

Nach Überführen des Bestands-Codes eines älteren Projektes auf GIT und Jenkins als CI-System hatte sich seit einem JUGH-Vortrag die Idee des Continious-Integration festgesetzt.

Es wäre doch schön, wenn man Code eincheckt und das Ergebnis zentral für Tester in kurzer Zeit zur Verfügung steht (bzw. für den Entwickler selbst in einer kundensystem-nahen Umgebung und gerade nicht auf dem full-blown Entwicklungsrechner).

Nach dem Experimentieren mit diversen Ant, Copy und Deploy-Mechanismen (SSH-Wagon-PlugIn) mit Maven stellte sich alles als zu fummelig heraus. Warum also nicht einmal eine nicht so allgemeine Lösung verwenden, das jboss-as-maven-plugin.

Dies stellte sich als Glücksgriff heraus. Zentral lässt sich der SSL-Zugriff zu einem laufenden AS7-Server konfigurieren und dann wird das entsprechende WAR (oder EAR) direkt (ohne File-Copy in einen Ordner) in den AS7-Server eingespielt.

Da ich ein modulares Maven-Projekt verwende mit 4 Web-Applikationen, wurde folgendes in die Parent-POM eingetragen:

<plugin>
<!– Deployment configuration –>
<groupId>org.jboss.as.plugins</groupId>
<artifactId>jboss-as-maven-plugin</artifactId>
<version>7.4.Final</version>
<configuration>
<hostname>testsystem.curses.priv</hostname>
<port>9999</port>
<username>admin</username>
<password>asfi834f</password>
<skip>${jboss-as.deployment.skip}</skip>
</configuration>
</plugin>

Das Angenehme ist, dass man über skip steuern kann, ob ein Artefakt eingespielt werden soll oder nicht. So wird die entsprechende Variable jboss-as.deployment.skip z. B. für die Parent-POM selbst auf false gesetzt, um Fehlermeldungen und eine eventuell notwendige force-Einstellung zu vermeiden.

Über die Admin-Oberfläche (Port 9990) lassen sich bequem die entsprechend eingespielten Artefakte prüfen.

 

Flex-SDK mavenisieren – possible impossible

Für ein Projekt war u.a. der Flex-Compiler (SDK) als Maven-Abhängigkeit aufzulösen.
Eine sehr schöne Anleitung, was zu tun ist, mit Scripts und kurzen Hinweisen ist hier zu finden:
http://www.flexthinker.com.

Besonders * finde ich solche Kommentare bei Flexmojos:

The descriptors used by Flexmojos to publish Flex SDK aren’t public available and won’t be provided. The goal is to really make this process hard. If possible impossible to reproduce. People tend to abuse on this, leading to ghost bugs and all kind of inconsistencies. This is a very sensitive process, so be aware that even Flex SDK published on Flexmojos repository can be broken.

Wo findet man hingegen den Download für das Flex-SDK, wenn man nicht die aktuelle Version 4.6 haben möchte?
Nicht in einer historisierende Übersicht sondern in den Kommentaren des Souceforge-Wikis wird man fündig.

Maven-PlugIn und transitive Workspace-Abhängigkeiten

Die Fehler-Situation war eine Exception im XStream/CGLIB. Sowohl der POM-Editor, die Eclipse „Maven-Dependencies“ und auch sonst zeigten XStream 1.3 an, wie man es erwarten konnte.
Im POM für Projekt A ist XStream 1.3 als Abhängigkeit eingetragen. A hängt noch von B ab, in welchem XStream 1.2.2 eingetragen ist. Der Dependency-Eintrag im POM von A enthält einen entsprechenden Exclude auf XStream aus B. Soweit so gut.

Wenn man nun aber in Eclipse und dem „Maven Integration for Eclipse“-PlugIn die „Workspace Resolution“ eingeschaltet hat, dann kann es passieren, das über diesen Bypass ein zweites XStream in den Classpath wandert. Das kostet dann Zeit, weil es auf dem einen Eclipse-Helios-Workspace geht und auf dem anderen nicht. Das macht sich beim Kunden besonders schlecht, wenn man für das Deployment einen solchen Workspace benutzt (wie bei mir geschehen) und Stunden benötigt, auf das Problem zu kommen.

Ich tendiere immer mehr dazu, dass man mit Maven einen festen überprüfbaren Abhängigkeitsbaum initial erzeugt und diesen dann fest in das Projekt einbindet. Sollten neue Abhängigkeiten nötig werden, so geht man wieder diesen Weg: get dependencies, test it and freeze.

Properties und Encoding

Manchmal sollte man die Warnings lesen, die diverse Tools auswerfen.

Es ist ein guter Hinweis von Maven2, dass man ggf. folgendes einfügen sollte:


<properties>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>

Ansonsten kann es sein, dass die Quellcode-Dateien stillschweigend umgesetzt werden.
In diesem Zusammenhang sind wir auf einen Mechanismus gestoßen, der komischerweise bis jetzt immer so weit funktioniert hat.

Die Properties-Dateien besitzen gesonderte Einstellungen im Eclipse und sie sind voreingestellt auf ISO-8859-1.
Der Grund ist das Default-Einlese-Verhalten von Ressource-Bundles.
Alle Zeichen, die nicht ISO-8859-1 entsprechen, müssen als Unicode-Escape-Sequencen geschrieben werden.
Wenn man nun UTF-8 kodierte Properties-Dateien benutzt, dann können die Zeichen beim Default-Einlesen zerstört werden.

Siehe hierzu z. B.: globalizer.wordpress.com

Aber unter Java 1.6 gibt es eine neue Möglichkeit, dieses Default-Einlesen mit einem eigenen Reader zu umgehen.
Nur leider wird beim Verwenden von verschiedensten Frameworks diese neue Möglichkeit sicher nicht konsistent umgesetzt.


Update: With Java 6 you can use PropertyResourceBundle constructed with a Reader, which can use UTF-8 directly.

Es kann passieren, dass beim Ressouce-Kopieren durch Maven die Dateien umkodiert werden und man lustige Ausgaben erhält, je nach Zielplattform und deren Encoding.

Eclipse-Maven-WTP-Deployment

Es ist von großem Vorteil, wenn klar wird, dass die m2eclipse-Entwickler die WTP-Integration nicht als ihre Hauptaufgabe betrachten. Deswegen ist die Unterstützung des WTP-Deploy-Prozesses bei der Maven-Integration im Eclipse auch oft brüchig.

Aber es gibt eine Abhilfe, welche sich in optionalen Paketen unter einer eigenen Update-URL verbirgt:

http://m2eclipse.sonatype.org/sites/m2e-extras

Wenn man die dortige WTP-Unterstützung ausgewählt und installiert hat, dann entfallen meistens die manuellen Anpassungen der org.eclipse.wst.common.component, um die richtigen Artefakte, respektive Workspace-Abhängigkeiten einzutragen.

Ernsthaftes Problem: Maven2 und transitive Repositories

Plötzlich erhält man vom seinem Bamboo-Build mittels Maven2 folgende Meldung:
Unable to get dependency information: Unable to read local copy of metadata

Beim Blick in die Datei stellt sich heraus, dass es sich bei den maven-metadata-jaspersoft.xml um eine HTML-Datei handelt.
Diese beinhaltet den Hinweis, dass eine bestimmte URL nicht gefunden wird. Wir dachten, dass wir mit Nexus und unseren POMs auf der sicheren Seite wären, aber weit gefehlt. Dies kann übrigens auch passieren, wenn man zu Hause mit seinem neuen DSL spielt und der Provider einem statt 404 eine HTML-Seite durchreicht. So landen dann auch schon einmal HTML-Seiten als JAR-Dateien im Maven2-Repository.

Im Moment existiert noch keine befriedigende Lösung, soweit ich das gesehen habe.

Selbst wenn man sein Nexus-Repository-Proxy abgeschottet hat, muss man natürlich darauf achten, dass die POMs abgeschottet sind.

  • alle repository-Einträge zeigen nur auf gekapselte Nexus-Repositories
  • „central“ ist gesperrt


<repository>
<id>central</id>
<name>Maven Repository Switchboard</name>
<layout>default</layout>
<url>http://repo1.maven.org/maven2</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
<releases>
<enabled>false</enabled>
</releases>
</repository>

Das Gleiche gilt natürlich auch für die Plug-In-Repositories.

Aber dies nützt einem alles nichts bei dem Problem der transitiven-Repositories.


[INFO] artifact commons-collections:commons-collections: checking for updates from jaspersoft
[DEBUG] Checking for pre-existing User-Agent configuration.
[DEBUG] Adding User-Agent configuration.
[DEBUG] Connecting to repository: 'jaspersoft' with url: 'http://www.jasperforge.org/maven2'.

Besonders unangenehm ist uns das bei jaspersoft (http://www.jasperforge.org/maven2) aufgefallen.
(Siehe: jasperforge.org espforum, http://stackoverflow.com)

Currently, there's no way to exclude more than one transitive dependency at a time, but there is a feature request for this on the Maven JIRA site:

http://jira.codehaus.org/browse/MNG-2315

Da mogelt sich doch tatsächlich ein weiteres Repository in die Abarbeitungskette. Und das ist eine fatale Sicherheitslücke. Es bleibt einem nichts anderes übrig, als auf mögliche Transitivitäten zu achten mit dem Scannen seines JAR-Dependency-Baumes z. B. unter WEB-INF/lib.

Auf alle Fälle zeigt dieser Vorfall, dass eine solch komplexe und transitive Struktur, wie die Maven-Abhhängigkeiten, gepflegt und überwacht sein will. Wäre uns dieser Crash beim Deployment zum Kunden passiert …