JEE: Arquillian

Überblick

# This code block gets replaced with the TOC

Arquillian ist ein Framework für Integration Tests. Es bietet die Möglichkeit für bestimmte Testfälle ein Deployment bereitzustellen, was die nur die relevanten Klassen besitzt. Diese sogenannten Micro-Deployments können mittels Arquillian einfach definiert werden und dann in einem embedded or existierenden Container eingesetzt werden. In diesem werden dann die Testfälle durchgeführt. Zur Vollständigkeit ist noch erwähnt, dass Arquillian auch für client-seitige Tests verwendet werden kann, in solchen Fällen ist ein Deployment nicht notwendig. Als Deployment-Format stehen verschiedene zur Verfügung, z.B. Jar, War, Ear etc. Genauso stehen als Container verschiedene Alternativen zur Verfügung. Arquillian bietet hierfür die gängigsten Adapter an, siehe [2].

[Read More]

CDI in JavaSE

CDI – Contexts and Dependency Injection for the Java(tm) EE platform [1] - ist nicht neu und man findet im Netz auch genug gute Einführungen (z.B. [2] und natürlich immer auch bei [3], [4] etc). Möchte man jedoch CDI außerhalb eines Container (AppServer) verwenden, sprich in einer Java SE Umgebung, sucht man schon etwas länger. Bei CDI gibt es u.a. folgende Implementierungen: Weld [5] und OpenWebBeans [6]. Bei der Referenzimplementierung Weld ist die Dokumentation vorbildlich und es gibt auch ein Kapitel [7] welches den Einsatz in einer Java SE Umgebung beschreibt. Solch ein Kapitel sucht man bei OpenWebBeans leider vergebens – das Kapitel an sich existiert schon, leider ohne Inhalt. Zum Glück findet man im SVN jedoch ein SE-Bespiel [8]. Für Version 1.1.2 ersetzt man folgende Zeil:

[Read More]
cdi  java 

Nodejs HTTP-Server

Schreibt man eine Client-Anwendung, die mit einem Server kommunizieren soll, weclhes zum Testing nicht zur Verfügung steht, muss man schauen, wie man die Kommunikation simulieren kann. Am besten wäre eine Test-Implementierung des Servers, der die Spezifikation/API unterstützt. Bevor die Spezifikation zum Test implementiert werden kann, muss jedoch die Grundfunktionalität (HTTP) des Server implementiert werden. Um sich das zu ersparen, kann man z.B. nodejs verwenden.

var http = require('http'),
	url = require('url');

var results = \["status=OK&desc=Alles paletti&url=http://www.heise.de/",
			   "status=NOK&desc=Oh, problem&url="\];
	
var httpServer = http.createServer();

httpServer.on('request', function(request, response) {
	// Parse the entire URI to get just the query
	var query = url.parse(request.url, true).query;
	// parse the query parameters
	var param1 	= query\['p1'\];
	var param2	= query\['p2'\];
	var param3	= query\['p3'\];
	
	// Do something with the parameters to generate the response.....
	
	// return random response
	response.writeHead(200, {'Content-Type': 'text/plain'});
	var rnd = Math.floor(Math.random() \* results.length)
	response.end(results\[rnd\]);
});

httpServer.listen(1337, '127.0.0.1');

console.log('- Server running at http://127.0.0.1:1337/');

Wie man sehen kann, wird in wenigen Zeilen JavaScript ein HTTP-Server geschrieben, der auf den “request”-Event horcht. Bei jedem Request werden die Parameter ermittelt und die Response generiert. Nodejs bietet verschiedene Events an, für die ein Callback-Funktion registriert werden kann. Beim HTTP-Server sind das z.B.: request, connection, close. Weitere Details sind in der Docu zu finden.

[Read More]
js  test  web 

REST JMX Monitoring

Ich bin wieder auf der JAX und auch bei Adam Bien. Beides ist nur zu empfehlen! ;-) Während des Workshops kamen wir auf REST und JMX und das es eigentlich eine gute Idee wäre, JMX Monitoring mittels REST anzubieten. Klingt interessant. Sofort ausprobiert.

