Posts

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:

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.

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:

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.

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):

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:

• JDK 6
• Tomcat 6
• Eclipse inklusive WTP, Maven (m2eclipse)
• Beim m2eclipse-Plugin “Maven integration for WTP” in Eclipse nachinstallieren, falls nicht vorhanden

Vorbereitung:

Commons-IO bzw. allg. Apache Commons ist eine schöne Ansammlung von nützlichen Bibliotheken und Funktionen. Darunter ist auch Commons-IO zu finden. Daraus will ich heute eine spezielle Lösung vorstellen. Hat man folgendes Problem: Möchte man einen Ordner, inklusive dessen Unterordner, nach bestimmten Dateien suchen und dann diese vielleicht nach Last-Modified sortiert, bietet Commons-IO eine Lösung an.

Um den/die Ordner durchzulaufen existiert ein DirectoryWalker. Um den abstrakten DirectoryWalker nutzen zu können könnte man z.B. eine folgende Implementierung nutzen:

Vor einiger Zeit wurde MQ installiert. Nun folgt endlich ein Beispiel wie man in Java MQ ansprechen kann. Dabei wird JMS (Java Message Servic) ohne JNDI (Java Naming and Directory Interface) verwendet. Ein JNDI-Beispiel folgt in einem späteren Blog.

Das Beispiel zeigt wie man mittels JMS eine MQ Nachricht verschicken und empfangen kann. Die Architektur steht hier nicht im Vordergrund, das nur die MQ Kommunikation.

Für das Versenden von MQ Nachrichten ist ein MQQueueSender verantwortlich, entsprechendes gilt für das Empfangen (MQQueueReceiver). Da bei MQ mehrere Clients Nachrichten verschicken können und jedem Client nur seine Antworten interessieren, gibt es die Möglichkeit dem Receiver einen Filter (Selector) anzugeben. Mit diesem Selector werden dann nur die MQ Nachrichten geliefert (empfangen), welche die Kriterien erfüllen. Hier lohnt es sich (nur) Correlation und Message ID zu nutzen, da andere Eigenschaften zu langsam in der Filterung sind. Bei der Correlation ID muss noch das Präfix ‘ID:’ angehangen werden, welches bei der Message ID schon automatisch vorhanden ist.

Beim Leeren von Datenbank-Tabellen müssen immer die vorhandenen Constraints beachtet werden. Das Löschen von Tabellen-Zeilen, obwohl andere darauf verweisen, ist nicht erlaubt (referenzielle Integrität). Versucht man es doch (mittels TRUNCATE [1]) kriegt man eine Fehlermeldung. Hier kann man nun entweder DELETE Statements [2] nutzen, was länger dauern kann, oder man verwendet doch TRUNCATE und muss die vorhandenen Constraints löschen.

ALTER TABLE TableName DROP CONSTRAINT FK_ConstraintName

Durch das Löschen aller Constraints der betroffenen Tabelle kann diese dann mit TRUNCATE geleert werden. Zum Hinzufügen der Constraints:

Caching ist eins der Aspekte welches man nicht unbedingt direkt in der Businesslogik verankern möchte. Hierzu empfehlt es sich eine AOP-Lösung. Mit AOP kann die Funktionalität einer Cache-Realisierung genutzt werden. Eins der populärsten Cache-Provider ist Ehcache.

In dem Umfeld von Spring kann man Ehcache folgendermaßen integrieren:

Man nutzt das aus dem nicht mehr gewarteten spring-modules-Projekt das cache-Modul. Ja, spring-modules wird durch Spring-Extensions abgelöst, jedoch werden nicht alle Projekte übernommen. D.h. manche Unterprojekte (wohl auch Cache) werden nicht nach Spring-Extensions übernommen. Wo da der Sinn liegt, ist wohl nur den Betreibern klar.