Intermittierende classcastexception-Fehler aus ElementNSImpl zum eigenen Typ beim unmarshalling

Erleben wir eine überaus schwer aufzuspüren Problem, wo wir sehen ClassCastExceptions manchmal, wenn Sie versuchen zu iterieren über eine Liste von unmarshallt Objekte. Der wichtige Teil ist manchmal, nach einem Neustart ist der Quellcode funktioniert einwandfrei. Das scheint in die Richtung des concurrency - /timing - /race-Bedingung. Ich kann bestätigen, dass weder der JAXBContext, noch die marshallers und unmarshallers werden gleichzeitig verwendet. Wir haben so weit gegangen wie mit der Serialisierung der Zugang zu Ihnen durch sperren.

Jedoch, da wir auf eine OSGi-Plattform, wo die einzelnen Bündel sind immer initialisiert asynchron durch Spring DM kann es sein, dass 2 verschiedene bundles erstellen Ihre JAXBContext zur gleichen Zeit.

In jedem Fall, ich würde schätzen, irgendwelche Hinweise auf eine Erklärung für das, was könnte dazu führen, dass diese intermittierende ClassCastExceptions. Die intermittierende ist wichtig, da Sie zeigen, dass der code an sich ist der Regel funktioniert gut, aber, dass einige externe Faktor scheint Einfluss auf das Verhalten.

Hier ist ein konkretes Beispiel für die Ausnahme (Hinweis habe ich entfernt, das Unternehmen spezielle Sachen):

Caused by: java.lang.ClassCastException: com.sun.org.apache.xerces.internal.dom.ElementNSImpl cannot be cast to com.foobar.TunnelType
    at com.foobar.NetMonitorImpl.getVpnStatus(NetMonitorImpl.java:180)

Dass die Methode in Zeile 180 ist eine for () - Konstrukt Durchlaufen einer Sammlung von TunnelType Objekte, die sich innerhalb eines unmarshallt Objekt (sagte unmarshalling funktioniert gut, BTW).

Gegeben, dass das eigentliche Objekt unmarshalling gelaufen ist, ist es auch physisch möglich für JAXB zu verlassen ElementNSImpl Objekte innerhalb eines geschachtelten Kollektionen?

Runtime environment:

  • JAXB 2.1
  • OSGi
  • Spring DM
  • Der JAXBContext ist initialisiert mit dem ClassLoader des Bundles, das die Klassen enthält, umgewandelt werden/unmarshallt

InformationsquelleAutor Boris Terzic | 2008-12-18

  1. 4

    Bekomme ich diese Ausnahme NUR, wenn ich vergessen zu sagen JAXBContext
    über ALLE zu-sein-gemarshallt Arten könnte es zu tun haben.

    JAXBContext.newInstance(MyClass1.class,MyClass2.class, [...]);

    InformationsquelleAutor ivan_ivanovich_ivanoff

  2. 1

    Keiner der Ansätze die hier vorgeschlagen wird, hat es für mich. Allerdings ist diese gelöst, mein problem

    @XmlAnyElement(lax = true)
public List<Foo> foos;
    Dieser arbeitete für mich!

    InformationsquelleAutor Johan Sjöberg

  3. 0

    Aus der Verzweiflung wandten wir uns an die Synchronisation auf den JAXBContext.class Objekt, sehen dies als die einzige Verbleibende Möglichkeit für einige race-condition und wenigstens haben wir nicht in der Lage gewesen, um dieses Problem zu reproduzieren wieder. Hier ist der kritische code:

    synchronized (JAXBContext.class) {
    context = JAXBContext.newInstance(packageList, classLoader);
}

    InformationsquelleAutor Boris Terzic

  4. 0

    Die synchronized-Klausel oben aufgelöst das Problem für mich als gut, aber es scheint, wie der Kontext sollte nicht eine lokale variable. Stattdessen sollte es eine Instanz-variable oder ein statisches. Ich war nicht in der Lage umgestalten mein code, wie ich möchte, also statt ich zog den Kontext in einen statischen Initialisierer, der ist nicht perfekt, aber scheint zu funktionieren:

     private static Unmarshaller um;

  static{
    try {
      final JAXBContext ctx = JAXBContext.newInstance(ObjectFactory.class.getPackage().getName());
      um = ctx.createUnmarshaller();
    } catch (final JAXBException e) {
      e.printStackTrace();
    }
  }

    InformationsquelleAutor jon077

Schreibe einen Kommentar