Mit Eclipse mal fix ein dynamisches Webprojekt erstellt. Drauf geachtet, dass REST (JAX-RS) ausgewählt wird. Glassfish ist schon vom letzten Projekt in Eclipse integriert. Während der Projekterstellung bietet der Wizard u.a. die Konfiguration für REST an. Da kann u.a. das URL matching pattern eingeben werden (default: /rest/*)

[Read More]
jee  jmx  rest 

Derby Export

Beim Einsatz der Java Derby Datenbank kommt irgendwann der Wunsch einzelne Daten oder eine komplette Tabelle zu exportieren. Hierfür bietet Derby verschiedene Procedures an:

  • SYSCS_UTIL.SYSCS_EXPORT_TABLE: Zum exportieren einer kompletten Tabelle
  • SYSCS_UTIL.SYSCS_EXPORT_QUERY: Exportiert die Daten, die dem mitgegebenen SELECT entsprechen
  • SYSCS_UTIL.SYSCS_BACKUP_DATABASE: Kompletter Backup der DB.

Die Export-Procedures liefern eine CSV-Datei, wobei man die Trennzeichen definieren kann. Beim Backup-Procedure wird die ganze Ordnerstruktur in einen gewünschten Ordner kopiert.

Zum Exportieren einer ganzen Tabelle sieht die Signatur der Procedure wie folgt aus:

[Read More]
db2  java 

JPA: Dynamic Datasource Routing

Man stelle sich vor, in einer (Web-)Anwendung müssen verschiedene Datasources verwendet werden. Ob bei den unterschiedlichen Datasourcen es sich immer um die andere/gleiche Datenbank handelt, sei mal dahingestellt. Die Datasourcen unterscheiden sich mind. in einer Eigenschaft, z.B. User.

Im Spring-Kontext gilt folgendes: In JPA braucht man pro EntityManagerFactory eine Datasource. Der EMF ist einen TransactionManager zugeordnet.

Man könnte alle Datasource, EMF, TX-Manager und PUs in Spring konfigurieren. Man hat jedoch ein Problem, wenn man n verschiedene Datasourcen hat, die zur Laufzeit ausgewählt werden müssen.

[Read More]
db2  jpa  spring 

.NET: XmlSerializer ohne dynamische Code-Generierung

Unter C# kann man mittels XmlSerializer XML Daten zu Objekten deserialisieren oder den umgekehrten Weg, Objekte zu XML umwandeln. Hier hat die Dokumentation jedoch eine beachtliche Lücke. XmlSerialiser generiert nämlich jedesmal on-the-fly eine DLL um den XML Stream typ-sicher umwandeln zu können. Hierfür wird eine C# Source-Datei generiert und csc.exe aufgerufen. Die erstellten Dateien werden im %TEMP%-Verzeichnis erstellt und in der Standardeinstellung sofort wieder gelöscht, wenn sie nicht mehr benötigt werden. Das automatische Löschen kann man umgehen, wenn man z.B. in WINDOWS\Microsoft.NET\Framework\v2.0...\CONFIG\maschine.config folgenden Eintrag hinzufügt:

[Read More]
net  c  xml 

Spring AOP & Ehcache

Caching ist ja bekanntlich eine Querschnitts-Anforderung (cross cutting concern), was man eigentlich nicht direkt in die Business-Logik integrieren möchte/sollte. Hier bietet es sich an, die Cache-Funktionalität mittels AOP (Aspektorientierte Programmierung) zu realisieren. Dieser Beitrag erklärt das exemplarisch realisieren der Cache-Funktionalität mittels Spring AOP und Ehcache. Einführung Vorweg. Es gibt natürlich bei den springmodules ein Cache-Modul. Dieses wird, wenn überhaupt, nur sehr langsam weiterentwickelt. Das neue Spring Extensions Projekt beinhaltet leider kein Cache-Modul. Hinzu kommen noch fehlende Funktionalitäten wie z.B. das Löschen von nur einem Objekt aus dem Cache. Falls man jedoch doch Springmodules Cache nutzen will, kann man sich mein altes Beispiel anschauen.

[Read More]

Spec 2.0: JSF 2 Überblick

JSF ist ja nicht jedermanns Sache. Ich fand JSF 1.x auch mit den “Problemen” toll. Die Implementierung (Mojarra und MyFaces) hatten so manche Fehler und zusätzliche Funktionalitäten, welche in der Spec nicht definiert wurden. Aber im Großen und Ganzen ein gutes und solides Konzept. Leider jedoch ein Framework, was ein paar Jährchen und Trends hinter sich hat - JSF 1.1 (JSR 127, 03.2001) und JSF 1.2 (JSR 252, 05.2006). Seit 07.2009 gibt es nun das Final Release der JSF 2.0 Spezifikation (JSR 314). Die RI von SUN steht auch bald bereit und auch die Truppe um MyFaces hat einen JSF 2.0 Branch erstellt. Spätestens jetzt sollte man einen Blick auf die Neuerungen und Verbesserungen, die mit 2.0 eingeführt werden, werfen. Möchte man sich nun mit JSF 2.0 auseinander setzen, könnte man sich die ersten Bücher besorgen, aber ob diese aktuell und praxistauglich sind, sei jedem überlassen. Die vielleicht komplette und aktuelle Information kriegt man zur Zeit, wenn man sich direkt die APIs anschaut und verschiedene Blogs verfolgt. Hier folgt erstmal eine unvollständige Liste von Informationsquellen (wird aktualisiert):

[Read More]

Tutorial: JSF 2.0 Beispielanwendung

Wie schon erwähnt, erscheinen bald die ersten Releases von JSF 2.0. Entsprechend wird nun eine kleine Beispielanwendung erstellt, um einen ersten Eindruck zu bekommen. Technologie:

  • JSF 2.0: Mojarra in Version 2.0.0-b16
  • Tomcat 6
  • Maven
  • Eclipse

Voraussetzung:

Vorbereitung:

[Read More]