Nicht übereinstimmende Serialisierung UIDs, die in EJB-Remote-Methode - java.util.Datum & DBTimestamp
Ich habe ein java-web-Anwendung, die bereitgestellt wird, in zwei Ohren, eines für die UI-Schicht (enthält ein KRIEG-Modul) und eine für die business-Schicht (enthält ein EJB-Modul). Beide Stufen werden eingesetzt, um WebSphere Application Server 7. Die Ebenen sind verbunden über EJB 3.0 stateless session beans. Die Bohnen werden über JNDI gesucht.
Verwenden wir Hibernate für die Persistenz und eine DB2-Datenbank.
Wenn die remote-EJB-Aufruf zurückgegeben wird, tritt die folgende Fehlermeldung auf der client-Seite:
java.rmi.MarshalException: CORBA MARSHAL 0x4942f896 No; nested exception is:
org.omg.CORBA.MARSHAL: Unable to read value from underlying bridge : Mismatched serialization UIDs : Source (RepId RMI:java.util.Date:AC117E28FE36587A:686A81014B597419) = 686A81014B597419 whereas Target (RepId RMI:com.ibm.db2.jcc.DBTimestamp:AA774DBE96ECCE99:7AFCE1FB570D419C) = 7AFCE1FB570D419C vmcid: IBM minor code: 896 completed: No
Den java.util.Date
Feld auf das Objekt zurückgegeben wird von Hibernate als com.ibm.db2.jcc.DBTimestamp
Feld, die sich java.sql.Timestamp
erstreckt java.util.Date
. Wie es eine Unterklasse von java.util.Date
und serialisierbar ist, sollte dies nicht behandelt werden?
Ich gesprochen habe, um eine weitere Erfahrung, die person, die sagte, die wahrscheinlichste Ursache ist, dass die JVM-version oder DBTimestamp
- Klasse-version ist der Unterschied zwischen der web-und business-tier-WAR-Server. Beide Server haben den gleichen JVM, WAR-und JAR-version.
Ich habe auch ein Ort WAR 7 server, wo beide Ebenen sind auf demselben server bereitgestellt. Die EJBs sind immer noch aus der Ferne gelöst, die über einen JNDI Aufruf von localhost. Die Anwendung funktioniert gut auf meinem lokalen server. Der einzige Unterschied, den ich bewusst bin, ist eine andere micro-version WAR, sowie der Bereitstellung beider Reihen auf dem gleichen server.
Was ist die Ursache des Problems? Ist es, dass die DBTimestamp
Klasse nicht gefunden werden kann auf der web-Schicht, oder, dass die version der Klasse unterscheidet? Oder ist es ein Problem mit Polymorphie, oder etwas ganz anderes?
Abgesehen von einer Antwort, ich würde schätzen jede Beratung, was zu Debuggen, um zu versuchen - ich bin aus Ideen heraus.
Du musst angemeldet sein, um einen Kommentar abzugeben.
Ich es geschafft habe, zu "reparieren" das problem durch eine Verpackung den entsprechenden DB2-Treiber-JAR in das web-tier OHR.
Die Ursache für das problem ist daher, dass die Klasse nicht verfügbar war auf dem classpath der web-tier.
Ich werde untersuchen müssen, das setup der Umgebung, um herauszufinden, warum es nicht verfügbar ist, aber zumindest das problem ist jetzt klar.