J and I and Me
2007-02-26
  Spring und der Spring Day auf der JAX
Im Rahmen der JAX findet auch dieses Jahr ein Spring Day statt. Einige der Vorträge drehen sich dabei auch um Architekturfragen wie:



Weitere Themen sind:


Spring Lead Developer Jürgen Höller (Interface21) gibt außerdem einen Überblick über die neuen Features in Spring 2.1. Weitere Infos gibt es hier.

In der Hauptkonferenz gibt es noch mehr Vorträge im Bereich Spring:


Interface21 wird auch einen Stand haben, wo man sicher auch Jürgen oder Rod treffen kann! Mehr Informationen gibt es auf der JAX Web Site: http://jax.de/ .

Vielleicht trifft man sich!
 
Bookmark and Share
2007-02-25
  Refactoring-Episode bei SE-Radio
Hier gibt es die neue Folge von SE-Radio - in dieser reden Martin Lippert und ich über Refactoring. Viel Spaß beim Zuhören!
 
Bookmark and Share
  Mac OS X: Betriebssystem der Wahl...
Als Betriebssystem mit Unix-Kernel bietet Mac OS X natürlich hervorragende Qualitäten. Letztes Wochenende verabschiedete es sich so, dass mir nur die Wahl blieb, den Rechner auszuschalten. Na ja, Rechner wieder eingeschaltet und - Computer fährt nicht wieder hoch. Hm. Rechner in Verbose-Mode hochgefahren - irgendwas von wegen "Filesystem is read-only". Schön. Also: Single-User Mode. Dankenswerterweise gibt es da auch gleich eine Anleitung, wie man das File-System mit read-write nach einem fsck mounten kann. Gesagt - getan. Ergebnis "invalid sibling link" und nichts von wegen, dass das Filesystem jetzt wieder read-write wäre. Hm. In diesem Zusammenhang ist die Manual-Page von fsck_hfs auch nicht sehr ermutigend:

BUGS
fsck_hfs is not able to fix some inconsistencies that it detects.

Das bedeutet in letzter Konsequenz: "Hey, Dein Filesystem ist halt hin. Ich kann aber nix machen. Sorry." Anscheinend ist beim Runterfallen des Betriebssystems irgendetwas in den Verzeichnis-Strukturen verloren gegangen. Ein fsck -r, dass die Verzeichnisse wieder neu anlegt, brachte auch nicht. OK, also ein echtes Problem. Und, nein, ich kann meinen Laptop nicht ernsthaft am Sonntag abend neu installieren, wenn ich am Montag beim Kunden sein will - trotz Backup. Dauert einfach zu lange.

Lösung war dann, das MacBook an meinen G4 im Firewire-Target-Mode zu hängen, so dass er sich wie eine Firewire-Festplatte verhält und von dort aus mit DiskWarrior 4 reparieren zu lassen. Verluste: Bookmarks und ein VMWare PC-Image, aber keine Arbeit. Ufff. Wie man sieht, Mac OS X bietet die höchste Sicherheit für die Daten.

Labels:

 
Bookmark and Share
2007-02-09
  Globalisierung
Woran merkt man, dass man in einer internationalen Firma arbeitet?

 
Bookmark and Share
  JDBC Innovation in JDK 6
Wie man hier nachlesen kann, wird uns JDK 6 einige neue SQLExceptions geben. Das ist erstmal gut. Leider sind die SQLRuntimeExceptions, die mal geplant waren, inzwischen wieder aus der Spezifikation verloren gegangen. Das ist auch nicht wirklich verwunderlich, weil man durch diese Exceptions das Problem hatte, dass auf der einen Seite die checked SQLException steht, die man fangen muss, und auf der anderen Seite die unchecked SQLRuntimeException, die man nicht unbedingt fangen muss - das macht das Leben nur bedingt einfacher. Grundsätzlich sollten technische Exceptions aber RuntimeExceptions sein, weil man sonst die Anwendung dazu zwingt, auf technische Fehler zu reagieren, was sie nur in Ausnahmefällen kann. RuntimeExceptions sind besser geeignet, weil man sie auch in einen generischen Exception-Handler behandeln lassen kann, der z.B. wegen NullPointExceptions sowieso da sein sollte.

