cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From immutability <devli...@bielik.org>
Subject Re: AW: AW: xsi:type missing in returned value
Date Mon, 23 Mar 2009 21:43:29 GMT

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.


Mime
View raw message