Archiv der Kategorie: J2EE

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, 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.

 

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.