Dafür sind die Exceptions bei JDBC jetzt also genauer ausdifferenziert - wenn die Treiber denn mitmachen. Leider betriffft das nur JDBC, wenn man also mit Hibernate auf die Datenbank zugreift, bekommt man für dieselbe Fehler-Situation eine andere Exception.

Letztendlich kommt auch der zitierte Artikel zu dem Schluß, dass man dennoch Spring nutzen sollte. Warum? Weil


Und dann gibt es noch Dinge wie NamedParameterJdbcTemplate die das Leben weiter vereinfachen.

JDBC ohne Spring ist einfach keine gute Idee. Die interessante Frage ist nun, was das für JDBC heißt. Meiner Ansicht nach kann im JDBC-Standard selbst kaum noch sinnvolle Arbeit geleistet werden. Wenn man sowieso nicht mit JDBC direkt arbeiten kann, sondern eine Abstraktion wie Spring JdcbTemplate verwendet, macht eine Verbesserung der APIs keinen Sinn. Die neuen Features von JDBC 4 zur automatischen Umwandlung von Anfrage-Ergebnissen in Objekte, die eher in die Richtung von iBATIS gehen, sehe ich daher eher kritisch. Bei den Exceptions kann man wegen der Abwärtkompatibilität nicht viel machen, RuntimeExceptions zusätzlich einzubauen ist kaum sinnvoll. Der große Erfolg von JDBC ist, dass es JDBC-Treiber für praktisch alle Datenbanken gibt und JDBC daher eine gute Basis für all die anderen Java-Persistenzlösungen bieten kann.
 
Bookmark and Share
2007-02-07
  Interface21 ist auf dem Radarschirm der Analysten
Hier gibt es auf Seite 9 einen interessanten Artikel von Michael Goulde, Senior Analyst bei Forrester. Er sagt, dass Interface21 das Open Source Business Modell hervorragend versteht - danke für die Blumen! Interessant ist vor allem, dass der Artikel sich nicht auf die technischen Qualität von Spring bezieht, die schon häufig von verschiedenen Blickwinkel heraus betrachtet worden ist, sondern es geht um das Geschäftsmodell. Das Produkt ist aus seiner Sicht nur ein Punkt. Die beiden anderen sind die Community und schließlich Customer Engagement. Der Autor empfiehlt sogar, dass Modell zu studieren und gegebenenfalls auf andere Open Source Projekte und Firmen übertragen kann.

Labels: , , ,

 
Bookmark and Share
2007-02-04
  AOP ist zu kompliziert!
AOP geht leider immer noch der Ruf voraus, zu kompliziert zu sein. Das Thema hatte ich schon mal am Rande aufgegriffen.

Es ist zunächst schlicht so, dass AOP eine Basis für Enterprise-Anwendungen bildet. Schon in EJB gab es Unterstützung für Security und Transaktionen und der notwendige Code wurde zwischen den Interfaces des EJBs und der Implementierung eingebaut. Das Problem bei diesem Ansatz war, dass es keine Möglichkeit gab, eigene Dinge analog zu Security und Transaktionen einzubauen. EJB 3 bietet hier zwar einen Interceptor-Mechanismus, aber der führt dazu, dass man an jeder Bean eine Konfiguration für den Interceptor vornehmen muss oder aber der Interceptor bei jeder Bean zuschlägt - dann muss man selber zum Beispiel abfragen, ob die Bean eine passende Annotation trägt.

Es geht hier also zunächst darum, eine vernünftige und allgemeingültige Basis für die Implementierung technischer Aspekte zu schaffen. Und in AOP / AspectJ sind mittlerweile 10 Jahre Forschung und Entwwicklung geflossen - was könnte also besser geeignet sein? Bei Spring ist es durch den DebugInterceptor, den PerformanceMonitoringInterceptor oder dem JamonPerformanceMonitorInterceptor hat Spring auch gleich eine Palette an anderen interessante Interceptoren.

