Niki rocks

In vielen Applikationen ist es üblich, dass Zusatz-Informationen zu einem persistierten Objekt gespeichert werden. Solche Zusatzinformationen sind normalerweise: Datum und Zeit des Creates oder Updates und die User, die diese Aktionen gemacht haben. Anstatt in den Service-Klassen dauernd diese Attribute zu setzen gibt es in JPA eine elegante Möglichkeit das zu erreichen.

Die zu persistierenden Objekte sollten alle von einer Basisklasse abgeleitet sein. Diese Basisklasse besitzt nun die Attribute createdBy, createdAt, changedBy und changedAt. Mit den Annotations @PrePersist und @PreUpdate kann man Methoden kennzeichnen, die vor dem Anlegen bzw. updaten des Objekts in der Datenbank aufgerufen werden. Dort kann man die Zusatzinformationen setzen bzw. updaten.

Hier mal ein kleines Codebeispiel dazu.

/**
 *
 */
package com.nikirocks.common.domain;

import java.io.Serializable;
import java.util.Date;

import javax.persistence.Column;
import javax.persistence.MappedSuperclass;
import javax.persistence.PrePersist;
import javax.persistence.PreUpdate;

import org.apache.log4j.Logger;

/**
 * @author Niki
 *
 */
@MappedSuperclass
public abstract class ABase implements Serializable {

 private static final Logger LOG = Logger.getLogger(ABase.class);

 /**
 *
 */
 private static final long serialVersionUID = -8317834487523332409L;
 protected String changedBy = "test";
 protected Date created;
 protected String createdBy = "test";
 protected Long id;
 protected Date lastChanged;

 @PrePersist
 public void fillCreated() {
 LOG.info("fillCreated called");
 Date now = new Date();
 this.created = now;
 this.lastChanged = now;
 }

 @PreUpdate
 public void fillLastChanged() {
 LOG.info("fillLastChanged called");
 this.lastChanged = new Date();
 }

 /**
 * @return the changedBy
 */
 @Column(name = "changedBy", nullable = false)
 public String getChangedBy() {
 return changedBy;
 }

 /**
 * @return the created
 */
 @Column(name = "created", nullable = false)
 public Date getCreated() {
 return (Date) created.clone();
 }

 /**
 * @param id
 *            the id to set
 */
 public void setId(Long id) {
 this.id = id;
 }

 /**
 * @return the createdBy
 */
 @Column(name = "createdBy", nullable = false)
 public String getCreatedBy() {
 return createdBy;
 }

 /**
 * @return the lastChanged
 */
 @Column(name = "lastChanged", nullable = false)
 public Date getLastChanged() {
 return (Date) lastChanged.clone();
 }

 /**
 * @param changedBy
 *            the changedBy to set
 */
 public void setChangedBy(String changedBy) {
 this.changedBy = changedBy;
 }

 /**
 * @param created
 *            the created to set
 */
 public void setCreated(Date created) {
 this.created = (Date) created.clone();
 }

 /**
 * @param createdBy
 *            the createdBy to set
 */
 public void setCreatedBy(String createdBy) {
 this.createdBy = createdBy;
 }

 /**
 * @param lastChanged
 *            the lastChanged to set
 */
 public void setLastChanged(Date lastChanged) {
 this.lastChanged = (Date) lastChanged.clone();
 }

 @Override
 public String toString() {
 return "Id=" + id + ", created=" + createdBy + "@" + created
 + ", modified=" + lastChanged + "@" + changedBy;
 }
}

Das einzige was man nun tun muss ist die Attribute changedBy und createdBy zu versorgen. Woher man diese Information zum aktuell eingeloggten User bekommt hängt stark von der Applikation bzw des gewählten Frameworks ab.

In letzter Zeit habe ich mich mit dem Web-Framework Wicket beschäftigt. Einer der größten Vorteile ist die Trennung von Mark-Up und Ablauflogik. Endlich muss der Webdesigner keine Ahnung von speziellen Markups haben. Dieses Framework könnte Zukunft haben!

Sofort habe ich mir ein Buch dazu bestellt - Praxisbuch Wicket. Dieses Buch kann ich nur empfehlen.

Ich werde demnächst dazu ein Wicket Projekt online stellen.

Endlich habe ich es geschafft. Ich habe das Xradar-Maven-Plugin gebändigt. Es war gar nicht so leicht, auf jeden Fall nicht so leicht wie auf der Plugin-Homepage beschrieben.

Zuerst passten einige Report-Destiniations nicht. Dann musste ich das Plugin aus der Report-Section herausnehmen und in die Build-Section stecken, weil die Emma-Reports und ein paar andere nicht gefunden wurden. Da passt wohl die zeitliche Abfolge oder die Reihenfolge der Reports nicht. Obwohl ich das Xradar-Plugin an das Ende der Report-Section gestellt habe (wie beschrieben) funktionierte es nicht.

Also muss ich jetzt mvn site aufrufen um alle Reports zu erstellen. Danach die Xradar-Goals (audit und dynamic) und anschließend mvn site:deploy um diese Site auf meinen Webspace zu legen. Deshalb musste auch der Site-Descriptor angepasst werden um Links zu den Xradar-Reports einzufügen.

Schlussendlich habe ich dann das CustomScope Projekt online gestellt – inklusive Xradar.

Die nächsten Schritte sollten nun die Xradar-Anpassungen sein (Subsysteme anlegen, usw.) und XRadar in das Timing Projekt zu integrieren.

So, nun habe ich mal zwei Beispiele für Java Projekte online gestellt. Es handelt sich um Java Projekte, die mit Maven erstellt wurden. Der Inhalt der Projekte ist nicht so spannend. Ich wollte nur ein paar Tools, die ich schon länger verwende einsetzen und alles online stellen.

Also haute ich in die Tasten und habe diese Schritte unternommen:

• neue Subdomain erstellt – http://java.nikirocks.com/
• neue Subdomain für Subversion angelegt – http://svn.nikirocks.com/
• Subversion repository angelegt (ging ganz leicht bei meinem Hoster dreamhost.com)
• die alten Spielprojekte Timing und SpringScopes auf maven umgestellt
• die Projekte in Subversion angelegt
• die maven sites (project-sites) deployed
• CruiseControl für Continous-Integration eingesetzt
• google Analytics in die maven project-sites integriert

Folgende Dinge möchte ich als nächstes erledigen:

• Xradar einbinden
• trac oder bugzilla aufsetzen und die Projekte dort einbringen
• noch ein paar zusätzliche private Projekte ablegen

Für Interessierte gibts hier die Links zu den Projekten

• Timing wiht AOP
• Custom Spring Scopes