Heute erreichte mich die Exception java.rmi.NoSuchObjectException mit der Meldung “No such object in table”. Diese Meldung habe ich zuerst nicht ganz verstanden, denn der Client hat ja zuvor über Lookup das Objekt erfolgreich geholt. Dennoch trat anschließend bei der Verwendung diese Meldung auf.
Das Problem ist jedoch so einfach wie zugleich auch etwas versteckt. Bei einem Lookup des Clients erfolgt dies auf die RMI-Registry. Diese hält die Stubs bereit und bei einem Lookup erhält der Client Informationen wie er zum eigentlichen Remote-Objekt gelangt. Der Lookup war also kein Problem. Bei der ersten Verwendung des erhaltenen Objektes wird nun eine Verbindung zum RMI-Server aufgebaut und dann das Remote-Objekt verwendet. Dies war jetzt nicht mehr da und damit kam es zu dieser Meldung. Aber warum war es nicht mehr da? Ganz einfach: Der Garbage Collector hatte es aus dem Speicher entfernt.
Die Lösung ist daher, dass die Instanz, die beim Erzeugen des UniCastRemoteObjects verwendet wird, mit gehalten werden muß, damit diese nicht vom GC entfernt wird.

RMI ist ja das Werkzeug schlechthin um verschiedene Javaprozesse miteinander kommunizieren zu lassen. Es können damit entfernte Methoden aufgerufen (Remote Method Invocation) werden, als wäre die Klasse lokal verfügbar. Da sich Java selbst um die ganze Kommunikation über TCP kümmert, hat man natürlich wenig Einflussmöglichkeiten. Betreibt man nun einen RMI-Server hinter einem NAT-Router und möchte diesen vom Internet aus zugreifbar machen, so wird einem immer wieder auf Clientseite eine Exception um die Ohren fliegen, die sagt dass das Netzwerk mit z.B. der IP 192.168.x.x nicht verfügbar wäre. Grund hierfür ist, dass der RMI-Server seine lokale IP nach außen sendet und nicht seine globale IP. Abhilfe schafft hier der Start der Applikation mit einem Parameter:

java -Djava.rmi.server.hostname=GLOBALEIP ...

Ab jetzt sendet der Server die globale IP als Hostnamen und ein Zugriff von Außerhalb ist problemlos möglich.

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.

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.

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.

Wie bereits bei Caching von EJB3 EntityBeans geschrieben, können diese im JBoss gecached werden. Zusätzlich ist es auch möglich häufige Datenbankabfragen zu cachen. Wenn man den JBoss und seine persistence.xml gemäß der Anleitung ist automatisch alles für das Caching von Abfragen eingestellt.
Jetzt muss bei einer Abfrage lediglich das Attribute CacheAble gesetzt werden:

Criteria crit = session.createCriteria(Entity.class);
crit.setCacheable(true);

Zusätzlich kann auch noch mit setCacheRegion die CacheRegion im TreeCache gesetzt werden.
Bei der Verwendung von ResultTransformer muss noch die Referenz beachtet werden. Der Transformer wird als Parameter mit verwendet und muss für ein erfolgreiches Caching daher immer der Gleiche sein. Unter dem Interface “Criteria” werden verschiedene Transformer angeboten. Z.B. unter Criteria.DISTINCT_ROOT_ENTITY der DistinctRootEntityResultTransformer.

In der pom.xml-Datei können natürlich auch die vorhandenen Plugins entsprechend konfiguriert werden. Dies geschieht an folgender Stelle:

<project>
  …
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>

        <artifactId>maven-compiler-plugin</artifactId>
        <version>2.0</version>
        <configuration>
          <source>1.5</source>
          <target>1.5</target>
        </configuration>
      </plugin>
    </plugins>

  </build>
  …
</project>

Im Beispiel wird das Compiler-Plugin konfiguriert, welches Java-Dateien im Projekt kompiliert. Es wird z.B. das Source-Level auf 1.5 gesetzt, damit auch Annotations verwendet werden können.
Die Parameterbeschreibungen sind auf der einen Seite teileweise bei Apache.org verfügbar, können jedoch mit Hilfe eines sehr interessanten Plugins auch direkt abgefragt werden. (weiterlesen…)

Wichtig bei der Verwendung von Beziehungen unter Entitäten bei Hibernate ist die korrekte Definition wer Parent und wer Child ist. Davon abhängig ist, wie und wer die Beziehung in der Datenbank gepflegt wird und welche SQL-Statements ausgeführt werden.
Parents pflegen dabei die Beziehung in der Datenbank und Childs müssen lediglich in den Valueobjekten gepflegt werden.
Wir haben z.B. eine Klasse A, welche eine 1:m Beziehung zu B hat. Das heißt jedes B hat genau ein A, aber ein A kann bei mehreren B genutzt werden.
Dies sieht dann ungefähr so aus:
(weiterlesen…)

Da man ja in der Regel nicht mit einem einfachen Editor wild auf einem Projektverzeichnis herum editieren möchte, sondern lieber eine komfortable IDE verwendet, stellt sich die Frage nach der Unterstütztung von Maven in den bekannten IDEs IntelliJ Idea, NetBeans oder Eclipse.
(weiterlesen…)

Maven 2 verfolgt mit Ant einen nahezu gleichen Ansatz. Es soll die Erstellung eines Projektes unterstützt werden. Maven jedoch bietet darüber hinaus noch ein wesentlich umfassenderes Konzept mit an. Das Konzept beinhaltet die Verwaltung mehrerer Module und deren Version sowie Abhängigkeiten und hat als Ziel nicht nur die Erstellung von Binärdateien sondern auch von Dokumentationen oder beliebigen anderen Dateien.
(weiterlesen…)