Archiv für den Monat: Mai 2013

JBoss AS7 lokales und globales JNDI

Uncategorized

Wenn man ein Set von Web-Applikationen hat (Bestands-Code), die über die selbe Datenbank-Zugriffs-Klasse ihren Zugriffe kapseln, dann ist das schon mal nicht schlecht.

Wenn dann aber in dieser Klasse der JNDI-Name fest kodiert ist und man aber dummerweise die Datasources JNDI-zentral definiert hat (um sie zentral zu warten), ist das nicht gut. Da natürlich alles Web-Applikationen eigene Datenbanken besitzen sollen.

Eine gute Referenz und Übersicht über die JNDI-Regeln ist hier zu finden.

Also ist die Aufgabe, die globalen JNDI-Namen auf den einen lokalen JNDI-Namen jeweils zu mappen. Wenn man es erst einmal gefunden hat, ist dies trivial. Der Eintrag in der WEB-INF/jboss-web.xml hierzu lautet:


<resource-ref>
<res-ref-name>comp:jdbc/Datasource</res-ref-name>
<jndi-name>java:jboss/datasources/MyDataSource</jndi-name>
</resource-ref>

Der analoge Eintrag in der web.xml hierzu ist:


<resource-ref>
<description>java:postgreSQL Datasource</description>
<res-ref-name>jdbc/DataSource</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>

Kurzwellen-Küche: EPC-Mitglied #20910

amateur radio

Da ich sowieso etwas mikrophon-faul bin, meine CW-Kenntnisse noch nicht wirklich für die Welt taugen und die Antennensituation mit einem Balkon doch etwas eingeschränkt sind, bietet sich über diverse teils erstaunlich wirkungsvolle, digitale Betriebsarten ein weites Betätigungsfeld.

Da im OV und auch sonst in der Umgebung viel PSK betrieben wird, habe ich mich schon mal als Member beim EPC kostenlos eingetragen und angefangen mein Modem zu basteln. Die kostenlosen Diplome – die DIG erkennt sich nicht an – kann man über das EPC-eigene Diplomprogramm bequem ausrechnen lassen. Das ist mal ein Fortschritt. Es macht mir jetzt schon Spaß.

IMG_0094

Hier beim Löten eines Mini-DIN-6-Steckers für die DATA-Buchse des Transceivers in der Kurzwellen-Küche.

 

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

J2EE, Pitfall

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

J2EE, Maven

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.