Pat,
I usually use substitution groups for this, but you are right that you
can substitute a EmployeeIdentifier by a CoManagerIdentifier by using
xsi:type. This should also be supported by JAXB. One possible reason
why JAXB has problems with this could be the way the JAXBContext is
created. I'm not familiar with the JAXBRI databinding in Axis2, but I
had a look at the unit tests in Axis2 1.4 and it seems that in your
case the JAXBContext would be created as follows:
JAXBContext.newInstance(CreateCompany.class)
Can you verify this by looking at the generated code?
The problem I see with this is that since there is no direct link
between CreateCompany and CoManagerIdentifier (there is no way for
JAXB to discover the subclasses of EmployeeIdentifier), the
JAXBContext will not contain the metadata for CoManagerIdentifier.
This could explain why JAXB is unable to serialize instances of this
class correctly. A simple way to check is this is the root cause of
the problem would be to modify the generated code to add the
CoManagerIdentifier class:
JAXBContext.newInstance(CreateCompany.class, CoManagerIdentifier.class)
If this solves the problem than it is a bug in Axis2.
Regards,
Andreas
On 02 May 2008, at 10:55, patc wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
