Seit der Version 3.2 können verschiedene ByteCode-Provider eingesetzt werden. So kann der Standard-Provider CGLIB durch z.B. javassist ersetzt werden. Diese Einstellung wird über den Parameter “hibernate.bytecode.provider” in der Hibernate-Konfiguration geregelt:

hibernate.bytecode.provider = cglib | javassist

Im JBoss-Server wird diese Einstellung standardmäßig auf javassist gestellt. Da dies jedoch teilweise noch Probleme gibt, vor allem bei RMI-Anwendungen, kann dies über die persistence.xml entsprechend angepasst werden. In der Version 4.0.4.GA vom JBoss produziert JavaAssist bei jeder Abfrage eine Unmenge an Klassen, die dann den PermGen Space zum Überlauf bringen.

Am 16. April war es so weit: Google kauft das Affiliate Netzwerk DoubleClick. Für 3,1 Milliarden US Dollar ging das Unternehmen an Google über. Der Preis ist jedoch etwas hoch; so hat DoubleClick nur einen geschätzten Marktwert von 2 Milliarden Dollar. Man munkelt dass der Preis das Ergebnis einer Preisschlacht mit anderen Unternehmen sein könnte wobei Google mit seiner Finanzstärke wohl am längeren Hebel sass. DoubleClick Arbeitet vorwiegend mit ImageAnzeigen wie die Firma Zanox hierzulande. Es bleibt doch zu hoffen, dass die Zanox nicht auch noch Opfer einer feindlichen Übernahme wird, was ich persönlich sehr schade finden würde. Wie auf lektroliv.com zu lesen ist, sollte Springer auch seit einiger Zeit Interesse an der Zanox haben, womit mir die Befürchtung nicht ganz unbegründet erscheint.

Ich wollte soeben von einer Klasse das Vorhandensein einer Annotation prüfen.

Hierzu wie gewohnt folgender Code:

Class clazz = …
if (clazz.isAnnotationPresent(Stateless.class)) { … }

Danach bekam ich folgende Exception um die Ohren geschmissen:

java.lang.annotation.AnnotationFormatError: Invalid default: public abstract java.lang.Class org.jboss.annotation.ejb.RemoteBinding.factory()
	at java.lang.reflect.Method.getDefaultValue(Method.java:709)
	at sun.reflect.annotation.AnnotationType.(AnnotationType.java:90)
	at sun.reflect.annotation.AnnotationType.getInstance(AnnotationType.java:64)
	at sun.reflect.annotation.AnnotationParser.parseAnnotation(AnnotationParser.java:202)
	at sun.reflect.annotation.AnnotationParser.parseAnnotations2(AnnotationParser.java:69)
	at sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:52)
	at java.lang.Class.initAnnotationsIfNecessary(Class.java:2998)
…

Nach langer Suche und anfänglicher Fehlinterpretation bin ich dank des Bugeintrages bei Java dahinter gekommen, dass einfach eine Klasse nicht zur Verfügung stand. Die Annotation RemoteBinding definiert eine Klasse als Default-Wert, die in dem Standardpaket vom JBoss nicht mit enthalten ist und daher im JUnit-Test zu Problemen führen kann. Nachdem die richtige Bibliothek mit im Klassenpfad aufgenommen wurde, funktioniert auch die Analyze wie erwartet.

Standardmäßig beginnen im Latex die Fußnoten mit jedem neuen Kapitel von vorn. Der Zähler selbst kann mit dem “footnote”-counter gesetzt werden. (\setcounter{footnote}{100}) Dies hilft einem jedoch nicht, wenn der Zähler zurück gesetzt wird, aber dies nicht geschehen soll. Hierfür kann das Paket “remreset” verwendet werden, dass den Befehl “removefromreset” definiert um vorher definierte “addtoreset” zu widerrufen. Im Code sieht das dann wie folgt aus:

...
\usepackage{remreset}
\makeatletter
\@removefromreset{footnote}{chapter}
\makeatother
…
\begin{document}
…

Für andere Zähler müssen nur die Parameter entsprechend angepasst werden.

Mit Hilfe des Maven Plugins “aspectj-maven-plugin” von Codehaus kann man problemlos den AspectJ-Compiler in Maven integrieren und seine Projekte entsprechend mit Aspekten anreichern. Diese Bibliothek ist jedoch von Haus aus an AspectJ Version 1.5.2a gebunden. Man erhält bei Verwendung einer anderen Version der Runtime von AspectJ automatisch immer folgende Fehlermeldung:

bad version number found in /Users/frank/.m2/repository/aspectj/aspectjrt/1.5.3/aspectjrt-1.5.3.jar expected 1.5.2a found 1.5.3

Dies ist soweit nicht schlimm, falls man mit dem Compiler aus 1.5.2a keine Probleme hat. Da ich jedoch auf die Behebung eines Bugs in Version 1.5.3 angewiesen war, nützte die Verwendung von 1.5.2a mir recht wenig. Dies ist jedoch dank des ausgefeilten Abhängigkeitsmanagement von Maven behebbar, indem auch die AspectJ-Tools in Version 1.5.3 verwendet werden. Dazu muss einfach unter den Abhängigkeiten bei Maven folgender Punkt eingetragen werden:

<dependency>
     <groupId>aspectj</groupId>
     <artifactId>aspectjtools</artifactId>
     <version>1.5.3</version>
     <scope>compile</scope>
</dependency>

Damit verwendet das AspectJ-Plugin automatisch die korrekte Version auch zum Kompilieren.