You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by patc <pa...@fineos.com> on 2008/04/29 19:14:25 UTC
[Axis2] Sub-types not being marshalled correctly
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: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
[Axis2] Client
Posted by Arlindo Luis Marcon Junior <ar...@gmail.com>.
Hi All...
Someone, maybe, know how many clients the Axis2 can attend at same time?
It depends on the resources of the computer,,, the "server" ( like
memory, processor, and so on )...
Axis2 has some configuration about?
Any clue is welcome...
Thanks in Advance...
--
Arlindo Luis Marcon Junior
E-mail: arlindomarconjr@gmail.com
Internet Web Page: http://lattes.cnpq.br/6483462042489662
ICQ: 138864173
Curitiba - Paraná - Brasil
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: [Axis2] Sub-types not being marshalled correctly
Posted by Andreas Veithen <an...@skynet.be>.
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: axis-user-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>
>>
>>
>
> --
> 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: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: [Axis2] Sub-types not being marshalled correctly
Posted by patc <pa...@fineos.com>.
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: axis-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-user-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
>
>
--
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: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org
Re: [Axis2] Sub-types not being marshalled correctly
Posted by Andreas Veithen <an...@skynet.be>.
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: axis-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-user-help@ws.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-user-help@ws.apache.org