Hi Andreas, thanks for the response
It is the JAXB generated classes that determine how types are
serialized/unserialized. We don't need to update the XML like you are
saying (with substitution groups) as the type classes (CoManagerIdentifier
and EmployeeIdentifier) are generated correctly, CoManagerIdentifier extends
EmployeeIdentifier.
I have managed to isolate the behaviour to a working/non working case. For
our original failing service request definition we had:
<xs:element name="CreateCompany">
<xs:complexType>
<xs:sequence>
<xs:element name="manager" type="EmployeeIdentifier"/>
</xs:sequence>
</xs:complexType>
</xs:element>
The JAXB class that represents the service request is generated as:
@XmlRootElement(name = "CreateCompany")
public class CreateCompany {
@XmlElement(required = true)
protected EmployeeIdentifier manager;
.....
.....
}
When we send a CoManagerIdentifier (which extends EmployeeIdentifier) the
message on the wire contains only EmployeeIdentifier information
(CoManagerIdentifier data is lost).
Now lets change the definition of the CreateCompany request. Let's make it
nillable and optional:
<xs:element name="CreateCompany">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" nillable="true" name="manager"
type="EmployeeIdentifier"/>
</xs:sequence>
</xs:complexType>
</xs:element>
The generated JAXB class is :
@XmlRootElement(name = "CreateCompany")
public class CreateCompany {
@XmlElementRef(name = "manager", type = JAXBElement.class)
protected JAXBElement<EmployeeIdentifier> manager;
.....
.....
}
As you can see the generated class contains now contains a
JAXBElement<EmployeeIdentifier> which works perfectly, marshaling the
CoManagerIdentifier correctly and preserving CoManagerIdentifier data when
putting the message on the wire.
There are 2 issues currently with the later, functioning, approach:
1) It only seems to work with one level of inheritance. If I had
TeamLeaderIdentifier that extended CoManagerIdentifier, the
TeamLeaderIdentifier does not seem to be marshalled correctly (behaviour
simillar to the first approach). This not a big issue for us at the moment.
2) The element data has to be nillable AND optional. Nillable is
workaroundable for us, but optional is a show stopper as we need some of our
inheritence hierarchy types (such as EmployeeIndentifier above) to be
mandatory fields.
This looks to all intents and purposes a bug to me. Why do I have to make
elements optional and nillable in order for subtypes to marshaled correctly?
Also why does it only work to one level of inheritence? Are these bugs in
JAXB or is it the AXIS2 generated JAXB classes that are causing the problem?
I still need to overcome problem 2) above. While the solution I have
outlined works for certain scenarios, it does not work for mine (need to
make elements optional). Anyone else overcome this problem, or have any
ideas I can make it work?
Any ideas gratefully received
Pat Considine
Andreas Veithen wrote:
>
> Pat,
>
> I think JAXB's behavior in your case is entirely correct. The reason
> is that the fact that the schema type CoManagerIdentifier extends
> EmployeeIdentifier does not mean that in your XML you can substitute
> an EmployeeIdentifier wherever a CoManagerIdentifier can appear. To
> allow this you need to use a substitution group in your schema. This
> is a fundamental difference between XML schema and OO languages such
> as Java, where extension always implies substitutability.
>
> Regards,
>
> Andreas
>
>
> On 29 Apr 2008, at 19:14, patc wrote:
>
>>
>>
>> Hi there
>>
>> I am encountering a problem involving Axis2 1.3 with JAXBRI
>> databinding when
>> dealing with subtypes (inherited types).
>>
>> I have a CoManagerIdentifier that is a subclass of
>> EmployeeIdentifier, and a
>> service request called createCompany (namespaces, etc. are left out to
>> reduce clutter):
>>
>> <xs:complexType name="EmployeeIdentifier">
>> ...
>> </xs:complexType>
>>
>> <xs:complexType name="CoManagerIdentifier">
>> <xs:complexContent>
>> <xs:extension base="EmployeeIdentifier">
>> <xs:sequence>
>> <xs:element name="dept" type="xs:string"/>
>>
>> </xs:sequence>
>> </xs:extension>
>> </xs:complexContent>
>> </xs:complexType>
>>
>> <wsdl:message name="createCompanyRequest">
>> <wsdl:part name="parameters" element="CreateCompany"/>
>> </wsdl:message>
>>
>> The CreateCompany request contains a CoManagerIdentifier:
>>
>> <xs:element name="CreateCompany">
>> <xs:complexType>
>> <xs:sequence>
>> <xs:element name="manager" type="CoManagerIdentifier"/>
>> </xs:sequence>
>> </xs:complexType>
>> </xs:element>
>>
>> If I execute the following code:
>>
>> CreateCompany companyRequest = new CreateCompany();
>> CoManagerIdentifier coManagerIdentifier = new CoManagerIdentifier();
>> coManagerIdentifier.setDept("TESTVAL");
>> companyRequest.setManager(coManagerIdentifier);
>> CreateCompanyResponse response = stub.createCompany(companyRequest);
>>
>> , the following message is sent on the wire from the client (minimised
>> actual SOAP message for clarity):
>>
>> <soapenv:Body>
>> <manager><dept>TESTVAL</dept></manager>
>> </soapenv:Body>
>>
>> , which is correct and exactly what you would expect.
>>
>> Now lets change the definition of the CreateCompany request to have a
>> manager type of EmployeeIdentifier (CoManagerIdentifier's parent).
>> Note, we
>> will still be dealing with CoManagerIdentifier at runtime:
>>
>> <xs:element name="CreateCompany">
>> <xs:complexType>
>> <xs:sequence>
>> <xs:element name="manager" type="EmployeeIdentifier"/>
>> </xs:sequence>
>> </xs:complexType>
>> </xs:element>
>>
>> If the above code is executed once again, the following is what is
>> sent on
>> the wire from the client:
>> <soapenv:Body>
>> <manager xmlns:ns4="http://com.namspace…...";
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>> xsi:type="ns4:EmployeeIdentifier" />
>> </soapenv:Body>
>>
>> Basically even though the runtime type is CoManagerIdentifier the SOAP
>> message is generated to have the type EmployeeIdentifier
>> (xsi:type="ns4:EmployeeIdentifier"). Thus the real type
>> CoManagerIdentifier
>> and it's attribute (dept with a value of "TESTVAL") is completely
>> ignored.
>>
>> This only seems to happen when making a client request. When
>> sending a
>> simillar response from the server (signature of response is the
>> parent type)
>> the marshaller is able to figure out that it needs to marshall the
>> sub type
>> (I can post a similar example if necessary).
>>
>> The code base I am using relies heavily on being able to send
>> inherited
>> types as part of service requests, so I really need a way of doing
>> this with
>> Axis2 and JAXB.
>>
>> Any help greatly appreciated…
>>
>> Pat Considine
>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/-Axis2--Sub-types-not-being-marshalled-correctly-tp16964278p16964278.html
>> Sent from the Axis - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/-Axis2--Sub-types-not-being-marshalled-correctly-tp16964278p17009977.html
Sent from the Axis - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
