cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christofer Dutz" <c.d...@upw.de>
Subject AW: xsi:type missing in returned value
Date Mon, 16 Mar 2009 13:56:50 GMT
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
 


Mime
View raw message