You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by immutability <de...@bielik.org> on 2009/03/09 10:56:09 UTC
xsi:type missing in returned value
Hello everyone - I'm new to webservices in Java, so my issue may be some
trivial, but I've had a hard time trying to figure this out. I've been
playing with CXF for a while, and I've created a simple web service to test
integration with spring.
It all seems to be working fine, but what I need to do is make this
compatible with older versions of client applications which are using
org.apache.soap to talk to the service. Currently, these applications can
properly call methods of my webservice, but fail to parse the returned
response, possibly due to the missing xsi:type attribute. My testing service
is currently very simple and contains a single method "login" accepting 2
string parameters username and password:
@WebService
public interface HelloService
{
boolean login(
@WebParam(name = "username")
String username,
@WebParam(name = "password")
String password);
}
The JAX-WS endpoint is defined in my spring XML.
The SOAP response looks like this:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<ns1:loginResponse xmlns:ns1="urn:soap-interface">
<return>true</return>
</ns1:loginResponse>
</soap:Body>
</soap:Envelope>
It looks like the clients expect the following:
<return xsi:type="xsd:boolean">false</return>
Is there a way for me to make CXF add the xsi:type attribute to the return
value somehow? Am I doing something wrong here, or do I need to use some
annotation to make it use the xsi:type?
Again, I apologize if this is something stupid, I'm still learning. Thanks
for any clues in advance!
Rado
--
View this message in context: http://www.nabble.com/xsi%3Atype-missing-in-returned-value-tp22410060p22410060.html
Sent from the cxf-user mailing list archive at Nabble.com.
AW: AW: xsi:type missing in returned value
Posted by Oliver Wulff <ow...@progress.com>.
Rado,
do you have a wsdl with an rpc/encoded binding?
-----Ursprüngliche Nachricht-----
Von: immutability [mailto:devlists@bielik.org]
Gesendet: Mo 16.03.2009 21:07
An: users@cxf.apache.org
Betreff: Re: AW: xsi:type missing in returned value
Thank you for both of your responses,
Chris: I've already tried using Aegis instead of JAXB, configured with
readXsiTypes and writeXsiTypes both set to true - with no effect on the
<return> value.
Dan: I guess I'll just have to stick to the old org.apache.soap
implementation for backward compatibility. :( I already spent too much time
trying to make CXF write the xsi:type.
Thanks,
Rado
Christofer Dutz-4 wrote:
>
> Hi,
>
> I am using Aegis data binding and here there are two parameters to control
> this
>
> <bean id="aegisContext" class="org.apache.cxf.aegis.AegisContext"
> scope="prototype">
> <property name="readXsiTypes" value="true"/>
> <property name="writeXsiTypes" value="true"/>
> ....
> </bean>
>
> If you are not bound to using jaxb, maybe just give Aegis a try.
>
> Chris
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Daniel Kulp [mailto:dkulp@apache.org]
> Gesendet: Freitag, 13. März 2009 20:47
> An: users@cxf.apache.org
> Cc: immutability
> Betreff: Re: xsi:type missing in returned value
>
>
> In general, jaxb and aegis only write the xsi:type when it's actually
> needed.
> Basically, if the xsi:type is identical to what the schema says it would
> be,
>
> it doesn't write it out. I don't think there is a way to force it
> either.
>
> Dan
>
>
> On Fri March 13 2009 3:14:25 pm immutability wrote:
>> Any clues, anyone? I've been struggling with this for too long now, read
>> all possible and impossible forum posts, bug reports, etc. (the positive
>> side of this is that I have a much better understanding of web services
>> now) ;)
>>
>> I've also tried to use Aegis instead of JAXB (with both JAX-WS and the
>> Simple frontend), and set the writeXsiTypes and readXsiTypes properties
>> of
>> the aegis context to "true" but I still don't get the xsi:type on the
>> returned value.
>>
>> I think the question here is if my expectation is correct: should I have
>> the xsi:type with my current configuration in the <return> element or
>> not?
>> If not, can I somehow get it there?
>>
>> Thanks,
>> Rado
>>
>> immutability wrote:
>> > Hello everyone - I'm new to webservices in Java, so my issue may be
>> some
>> > trivial, but I've had a hard time trying to figure this out. I've been
>> > playing with CXF for a while, and I've created a simple web service to
>> > test integration with spring.
>> >
>> > It all seems to be working fine, but what I need to do is make this
>> > compatible with older versions of client applications which are using
>> > org.apache.soap to talk to the service. Currently, these applications
> can
>> > properly call methods of my webservice, but fail to parse the returned
>> > response, possibly due to the missing xsi:type attribute. My testing
>> > service is currently very simple and contains a single method "login"
>> > accepting 2 string parameters username and password:
>> >
>> > @WebService
>> > public interface HelloService
>> > {
>> > boolean login(
>> > @WebParam(name = "username")
>> > String username,
>> > @WebParam(name = "password")
>> > String password);
>> > }
>> >
>> > The JAX-WS endpoint is defined in my spring XML.
>> >
>> > The SOAP response looks like this:
>> >
>> > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
>> > <soap:Body>
>> > <ns1:loginResponse xmlns:ns1="urn:soap-interface">
>> > <return>true</return>
>> > </ns1:loginResponse>
>> > </soap:Body>
>> > </soap:Envelope>
>> >
>> > It looks like the clients expect the following:
>> > <return xsi:type="xsd:boolean">false</return>
>> >
>> > Is there a way for me to make CXF add the xsi:type attribute to the
>> > return value somehow? Am I doing something wrong here, or do I need to
>> > use some annotation to make it use the xsi:type?
>> >
>> > Again, I apologize if this is something stupid, I'm still learning.
>> > Thanks for any clues in advance!
>> >
>> > Rado
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
>
> __________ Hinweis von ESET NOD32 Antivirus, Signaturdatenbank-Version
> 3938
> (20090316) __________
>
> E-Mail wurde geprüft mit ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
> __________ Hinweis von ESET NOD32 Antivirus, Signaturdatenbank-Version
> 3938
> (20090316) __________
>
> E-Mail wurde geprüft mit ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
>
--
View this message in context: http://www.nabble.com/xsi%3Atype-missing-in-returned-value-tp22410060p22544885.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: AW: AW: xsi:type missing in returned value
Posted by immutability <de...@bielik.org>.
Chris, thank you for your response, and for your tutorial too, it is an
excellent resource. I was playing with CXF/Aegis a bit more, but just
couldn't make it output the xsi:type for primitive types, such as boolean.
By explicitly listing the classes, as you suggested, it worked for complex
type (i.e. when a web method was returning one of my classes).
For now I just decided to use the old org.apache.soap library (soap.jar) to
get moving with the project, as this will produce exactly the kind of output
our existing applications need. I'll probably re-visit CXF later.
Thanks again,
Rado
Christofer Dutz-4 wrote:
>
> Hi Rado,
>
> I think you might have to list the classes, you want Aegis to handle like
> this.
> I have documented all I did in my confluence under:
> http://dev.c-ware.de/confluence/display/PUBLIC/Seting+up+Flex+to+communicate+with+Apache+CXF+web+service+using+Aegis+databinding
>
> I used Aegis, because I have multiple different implementations of one
> abstract base class I want to use in my webservice. For this you have to
> make sure Aegis outputs the type, reads and reads the type. Additionally
> you have to register all classes that could be candidates for reading and
> writing. So maybe this was the thing I forgot to mention ;)
>
> Hope this and my tutorial helps you.
>
> Would really appreciate some feedback ;-)
>
> Chris
>
> -----Ursprüngliche Nachricht-----
> Von: immutability [mailto:devlists@bielik.org]
> Gesendet: Montag, 16. März 2009 21:08
> An: users@cxf.apache.org
> Betreff: Re: AW: xsi:type missing in returned value
>
>
> Thank you for both of your responses,
>
> Chris: I've already tried using Aegis instead of JAXB, configured with
> readXsiTypes and writeXsiTypes both set to true - with no effect on the
> <return> value.
>
> Dan: I guess I'll just have to stick to the old org.apache.soap
> implementation for backward compatibility. :( I already spent too much
> time
> trying to make CXF write the xsi:type.
>
> Thanks,
> Rado
>
>
>
> Christofer Dutz-4 wrote:
>>
>> Hi,
>>
>> I am using Aegis data binding and here there are two parameters to
>> control
>> this
>>
>> <bean id="aegisContext" class="org.apache.cxf.aegis.AegisContext"
>> scope="prototype">
>> <property name="readXsiTypes" value="true"/>
>> <property name="writeXsiTypes" value="true"/>
>> ....
>> </bean>
>>
>> If you are not bound to using jaxb, maybe just give Aegis a try.
>>
>> Chris
>>
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Daniel Kulp [mailto:dkulp@apache.org]
>> Gesendet: Freitag, 13. März 2009 20:47
>> An: users@cxf.apache.org
>> Cc: immutability
>> Betreff: Re: xsi:type missing in returned value
>>
>>
>> In general, jaxb and aegis only write the xsi:type when it's actually
>> needed.
>> Basically, if the xsi:type is identical to what the schema says it would
>> be,
>>
>> it doesn't write it out. I don't think there is a way to force it
>> either.
>>
>> Dan
>>
>>
>> On Fri March 13 2009 3:14:25 pm immutability wrote:
>>> Any clues, anyone? I've been struggling with this for too long now, read
>>> all possible and impossible forum posts, bug reports, etc. (the positive
>>> side of this is that I have a much better understanding of web services
>>> now) ;)
>>>
>>> I've also tried to use Aegis instead of JAXB (with both JAX-WS and the
>>> Simple frontend), and set the writeXsiTypes and readXsiTypes properties
>>> of
>>> the aegis context to "true" but I still don't get the xsi:type on the
>>> returned value.
>>>
>>> I think the question here is if my expectation is correct: should I have
>>> the xsi:type with my current configuration in the <return> element or
>>> not?
>>> If not, can I somehow get it there?
>>>
>>> Thanks,
>>> Rado
>>>
>>> immutability wrote:
>>> > Hello everyone - I'm new to webservices in Java, so my issue may be
>>> some
>>> > trivial, but I've had a hard time trying to figure this out. I've been
>>> > playing with CXF for a while, and I've created a simple web service to
>>> > test integration with spring.
>>> >
>>> > It all seems to be working fine, but what I need to do is make this
>>> > compatible with older versions of client applications which are using
>>> > org.apache.soap to talk to the service. Currently, these applications
>> can
>>> > properly call methods of my webservice, but fail to parse the returned
>>> > response, possibly due to the missing xsi:type attribute. My testing
>>> > service is currently very simple and contains a single method "login"
>>> > accepting 2 string parameters username and password:
>>> >
>>> > @WebService
>>> > public interface HelloService
>>> > {
>>> > boolean login(
>>> > @WebParam(name = "username")
>>> > String username,
>>> > @WebParam(name = "password")
>>> > String password);
>>> > }
>>> >
>>> > The JAX-WS endpoint is defined in my spring XML.
>>> >
>>> > The SOAP response looks like this:
>>> >
>>> > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
>>> > <soap:Body>
>>> > <ns1:loginResponse xmlns:ns1="urn:soap-interface">
>>> > <return>true</return>
>>> > </ns1:loginResponse>
>>> > </soap:Body>
>>> > </soap:Envelope>
>>> >
>>> > It looks like the clients expect the following:
>>> > <return xsi:type="xsd:boolean">false</return>
>>> >
>>> > Is there a way for me to make CXF add the xsi:type attribute to the
>>> > return value somehow? Am I doing something wrong here, or do I need to
>>> > use some annotation to make it use the xsi:type?
>>> >
>>> > Again, I apologize if this is something stupid, I'm still learning.
>>> > Thanks for any clues in advance!
>>> >
>>> > Rado
>>
>> --
>> Daniel Kulp
>> dkulp@apache.org
>> http://www.dankulp.com/blog
>>
>>
>> __________ Hinweis von ESET NOD32 Antivirus, Signaturdatenbank-Version
>> 3938
>> (20090316) __________
>>
>> E-Mail wurde geprüft mit ESET NOD32 Antivirus.
>>
>> http://www.eset.com
>>
>>
>>
>> __________ Hinweis von ESET NOD32 Antivirus, Signaturdatenbank-Version
>> 3938
>> (20090316) __________
>>
>> E-Mail wurde geprüft mit ESET NOD32 Antivirus.
>>
>> http://www.eset.com
>>
>>
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/xsi%3Atype-missing-in-returned-value-tp22410060p22544885.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
>
>
> __________ Hinweis von ESET NOD32 Antivirus, Signaturdatenbank-Version
> 3941 (20090317) __________
>
> E-Mail wurde geprüft mit ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
> __________ Hinweis von ESET NOD32 Antivirus, Signaturdatenbank-Version
> 3941 (20090317) __________
>
> E-Mail wurde geprüft mit ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
>
--
View this message in context: http://www.nabble.com/xsi%3Atype-missing-in-returned-value-tp22410060p22669886.html
Sent from the cxf-user mailing list archive at Nabble.com.
AW: AW: xsi:type missing in returned value
Posted by Christofer Dutz <c....@upw.de>.
Hi Rado,
I think you might have to list the classes, you want Aegis to handle like this.
I have documented all I did in my confluence under:
http://dev.c-ware.de/confluence/display/PUBLIC/Seting+up+Flex+to+communicate+with+Apache+CXF+web+service+using+Aegis+databinding
I used Aegis, because I have multiple different implementations of one abstract base class I want to use in my webservice. For this you have to make sure Aegis outputs the type, reads and reads the type. Additionally you have to register all classes that could be candidates for reading and writing. So maybe this was the thing I forgot to mention ;)
Hope this and my tutorial helps you.
Would really appreciate some feedback ;-)
Chris
-----Ursprüngliche Nachricht-----
Von: immutability [mailto:devlists@bielik.org]
Gesendet: Montag, 16. März 2009 21:08
An: users@cxf.apache.org
Betreff: Re: AW: xsi:type missing in returned value
Thank you for both of your responses,
Chris: I've already tried using Aegis instead of JAXB, configured with
readXsiTypes and writeXsiTypes both set to true - with no effect on the
<return> value.
Dan: I guess I'll just have to stick to the old org.apache.soap
implementation for backward compatibility. :( I already spent too much time
trying to make CXF write the xsi:type.
Thanks,
Rado
Christofer Dutz-4 wrote:
>
> Hi,
>
> I am using Aegis data binding and here there are two parameters to control
> this
>
> <bean id="aegisContext" class="org.apache.cxf.aegis.AegisContext"
> scope="prototype">
> <property name="readXsiTypes" value="true"/>
> <property name="writeXsiTypes" value="true"/>
> ....
> </bean>
>
> If you are not bound to using jaxb, maybe just give Aegis a try.
>
> Chris
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Daniel Kulp [mailto:dkulp@apache.org]
> Gesendet: Freitag, 13. März 2009 20:47
> An: users@cxf.apache.org
> Cc: immutability
> Betreff: Re: xsi:type missing in returned value
>
>
> In general, jaxb and aegis only write the xsi:type when it's actually
> needed.
> Basically, if the xsi:type is identical to what the schema says it would
> be,
>
> it doesn't write it out. I don't think there is a way to force it
> either.
>
> Dan
>
>
> On Fri March 13 2009 3:14:25 pm immutability wrote:
>> Any clues, anyone? I've been struggling with this for too long now, read
>> all possible and impossible forum posts, bug reports, etc. (the positive
>> side of this is that I have a much better understanding of web services
>> now) ;)
>>
>> I've also tried to use Aegis instead of JAXB (with both JAX-WS and the
>> Simple frontend), and set the writeXsiTypes and readXsiTypes properties
>> of
>> the aegis context to "true" but I still don't get the xsi:type on the
>> returned value.
>>
>> I think the question here is if my expectation is correct: should I have
>> the xsi:type with my current configuration in the <return> element or
>> not?
>> If not, can I somehow get it there?
>>
>> Thanks,
>> Rado
>>
>> immutability wrote:
>> > Hello everyone - I'm new to webservices in Java, so my issue may be
>> some
>> > trivial, but I've had a hard time trying to figure this out. I've been
>> > playing with CXF for a while, and I've created a simple web service to
>> > test integration with spring.
>> >
>> > It all seems to be working fine, but what I need to do is make this
>> > compatible with older versions of client applications which are using
>> > org.apache.soap to talk to the service. Currently, these applications
> can
>> > properly call methods of my webservice, but fail to parse the returned
>> > response, possibly due to the missing xsi:type attribute. My testing
>> > service is currently very simple and contains a single method "login"
>> > accepting 2 string parameters username and password:
>> >
>> > @WebService
>> > public interface HelloService
>> > {
>> > boolean login(
>> > @WebParam(name = "username")
>> > String username,
>> > @WebParam(name = "password")
>> > String password);
>> > }
>> >
>> > The JAX-WS endpoint is defined in my spring XML.
>> >
>> > The SOAP response looks like this:
>> >
>> > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
>> > <soap:Body>
>> > <ns1:loginResponse xmlns:ns1="urn:soap-interface">
>> > <return>true</return>
>> > </ns1:loginResponse>
>> > </soap:Body>
>> > </soap:Envelope>
>> >
>> > It looks like the clients expect the following:
>> > <return xsi:type="xsd:boolean">false</return>
>> >
>> > Is there a way for me to make CXF add the xsi:type attribute to the
>> > return value somehow? Am I doing something wrong here, or do I need to
>> > use some annotation to make it use the xsi:type?
>> >
>> > Again, I apologize if this is something stupid, I'm still learning.
>> > Thanks for any clues in advance!
>> >
>> > Rado
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
>
> __________ Hinweis von ESET NOD32 Antivirus, Signaturdatenbank-Version
> 3938
> (20090316) __________
>
> E-Mail wurde geprüft mit ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
> __________ Hinweis von ESET NOD32 Antivirus, Signaturdatenbank-Version
> 3938
> (20090316) __________
>
> E-Mail wurde geprüft mit ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
>
--
View this message in context: http://www.nabble.com/xsi%3Atype-missing-in-returned-value-tp22410060p22544885.html
Sent from the cxf-user mailing list archive at Nabble.com.
__________ Hinweis von ESET NOD32 Antivirus, Signaturdatenbank-Version 3941 (20090317) __________
E-Mail wurde geprüft mit ESET NOD32 Antivirus.
http://www.eset.com
__________ Hinweis von ESET NOD32 Antivirus, Signaturdatenbank-Version 3941 (20090317) __________
E-Mail wurde geprüft mit ESET NOD32 Antivirus.
http://www.eset.com
Re: AW: xsi:type missing in returned value
Posted by immutability <de...@bielik.org>.
Thank you for both of your responses,
Chris: I've already tried using Aegis instead of JAXB, configured with
readXsiTypes and writeXsiTypes both set to true - with no effect on the
<return> value.
Dan: I guess I'll just have to stick to the old org.apache.soap
implementation for backward compatibility. :( I already spent too much time
trying to make CXF write the xsi:type.
Thanks,
Rado
Christofer Dutz-4 wrote:
>
> Hi,
>
> I am using Aegis data binding and here there are two parameters to control
> this
>
> <bean id="aegisContext" class="org.apache.cxf.aegis.AegisContext"
> scope="prototype">
> <property name="readXsiTypes" value="true"/>
> <property name="writeXsiTypes" value="true"/>
> ....
> </bean>
>
> If you are not bound to using jaxb, maybe just give Aegis a try.
>
> Chris
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Daniel Kulp [mailto:dkulp@apache.org]
> Gesendet: Freitag, 13. März 2009 20:47
> An: users@cxf.apache.org
> Cc: immutability
> Betreff: Re: xsi:type missing in returned value
>
>
> In general, jaxb and aegis only write the xsi:type when it's actually
> needed.
> Basically, if the xsi:type is identical to what the schema says it would
> be,
>
> it doesn't write it out. I don't think there is a way to force it
> either.
>
> Dan
>
>
> On Fri March 13 2009 3:14:25 pm immutability wrote:
>> Any clues, anyone? I've been struggling with this for too long now, read
>> all possible and impossible forum posts, bug reports, etc. (the positive
>> side of this is that I have a much better understanding of web services
>> now) ;)
>>
>> I've also tried to use Aegis instead of JAXB (with both JAX-WS and the
>> Simple frontend), and set the writeXsiTypes and readXsiTypes properties
>> of
>> the aegis context to "true" but I still don't get the xsi:type on the
>> returned value.
>>
>> I think the question here is if my expectation is correct: should I have
>> the xsi:type with my current configuration in the <return> element or
>> not?
>> If not, can I somehow get it there?
>>
>> Thanks,
>> Rado
>>
>> immutability wrote:
>> > Hello everyone - I'm new to webservices in Java, so my issue may be
>> some
>> > trivial, but I've had a hard time trying to figure this out. I've been
>> > playing with CXF for a while, and I've created a simple web service to
>> > test integration with spring.
>> >
>> > It all seems to be working fine, but what I need to do is make this
>> > compatible with older versions of client applications which are using
>> > org.apache.soap to talk to the service. Currently, these applications
> can
>> > properly call methods of my webservice, but fail to parse the returned
>> > response, possibly due to the missing xsi:type attribute. My testing
>> > service is currently very simple and contains a single method "login"
>> > accepting 2 string parameters username and password:
>> >
>> > @WebService
>> > public interface HelloService
>> > {
>> > boolean login(
>> > @WebParam(name = "username")
>> > String username,
>> > @WebParam(name = "password")
>> > String password);
>> > }
>> >
>> > The JAX-WS endpoint is defined in my spring XML.
>> >
>> > The SOAP response looks like this:
>> >
>> > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
>> > <soap:Body>
>> > <ns1:loginResponse xmlns:ns1="urn:soap-interface">
>> > <return>true</return>
>> > </ns1:loginResponse>
>> > </soap:Body>
>> > </soap:Envelope>
>> >
>> > It looks like the clients expect the following:
>> > <return xsi:type="xsd:boolean">false</return>
>> >
>> > Is there a way for me to make CXF add the xsi:type attribute to the
>> > return value somehow? Am I doing something wrong here, or do I need to
>> > use some annotation to make it use the xsi:type?
>> >
>> > Again, I apologize if this is something stupid, I'm still learning.
>> > Thanks for any clues in advance!
>> >
>> > Rado
>
> --
> Daniel Kulp
> dkulp@apache.org
> http://www.dankulp.com/blog
>
>
> __________ Hinweis von ESET NOD32 Antivirus, Signaturdatenbank-Version
> 3938
> (20090316) __________
>
> E-Mail wurde geprüft mit ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
> __________ Hinweis von ESET NOD32 Antivirus, Signaturdatenbank-Version
> 3938
> (20090316) __________
>
> E-Mail wurde geprüft mit ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
>
--
View this message in context: http://www.nabble.com/xsi%3Atype-missing-in-returned-value-tp22410060p22544885.html
Sent from the cxf-user mailing list archive at Nabble.com.
AW: xsi:type missing in returned value
Posted by Christofer Dutz <c....@upw.de>.
Hi,
I am using Aegis data binding and here there are two parameters to control
this
<bean id="aegisContext" class="org.apache.cxf.aegis.AegisContext"
scope="prototype">
<property name="readXsiTypes" value="true"/>
<property name="writeXsiTypes" value="true"/>
....
</bean>
If you are not bound to using jaxb, maybe just give Aegis a try.
Chris
-----Ursprüngliche Nachricht-----
Von: Daniel Kulp [mailto:dkulp@apache.org]
Gesendet: Freitag, 13. März 2009 20:47
An: users@cxf.apache.org
Cc: immutability
Betreff: Re: xsi:type missing in returned value
In general, jaxb and aegis only write the xsi:type when it's actually
needed.
Basically, if the xsi:type is identical to what the schema says it would be,
it doesn't write it out. I don't think there is a way to force it either.
Dan
On Fri March 13 2009 3:14:25 pm immutability wrote:
> Any clues, anyone? I've been struggling with this for too long now, read
> all possible and impossible forum posts, bug reports, etc. (the positive
> side of this is that I have a much better understanding of web services
> now) ;)
>
> I've also tried to use Aegis instead of JAXB (with both JAX-WS and the
> Simple frontend), and set the writeXsiTypes and readXsiTypes properties of
> the aegis context to "true" but I still don't get the xsi:type on the
> returned value.
>
> I think the question here is if my expectation is correct: should I have
> the xsi:type with my current configuration in the <return> element or not?
> If not, can I somehow get it there?
>
> Thanks,
> Rado
>
> immutability wrote:
> > Hello everyone - I'm new to webservices in Java, so my issue may be some
> > trivial, but I've had a hard time trying to figure this out. I've been
> > playing with CXF for a while, and I've created a simple web service to
> > test integration with spring.
> >
> > It all seems to be working fine, but what I need to do is make this
> > compatible with older versions of client applications which are using
> > org.apache.soap to talk to the service. Currently, these applications
can
> > properly call methods of my webservice, but fail to parse the returned
> > response, possibly due to the missing xsi:type attribute. My testing
> > service is currently very simple and contains a single method "login"
> > accepting 2 string parameters username and password:
> >
> > @WebService
> > public interface HelloService
> > {
> > boolean login(
> > @WebParam(name = "username")
> > String username,
> > @WebParam(name = "password")
> > String password);
> > }
> >
> > The JAX-WS endpoint is defined in my spring XML.
> >
> > The SOAP response looks like this:
> >
> > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
> > <soap:Body>
> > <ns1:loginResponse xmlns:ns1="urn:soap-interface">
> > <return>true</return>
> > </ns1:loginResponse>
> > </soap:Body>
> > </soap:Envelope>
> >
> > It looks like the clients expect the following:
> > <return xsi:type="xsd:boolean">false</return>
> >
> > Is there a way for me to make CXF add the xsi:type attribute to the
> > return value somehow? Am I doing something wrong here, or do I need to
> > use some annotation to make it use the xsi:type?
> >
> > Again, I apologize if this is something stupid, I'm still learning.
> > Thanks for any clues in advance!
> >
> > Rado
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
__________ Hinweis von ESET NOD32 Antivirus, Signaturdatenbank-Version 3938
(20090316) __________
E-Mail wurde geprüft mit ESET NOD32 Antivirus.
http://www.eset.com
__________ Hinweis von ESET NOD32 Antivirus, Signaturdatenbank-Version 3938
(20090316) __________
E-Mail wurde geprüft mit ESET NOD32 Antivirus.
http://www.eset.com
Re: xsi:type missing in returned value
Posted by Daniel Kulp <dk...@apache.org>.
In general, jaxb and aegis only write the xsi:type when it's actually needed.
Basically, if the xsi:type is identical to what the schema says it would be,
it doesn't write it out. I don't think there is a way to force it either.
Dan
On Fri March 13 2009 3:14:25 pm immutability wrote:
> Any clues, anyone? I've been struggling with this for too long now, read
> all possible and impossible forum posts, bug reports, etc. (the positive
> side of this is that I have a much better understanding of web services
> now) ;)
>
> I've also tried to use Aegis instead of JAXB (with both JAX-WS and the
> Simple frontend), and set the writeXsiTypes and readXsiTypes properties of
> the aegis context to "true" but I still don't get the xsi:type on the
> returned value.
>
> I think the question here is if my expectation is correct: should I have
> the xsi:type with my current configuration in the <return> element or not?
> If not, can I somehow get it there?
>
> Thanks,
> Rado
>
> immutability wrote:
> > Hello everyone - I'm new to webservices in Java, so my issue may be some
> > trivial, but I've had a hard time trying to figure this out. I've been
> > playing with CXF for a while, and I've created a simple web service to
> > test integration with spring.
> >
> > It all seems to be working fine, but what I need to do is make this
> > compatible with older versions of client applications which are using
> > org.apache.soap to talk to the service. Currently, these applications can
> > properly call methods of my webservice, but fail to parse the returned
> > response, possibly due to the missing xsi:type attribute. My testing
> > service is currently very simple and contains a single method "login"
> > accepting 2 string parameters username and password:
> >
> > @WebService
> > public interface HelloService
> > {
> > boolean login(
> > @WebParam(name = "username")
> > String username,
> > @WebParam(name = "password")
> > String password);
> > }
> >
> > The JAX-WS endpoint is defined in my spring XML.
> >
> > The SOAP response looks like this:
> >
> > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
> > <soap:Body>
> > <ns1:loginResponse xmlns:ns1="urn:soap-interface">
> > <return>true</return>
> > </ns1:loginResponse>
> > </soap:Body>
> > </soap:Envelope>
> >
> > It looks like the clients expect the following:
> > <return xsi:type="xsd:boolean">false</return>
> >
> > Is there a way for me to make CXF add the xsi:type attribute to the
> > return value somehow? Am I doing something wrong here, or do I need to
> > use some annotation to make it use the xsi:type?
> >
> > Again, I apologize if this is something stupid, I'm still learning.
> > Thanks for any clues in advance!
> >
> > Rado
--
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog
Re: xsi:type missing in returned value
Posted by immutability <de...@bielik.org>.
Any clues, anyone? I've been struggling with this for too long now, read all
possible and impossible forum posts, bug reports, etc. (the positive side of
this is that I have a much better understanding of web services now) ;)
I've also tried to use Aegis instead of JAXB (with both JAX-WS and the
Simple frontend), and set the writeXsiTypes and readXsiTypes properties of
the aegis context to "true" but I still don't get the xsi:type on the
returned value.
I think the question here is if my expectation is correct: should I have the
xsi:type with my current configuration in the <return> element or not? If
not, can I somehow get it there?
Thanks,
Rado
immutability wrote:
>
> Hello everyone - I'm new to webservices in Java, so my issue may be some
> trivial, but I've had a hard time trying to figure this out. I've been
> playing with CXF for a while, and I've created a simple web service to
> test integration with spring.
>
> It all seems to be working fine, but what I need to do is make this
> compatible with older versions of client applications which are using
> org.apache.soap to talk to the service. Currently, these applications can
> properly call methods of my webservice, but fail to parse the returned
> response, possibly due to the missing xsi:type attribute. My testing
> service is currently very simple and contains a single method "login"
> accepting 2 string parameters username and password:
>
> @WebService
> public interface HelloService
> {
> boolean login(
> @WebParam(name = "username")
> String username,
> @WebParam(name = "password")
> String password);
> }
>
> The JAX-WS endpoint is defined in my spring XML.
>
> The SOAP response looks like this:
>
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
> <soap:Body>
> <ns1:loginResponse xmlns:ns1="urn:soap-interface">
> <return>true</return>
> </ns1:loginResponse>
> </soap:Body>
> </soap:Envelope>
>
> It looks like the clients expect the following:
> <return xsi:type="xsd:boolean">false</return>
>
> Is there a way for me to make CXF add the xsi:type attribute to the return
> value somehow? Am I doing something wrong here, or do I need to use some
> annotation to make it use the xsi:type?
>
> Again, I apologize if this is something stupid, I'm still learning. Thanks
> for any clues in advance!
>
> Rado
>
--
View this message in context: http://www.nabble.com/xsi%3Atype-missing-in-returned-value-tp22410060p22501441.html
Sent from the cxf-user mailing list archive at Nabble.com.