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:[email protected]] Gesendet: Montag, 16. März 2009 21:08 An: [email protected] 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:[email protected]] > Gesendet: Freitag, 13. März 2009 20:47 > An: [email protected] > 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 > [email protected] > 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
