We are faced with an extremely difficult task to track down a problem when we sometimes encounter ClassCastExceptions when trying to iterate over a list of unmarshalled objects. Sometimes an important bit, after a reboot, works correctly. This seems to be pointing in the direction of the concurrency / timing / race state. I can confirm that neither JAXBContext, nor marshalers and non-marshals are used at the same time. We got to serializing access to them through blocking.
However, since we run on the OSGi platform, where individual packages are initialized asynchronously via Spring DM, it may be that two different bundles create their own JAXBContext at the same time.
In any case, I would appreciate any pointers to an explanation of what these intermittent ClassCastExceptions might cause. Intermittent is important, as they indicate that the code itself works fine, but something affects the behavior of some external factor.
Here is a specific example of an exception (note that I removed the specifics of the company):
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)
This method on line 180 is a for () construct that loops over Collection TunnelType objects inside an object without marshalling (BTW works fine with unmarshalling).
Given that the actual unmarshalling of the object went fine, is it even physically possible for JAXB to leave ElementNSImpl objects inside nested collections?
Runtime environment:
- JAXB 2.1
- OSGi
- Spring dm
- JAXBContext is initialized with a ClassLoader package containing classes to be ordered / unmarshalled
java exception race-condition jaxb unmarshalling
Boris Terzic
source share