Nun kann man natürlich argumentieren, dass das alles viel zu komplizier ist. Eine Möglichkeit damit umzugehen, ist es, dass man das Wissen auf einige Leute beschränkt. Es muss schließlich nicht jeder technische Aspekte wie Security oder Tranaktione implementieren - dann kann man das Wissen über AOP auch auf jene beschränken, die solche Aspekte implementieren wollen bzw. müssen - die anderen können einfach die richtigen Annotationen im Code setzen und sich dann darauf verlassen, dass das richtige passiert - wie es eben auch schon bei EJB war.

Der andere interessante Effekt ist, dass AOP der Ruf voraus geht, dass es kompliziert ist - und zwar bis dahin, dass Adrian Colyer zum Teil die Strategie hat "Don't tell them it's AOP". Das ist nachvollziehbar - zumal die AspectJ Pointcuts den normalen Methodendefinitionen in Java sehr ähnlich sind.

Man sehe sich folgende Beispiel an:


@Aspect
public class MeinDebugAspekt {

@Before("execution(void tuEs())")
public void meinBeforeAdvice() {
System.out.println("Before Advice");
}
}


Hier gibt es nicht viel zu verstehen, außer dass vor Ausführung (execution) jeder Methode, die die Methodendefinition void tuEs() hat, noch der zusätzliche Code aus meinBeforeAdvice ausgeführt wird. Wenn man dann noch Wildcards einführt wie


@Aspect
public class MeinDebugAspekt {

@Before("execution(* tuEs(..))")
public void meinBeforeAdvice() {
System.out.println("Before Advice");
}
}


dann kann man schon mal definieren, dass beliebige Rückgabewerte (*) und Parameter (*) für die Methode erlaubt sind - das ist dann schon ausreichend, um zum Beispiel für die create()-Methoden der DAOs einen Aspekt zu definieren.

Also: AOP ist nicht so kompliziert wie es scheint. Und selbst wenn - nicht jeder muss es verstehen - schließlich versteht auch nicht jeder die internen Abläufe in einem Application Server. Dennoch benötigt man die Technologie, um Aspekte wie Security, Transaktionen usw. zu implementieren. Und statt einer ad-hoc-Lösung ist dann AOP als etablierte Basis sicher besser.
 
Bookmark and Share
J for Java | I for Internet, iMac, iPod and iPad | Me for me

ARCHIVES
Juni 2005 / Juli 2005 / August 2005 / September 2005 / Oktober 2005 / November 2005 / Dezember 2005 / Januar 2006 / Februar 2006 / März 2006 / April 2006 / Mai 2006 / Juni 2006 / Juli 2006 / August 2006 / September 2006 / Oktober 2006 / November 2006 / Dezember 2006 / Januar 2007 / Februar 2007 / März 2007 / April 2007 / Mai 2007 / Juni 2007 / Juli 2007 / August 2007 / September 2007 / Oktober 2007 / November 2007 / Dezember 2007 / Januar 2008 / April 2008 / Mai 2008 / Juni 2008 / August 2008 / September 2008 / November 2008 / Januar 2009 / Februar 2009 / März 2009 / April 2009 / Mai 2009 / Juni 2009 / Juli 2009 / August 2009 / September 2009 / Oktober 2009 / November 2009 / Dezember 2009 / Januar 2010 / Februar 2010 / März 2010 / April 2010 / Mai 2010 / Juli 2010 / August 2010 / Oktober 2010 / Januar 2011 / Februar 2011 / März 2011 / April 2011 / Mai 2011 / Juni 2011 / August 2011 / September 2011 / November 2011 / Februar 2012 / April 2012 / Mai 2012 / April 2013 / Mai 2013 / Juni 2013 / Januar 2015 / Juli 2015 / Februar 2016 /

Links

Twitter
Google +
Slideshare
Prezi
XING
LinkedIn
Das Spring Buch


Feeds

Feedburner


Impressum
Betreiber und Kontakt:
Eberhard Wolff
Leobschützer Strasse 22
13125 Berlin
E-Mail-Adresse: eberhard.wolff@gmail.com

Verantwortlich für journalistisch-redaktionelle Inhalte:
Eberhard Wolff