Buschmais wird sich am 10.12.2009 in der Fakultät Informatik der TU Dresden dem Thema Laufzeitmanagement von OSGi Applikationen widmen.
Die OSGi-Plattform mit ihren modularen und dynamischen Konzepten stellt das Laufzeitmanagement von Applikationen vor neue Herausforderungen. Wo standardisierte Vorgaben fehlen, entsteht Freiraum für Wildwuchs und zahlreiche proprietäre Lösungen. Dass dieser vermeintliche Stolperstein nicht allzu fest verankert ist, zeigt das Framework “MAEXO”, indem es die Konzepte von OSGi und JMX zu einer gleichermaßen nützlichen Symbiose vereint. Wie genau diese Harmonie zwischen beiden Welten in Theorie und Praxis entsteht, wird Gegenstand des Vortrags von Tobias Israel sein.
Weitere Informationen zur Veranstaltung finden Sie unter www.jugsaxony.de.
Die Anmeldung erfolgt unter http://de.amiando.com/jugsaxony-osgi.html.
Zwischen der Flexibilität reinen SQLs und der Mächtigkeit ausgewachsener O/R-Mapper existiert eine kleine Bibliothek, die es beinahe in das JDK 6 geschafft hätte: EoD SQL (Ease of Development SQL). Die Idee hinter EoD SQL ist so genial wie einfach: Der Nutzer annotiert ein Java-Interface mit SQL-Statements und die Bibliothek liefert mittels eines Java-Reflection-Proxys eine Implementierung dieses Interfaces zur Benutzung:
public interface NutzerMgmt extends BaseQuery {
@Select("SELECT COUNT(*) FROM USER")
long ermittleNutzerAnzahl();
}
Folglich die Benutzung :
Connection c = … ;
NutzerMgmt nutzerMgmt = QueryTool.getQuery(c, NutzerMgmt.class);
try {
long anzahl = nutzerMgmt.ermittleNutzerAnzahl();
} finally {
nutzerMgmt.close(); // schließt ebenfalls die Connection
}
Möchte man das Gleiche mit reinem SQL erreichen, so ist der Code ungleich komplizierter:
‘O/R-Mapping ohne Schnickschnack’ weiterlesen
Die buschmais GbR wird am 25. November 2009 mit dem Vortrag „Java Persistence Puzzlers“ von Herrn Frank Schwarz auf der datacon 09 in München vertreten sein.
Im Stile der beliebten Java-Puzzlers wird das Publikum auf die dunkle Seite
des Java Persistence APIs gelockt. Durch die Untiefen der Implementierungen,
vorbei an schaurig schönen Formulierungen alter und neuer Spezifikationen
begibt sich das Publikum auf eine Reise voller Rätsel und Mysterien.
Java Persistence Puzzlers
Frank Schwarz | buschmais GbR
25. November 2009
12.00 - 13.00 Uhr
Die datacon zum Thema “Datenintegration” findet vom 24. - 25. November 2009
im Konferenzzentrum in München statt.
Nähere Informationen zum Programm, zu Referenten, zur Anreise etc. erhalten
Sie unter www.data-conference.de
datacon 09 – Die Konferenz für Datenprofis
Allgemein bekannt ist die Tatsache, dass Managed-Beans in der Faces-Config-XML-Datei nicht nur deklariert, sondern auch initialisiert werden können. Schon weniger bekannt ist die Tatsache, dass bei der Initialisierung der Beans auch Verknüpfungen zu anderen Managed-Beans hergestellt werden können. Zur Verdeutlichung soll der folgende Code-Schnipsel dienen:
<faces-config version="1.2" ...>
<managed-bean>
<managed-bean-name>user</managed-bean-name>
<managed-bean-class>
my.app.model.Person</managed-bean-class>
<managed-bean-scope>application</managed-bean-scope>
<managed-property>
<property-name>homeAddress</property-name>
<value>#{address}</value>
</managed-property>
</managed-bean>
<managed-bean>
<managed-bean-name>address</managed-bean-name>
<managed-bean-class>
my.app.model.Address</managed-bean-class>
<managed-bean-scope>application</managed-bean-scope>
<managed-property>
<property-name>city</property-name>
<value>Dresden</value>
</managed-property>
<managed-property>
<property-name>street</property-name>
<value>Leipziger Str. 93</value>
</managed-property>
</managed-bean>
</faces-config>
WEB-INF/faces-config.xml: Initialisierung einer Managed-Bean
In Zeile 9 wird die Verbingung zwischen der Bean “user” und der Bean “address” über die Eigenschaft “homeAddress” hergestellt.
Wie lässt sich allerdings die Sache angehen, wenn man für das Address-Objekt keine eigenständige Bean deklarieren möchte?
‘Initialisierung von JSF-Managed-Beans’ weiterlesen
Möchte man ein Nicht-Maven-Artefakt samt Quellen und Javadoc in ein privates Maven-Repository einbringen, so scheint sich das Maven-Kommando maven deploy:deploy-file bei den Prüfsummen gründlich zu verrechnen:
[WARNING] *** CHECKSUM FAILED - Checksum failed on download:
local = ‘ce32ed2aacb0fc64e82…’; remote = ‘8d52454bff41a149f4b…’
- RETRYING
Ein kleines Shell-Skript - auf Seiten des Repositorys - verschafft Abhilfe:
#! /bin/bash
find . -type f \
\( -name '*.jar' -or -name '*.pom' -or -name '*.xml' \) \
-print0 | while read -rd $'\0' file; do
sha1sum $file | cut -d ' ' -f 1 > $file.sha1
md5sum $file | cut -d ' ' -f 1 > $file.md5
done
Maven ist genial, solange es funktioniert.
