Archiv der Kategorie: Pitfall

Unique-Constraint greift nur bei Nicht-null Einträgen

Bei einem Unique-Constraint über mehrere Spalten verhalten sich Null-Values nicht, wie man es erwartet. Bei zwei Spalten A und B in einem Unique-Constraint, kann nur eine Zeile mit Werten (‚a‘, ‚b‘) einfügen.

Hingegen funktioniert das Einfügen beliebig vieler Zeilen mit z. B. den Werten („a“, null). Da lohnt es sich, wieder mal in die Definitionen zu schauen.

SQL hat BOM gemacht: „Unexpected Token:“

Man hat mit Spring eine Testinfrastruktur schnell hochgezogen und immer mehr kommt hinzu. Schließlich schickt ein Kollege für einen speziellen Unit-Test eine SQL-Datei (PostgreSQL). SQL eingeladen und „Unexpected Token:“. Nichts weiter, kein Anhaltspunkt, leerer String. Ok, ich verwende HSQL-DB aber einfach SQL-Updates sollten nun wirklich nicht so verschieden sein.

Da erinnerte ich mich, eines ganz bestimmten Falles und sah mir die Datei im ‚vi‘ an. Keine Auffälligkeiten. Anschließend benutzete ich den Befehl ‚file‘. Und siehe da: Der Kollege benutzte ein Apfel-Betriebssystem und schickte mir das SQL mit einem heimtückischen BOM. Das brachte es mit sich, dass die ersten unsichtbaren 3 Bytes mit zur Datenbank gelangten, somit gleich der Anfang der ein defektes Token darstellt und folgerichtig das unexpected Token leer angezeigt wurde. Nun diesen unerwünschten Prefix des Datenstromes gelöscht und alles funktioniert, wie es soll.

Übrigens könnte man sich doch manchmal an Befehle wie ‚iconv -f ISO-8859-1 -t utf-8 FILE‘ erinnern.

Firefox und (required=“false“) == (required=“true“)

Weil der Firefox (zumindest ab Version 28) den HTML-5-Mechanismus zur Validierung von Formfeldern benutzt, werden manche Masken aus älteren Anwendungen gestört.

Hat man ein input-Feld mit dem Attribut required=’false‘ (ganz davon abgesehen, wie regelkonform das wohl ist), dann wird dieses gegenteilig interpretiert. Beim Abschicken der umgebenden Form wird das Übertragen unterbunden und die Eingabefelder erhalten einen roten Rahmen und einen Hinweis-Text, dass sie auszufüllen sind.

firefox.redborder

Das ist verwirrend und besonders störend, wenn ein „Bitte warten“-Dialog angezeigt wird, der modal und nicht schließbar ist.

Im günstigsten Fall löscht man einfach das required-Attribut, welches vom Firefox binär interpretiert wird. D. h. das Attribut einfach da, dann bedeutet es required=’true‘.

„This allows forms to easily indicate which fields must have valid data before the form can be submitted. …“, vielen Dank.

Siehe auch: developer.mozilla.org, stackoverflow.com.

 

 

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.

 

TomEE: java.sql.SQLException: Unexpected token: NEXTVAL in statement [select nextval(‚SQ_TA_LOG_MASTER‘)]

Die Fehlermeldung – vom TomEE geworfen – „java.sql.SQLException: Unexpected token: NEXTVAL in statement [select nextval(‚SQ_TA_LOG_MASTER‘)]“ sagt nicht wirklich aus, was das Problem ist.
Es wird mit dem falschen SQL-Dialekt versucht, mit einer HSQL-DB zu sprechen, obwohl eine solche gar nicht im Projekt konfiguriert ist, zumindest nicht für den Kunden.

Nach dem wir endlich entdeckten, dass die tomee.xml Datei fehlte, wurde offensichtlich, dass die Applikation keine Datenbank vorfinden würde.
An dieser Stelle fühlt sich TomEE stillschweigend bemüßigt, seine Default-HSQL-DB zur Verfügung zu stellen.
Diese beschwert sich dann zu Recht, mit dem falschen Dialekt angesprochen zu werden.

Die Datasources richtig konfiguriert und alles klappt hervorragend.

