Da hatte ich mir eine handvoll prima funktionierender, generischer Methoden zur Persistierung der Entities in eine stateless Bean geschraubt, um mit JUnit meine Mappings zu testen. Das sah dann zum Beispiel so aus:
public T getEntity(Class t, K k ) {
log.info("getEntity(" + t + ", " + k );
Object o = em.find(t, k);
@SuppressWarnings("unchecked")
T r = (T) o;
if ( r != null) {
em.refresh(r); // unbedingt nötig, damit OneToMany aktualisiert wird
}
return r;
}
Für den Einsatz in einer richtigen Anwendung war das aber zu unpraktisch und ließ keinen Raum für Geschäftslokik. Also wurde eine Facade gebaut:
public Xyz getXyz(final Integer xyzKey){
Xyz xyz = this.getEntity(Xyz.class,cargowrid);
... xyz geschäftlich bearbeiten ...
return xyz;
}
Prima! Es ging um ein Package mit ungefähr 50 Entities. Für jedes Entity Methoden fürs
- Einfügen
- Finden
- Ändern
- Löschen
macht zusammen 4 x 50 = 200 Methoden im Remote Interface. Einige Stunden Arbeit später fiel der Startschuss für die Wiederholung der inzwischen auch angepassten JUnit Tests.
Ich sollte hier erwähnen, dass meine JUnit Tests gegen das Remote Interface ausgeführt werden und bis vor dieser Neu-Ordnung prima funktionierten. Meine Überraschung war nicht gering, als ich das erste Ergebnis sah:
Testcase: testCargowWithCarseqInsert(ejb.TestPartnerServiceRemoteCargow): Caused an ERROR
-98
java.lang.ArrayIndexOutOfBoundsException: -98
at com.sun.corba.ee.impl.presentation.rmi.bcel.BCELStubBase.invoke(BCELStubBase.java:193)
at ejb.__PartnerServiceRemote_Remote_DynamicStub.finishSession(ejb/__PartnerServiceRemote_Remote_DynamicStub.java)
at ejb._PartnerServiceRemote_Wrapper.finishSession(ejb/_PartnerServiceRemote_Wrapper.java)
at ejb.TestPartnerServiceRemoteCargow.tearDown(TestPartnerServiceRemoteCargow.java:38)
Das ist doch ganz klar, um was es hier geht ... oder? Na - ich habe jedenfalls ungefähr eine Stunde gebraucht, um von der Fehlersuche in und am Glassfish Application Server abzulassen.
Um es kurz zu machen: Die Testanwendung, welche im Glassfish installiert ist und das Local Interface verwendet, hatte gar keine Probleme mit der neuen Facade. Also war mein JUnit Testaufbau kaputt? Hatte ich plötzlich falsche JARs am Wickel?
Eine Tasse Kaffee später ging mir ein Kronleuchter auf. Ich kommentierte 90% der Methoden im Remote Interface aus und suchte mir einen JUnit Tests, der mit dem Rest agierte aus: VOILA!
Die durch meinen Hang zur Ordnung hervorgerufene Inflation an Methoden im Remote Interface hatte eine Schallmauer durchbrochen, von deren Existenz ich nichts wusste. Meine anschliessende Suche nach der unsichtbaren Grenze blieb ohne Ergebnis. Wer weiß, wo man sowas nachlesen kann? Und, um es mit Torfrock zu sagen "Gibt es Leben auf anderen Planeten?" - also noch andere Limits, vor deren Überschreitung ich mich gern schützen würde?
Ich bin - um ehrlich zu sein - einfach nicht ehrgeizig genug, die nächsten Tage damit zu verbringen, nach diesen Grenzen zu suchen. Mein derzeitiger Auftraggeber ist auch nicht wirklich daran interessiert, Geld für diese Suche auszugeben.
.... aber irgendwie wurmt es mich doch, dass ich das alles noch nicht weiß!
Natürlich muss ich jetzt noch weiter aufräumen - neue Packages - neue Remote Interfaces - neue Lookups - neue Arbeit.
Schade - es war zu schön einfach.
Leider vermeldet die SUN Bug WebSite "Maintenance" ... also werde ich demnächst erfahren, ob es sich wirklich um einen Bug handelt oder lediglich die Exception mit besserer Diagnose Information ausgestattet wird.
Inzwischen heißt SUN jetzt ORACLE und die haben sich von diesem Bug völlig getrennt. Es lohnt sich also nicht mehr, auf den obigen Link zu klicken.
