HSQLDB unterstützt seit einiger Zeit Sequences. Mit Sequences lassen sich sehr einfach Primärschlüssel generieren was von Hibernate mit dem Sequences-Generator auch direkt unterstützt wird. Will man das Default-Verhalten "eine Sequence für alle Entitäten" aber ersetzen durch "eine Sequence per Entität", so stößt man mit HSQLDB 1.8 und Hibernate 3.1.3 auf Probleme.
Wenn Spring’s AOP Framework Proxies erzeugt um eigene Klassen mit zusätzlichen Features zu versehen, kann das mitunter seltsame Effekte haben. Beispielsweise würde man doch vermuten, dass eine SpringBean die auf folgende Weise definiert ist:
<bean name="testBean" class="com.rinke.solutions.spring.test.SpringTestImpl" /> |
sich in einer Applikation immer in etwa in der Art verwenden läßt:
package com.rinke.solutions.spring.test;
import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;public class TestSpring {
/**
* @param args
*/
public static void main(String[] args) {
ApplicationContext ctx = new ClassPathXmlApplicationContext(
new String[] {"applicationContext.xml" });
SpringTestImpl myBean = (SpringTestImpl) ctx.getBean("testBean");
// ... do something
}}
Weit gefehlt!
Gestern hab ich mir die Preview von Pirates of the Caribbean – Fluch der Karibik 2 angetan, aber ich kann jedem Fan der ersten Folge nur abraten.
Das Applikation Framework Spring bringt ein sehr nützliches Feature mit: Autoproxing. Damit lassen sich Spring Beans – also eigentlich jede POJO-Klasse – um Aspekte erweitern. Aspekte sind gemäss AOP Belange eines Programms die sich quer zur eigentlichen Programmlogik erstecken (Cross-Cutting-Concerns).
In der Aspektorientierten Programmierung kann man diese Aspekte getrennt vom Rest des Programms formulieren und erst die AOP Umgebung "verwebt" den Aspektcode mit dem eigentlichen Programmcode. Hier gibt es prinzipiell zwei unterschiedliche Vorgehensweisen 1. zur Compile-Time (während des Kompilierens) oder 2. zur Run-Time (während der Laufzeit).
Der bekannteste Vertreter der 1. Variante ist sicher AspectJ, welches eine eigene Sprache formuliert und folglich auch einen eigenen Compiler mitbringt. Dieser Compiler sorgt für das Zusammenweben von Aspekten und restlichem Programmcode. Die Sprache liefert alle Mittel um Aspekte zu formulieren und darüber hinaus festzulegen an welchen Stellen der Aspect-Code eingebunden werden muss (Definition von sogenannten Pointcuts).
Beim Spring-Framework wird der Aspect-Code erst zur Laufzeit dem restlichen Programm hinzugefügt. Wie kann man sich das vorstellen? Da Spring Bean-Instanzen immer über die BeanFactory erzeugt werden, kann die Factory die erzeugten Instance beliebig verändern, solange sie für die Applikation nur "so aussehen" wie eine Bean vom Type XY. Bei Beans die ein bestimmtes Interface implentieren, bedeutet das, das die erzeugte Instance eben immer noch diese Interface implementieren muss. Wird kein Interface implementiert, so wird eine abgeleitete Klasse mindestens die gleichen "Public-Methods" bieten, wie die Basis-Klasse.
Endlich geschafft, das Media Portal ist in der Version 0.2 released. Äusserlich hat sich nicht viel getan, wer die SVN Shapshot mitverfolgt hat, der wird kaum einen Unterschied bemerken
Es gibt eine neue Version des "My Films"-Plugin für MediaPortal. Es importiert nun die Datenbank von Ant Movie Catalog direkt (als XML) und funktioniert seit der Version 2.2.2 richtig gut.
Zu beachten ist, dass für das MCE-Skin die Screen und Media-Datei extra zu kopieren sind, da das ürsprüngliche Zip-File das MCE Skin gar nicht unterstützt. Ausserdem hab ich für die deutsche Beschriftung die Position der Labels etwas angepasst und das Hover-Image von "My DVDs" verwendet, was mir persönlich besser gefällt.
Seit gut 2 Monaten ist auf meinem HomeCinema PC XC Cube EA65 AV von AOpen nun auch eine DVB-S Karte installiert. Ich verwende die Nova SE2 von Hauppauge, das günstigste Modell, da ich eine Fernbedienung eh schon zum AOpen dazu bekommen hab.
WebServices die unter Microsoft’s WSE 3.0 betrieben werden, können optional einen neuen Transport für Soap-Nachrichten benutzen:
Soap.Tcp: Die SOAP Nachrichten werden direkt per TCP verschickt allerdings versehen mit einem DIME-Frame.
Zwar gibt es einen kurzen Artikel von "Simon", der beschreibt wie man Microsoft .NET Services mit WSE 2.0 mit Java Axis interoperabel macht, aber die vorgestellten Sourcen setzen die SOAP Nachrichten "von Hand" zusammen, ausserdem läuft Simons Beispiel mit der aktuellen Version von WSE 3.0 nicht mehr.
Eine erste Version steht. Was mir bislang bei Facelets in einem ersten produktiven Projekt gefehlt hat, geht nun:
Wie integriere ich Third-Party-JSP Taglibs, wenn meine Views gar keine JSPs verwenden?
Die Idee beruht auf einer Lösung wie sie die Template-Engine Freemarker verwendet. Eine Container unabhängige JSP-Umgebung, die eine Taglib laden und aufrufen kann. Auf diese Weise werden in Freemarker JSP-Fragmente eingebettet und genauso lassen sich in Facelet-Views auch Third-Party-Taglibs integrieren.
Die Java-Sourcen sind weitgehend von Freemarker übernommen und noch nicht vollständig angepasst, aber das Prinzip wird deutlich und es funktioniert mit SimpleTags bereits.
Das Beispiel geht davon aus, dass man das Starterkit aus Facelets als WebApplikation installiert alles weitere ist in der Zip-Datei im Anhang zu finden.
Enttäuscht von den Schwierigkeiten die JSPs bei der Erstellung von Java Server Applikationen machen, suchte ich seit letzte Woche noch einer alternativen View-Technologie.
Die Suche ist zunächst zu Ende: Facelets ist die JSF-View Technologie.
Die Vorteile liegen für mich auf der Hand:
Die reichlich undurchsichtigen Regeln, die man beachten muss, wenn man JSF-Views mit JSP-Tags baut, sind vergessen. Eine View zu definieren ist sehr intuitiv.
