artanis.info

Heute: Bedingte Ausführung von Geschäftslogik abhängig vom Loglevel:

Csvheader item = csvheaderDAO.findByPeriod(period);
if (item != null && item.getPeriod() == period)  {
	if (log.isDebugEnabled()) {
		log.debug("Aktualisierung des CSV Headers");
	}
	item.setHeader(header);
	item.setChangedBy(user);
	item.setChangedAt(new Timestamp(System.currentTimeMillis()));
} else if (log.isDebugEnabled()) {
	log.debug("neues Objekt des CSV Headers erzeugen.");
	item = new Csvheader();
	item.setPeriod(period);
	item.setHeader(header);
	item.setCreatedBy(user);
	item.setCreatedAt(new Timestamp(System.currentTimeMillis()));
	csvheaderDAO.persist(item);
}

Die heutige Preisfrage: Wie geht man wohl mit XML-Daten um?
Die Antwort zumindest im aktuellen Projekt führt einem die erschreckende Wahrheit vor Augen. Mich bestürzt vor allem die eklatante Mißachtung von Standards und das Ignorieren von vorhandenen Frameworks, welche die Arbeit mit XML-Daten optimieren würden. Stattdessen werden von allen möglichen Teams eigenen Lösungen gefrickelt und XML mit Java-Standardmitteln verarbeitet: Strings! Nicht, daß man eine XML-Datei bspw. mit SAX, DOM, JDOM oder $INSERT_YOUR_PREFERRED_XML_PARSER_HERE verarbeiten könnte, das wäre ja zu leicht.

currRequestId = zeile.substring(zeile.indexOf("<requestId>") + 11, 
        zeile.indexOf("</requestId>"));

Die Krönung ist dann, auch SOAP-Nachrichten auf diese Art und Weise zu erzeugen. Ist zu Fuß vermutlich viel einfacher, als – im Falle von Java – den Web Services Stack oder Axis zu verwenden.

Diese Fehlermeldung ist einem Kollegen auf dem aktuellen Projekt vor einigen Tagen über den Weg gelaufen, als er eine Blick in die Logdateien warf:

2010-03-16 18:06:24,523 FATAL [TA_KP20 / 488917180557516]
[MessageListenerThreadPool : 0]
DefaultTLProcessor - An unchecked exception has been caught.
java.lang.NullPointerException
        at PIObjectEnricherVeryDirtyWorkarroundForBugs1842and1924.enrich(PIObjectEnricherVeryDirtyWorkarroundForBugs1842and1924.java:62)

Da sage mal noch einer, Fehler würden nicht korrigiert werden oder gar, Entwickler hätten keinen Humor…

Folgende Methode haben zwei Kollegen in Java-Code gegossen aufgefunden:

private Period eroeffnung;
public Period getEroeffnung() {
    if (eroeffnung != null)
        return eroeffnung;
    else
        return null;
}

Folgendes Stück Code habe ich die Tage fabriziert und mich gewundert, warum Findbugs gleich zweimal laut anschlägt:

Connection conn = null;
Statement stmt = null;
ResultSet rs = null;
try {
    conn = DriverMananger.getConnection(...);
    ...
} catch (SQLException e) {
    ...
} finally {
    ...
    if (conn == null)
        conn.close();
}

Ich bin mittlerweile zum millionsten Mal über db4o und dessen Problem mit dem Java-Datentypen BigDecimal gestolpert.
Merke: In der Standardkonfiguration kann die objektorientierte Datenbank db4o Objekte vom Typ java.math.BigDecimal nicht korrekt speichern. Die Unterschiede hierfür scheinen – wenn man den Foren auf der Webseite folgt – über die Zeit unterschiedlich zu sein. Mal heißt es, es läge am fehlenden Standardkonstruktor, ein andermal, besondere transiente Felder seien daran schuld. Wie auch immer, es hat sich gezeigt, daß es mindestens drei Möglichkeiten gibt, mit dem Problem umzugehen.
Wichtig in allen drei Fällen ist, daß die Konfiguration von db4o vor dem Öffnen der Datenbank bzw. einer Datenbankverbindung stattfinden muß. weiter lesen

Mit der Standard Edition 5.0 hat Sun die Sprache Java u.a. um Generics erweitert. Hierbei handelt es sich um die Möglichkeit, Typen und Methoden zu parametrisieren. Damit ist es einem Entwickler möglich, beispielsweise typisierte Listen zu erstellen. Diese sind zur Entwicklungszeit typsicher und lästige Typumwandlungen entfallen. Allerdings werden diese Informationen vom Compiler während der Übersetzung wieder entfernt.
Ich selbst verwende Generics mittlerweile sehr gern, da man sich viel Arbeit spart und gleichzeitig robusteren Code schreibt. Allerdings habe ich vor einigen Tagen erstmals die Tücken von Generics kennengelernt. weiter lesen

Dieser Eintrag soll als kleine Anleitung zur Erstellung einer von der eigentlichen Installation unabhängigen Konfiguration des Tomcat Web Application Server dienen. Die Idee dahinter ist die, Installation und Konfiguration zu trennen, um beispielsweise die Wartung zu vereinfachen. In vielen Fällen werden die Webanwendungen direkt im Installationsverzeichnis installiert, ebenso wird die Konfiguration dort direkt angepaßt. Das führt jedoch dazu, daß die gesamte Arbeit wiederholt erledigt werden muß, wenn z.B. der Tomcat in einer neuen Version installiert wird. weiter lesen

Vor einiger Zeit stieß ich auf Arbeit auf ein Problem des JDBC-Treibers für Oracle, der da meldete, daß nur maximal 1000 Parameter an eine Anfrage übergeben werden dürfen. Die Liste mit Parametern war natürlich länger und mußte daher geeignet zerlegt werden. Dafür habe ich den folgenden Algorithmus verwendet:

public static List[] splitList(List largeList, int max) {
    int sublists = largeList.size() / max;
    if ((largeList.size() % max) > 0)
        ++sublists;
 
    List[] res = new List[sublists];
 
    for(int i=0; i<sublists; i++) {
        int from = max * i;
        int to = Math.min(max * (i+1), largeList.size());
        res[i] = largeList.subList(from, to);
    }
 
    return res;
}

Die Methode erwartet die zu teilende Liste sowie die Maximalzahl der Elemente pro Teilliste. Als Ergebnis wird ein Array mit allen erzeugten Teillisten geliefert.
Zunächst ermittelt der Algorithmus die Anzahl der notwendigen Teillisten (Zeilen 1 bis 3). Nach Erzeugung des Rückgabewertes wird dann mit Hilfe einer Schleife die Ausgangsliste in die berechnete Anzahl von Teillisten zerlegt (Zeilen 7 bis 11).