JBoss AS7, Stripes und ‚for classes matching criteria: is assignable to ActionBeandue to an IOException:‘

Ein Web-Projekt wird als WAR-Datei in einen JBoss AS 7.1.1_FINAL eingespielt. Dieses WAR benutzt Stripes 1.51b (Bestands-Code). Bei „normalem“ Deployment über Eclipse in das JBoss Deployments-Verzeichnis ergibt sich kein Problem.

Als ich allerdings das Projekt über das Maven-JBoss-PlugIn als Continious-Integration (analog dem CLI-Mechanismus) einspielte, dann erhielt ich eine Fehler-Meldung. Diese besagt, das Stripes beim Initialisieren den Klassenpfad nicht finden kann und somit auch kein URL-Binding durchführen kann.

Nach experimentieren mit diversen Einstellungen von PlugIns usw., stellte ich Stripes 1.5.7 als neue Dependency ein. (Dies war relativ unkritisch für den Code.) Und siehe da, die Meldung trat nicht mehr auf und das URL-Binding funktioniert. Warum auch immer.

 

 

 

 

JBoss AS7, PostgreSQL als Modul

Wenn man im JBoss PostgreSQL in zentral definierten Datasources (z. B. standalone.xml) verwenden will, z. B. für JNDI-Lookup, muss der entsprechende Treiber auch zentral eingetütet werden.

Hierfür kann man den Treiber als Modul im JBoss einfügen. Die geschieht relativ einfach, indem man das Treiber-Jar in einen Ordner $JBOSS_HOME/modules/org/postgresql/main kopiert.

Dann legt man an gleichem Ort einen Modul-Deskriptor modules.xml an.


<?xml version="1.0" encoding="UTF-8"?>
<module xmlns="urn:jboss:module:1.1" name="org.postgresql">
<resources>
<resource-root path="postgresql-9.1-903.jdbc4.jar"/>
</resources>
<dependencies>
<module name="javax.api"/>
<module name="javax.transaction.api"/>
<module name="javax.servlet.api" optional="true"/>
</dependencies>
</module>

Dieses Modul kann man nun in der standalone.xml einfügen (Pfad des Modules muss übereinstimmen, wie auch der Name):


<driver name="postgresql" module="org.postgresql"><xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class></driver>

Dieses Modul kann nun in der Definition der Datasource (standalone.xml) verwendet werden:


<datasource jndi-name="java:jboss/datasources/MyDataSource" pool-name="MyDataSource" enabled="true" use-java-context="true">
<connection-url>jdbc:postgresql://localhost:5432/testdb?charSet=utf-8</connection-url>
<driver-class>org.postgresql.Driver</driver-class>
<driver>postgresql</driver>
<security>
<user-name>USER</user-name>
<password>PASSWORD</password>
</security>
</datasource>

Aber: Es scheint von Belang zu sein, dass man als Modul einen JDBC-4-Treiber-JAR verwendet. Jedenfalls funktioniert nun folgendes JAR postgresql-9.1-903.jdbc4.jar.

Ein klasse Quelle für Informationen ist die JBoss-Community, herzlichen Dank.

Ubuntu Backup mit deja-dup schlägt fehl

Eigentlich sieht es ziemlich gut aus. Einfache Konfiguration 4 Tabs, kurz angeklickt und „backup now“.

Nun wird man nach einem Passwort gefragt und weiter gehts. Dann fragt er wieder nach einem Passwort …
Nach etlichem Hin-und-Her versuche ich es ohne Passwort und Verschlüsselung. Siehe da, es geht.
Ein Kollege gab mir dann den Tip, dass das deja-dup (ein Python-Programm) gnupg benutzt.
Also kurz gnupg angeworfen und es ist kaputt.

Da hat doch wieder irgendein Aufruf als Besitzer des .gnupg-Ordners root gesetzt.
Will ich jetzt vom Arbeits-Account aus ein Backup machen, dann bricht deja-dup ohne Fehlermeldung ab (auch nicht auf Kommandozeile).

chown -R xxxx:yyyy .gnupg

Löst das Problem und das Backup läuft, wie es soll.
Eine Fehlermeldung hätte 2h gespart.