AInsissams
New Member
I have a problem with a webservice, that runs on glassfish 3.1.1, but fails on glassfish 3.1.2.2\[code\]@XmlSeeAlso({B.class,BId.class,C.class,CId.class})public abstract class A {private Id id;}public abstract class Id {}public class B extends A {}public class C extends A {}public class BId extends Id {}public class CId extends Id {}\[/code\]class B get's a BId at runtime, C a CId.I have several other places, where I have abstract classes and the webservice serialization works just fine and I see a xsi:type qualifier in the generated xml. In this case however, no xsi:type qualifier is added and I get something like:\[code\]<a xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="B"> <id> ... </id> ...</a>\[/code\]So the unmarshalling can't identify the type of the id and tries to instantiate an abstract Id instead of a subclass.My best guess, is that this is a bug in eclipselink moxy that was added to glassfish 3.1.2 (but might be wrong about that)Anyone got an idea on how to work around this issue?I already tried adding more @XmlSeeAlso tags, but that didn't help.I also tried using @XmlRootElement and @XmlElementRef, but I couldn't get it to generate a getId() method on the generated Stubs for A. The webservice stubs I generate only had methodsgetBId and getCId on the class A, instead of a getId that returns the base type.